What should security teams check before enforcing passkey policy on shared devices?

They should confirm browser support, authenticator capabilities and whether the workforce is using synced or device-bound credentials. Shared devices expose weak assumptions quickly, especially when policy relies on features that only certain browsers or key types support. If the rollout target is a hospital workstation, the client mix matters as much as the identity policy.

What needs to be true before passkeys work on a shared device?

Before enforcing a passkey policy on shared devices, security teams should verify the browser path, the authenticator types available on that device class, and whether the rollout assumes synced passkeys or device-bound credentials. Shared endpoints are where hidden assumptions break first, especially when the browser or operating system mix is not uniform across locations or shifts.

That check matters because the same policy can behave very differently on a kiosk, a hospital workstation, or a frontline tablet. A device may technically support passkeys but still be a poor fit if the user experience depends on personal devices, private profile storage, or recovery steps that do not survive user handoff.

How synced and device-bound passkeys change the rollout decision

Passkeys are not one uniform control. Synced passkeys can improve usability on shared estates, but they also change where credential state lives and how recovery works. Device-bound credentials reduce portability, which can be helpful on shared endpoints, but they can also introduce enrollment and reset friction if the workforce moves between terminals or locations.

For shared-device policy, the key question is whether the passkey model matches the operating pattern. If a worker signs into different shared endpoints during the same shift, a control that assumes one stable device may create lockouts or force workaround behavior. If the endpoint is purpose-built and tightly managed, device-bound authentication may be a better fit, provided the browsers and authenticators are consistent.

That is why the rollout target matters as much as the credential type. A passkey policy that works on office laptops can fail on shared hospital workstations if the browser stack, profile handling, session clearing, or authenticator choice does not line up with the real workflow.

What shared-device teams should validate before enforcement

Security teams should validate support at three layers: the browser, the authenticator, and the operating model. The browser must support the passkey flow the organization intends to use, the authenticator must be available in the form expected by policy, and the device model must support sign-in, sign-out, and session clearing without exposing the next user.

Teams should also confirm how recovery will work when a passkey is unavailable. Shared devices often create edge cases around lost sessions, expired enrollment, and user switching, so recovery paths need to be operationally realistic and not dependent on the same shared endpoint staying available. If the policy cannot tolerate those edge cases cleanly, the rollout is not ready.

Finally, the control should be tested against the exact client mix in production, not only in a clean lab. Different browser versions, managed profiles, and local restrictions can change whether passkey prompts appear, whether synced credentials are accessible, and whether users can complete sign-in without extra support load.

Risk and Threat Considerations

Shared devices make bad assumptions visible fast, and passkey enforcement can fail in ways that create lockouts, help desk pressure, or informal bypasses if the client environment is not verified first. The biggest risk is not the passkey itself, but enforcing a policy that only works on a subset of browsers or authenticator types.

Failure mechanism: The organisation treats passkey support as uniform when the actual device fleet is heterogeneous, so users on unsupported browsers, mismatched authenticators, or incompatible shared-device configurations cannot complete authentication reliably.

Impact: Users either fail to sign in, fall back to weaker exceptions, or pressure teams to keep legacy authentication alive longer than planned, which weakens the policy and increases operational risk.

Practitioner Guidance

What to verify: Confirm the exact browser, OS and authenticator combinations used on the shared-device estate before enforcement. If the rollout is for a kiosk or shift-based workstation, test the full sign-in and sign-out path on those endpoints, not just on standard desktops.

Decision rule: If the device class cannot reliably support the intended passkey mode end to end, delay enforcement or scope the policy to the subset of endpoints that do meet the requirement. Do not rely on exceptions as the primary deployment model.

What practitioners underestimate: Shared devices turn recovery, session clearing and user switching into first-order design issues. A passkey deployment that is technically correct but operationally awkward will often be undermined by manual workarounds long before it fails in a formal security review.

Practitioner takeaway: Enforce passkey policy only after you have proven that the real shared-device client mix can support the chosen passkey model without breaking sign-in, recovery or user handoff.

FRAMEWORK_REFS—
[{“framework_code”:”NIST-800-63″,”control_ref”:”null”,”control_ref_label”:”Digital Identity Guidelines”,”relevance_note”:”Passkey assurance and authenticator support are central to this sign-in decision.”,”framework_summary”:”Align shared-device passkey rollout with the authenticator and assurance guidance in SP 800-63.”},{“framework_code”:”NIST-800-53″,”control_ref”:”IA-5″,”control_ref_label”:”Authenticator Management”,”relevance_note”:”Passkey rollout depends on managing authenticators, recovery and lifecycle on shared endpoints.”,”framework_summary”:”Verify authenticator lifecycle and recovery handling before enforcing passkey policy.”},{“framework_code”:”NIST-800-53″,”control_ref”:”IA-2″,”control_ref_label”:”Identification and Authentication (Organizational Users)”,”relevance_note”:”Shared-device workforce sign-in is an organizational-user authentication problem.”,”framework_summary”:”Validate that organizational-user authentication works across the shared-device fleet.”},{“framework_code”:”ISO-27001″,”control_ref”:”A.5.15″,”control_ref_label”:”Access control”,”relevance_note”:”Shared-device passkey policy is an access control decision tied to allowed sign-in paths.”,”framework_summary”:”Define and enforce access rules that match the supported shared-device authentication model.”},{“framework_code”:”OWASP-ASVS”,”control_ref”:”V6″,”control_ref_label”:”Authentication”,”relevance_note”:”Passkey enforcement is an authentication implementation question with device-specific constraints.”,”framework_summary”:”Test the authentication flow on the actual supported browsers and device types before rollout.”}]
—TERM_META—
{“domain”:”Auth”}