Passkeys in Entra ID: Where Are We Now?

Writing this in late 2025, I can’t go to a conference or open a vendor pitch deck without hearing “passwordless is the future.” And look, they’re right — it is. But there’s a pretty big gap between the slick demos on stage and what’s actually happening in production. So here’s an honest look at where passkeys in Entra ID really stand right now.

The FIDO2 to Passkey Evolution

If you’ve been using FIDO2 security keys with Entra ID, you’ll have spotted the terminology changing. Microsoft have been quietly shifting from “FIDO2 security key” to “passkey” across their docs and the portal. It’s not just a rebrand though — it reflects the wider industry move towards the passkey standard under the FIDO Alliance.

Under the hood, the tech is the same — WebAuthn and CTAP2. But passkeys bring in some distinctions that matter, especially around portability. The old model was dead simple: physical security key, stores your credential, done. Passkeys make things more nuanced, in ways that are mostly helpful.

Two flavours to get your head around:

• Device-bound passkeys: These live on a specific piece of hardware. Your YubiKey, a Windows Hello TPM credential, a hardware security key. Can’t be copied, can’t be synced. This is basically what FIDO2 keys always were.

• Synced passkeys: These synchronise across devices through a platform credential manager. Apple Keychain, Google Password Manager, or — and this is the one that matters for Microsoft shops — Microsoft Authenticator.

Both types are phishing-resistant. Both get rid of passwords. But the security profiles are quite different, and that distinction absolutely matters when you’re writing Conditional Access policies.

Microsoft Authenticator Passkey Support

For most organisations, this is the biggest development. Microsoft Authenticator now supports passkeys, so your users can register a passkey on their phone and use it to sign in to Entra ID.

The experience is pretty smooth. User registers a passkey in Authenticator, and after that they can sign in by scanning a QR code or via Bluetooth proximity when they’re authenticating on a different device. On the phone itself it’s even simpler — biometric prompt and you’re in.

I’ve been testing this across a few different environments and the UX is genuinely good. It feels similar to the existing passwordless phone sign-in flow but with a proper FIDO2/passkey credential behind it, which means it’s phishing-resistant in a way that push notifications just aren’t.

The catch? You need recent-ish versions of Authenticator, devices need Bluetooth LE support for cross-device flows, and there are still some edge cases where older browsers and operating systems don’t cooperate. None of them are showstoppers, but test thoroughly before rolling this out to thousands of people. I spent a full afternoon once debugging a Bluetooth issue on a fleet of managed laptops that turned out to be a group policy conflict. Not a fun afternoon.

The passkey registration documentation has the setup details.

Cross-Device Authentication

This is where it gets interesting — and sometimes frustrating. Cross-device authentication means using a passkey on one device (usually your phone) to sign in on another (usually your laptop).

It uses Bluetooth proximity to check both devices are physically near each other, then shows a QR code or sends a push to complete the sign-in. When it works, it’s slick. But I’ll be honest, “when it works” is doing quite a lot of heavy lifting in that sentence.

In practice, I’ve run into:

• Bluetooth being Bluetooth: Corporate laptops with managed Bluetooth policies interfering with the proximity check
• Browser inconsistencies: Not every browser handles the WebAuthn cross-device flow the same way
• Users scanning with the wrong app: Explaining that they need to scan the QR code with Authenticator, not their camera app, takes more effort than you’d expect

All solvable, but they do add friction to something that’s meant to be frictionless. Test the cross-device flow thoroughly in your actual environment before you make it anyone’s primary authentication method. Trust me on this one.

Conditional Access and Authentication Strength

Here’s where the policy side catches up. Conditional Access authentication strength policies let you distinguish between different types of passkeys.

You can build custom authentication strength policies that require:

• Any passkey — device-bound or synced, either works
• Device-bound passkeys only — when you want the higher assurance of hardware-bound credentials
• Specific FIDO2 security key models — via AAGUIDs, same mechanism as before

This matters a lot for organisations with different assurance levels. General workforce? Synced passkeys through Authenticator are probably fine. Privileged admins managing production infrastructure? They should be on device-bound passkeys with hardware security keys. Different risk, different requirements.

The setup is covered in the authentication strength overview. I’d say create at least two authentication strength policies from the start — one for standard users, one for privileged roles.

Where Passwordless Actually Stands

Right, let me be straight about what I’m actually seeing out there.

What’s going well:

• Windows Hello for Business adoption is solid on Entra joined and hybrid joined devices
• FIDO2/passkey security keys are reliable for privileged users who are motivated to use them
• Authenticator passkeys look promising and the UX is good
• Conditional Access authentication strength gives us the policy controls we’ve been asking for

What’s still hard:

• Legacy apps that don’t do modern authentication — every single organisation has some
• Shared device scenarios where passkeys are an awkward fit
• Registration and lifecycle management at scale still feels clunky
• Temporary Access Pass is a must for onboarding and recovery, but not everyone plans for it properly
• Reporting on passkey vs password usage across the tenant — it could be better, to put it politely

Where things actually sit: Most organisations I work with land somewhere between 30-60% passwordless for day-to-day sign-ins. That’s decent progress, but it’s miles from the “passwords are dead” narrative you hear everywhere. The rest is usually stuck behind legacy apps, weird edge cases, and the sheer organisational effort of getting everyone migrated.

My Recommendations

If you’re heading towards passwordless and haven’t got into passkeys yet:

1. Turn on passkey registration alongside your existing FIDO2 policy — it’s mostly the same config
2. Get authentication strength policies set up before you need them — separate your standard and privileged requirements early
3. Pilot Authenticator passkeys with a group of willing testers first — work out the cross-device kinks in your environment before going broad
4. Sort out your Temporary Access Pass policy — you will need it for onboarding and account recovery, guaranteed
5. Don’t kill passwords yet — run both in parallel and track actual usage data before you make any big decisions

The direction of travel is clear and the technology is getting there. But this is a journey, not a switch you flip one morning. Anyone who tells you otherwise is trying to sell you something.

For the full picture, the Entra ID passkeys documentation is where to start. Happy to chat about deployment strategies if you’re planning a rollout — it’s a topic I don’t get tired of talking about.