Topic starter
06/11/2026 6:38 pm
TL;DR: NIST zero trust architecture can misattribute actions when shared devices, shift changes, and weak authentication let one user inherit another’s session, and SP 1800-35’s implementation patterns still depend on strong identity signals, according to OLOID’s guide. The assumption that a device posture check can stand in for a verified person collapses in frontline environments.
Editorial analysis by NHI Mgmt Group, based on content published by OLOID: “NIST Zero Trust Architecture: A Practical Guide”.
By the numbers:
- 63% of organisations have fully or partially implemented a zero trust strategy, but for most respondents the strategy covered half or less of their environment.
Key questions
Q: How should teams secure shared devices in a zero trust architecture?
A: Secure shared devices by treating the device as untrusted until it is individually attested, hardened, and revalidated at each use.
Q: Why do device posture scores matter for access control in Zero Trust environments?
A: Device posture scores matter because they turn endpoint health into an actionable control decision.
Q: How do phishing-resistant authenticators change zero trust risk?
A: Phishing-resistant authenticators reduce account takeover by binding login to a device or cryptographic factor that cannot be replayed from a fake login page.
Practitioner guidance
- Define shared-device workflows as a separate zero trust use case Inventory every environment where multiple workers use the same terminal, including plants, hospitals, warehouses, and retail counters.
- Require reauthentication at every handoff Use session termination, lock, or prompt-based re-verification whenever a worker steps away or a shift changes.
- Move high-risk access to phishing-resistant authenticators Prioritise workflows that protect sensitive resources or regulated actions and bind them to stronger authenticators such as passwordless methods or non-exportable keys.
Bottom line: Shared-device environments expose a gap in zero trust designs because device compliance can mask a change in the human user.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Shared-device zero trust exposes an identity continuity problem, not a network trust problem. The core issue is that the policy engine can be given a healthy endpoint and still miss the fact that the person using it has changed. That is why frontline environments can look compliant while the action trail belongs to the wrong worker. Practitioners should treat identity continuity across handoffs as a governance requirement, not a deployment detail.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
A question worth separating out:
Q: What should teams do first when users share the same workstation?
A: Start by separating the user session from the device session. Require unique user authentication, then enforce automatic lock, logout on switch, and per-user profiles or virtual desktops so credentials, browser sessions and local data do not bleed between people. If privileged access is involved, add PAM checkout and session recording.
👉 Read our full editorial: NIST zero trust breaks down when shared devices hide users