WebAuthn passwordless authentication and the limits of IAM

At a glance

What this is: This is an explanatory guide to WebAuthn that shows how passwordless authentication works, why it reduces password-driven attacks, and where adoption still creates operational friction.

Why it matters: For IAM and NHI practitioners, WebAuthn matters because it changes how human authentication is anchored, but it also raises recovery, device lifecycle, and user-assurance questions that mirror broader identity governance problems.

By the numbers:

• WebAuthn became the official web standard for password-free logins in March 2019, with full support across Chrome, Firefox, Microsoft Edge, and Safari by that time.
• The FIDO Alliance was founded in 2012, and FIDO UAF and FIDO U2F were published by December 2014.

👉 Read StrongDM's guide to WebAuthn authentication and passwordless login

Context

WebAuthn is a passwordless authentication standard, but the governance challenge is bigger than replacing a login field. Once authentication depends on public-key cryptography, devices, browsers, and recovery processes become part of the access control model, which makes the topic relevant to IAM and NHI governance rather than just web application design.

StrongDM frames WebAuthn as a way to reduce password-based attacks while improving the user experience, but the article also shows why adoption remains inconsistent across applications and workflows. That gap is typical of modern identity rollouts, where the technical standard is available before the operating model is ready.

Key questions

Q: How should security teams implement WebAuthn without creating recovery chaos?

A: Security teams should define enrolment, replacement, and break-glass recovery before broad deployment. WebAuthn works best when the primary authenticator is paired with a verified fallback path, documented revocation rules, and support workflows that can restore access without weakening assurance. If recovery is ad hoc, passwordless access becomes harder to govern than the password model it replaces.

Q: When does passwordless authentication create more risk than it removes?

A: Passwordless authentication creates more risk when the organisation cannot manage device loss, account recovery, or user education. In that situation, users fall back to weaker exceptions or support teams improvise recovery steps, which expands the attack surface. The control is strongest when the security model, help desk process, and device lifecycle are aligned.

Q: What is the difference between WebAuthn and multi-factor authentication?

A: WebAuthn is an authentication standard that can support passwordless or multi-factor flows, while MFA is a broader policy pattern requiring two or more factors. WebAuthn provides the mechanism, such as public-key cryptography and authenticators, but MFA describes the assurance model. Organisations often use WebAuthn as part of MFA, not as a full replacement for policy decisions.

Q: Why do passwordless systems still need identity governance?

A: Passwordless systems still need identity governance because authentication strength does not answer lifecycle questions. Teams still need to decide who can enrol devices, how to revoke lost authenticators, how to prove ownership during recovery, and when fallback access is acceptable. Strong login technology without governance often produces hidden exceptions that are hard to audit.

Technical breakdown

How WebAuthn uses public-key cryptography for authentication

WebAuthn shifts authentication from shared secrets to asymmetric key pairs. During registration, the relying party asks the browser to create a credential, which binds a private key to the authenticator and stores the public key on the server. During login, the server issues a challenge, and the authenticator signs it with the private key. The server verifies the signature against the stored public key, so it never needs to handle the secret itself. That design reduces phishing and password theft risk, but it also means the authenticator, browser, and origin boundary all become security dependencies. The assurance of the flow depends on correct origin binding and sound credential lifecycle management.

Practical implication: Treat the authenticator lifecycle as part of your access model, not as a UX layer.

FIDO2, CTAP, and the authenticator layer

WebAuthn is one half of the modern passwordless stack. FIDO2 defines the broader framework, while CTAP, the Client-to-Authenticator Protocol, handles communication between the browser or operating system and an external authenticator such as a security key or mobile device. That separation matters because the browser talks to the website through WebAuthn, but it talks to the hardware through CTAP. In practice, the security properties depend on where the authenticator lives, how it is provisioned, and whether the organisation can recover access when the device is lost. This is why passwordless programs often fail at the operational edges rather than in the cryptography itself.

Practical implication: Map each authenticator type to a recovery process before broad rollout.

Why device loss and biometric trust create policy gaps

WebAuthn reduces password exposure, but it does not remove trust decisions. Device-based authentication can fail when a key is lost, stolen, or shared, and biometrics introduce privacy and recovery concerns because the user cannot simply reset a fingerprint the way they reset a password. That makes enrolment, revocation, and backup access critical policy controls. For identity teams, the hard part is no longer only verifying a login. It is deciding how much trust to assign to a device, how to re-establish identity after loss, and how to prevent a fallback path from becoming the weakest control in the stack.

Practical implication: Build fallback and recovery rules with the same rigor you apply to primary authentication.

Threat narrative

Attacker objective: The attacker aims to bypass weak authentication and obtain durable access to user accounts or connected systems.

