They should move the policy decision to a place the device cannot evade, such as the browser or endpoint interaction layer. If control depends on installing and steering a stack that the organisation does not own, enforcement will remain inconsistent and access governance will degrade.
Why unmanaged devices break legacy SASE enforcement
Legacy SASE controls usually assume the organisation can install an agent, enforce posture checks, or steer traffic through a managed path. When the device is unmanaged, that assumption fails. The control may still exist on paper, but the policy decision is now dependent on software and settings the organisation does not own, which makes enforcement inconsistent and hard to trust.
The practical issue is not just access, it is control placement. If policy is evaluated only after the device has already connected, the device can bypass or partially satisfy the check, especially when users switch browsers, networks, or endpoints. The answer is to relocate the decision to a layer that remains under organisational control, such as the browser session or endpoint interaction point.
That shift also changes what “good” looks like operationally. Instead of asking whether the unmanaged device is compliant enough to run a full stack, teams should ask whether they can still apply a stable, repeatable control point that does not depend on local administration rights, persistent agents, or reliable device posture telemetry.
Where enforcement should move instead
When the device cannot be trusted to host the control, the organisation needs a policy enforcement point that is closer to the session and less dependent on the endpoint. Browser-based control can preserve a usable experience while still keeping access decisions centralised. Endpoint interaction controls can do the same when the organisation can govern the session even if it cannot govern the whole device.
This is why remote-access and access-governance design matters. A control that depends on the user’s device behaving well is weaker than one that can make the decision at the point of use. NHIMG’s Remote Access Identity Guide is useful here because it connects device posture, ZTNA, MFA at entry points, and the retirement of brittle VPN assumptions.
In practice, this means choosing a control plane that can still evaluate identity, session context, and risk when the endpoint is unmanaged. The more the policy depends on local software installation or device ownership, the more likely it is that enforcement will drift into a best-effort model rather than a real control.
How to decide when to abandon device-dependent controls
Legacy SASE can still work for managed fleets, but unmanaged endpoint need a different rule. If the organisation cannot reliably install, update, or enforce the required stack, then the device should be treated as an untrusted access surface and the control should be moved up the stack. That is especially important when access governance, auditability, or conditional access must remain consistent across users and devices.
Browser-mediated access, session controls, and policy decisions at the interaction layer are usually better than relying on endpoint agents that users can remove, disable, or sidestep. The control should also be easy to measure: if you cannot show that every access attempt passed through the same enforcement point, the policy is already fragmented.
Where this becomes critical is third-party access, contractor access, or bring-your-own-device scenarios. In those cases, the organisation often has less control over patching, posture, and software inventory, so a device-centric model creates a hidden dependency on unmanaged local conditions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-16 — Security and Privacy Attributes | Browser or session-layer enforcement depends on centrally evaluated access attributes. |
| AC-2 — Account Management | Unmanaged-device access still needs consistent account governance and revocation. | |
| Recommendation — Use AC-16 to base access decisions on centrally controlled attributes, not endpoint trust alone. Use AC-2 to govern access consistently when devices are outside your management boundary. | ||
| NIST Zero Trust (SP 800-207) | N/A — Zero Trust Architecture | The question is about moving policy enforcement to a trusted control plane, a core ZTA pattern. |
| Recommendation — Apply zero trust principles to enforce decisions at the session and policy plane, not on the device. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The subject is access governance when endpoint control is unreliable. |
| Recommendation — Enforce access control centrally and remove reliance on unmanaged device state. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The answer concerns choosing an access control point that remains under organisational control. |
| Recommendation — Implement access control so policy decisions do not depend on unmanaged endpoints. | ||
Practitioner Guidance
What to prioritise: Move the decision point away from the unmanaged device and toward a browser or session layer that the organisation can actually govern. If the stack cannot be installed, maintained, or trusted locally, stop treating it as a reliable enforcement layer.
What to verify: Confirm that access policy is enforced consistently across unmanaged devices, not just during pilot flows or on the most cooperative browsers. Validate that revocation, step-up checks, and session controls still work when the endpoint is outside your administration boundary.
Common mistake: Teams often extend legacy SASE assumptions to BYOD and third-party access, then discover too late that “conditional” enforcement is really optional enforcement. The tell is inconsistent policy behaviour across browsers, device types, and user populations.
Practitioner takeaway: If the organisation cannot own the device, it must own the decision point. Stable access governance comes from controlling the session layer, not from hoping an unmanaged endpoint will reliably execute your policy.
Related resources from NHI Mgmt Group
- Should organisations support AI agent access on devices where the main VPN client cannot be installed?
- What happens when organisations try to support unmanaged devices without a unified access layer?
- How should healthcare security teams reduce identity risk on legacy medical devices that cannot support MFA?
- What should security teams do when legacy systems cannot support modern password controls?