TL;DR: WebAuthn and passkeys remove shared secrets from the login path, but Ory’s guide shows the harder problems are recovery, device diversity, RP ID stability, and lifecycle handling across hybrid authentication flows. The operational shift is not just passwordless UX; it is managing identity state, fallback, and credential retirement without breaking access.
At a glance
What this is: This is a practitioner guide to WebAuthn and passkeys that finds the hard part of passwordless login is lifecycle management, not the underlying cryptography.
Why it matters: IAM teams, IGA leads and security architects need to treat passkeys as a governance change because recovery, fallback, device support and credential retirement can all disrupt access at scale.
Context
WebAuthn and passkeys are a passwordless authentication model built on public-key cryptography, where the private key stays on the device and the server stores only the public key. The article's central point is that this removes shared-secret risk, but it also shifts the operational burden into enrollment, recovery and retirement of credentials.
For identity programmes, the real issue is lifecycle governance. Passkeys may improve phishing resistance, but organisations still need to manage fallback paths, cross-device behaviour, hybrid login states and domain stability without creating lockouts or orphaned access.
The article is typical of current passwordless guidance: the cryptographic model is mature, while the operational model is still where implementations fail.
Key questions
Q: What breaks when passkeys are rolled out without strong fallback controls?
A: The recovery path becomes the easiest route into the account. If password resets, device re-binding, or support exceptions are weakly controlled, attackers will bypass the passkey itself and compromise the identity through the exception process instead of the primary login.
Q: Why do passkeys create different governance requirements from passwords?
A: Passkeys change how credentials are issued, stored and retired because the secret never lives on the server and may be synced across devices. That means identity teams must govern enrollment, device changes, fallback and offboarding with more precision than they would for a reusable password.
Q: How do you know if a passwordless rollout is actually working?
A: Look beyond go-live status and measure whether support tickets are falling, adoption is stable across user groups, and users are not bypassing the new process. If the programme still drives heavy fallback use or repeated recovery events, the operating model is not yet mature.
Q: What is the difference between passkeys and WebAuthn in modern authentication?
A: WebAuthn is the underlying web standard for cryptographic authentication, while passkeys are the user-facing implementation that replaces passwords with public-private key pairs. WebAuthn defines how browsers and apps use device-bound credentials, and passkeys package that capability into a simpler user experience with biometric or device-based verification.
Technical breakdown
How WebAuthn changes the authentication trust model
WebAuthn uses public-key cryptography instead of shared secrets. During registration, the authenticator creates a key pair, the private key remains on the user device, and the server stores the public key bound to a relying party and origin. During login, the server sends a challenge and the device signs it, which gives phishing resistance because the credential is scoped to the correct site. This is different from password authentication, where the server must compare a reusable secret and therefore inherits password reuse and leak risk.
Practical implication: treat WebAuthn as a protocol shift that changes where trust sits, not as a cosmetic login upgrade.
Why passkeys behave differently from raw WebAuthn
Passkeys are the user-facing implementation layer on top of WebAuthn. They are designed to be discoverable, often sync across devices through cloud or OS services, and support a smoother sign-in experience through conditional UI and biometric prompts. That convenience changes the identity model because the credential is no longer tied only to one device in one place. Organisations need to understand whether they are operating with resident, synced credentials or with a stricter WebAuthn registration model, because the lifecycle and recovery consequences are different.
Practical implication: decide whether your programme is governing device-bound WebAuthn credentials or syncable passkeys before you standardise flows.
Where passkey lifecycle management fails in practice
The article highlights several operational failure points: lost devices, account recovery, fallback design, RP ID or origin changes, and zombie credentials that remain on the server after the authenticator is gone. These are lifecycle problems, not cryptographic problems. If recovery is weak, users get locked out. If RP ID stability is poor, existing credentials can break after domain or subdomain changes. If old credentials are not removed cleanly, the organisation accumulates stale authentication state that still affects access decisions and support load.
Practical implication: govern passkeys with the same discipline used for identity lifecycle events, including offboarding, recovery and credential retirement.
NHI Mgmt Group analysis
WebAuthn reduces shared-secret exposure, but it does not remove lifecycle governance. The article makes clear that the protocol solves password and replay problems by binding authentication to public-key credentials. That shifts the identity burden into issuance, recovery, retirement and fallback, which are governance functions rather than cryptographic ones. The practical conclusion is that passwordless success depends on lifecycle control, not only on adoption of the protocol.
Passkeys create a cross-device identity state that many IAM programmes are not designed to model. A synced credential can exist across phones, laptops and browser ecosystems, which means identity state is no longer a simple device-to-account mapping. This complicates support, revocation and assurance because the organisation has to understand where the credential lives, how it propagates and when it is no longer valid. Practitioners should treat passkeys as a distributed identity object.
RP ID stability is a governance assumption, not just a technical setting. WebAuthn credentials are bound to a relying party ID and origin, so domain changes, CNAME decisions and subdomain design can break authentication at scale. That assumption was designed for environments where the application boundary stays stable long enough for credentials to remain valid. The implication is that identity architecture, DNS strategy and application change management now intersect directly.
Hybrid authentication states deserve formal ownership. Most organisations will not remove passwords overnight, so passkeys will coexist with OTP, legacy passwords and social or federated login for some time. That mixed state creates policy ambiguity about fallback, recovery, user education and metrics. Identity teams should own the transition state explicitly rather than treating it as a temporary implementation detail.
Zombie credentials are the signal that authentication has outgrown user-facing UX thinking. The article's warning about old or removed passkeys still lingering server-side shows how easy it is to accumulate stale authentication records. That is a lifecycle integrity problem with direct operational impact. The practitioner takeaway is clear: manage passkey inventory as an access asset, not as a front-end convenience feature.
From our research library:
- eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
What this signals
Identity teams should stop treating passwordless as a pure authentication project. The harder work sits in lifecycle governance, especially where recovery, device turnover and fallback methods intersect. That is where access continuity is won or lost, and where IAM teams need ownership rather than handoff to product teams.
Passkey programmes expose the same programme weakness seen in other identity transitions. If enrolment, offboarding and exception handling are not defined up front, the organisation ends up with stale credentials, user frustration and inconsistent assurance. The operational model has to be built alongside the authentication model.
WebAuthn only becomes durable when the identity boundary is stable. Domain strategy, application change management and credential inventory need to be aligned or otherwise credentials will break when the environment changes. That makes passwordless a cross-functional identity architecture decision, not just a security feature choice.
For practitioners
- Map passkey recovery to identity lifecycle ownership Assign explicit ownership for lost-device recovery, fallback verification and credential re-enrolment so users are not stranded when a single authenticator fails.
- Stabilise relying party and origin design Review domain, subdomain and CNAME strategy before rollout so WebAuthn credentials do not break when application boundaries change.
- Design and test fallback flows before enforcing passwordless Keep backup paths such as OTP or legacy authentication available until passkey coverage, device diversity and recovery confidence are proven.
- Inventory and retire stale passkeys Track enrolled credentials, remove orphaned entries when devices are replaced or lost, and audit for server-side records that outlive the authenticator.
- Test cross-platform login paths end to end Validate passkey behaviour across browsers, operating systems and sync ecosystems before broad deployment so device-specific quirks do not become production incidents.
Key takeaways
- WebAuthn removes shared secrets from the login path, but the practical challenge shifts to credential lifecycle, recovery and fallback governance.
- Passkeys improve usability by making WebAuthn credentials easier to use across devices, yet that convenience also creates new state-management problems.
- Organisations that want passwordless at scale need stable origins, explicit ownership for recovery and clean retirement of stale credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | WebAuthn and passkeys are authentication mechanisms covered by digital identity guidance. |
| Recommendation — Apply SP 800-63B to align passwordless authentication with assurance and verifier requirements. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Passkey rollout changes how access is granted and maintained across lifecycle states. |
| Recommendation — Use PR.AA-05 to govern authentication state, fallback access and credential changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale passkeys and removed devices create offboarding gaps for non-human credential state. |
| NHI-07 — Long-Lived Secrets | The article warns that credentials can linger after device changes instead of being retired cleanly. | |
| Recommendation — Remove orphaned passkeys when devices or users leave to prevent stale authentication state. Shorten credential lifetime and retire inactive passkeys on a defined lifecycle schedule. | ||
| CIS Controls v8 | CIS-5 — Account Management | Passkey enrolment, recovery and removal are account lifecycle problems under account management controls. |
| Recommendation — Align passkey enrolment and recovery with account management procedures and periodic review. | ||
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.
- Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
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.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org