1. Entry occurs when users remain vulnerable to phishing, brute force attacks, and keystroke logging on password-based accounts.
2. Escalation happens when attackers reuse stolen credentials across multiple systems because users often maintain many password-based accounts.
3. Impact is unauthorized access to web applications, networks, or servers when certificate or device private keys are exposed or misused.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

WebAuthn is best understood as an authentication control, not an identity governance program. The standard improves how a user proves possession or presence, but it does not solve lifecycle questions such as enrolment, revocation, recovery, and exception handling. That distinction matters because identity teams often mistake a stronger login for a complete control plane. Practitioners should treat WebAuthn as one control in a broader IAM operating model.

Passwordless authentication shifts risk from memorised secrets to device trust. That is a meaningful trade-off, but it is not automatically a lower-risk state. If the organisation cannot manage lost authenticators, secondary recovery paths, and enrolment assurance, it simply moves the weak point from passwords to fallback procedures. Practitioners should evaluate WebAuthn alongside device governance and support readiness.

Consistent user journeys are part of security, not a convenience extra. The article shows that WebAuthn can look different across browsers, operating systems, and applications, which creates training and support overhead. In identity programs, inconsistency drives bypass behaviour, and bypass behaviour erodes security. Practitioners should design for explainable, repeatable authentication flows.

WebAuthn does not eliminate the need for multi-layer access decisions. The strongest deployments still need policy around origin validation, attestation, fallback MFA, and recovery workflows. That makes it a good fit for modern phishing-resistant authentication, but only when teams align it with Zero Trust assumptions and lifecycle governance. Practitioners should plan for policy depth, not just cryptographic strength.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity governance starts from an incomplete inventory.
• For a broader governance baseline, review Ultimate Guide to NHIs , Key Challenges and Risks and compare those controls to your passwordless rollout.

What this signals

WebAuthn adoption will force IAM teams to tighten the operational boundary between authentication and recovery. If the login step becomes stronger but the exception path remains informal, the organisation has only moved risk into support processes. Teams should assume that passwordless adoption increases the importance of documented recovery approvals, device replacement rules, and help desk assurance.

The broader signal is that identity programmes are shifting from secret-centric controls toward trust decisions about devices, origins, and user journeys. That means security teams should review where fallback MFA, attestation checks, and enrolment proofing belong in policy, not only in application code.

For practitioners

• Map where WebAuthn fits in your authentication stack Decide whether it will serve as a primary authenticator, an additional factor, or a recovery method, then document which user populations and applications use each pattern. This avoids inconsistent rollout decisions that create support confusion.
• Design fallback and recovery processes before rollout Define what happens when a user loses a device, changes phones, or cannot use biometrics, and make sure recovery requires assurance strong enough to resist social engineering. The fallback path should not be easier to abuse than the password flow it replaces.
• Standardise enrolment and revocation procedures Create step-by-step rules for issuing, replacing, and retiring authenticators so that teams can reliably revoke lost or compromised devices. A passwordless program without revocation discipline simply replaces one credential problem with another.
• Train users on device handling and verification cues Provide short guidance on how to recognise legitimate prompts, how to recover access safely, and what to do if an authenticator is missing. User understanding is part of phishing resistance because confused users are more likely to accept unsafe prompts.

Key takeaways

• WebAuthn improves authentication strength, but it does not replace lifecycle governance for enrolment, revocation, and recovery.
• The main implementation risk is not the cryptography itself, but the operational gap between primary login and fallback access.
• IAM teams should treat passwordless adoption as a policy and support change, not only a technical integration project.

Key terms

• WebAuthn: WebAuthn is a web authentication standard that lets browsers and applications verify users with public-key cryptography instead of passwords. It supports passwordless and multi-factor flows by binding a private key to an authenticator and a public key to the server-side identity record.
• Relying Party: A relying party is the application or service that asks a browser to create or verify a credential during WebAuthn flows. It receives the public key, issues login challenges, and checks the returned signature to confirm that the authenticator matches the registered user.
• Authenticator: An authenticator is the device or built-in capability that proves a user’s presence or possession during a WebAuthn transaction. It may be a security key, phone, or biometric-capable device, and its lifecycle becomes part of the access-control model once it is trusted for login.
• Phishing-Resistant Authentication: Phishing-resistant authentication is a login method that is designed to stop credential capture by binding authentication to the legitimate origin and a cryptographic proof. It reduces the value of stolen secrets, but it still requires policy for enrolment, recovery, and exception handling.

Deepen your knowledge

WebAuthn, phishing-resistant authentication, and identity recovery are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a passwordless programme alongside broader IAM governance, it is worth exploring.

This post draws on content published by StrongDM: What is WebAuthn? Web Authentication Explained. Read the original.