Use a shared-device policy, not a blanket passwordless policy. Passkeys work best when a single person owns the device and the account. On communal workstations, require a credential model that preserves individual attribution, explicit revocation, and session separation so one user’s sign-in does not become the next user’s starting state.
Why shared workstations change the passkey decision
Passkeys are strongest when the authenticator, the account, and the device all map cleanly to one person. A communal workstation breaks that assumption because the next user may inherit an already signed-in browser, an unlocked profile, or a cached session. The problem is not passkeys themselves, it is using them in a device-sharing model that destroys attribution and makes state cleanup unreliable.
On a shared terminal, the security question is whether the workstation can reliably separate users, not whether the sign-in method is phishing-resistant. If you cannot guarantee profile separation and logout discipline, a passwordless-only rollout can turn a convenient login method into a persistence mechanism for whoever used the machine last.
That is why teams should treat shared workstations as a distinct operating mode, with tighter session handling and stronger device-policy boundaries than personal endpoints. In practice, the device model has to decide who is allowed to start a session, how that session is isolated, and how the system returns to a clean state after each user.
What a safe deployment model needs
A workable shared-device model needs three properties: individual attribution, explicit revocation, and session separation. Individual attribution means each action still maps to one person, even if the hardware is shared. Explicit revocation means administrators can remove access quickly when a user leaves, a shift ends, or a device is reassigned. Session separation means one user’s sign-in does not become the next user’s starting point.
That usually means combining passkeys with a shared-device workflow rather than letting a browser or workstation cache the first successful sign-in. Teams should require a full user boundary, not just a convenient reauthentication prompt, because the real failure mode is inherited access state. A shared workstation should behave more like a controlled kiosk or shift-based endpoint than like a personal laptop.
For organizations that need more background on deploying phishing-resistant authentication, the Passwordless and Passkeys Guide covers rollout and recovery, while the Workforce Identity Security Guide is useful for understanding how passkeys fit alongside SSO, recovery and session controls.
Where shared workstations fail in practice
The main failure condition is not a weak passkey, it is leftover authenticated state. If the browser remembers a session, a platform authenticator remains available without a fresh boundary, or a user can close and reopen an app without re-authenticating, the workstation stops being shared in any meaningful security sense. At that point, the next user may be operating inside the previous user’s identity context.
Another common failure is over-trusting the device as a trust anchor. Passkeys can reduce phishing risk, but they do not fix poor workstation hygiene, poor logout behavior, or shared browser profiles. On communal devices, the organization has to decide whether the endpoint is truly single-user at a time, or whether the operational model needs stronger controls around sign-out, profile reset, and account switching.
Teams that want a broader operational framing can also look at the Healthcare Identity Security Guide, which includes shared-workstation patterns in high-consequence environments where user turnover and session cleanup are especially important.
Risk and Threat Considerations
Shared workstations create a higher chance of session inheritance, mistaken attribution, and unauthorized follow-on access. The security issue is not only account takeover, but also the possibility that one person can continue another person’s authenticated workflow if the device or browser state is not cleared correctly.
Failure mechanism: A passkey authenticates the right person, but the workstation preserves the wrong session, profile, or browser state, so the next user starts from an already trusted context.
Impact: Sensitive actions may be performed under the wrong identity, access may outlive the intended user, and revocation becomes harder because the device keeps part of the trust boundary alive after the person has left.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Shared-workstation passkey rollout depends on phishing-resistant auth and session handling guidance. |
| Recommendation — Apply phishing-resistant authenticator guidance and enforce clean session restart rules on shared endpoints. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkey deployment requires control over authenticator lifecycle, revocation and replacement on shared devices. |
| IA-2 — Identification and Authentication (Organizational Users) | Shared workstations need strong user authentication with preserved individual attribution. | |
| AC-11 — Session Lock | Shared workstation safety depends on session separation and preventing inherited access state. | |
| Recommendation — Manage authenticator lifecycle so shared-device access can be revoked and reissued cleanly. Require distinct user authentication so shared terminals do not collapse multiple users into one session. Enforce session lock and reauthentication between users to prevent inherited access on communal devices. | ||
| OWASP ASVS | V7 — Session Management | The core deployment issue is session isolation and cleanup between users on shared workstations. |
| Recommendation — Validate that sessions are isolated, expired and cleared when users change on shared devices. | ||
Practitioner Guidance
What to verify: Confirm that the workstation clears sessions, browser state, and app tokens between users, and that a new user cannot inherit prior authenticated context. If the device cannot prove that boundary, treat it as unsuitable for a blanket passkey rollout.
Decision rule: If the endpoint is truly communal, use a shared-device policy with explicit sign-out and reset behavior; if the endpoint is effectively assigned to one person per shift or session, you can support passkeys more naturally because ownership and attribution remain intact.
What good looks like: Each user signs in with their own passkey, the device returns to a clean state after logout, and administrators can revoke access without depending on the next user to “do the right thing.”
Practitioner takeaway: Passkeys are not the wrong control for shared workstations, but they only work safely when the device model preserves user boundaries as rigorously as the authentication method does.
Related resources from NHI Mgmt Group
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- How should security teams govern passkeys for shared application accounts?
- How should security teams implement identity controls for shared clinical workstations without slowing care?