Passwordless authentication and FIDO2 keys are changing IAM controls

At a glance

What this is: This is an explanation of how FIDO2 security keys enable passwordless authentication and why they reduce phishing, reuse, and interception risk by keeping private keys on the device.

Why it matters: It matters because IAM teams need to decide when passwordless authentication can replace passwords without weakening recovery, device assurance, or access governance.

By the numbers:

• 74% of consumers are now familiar with passkeys, according to Frontegg.
• More than 35% of people experienced account compromises due to password vulnerabilities in the previous year, according to Frontegg.

Context

Passwordless authentication replaces shared secrets with device-bound cryptographic credentials. In this model, the authenticator proves possession of a private key without exposing that key to the service, which changes the control surface for IAM and access governance.

For identity teams, the shift is not simply about user convenience. It alters how organisations think about phishing resistance, recovery, device binding, and the operational assumptions behind multi-factor authentication and single sign-on.

Frontegg positions FIDO2 keys as a practical path away from password-centric authentication. That framing is typical of the market direction, but the governance implications reach further than login UX.

Key questions

Q: What breaks when passwords are replaced with FIDO2 security keys?

A: The main break is the shared-secret model. Passwords can be phished, reused, reset, or copied from databases, while FIDO2 signs a service-specific challenge with a private key that stays on the device. That removes a major credential theft path, but it also means recovery, enrollment, and device custody become the real governance controls.

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: How should IAM teams decide between platform and roaming authenticators?

A: Use platform authenticators for tightly controlled, single-device workflows and roaming authenticators when users move between devices, travel, or share workstations. The decision should follow the account's assurance requirement, recovery model, and physical custody needs, not just user convenience.

Q: When should organisations require PIN or biometric verification with a security key?

A: Require PIN or biometric verification for accounts where physical theft would create unacceptable risk, especially administrative or sensitive business systems. A tap-only key is still stronger than a password, but local verification adds another layer that limits misuse if the device is lost or borrowed.

Technical breakdown

How FIDO2 security keys use public-key authentication

FIDO2 security keys work by creating a unique key pair at registration. The private key stays on the authenticator or device, while the public key is stored by the service. On login, the service sends a challenge and the key signs it locally, then the service verifies the signature. WebAuthn provides the browser interface and CTAP2 links external authenticators to the client device. Because the private key never leaves the device, attackers cannot replay it, intercept it in transit, or copy it from a password database. That design removes the shared-secret model that passwords depend on and narrows the attack surface to device possession and local user verification.

Practical implication: treat passwordless rollout as an authentication architecture change, not a cosmetic login update.

Why phishing resistance depends on device-bound credentials

Phishing succeeds when an attacker can trick a user into surrendering a reusable secret. FIDO2 breaks that pattern because the credential is not typed, transmitted, or reusable across sites. Each relying party gets its own key pair, so a captured response from one service does not authenticate anywhere else. This also weakens man-in-the-middle attacks, because the authenticator signs a server-specific challenge rather than a generic credential. The control is therefore strongest when the authenticator is bound to the device and local presence is verified with a tap, PIN, or biometric. If those local checks are optional, the credential remains resistant to remote theft but less resilient to physical misuse.

Practical implication: require user verification for higher-risk accounts, not touch-only authentication.

How roaming authenticators and platform authenticators differ in governance

Platform authenticators are built into a single device, such as a laptop or phone, while roaming authenticators are portable security keys that can move across devices. That difference matters for governance because the recovery model, inventory model, and support model change. Platform authenticators improve convenience but tie authentication to one endpoint. Roaming keys support shared workstations, travel, and higher-assurance environments, but they require key issuance, backup registration, and physical custody controls. The article also notes that synced passkeys may suit lower-assurance use cases, while device-bound keys are preferable for high-risk systems. The governance decision is not which format is modern, but which binding model matches the account's risk.

Practical implication: classify accounts by assurance need before selecting platform, roaming, or synced passkeys.

Threat narrative

Attacker objective: The attacker wants reusable authentication material that can be replayed, reused, or sold for account takeover.

