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

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.

Why This Matters for Security Teams

A lost passkey device is not just a help desk inconvenience. It is a control-plane event that can expose authentication, recovery, and privilege assumptions at the same time. If the organisation has not pre-defined how a device is revoked, recovered, or re-bound to the user record, the fallback path often becomes the weakest path. That is especially dangerous for privileged users, where one rushed exception can outlive the incident itself.

Current guidance from NIST Cybersecurity Framework 2.0 pushes organisations toward repeatable identity and access governance rather than ad hoc recovery decisions. In the NHI context, NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a reminder that recovery discipline is often weak even before a device is lost. The same lifecycle thinking applies to passkeys: the credential must be handled through a documented identity process, not an improvised trust decision.

In practice, many security teams encounter the real failure only after a device loss turns into an undocumented bypass for re-enrolment or recovery.

How It Works in Practice

The safest response is to treat the lost device as a credential lifecycle event, not a simple replacement request. The organisation should first verify the user through an identity proofing or recovery workflow that is stronger than the lost factor itself, then revoke or invalidate the passkey binding associated with the missing device. If the user needs continued access, a new passkey should be enrolled only after the recovery step is tied to the user’s authoritative identity record and current access level.

For privileged accounts, the process should be stricter. Best practice is evolving, but most mature programs separate standard user recovery from privileged recovery and require a different approval path, stronger proofing, or temporary step-up controls. That reduces the chance that a lost device becomes a shortcut around privileged access controls. The response should also be logged as an identity event, not just an IT support ticket, so security teams can review patterns, confirm revocation, and check for lateral access exposure.

Operationally, this works best when passkey recovery is paired with explicit fallback policy, such as:

• device loss triggers immediate credential revocation for the missing authenticator
• re-enrolment is allowed only after verified identity recovery
• privileged users require separate approval and audit evidence
• temporary access is time-bound and removed automatically after recovery completes
• help desk scripts are locked to the approved workflow, not judgment calls

This approach aligns with the broader identity lifecycle discipline described in Ultimate Guide to NHIs, where governance failures often come from unmanaged exceptions rather than the primary control itself. These controls tend to break down when recovery is handled through informal support channels because the organisation cannot prove who was re-bound to which access rights.

Common Variations and Edge Cases

Tighter recovery controls often increase user friction and support workload, requiring organisations to balance resilience against operational speed. That tradeoff becomes more pronounced when the lost device belongs to an executive, an administrator, or a field worker who cannot easily complete a normal proofing flow.

There is no universal standard for every recovery scenario yet, but current guidance suggests that the recovery method should match the sensitivity of the account and the assurance level originally used to issue the passkey. For lower-risk users, a well-governed reset may be acceptable. For higher-risk roles, organisations often need a stronger combination of manager approval, identity verification, and short-lived access restrictions before a new passkey is issued.

Edge cases also include shared devices, BYOD environments, and users with multiple authenticators. In those settings, the key question is whether the lost device was the only binding to the account or just one of several valid authenticators. If other strong factors remain active, the organisation may choose to disable the missing device without interrupting service. If the lost device was the sole trusted path, the user should be treated as effectively offline until recovery is complete. That is why a pre-written recovery policy matters more than the device loss itself, because the business impact depends on the account’s privilege, fallback methods, and recovery assurance.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?