Passkeys replace passwords, but the governance gap remains

At a glance

What this is: This is a practitioner analysis of how passkeys differ from passwords and why passwordless authentication changes identity risk, user experience, and implementation choices.

Why it matters: It matters because IAM teams must redesign authentication, recovery, and fallback controls across human identity programmes without creating new blind spots for access assurance.

By the numbers:

• Microsoft reports a 98% success rate with passkeys compared to just 32% for passwords.
• Google measured passkey logins averaging 14.9 seconds vs. 30.4 seconds for passwords.
• PayPal observed a 70% drop in ATO attempts after introducing passkeys.
• Authsignal analyzed one million authentication attempts and found passkeys used in 62% of flows.

👉 Read Descope's analysis of passkeys versus passwords

Context

Passkeys are a passwordless authentication method that replaces shared secrets with device-bound cryptography and local user verification. In identity terms, the shift changes the control surface from memorized credentials to possession of a private key and the policies that surround device trust, recovery, and fallback.

For IAM teams, the question is not whether passkeys are more secure than passwords. The real issue is how to move from a familiar but fragile authentication model to one that changes enrolment, recovery, helpdesk processes, and user fallback paths across human identity programmes.

Key questions

Q: How should security teams roll out passkeys without creating new identity gaps?

A: Roll out passkeys by application tier and assurance level, not by blanket mandate. Start with high-friction, high-risk use cases, then align enrolment, recovery, device replacement, and revocation with existing IAM lifecycle processes. The goal is to remove shared secrets without creating weak fallback paths that attackers can exploit.

Q: Why do passkeys improve security but not eliminate identity risk?

A: Passkeys remove the shared secret that attackers usually steal, guess, or phish, which is a major improvement. But identity risk shifts into device trust, account recovery, enrolment, and fallback. If those controls are weak, an attacker can still gain access without ever defeating the passkey cryptography itself.

Q: What do organisations get wrong when replacing passwords with passkeys?

A: The most common mistake is treating passkeys as a simple factor replacement. In practice, passwordless authentication changes the entire access lifecycle, including proofing, support workflows, device registration, and revocation. If those surrounding controls stay password-era, the programme inherits the old risk in a new form.

Q: How do you know whether a passkey programme is actually working?

A: A passkey programme is working when password use, phishing success, and reset-related support demand all decline without increasing account recovery incidents or access exceptions. Track login success, fallback usage, recovery events, and the proportion of applications still outside the passkey policy boundary.

Technical breakdown

How passkeys change the authentication ceremony

Passkeys use a public-private key pair instead of a shared secret. The public key is stored by the service, while the private key stays on the user’s device and is unlocked locally by a PIN, fingerprint, or face scan. During login, the service issues a challenge and the device signs it, proving possession without exposing reusable credentials. That removes the phishing target that passwords create and shifts risk toward device compromise, enrolment abuse, and recovery flows rather than password guessing or reuse.

Practical implication: move authentication design away from shared-secret assumptions and treat device binding, recovery, and fallback as first-class controls.

Passwordless authentication and the new failure modes

Passwordless authentication reduces credential stuffing, brute force, and password reset fraud, but it does not eliminate identity risk. Attackers can still target enrolment, intercept session handoff, abuse legacy fallback methods, or exploit weak account recovery. In other words, the attack surface moves from password theft to identity orchestration. That makes the surrounding identity lifecycle, including proofing, device registration, recovery, and revocation, more important than the login factor itself.

Practical implication: review enrolment and recovery paths with the same scrutiny you once reserved for password policy.

Cross-platform passkey adoption and integration constraints

Passkey support is increasingly available across major operating systems and browsers, which makes adoption more realistic for enterprise identity stacks. But compatibility does not mean uniform implementation. Organisations still have to decide how passkeys fit with federation, conditional access, backup factors, and legacy applications that cannot yet handle passwordless flows. The architectural challenge is to introduce passkeys without creating parallel authentication paths that weaken assurance or confuse users.

Practical implication: map passkey rollout to application criticality and federation dependencies before removing passwords from high-value paths.

NHI Mgmt Group analysis

Passkeys solve the shared-secret problem, but they do not solve the identity lifecycle problem. Passwordless authentication removes one of the oldest attack primitives in IAM, yet the real governance burden shifts to enrolment, recovery, revocation, and fallback. The control plane changes from password policy to device-bound identity assurance, which means programme owners have to govern the full authentication journey, not just the credential.