1. Entry occurs when an attacker tries to harvest reusable login secrets through phishing or interception, but FIDO2 removes the shared secret from the path.
2. Escalation is blocked because the authenticator signs a service-specific challenge rather than exposing a password or reusable token that can be replayed elsewhere.
3. Impact is reduced because a compromised site database or intercepted login flow does not yield credentials that work beyond the original relying party.

Breaches seen in the wild

• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

FIDO2 shifts IAM away from shared-secret governance: Passwordless authentication is not just another login option, it is a different trust model. Once the private key never leaves the authenticator, phishing and database replay stop being the main control problem and identity assurance moves to device custody and local verification. For IAM teams, the practical implication is that authentication policy must be designed around cryptographic possession, not secret memorisation.

Recovery becomes the hidden governance problem: Most passwordless discussions focus on the front-door login flow, but the harder question is how users recover when a key is lost, damaged, or unavailable. Multiple enrolled keys, physical custody, and admin-controlled recovery are not convenience features, they are the controls that prevent passwordless deployment from collapsing back into weaker fallback methods. That is where the programme either stays resilient or reintroduces risk through the side door.

Phishing resistance only matters if the assurance model is explicit: FIDO2 keys can reduce one of the most common credential theft paths, but assurance is not uniform across every use case. Device-bound keys, synced passkeys, platform authenticators, and local verification options represent different governance choices, not interchangeable implementations. Teams should classify which accounts need strong device binding and which can tolerate lighter assurance without weakening the identity model.

Phishing-resistant authentication should be treated as access governance, not just security tooling: When an organisation removes passwords, it also removes a category of help desk work, reset workflow, and credential exposure. That changes how access is provisioned, supported, and audited across human identity programmes. The strongest programmes will align authentication strength with account criticality instead of rolling out passwordless as a universal UX upgrade.

FIDO2 creates a cleaner boundary between login proof and account recovery: The key insight is that authentication can become materially stronger while recovery remains the weakest part of the journey. That gap is where governance, not protocol design, determines whether passwordless genuinely reduces risk or merely shifts it. Practitioners should therefore evaluate passwordless deployments as end-to-end identity workflows, not isolated credential events.

What this signals

Passwordless authentication changes the control point: The key governance shift is that authentication assurance moves from secret protection to device-bound proof and local verification. That means policy has to distinguish between merely supporting passkeys and actually reducing account takeover risk.

Recovery and custody are now first-class identity controls: Once passwords leave the model, organisations have to govern backup keys, lost-device procedures, and account recovery with the same seriousness they once gave to password resets. Without that, passwordless simply relocates risk instead of reducing it.

For practitioners

• Define where passwordless is mandatory Map high-risk accounts, such as admin profiles and production access, to device-bound FIDO2 keys and require local user verification for those accounts.
• Register backup keys at enrolment Require at least two enrolled keys for each account so users can recover access without falling back to weaker reset channels or shared support workflows.
• Set custody rules for roaming keys Store spare keys in controlled locations, track assigned users and serial numbers, and revoke lost or stolen keys through a written recovery process.
• Test compatibility before rollout Validate browser, OS, and application support before broad deployment so legacy systems do not force unmanaged fallback authentication.
• Separate assurance levels by account type Allow lower-risk accounts to use lighter passkey options only when the risk profile and recovery path are explicitly documented.

Key takeaways

• FIDO2 security keys reduce credential theft by replacing passwords with device-bound cryptographic authentication.
• The real governance challenge is not login convenience, but recovery, custody, and assurance level selection.
• Passwordless programmes work best when high-risk accounts get stronger device binding and explicit local verification.

Key terms

• FIDO2 Security Key: A physical authenticator that uses public-key cryptography to prove a user’s identity without sending a password. The private key stays on the device, and the service verifies a signed challenge with the matching public key, which makes phishing and replay attacks far less effective.
• WebAuthn: WebAuthn is a browser and platform standard for phishing-resistant authentication using public-key cryptography. It binds the authenticator to the origin and signs a challenge instead of sending a reusable code, which makes replay and relay attacks far harder.
• CTAP2: A protocol that lets an external authenticator, such as a security key, communicate with a client device. It carries the commands used for registration and login so the browser can work with hardware keys across devices and operating systems.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.