Passkeys:Security Only Works If People Use It

There's a version of this post that opens with statistics about phishing attacks, credential theft rates, and breach costs. You've read that post a hundred times. It doesn't change behavior. Here's a different opening.

Last year a user got a new iPhone. They logged into their password manager, their photos were already there, their apps restored, their contacts synced. They opened their work email, got prompted to authenticate, tapped Face ID, and were in. They texted their IT admin: "Wait, that's it? That was easy."

That moment — the "wait, that was easy" moment — is the entire argument for passkeys. Not the cryptography. Not the FIDO2 spec. Not the AAL2 compliance validation. The moment a user realizes the most secure way to log in is also the easiest way to log in is the moment adoption becomes possible.

This conversation has shifted significantly in the last six months. As of March 2026, synced passkeys and passkey profiles reached General Availability in Microsoft Entra ID. This isn't a preview feature to pilot with early adopters anymore. It's production-ready infrastructure that's being auto-rolled into tenants that already have FIDO2 enabled.

More importantly: if your tenant is in scope, Microsoft's managed registration campaign has already started nudging users to register passkeys after MFA. Not sometime in the future. Right now. The question isn't whether your users will encounter this. It's whether you planned the rollout or whether your helpdesk is about to find out through tickets.

The most common objection to passkey deployment is "but what happens when a user gets a new phone?" It's the right question, and for years the honest answer was "it's complicated." Synced passkeys change that answer to "nothing, it's already there."

But synced and device-bound passkeys are not interchangeable, and treating them as such is where most deployment plans go wrong. The right model is a segmented assurance model: different credential types for different risk profiles, enforced through passkey profiles in Entra.

Passkey profiles in Entra are what make this split operationally real. You can require hardware-bound passkeys for your Global Admins while allowing synced passkeys for the rest of the organization, all within a single authentication methods policy. You don't need separate tenants, separate configurations, or separate rollouts. One policy, two profiles, two risk tiers handled cleanly.

Here's the problem nobody talks about in passkey deployment guides: how does a brand new employee register a passkey when they have no prior credential to authenticate with in the first place?

It's a genuine chicken-and-egg problem. Passkey enrollment requires authentication. Authentication requires something the user already has. A new employee has nothing yet. The old answer was to set a temporary password, let them log in, then have them register their authenticator. Every step of that process is a security gap. The temporary password is a phishable credential. The setup flow is an opportunity for a social engineering attack. The transition period is where things go wrong.

TAP also solves the recovery scenario. User loses their phone or their hardware key. They can't log in. You generate a TAP, they use it once to register a new passkey, and they're back. No password reset, no SMS fallback, no regression to a weaker method. The recovery path is as strong as the initial enrollment path.

Ask a non-technical user what a passkey is. Then ask them what a security key is. Then a hardware key. A YubiKey. Passwordless. Windows Hello. Windows Hello for Business. Phone sign-in. Authenticator. They are not the same thing. To most users, they are completely indistinguishable words that IT keeps using interchangeably.

This is not a user failure. It's a communication failure. And it's one of the biggest practical barriers to passkey adoption that doesn't show up in any technical deployment guide.

The "unlock" concept is what lands. Users understand unlocking their phone. They do it dozens of times a day. Passkeys are just that same gesture applied to work logins. Once the mental model clicks, the resistance largely disappears. The job of the rollout communication isn't to explain cryptography. It's to make the new thing feel familiar before anyone is asked to use it.

The most common pushback from security-conscious admins when synced passkeys came up was "but are they really as secure as a hardware key?" It's a fair question and it deserves a straight answer: no, not quite. And that's fine, because the alternative for most users isn't a hardware key. It's Authenticator push or, worse, SMS OTP.

NIST SP 800-63B Supplement 1 validated synced passkeys as meeting AAL2 requirements. That's phishing-resistant enough for general workforce use. The private key is encrypted within the cloud provider's sync fabric. Compromising a synced passkey requires compromising both the user's cloud provider account and the device. For standard users, that's a dramatically higher bar than any legacy MFA method.

Passkeys are no longer a preview feature, a future roadmap item, or something to evaluate next quarter. They're generally available, they're being auto-rolled into tenants, and the users in your organization are about to start seeing registration prompts whether you planned for it or not.

The good news is the deployment model is cleaner than it's ever been. Synced passkeys handle the scale problem — every knowledge worker with a phone or a laptop can be phishing-resistant without a YubiKey in the mail. Device-bound passkeys handle the admin problem — the accounts that actually matter to attackers get hardware-rooted credentials. TAP handles the bootstrapping problem. Passkey profiles handle the policy separation.

The only thing left is making sure users understand that the most secure way to log in is also the easiest way to log in. That's the story worth telling.