FIDO2 and passwordless authentication: what IAM teams need to know

At a glance

What this is: FIDO2 is an open passwordless authentication standard that uses public-key cryptography to verify users without exposing a reusable secret.

Why it matters: It matters because IAM teams can reduce phishing and password-reset exposure, but they still need to manage proofing, recovery, and access decisions around the new ceremony.

👉 Read Scramble ID's full explanation of FIDO2 and passwordless authentication

Context

FIDO2 is a passwordless authentication standard, not an authorization model. It changes how a user proves possession of a credential, but it does not decide what that user or device can do once access is granted.

For IAM teams, the governance question is whether replacing shared secrets with hardware-bound keys actually removes the programme risk or simply moves it into registration, recovery, and lifecycle control. That distinction matters for human identity programmes first, then for any future machine or agent identity patterns that borrow the same cryptographic approach.

The core security gain is origin-bound authentication. A phishing site cannot mint a valid assertion for the real relying party because the browser and authenticator bind the challenge to the legitimate origin.

Key questions

Q: How should organisations roll out FIDO2 without breaking recovery and support?

A: Start with high-risk populations, then design recovery before broad enforcement. Require strong proofing for new registration, keep a tightly controlled fallback path for exceptional cases, and test help desk workflows for lost devices, browser incompatibilities, and account re-binding. The goal is to remove passwords without creating a weaker recovery channel that attackers can target.

Q: Why do FIDO2 and passkeys reduce phishing risk more effectively than OTP codes?

A: FIDO2 binds the authentication response to the relying-party origin, so a lookalike site cannot reuse the assertion. OTP codes can be relayed in real time and are still shared secrets at the moment of use. Passkeys keep the cryptographic benefit while improving usability, but they still depend on sound enrollment and recovery controls.

Q: What should IAM teams monitor when passkeys become the default login method?

A: Watch for anomalous registration events, unexpected recovery requests, and sudden changes in platform-account ownership. Those signals indicate that the attack surface has moved from password theft to lifecycle abuse. If the organisation cannot see who enrolled which authenticator and when, governance is incomplete.

Q: What is the difference between authentication assurance and authorization in FIDO2 deployments?

A: Authentication assurance answers whether the user proved possession of a trusted authenticator. Authorization answers what that authenticated user can do afterward. FIDO2 strengthens the first problem only, so teams still need RBAC, ABAC, scoped tokens, and privilege review to control downstream access.

Technical breakdown

WebAuthn origin binding and browser mediation

WebAuthn is the browser-side API in FIDO2. The relying party calls navigator.credentials.create() for registration or navigator.credentials.get() for authentication, and the browser validates the origin before constructing a challenge. That challenge is signed by the authenticator, which means the resulting assertion is bound to the legitimate relying-party origin rather than to a reusable secret that a phishing site can replay. The browser is not just a transport layer here. It is the control point that prevents scripts from one origin from producing credentials for another.

Practical implication: verify that your web apps use modern browser-mediated flows and do not backslide to password or OTP fallbacks that reintroduce phishing exposure.

CTAP and hardware-protected authenticators

CTAP is the client-to-authenticator protocol used with external authenticators such as security keys. It defines how the client requests credential creation or authentication, how user verification occurs with a PIN or biometric, and how the signed assertion returns to the relying party. Platform authenticators use OS-level APIs rather than CTAP directly, but they still rely on the same hardware-protected key store. The important architectural point is that the private key never leaves the authenticator, which eliminates shared-secret replication across systems.

Practical implication: inventory which authenticators your users actually have, and make sure your policy distinguishes between device-bound recovery paths and roaming-key portability.

Passkeys, discoverable credentials, and recovery boundaries

Passkeys are discoverable FIDO2 credentials, often synced across devices. They make login simpler because the authenticator can locate the credential without the relying party providing a credential ID first. That convenience also changes governance. Sync can improve resilience, but it creates a new dependency on the platform account and its recovery process. FIDO2 solves authentication, not identity proofing or account recovery, so the surrounding control plane still matters. If registration or recovery is weak, passwordless deployment can still be abused at the account lifecycle boundary.

Practical implication: treat passkey rollout as a lifecycle programme, not a pure authentication upgrade, and review recovery, enrollment, and step-up policy together.

NHI Mgmt Group analysis

FIDO2 is a control redesign, not just a stronger login method. The standard removes reusable shared secrets from the primary authentication ceremony, which is why it materially changes phishing economics. But it does not remove the need for identity proofing, account recovery, or authorization policy. That means IAM teams must separate authentication assurance from lifecycle governance instead of treating them as one problem.

