How should security teams use conditional access to block risky devices?

Why This Matters for Security Teams

conditional access is only effective when it evaluates the device that is actually trying to connect right now. If policy is based on enrollment alone, a laptop that was compliant last quarter can still be compromised today and continue to receive access. That gap is especially dangerous for endpoints with stale operating systems, missing patches, or a failed security agent, because the device may still present valid user credentials while carrying a much higher compromise risk. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward continuous trust evaluation rather than static approval. NHIMG research also shows why this matters operationally: the Ultimate Guide to NHIs — Why NHI Security Matters Now highlights the scale of identity-driven risk across modern environments. In practice, many security teams discover risky devices only after access has already been granted and the incident response timeline has begun, rather than through intentional policy design.

How It Works in Practice

Effective conditional access policy should combine authentication context with live device signals. That means checking endpoint posture at session start and, where possible, during the session if the application and identity stack support re-evaluation. Security teams typically block access when one or more of these conditions are true:

• The operating system is end-of-life or outside support.
• The build level is below the approved security baseline.
• The endpoint protection or MDM agent is unhealthy, disabled, or missing.
• The device fails encryption, jailbreak, or compliance checks.
• The request comes from an unmanaged or unknown device class.

This approach aligns with the Top 10 NHI Issues because identity assurance is only useful when it reflects current state, not historical registration. For implementation, policy engines should be able to consume signals from endpoint management, EDR, and identity providers, then make a deny or step-up decision before the application session starts. That is where conditional access differs from simple MFA. MFA proves the user once; device posture proves whether the endpoint should be trusted at all. It is also consistent with 52 NHI Breaches Analysis, which reinforces how identity compromise often depends on weak control points rather than a single broken login. Where environments lack reliable device telemetry, this guidance breaks down because the policy engine cannot distinguish a healthy endpoint from one that is merely enrolled but operationally unsafe.

Common Variations and Edge Cases

Tighter device blocking often increases help desk load and can disrupt remote work, so organisations must balance stronger risk reduction against user friction and telemetry gaps. Best practice is evolving, and there is no universal standard for every device class. Managed corporate laptops can usually be enforced more aggressively than personal devices, contractor endpoints, or shared workstations. In BYOD scenarios, many teams use partial access, web-only access, or step-up authentication rather than a full deny rule when the device is unmanaged but the user context is otherwise low risk. Another edge case is offline endpoints: if a device cannot report current posture, a strict policy may treat it as non-compliant, which is safer but can block legitimate users during travel or outages. For teams adopting broader identity governance, the Ultimate Guide to NHIs remains useful as a reminder that access decisions should be tied to current trust signals, not one-time onboarding. The practical rule is simple: block when posture is known bad, step up when posture is uncertain, and avoid assuming enrollment means security.

Related resources from NHI Mgmt Group

• How should security teams use MDM to enforce conditional access?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams govern AI agents that use OAuth access?
• How should security teams implement Client ID Metadata Documents?