Introduction
Traditional authentication methods are increasingly vulnerable to phishing attacks. Microsoft Entra ID offers a variety of authentication methods, but not all of them provide strong phishing resistance.
Authentication Method | Phishing Resistant? | Notes |
---|---|---|
Windows Hello for Business | ✅ Yes | Uses TPM-bound keys and biometrics/PIN. Fully phishing-resistant. |
FIDO2 Security Keys | ✅ Yes | Hardware-based authentication with biometric/PIN. Fully phishing-resistant. |
Certificate-based Authentication (CBA) | ✅ Yes | Uses X.509 certificates. Resistant to phishing if properly implemented. |
Microsoft Authenticator (Push Notification + Phone Sign-in) | ❌ No | Push notifications and Phone Sign-in are not phishing-resistant. |
Microsoft Authenticator (OTP) and Third-party software / hardware OATH tokens | ❌ No | One-time passcodes (OTP) are susceptible to phishing attacks. |
SMS | ❌ No | Can be intercepted via SIM-swapping or phishing attacks. |
Voice Call Verification | ❌ No | Vulnerable to call interception, phishing, and social engineering. |
Email OTP | ❌ No | Can be phished and compromised if email is breached. |
Temporary Access Pass (TAP) | ❌ No | Should only be used for registering passwordless Authentication Methods |
The most commonly used Microsoft Authenticator with Push Notifications and Phone Sign-in is not phishing-resistant. Attackers can use tools like Evilginx to steal session cookies to bypass MFA and gain unauthorized access. For more details, check out my colleague Roman's post:
Since January 2025, Passkeys are generally available in the Microsoft Authenticator app. This means that organizations with the passkey (FIDO2) authentication methods policy enabled and no key restrictions, will be able to use passkeys in the Microsoft Authenticator app in addition to FIDO2 security keys. Passkeys, based on FIDO2 standards, are designed to provide a phishing-resistant and seamless authentication experience by eliminating the need for traditional passwords. Device-bound passkey is a type of passkey that is securely stored on a user's device and requires biometric authentication (such as Face ID or fingerprint sensors) or a device PIN to sign in. Unlike cloud-synced passkeys, device-bound passkeys remain on a single device, reducing the risk of unauthorized access if a user’s cloud account is compromised.
But are Passkeys ready for prime time in enterprise environments? Can organizations confidently deploy passkeys at scale today, or are there challenges that still need to be addressed? In this post, we'll explore the current state of passkeys in Entra ID, their limitations, and best practices for deploying them to users.
Deploying Passkeys in Entra
Before we get into the challenges and limitations, let's first enable passkeys and explore the best way to deploy them to users.
Requirements
There are some requirements for registering passkeys:
- Android 14 and later or iOS 17 and later.
- Microsoft Authenticator App
- Another registered MFA or TAP (Temporary Access Pass) for new Users
- For cross-device registration and authentication:
- Requires Bluetooth on both devices for proximity check.
- Attestation must be disabled in the Authentication Policy.
- Passkeys must be enabled for users in the Authentication Policy.
Configure the Authentication Method policy
Microsoft has announced that starting September 30, 2025, the ability to manage authentication methods through the legacy Multifactor Authentication (MFA) and Self-Service Password Reset (SSPR) policies in Entra ID will be retired. If you haven't migrated to the new Authentication Policy yet, I recommend doing so as soon as possible. Find out how here.
Now, let's configure the Authentication Method policy.
- Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.
- Browse to Protection > Authentication methods > Authentication method policy.
- Under the method Passkey (FIDO2), select All users or Add groups to select specific groups. Only security groups are supported.
- Click on Configure to set up the Passkey settings.

- If you choose to restrict specific keys, you have to select the Option Microsoft Authenticator to automatically add the AAGUIDs.
Since an MFA claim is required to register a Passkey, you need alternative methods for new users. Temporary Access Pass (TAP), which is considered a form of MFA, comes into play here. Let's configure it as well:
- Browse to Protection > Authentication methods > Authentication method policy.
- Under the method Temporary Access Pass, select All users or Add groups to select specific groups. Only security groups are supported.
- Click on Configure to set the TAP settings.

