How should security teams enforce zero trust across managed and unmanaged devices?

Why This Matters for Security Teams

zero trust only becomes meaningful when the policy decision follows the user, device, and session everywhere access is attempted. That matters because managed devices can still be compromised, while unmanaged devices can be legitimate but untrusted. Security teams that rely on network location or a one-time login check often leave gaps in data access, privilege use, and session persistence. The practical standard is closer to continuous authorization than perimeter enforcement, which is the core direction of NIST SP 800-207 Zero Trust Architecture.

The challenge is not only whether a device is enrolled in endpoint management. It is whether the access request can be evaluated against current posture, identity assurance, application sensitivity, and session risk at the moment of use. That becomes especially important for SaaS, remote work, contractor access, and bring-your-own-device scenarios, where trust cannot be inferred from being inside a corporate network. In practice, many security teams encounter uncontrolled access only after a sensitive dataset has already been downloaded or a privileged session has already been established, rather than through intentional policy design.

How It Works in Practice

Enforcing zero trust across managed and unmanaged devices usually means placing the control point at the application, data, or identity layer rather than the network layer. A common pattern is to combine identity-based access, device posture checks, and session-level policy so that access can be allowed, limited, stepped up, or denied based on context. Managed devices may present stronger posture signals through EDR, MDM, or certificate-based trust. Unmanaged devices may be allowed only through browser-based access, restricted downloads, or read-only modes.

Security teams typically implement this as layered policy:

• Use strong authentication and conditional access tied to identity assurance.
• Check device posture where signals are available, such as encryption, OS version, or known risk state.
• Differentiate managed from unmanaged devices in policy rather than treating both as equally trusted.
• Limit what the session can do, including copy, download, print, and privileged admin actions.
• Re-evaluate risk during the session, not only at sign-in.

This is where NIST Cybersecurity Framework 2.0 is useful as an operational lens: identify what is being protected, protect it with access restrictions, detect abnormal use, and respond when context changes. Controls from NIST SP 800-53 Rev 5 Security and Privacy Controls also map cleanly to device trust, least privilege, session control, and auditability.

The strongest deployments also distinguish between user trust and device trust. A user may be well authenticated, but the device may be unmanaged, rooted, or outside acceptable risk thresholds. In that case, the policy should reduce access scope rather than simply blocking all use. These controls tend to break down when legacy applications require broad network reachability because the access model cannot be enforced at the application layer.

Common Variations and Edge Cases

Tighter device policy often increases user friction, requiring organisations to balance security assurance against operational flexibility. That tradeoff is most visible in contractor-heavy environments, merged IT estates, and regulated workflows where unmanaged access is necessary but must remain constrained.

One common variation is a split policy model. Managed devices get fuller access because the organisation can attest to posture, patching, and logging. Unmanaged devices receive limited access through browser isolation, app-specific gateways, or time-bound sessions. Current guidance suggests this is more defensible than a blanket allow or deny approach, but there is no universal standard for exactly how much access unmanaged endpoints should receive.

Another edge case is service access from non-traditional endpoints, such as shared kiosks, lab systems, or third-party support machines. In those environments, posture signals may be weak or unavailable, so the policy must lean more heavily on identity proofing, session constraints, and data-level controls. The same applies when a device is technically managed but is outside normal compliance due to stale telemetry or disconnected management tooling. Zero trust should not assume that management status equals current safety.

For teams building this into broader resilience and governance programs, the key question is whether access decisions remain defensible when device trust is partial, transient, or unavailable. That is the practical test of zero trust, not whether every endpoint is fully enrolled.

Related resources from NHI Mgmt Group

• How should K-12 teams enforce CIPA controls across managed and unmanaged devices?
• How should security teams implement zero trust access management across hybrid environments?
• How should teams unify zero trust controls across identity and device security?
• Who should own Zero Trust justification across security and IAM teams?