Hi and welcome back!
Do you want your employees to be able to log on without passwords in your tenant? And even better, do you want them to get phishing-resistant logon? Let’s go ahead and set it up!
This picture is Microsoft’s, and I’m just borrowing it for reference.
For more information on authentication and verification methods, you can visit Microsoft Learn here; Authentication methods and features – Microsoft Entra ID | Microsoft Learn
Everything is better then just a username and password. If you don’t have MFA setup in your tenant yet, do it.
You should skip SMS and voice, that’s not really a good option any longer. Number matching/Push notifications MFA with number matching is better than no MFA.
Next level is passwordless. But be aware, attackers with good phishing-kits is also able to intercept the MFA-token now with AiTM-attacks, so passwordless-MFA is not 100% secure any longer either. But it’s still better than no MFA and MFA with number matching. As you can see on the picture, passwordless is on the far right, but passwordless-MFA is not phishing-resistant.
If you want to go phishing-resistant, your options is either Windows Hello for Business (WHfB), Passkeys with security keys like FIDO, Passkeys in Authenticator-app or certificate based.
In this article I will show you how to enable Passwordless-MFA and Passkeys for Authenticator-app and Security Keys.
I will try to do another article on WHfB later on, so you can secure your local logon on the computers with passwordless options as well.
Head over to portal.azure.com and PIM yourself to either Authenticator Admin or Global Admin. If you’re going to set up a Conditional Access policy to enforce the usage also, you will need at least Security Administrator or Conditional Access Administrator as well.
(What is PIM? Have a look here: (Blogpost-in-the-making)
On the left menu, under “Manage”, locate “Security” and click there. Under “Manage” you will find “Authentication Methods” – and we are in the right place;
This is a fresh tenant, so I’ve done nothing yet. First, I will go to the “Microsoft Authenticator” policy. Firstly, I enable it with the toggle, I will include “All Users” and I will choose “Passwordless” as my preferred authentication mode;
Secondly, I will go to the “Configure”-tab and do some other settings;
- If you want to enable the use of the 6-digit code in Authenticator-app, you can set the “Allow use of Microsoft Authenticator OTP” to yes – I choose not to do it in this scenario.
- “Require number matching for push notifications” is Enabled as default now
- I’m enabling “Show application name in push and passwordless notifications” – this way the users will see what application is requiring them to perform MFA.
- I’m enabling “Show geographic location in push and passwordless notifications” – this way the users will see what location the MFA-prompt is coming from. Note: This will not always be 100% accurate, as it can show the location of the nearest mobile tower if you’re using cellular – or it can show a location used from the ISP-provider. But at least it will give you a close-to-correct location and the country.
- The last option, “Microsoft Authenticator on companion applications”, has to do with the Authenticator Lite – have a read here; Enable Authenticator Lite for Outlook mobile – Microsoft Entra ID | Microsoft Learn. I’m keeping it like it is; “Microsoft Managed” in this scenario.
- Hit “Save”.
If you are providing your users with a passwordless option to sign in, maybe you don’t want them to have a password at all, right? In this case, the use of TAP (Temporary Access Pass) is most likely the way to go.
Temporary Access Pass, or TAP, is a time-limited or limited-use passcode that can be used by users for bootstrapping new accounts, account recovery, or when other auth-methods are unavailable. I’m not going to do this now, as I hopefully will have a blogpost later, diving a bit deeper into this and how this could be administrated in a good way for a bigger organization. But if you want to set it up, have a read through Microsoft’s documentation here; Configure a Temporary Access Pass in Microsoft Entra ID to register passwordless authentication methods – Microsoft Entra ID | Microsoft Learn
Let’s get to the phishing-resistant bit!
In the “Authentication methods | Policies” page, click on Passkey (FIDO2). Enable it with the toggle and go to “Configure”.
- Set “Allow self-service set up” to “Yes”. If set to “No”, users can’t register a passkey by using “Security info”, even if passkeys (FIDO2) are enabled by the Authentication methods policy.
- Set “Enforce attestation” to “Yes” if your organization wants to be assured that a FIDO2 security key model or passkey provider is genuine and comes from the legitimate vendor.
- NOTE: We will set this to now in this scenario since this is not currently supported for use with Microsoft Authenticator and we want to try the “Microsoft Authenticator (Preview)” function in addition to the FIDO2 security key.
- Next, we set “Enforce key restrictions” to “Yes” so we only allow or disallow certain security key models or passkey providers which are identified by their AAGUID. In our scenario we will allow the AAGUID for a Yubico YubiKey 5 (2fc0579f-8113-47ea-b116-bb5a8db9202a). Search for AAGUID and your FIDO2-vendor to find the one you need – more AAGUIDs for YubiKey can be found here; YubiKey Hardware FIDO2 AAGUIDs – Yubico) – and the AAGUID for iPhone
- We set “Restrict specific keys» to “Allow”
- We enable the “Microsoft Authenticator (Preview)” – this populates the AAGUID-list with the AAGUIDS for both iOS Microsoft Authenticator (90a3ccdf-635c-4729-a248-9b709135078f) and Android Microsoft Authenticator (de1e552d-db1d-4423-a619-566b625cdc84). I also add the AAGUID for the YubiKey here.
My setup now looks like this;
As you can see, both Passkeys and Passwordless is now enabled for my users. Before we leave this page, we will visit two more options on the menu on the left.
In “Authentication Strengths” you can see that there is some built-in that we can use when we start enforce these settings on our users. Click on them to show a list over what is included. It will also show which is used in what Conditional Access policy. In our scenario we will focus on enforce the “Phishing-resistant MFA” which includes WHfB, Passkeys and Certificate-based.
Before I enforce these new settings, I will register the methods on my admin-user in this tenant. Head over to https://aka.ms/mysecurity and register these two new bad boys;
I want to register both of these, so my user will have two options in case I loose/forget my Security Key or I loose/forget my phone.
Instead of me using a lot of time taking pictures and upload those from the setup process – I will use this opportunity to refer to another blogger who I think is awesome and you should have in your list – Simon Skotheimsvik. This is a link to his passkeys-tutorial and it is filled with pictures from the user perspective; Simon does How to Use Passkey in Authenticator: A Tutorial. Be sure to check out his other awesome blogposts while you are there!
The last thing we will do here now, is in “Settings” to set “System-preferred multifactor authentication” to “Enabled”. This will ensure also that the most secure multifactor authentication method is presented to users when they try to log on. In our scenario this will not be so important, as we will enforce phishing-resistant with Conditional Access policies in the next blogpost.
NOTE: If you have used the old legacy MFA and Self-Service Password Reset (SSPR) policies, remember this will be deprecated on September 30th 2025 and all new settings will be managed here. If you haven’t switched over to these yet, do it now so it won’t come as a surprise. If you’re done already, set your migration status to Complete;
Hopefully I will see you again next time where we will enforce our new phishing-resistant MFA with Conditional Access policies – stay tuned!