Passkeys are replacing passwords, but lifecycle control still matters

At a glance

What this is: This is an RSA Security analysis of passwordless authentication that argues passkeys are replacing passwords and highlights their phishing resistance, lower support cost, and enterprise rollout considerations.

Why it matters: It matters because passkeys change human identity control design, especially for regulated access, privileged users, and lifecycle processes that have to work across IAM, IGA, and PAM.

By the numbers:

• The average cost of a single password reset is $70 per incident, covering support labor, infrastructure, and downstream productivity loss.
• In 2026, 87% of enterprises are actively deploying or piloting passkeys, up from 53% just two years prior.
• The passwordless authentication market reached $24.1 billion in 2025 and is projected to reach $55.7 billion by 2030.
• According to Google’s research, accounts protected by passkeys are 99.9% less likely to be compromised than password-only accounts.

👉 Read RSA Security's blog on why passkeys are replacing passwords

Context

Passkeys are cryptographic credentials that replace passwords with public-key authentication tied to a device or synced credential store. For human identity programmes, the shift matters because the control point moves away from shared secrets and toward device assurance, lifecycle handling, and phishing resistance.

The governance gap is not authentication alone. IAM, IGA, and PAM teams still need to answer who can enrol a passkey, how device loss and recovery are handled, and what happens when a privileged user leaves the organisation or a regulated device is replaced.

RSA Security frames passkeys as the next stage of passwordless authentication, but the operational challenge is enterprise adoption at scale. That makes identity lifecycle management, fallback paths, and recovery design as important as the login ceremony itself.

Key questions

Q: How should security teams govern passkey issuance in enterprise identity systems?

A: Security teams should treat passkey issuance as a governed identity event, not a simple enrollment action. That means separating identity proofing from credential binding, logging approvals, and aligning recovery and offboarding with the same assurance level as issuance. Without those controls, phishing-resistant authentication can still be attached to an inadequately verified identity.

Q: Why do passkeys change the risk profile for human identity programmes?

A: Passkeys remove the shared secret that phishing, replay, and password reuse depend on. That reduces credential theft risk, but it also shifts governance toward device assurance, recovery processes, and user lifecycle handling. The main challenge becomes whether the identity programme can manage the authenticator end to end without creating new exceptions.

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

A: The most common mistake is treating passwordless as a user-experience upgrade instead of an identity control change. Teams often focus on the login screen and ignore recovery, lifecycle governance, and fallback authentication, which is where many of the real risks emerge.

Q: What should organisations do when an employee loses a passkey device?

A: They should revoke or recover the credential through a documented process that is tied to the user’s identity record and access level. The response should be defined before rollout, especially for privileged users. If recovery is improvised, the organisation creates a new bypass path that weakens the control it intended to strengthen.

Technical breakdown

How passkeys replace password-based authentication

Passkeys use asymmetric cryptography instead of shared secrets. When a user enrols, the device creates a public-private key pair, and the service keeps only the public key. During login, the device signs a challenge with the private key, and the service verifies it. Because no password is generated, transmitted, or stored, phishing and replay attacks lose their primary target. In enterprise settings, the assurance level depends on whether the passkey is device-bound or synced, since syncing changes where the private key lives and how much control the organisation has over it.

Practical implication: treat passkey type as an assurance decision, not a user-experience preference.

Device-bound passkeys and enterprise assurance

Device-bound passkeys keep the private key on a single device and are the stronger choice for privileged access and regulated workflows. Synced passkeys improve convenience, but they introduce a different trust model because the credential may be recoverable across devices through a sync fabric. That distinction matters for IAM governance, because the assurance boundary is no longer just the user, but the device and the recovery ecosystem around it. For privileged access, the control objective is not merely password removal, but assurance that the authenticator is tightly bound to the intended device and user context.

Practical implication: reserve device-bound passkeys for high-risk roles and regulated access paths.

Lifecycle management is now part of authentication architecture

Passwordless programmes fail when lifecycle handling is treated as an afterthought. Enrollment, deprovisioning, device replacement, and recovery must all be defined before broad rollout, especially where users hold elevated access. If a device is lost or an employee departs, the organisation must be able to revoke or recover the credential without creating a gap that weakens identity assurance. That makes passkeys an IAM and IGA issue, not just an authentication project. The practical question is whether the identity team can govern the credential across its full lifecycle, not whether the sign-in prompt is simpler.

Practical implication: build passkey lifecycle rules into joiner-mover-leaver processes before expanding rollout.

Threat narrative

Attacker objective: The attacker wants to take over a human identity through stolen or replayed credentials and use that access to move into sensitive systems.

