I read a lot of blogs and posts about going passwordless. Some of these are from the Microsoft folks who have visibility of massive amounts of logon data, and the amount of attempted password attacks are numerous and terrifying.

This week in risual towers we have been testing passwordless sign-in with FIDO 2 Security keys – due to support for Azure Active Directory account logon with FIDO 2 keys having gone into public preview (July 2019)

Winding back a little – quite rightly Microsoft have made significant moves to go passwordless in recent times, and whilst it is not ‘passwordless’ the first thing I would say is please, please at least start to use Multi Factor Authentication (MFA). Even if someone manages to get your password and attempt to log on with it, they will still need a second factor such as text or approval message to a trusted device such as a phone, or a bio-metric such as fingerprint or face.  I’ve seen quoted that 81% of hacking breaches are because of stolen or weak passwords, and the risk of compromise is cut up to 99.9% by using MFA. And if that happens, how much will it cost not only in terms of cold hard cash, but reputation and productivity.

If MFA is so great then, why not just use that?

MFA can present users with a slightly clunky experience, and whilst more secure can be inconvenient. Passwords are convenient, but less secure. The nirvana of highly secure and convenient is the sought-after goal.

Windows Hello for Business

Windows Hello for Business (WHfB) replaces passwords with strong two factor authentication, and has been around for some time since Windows 10 1511 in fact. There are some infrastructure prerequisites depending on the requirements and therefore the trust model used. When everything is configured (that’s another blog!) the user is prompted to enrol for Hello at logon​ and two-step verification that takes place.

This enrolment:

  • Creates a cryptographic key pair bound to the device
  • Validates the user and creates a trusted relationship between the identity provider (Azure Active Directory (AAD)) and the user​ – the public portion of this public/private key pair is sent to AAD and mapped to the user account.
  • Access to the private key held in Trusted Platform Module or Software locally is only via your Hello PIN or (Bio-metric) gesture.
  • When a user enters the gesture on the device, AAD knows from the combination of Hello keys and gesture if all is good and issues an authentication token that allows Windows 10 to access resources and services. (Again, WHfB the authentication flow is a separate blog, and don’t make me say NONCE in a crowded room again).
  • The cryptography used is strong, and the public/private key encryption is tied to the session, cutting the chances of a man-in-the-middle attack and a baddie being able to replay your authentication token.

I have to say if the camera is compatible, I really like the facial recognition sign in with Windows Hello for Business, combined with seamless single sign on I think that makes for a great user experience.

This is great then. With WHfB I’m not using a password, I’ve got strong cryptography but as the points above suggest, I’m tied to the device. At risual because of the nature of how we work, we all have our own device, but organisations such as healthcare where staff may move consulting rooms, help desk staff who sit in areas with many PCs and no allocated desk, airport staff who move around to different desks – would need a different solution. They need to securely authenticate whilst moving around computers. This is where the security key comes in.


​FIDO is a board of companies that include Microsoft, Google, Facebook, eBay and ‘FIDO 2’ are a universal set of standards for going passwordless. Security Keys themselves from the likes of Yubico have been around for some time, and in recent months support for FIDO 2 compliant security key logon has been added for Microsoft accounts as a taster before the big announcement of support for FIDO 2 Key Azure Active Directory logons last week.

We were very excited by this, so decided to purchase some cheap keys to test. We ended up getting:

The Yubico Security Key (£19)

and the KEY-ID key (£7)


Lesson 1: read the small print. The Key-ID key, whilst FIDO 2 compliant and ‘Windows compatible’ could be used for Google, Dropbox logon etc but is not compatible for use with a Windows 10 Logon. We got an error when trying to use it but I had suspected as much before we tried due to the cheapness of it. There is a list of requirements here – there are a lot of choices when looking say on Amazon and it is worth double checking your one will work before ordering 3000. Hey ho it was so cheap you could give it away as a freebie (hence forever being known as the “happy meal” key)

You can look at keys and register for a Yubikey passwordless kit here: I did have a look at the Feitian website as having a key with built in fingerprint reader would be cool but they seemed to not be available in the UK and the US Feitian website only delivered their side of the pond. 🙁

