When should organisations use shared-device authentication instead of synced passkeys?

When shared-device authentication is the better fit

Shared-device authentication is the better fit when the trust boundary is the endpoint and the current session, not a long-lived personal authenticator. That makes it appropriate for kiosks, shift workers, shared tablets, and other environments where the same device serves different people over time and the organisation needs fast, controlled sign-in and sign-out.

The design assumption is different from synced passkeys. Synced passkeys work best when a user carries a stable personal device and can move between devices without losing their account context. Shared-device flows instead need the device to be managed, the session to be bounded, and the handoff between users to be explicit so one person does not inherit another person’s access state.

That is why shared-device authentication is usually combined with short session lifetimes, stronger re-authentication at the point of use, and device-level controls that clear the previous user’s state. In practice, the question is not whether passkeys are strong, but whether a synced authenticator matches the operating model. On a shared endpoint, it often does not.

What changes in the authentication design

When a device is shared, authentication must prove both who is using the service and that the current device state is clean enough to trust. The control focus shifts from “is this the right person with the right personal authenticator?” to “is this the right person on the right managed device for this session?” That usually means the device, session, and re-authentication policy matter more than portability.

Shared-device authentication can use mechanisms such as device binding, QR or badge based sign-in, PIN or step-up checks, and managed guest or shared-device mode. The important point is that the credentials are designed to work within a transient session model. If the workflow depends on the next user starting from a blank state, portability becomes less important than clean session separation.

For readers comparing implementation patterns, the practical difference is covered well in Passwordless for Frontline and Shared Devices Guide and Kiosk and Shared Device Security Guide. If the environment is truly shared, those models are more aligned than a consumer-style synced passkey experience.

When synced passkeys are the wrong assumption

Synced passkeys assume the user can retain a personal relationship with an authenticator across devices and over time. That assumption breaks down when workers do not have reliable personal devices, when devices are handed between users, or when the business process requires a rapid sign-in and clean sign-out between shifts. In those cases, a synced passkey can create friction or leave the organisation trying to force a personal-authenticator model onto a shared operating model.

That mismatch matters operationally because recovery, enrolment, and device replacement are much less predictable in transient environments. If the account model depends on a personal phone, a user profile, or a long-lived synced credential ecosystem, the organisation can end up with fragile fallback paths that are harder to administer than the access problem they were meant to solve.

The most useful comparison for rollout planning is the distinction between portability and continuity. Passkeys for Everyone Guide and Passkey Rollout Guide both help clarify where synced passkeys are a good fit and where a population needs a different sign-in pattern.

Risk and Threat Considerations

Shared-device authentication reduces the risk of assuming a personal authenticator exists when it does not, but it introduces its own exposure if session clearing, re-authentication, or device management is weak. The main danger is cross-user access leakage, where the next user inherits a live session, cached state, or residual trust on a device that was not properly reset.

Failure mechanism: The control fails when a shared endpoint keeps tokens, browser state, local credentials, or active sessions after the user changes. In that situation, the authentication method may be sound, but the operational handoff is not, which can turn a shared device into an access persistence point.

Impact: A compromised or simply uncleared session can expose application data, internal tools, or downstream accounts to the next user, and it can also make investigations harder because the device no longer cleanly maps actions to one person. In high-turnover or frontline settings, that can become a repeated governance and incident-response problem rather than a one-off error.

Practitioner Guidance

What to prioritise: Decide first whether the environment is truly shared, because that decision should drive the authentication pattern. If users regularly swap devices or cannot rely on a personal authenticator, treat session control and device hygiene as first-class requirements rather than add-ons.

What to verify: Confirm that sign-out really clears the previous user’s state, that re-authentication happens at sensible checkpoints, and that recovery does not quietly reintroduce a personal-device dependency. The control is only working if a new user starts from a bounded session, not from a remembered one.

Practitioner takeaway: Use shared-device authentication when the security boundary is the managed endpoint and the current session, and use synced passkeys when the security model can safely follow the person across devices. If the workplace is transient or jointly used, portability is less important than clean session separation and predictable handoff.

Related resources from NHI Mgmt Group

• Device Authentication
• How should security teams decide when to use device binding instead of passkeys?
• Should organisations use synced or device-bound passkeys for privileged access?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?