1. Entry occurs through password phishing, credential reuse, or help desk abuse of password reset workflows, which remain the main weaknesses in traditional authentication.
2. Escalation follows when stolen secrets or weak MFA allow account takeover, privileged session access, or lateral movement into enterprise applications and remote access paths.
3. Impact is credential-based compromise, with attackers using the authenticated identity to steal data, alter systems, or maintain persistent access until passwords are reset.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Passkeys solve the phishable secret problem, but they do not eliminate identity governance. Moving from passwords to cryptographic authenticators removes a major attack path, but the organisation still has to govern enrolment, recovery, and revocation. Human identity risk shifts from secret theft to lifecycle control. The practitioner conclusion is straightforward: the control surface changes, not the need for governance.

Device-bound passkeys create a stronger enterprise assurance model than synced passkeys. Synced credentials may improve adoption, but they weaken organisational control over where the private key can exist and how recovery is mediated. That matters most for privileged users and regulated access. The practitioner conclusion is that assurance requirements should drive passkey type selection, not deployment convenience.

Passwordless adoption exposes the same lifecycle discipline that IAM teams have always needed. Passkeys only reduce risk when they are wired into joiner-mover-leaver processes, device governance, and offboarding. Without that, organisations simply replace password sprawl with passkey sprawl. The practitioner conclusion is to treat credential lifecycle as the core programme, not the login method.

Passkeys are becoming a compliance and controls conversation, not just an authentication upgrade. Their value shows up in phishing resistance, reduced help desk pressure, and better support for regulated access, but only if the surrounding identity programme can sustain the change. That puts IAM, IGA, and PAM teams in the same operating conversation. The practitioner conclusion is to align passwordless rollout with identity governance ownership from day one.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• For the governance lens that sits behind passwordless and machine identity work, see Ultimate Guide to NHIs , Why NHI Security Matters Now.

What this signals

Passkeys are a useful reminder that authentication improvements only become durable when the surrounding identity programme can govern enrolment, recovery, and revocation. Teams that treat passwordless as a point solution will likely recreate the same operational sprawl in a new control plane.

Identity assurance debt: This is the gap that appears when organisations modernise the sign-in method without modernising the lifecycle rules around it. The reader should expect more scrutiny of recovery workflows, device binding, and fallback authentication as passwordless adoption expands.

The next phase of passwordless maturity will be measured less by adoption headlines and more by whether IAM, IGA, and PAM operate from a shared lifecycle model. That shift is already visible in the broader move toward identity governance for every authenticator type.

For practitioners

• Map every authentication path before rollout Inventory VPNs, cloud apps, privileged workstations, and any legacy system that still depends on passwords or phishable MFA. Use that map to decide where passkeys can replace credentials directly and where fallback controls need redesign. Suggested anchor: authentication path
• Use device-bound passkeys for privileged and regulated access Set device-bound passkeys as the default for administrator accounts, sensitive business functions, and environments with compliance requirements. Keep synced passkeys for lower-risk scenarios where usability outweighs the need for tighter device binding. Suggested anchor: device-bound passkeys
• Define passkey recovery and revocation rules up front Document what happens when a device is lost, a user changes devices, or an employee leaves the company. Build those rules into JML, offboarding, and privileged access workflows so recovery does not create a new standing-access problem. Suggested anchor: recovery and revocation
• Pilot with privileged users and measure lifecycle friction Start with IT staff or a single business unit, then track successful authentications, help desk volume, fallback usage, and recovery exceptions. Those signals show whether the programme is reducing risk or simply moving it into a different workflow. Suggested anchor: fallback usage
• Align passwordless policy to IAM, IGA, and PAM ownership Assign clear accountability for passkey enrolment, device assurance, recovery, and deprovisioning across identity teams. If no team owns the lifecycle end to end, passwordless adoption will fragment across support, security, and operations. Suggested anchor: lifecycle end to end

Key takeaways

• Passkeys remove phishable secrets, but they do not remove the need for identity governance.
• Device-bound authenticators are the stronger enterprise choice when privileged access and regulated workflows are involved.
• Passwordless programmes fail when recovery, revocation, and offboarding are not designed before rollout.

Key terms

• 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.
• Device-Bound Passkey: A device-bound passkey is a FIDO credential tied to one physical device and generally stored in hardware-backed secure components. The value for enterprise security is lifecycle control, because the credential is easier to inventory, constrain, and revoke without relying on cloud sync paths.
• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.

What's in the full article

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

• Step-by-step enterprise rollout guidance for moving from password-based sign-in to passkeys across hybrid environments.
• Specific implementation notes on device-bound versus synced passkeys for enterprise, privileged, and consumer-facing use cases.
• Lifecycle handling details for enrollment, device loss, employee departure, and recovery within a central administration plane.
• Practical adoption measures such as pilot design, fallback authentication, and help desk impact tracking.

👉 RSA Security's full article covers the eight-step rollout, lifecycle handling, and enterprise adoption details.

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.