What happens when users lose all trusted devices but still need access to a passkey protected account?

What changes when no trusted device is left?

A passkey protected account is usually tied to one or more trusted devices, so losing all of them removes the normal sign-in path. At that point, the account is only recoverable if the service offered a separate restoration method and the user set it up before the loss. The practical question is not whether passkeys work, but whether continuity was designed in.

The important distinction is between authentication and recovery. A passkey proves possession of a device-backed credential, but recovery is a different control path that may use backup codes, another enrolled device, help desk verification, or an identity recovery workflow. If none of those exist, the account may be effectively locked, even though the passwordless design itself is working as intended.

That is why passkey programmes should be treated as an account continuity design problem, not just a sign-in upgrade. If the account is business critical, the recovery route needs to be documented, tested, and stored separately from the primary device. For broader identity design context, the Passwordless and Passkeys Guide explains how recovery should be planned alongside rollout, and the Workforce Identity Security Guide covers account recovery as part of secure identity operations.

Why recovery paths matter more than most teams expect

Passkeys reduce phishing exposure, but they also concentrate access around trusted devices. That means the failure mode shifts from stolen passwords to lost device access, broken device enrollment, or a recovery process that is too weak to trust. The design goal is to make account restoration possible without making takeover easy.

A good recovery design usually includes at least one independent fallback, such as recovery codes, a second enrolled authenticator, or a high-assurance identity proofing step. The fallback should not simply mirror the lost device path. It needs different evidence, different storage, and different abuse resistance so that losing one device does not collapse the whole account model.

Practitioners should also expect user behaviour to create risk. People often store backup codes badly, fail to test restoration, or assume a cloud-synced passkey will always be available on the next phone. The result is avoidable lockout, support escalation, and pressure to weaken recovery controls after the fact.

How to design recovery without weakening passkey security

Recovery should be treated as a controlled exception path, not a convenience feature. A strong design keeps the primary passkey flow phishing-resistant while making the restoration route deliberate, documented, and auditable. The more valuable the account, the more important it is to separate ordinary sign-in from emergency restoration.

In practice, that means giving users clear instructions for storing recovery codes, enrolling more than one trusted device where appropriate, and knowing which recovery step applies if the device is lost, wiped, or replaced. The recovery process should also define who can approve it, what evidence is required, and when the account must be suspended until ownership is re-established.

For teams that own identity operations, this is also where break-glass thinking helps. The safest recovery path is one that is rare, tested, and monitored rather than improvised during an outage. The Break-Glass and Emergency Access Account Guide is useful when recovery has to be handled as a controlled emergency path, and the Privileged Access Management Guide is relevant where administrative recovery access itself must be tightly bounded.

Risk and Threat Considerations

When all trusted devices are lost, the main risk is either permanent lockout or a rushed recovery process that is easier to abuse than the original sign-in method. Attackers often target recovery because it is the weakest remaining route, especially when support staff can be pressured, identity checks are inconsistent, or backup materials are stored insecurely.

Failure mechanism: The primary sign-in device disappears, the user cannot complete the normal passkey challenge, and the recovery path is missing, untested, or too permissive. In some environments the fallback becomes the real attack surface, especially if recovery codes are reused, shared, or stored where an intruder can find them.

Impact: Users may lose access to critical accounts, business workflows may stall, and help desk or recovery teams may be forced into ad hoc decisions under time pressure. In the worst case, a weak recovery process becomes a takeover path that defeats the security gains of passkeys.

Practitioner Guidance

What to verify: Confirm that every passkey protected account has at least one tested recovery path before rollout is treated as complete. Verify where recovery codes are stored, who can use them, and whether a lost-device scenario has been exercised end to end.

Decision rule: If the account is important enough that loss would interrupt operations, require a documented backup device or a high-assurance recovery method, not just a single trusted phone. If the recovery route depends on support intervention, make sure the approval and evidence standard is explicit and resistant to social engineering.

Practitioner takeaway: Passkeys are strongest when recovery is designed with the same discipline as primary authentication, because account continuity depends on the quality of the fallback path, not on the lost device itself.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• What happens if users lose access to their second-factor device and have no recovery process?
• What happens when employees access protected web apps from devices that do not meet policy?
• What are the signs that a passkey login flow is not well designed for shared devices or multi-account users?