How should security teams manage phishing-resistant hardware keys in shared-workstation environments?

Why This Matters for Security Teams

Shared-workstation environments change the threat model for phishing-resistant hardware keys. The key may still stop credential replay, but it does not solve the bigger problem of who can touch the workstation, which sessions remain open, or how quickly a token can be misused after handoff. Security teams should treat the key as one control in a governed access workflow, not as a standalone guarantee. That is especially important when local admins, kiosk users, and temporary staff all interact with the same device pool. Guidance from the NIST Cybersecurity Framework 2.0 remains useful here because identity assurance only works when paired with device, session, and recovery controls. NHIMG’s NHI Lifecycle Management Guide makes the same operational point: lifecycle governance matters as much as the factor itself. In practice, many security teams encounter misuse only after a shared terminal has already been used for session hijack, token extraction, or accidental handoff.

How It Works in Practice

The practical model is to reduce user discretion and increase central control. On shared workstations, that usually means assigning hardware keys through managed enrollment, not informal handover, and pairing the key with short session windows, remote revocation, and tightly scoped application allow-lists. The aim is to prevent the key from becoming a reusable privilege object that outlives the user’s shift or role. The NIST Cybersecurity Framework 2.0 supports this by tying identity proofing, access management, and recovery into the broader control environment, while the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows why lifecycle events such as issuance, reassignment, suspension, and offboarding must be explicit. A workable shared-workstation pattern usually includes:

• Named issuance or tightly controlled pool issuance, with each key mapped to a known user, shift, or duty station.
• Administrator-led revocation for lost, shared, or suspiciously used keys, with fast replacement paths so users are not tempted to bypass policy.
• Local session controls such as auto-lock, short idle timeouts, and blocked browser persistence on shared terminals.
• Application allow-listing so the workstation cannot be used to pivot into unrelated services after authentication.
• Central logging for key use, failed authentication, and abnormal re-authentication patterns.

This approach also aligns with the lifecycle emphasis in NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives, because shared-device access becomes an audit issue as soon as the organisation cannot prove who used the key, when, and for what purpose. These controls tend to break down in kiosk-heavy environments with frequent shift changes and weak endpoint management because the workstation itself becomes the easiest place to inherit access.

Common Variations and Edge Cases

Tighter hardware-key control often increases operational friction, requiring organisations to balance phishing resistance against user throughput and recovery time. There is no universal standard for every shared-workstation scenario, so current guidance suggests matching the control model to the environment rather than forcing a single pattern everywhere. For example, front-desk terminals, clinical stations, and contractor desks may need different key custody rules even when the same authentication standard is used. A few edge cases matter in practice. Break-glass accounts should not rely on the same shared key process as day-to-day users, because emergency access needs separate logging and approval. Kiosk modes can reduce persistence, but only if browser sessions, cached credentials, and local downloads are also tightly restricted. Where multiple users must share a device pool, the stronger approach is often to combine hardware keys with central session orchestration and rapid revocation rather than try to make the key itself do all the work. For the broader identity risk picture, NHIMG’s The State of Non-Human Identity Security is a useful reminder that control gaps usually show up in lifecycle and visibility, not just in authentication. Teams that over-trust the key alone tend to discover the gap only after an abandoned session or misrouted key has already been used to access a sensitive application.

Related resources from NHI Mgmt Group

• How should organisations roll out phishing-resistant hardware passkeys without overloading IT teams?
• Who is accountable for phishing-resistant authentication rollout when end users can self-order hardware keys?
• How should security teams govern third-party connections that rely on API keys and OAuth tokens in cloud environments?
• How should security teams prioritise NHI remediation in cloud environments?