WebAuthn and passkeys expose the real identity lifecycle gap

At a glance

What this is: This is a practical guide to WebAuthn and passkeys that shows passwordless login is easy to describe but harder to operate at scale because recovery, lifecycle, and browser compatibility issues can break adoption.

Why it matters: It matters to IAM and identity teams because passkeys change authentication design, but they also create governance work around enrolment, fallback, device loss, and credential lifecycle that affects human identity programmes and adjacent NHI controls.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Ory's guide to WebAuthn and passkeys for passwordless login

Context

WebAuthn and passkeys replace shared secrets with public-key authentication, which removes password reuse and phishing-prone credential handling from the login flow. For identity programmes, the harder problem is not the cryptography itself but the operating model around enrolment, recovery, device trust, and lifecycle management.

That matters because passwordless rollouts rarely fail on protocol support alone. They fail when teams cannot keep login stable across browsers, devices, domains, fallback flows, and account recovery paths, especially in hybrid environments where passwords and passkeys coexist.

For IAM teams, the relevant question is whether authentication can be simplified without creating a new class of support, governance, and offboarding problems. That is a human identity challenge first, but the lifecycle lessons are also relevant to other identity types that rely on durable credentials.

Key questions

Q: How should security teams adopt passkeys for infrastructure access?

A: Start with the highest-risk interactive accounts, especially administrators who are exposed to phishing and push fatigue. Then tie enrolment to device trust, define recovery requirements, and keep terminal and break-glass workflows under separate policy. Passkeys improve authentication strength, but they only reduce risk when the surrounding identity process is controlled end to end.

Q: When do passkeys create more operational risk than they reduce?

A: They create more risk when teams deploy them before defining device loss recovery, origin stability, and cross-platform testing. In that state, passwordless login can increase lockouts, support calls, and exception handling even if the cryptography is sound.

Q: What do IAM teams get wrong about passwordless authentication?

A: Teams often assume passwordless means identity has been solved, when it usually means one class of credential risk has been reduced. Without verified identity binding, liveness, and controlled recovery, passwordless can still admit spoofed or fraudulently enrolled accounts. The right question is whether the access decision is tied to a verified identity claim.

Q: How do organisations know whether passkey adoption is actually reducing risk?

A: Track the share of accounts that are passkey-enrolled, the proportion of sign-ins still using passwords, and the number of recovery events that bypass the primary factor. If password use remains high or recovery is frequent, the programme is still in transition rather than truly passwordless.

Technical breakdown

How WebAuthn changes authentication from shared secret to challenge-response

WebAuthn uses public-key cryptography so the browser and authenticator can prove possession of a private key without sending the secret itself to the server. The relying party stores the public key and issues a challenge at login, which the authenticator signs inside a secure device or platform component. Because the credential is bound to the origin, phishing sites cannot replay it in the same way they can replay passwords. The protocol is strong, but its security depends on correct origin handling, platform support, and registration lifecycle.

Practical implication: treat origin and relying-party configuration as authentication-critical controls, not implementation details.

Passkeys and browser UX: discoverability, conditional UI, and device sync

Passkeys are the user-facing layer built on WebAuthn, usually adding discoverable credentials and cross-device convenience through OS or cloud sync. That improves usability, but it also changes how login is initiated because the browser may surface passkeys differently across devices and platforms. Some flows rely on conditional UI, some on QR-based cross-device approval, and some on platform-specific credential stores. Teams that assume all passkeys behave the same end up with inconsistent login journeys and avoidable support load.

Practical implication: test the login journey across browsers, operating systems, and device combinations before broad rollout.

Lifecycle management for passkeys and fallback authentication

Passkey adoption creates a lifecycle problem that looks familiar to IAM teams but behaves differently in practice. Credentials can become unusable when devices are lost, accounts are replaced, domains change, or old authenticators linger after they should have been removed. If organisations add passkeys without a defined fallback path, recovery process, and audit trail, they simply move the failure point from password reset to credential rescue. In regulated environments, that can also collide with onboarding and identity proofing requirements.

Practical implication: define enrolment, recovery, and retirement workflows before you disable legacy authentication.

NHI Mgmt Group analysis

Passwordless login solves secret exposure, but not identity governance. WebAuthn removes reusable passwords from the primary authentication path, yet the control problem shifts to enrolment, recovery, and trust in the device ecosystem. That means the security gain is real, but only if the identity programme can govern the whole credential lifecycle, not just the sign-in ceremony. For practitioners, passwordless is an operating model change, not a front-end feature.

