Passkeys break down on shared ward devices and shared accounts

At a glance

What this is: This is a passkey governance analysis showing that FIDO2 credentials designed for individual users can fail to map cleanly onto shared ward computers, shared accounts, and frontline device-sharing patterns.

Why it matters: It matters because IAM teams planning passwordless rollouts need to separate person-centric authentication from shared-device operations, or they risk deploying a strong factor into the wrong operating model.

Context

Passkeys and other FIDO2 credentials are often treated as a universal replacement for passwords, but the real control boundary is the identity model around them. In healthcare, the question is not whether the factor is strong, but whether it belongs to a single user, a shared workstation, or an account that multiple people touch in a shift.

Crayonic's analysis makes that boundary explicit: shared ward devices, shared operating-system accounts, and synced credentials all create different failure modes. Passwordless and Passkeys Guide is useful background because the article is really about where passwordless sign-in assumptions stop holding up.

Key questions

Q: How should teams deploy passkeys on shared workstations?

A: 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.

Q: Why do synced passkeys create governance problems for corporate accounts?

A: Synced passkeys can escape the organisation’s control when they land in a personal cloud account that IT cannot inspect or revoke. If that personal account is compromised, every synced credential inside it is exposed. In B2B, that shifts trust from corporate policy to a consumer platform, which weakens lifecycle control, offboarding, and incident response for access to production systems.

Q: What signs show passwordless controls are being used in the wrong context?

A: Watch for shared Windows accounts, multiple staff using the same sign-in profile, unclear ownership of enrolled credentials, and policies that assume a device is personal when it is actually communal. Those are strong indicators that the authentication model and the operating model no longer match.

Q: What should identity teams do when a passkey programme reaches frontline devices?

A: Reassess whether the device is dedicated, shared, or pooled, then align the credential type to that model. If the device is shared, treat the rollout as a governance decision about enrollment, recovery, revocation, and session handoff, not just a sign-in feature choice.

Technical breakdown

Why shared Windows PCs break per-person passkey assumptions

Windows Hello for Business is built around a credential bound to one person and one device. That works when the user and the machine move together, but it collapses on shared ward PCs where multiple staff members sign in across shifts. The practical problem is not the cryptography of the passkey, but the lifecycle of the workstation session, device enrollment, and account context. Once a computer becomes communal, the authenticator no longer maps cleanly to the person using it. See the Workforce Identity Security Guide. See the Workforce Identity Security Guide.

Practical implication: Treat shared PCs as a different authentication class and do not assume a per-person passkey model will survive multi-user rotation.

How synced passkeys shift the trust boundary from device to account

A synced passkey is not tied to the hardware in the way a device-bound credential is. It follows the cloud account that stores and synchronises it, which means the security question becomes who controls that account, who can revoke it, and what happens when the clinician leaves. In shared environments, that creates ambiguity between the device the person used and the identity provider that now owns the credential. The result is a governance problem, not just an authentication one. See the Passwordless and Passkeys Guide.

Practical implication: Govern synced passkeys as account-scoped credentials with explicit issuance and revocation rules, especially where staff move between devices.

Why roaming authenticators fit shared clinical devices better

Roaming authenticators change the model again because the credential travels with the person instead of being embedded in the workstation or account profile. That does not make them universally safer, but it aligns better with shared desktops, kiosks, and frontline tablets where the device is communal and the user is individual. The architectural point is that the authenticator must survive device turnover without inheriting the device's shared state. In healthcare, that is often the only model that preserves personal identity while leaving the workstation shared. See the Passwordless and MFA Buyer's Guide. See the Passwordless and MFA Buyer's Guide.

Practical implication: Use roaming authenticators where the device is shared and the user must still carry a unique, revocable credential.

Threat narrative

Attacker objective: The objective is to obtain usable access through identity ambiguity rather than by breaking the passkey itself.

