- A passkey is a FIDO2 credential. The private key lives on the device and never leaves it. The server stores only the public key, so a breach at the server exposes nothing an attacker can use.
- FIDO2 eliminates phishing by binding the cryptographic challenge to the registered origin domain. A lookalike phishing site gets a different origin and receives no valid signature, regardless of how convincing it looks.
- NIST SP 800-63B-4 classifies FIDO2 as phishing-resistant. TOTP and push notifications are not, because both involve transmitted values a proxy can relay in real time.
- Microsoft, Apple, and Google all support passkeys natively. Microsoft moved consumer accounts to passkey-first in May 2026, deprecating SMS OTP as the default.
- Enterprise rollout requires mapping legacy application authentication, planning for shared workstations, and designing a tested recovery workflow before disabling password fallback for any user group.
- Enforcement in Microsoft Entra ID uses Authentication Strength policies inside Conditional Access. Temporary Access Pass provides a controlled recovery path that does not reintroduce passwords.
What a passkey is
A passkey is a FIDO2 credential. At registration, the device generates two cryptographic keys: the private key stays on the device, inside a TPM chip, Secure Enclave, or roaming hardware authenticator, and the public key is sent to the server. At login, the server issues a challenge. The device signs it with the private key. The server verifies the signature with the stored public key. The private key never leaves the device and the server never stores a secret that can be breached.
Device-bound passkeys are tied to a specific piece of hardware: Windows Hello for Business uses the TPM on a managed PC, Face ID and Touch ID use Apple's Secure Enclave, and hardware security keys such as the YubiKey generate and store the key internally with no extraction path. Synced passkeys replicate across your devices via an end-to-end encrypted cloud service such as iCloud Keychain, Google Password Manager, or 1Password. Both types use FIDO2. Synced passkeys trade a marginal amount of assurance for cross-device convenience; device-bound passkeys offer stronger isolation but require more deliberate recovery planning when a device is lost.
The server stores only a public key. Stealing it gives an attacker nothing usable.
Why passwords keep failing
Passwords are a shared secret: both the user and the server know it, which means it can be extracted from either side. Phishing steals it from the user. Database breaches steal it from the server. Keyloggers steal it from the device. Adversary-in-the-middle proxy attacks steal it mid-session while the user is actively entering it into what they believe is a legitimate login page.
Multi-factor authentication narrows the gap. TOTP codes and push notifications both flow through the same proxy in an adversary-in-the-middle attack: the user completes the MFA challenge, the proxy relays it to the real service, and the attacker walks away with the authenticated session cookie. The fundamental problem is the shared-secret model, which ensures that at least one party holds a value that can be stolen, and that stolen value travels over a channel that can be intercepted.
How FIDO2 eliminates the phishing attack surface
The mechanism is origin binding. At registration, the authenticator records the Relying Party ID, which is effectively the domain of the service. At authentication, the browser includes the exact origin in the signed assertion. If the origin in the response does not match the registered Relying Party ID, the authenticator refuses to sign. A phishing proxy operating at login-microsoft-365-secure.com cannot obtain a valid assertion for login.microsoft.com. There is no value to intercept because nothing valid is produced.
Every prior authentication factor, including hardware TOTP tokens and push notifications, produces a value the user or browser sends to the server. That value can be relayed. FIDO2 produces a value that is mathematically bound to the legitimate origin, so relay is useless: the signature will not verify against the registered public key for a different domain.
NIST SP 800-63B-4 requires phishing-resistant authentication for Authenticator Assurance Level 3 (AAL3). Both CISA and the NCSC identify FIDO2 and PIV smart cards as the only forms of authentication that qualify. TOTP and push notifications, regardless of implementation, are classified as phishing-susceptible because they involve transmitted values a proxy can relay in real time.
FIDO2 protects the login. It does not protect the session token once issued. A compromised device can still have its session token extracted after a legitimate authentication. Device compliance policies enforced through Conditional Access and Continuous Access Evaluation in Microsoft Entra ID handle session-layer risk separately from the authentication itself.
Passkeys in practice: Microsoft, Google, and Apple
Microsoft
Windows Hello for Business uses TPM-backed device-bound passkeys enrolled per machine. The private key is generated inside the TPM at enrolment and cannot be exported. Microsoft Authenticator now supports passkeys for both consumer and work accounts, providing a software-based FIDO2 authenticator for users who do not have a hardware key. In May 2026, Microsoft moved all consumer Microsoft accounts to passkey-first authentication, deprecating SMS OTP as the default login method. Enterprise deployments control which FIDO2 methods are permitted via Authentication Methods policies in Microsoft Entra ID, and enforcement is applied through Conditional Access Authentication Strengths.
Apple
iCloud Keychain syncs passkeys across all Apple devices signed into the same Apple ID using end-to-end encrypted sync, meaning Apple cannot read the keys in transit or at rest on its servers. Face ID or Touch ID provides the local biometric verification step. Passkeys on Apple platforms are available from iOS 16 and macOS Ventura. Cross-platform use, such as signing in to a service on a Windows device using an iPhone passkey, is handled via a QR code and Bluetooth proximity verification: the user scans the QR code with their phone, which confirms physical proximity and then performs the FIDO2 signing locally. The credentials travel as a cryptographic signature, not as a passkey or password.
Google Password Manager syncs passkeys across Android devices and Chrome on any desktop platform, available from Android 9 onwards. Google Workspace supports FIDO2 for workforce authentication across its services. The Chrome passkey implementation handles both platform authenticators, using the device's built-in biometrics, and roaming FIDO2 authenticators connected by USB or NFC. Google's implementation supports the full WebAuthn Level 2 specification, including resident keys stored on the authenticator for usernameless login flows.
Hardware security keys
Roaming FIDO2 authenticators from manufacturers including YubiKey, Google Titan, and Feitian work across any device with USB-A, USB-C, or NFC capability. The private key is generated on the hardware at manufacture or enrolment and cannot be extracted by any software means. They are the best choice for privileged accounts, shared workstations where a user carries their own authenticator, or environments where syncing credentials across cloud services is undesirable for policy or regulatory reasons. After a configurable number of failed PIN attempts, hardware keys lock and require a reset, preventing brute-force attacks on the PIN. The YubiKey 5 series supports FIDO2, FIDO U2F, PIV, OpenPGP, and OTP in a single device, making it compatible with both modern passwordless flows and legacy systems that have not yet migrated.
Enterprise rollout: the real challenges
Legacy application compatibility
Modern browsers and all major cloud identity platforms support WebAuthn natively. The gap is on-premise applications that authenticate via RADIUS, NTLM, Kerberos password-based flows, or proprietary web authentication that predates the WebAuthn specification. These cannot consume a FIDO2 assertion directly. Map your authentication stack before beginning any rollout. Applications that federate to Entra ID or another modern identity provider via SAML or OIDC can inherit passkey authentication from the identity provider without any changes to the application itself. Applications that authenticate independently need to be upgraded, migrated to a modern identity provider, or fronted by a proxy that handles the authentication translation. Identifying this split is the first and most important step.
Shared and kiosk accounts
Passkeys are user-bound and device-bound. They are not designed to be shared, and attempting to share them defeats the security model by removing the binding between a specific person and the credential. Shared workstations need a different approach. Windows Hello for Business with shared device mode allows individual users to authenticate with their own credentials on a shared machine and have their session isolated. Hardware security keys assigned to the workstation with a PIN known to authorised users are another option, though this weakens the assurance level. For shift-based workers who rotate across devices, Temporary Access Passes provide a time-limited, controlled authentication method that bridges the gap during enrolment without reintroducing persistent passwords.
User training
The login experience changes. Users who expect a username and password field will encounter a biometric prompt, a device PIN request, or a tap on a hardware key instead. Without preparation, this confusion generates service desk calls, workarounds, and resistance that slows the rollout. Run a structured pilot with IT and security staff first, document every friction point in the enrolment and daily login flow, then extend to a broader user group with clear internal communications. Brief the service desk specifically on what the new flows look like and what the most common user errors are, before those errors start appearing in volume.
Recovery planning
NIST requires that recovery mechanisms be at least as strong as the primary authenticator. This rules out email-based recovery links for a FIDO2 deployment, since email accounts are typically far weaker than the passkey they would be used to bypass. Practical recovery options include enrolling a second device or hardware key as a backup authenticator at the time of initial enrolment, using Temporary Access Pass in Entra ID as a time-limited passwordless code for controlled recovery scenarios, or implementing a formal identity-verified re-enrolment workflow through the service desk that requires confirmation of identity before issuing any new credential. The critical constraint is this: the recovery workflow needs to be designed, documented, tested, and known to your service desk before you disable password fallback for any user group. Recovery is not a detail to address later.
Do not design recovery after rollout. Most passkey projects hit their first real problem when a user loses their only enrolled device and there is no recovery path. The identity-verified re-enrolment workflow needs to exist, be documented, be tested, and be known to your service desk before you disable password fallback for any user group.
Conditional Access and passkey enforcement in Microsoft Entra ID
Entra ID Authentication Strengths, available since late 2023, allow you to specify which authentication methods are acceptable as a condition inside a Conditional Access policy. Creating a custom Authentication Strength that permits only FIDO2 security keys or Windows Hello for Business creates an enforceable requirement: users who cannot satisfy it with a qualifying authenticator are blocked entirely, not stepped down to a weaker form of authentication. This is the mechanism that converts a capability into a mandate.
To configure this: navigate to Security, then Authentication Methods, then Authentication Strengths, and create a new custom strength. Enable FIDO2 security keys and Windows Hello for Business as the permitted methods. Assign this strength as a requirement in a Conditional Access policy scoped to privileged roles, administrative portals, or your highest-sensitivity applications. For organisation-wide rollout, phase by application risk tier rather than rolling out universally on day one.
Temporary Access Pass (TAP) provides a time-limited, single-use or multi-use passwordless PIN for users who need to enrol a new passkey or recover from a lost device. Set validity to hours, not days, and require a second verification step before issuing one. Disable the pass after use. TAP is the controlled bridge that replaces the informal and insecure practice of temporarily disabling MFA requirements for affected users.
For privileged accounts managed via Privileged Identity Management (PIM): require passkey authentication as a condition of role activation. This ensures that even if an attacker holds a valid session token for the user's standard account, they cannot escalate to administrative access without presenting a physical passkey. The combination of PIM-scoped activation and a passkey requirement removes the most damaging escalation path from most credential compromise scenarios.
Five steps to start this quarter
- Audit your authentication stack: identify which applications support WebAuthn natively, which federate to your identity provider via SAML or OIDC, and which rely on legacy protocols such as RADIUS or NTLM. The federated and native applications can be covered in the initial rollout phase. Legacy applications need a separate remediation plan and should not block the rollout for everything else.
- Enable FIDO2 in your identity provider: in Entra ID, navigate to Security, Authentication Methods, and enable FIDO2 security keys and passkeys in Microsoft Authenticator. This unlocks the capability without mandating it for any user. No one's login flow changes until you create an Authentication Strength policy that requires it.
- Pilot with IT and security staff: enrol ten to twenty people using hardware security keys or platform passkeys. Run them through the full login experience, the recovery flow, and a simulated device-loss scenario. Document every friction point before scaling. The goal is to find the edge cases when the impact is limited to a small group of technically capable users.
- Build and test your recovery workflow: define the Temporary Access Pass process or identity-verified re-enrolment procedure. Brief the service desk on what it looks like from their side. Test it with a real recovery scenario involving a pilot user before any broader group has passwords disabled. Recovery that exists only in a document is not recovery.
- Set enforcement by application risk tier: use Authentication Strength policies inside Conditional Access to require phishing-resistant authentication on administrative portals, finance applications, and email first. Expand progressively as confidence in the recovery workflow grows and user training reaches each group. Do not attempt a universal cutover on the first enforcement date.
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years, including senior roles at Microsoft, ING, IPsoft, PPHE and more. View full profile