The passkey transition exposes a hidden dependency on human identity recovery flows. Password programmes have trained enterprises to think in terms of memorised secrets and reset procedures. Passkeys move the risk into proofing, device trust, and account recovery, which are often less mature than the password controls they replace. Practitioners should treat that as a governance redesign, not a simple factor swap.

Passkey adoption is a human IAM modernisation issue, not a point product decision. The strongest implementations will align authentication, helpdesk, fraud prevention, and access assurance under one operating model. That matters because user convenience and security gains disappear if organisations leave legacy fallback paths untouched or create inconsistent experiences across applications.

Passwordless assurance debt: The industry has spent years optimising password hygiene while leaving recovery, fallback, and device binding unevenly governed. Passkeys reduce password risk only if the surrounding identity process is strong enough to carry the assurance model forward. That is the central governance test for IAM teams adopting passwordless flows. The practitioner conclusion is to judge passkey programmes by lifecycle integrity, not by login ceremony alone.

Cross-domain identity governance matters more as authentication improves. Stronger login methods can make it easier to overlook downstream access governance gaps, especially where human identity, federation, and privileged access intersect. The practical lesson is that passkeys should tighten control expectations across IAM, not relax them.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to the same report.
• That pattern reinforces why teams moving to passwordless authentication should pair stronger login assurance with tighter governance of privileged and non-human access, including the Ultimate Guide to NHIs.

What this signals

Passkey adoption will reduce dependence on shared secrets, but it will also expose how many identity programmes still treat recovery and fallback as administrative afterthoughts. The governance shift is broader than authentication. Teams that already struggle with lifecycle discipline will see the same weakness surface in device binding, account recovery, and cross-application exception handling.

Passwordless assurance debt: if authentication improves faster than governance, organisations accumulate risk in the gaps between enrolment, recovery, and revocation. That is why passkey programmes need to be designed alongside identity lifecycle controls, not bolted onto existing login flows.

For practitioners building a broader identity roadmap, the useful next step is to align passwordless rollout with standards such as the NIST AI Risk Management Framework only where AI-assisted identity workflows are involved, and with the Ultimate Guide to NHIs when device, workload, or machine credentials share the same lifecycle.

For practitioners

• Rework authentication policy around device-bound assurance Define where passkeys are mandatory, where fallback factors are allowed, and which applications still require passwords during transition. Tie the policy to assurance level, not user preference.
• Audit account recovery and enrolment flows Review proofing, helpdesk reset steps, and device re-registration to ensure they do not reintroduce weak or phishable paths into an otherwise passwordless programme. Use the same governance standard across web, mobile, and workforce apps.
• Map legacy fallback paths before rollout Inventory every place a password, OTP, or manual override still exists so you can avoid shadow authentication routes that undermine passkey adoption. Remove or constrain fallback options where risk tolerance is low.
• Align passkey rollout with IAM lifecycle controls Connect enrolment, device replacement, revocation, and offboarding to your identity lifecycle process so a passkey is treated as governed access, not just a login convenience.

Key takeaways

• Passkeys remove the shared-secret weakness that makes passwords so easy to steal, reuse, and phish.
• The biggest governance risk shifts to enrolment, recovery, fallback, and device trust, not the login ceremony itself.
• IAM teams should treat passkey adoption as a lifecycle redesign exercise, because authentication is only as strong as the controls around it.

Key terms

• Passkey: A passkey is a passwordless credential that uses public-private key cryptography and device-local verification instead of a memorised secret. The private key stays on the user’s device, while the service stores only the public key, which makes phishing and reuse far harder than with passwords.
• Passwordless Authentication: Passwordless authentication is a login model that removes shared secrets from the primary sign-in step. Instead, access is proven with cryptographic possession, device trust, biometrics, or a screen lock, shifting security decisions into enrolment, recovery, and lifecycle controls rather than password policy.
• Account Recovery: Account recovery is the process used to restore access when a user loses a credential, device, or authentication factor. In passwordless programmes, it becomes a critical trust boundary because weak recovery flows can undo the security benefits of stronger primary authentication.
• Device Binding: Device binding links an identity credential to a specific device or trusted hardware environment. In passkey systems, it limits where the private key can be used and helps prevent credential reuse, but it also requires careful handling of device replacement, revocation, and support workflows.

What's in the full article

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

• Step-by-step passkey implementation guidance for teams planning a phased authentication transition.
• Practical comparison points for deciding where passwords can remain as fallback during rollout.
• Platform compatibility notes across browsers, operating systems, and SDK integrations.
• Examples of how to position passkeys alongside existing authentication workflows without breaking user access.

👉 Descope's full post covers the authentication ceremony, user-experience trade-offs, and implementation context in more detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.