Why do passkeys fail on shared devices?

Why shared devices break the passkey model

Passkeys are designed around a stable user context, so shared devices create friction when that context keeps changing. The problem is usually not the passkey itself, but the device state it depends on: a different OS profile, a wiped browser store, a reset session, or a kiosk configuration that prevents the credential from being found or reused reliably.

On a personal device, the passkey can stay bound to the same authenticator and user profile. On a shared endpoint, that binding is weaker because the next person may inherit a clean session, a temporary profile, or a restricted shell. The result is an authentication method that works well for one user context but becomes fragile when the device is shared across multiple people.

In practice, the failure mode is often user-state mismatch rather than cryptographic weakness. Shared PCs, kiosks, managed guest sessions and roaming profiles can all interrupt credential discovery, local persistence, or the handoff back to the relying party. The issue is easiest to see when the shared device is treated as a stateless access point, but the passkey flow still expects a persistent, per-user authenticator relationship.

What usually causes the failure in real environments

The most common causes are synchronisation gaps, profile resets and platform restrictions. If the passkey lives in a password manager, OS cloud sync or a device-bound authenticator, the device must expose the right profile at the right time. If that profile is cleared, locked down, or unavailable to the next user, the passkey may not surface during the assertion step.

Shared-device settings can also break assumptions about user presence and local state. Kiosk lockdown modes, managed guest sessions, browser profile isolation, sign-out hygiene and disabled roaming behaviour may be appropriate for security, but they can prevent the device from carrying the credential state that passkeys expect. That trade-off is why the same deployment can feel seamless on a laptop and unreliable on a shared tablet or workstation.

When teams want a deeper operational pattern for these environments, the Kiosk and Shared Device Security Guide is the closest fit because it covers the lockdown and session-clearing patterns that shape this failure mode.

What works better when you cannot give every user a private device

For shared endpoints, the practical answer is usually not “force the same passkey everywhere”, but “choose an authentication pattern that matches the device model.” That may mean shared-device mode, a security key, badge sign-in, QR-code sign-in, or another method that can survive user turnover without relying on a leftover local profile.

Where passkeys are still desirable, the deployment needs to distinguish between syncable and device-bound behaviour, and between consumer-style convenience and enterprise control. A shared workstation is not just another browser, it is a different trust boundary, so the sign-in design has to account for session clearing, enrolment, recovery and user handoff from the start. NHIMG’s Passwordless and Passkeys Guide and Passwordless for Frontline and Shared Devices Guide both map well to that operational choice.

Risk and Threat Considerations

Shared devices do not just make passkeys inconvenient, they can widen the gap between intended authentication policy and actual user behaviour. When users cannot complete passkey sign-in reliably, they are more likely to fall back to weaker recovery paths, shared accounts, or help-desk assisted resets, which can enlarge the attack surface around the shared endpoint.

Failure mechanism: The device either loses the user-specific credential state on sign-out or never exposes the correct profile, so the passkey cannot be selected or asserted when needed. If administrators compensate by adding permissive fallbacks, the control posture shifts from strong authentication to exception handling.

Impact: Repeated login failure can create shadow access patterns, more password resets, more shared credentials, and more opportunities for misuse of a kiosk or terminal that was meant to be tightly controlled.

Practitioner Guidance

What to verify: Confirm where the passkey actually lives, on the device, in a synced credential store, or in a managed profile, before assuming a shared endpoint can support it. If users rotate through the same hardware, test the full sign-out and next-user path, not just first-time enrolment.

Decision rule: If the endpoint is deliberately stateless, treat passkey support as conditional and design for a shared-device authentication pattern instead of relying on local persistence. If the device must preserve user state, verify that profile isolation, roaming behaviour and recovery flows are compatible before rollout.

Practitioner takeaway: Shared-device passkey failures usually point to a mismatch between authentication design and endpoint design, so the right fix is to align the sign-in method with the device lifecycle, not to assume every passkey should behave the same way on every workstation.

Related resources from NHI Mgmt Group

• Who is accountable when device-bound passkeys are used across shared and personal devices?
• Why do healthcare identity controls fail when clinicians use shared devices and mixed systems?
• Where do shared devices fail in law-enforcement identity design?
• Why do IP-based policies fail for distributed devices?