Understanding Device Compliance Policies in Microsoft Intune (with Azure AD Conditional Access)
If you manage corporate devices with Microsoft Intune, you’ve probably run into this situation: a user insists their laptop is “compliant” but still can’t access email, Teams, or other company resources. Or you open the Intune portal and see a bunch of devices flagged as non-compliant without an obvious reason.
To be honest, this is more common than many admins like to admit. Device compliance policies, especially when combined with Azure AD Conditional Access, are powerful—but they can also be a bit confusing when you’re trying to troubleshoot real-world issues.
In this article, we’ll break down how device compliance policies work in Intune, what the built-in compliance policy actually does, how custom policies interact with it, and how all of this ties into Azure AD Conditional Access. We’ll focus mainly on Windows devices, but the core ideas apply across platforms. The goal is simple: help you understand why a device is marked compliant or non-compliant, and what that means for access to your protected corporate resources.
What Are Device Compliance Policies in Intune?
At a high level, device compliance policies in Microsoft Intune define what a “secure enough” device looks like for your organization.
Compliance, in this context, means:
- The device adheres to specific rules or security standards
- Those standards are checked and validated before a user can access protected corporate resources
Think of compliance policies as a gatekeeper. Before a device gets access to things like Exchange Online, SharePoint, or internal apps, it’s evaluated against a list of requirements. If it passes, it’s marked compliant; if not, access is often blocked using Azure AD Conditional Access.
### H3
Common examples of compliance rules
In a typical enterprise environment, a compliance policy might require:
- Antivirus enabled – e.g., Microsoft Defender Antivirus must be turned on
- Firewall enabled – the device’s firewall service must be active
- Disk encryption – such as BitLocker enabled for Windows
- OS version – device must be on or above a specific OS build
- No jailbreak or root (on mobile platforms)
Using the example from the transcript, a simple policy might say:
> If antivirus is enabled, mark the device as compliant. If antivirus is disabled or missing, mark it as non-compliant.
On its own, this just sets a status in Intune. The real impact comes when you combine that status with Conditional Access policies to decide who can sign in to which apps.
### H3
How compliance ties into Azure AD Conditional Access
Most organizations don’t stop at just marking devices compliant or non-compliant. They go a step further and enforce:
- Only compliant devices can access corporate resources
This is done using Azure AD Conditional Access. A typical rule might be:
- When a user tries to access Microsoft 365
- From any location
- Require the device to be marked as compliant
If the device is compliant in Intune, access is granted.
If the device is non-compliant, Conditional Access blocks the sign-in (or requires extra controls).
This is why mismatches or misconfigurations in compliance policies or Conditional Access can cause confusing user issues. A device can look fine in one place, but still be blocked because of a different setting somewhere else.
Built-In vs. Custom Device Compliance Policies
In Intune, there are essentially two kinds of compliance policies:
1. Built-in device compliance policy (tenant-wide baseline)
2. Custom compliance policies you create manually
Both matter.
To be considered compliant, a device needs to satisfy:
- The built-in compliance requirements, and
- The custom policies assigned to it
If either one fails, the device ends up non-compliant.
#### 1. Built-in device compliance policy
The built-in policy is a tenant-wide baseline that every device receives. It’s not always obvious because many admins focus on the custom policies they’ve created, but the built-in one quietly does its job in the background.
Key points about the built-in policy:
- It applies to all devices in the tenant
- It acts as a baseline configuration for compliance behavior
- It contains a few fundamental checks (for example, user must be active and licensed)
One important behavior that often trips people up is the setting related to devices that aren’t targeted by any compliance policy (we’ll come back to this in detail below).
#### 2. Custom (manually created) compliance policies
Custom compliance policies are the ones you configure yourself, per platform. For example, you might create:
- A Windows 10/11 compliance policy that requires antivirus, firewall, BitLocker, and a minimum OS version
- A mobile device policy that blocks rooted or jailbroken devices
Each of these policies can be targeted to specific groups of users or devices.
Intune then evaluates all assigned policies. If any compliance policy (built-in or custom) is not met, the device is flagged non-compliant.
So, in practice:
- All relevant compliance policies must pass
- If one is in a “red” state (to use the wording from the transcript), the device is considered non-compliant overall
Why users see “compliant” but still can’t access resources
Surprisingly, one of the most common complaints from end users sounds like this:
> “My device shows as compliant, but I still can’t access my email or apps.”
From an admin perspective, this usually boils down to a mismatch between:
- What Intune says about the device (compliant / non-compliant)
- What Conditional Access is actually requiring
A few classic scenarios:
1. Intune shows the device as compliant, but Conditional Access is configured to require a hybrid Azure AD joined device instead of “require device to be marked as compliant.” The device might be compliant, but not hybrid-joined, so access is blocked.
2. A policy was recently changed, but the device hasn’t synced yet, so Conditional Access sees it as non-compliant.
3. The built-in compliance settings are stricter than expected (e.g., devices not targeted by any policy are treated as non-compliant).
In my experience, whenever you get an access issue that doesn’t make sense, you should always look at both:
- The device’s compliance status in Intune
- The specific Conditional Access policy evaluation result in Azure AD sign-in logs
Most of the mystery disappears once you compare those two views side by side.
Key Settings That Affect Device Compliance (Especially on Windows)
Now let’s zoom in a bit more on Windows devices, because that’s where a lot of admins spend their time.
When a user can’t access company resources, or a device is suddenly marked non-compliant, the root cause is often one of a handful of settings—either in the compliance policy itself or in Conditional Access.
Below are some of the most important ones to understand and double-check during troubleshooting.
Example: Antivirus requirement in a Windows compliance policy
Imagine you’ve created a Windows compliance policy in Intune with this rule:
- Require antivirus to be enabled
The logic is straightforward:
- If antivirus is enabled → mark device as compliant
- If antivirus is disabled or missing → mark device as non-compliant
In a normal scenario, as soon as the policy evaluates and the device doesn’t meet the antivirus requirement, Intune marks it non-compliant. If you’ve tied access to compliance status using Conditional Access, the user will then be blocked from accessing protected apps.
Things to verify when troubleshooting:
- Is antivirus actually installed and running?
- Is Defender turned off because a third-party AV is installed, and does your policy account for that?
- Has the device recently synced with Intune to refresh its compliance state?
It sounds basic, but a lot of headaches come from assumptions like “of course the antivirus is running” when it’s actually been disabled by the user or another tool.
The “mark devices with no compliance policy as compliant/non-compliant” setting
One setting that causes a lot of confusion lives under the built-in compliance policy behavior. It controls how Intune treats devices that aren’t assigned to any compliance policy at all.
You’ll typically see a setting along the lines of:
> If a device is not part of any compliance policy, mark it as compliant / non-compliant.
By default, many tenants have this set to compliant. That means:
- If a device has no compliance policy targeted to it, Intune still treats it as compliant.
However, organizations with stricter security standards often change this to non-compliant. And this is where things get tricky.
If this setting is changed to non-compliant:
- Any device that doesn’t have a compliance policy targeted will automatically be flagged as non-compliant
- Users on those devices will be blocked by Conditional Access if it requires a compliant device
So when you see devices mysteriously showing as non-compliant, ask yourself:
- Are these devices actually receiving any compliance policy?
- Has someone in your organization changed the “no compliance policy” behavior recently?
It sounds like a small configuration detail, but it has tenant-wide impact.
Compliance validity period and why offline devices go non-compliant
Another key setting is the compliance validity period—basically how long Intune will consider a compliance check “fresh” before it expires.
Some important points from the transcript:
- The maximum validity period is 120 days
- By default, many tenants use around 30 days
- Your tenant might be configured to something stricter like 1 or 2 days
What this means in practice:
- Intune expects the device to check in (sync) within that validity period
- If the device doesn’t connect to the internet or the user doesn’t log in and trigger a sync, Intune can’t refresh its compliance data
- Once the validity period expires without a new check-in, the device is marked as non-compliant
So even if the device technically still meets all security requirements (antivirus is on, firewall is enabled, etc.), Intune will treat it as non-compliant because it hasn’t heard from the device in too long.
This is especially relevant for:
- Remote or traveling users
- Devices that sit powered off for long periods
- Shared machines or seasonal workers’ devices
In those cases, either:
- Set a reasonable compliance validity period that matches your real-world usage, or
- Educate users that devices must connect regularly for policy refreshes
Otherwise, you’ll get a lot of “But it was compliant last week!” complaints when they finally boot up and hit a Conditional Access block.
How Conditional Access can override your expectations
Even when a device is correctly marked as compliant in Intune, access can still fail if the Conditional Access policy is configured differently from what you expect.
Consider two common configurations:
1. Require device to be marked as compliant
- Access is granted if Intune says the device is compliant
- Simple and aligns directly with your compliance policies
2. Require hybrid Azure AD joined device
- Access is granted only if the device is hybrid Azure AD joined (on-prem AD + Azure AD)
- Even if the device is compliant, it will still be blocked if it’s not hybrid-joined
In the second case, admins sometimes forget they changed or added this requirement. From the user’s perspective, it’s confusing:
- Intune: “Your device is compliant.”
- Conditional Access: “You are blocked, because your device isn’t hybrid Azure AD joined.”
When troubleshooting access issues, always check:
- What exact controls are configured in Conditional Access? Is it “require compliant device,” “require hybrid Azure AD joined device,” or a combination?
- Does the device actually meet all those conditions (not just compliance)?
In my experience, a quick review of the Conditional Access settings explains at least half of the mysterious access issues people raise with IT.
Practical Troubleshooting Steps for Non-Compliant Devices
Let’s put all of this together into something you can actually use day-to-day. When a user complains that they can’t access a protected app, or when you see a device flagged as non-compliant in Intune, here’s a practical approach.
Step-by-step checklist for admins
1. Check the device’s compliance status in Intune
- Open the device record in the Intune admin center
- Look at the overall compliance state (compliant / non-compliant / in grace period)
- Review which specific policy is failing, if any
2. Review the assigned compliance policies
- Confirm which policies are actually assigned to the device/user
- Open the failing policy and read the configuration
- For Windows, look at settings like antivirus, firewall, BitLocker, OS version, etc.
3. Verify built-in compliance behavior
- Check the tenant-wide setting: “If a device is not part of any compliance policy, mark it as…”
- Confirm whether it’s set to compliant or non-compliant
- If it’s non-compliant, ensure every relevant device is actually targeted by a policy
4. Check the compliance validity period
- Look at how many days are configured (e.g., 30, 60, 120 days, or something very short)
- See when the device last synced
- If the device hasn’t checked in within the validity window, have the user connect to the internet and sync the device (via Company Portal or Settings)
5. Examine the Conditional Access policy
- Open the relevant Conditional Access policy in Azure AD
- Check if it’s requiring:
- A compliant device, or
- A hybrid Azure AD joined device, or
- Some combination of device and sign-in risk
- Compare this with the actual state of the device
6. Test a fresh sign-in and review sign-in logs
- Ask the user to sign out and sign in again
- In the Azure AD sign-in logs, review the Conditional Access evaluation
- This often tells you exactly which requirement failed (e.g., device not hybrid-joined, not marked compliant, or something else)
By walking through these steps, you turn a vague complaint like “It just doesn’t work” into a concrete root cause.
Best practices for stable, predictable compliance
To reduce the number of confusing compliance incidents, there are a few best practices worth considering:
1. Keep compliance policies clear and minimal
- Start with essential controls (antivirus, firewall, OS version)
- Avoid overly complicated rules unless you really need them
2. Align Conditional Access with your compliance model
- If your main security gate is “device must be compliant,” then use “require device to be marked as compliant” in Conditional Access
- Only add extra requirements (like hybrid Azure AD join) if you truly need that level of control
3. Set a realistic compliance validity period
- Balance security and usability
- Very short windows (1–2 days) can cause lots of unintentional non-compliance for infrequently used devices
4. Document and communicate changes
- When you change the built-in compliance behavior or Conditional Access rules, document it
- Let your helpdesk and security teams know what changed and why
5. Educate users (lightly)
- You don’t need to turn everyone into an Intune expert, but a simple message like “Your device must connect to the internet regularly so security checks can run” can save a lot of tickets.
None of this is rocket science, but pulling these pieces together makes your compliance posture more predictable—for admins and for end users.
Why Getting Compliance Right Really Matters
It’s easy to think of compliance policies as just another IT checkbox, but they sit right at the intersection of security and productivity.
If they’re too loose, unprotected or compromised devices can access sensitive company resources. If they’re too strict or misconfigured, legitimate users with healthy devices get blocked from doing their jobs.
Finding the right balance means:
- Defining sensible, realistic security standards for your devices
- Implementing those standards in Intune compliance policies
- Enforcing them consistently using Azure AD Conditional Access
- Regularly reviewing settings like built-in behavior and validity periods
When all of that is aligned, you get what most organizations actually want:
- Only healthy, trusted devices can access important corporate data
- Users understand that if their device is out of date or missing protections, access will be restricted
- IT can troubleshoot issues quickly by reviewing compliance and Conditional Access together
To be honest, it may take a bit of trial and error at first, especially in complex environments. But the payoff is a much clearer, more controllable security model for all your endpoints.
Device compliance policies in Microsoft Intune, combined with Azure AD Conditional Access, form a powerful mechanism to secure access to corporate resources. They define what a “trusted” device looks like and enforce that standard in a consistent, automated way.
The key takeaways are:
- There are two layers of compliance: the built-in tenant-wide behavior and the custom policies you configure
- Devices must satisfy all relevant policies to be marked compliant
- Settings like “mark devices with no compliance policy as…” and the compliance validity period can drastically affect how many devices appear non-compliant
- Conditional Access must be configured in a way that matches your intent—whether that’s simply requiring a compliant device or also requiring hybrid Azure AD join
If you’re seeing unexpected non-compliance or users blocked from apps, start by reviewing the compliance policies, the built-in behavior, the last sync time, and the Conditional Access rules side by side. That combination almost always reveals the issue.
If you haven’t done it yet, this is a good time to audit your current Intune compliance and Conditional Access configuration, tighten what needs tightening, and simplify anything that’s become overly complex. A bit of cleanup now can save a lot of support tickets and frustrated emails down the road.