Passkeys introduce a lifecycle discipline that most identity teams still under-model. The article correctly points to device loss, credential removal, and domain changes as failure points. Those are not edge cases, they are the places where durable credentials turn into support incidents, lockouts, or orphaned authentication state. The useful concept here is passkey lifecycle drift: credentials remain conceptually valid while their operational context has changed. Practitioners need to treat that drift as a governance signal, not a UX nuisance.

Hybrid authentication is where passwordless programmes usually become messy. Enterprises rarely switch off passwords on day one, so they run passkeys alongside OTP, SSO, and older recovery paths. That creates duplicated assurance logic, overlapping fallback decisions, and inconsistent user journeys across applications. The implication is that authentication architecture, access policy, and user support have to be planned together, or the passwordless programme simply adds another layer of exception handling.

WebAuthn is human IAM today, but the governance pattern is broader than humans. The same discipline of credential issuance, bounded use, recovery, and retirement applies across identity types, including service accounts and machine credentials. The lesson is not that passkeys are NHI technology, but that identity governance remains lifecycle governance, regardless of actor type. For practitioners, this is a reminder that durable credentials always create operational debt if ownership and retirement are unclear.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, which increases exposure paths and makes retirement harder to govern.
• Passkey programmes should be read alongside the Guide to the Secret Sprawl Challenge because lifecycle drift, not just authentication strength, drives operational risk.

What this signals

Passkey adoption will expose whether your identity programme can manage state, not just login UX. Organisations that cannot track credential enrolment, fallback use, and retirement will see passwordless become another exception-handling layer. The practical question is whether your programme can govern authentication changes across the full lifecycle, not whether the browser supports the standard.

Identity teams should expect recovery and retirement to become the real control points. Once passwords are reduced, the weak links move to device replacement, support escalation, and stale registrations. That is why passkey maturity should be measured by recovery success and orphan cleanup, not by enrolment counts alone.

Passkey lifecycle drift: credentials stay valid in the system after their real-world context has changed, which creates hidden operational debt. Teams that pair passwordless with disciplined lifecycle review will absorb change more safely than teams that treat it as a one-time authentication upgrade.

For practitioners

• Define recovery before rollout Map how users regain access when a device is lost, replaced, or wiped, and test that path against real support and proofing requirements. Do not let passwordless adoption outpace account rescue design.
• Stabilise relying-party and origin strategy Review domain, subdomain, and CNAME plans before enabling passkeys so existing credentials do not break when the application footprint changes. Treat RP ID stability as part of authentication architecture.
• Run cross-platform login testing Validate passkey flows on Chrome, Firefox, Edge, Safari, iOS, Android, Windows, and macOS, including cross-device approvals and browser-specific fallbacks. Record which combinations need alternate journeys.
• Keep fallback authentication governed Maintain a controlled backup path such as OTP or password recovery until passkey coverage, enrolment success, and support readiness are proven. Remove fallback only when the recovery path is operationally mature.
• Track lifecycle exceptions and orphaned credentials Monitor failed logins, deleted authenticators, and stale registrations so you can remove credentials that no longer match a valid device or user state. Build retirement into routine identity administration.

Key takeaways

• WebAuthn removes shared secrets from login, but the governance burden shifts to recovery, fallback, and credential retirement.
• Passkey rollouts fail most often at the edges of device diversity, domain stability, and hybrid authentication design.
• IAM teams should measure passwordless success by operational resilience, not by the number of users enrolled.

Key terms

• 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.
• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Relying Party: A relying party is the application or service that consumes an authentication assertion or token and grants access based on the identity proof it receives. In federation designs, its configuration quality directly affects whether trust decisions remain consistent and secure.
• Passkey Lifecycle: The full set of states a passkey passes through from registration to revocation. It includes enrolment, device binding, synchronisation, backup, recovery, replacement, and deletion, and each state creates a different control requirement for identity teams.

What's in the full article

Ory's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on configuring WebAuthn and passkeys in Ory Network or a self-hosted deployment.
• Implementation notes on fallback flows, recovery paths, and user onboarding for mixed authentication environments.
• Practical considerations for RP ID stability, cross-device testing, and browser-specific behaviour.
• References to Ory documentation for passkey setup and developer integration details.

👉 Ory's full post covers implementation details, fallback design, and lifecycle considerations for passkey rollout.

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.