1. Entry occurs when a shared workstation, shared account, or synced profile lets multiple users inherit the same sign-in context.
2. Credential abuse follows when the passkey is bound to the account or device rather than to an individual with a clear offboarding path.
3. Impact appears as session confusion, lingering access, and the inability to prove which person authenticated at the point of use.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared-device passkey risk is a governance mismatch, not an authentication failure: passkeys are being asked to solve a problem they were not designed to own. The central issue is that hospital workflows often treat the workstation as communal while identity controls still assume a stable person-device pair. Practitioners should read this as a boundary problem between authentication and operational access design.

Synced credentials create a hidden offboarding problem: when a passkey lives in a cloud account, revocation depends on knowing which account owns it and where it was enrolled. That breaks the assumption that removing a user from a local device or shared PC is enough to retire their access. The lesson is that passwordless programmes need account-level lifecycle control, not just enrollment success.

Ward computers expose the limits of device-centric assurance: a control that is excellent on a dedicated laptop can become ambiguous on a communal workstation where the next user inherits the same hardware trust. That is why the article's real concept is identity context drift, where the factor remains valid but the person using it changes. Practitioners should design for the context, not the token.

Passkey strategy must distinguish three operating models: dedicated corporate devices, shared devices, and account-synced consumer contexts are not interchangeable. The failure to separate them creates policy drift, because the same credential technology produces different governance outcomes in each model. The practical conclusion is that passwordless design has to start with device ownership and session ownership, not with the feature list of the authenticator.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Passwordless and Passkeys Guide

What this signals

Shared clinical devices force passwordless programmes to prove they can handle communal use, not just strong authentication. The most important design choice is whether the credential follows the person, the account, or the workstation, because those three models create very different offboarding and recovery obligations.

Identity context drift: this is the point at which a valid authenticator no longer proves a stable person-to-device relationship. In shared environments, the control boundary moves from the factor itself to the surrounding lifecycle, session and handoff rules, which means IAM teams need to design for use context before they design for convenience.

92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs, a reminder that credential governance fails quickly when ownership and lifecycle are unclear. The same governance discipline applies here: if you cannot name who owns the credential and when it must be revoked, passwordless will not stay orderly in a shared-device programme.

For practitioners

• Map passkey rollout by device ownership Classify endpoints as dedicated, shared, or kiosk-like before deciding where passkeys are acceptable and where they are not.
• Separate account lifecycle from device lifecycle Define who can enroll, revoke, and recover synced passkeys when the credential is attached to a cloud account rather than a local workstation.
• Prefer roaming authenticators for communal workstations Issue portable authenticators where many users share the same PC so the credential remains tied to the person, not the shared device.
• Decide what happens at session handoff Set a clear lock, sign-out, or re-authentication rule for when one clinician leaves and the next person sits down at the same machine.

Key takeaways

• Passkeys do not remove the need to model who owns the device, account, and session in a shared environment.
• Healthcare rollouts fail when a strong authenticator is applied to a communal workstation without a matching lifecycle model.
• The practical control question is whether the credential stays tied to one person long enough to remain governable.

Related NHI Mgmt Group resources: Workforce Identity Security Guide · Passwordless and Passkeys Guide · Passwordless and MFA Buyer's Guide

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Synced Passkey: A synced passkey is a FIDO credential that can be replicated across multiple devices through a cloud account and recovery system. It can improve usability, but it also shifts trust from a single device to the sync provider, recovery workflow, and account protections surrounding the credential.
• Roaming Authenticator: Roaming Authenticator is an authentication factor stored on a separate device or service that can be used across multiple systems and locations. It is attractive to attackers because compromise of the roaming factor can unlock many accounts. Defenders should protect enrolment, require device and user verification, and watch for unusual factor reuse.
• Shared Device Mode: Shared device mode is an operating pattern where multiple people use the same endpoint, often across shifts or locations. It changes identity assurance because the device is no longer a personal possession, so authentication, session reset, and offboarding must be designed for handoff.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.