Passkeys shift the risk from password theft to enrollment and recovery governance. Once discoverable credentials are synced across devices, the main questions move to who can enroll, who can recover, and what conditions trigger re-binding. That makes the control surface closer to identity lifecycle management than to classic password hardening. Practitioners should treat passkey adoption as a governance programme with operational exceptions, not as a checkbox rollout.

Origin binding is the real phishing-resistant property, and that is why browser mediation matters. The FIDO2 ceremony works because the browser refuses to misrepresent origin and the authenticator signs a challenge tied to that origin. That assumption is what breaks phishing replay. The practical conclusion is that relying parties need to preserve the full browser-to-authenticator path, not shortcut it with weaker compatibility layers.

FIDO2 is the strongest example of why shared-secret thinking is failing in identity security. The model assumes credentials can be copied, replayed, or stored centrally. FIDO2 rejects that premise by making the private key non-exportable and verification origin-bound. For identity programmes, the broader lesson is that any process still built around secret reuse is carrying avoidable blast radius.

Credential portability must not be confused with credential governance. Synced passkeys reduce friction, but portability can obscure where accountability sits when a device is lost, a platform account is compromised, or a user changes devices. The implication for practitioners is to define device recovery, registration trust, and revocation boundaries before broad rollout, not after users depend on them.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• From our research: Read 52 NHI Breaches Analysis to see how credential exposure turns into real-world compromise patterns across identity programmes.

What this signals

Passkey adoption changes the centre of gravity for identity teams. The hard problem is no longer secret storage, it is ceremony design. Registration, recovery, and device replacement become the places where trust is granted or lost, so IAM teams should review those flows with the same discipline they once applied to password resets and privileged account recovery.

A useful concept here is recovery-path risk: the weaker the alternate path, the less benefit passwordless authentication delivers in practice. Organisations that keep broad fallback options for convenience often preserve the very takeover routes they meant to remove.

For mature programmes, the next step is to align authentication policy with zero-trust access decisions and lifecycle review. FIDO2 can strengthen the front door, but it does not replace access governance, and the combination of strong authentication plus weak entitlement control still leaves excessive reach in the environment.

For practitioners

• Map fallback paths that reintroduce shared secrets Audit every application that supports FIDO2 and identify whether password, SMS OTP, or email recovery still exists as an alternate path. Those paths often become the real attack surface after passkey rollout, so remove or heavily constrain them where business risk allows.
• Define enrollment and recovery trust boundaries Require step-up verification for new authenticator registration, lost-device recovery, and platform-account changes. The weakest point in passwordless programmes is often the recovery ceremony, not the authentication ceremony itself.
• Prefer phishing-resistant MFA for high-value access Use FIDO2 or equivalent phishing-resistant methods for privileged users, administrators, and sensitive internal applications first. Keep a clear exception register for legacy systems that cannot support the browser-to-authenticator flow.
• Test browser and device compatibility before enforcement Validate platform authenticators, roaming keys, and browser support across managed endpoints, remote users, and accessibility needs. A passwordless policy fails if legitimate users cannot complete the ceremony reliably.

Key takeaways

• FIDO2 removes reusable secrets from the primary login ceremony, which materially reduces phishing exposure.
• The main governance risk shifts to enrollment, recovery, and fallback paths, where weaker controls can reintroduce account takeover.
• IAM teams should treat passkeys as a lifecycle programme with policy, proofing, and revocation controls, not as a simple authentication upgrade.

Key terms

• WebAuthn: WebAuthn is the browser-side API used in FIDO2 ceremonies to create and verify public-key credentials. It lets a relying party ask the browser to generate a challenge, gather an authenticator response, and return a signed assertion that is bound to the correct web origin.
• CTAP: CTAP is the protocol used by browsers and operating systems to communicate with external authenticators such as security keys. It defines how credentials are created, how user verification happens, and how a signed assertion is returned without exposing the private key.
• Passkey: A passkey is a discoverable FIDO2 credential that can be found by the authenticator without the relying party supplying a credential ID first. In practice, passkeys improve usability and portability, but they also make enrollment and recovery part of the security model.
• Platform authenticator: A platform authenticator is built into the user’s device and uses the device’s hardware-protected key store for private-key operations. Examples include Touch ID, Face ID, Windows Hello, and Android biometric systems, all of which support phishing-resistant authentication when configured correctly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: What Is FIDO2? Read the original.