Who is accountable when a passkey is lost, replaced, or revoked incorrectly?

Why This Matters for Security Teams

passkey change the failure mode, but not the accountability problem. When a passkey is lost, replaced, or revoked incorrectly, the risk is not just a login issue. It is a governance failure across authenticator policy, lifecycle proof, and exception handling. Security teams need a clear owner for issuance, recovery, and trust removal, because passwordless controls still depend on auditable decisions.

NIST’s Security and Privacy Controls emphasise identity lifecycle discipline, and the same principle shows up in NHI governance. NHI Management Group’s NHI Lifecycle Management Guide frames lifecycle ownership as a control, not an administrative detail. The same pattern matters for passkeys because a broken recovery path can silently reintroduce access after the original authenticator should have been retired.

Current guidance suggests the accountable function is identity and access management, but operational responsibility often crosses help desk, endpoint, security operations, and application owners. The organisation still needs a single control owner who can prove who approved the credential, when it changed, and when trust was removed. In practice, many security teams discover this only after a failed recovery or duplicate enrollment has already reopened access.

How It Works in Practice

Accountability should follow the control plane that governs the authenticator lifecycle. IAM owns the policy, while adjacent teams may execute parts of the workflow under defined approvals. The key requirement is that every loss, replacement, or revocation event leaves evidence that can be audited later. That includes who initiated the action, what assurance checks were performed, what device or factor was bound, and when the old binding stopped being valid.

This is where passwordless governance overlaps with broader identity lifecycle work described in Ultimate Guide to NHIs and with the operational failure modes in Top 10 NHI Issues. The same governance discipline applies even though passkeys are human authenticators: the organisation must treat replacement as a controlled state change, not a convenience reset.

• Define a single policy owner for passkey issuance, replacement, and revocation.
• Require step-up verification before replacement, especially for remote or high-risk recovery.
• Log the original authenticator, the reason for change, the approver, and the revocation timestamp.
• Synchronise revocation across IdP, device management, and application sessions.
• Use short-lived recovery grants and remove them automatically after use.

OWASP Non-Human Identity Top 10 is useful here because it reinforces a wider control lesson: lifecycle mistakes create standing trust that attackers can exploit. A passkey replacement process that is too permissive can become a recovery backdoor, especially when help desk workflows, device changes, and federated sessions are not tied together. These controls tend to break down in federated environments where revocation is delayed across multiple identity providers because the old assurance state persists in downstream sessions.

Common Variations and Edge Cases

Tighter recovery controls often increase user friction and support overhead, requiring organisations to balance account recovery speed against assurance. That tradeoff is real, especially for executives, contractors, and remote staff who cannot always complete the same recovery path as onsite employees. Best practice is evolving, but current guidance suggests risk-based recovery, not one-size-fits-all resets.

Some environments need stronger handling than others. Shared workstations, BYOD fleets, and regulated operations centers often require device-bound recovery with additional approval, while low-risk internal apps may tolerate simpler workflows. There is no universal standard for passkey replacement evidence depth yet, but the expectation is clear: the more sensitive the access, the stronger the proof of revocation and replacement.

NHIMG’s research on the Guide to the Secret Sprawl Challenge is relevant because weak recovery often creates new credential sprawl even in passwordless programs. The operational mistake is assuming revocation completed when only the primary login changed. In reality, stale sessions, synced devices, and fallback methods can keep trust alive unless IAM coordinates the full deprovisioning chain.

Security leaders should treat incorrect revocation as a post-incident control failure, not a minor help desk error. The accountable function remains IAM, but the evidence standard should span policy, execution, and verification so that trust removal is provable, not presumed.

Related resources from NHI Mgmt Group

• Who is accountable when identity data on a lost device is misused?
• Who is accountable when mobile access fails or a device is lost?
• Who is accountable when a passwordless credential is issued incorrectly or not revoked?
• Who is accountable when a smart data permission is granted or revoked incorrectly?