Using FIDO2 keys to deploy passwordless devices

This post makes frequent references to a previous blog post I wrote specifically on deploying passwordless devices: Deploy Passwordless Devices for New Users – Device Advice. I split out the FIDO2 key section because for new users the experience can be fairly convoluted, and I would highly recommend the methods from the other blog post for primarily deploying devices.

Aside from the Microsoft Authenticator app, the only other supported passwordless option during OOBE is using a FIDO2 key. But here’s where things get a bit tricky. To set up a FIDO2 key, users must also set up an Azure MFA method. Easy enough, there are 4 Azure MFA authentication methods listed on the docs page:

But the question is… if enabling FIDO2 keys requires also setting up an Azure MFA method, why not just use the Microsoft Authenticator app? The only reason I can think of is that you have a requirement that users can’t register or use their phones. And if that’s the case, the only Azure MFA method you can use is OATH Hardware tokens. (Note it does also support software tokens, but then we’re back to the “them using their phone” problem).

If you really don’t want users using their phones, you’ll need to ship them both a hardware token and a FIDO2 key. So that will be the purpose of today’s blog post – to cover how this would look for entirely new users (like when onboarding an employee). For users already using a previously configured device, some steps would be skipped because they already have access to Azure AD aware applications using their regular credentials.

Setup and configuration

First, let’s create a new user with a random password that we won’t save:

Since we’ll need that user to set up MFA, let’s make sure the right methods are enabled. Go to Azure Active Directory > Users > Multi-Factor Authentication

We talked about this page in a previous blog post – don’t worry if the multi-factor auth status is set to disabled for anyone, because this page is a bit poorly named. Click on service settings and enable Verification code from mobile app or hardware token:

In the “no phone” scenario, you may also want to uncheck the rest of the options.

With the hardware token option enabled, we now have an Azure MFA method ready for the user to set up prior to the FIDO2 key. Hardware tokens aren’t supported for primary authentication (just as an MFA method), so we can’t just stop here for a passwordless deployment.

Go to Azure Active Directory > Security > Authentication methods. This time we’ll click FIDO2 Security Key, and select Yes under Enable. Click Save.

We’ll also want to enable the combined registration experience, so click on the blue banner that says Click here to enable users for the combined security info registration experience. Then click All under the Users can use the combined security information registration experience option:

Now, we need to actually get the user to register for Azure MFA and set up their FIDO2 key. Go to Azure AD Identity Protection > MFA Registration policy:

This policy means that the next time a user hits the Azure AD page, they’ll be forced to set up MFA. Under assignments, you can select a group of users who should register for Azure MFA, and then click Enable. Forcing MFA registration can also be done using a Conditional Access policy, but I prefer this method.

With all the prerequisites in place, we have one final requirement – we need to set up a temporary access pass for the user to log in initially and set up their MFA tools. To do this, go to Azure Active Directory > Users > select user > Authentication methods > + Add authentication method > Temporary Access Pass (Preview). Click here for screenshots from my previous blog post on passwordless devices 🙂

End user experience

Here is our new user’s super modern workflow with a FIDO2 key:

1. Call the IT Helpdesk for their temporary access pass (my personal recommendation here is to set it to expire after after a few hours, rather than 1 time use, because when they go to set up the security key they will be prompted to re-authenticate)
2. Turn on their new laptop. Attempt to log in with the temporary access pass:

3. The login portal will recognize that the password wasn’t correct, and then give the option of using the Temporary Access Pass:

4. Complete Windows Hello setup:

5. Once they get to the desktop, open Edge and go to myprofile.microsoft.com:

6. Because of the Azure AD Identity Protection policy, they are required to set up an MFA method:

7. They set up the Hardware token (in the following screenshot, I set up a software token using the authenticator app because I don’t have a hardware token available)

8. Once the Hardware token is set up, they click on Update info in the Security info box:

9. Here they click +Add method and select Security key

10. After verifying log in once again, they complete set up of the security key by entering a PIN & name:

And they’re done! Now they can sign-in to their Windows 10 PC using the security key.

Recap

I think it’s clear through all these screenshots that this isn’t the most pleasant experience. But it does work – we can deploy devices to new users without using a password. Arguably, the temporary access pass is a password, but at least it natively expires.

And more importantly – once they have the FIDO2 key set up, setting up their next PC will be significantly easier! All they need to do is click the Sign in with a security key button in OOBE:

And of course, the FIDO2 key will work across the board for any of their workflows for authenticating against Azure AD. Maybe they want to log in to an Azure Virtual Desktop (previously WVD) instance on their personal computer:

I’m sure I’ll be writing more zero trust passwordless devices blog posts in the future, because it does seem to be the direction the industry is heading. And as more blog posts get written, I’m sure the process will become much more seamless. Until then – happy securing! 🔐