Passkey sprawl is the uncontrolled spread of passkeys across browsers, consumer password managers, and unmanaged storage locations. It becomes a governance problem when the organisation no longer knows where credentials live, who can recover them, or whether the intended control boundary still exists.
What Passkey Sprawl Means in Practice
Passkey sprawl is not just “too many passkeys.” It is the loss of a clear control boundary when passkeys appear across multiple browsers, consumer password managers, and unmanaged storage locations, making ownership and recovery harder to reason about.
That matters because passkeys are intended to replace fragile shared secrets with phishing-resistant sign-in, but the security value depends on knowing where the credential lives, which device or sync ecosystem can recover it, and whether the organisation still controls the path.
In a healthy model, passkeys are deliberately issued, discoverable, and governed. In a sprawl condition, they may still function, but they stop behaving like a managed access mechanism and start behaving like scattered consumer convenience artifacts.
How Passkey Sprawl Happens
Sprawl usually emerges when users create passkeys on unmanaged browsers, personal devices, or synced consumer accounts outside the organisation’s intended identity workflow. The result is multiple copies or recoverable versions of the same sign-in factor, often with unclear precedence and unclear recovery paths.
It is also common when teams roll out passkeys before defining enrollment policy, approved authenticators, device binding expectations, or account recovery rules. Without those constraints, the organisation may gain passkey adoption while losing consistency.
The underlying pattern is governance drift, not a broken cryptographic primitive. Passkeys can be secure and still be badly governed if the estate grows faster than the policies that should contain it.
Why Passkey Sprawl Becomes a Governance Problem
The core issue is visibility and control. If you cannot tell where passkeys are stored, who can sync or recover them, and which environment is authoritative, you cannot confidently answer ownership, audit, or incident-response questions.
That becomes especially important when account recovery, browser sync, or consumer-managed ecosystems create shadow control planes around the passkey. The organisation may think it has removed passwords, but it has actually distributed authentication authority into places it does not administer. NHIMG’s Passwordless and Passkeys Guide is useful here because it frames passkeys as a managed authentication choice, not just a usability feature.
Passkey sprawl also matters because identity teams often care about the lifecycle, not only the login event. A passkey that can be silently replicated, synced, or recovered outside policy creates the same kind of control ambiguity that makes other identity assets hard to govern.
Operational Boundaries and Control Signals
To treat passkeys as a governed control, organisations need a clear boundary between approved passkey use and unmanaged passkey proliferation. The practical signal is simple: if the help desk, IAM team, or security team cannot explain where recovery is possible and where it is not, the control boundary is already fuzzy.
Passkey sprawl also complicates offboarding and exception handling. A user may remove one device, but another browser profile, synced consumer vault, or personal recovery path may still retain access. That makes inventory, ownership, and recovery policy just as important as enrollment.
For a broader identity-control lens, NHIMG’s Workforce Identity Security Guide helps place passkeys inside the larger employee-authentication and recovery model, while NIST SP 800-63 Digital Identity Guidelines provides the identity-assurance context that passkey programmes usually need to align with.
Risk and Threat Considerations
Passkey sprawl raises the risk of uncontrolled recovery paths, inconsistent ownership, and weak visibility into where authentication control actually resides. The issue is not that passkeys are inherently unsafe, but that unmanaged duplication and consumer sync can erode the boundary the organisation depends on.
Failure mechanism: A passkey is created or synced into an unmanaged browser, personal account, or consumer vault, then survives outside the organisation’s intended lifecycle and recovery model.
Impact: Recovery becomes harder to audit, offboarding becomes less reliable, and an attacker or unauthorized user may benefit from a credential path the organisation did not expect to remain active.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkey sprawl concerns the lifecycle and control of authenticators. |
| IA-2 — Identification and Authentication (Organizational Users) | Passkeys are an organizational user authentication mechanism. | |
| IA-12 — Identity Proofing | Recovery and enrollment paths depend on trusted identity proofing. | |
| Recommendation — Track, govern, and revoke passkey authenticators under IA-5. Bind passkey use to approved user authentication under IA-2. Require strong identity proofing before issuing or recovering passkeys. | ||
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | Passkeys are commonly deployed within assurance-level based sign-in policy. |
| AAL3 — Authenticator Assurance Level 3 | Phishing-resistant passkeys often target higher-assurance authentication. | |
| Recommendation — Map passkey policy to the required assurance level and recovery rules. Use higher-assurance passkey requirements where phishing resistance is mandatory. | ||
Practitioner Guidance
Why practitioners should care: Treat passkey rollout as an identity-governance change, not just an authentication upgrade. If the organisation does not define which authenticators, browsers, and recovery mechanisms are approved, passkey adoption can quietly expand the attack surface instead of shrinking it.
What to watch for: Watch for duplicate registrations, consumer-managed recovery, unexplained sign-in success from unmanaged environments, and users who cannot describe where their passkey is stored. NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks is also relevant as a governance analogue because it highlights how sprawl and visibility gaps become control problems once an identity estate grows beyond direct oversight.
Practitioner takeaway: A passkey programme is only as strong as its recovery boundaries, inventory discipline, and approved storage model.