- The TAP can be configured to require one-time use. Even though it's good for security, one-time use is not ideal as it disrupts the authentication flow when registering a passkey.
Create a custom Authentication Strength
Now, you need to create a custom authentication strength to enforce specific authentication methods using a Conditional Access policy. Do not use the built-in Passwordless MFA or Phishing-resistant MFA authentication strengths, as TAP is not included in them. This will cause issues when creating passkeys for new users who do not yet have MFA.
- Browse to Protection > Authentication methods > Authentication strengths
- Click on New authentication strength

- We will now include some passwordless authentication methods and TAP. Ensure that you also add the AAGUIDs for Microsoft Authenticator.
Create a Conditional Access policy
To enforce the authentication strength, we will create a Conditional Access policy.
- Browse to Protection > Conditional Access > Policies
- Click on New policy
- Choose the users you want to assign the policy to. I highly recommend testing this policy with a pilot group. And don't forget the exclusions!
- Choose the resources you want to protect – All resources or specific applications.
- The important thing is to ensure that you require authentication strength in Access controls and select the custom authentication strength you created earlier.

Registering Passkeys in Authenticator app
For onboarding new users, you need to issue them with a Temporary Access Pass (TAP) to register their passkey. You must also ensure that the TAP is delivered securely to the user!
There are two options for registering a passkey in the Authenticator app, each with its own advantages and disadvantages.
Same-device registration
In the same-device registration process, the passkey is created directly on the device where the Microsoft Authenticator app is installed. This means the registration happen on a single device without requiring a second device for scanning or verification. This is the recommended option.
Existing users with an already registered MFA method can create a passkey directly in the Authenticator app.

For onboarding new users, I recommend instructing them to add the company account to the Microsoft Authenticator app first. They can then log in using multi-use TAP. After that, they can create a passkey and use it for Autopilot enrollment as well.
Cross-device registration
It is possible to register a passkey via https://aka.ms/mysecurityinfo using the legacy wizard. The disadvantage is that you must disable attestation in the Authentication Methods policy, which is not recommended. If the user clicks on Add sign-in method, they will be guided to create the passkey in the Microsoft Authenticator app. However, by clicking on the Having trouble? link, they can access the legacy wizard.


The user will be guided to scan a QR code to add the passkey in the Microsoft Authenticator app.
Challenges
Now that we have covered how to deploy and register passkeys for our users, can we lean back and chill while enjoying passwordless and phishing-resistant authentication? Not quite..
- When you use the recommended same-device registration and have a Conditional Access policy that requires a compliant device (iOS and Android), users cannot add passkeys in the MS Authenticator app on their personal devices if the device is not compliant.
- The same issue applies to companies that require approved client apps or app protection policies with a Conditional Access policy. The MS Authenticator app cannot be targeted as an approved client app. Currently, the workarounds provided by Microsoft are not ideal for security:
Users who can't register passkeys because of Require approved client app or Require app protection policy Conditional Access grant controls - To allow the Authenticator app to autofill passkeys, users must define the passkey provider setting. However, since every Android phone is different, it's difficult to provide instructions that work for everyone.
- Additionally, passkeys on Android are tied to the specific profile in which they are stored. If a passkey is saved in an Android Work profile, it can only be used within that profile. Similarly, if a passkey is stored in an Android Personal profile, it is only accessible from that profile. At the moment, Microsoft recommends adding two passkeys for each profile.
Conclusion
With passkeys, Microsoft is taking a significant step in the right direction toward improving security and simplifying authentication. While the foundation is strong, I believe it's not entirely ready for prime time just yet. There are still some challenges and limitations that need to be addressed.
However, given the rapid pace at which Microsoft has been improving its security features, I’m confident that these challenges will be resolved in the near future. Once those are addressed, passkeys will undoubtedly become a robust and widely adopted solution for passwordless authentication.
Member discussion