Device Compliance and Conditional Access

Plenty of tenants have device compliance policies. Fewer have a device trust model that actually changes what users can reach.

That gap matters. A compliant-looking device that still reaches SharePoint, Exchange, Teams, and admin portals after it has drifted or gone high risk is not much of a control.

The stronger model is joined-up:

• Intune defines compliance
• Defender for Endpoint contributes device risk
• Conditional Access enforces the outcome

That combination is what turns "device hygiene" into an access control.

Minimum useful setup

Control	Purpose
Enrollment or management state	Know which devices are in scope
Compliance policy	Define what healthy looks like
Defender for Endpoint integration	Add device risk signal
Conditional Access	Require compliant devices where it matters
Exception handling	Stop one awkward workflow from collapsing the whole model

That is the minimum bar. The rest is tuning.

Compliance checks worth defending

For Windows, start with controls that are clear and supportable:

1. Require BitLocker.
2. Require Defender Antivirus.
3. Require firewall.
4. Require supported OS version.
5. Require an acceptable Defender risk level.
6. Require recent check-in.
7. Mark noncompliance quickly enough that access decisions still mean something.

If you cannot explain why a check exists, you will struggle to defend the exception later.

The common failure pattern

The policy exists, but the protected apps do not actually require a compliant device.

That leaves you with a reassuring portal and a weak control. Users on unhealthy devices can still reach the services that matter most.

Another common problem is over-broad exclusions. One legacy app gets exempted, then the exemption quietly becomes the default path for half the business.

A practical access pattern

For normal user traffic:

App	Device requirement
Exchange Online	Require compliant device unless there is a named exception
SharePoint and OneDrive	Require compliant device for internal users
Teams	Keep aligned with the same device trust model
Admin portals	Compliant device plus strong MFA, no casual exclusions

You can add session controls or managed app requirements where licensing and use case justify them, but the first big win is getting device trust to matter consistently.

Why Defender risk changes the story

Intune can evaluate Defender risk as part of compliance. That matters because a device can still be encrypted and patched enough to look acceptable while actively carrying security issues that should block access until remediated.

That is the practical difference between static posture and live risk.

What good looks like

A good setup is easy to explain:

• which apps require a compliant device
• which risk level fails compliance
• who approves an exception
• how quickly access returns after remediation

If the answers are fuzzy, the control will be fuzzy too.

References

• Windows compliance settings in Microsoft Intune
• How to Require Device Compliance with Conditional Access
• Enable Conditional Access to better protect users, devices, and data