Microsoft used the recent World Password Day to announce a preview many of us have been waiting for: passkeys in Microsoft Authenticator for Entra ID, now in public preview on iOS and Android. For a long time I've seen organizations struggle to get away from passwords without handing every user a hardware security key. With device-bound passkeys supported directly in Authenticator, that gap finally closes, and phishing-resistant sign-in becomes something most users can realistically adopt.

Device-bound passkeys turn the phone into the security key

A passkey is an asymmetric key pair. The private key lives only on your phone, where Microsoft Authenticator manages it securely. That makes an ordinary smartphone a phishing-resistant FIDO2 device, without any USB or NFC dongle. To sign in, you approve a biometric prompt (FaceID, fingerprint) on a device you already trust. Classic FIDO2 hardware keys work a little differently; these passkeys are bound to your individual device. If someone phishes your credentials, they still can't authenticate without your physical phone and your biometric check.

As you'd expect from a public preview, setup is limited for now. It only works in the Authenticator app on iOS or Android, and only through the Security Info self-service page, not the usual MFA wizard. According to the Microsoft documentation on enabling Authenticator passkeys and the passkey overview, registration creates a FIDO2 credential in the background, with an AAGUID that identifies the device type. If you've rolled out hardware FIDO2 keys before, you'll recognize the principle. The only difference is that the phone now is the security key.

The FIDO2/passkey method can be limited to Authenticator with AAGUIDs

Turning on passkeys in Entra ID takes some policy planning. It all runs through the new authentication methods policy, which every modern tenant should be using by now (I covered the move in Entra ID authentication methods policy migration). In that policy you enable FIDO2/passkey authentication for specific groups, and you can also restrict registration to certain device types by AAGUID. The official guide shows how to find and configure AAGUIDs so you decide exactly which FIDO2 devices are allowed, down to Microsoft Authenticator alone. I'd start with a pilot in a small group. That way you can watch the experience closely and help users when they get stuck.

# Example: Allow FIDO2 registration only for Authenticator (by AAGUID)
Set-MsolAuthenticationMethodPolicy -PolicyType Fido2 -IncludeAAGUIDs @('b6b27cbe-c130-4b5e-a77f-1e18e6a1aef2')

Pro tip: Check which AAGUIDs the phones in your fleet actually use. Device software updates or new Authenticator app versions can change these values.

Users register the passkey once and then sign in with biometrics

Users have to register a passkey before they can use it, and at the moment the only way is via https://mysignins.microsoft.com/security-info on a device running Authenticator. Once the passkey is added, signing in is simple. The user enters a username, picks the passkey method, approves with biometrics on the phone and is signed in. The private key never leaves the device, because authentication happens on the phone itself. The sequence diagram below shows the main steps and makes the trust boundaries easier to see:

sequenceDiagram
    participant User ["User"]
    participant WebApp ["Web app"]
    participant EntraID ["Entra ID"]
    participant Authenticator ["Authenticator app"]
    User -> WebApp: [Enter username]
    WebApp -> EntraID: [FIDO2/passkey request]
    EntraID -> Authenticator: [Send challenge]
    User -> Authenticator: [Confirm with biometrics]
    Authenticator -> EntraID: [Signed response]
    EntraID -> WebApp: [Sign-in success]

Figure: Authentication flow with passkey in Microsoft Authenticator

Passkeys hold up against phishing and AiTM attacks

The real gain is phishing resistance. Passkeys hold up well even against attack-in-the-middle (AiTM) techniques, which are built to steal MFA codes and session tokens. I've written separately about the ongoing AiTM phishing risk in Microsoft 365 (in this post). With a passkey, the private credential stays on the phone and every cryptographic operation runs locally. So if a user does get tricked into typing credentials on a fake site, the attacker still can't complete the FIDO2 challenge without the phone and the biometric confirmation. Combine passkeys with Authentication Strengths in Conditional Access and you can decide which high-value applications require the strongest sign-in method. That's a clear step forward for security and gives you more flexibility too.

The preview still has caveats and practical limits

I'd still be careful. This is a public preview, not a finished product, so it's not ready for production, regulatory or compliance-critical use. There's no central reporting and no automated recovery if a device is lost. Onboarding is self-service only, without automated provisioning or enrollment flows for now. If you run a pilot, write down clear support guidance for lost devices and app reinstalls.

My early tests show that passkeys in Microsoft Authenticator do improve both usability and security, even if the preview is rough in places. A limited pilot now is worth the effort. When general availability arrives, you'll be ready to give your users a modern, phishing-resistant sign-in experience.