Passkeys, explained: what they are and how to roll them out

What is a passkey?

A passkey is a modern replacement for a password, based on the FIDO2 and WebAuthn standards. When you create one, your device generates a pair of keys. The public key is stored by the website or identity provider. The private key never leaves your device or password manager, and it's unlocked with something you already use: your fingerprint, your face or your device PIN.

When you sign in, the site sends a one-time challenge. Your device signs it with the private key, and the site checks that signature with the public key it holds. If it matches, you're in.

For the person signing in, it feels like unlocking their phone. There's no code to copy and nothing to remember.

How is that different from a password and MFA?

A password is a shared secret: you know it, the website knows it, and anyone who tricks you into typing it knows it too. Adding a text or app code helps, but the user can still be fooled into entering both on a convincing fake page.

A passkey removes both weaknesses. There's no shared secret for a website to leak, because the site only ever holds the public key. And each passkey is tied to the exact web address it was created for. A look-alike site simply can't ask for it, so even a user who's completely fooled can't hand it over. That's what makes passkeys phishing-resistant rather than just "stronger".

Synced or device-bound: which kind do you need?

There are two kinds of passkey, and the difference matters for organisations.

Synced passkeys are a big improvement for most staff and a natural fit for customer-facing services. For administrators and other high-risk roles, device-bound passkeys on security keys or managed devices give you tighter control over exactly where the credential lives.

What if someone loses their phone?

A lost device doesn't expose the passkey on its own: whoever finds it still needs to get past the device's own lock screen. The practical steps are to revoke that device's passkey in the identity provider, then help the person register a new one.

That second step is where most rollouts are weakest. If your helpdesk will reset someone's sign-in after a quick phone call, attackers will simply call the helpdesk instead of phishing the user. Several well-known breaches started exactly that way. Before rolling out passkeys, decide how you'll verify someone's identity during recovery, for example with a video call and photo ID check, a manager's approval, or a temporary access pass issued through a verified channel.

Do Okta and Microsoft Entra ID support passkeys?

Yes. Both support FIDO2 security keys and passkeys, and both let you require phishing-resistant sign-in through policy: authentication policies in Okta, and Conditional Access authentication strengths in Entra ID. Each also has its own phishing-resistant option alongside passkeys, Okta FastPass and Windows Hello for Business, which many organisations use as their main method on managed devices.

The exact options available depend on your licences and platform versions, so check your tenant's current settings before you plan the rollout.

How should an organisation roll them out?

A big-bang switch rarely works. A phased rollout, strongest protection first, does.

1. Protect administrators first. They're the most valuable target, and usually the most comfortable with new technology. Require phishing-resistant sign-in for every admin role.
2. Extend to high-risk groups. Finance, HR, executives and anyone who approves payments or handles sensitive data.
3. Run a registration campaign for everyone. Prompt people to enrol at sign-in, with a short guide and a clear deadline. Let them keep their current method while they switch.
4. Retire the weaker methods. Once enrolment is high, remove SMS and, where possible, other phishable factors. Until you do, attackers can still target the weakest method left on an account.

Common pitfalls to plan for

• Recovery that's easier than sign-in. Your process for lost devices must be at least as strong as the passkey itself.
• Leaving old factors in place. A passkey doesn't help if SMS is still allowed as a fallback on the same account.
• Shared and frontline devices. Kiosks and shared workstations may need security keys rather than phone-based passkeys.
• Apps outside the identity provider. Systems with their own local passwords won't benefit until they're connected through SSO.