How should teams secure shared devices in a zero trust architecture?

Why shared devices need a stricter zero trust pattern than personal endpoints

Shared devices break the assumption that the next person using the device should inherit anything from the previous user. In a zero trust architecture, that means access must be re-evaluated at every use, not trusted because the device was compliant earlier in the day. The practical goal is to keep the device useful while preventing session carryover, cached data reuse, and accidental cross-user exposure.

This is why the device itself, the user session, and the application access path all need separate controls. A compliant posture at login is not enough if the browser profile, local tokens, or application state survive sign-out. Shared devices are most safely handled as short-lived access environments with aggressive cleanup between users.

For the broader zero trust model, NHIMG’s NIST SP 800-207 Zero Trust Architecture Guide is a useful reference point because it ties device trust to policy enforcement, continuous verification, and reduced implicit access.

How to reduce cross-user leakage on kiosks, tablets, and shared PCs

The strongest control pattern is to combine identity checks with device-state checks and then force the session to end cleanly. That usually means phishing-resistant or strong user authentication, device compliance or attestation, automatic sign-out, and a profile model that prevents one user from inheriting another user’s cookies, documents, cached sessions, or browser state. If the platform supports it, shared-device mode or kiosk mode should limit local persistence by design.

Application scope matters as much as device scope. Teams should prefer app-level conditional access, per-app sign-in where possible, and restricted browser access over broad desktop sessions. If the user only needs one line-of-business app, do not expose the full desktop environment unless that is operationally necessary. The fewer local surfaces the device exposes, the less cleanup the next user depends on.

For device posture and compliance decisions, Device Trust and Posture Guide and Kiosk and Shared Device Security Guide both reinforce the same operational point, that access should depend on current device state and shared-device controls, not just on a successful login.

What to design for when users rotate quickly across the same device

The hardest part of shared-device security is not the first sign-in, but the handoff. Session lifetime has to be short enough that stale access does not survive a shift change, while logout must actually clear the active session, local profile data, and app caches that could reveal data to the next user. Where mobile or frontline workflows are involved, device re-enrolment, local account separation, and mandatory re-authentication between users are often more important than adding another control at the network edge.

Teams also need a recovery path for interrupted sign-outs, locked sessions, and power-loss events. A shared device that resumes into the previous user’s context is a security failure even if the endpoint remains technically compliant. Auditability matters too: you want to know which user held which session on which device, and whether the device was actually cleared before the next use.

Passwordless for Frontline and Shared Devices Guide is especially relevant here because it addresses the real-world handoff problem on shared tablets, handhelds, and PCs, while Passkeys for Everyone Guide provides useful context for shared-device sign-in flows and the practical limits of synced credentials.

Risk and Threat Considerations

Shared devices create a concentrated exposure point because one failure can affect many users in sequence. If sign-out is weak, profiles are not isolated, or cached tokens survive the handoff, the next user may gain unintended access to data, apps, or active sessions. In a high-churn environment, that can turn a modest configuration mistake into repeated cross-user disclosure.

Failure mechanism: The device, browser, or app retains authenticated state after the user leaves, so the next person inherits a live session or recoverable local data. Attackers do not need a sophisticated exploit if the environment itself leaks access across users.

Impact: Cross-user data exposure, unauthorized actions under the prior user’s context, and harder incident containment because the compromise path is built into the shared workflow rather than into a single account.

Practitioner Guidance

What to verify: Confirm that sign-out actually clears browser cookies, local app caches, downloaded files, and any resident profile data. If a user can reopen the device and see traces of the previous session, the control is not working well enough for production use.

Decision rule: If the device cannot reliably isolate users at the local layer, treat it as a restricted-access kiosk rather than a general-purpose endpoint. Narrow the app set, shorten session duration, and prefer managed shared-device modes over ad hoc desktop logins.

Practitioner takeaway: Shared-device security succeeds when the handoff is engineered, not trusted. The key question is whether every user starts from a clean, revalidated state, with no durable session or data carryover from the person before them.

Related resources from NHI Mgmt Group

• Zero Trust Architecture (ZTA)
• Trust Architecture
• Why do OT devices complicate zero trust architecture?
• How should OEMs build a zero trust architecture for connected devices from the start?