NIST zero trust breaks down when shared devices hide users

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OLOID's blog post: NIST zero trust architecture can misattribute activity on shared devices when user handoffs outpace identity verification and session controls.

Why it matters: This matters because IAM and zero trust programmes must distinguish endpoint health from user identity, especially in frontline environments where the wrong person can inherit a live session.

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.

Context

Zero trust depends on verifying the current requester, not just the endpoint they are using. In shared-device environments, that distinction breaks down because the terminal can look compliant while the person behind it changes from shift to shift.

That failure mode is common in frontline settings such as plants, hospitals, warehouses, and retail counters, where a session can outlive the worker who opened it. NIST SP 800-207 provides the architecture, but operational reality demands stronger user handoff controls and tighter session boundaries.

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. Use strong user authentication, device compliance checks, short session lifetimes, local profile separation, automatic sign-out, and strict app-level access controls so one user’s session, tokens, and cached data do not carry over to the next user.

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. When access policy reflects security state, organisations can restrict sensitive resources to devices that remain compliant and better aligned with policy. That reduces the chance that a compromised or unhealthy endpoint keeps access simply because it was trusted earlier in the day.

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. In zero trust, they make MFA far harder to bypass, lower the value of stolen passwords, and support stronger conditional access decisions for human identities and privileged accounts.

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.

Technical breakdown

How the policy engine uses identity and context signals

In NIST zero trust architecture, the policy engine does not simply ask whether a device is managed. It evaluates a bundle of signals, including identity assurance, endpoint posture, behavioural anomalies, resource sensitivity, and threat intelligence, then decides whether the request should be allowed, denied, or re-evaluated. The policy administrator carries out that decision, while the policy enforcement point applies it at the moment of access. The model only works when the requester can be distinguished from the device with enough confidence to support the decision. See the NIST SP 800-207 Zero Trust Architecture Guide.

Practical implication: Treat user verification as a first-class input to the decision path, not as a side effect of device compliance.

Why shared devices weaken zero trust assumptions

Shared terminals expose a structural weakness in zero trust deployments because the device can remain healthy while the human session changes. That creates a mismatch between the posture data the policy engine sees and the actual person using the resource. In shift-based workflows, session persistence, delayed reauthentication, and poor handoff discipline can all leave the wrong user operating under the previous user’s trust context. The architecture does not fail because zero trust is wrong; it fails because the operating model still assumes one stable user per session. See the Zero Trust Identity Guide.

Practical implication: Design the enforcement layer for handoffs, not for long-lived individual sessions on fixed endpoints.

Why stronger authenticators matter at higher assurance levels

NIST SP 800-63-4 raises the bar as assurance increases, and that matters because zero trust depends on the quality of the identity signal at the start of each decision. At AAL2, systems need a phishing-resistant option, and at AAL3 the authenticator must use a non-exportable key. Passwords, SMS-based flows, and weaker push patterns do not give the policy engine enough confidence for high-risk access, especially where devices are shared and the person using the terminal can change without warning.

Practical implication: Map higher-risk shared-device workflows to phishing-resistant authentication before they enter the zero trust policy path.

NHI Mgmt Group analysis

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.

The policy engine is only as strong as the weakest identity signal it receives. If the system relies too heavily on endpoint posture, it will overvalue device health and underweight user verification. OLOID’s guide reinforces a point NHIMG sees repeatedly: zero trust fails when teams assume a compliant device is a verified user. Practitioners need to separate the evidence for the endpoint from the evidence for the human, then require both where the workflow demands it.

Phishing-resistant authentication becomes a zero trust control, not just an MFA preference. NIST SP 800-63-4 raises assurance expectations because stronger authentication changes the quality of the trust decision itself. In shared-device workflows, that matters even more because the credential check must survive frequent handoffs and short sessions. Practitioners should treat authenticator strength as part of the access architecture, not as a user convenience decision.

One-user-one-device assumptions are no longer reliable in operational environments. The classic desktop model does not fit plant floors, nursing stations, warehouse scanners, or POS terminals. Those environments need session discipline, rapid reauthentication, and audit separation that reflect human turnover rather than device ownership. NHI Mgmt Group’s view is that zero trust programmes that ignore shared-device realities will keep stalling at the point where frontline work begins.

Identity telemetry has to follow the session, not just the device. Signal sharing across identity, endpoint, and analytics tools is not optional when access decisions are reevaluated continuously. The practical lesson is that zero trust should be designed around per-action evidence and handoff events, because that is where the real governance gap appears. Practitioners should make shared-device signals visible to the same policy layer that makes the access decision.

From our research library:

• 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.
• Read next: Zero Trust Identity Guide

What this signals

Shared-device zero trust will force identity teams to redesign the handoff, not just the login. The practical shift is from trusting a session once and watching the device thereafter to re-establishing who is present whenever control changes hands. That is a programme design issue as much as a control issue, especially where frontline operations depend on speed.

Identity assurance has to rise with the operational risk of the workflow. In environments where people rotate through the same terminal, stronger authenticators and tighter session lifecycles become the difference between accountable access and attributed noise. Zero trust programmes that stop at managed-device compliance will miss the point of the control.

NIST zero trust architecture works best when the policy layer sees both the device and the person as separate evidence streams. Without that separation, a healthy endpoint can hide an unverified user, which weakens auditability and response. Practitioners should plan for signal sharing across identity and endpoint tools from the start.

For practitioners

• 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. Set different policy expectations for those endpoints because the normal one-user model does not hold.
• Require reauthentication at every handoff Use session termination, lock, or prompt-based re-verification whenever a worker steps away or a shift changes. Keep the control at the policy enforcement point so the next user cannot inherit the previous session.
• 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. Weak MFA options should not feed high-assurance decisions.
• Separate endpoint posture from user identity evidence Make sure policy engines receive both device health and current-user assurance before access is granted. A compliant terminal should never be treated as proof that the correct person is present.

Key takeaways

• Shared-device environments expose a gap in zero trust designs because device compliance can mask a change in the human user.
• The article’s example and NIST’s implementation guidance both point to the same issue: identity evidence must survive handoffs, not just login.
• Practitioners should prioritise reauthentication, session termination, and stronger authenticators wherever one terminal serves many workers.

Related NHI Mgmt Group resources: NIST SP 800-207 Zero Trust Architecture Guide · Zero Trust for AI Agents · Zero Trust Identity Guide · Top 10 Zero Trust Mistakes

Key terms

• Zero Trust Architecture (ZTA): Zero Trust Architecture is a security model that assumes no user, device, workload, or network path should be trusted by default. It continuously verifies identity, context, and policy before allowing access, using least privilege, strong authentication, and segmentation to reduce blast radius and limit lateral movement.
• Policy Engine: A policy engine evaluates identity, device, and transaction data against defined rules and then automates the access decision. It is the mechanism that turns zero trust from a concept into an operational control by allowing approval, blocking, quarantine, or revocation based on risk.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Authentication Assurance: The degree of confidence that an identity has been verified to the intended standard before access is granted. For MFA, assurance depends on the whole enforcement chain, including session handling, retry policy, and telemetry, not merely the presence of a code prompt.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.