Implementing Device Compliance with Microsoft Intune
Device compliance is one of the most important pieces of your Microsoft 365 and Intune security strategy. It tells you which devices are healthy, which are risky, and which should be blocked from accessing company data.
In Intune, device compliance works hand in hand with Conditional Access. Compliance policies decide whether a device is healthy; Conditional Access decides what that device is allowed to reach (Exchange Online, SharePoint, Teams, line-of-business apps, etc.).
This post walks through:
- What a compliance policy is
- How the default compliance policy behaves
- Which settings you can use to define “healthy”
- How to configure actions for non-compliance
- How to monitor and review compliance state in the Intune admin center
- How often different platforms check in
What is a compliance policy?
A compliance policy in Intune is a set of rules that define what a “healthy” device looks like in your organization. It answers questions like:
- Does the device have disk encryption enabled?
- Is Secure Boot turned on?
- Is the OS supported and up to date?
- Is antivirus running and up to date?
- Does Defender for Endpoint see this device as low-risk?
A compliance policy has three main parts:
- Compliance settings – the rules (encryption, OS version, Defender status, etc.).
- Actions for non-compliance – what happens when a device fails those rules.
- Assignments – which users or devices the policy applies to.
You can create policies for:
- Android (including Android Enterprise)
- iOS and iPadOS
- macOS
- Linux
- Windows 10 and later (including Windows 11)
- Windows 8.1 and later (still supported, though you should move away from it)
The default compliance policy – and the big gotcha
Every Intune tenant has a built-in default compliance policy. You can’t delete it, but you can configure two very important settings:
- “Mark devices with no compliance policy assigned as”
- Compliant or Non-compliant
- Validity period (in days)
- How long the last successful check-in remains valid.
- Default is 30 days.
Why this matters
If you:
- Turn on a Conditional Access policy that requires “Device must be marked as compliant”, and
- Leave the default compliance status as Non-compliant, and
- Have no actual compliance policies assigned
…you have just locked out all enrolled devices.
To avoid this, many admins initially set:
- Mark devices with no compliance policy assigned as: Compliant
That lets you roll out Conditional Access safely while you build and assign proper compliance policies. Once your real policies are in place and broadly assigned, you can reconsider this setting.
How the default policy evaluates devices
A device is deemed compliant with the default policy if:
- An enrolled user exists for the device.
- The device has at least one compliance policy assigned.
- The device is active and checks in within the validity period.
In other words: user + policy + recent check-in.
Standard compliance settings you can use
When you create a compliance policy, Intune gives you several categories of settings.
1. Custom compliance
Custom compliance lets you go beyond the built-in options.
You can:
- Write a script (for example, PowerShell for Windows) that checks anything you care about:
- Specific firmware versions
- Presence of certain files or applications
- BIOS settings
- Hardware attributes
- Upload the script to Intune as a custom compliance script.
- Use the script’s output to mark the device as compliant or non-compliant.
This is powerful when you have very specific security or hardware requirements that Intune doesn’t expose directly.
2. Device health
For Windows devices, device health settings use Microsoft’s attestation services and low-level platform protections.
You can require things like:
- BitLocker on the OS drive
- Secure Boot
- Code integrity / boot integrity checks
These features help protect the device from rootkits, bootkits, and offline disk attacks. Most modern Windows 10/11 devices support them and often have them enabled already.
3. Device properties
Here you can restrict devices based on:
- OS platform and version
- Specific builds or editions you want to support or block
Example: block devices running Windows 10 versions that are out of support.
4. Configuration Manager state (for hybrid/co-managed devices)
If you’re in a hybrid environment with Configuration Manager (ConfigMgr):
- You can use ConfigMgr to contribute a “statement of health”.
- Intune can read that health state for co-managed or hybrid-joined devices.
This lets you reuse existing on-prem checks as part of your cloud compliance logic.
5. System security
This is where a lot of the real work happens. Typical settings include:
- Password requirements
- Require a password or PIN
- Minimum length, complexity, expiration
- Encryption
- Device must be encrypted
- Firewall
- Require the OS firewall to be enabled
- Trusted Platform Module (TPM)
- TPM must be present (already required for Windows 11 PCs)
- Antivirus and antimalware
- Require Microsoft Defender Antivirus
- Require antivirus and antispyware to be enabled
- Require real-time protection
- Require virus definitions to be up to date
If you’ve deployed Microsoft Defender for Endpoint (MDE), you can also:
- Require a minimum machine risk score, such as Low or better.
This means:
- If Defender for Endpoint flags the device as Medium or High risk, it becomes non-compliant.
- Conditional Access can then block that device from accessing sensitive resources until the risk is remediated.
Actions for non-compliance
Once you define what “healthy” looks like, you decide what happens when a device fails.
Typical actions:
- Mark device as non-compliant
- This is automatic and immediate.
- By itself, it does not block access. It just sets the flag that Conditional Access can use.
- Send email to the user
- Uses a notification template you define.
- You can include:
- Company logo
- Contact details for IT or the help desk
- Links to support documentation or self-service guides
- You can send it immediately or after a certain grace period.
- Notify additional recipients
- Line managers
- IT support teams
- Security operations
- Add device to a retire list
- Often after a delay (for example, 2 days after non-compliance).
- Retiring a device:
- Removes it from Intune management
- Wipes corporate data from the device
Paired with Conditional Access, these actions let you:
- Warn users early
- Give them time to fix issues
- Escalate and eventually remove corporate data if they ignore the warnings
Creating a Windows compliance policy in Intune
Here’s a simplified walkthrough based on Windows 10/11.
- Go to the Intune admin center → Devices → Compliance.
- Click Create policy and choose Windows 10 and later.
- Give the policy a clear name, e.g.
Sales – Windows Compliance. - Configure settings:
- Custom compliance (optional):
- Upload your script and mark it as required if you’re using one.
- Device health:
- Require BitLocker (if applicable).
- Require Secure Boot.
- Require code integrity checks.
- Device properties:
- Set minimum OS version, or block unsupported versions.
- System security:
- Turn on password requirements.
- Require encryption, firewall, TPM, antivirus, antispyware.
- Ensure Defender AV is up to date and real-time protection is on.
- Microsoft Defender for Endpoint (if deployed):
- Require machine risk score of Low or below, for example.
- Custom compliance (optional):
- Configure Actions for non-compliance:
- Keep “Mark device non-compliant immediately”.
- Add:
- Send email to end user (using your notification template) after 0–1 days.
- Add device to retire list after a longer period (for example, 2–7 days).
- Add Scope tags if you use RBAC so only certain admins can manage this policy.
- Configure Assignments:
- Assign to all users/devices, or
- Target specific Azure AD groups (for example,
Sales – Windows Devices). - Use exclusions if you take a broad “all devices” approach but want to leave out certain groups.
- Review and click Create.
From now on, assigned devices will be evaluated against this policy in addition to the default policy.
Notification templates and end-user customization
To keep user emails consistent and branded, you can configure templates.
- In Intune, go to Tenant administration → Customization.
- Add:
- Company logo
- Friendly company name
- Support email / phone
- Helpful URLs (self-service portal, help pages)
- Then go to Devices → Compliance → Notifications and create a new notification template:
- Give it a name, e.g.
Contoso – Non-compliant device notice. - Choose the language (e.g. English – United States).
- Set a subject, e.g. “Your device is not compliant with company policy.”
- Write a clear, short message explaining:
- What “non-compliant” means
- What the user should do next
- Give it a name, e.g.
- Save it and use the Send preview email option to test it.
This template can then be used in your compliance policies’ actions for non-compliance.
Reviewing compliance state in the Intune admin center
You have several ways to see how things are going.
High-level overview
- On the Home page, you’ll see a card such as Devices not in compliance.
- On the Dashboard, you’ll see a Device compliance tile with a basic breakdown.
These give you a quick health check.
Per-device view
- Go to Devices → Windows (or another platform).
- Select a device, e.g.
Contoso-Adele. - Open Device compliance.
Here you’ll see:
- Which policies apply to the device.
- Whether it’s compliant or non-compliant for each policy.
- What each policy is requiring (for example, BitLocker, Secure Boot, Defender risk score).
If a device shows as non-compliant, this is the place to start troubleshooting.
Non-compliant and retire lists
Under Devices → Compliance, you’ll find views for:
- Non-compliant devices
- Retire non-compliant devices
From here you can:
- Investigate why devices are failing.
- Clear or run retirement actions.
Reports
In Reports → Device compliance, you get more detailed reporting, including:
- Number of devices in each compliance state
- Trends over time
- Breakdown by policy or platform
Compliance severity states
Behind the scenes, Intune assigns severity values to compliance state:
- Unknown – policy not evaluated yet.
- Not applicable – policy doesn’t apply to this device.
- Compliant – all requirements met.
- In grace period – failing, but within an allowed grace window.
- Non-compliant – failed and past grace period.
- Error – something went wrong during evaluation.
These show up in reports and help you see where devices are in the journey from onboarding to fully compliant.
How often devices check in for compliance
Each platform has its own check-in rhythm. The early intervals are more frequent as the device first enrolls and receives policies; after that, it settles into a daily cadence.
Typical pattern:
- iOS / iPadOS
- Every 15 minutes for the first hour
- Then every 8 hours
- macOS
- Every 15 minutes for the first hour
- Then every 8 hours
- Android
- Every 3 minutes for the first 15 minutes
- Every 15 minutes for 2 hours
- Then every 8 hours
- Windows 10 / 11
- Same pattern as Android:
- Every 3 minutes for 15 minutes
- Every 15 minutes for 2 hours
- Then every 8 hours
- Same pattern as Android:
The main thing to remember: once enrolled, devices typically re-evaluate compliance about once every working day. That’s enough to keep your view of device health up to date without overloading the service.
Putting it all together
To implement device compliance with Intune in a safe, controlled way:
- Set the default compliance policy so devices without explicit policies don’t get locked out by accident.
- Design your baseline compliance policy for Windows (and other platforms) with encryption, Secure Boot, Defender, and OS version requirements.
- Add actions for non-compliance:
- Immediate marking as non-compliant
- User email notifications
- Optional retirement after a delay
- Link compliance to Conditional Access so only healthy devices get access to sensitive apps.
- Monitor compliance status through dashboards, device views, and reports.
- Iterate:
- Tune settings
- Refine custom scripts
- Improve user notifications and documentation
With this approach, device compliance becomes a living, measurable control that strengthens your overall Microsoft 365 security posture instead of just another checkbox in the portal.
