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.
How the device model changes the passkey decision
Frontline devices are not interchangeable just because they sit in the same rollout. A dedicated device can usually support a cleaner passkey posture because one person, one device, and one recovery path are easier to bind together. Shared and pooled devices change the question from “which authenticator is best?” to “who is allowed to enroll, recover, hand off, and revoke access on this endpoint?”
That distinction matters because passkeys are not only a sign-in method. They also create an enrollment and recovery lifecycle, and that lifecycle must match how the device is actually used. On a shared device, the safest design may be to keep the passkey bound to the right user relationship while preventing the device from becoming a convenient bridge between users, sessions, or leftover credentials.
Where the device is dedicated, the identity team can usually optimize for user convenience and phishing resistance. Where the device is shared or pooled, the same rollout needs explicit rules for registration, reauthentication, account recovery, and handoff between workers or shifts, otherwise the programme can accidentally encode the wrong trust assumption into a common endpoint.
What shared and pooled devices force you to govern
Shared devices introduce a governance problem because the sign-in event is only one part of the control story. You need a decision on whether the passkey lives with the person, the device, or the session, and that decision affects how you handle reset requests, device loss, end-of-shift cleanup, and the removal of stale access.
This is where identity teams should align the credential type to the operating model. Device-bound passkeys, roaming authenticators, and backup recovery paths can behave very differently on a shared terminal than they do on a personal laptop. If the device is used by multiple employees, the programme should avoid treating a successful login as proof that the next user can safely inherit the same state.
For frontline environments, the practical test is whether the endpoint can enforce a clean boundary between users. If it cannot, then enrollment and recovery become governance controls, not just help-desk conveniences. Workforce Identity Security Guide covers the identity-side controls that matter when passkeys, recovery, and session handling meet real-world workforce devices.
That same boundary concern shows up in the broader rollout path. Passwordless and Passkeys Guide is useful when you need to decide how passkey enrollment, secure recovery, and phishing resistance should work together instead of being treated as separate projects.
How to avoid turning rollout convenience into shared-device risk
The main failure mode is assuming that a passkey on a frontline device automatically improves security in every deployment model. In reality, a poorly governed shared device can create ambiguous ownership, weak recovery flows, and session carryover that defeats the point of stronger authentication. The right control is not only “can the user sign in?” but “can the organisation prove who can enroll, who can recover, and who loses access when the user changes?”
Identity teams should also be careful with lifecycle decisions that are easy to overlook during pilot success. If a pooled device is reset without a corresponding revocation step, if a recovery path bypasses the intended device model, or if session handoff is informal, the programme can leave behind access that no longer matches the operational reality. In frontline settings, that mismatch becomes a business continuity issue as much as an authentication issue.
When shared devices are in scope, the programme should be designed so that session release, credential revocation, and re-enrollment are all measurable outcomes. The goal is not just to deploy passkeys broadly, but to ensure that a worker leaving one device does not leave behind a trust relationship that the next worker can accidentally inherit.
Risk and Threat Considerations
Shared and pooled frontline devices increase the chance that a passkey programme will fail through lifecycle ambiguity rather than cryptographic weakness. The risk is credential misuse through poor handoff, incomplete revocation, or recovery processes that are too permissive for a multi-user endpoint.
Failure mechanism: A device is treated like a personal authenticator when it is actually shared, so enrollment, recovery, and session state are not tightly reset between users. That can leave access tied to the wrong person or allow the next user to inherit an active or recoverable trust path.
Impact: The organisation can end up with account misuse, unauthorized access after shift change, failed offboarding, or support processes that silently undermine the intended passkey model.
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 technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys, phishing-resistant auth and recovery choices map directly to digital identity assurance. |
| Recommendation — Use 800-63 passkey guidance to align authenticator choice, assurance and recovery with the device model. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkeys require controlled enrollment, storage, rotation and revocation on shared frontline devices. |
| IA-2 — Identification and Authentication (Organizational Users) | Frontline workforce sign-in decisions depend on how organizational users authenticate on shared devices. | |
| Recommendation — Manage passkey lifecycle so shared-device enrollment and revocation remain controlled. Apply organizational-user authentication controls that fit the frontline operating model. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Device-sharing changes the access control model for enrollment, recovery and session handoff. |
| Recommendation — Define access rules that reflect whether frontline devices are dedicated, shared or pooled. | ||
| OWASP ASVS | V6 — Authentication | Passkey rollout is an authentication design problem with recovery and binding decisions. |
| Recommendation — Verify authentication flows and recovery paths against the intended device-sharing model. | ||
Practitioner Guidance
What to prioritise: Decide first whether the frontline endpoint is dedicated, shared, or pooled, then set the credential pattern from that decision rather than retrofitting the device model after rollout. That choice should determine who can enroll, who can recover, and what happens at handoff.
What to verify: Confirm that revocation really removes the previous user’s practical access on the device, that recovery cannot recreate access without the right governance step, and that session handoff does not preserve leftover authentication state across users.
Decision rule: If the device can be used by more than one person in a normal shift, treat the passkey programme as an access-governance change with lifecycle controls, not as a simple authentication upgrade.
Practitioner takeaway: On frontline devices, passkeys succeed or fail on lifecycle control, not on sign-in UX. The stronger the sharing model, the more important it is to govern enrollment, recovery, revocation, and session handoff as one system.
Related resources from NHI Mgmt Group
- How should security teams handle identity verification on shared devices in frontline environments?
- How should healthcare IT teams structure an identity and access programme around shared devices, third-party access, and passwordless authentication?
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org