How should security teams implement Zero Trust when users work everywhere?

Start by removing implicit trust from network location and replacing it with identity-based verification, device posture checks, and least-privilege access. Then make policy consistent across SaaS, cloud, VPN, and remote endpoints so the control model does not change when the user moves. The goal is continuous decision-making, not a one-time gate.

Why This Matters for Security Teams

zero trust only works when it follows the user, the device, and the workload across every access path. Once people move between office, home, cloud, and SaaS, location-based trust becomes a weak control because the network no longer tells the full story. NIST’s NIST SP 800-207 Zero Trust Architecture makes the core point clearly: trust should be continuously evaluated, not granted because a request comes from inside a perimeter.

For security teams, the practical issue is that remote work multiplies identity states. A single person may authenticate from a managed laptop, a personal mobile device, a browser session, and a VPN within the same day. That means policy must stay consistent across all of those channels, or users will find the least resistant path and controls will fragment. NHIMG’s Ultimate Guide to NHIs — Standards notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which reflects the same structural reality: Zero Trust is an identity problem first, not a network topology problem. In practice, many security teams discover this only after remote access exceptions have already become the default operating model, rather than through deliberate design.

How It Works in Practice

Implementing Zero Trust for distributed users starts with identity-aware access decisions, then adds device posture, session context, and least privilege. A user should prove who they are, the device should prove it is compliant, and the policy engine should decide whether the request is allowed at that moment. The decision should not depend on whether the request arrives through VPN, a browser, a SaaS app, or a direct cloud console.

Current guidance suggests building this around a central policy layer and consistent signals. That usually means:

• Using strong authentication with phishing-resistant methods where possible.
• Checking endpoint health, encryption status, patch level, and management state before granting access.
• Applying role and attribute based policy so access is limited to what the task needs.
• Re-evaluating session risk continuously, rather than only at login.
• Logging access decisions centrally so the same controls apply across SaaS, cloud, and remote endpoints.

Where this becomes stronger is when identity is paired with workload and device trust. For human users, that can include managed device certificates, conditional access, and short-lived tokens. For machine access behind the user, the same Zero Trust logic should extend to service identities and secrets governance, because users working everywhere often means applications and automations are also everywhere. NHIMG’s Guide to SPIFFE and SPIRE is useful here because it frames workload identity as a first-class trust primitive, which helps teams keep policy consistent when access moves from one environment to another.

Security teams should also treat network controls as routing, not trust. VPNs, ZTNA, and SASE can still be useful, but only if they feed the same policy engine and do not create separate trust exceptions. These controls tend to break down in hybrid environments where legacy apps cannot emit modern identity signals and access decisions fall back to coarse network allowlists.

Common Variations and Edge Cases

Tighter verification often increases user friction and policy overhead, requiring organisations to balance stronger assurance against operational speed. That tradeoff becomes most visible in contractors, bring-your-own-device programs, and legacy application estates, where device posture checks or modern token flows may not be fully available.

There is no universal standard for this yet, but current guidance suggests using graduated controls rather than a single hard gate. For example, low-risk actions may allow browser-based access with step-up authentication, while sensitive actions require managed devices, shorter session lifetimes, or explicit re-authentication. This is also where exception handling matters: if temporary access cannot be time-bound and reviewed, Zero Trust quietly turns back into implicit trust.

For globally distributed users, time zone, latency, and regional data rules can also shape policy. Access should remain consistent, but the enforcement point may differ by jurisdiction or app type. Teams should avoid overfitting the architecture to one access channel, because the moment users can reach the same resource through two different paths, attackers will test both. NIST’s Zero Trust model is strongest when every path is governed by the same policy intent, not when each platform invents its own version of trust.

Related resources from NHI Mgmt Group

• How should security teams implement zero-trust authorization for microservices?
• What do security teams get wrong about trust in zero-trust access models?
• What is the difference between zero trust for users and zero trust for NHIs?
• How should security teams implement zero trust IAM in cloud-native environments?