The following Microsoft article is a good guide on how to configure the back-end components to allow you to test AAD logon with a FIDO 2 Key:  https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-enable

I don’t want to regurgitate the article, but the below details how we walked through the steps with some screenshots:


Did we have?

  • Azure Multi-Factor Authentication – check, we have this enabled.
  • Combined registration preview – check, this is now in public preview.
  • FIDO 2 security key preview requires compatible FIDO 2 security keys – check, lets forget about the Happy Meal.
  • WebAuthN (allows browser-based apps to interact with security key) requires Microsoft Edge on Windows 10 version 1809 or higher – check, our devices are on 1903.
  • FIDO 2 based Windows sign in requires Azure AD joined Windows 10 version 1809 or higher – check, our devices are on 1903 and AAD joined.


Then the fun bit

To enable Passwordless sign in with FIDO 2 Keys

  • The new credential provider needs to be enabled (in Azure portal)
  • Who can use the new credential provider needs to be defined (e.g. a test group in Azure and settings pushed out via Intune)
  • Enable and configure the preview (In Azure)
  • Obtain and register the Security keys (client device)


Enable Credential Provider & configure Intune:

We enabled the new Credential Provider using Intune:

We set “Use Security Keys for Sign in” – set to Enabled

To enable a pilot group to be able to use the new credential provider, we created an Azure AD group e.g. FIDO Key Test, and created an Intune Profile as per the Microsoft article. It is basically a custom profile that uses an OMA-URI setting to turn on the use of security keys for sign in.

Due to my impatience, we forced an Intune sync on my device to pull down the new settings. A provisioning package can also be created using the article guidance, which would allow devices not managed by Intune to be configured to use the security keys.

Configure Preview:

The preview feature also needs to be enabled to allow access to the FIDO 2 registration features. We can set which groups can register, and we are testing without impacting the rest of the business:

Configure Keys:

Now the back end work was done, we went to https://myprofile.microsoft.com (before this was configured going to this URL displays a page basically saying the feature hasn’t been switched on)

This shows the security info page for your account, including your recent sign in activity and sign in methods to which the Security Key can be added.

From security info, we added a method, chose security key and followed the instructions.

This gave an additional option on the logon screen when I locked and went to unlock my PC:

Going forward this is a logon option from my PC, and I can use my key to log on to other configured devices.

Also from my home PC when logging on to Office 365 from the (supported, don’t forget the prerequisites!) browser I can use the option below from “sign in options” on the launch page:

I insert my Yubi key, no username required and enter my PIN:

In this case touch the key and I’m logged in:

Final comments and thoughts for now:

  • Following setup instructions was straightforward – both on the admin portal and client side.
  • Make sure that you have the right compatible security key type! A standard key is relatively cheap (our Yubico one was £20) there are ones with NFC functionality which would require your device to have an NFC reader and I’d love to get my hands on a Fetian key with fingerprint reader.
  • Logon with the keys seems to work well, albeit the USB connection seems a bit jiggly in my Microsoft Surface USB port.
  • Having been already logged on when I provisioned my Yubi Key, I decided to reboot and log on with the Security key to get the full experience from the beginning. Because of the way our building network access works, you can’t initially log on with the Security key. To authenticate I needed to be connected to the Wi-Fi, but the building Wi-Fi relies on you being authenticated as your user account. Bit of a chicken and egg situation and fixable with some Wi-Fi configuration tweaking. Moving on to a normal internet connection, I could log on fine with the key and things worked as they should.
  • The support team quite like the idea of being able to move around devices, or at least use their key to sign into browsers on different devices, but I would never log on to someone else’s device in practice.

As it is, the existing Windows Hello for Business offering provides a great experience with PIN and facial recognition, and has some cool features like proximity additional factor (to log on I use my PIN *and* my device has to be bluetoothed to my mobile) there are other scenarios and setups we want to test, but this new support for Security Keys is really exciting for those who have a dynamic working environment and need to move around between devices. A great step in the quest for going passwordless.

About the author