Most organizations have compliance requirements for dozens of topics, spanning both technical and non-technical domains, as they are in a complex landscape of regulations, standards, and best practices to ensure the integrity, security, and conduct of their operations.

This post is just picking one technical subject out of it, which is related to Microsoft Intune 😉

What device compliance means

Before we can talk about device compliance, we need to open up the discussion on the "why" device compliance is important. Devices are:

  • Corporate assets
  • Access platform for organizational data
  • The stage for professional work
  • Interaction point of end user

As you see, devices are quite an important good and therefore need to follow compliance principles. From a technical view, we need to enforce settings and validate them. Important to know:

  • Configuration profiles or any other feature set
  • Compliance policies validate of what is set (they are read-only on the system)

Compliance in Intune

In Intune it is possible to create compliance policies for any OS that can be assigned to users or devices. They hold multiple configuration settings and rules of these scopes:

  • Custom Compliance - create own script that discovers settings
  • Device Health - Windows Health Attestation / Windows 11 Device health attestation
  • Device Properties - OS version and build
  • Configuration Manager Compliance - signals from SCCM in co-management scenario
  • System Security - Password, Encryption, Defender related settings
  • Microsoft Defender for Endpoint - Integration to include machine risk score

Once they evaluated the status on the device, the status of compliant or not compliant is reported back to Intune.


Don't forget that the same concept is also applicable to other OS. This post is focused on Windows.

What to do with device compliance?

We now understand the significance of compliance and how it integrates with Intune. So far, it's just showing us a signal and the current status, without doing anything else.


To use that signal to control something, we need to bring in another component: Conditional Access. See the architecture below:

Eventhough the compliance state can be used to allow access to resources, don't forget about Zero Trust.



  • Intune compliance policy
  • Conditional Access

Optional signal sources:

  • Microsoft Defender for Endpoint
  • ConfigMgr

Device compliance architecture

Take a look at the architecture and flows when devices are evaluated for compliance.

  • Intune applies and receives settings regarding compliance
  • The device compliance state can be used as a "grant control" in Conditional Access along with other signals
  • If prerequisites are met, Defender for Endpoint forwards a signal of machine risk score to Intune


Conditional Access

In combination with Conditional Access, device compliance can be used as a very powerful signal. "Require device to be marked as compliant" is the grant control, that correlates to the signal from Intune.

There are some common use cases to leverage the signal of a compliant device:

  • To register or modify personal security information
  • To access sensible applications
  • Establish Global Secure Access connection (preview)


  • Device is Entra ID registered
  • Device is Intune enrolled (to apply the policy)
  • Supported on Windows 10+, iOS, Android and macOS
  • Edge InPrivate mode is considered as "not compliant"
If you can not enforce device compliance (e.g. on unmanaged devices), consider mobile application management (MAM).

Device compliance policy for Windows

The following table shows my universal applicable and recommended settings in a compliance policy.

Setting Value Description
BitLocker Require Encryption
Secure Boot Require Verify integrity before booting
Code integrity Require Verify integrity of system files
Minimum OS version Latest OS version OS minimum requirement,
please note to continuously rise
Firewall Require Control network connections
Trusted Platform Module (TPM) Require Security chip on device
Antivirus Require System protection
Antispyware Require System protection against spyware
Microsoft Defender Antimalware Require System protection against malware
Microsoft Defender Antimalware security intelligence up-to-date Require Antimalware data up-to-date
Real-time protection Require Real-time system protection
Require the device to be at or under the machine risk score Medium Signal from MDE to consider machine risk score
The last setting "Require the device to be at or under the machine risk score" requires Defender for Endpoint (MDE) + connector enablement. Read more about the connection:
The bridge from Intune to Defender for Endpoint
Introduction This post is a straightforward tutorial to enable Defender for Endpoint with Intune. These two products live in the Microsoft ecosystem and can be natively integrated. It is a major advantage to connect your endpoint management product (Intune) with your XDR and security product (Defend…

Actions for noncompliance

Next you can configure what happens if a device is not fulfilling the settings from before.


It makes sense to create custom message templates/notifications. It depends from organization and workload how these should look and after how many days the user should receive such a mail.


Tenant compliance settings

Don't forget about the tenant-level compliance settings found at: Intune admin center>Devices>Compliance>Compliance policy settings


Setting Recommended value Description
Mark devices with no compliance policy assigned as Not compliant When a device has no compliance policy assigned, which compliance state it should get
Compliance status validity period (days) 7 Period of time in which the device must report the compliance settings status before it is considered as non compliant

Deployment plan

Just a quick and dirty deployment plan from the field:

  1. Define your scope
  • Target users and devices (managed/unmanaged)
  • Target OS
  • Required compliance settings
  1. Define Conditional Access integration
  2. Configure settings and create Conditional Access policy
  3. Assign on test group and pilot
  4. Inform end users
  5. Roll out (enable policy for all)


Organizations utilizing Intune should leverage its ability to enforce device compliance through profiles. In the Microsoft ecosystem, this signal can be seamlessly incorporated into Conditional Access, making it an important indicator. However, when implementing such controls, thorough testing and a staged rollout process are essential. Implementing at least a read-only policy can be beneficial. It's crucial to bear in mind that non-compliant devices may lose access to organizational data and apps in certain scenario. As a result, continuous monitoring of device compliance status is needed by an IT admin.

Want more? Read my post on Intune compliance: tips from the field

Intune compliance: tips from the field

Endpoint Management with Microsoft Intune
Ever wanted a full tutorial how to deal with Microsoft Autopilot Intune Technology? Well here it is!
You’ve successfully subscribed to Oceanleaf
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.