The 9 AM Call That Started the Audit
It is 9 AM on a Monday and the client’s CISO is on the bridge. Their Defender dashboard shows 1,847 enrolled Windows endpoints. Intune says 1,844 are compliant. Their auditor just pulled a sample of 20 devices at random and found three without BitLocker, two with Windows Update paused for 94 days, and one that had not checked into Intune since January. The compliance number was a lie. Not a malicious one — a default one.
This is the failure mode I see most often when I inherit an Intune tenant. The org stood up Microsoft Endpoint Manager, pushed Autopilot, enrolled devices, and assumed the green checkmarks meant something. They did not write Intune compliance policies that actually measured the controls their ISO 27001 or HIPAA scope demanded. The tenant defaulted to trusting every device, and the auditor did not.
This article is the playbook I hand new SecOps leads when they take over an Intune estate. It covers the tenant-wide settings you fix on day one, how to build compliance rules that match the controls you promised your auditor, how to handle noncompliance without triggering a helpdesk revolt, and how to extend compliance with custom checks when the built-in settings run out.
Why Green Checkmarks Lie by Default
The root cause is a single tenant-wide setting. Navigate to Devices → Compliance → Compliance settings in the Intune admin center. You will see a field labeled Mark devices with no compliance policy assigned as. Out of the box, Microsoft sets this to Compliant. Every device that enrolls without a policy targeted at it is marked green. The default is convenience. It is also a lie.
The second setting on that same blade is Compliance status validity period (days). Default is 30. If a laptop has not checked into Intune for 30 days, its last reported state is still treated as authoritative. Think about what that means operationally. A device that has been offline for three weeks has missed three Patch Tuesdays. It has missed every Defender signature update in that window. It may have been handed to a family member, sold on eBay, or sitting in a drawer with an expired session token that still works for Exchange Online.
The fix takes 45 seconds. Change Mark devices with no compliance policy assigned as to Not Compliant. Change the validity period to something that matches your patch cadence — I set 14 days for most clients, 7 days for regulated workloads. Save. Now Intune tells you the truth.
What Breaks When You Flip the Switch
Expect a spike. A law firm we consult for had 340 devices go from green to red within an hour of this change. The CIO called me three times that morning. None of those 340 devices were actually new problems — they had always been unmanaged. The dashboard was simply now honest about it. We worked through the list in 72 hours: 280 got a compliance policy assignment they should have had from day one, 40 were stale enrollments we retired, and 20 were genuine noncompliance we fixed one ticket at a time.
If you flip this setting on a production tenant without telegraphing it to the helpdesk and conditional access team first, you will block legitimate users. Do it in a maintenance window. Have a bypass group ready for executives. Communicate the timeline to anyone who approves conditional access exceptions.
Building a Compliance Policy That Maps to Real Controls
Compliance policies live under Devices → Manage devices → Compliance → Create policy. You pick a platform — Windows 10/11, macOS, iOS/iPadOS, Android Enterprise, Linux — and then walk a wizard. Each platform exposes different settings because the underlying OS exposes different telemetry. I will use Windows as the worked example because it is where most of the pain lives.
For a Windows 10/11 policy targeting a corporate fleet, the non-negotiable checks are:
- BitLocker: Require encryption on the system drive. This maps to MITRE ATT&CK mitigation M1047 (Audit) and T1552.004 (Unsecured Credentials: Private Keys) on stolen hardware.
- Secure Boot: Require Secure Boot to be enabled. Defends against bootkit persistence (T1542.003).
- Code integrity: Require the device to pass Windows code integrity attestation.
- Defender: Signatures up to date, real-time protection on, antimalware service running.
- Firewall: Microsoft Defender Firewall must be enabled on all profiles.
- Minimum OS build: Tie this to your patch rollout. I use N-1 build — last month’s approved cumulative update is the floor.
- Password complexity: Minimum length, complexity, and maximum PIN age if you are using Windows Hello for Business.
Do not check every box just because Microsoft exposes it. Every setting you enable is a setting your helpdesk has to support. I have seen orgs enable Valid operating system builds with a hardcoded build number, forget about it for six months, and then wonder why 600 freshly-patched devices are noncompliant. Compliance is a living document. Treat it like detection engineering — own the rules, tune them, retire the ones that do not earn their keep.
Actions for Noncompliance: The Grace Period Problem
After the settings page, the wizard asks about Actions for noncompliance. The default is a single action: Mark device noncompliant with a schedule of 0 days. That means the moment a device fails a check, it is marked red, and if you have a conditional access policy keyed to compliance, the user is locked out of Exchange, SharePoint, and Teams. Zero grace.
That default works for one scenario — a lost laptop that fails BitLocker check because someone decrypted it. It is hostile for every other scenario. The most common noncompliance I see is device pending reboot after a cumulative update. The update installed. The machine needs to reboot. The user is in a Teams meeting. Zero-day enforcement means they get kicked out of the meeting to reboot. That is how you generate alert fatigue in reverse — users start ignoring Intune prompts because Intune is seen as the thing that interrupts work.
The fix is layered actions with grace periods:
- Day 0: Send email to end user explaining the specific setting that failed and how to remediate. Use the Send email to end user action with a custom notification template.
- Day 3: Send a second email, escalated tone. CC the user’s manager if possible via a custom notification.
- Day 5: Mark device noncompliant. Conditional access kicks in.
- Day 7: Send email to IT admin. This is your escalation matrix trigger.
We rolled this exact schedule out across three client environments and watched helpdesk tickets on compliance drop by roughly 60% in the first month. Users self-remediated once they had clear instructions and a window. The ones who did not self-remediate were genuine problem devices that deserved to be blocked.
A Windows Compliance Policy Walkthrough
Here is what I configure on a greenfield engagement. Assume the client is a mid-market firm with 500 Windows devices, Entra ID joined, Autopilot enrolled.
Policy name: Win11-Corporate-Standard-v3
Description: Include the owner’s name, the control framework it maps to (SOC 2 CC6.7, CC7.2), and the version. Version everything. When the auditor asks why build 22621.3810 is the floor, you want the policy description to say “aligned with April 2026 cumulative update, per change request CR-2604-11.”
Compliance settings:
- Device Health: Require BitLocker — Require. Require Secure Boot — Require. Require code integrity — Require.
- Device Properties: Minimum OS version — 10.0.22621.3810. Maximum OS version — left blank. Valid operating system builds — left blank unless you have a genuine reason to whitelist.
- Configuration Manager Compliance: Not applicable for cloud-only tenants.
- System Security: Password required, type Alphanumeric, minimum length 8, maximum minutes of inactivity before password is required 15, password expiration 365 days. Encryption of data storage — Require. Firewall — Require. Antivirus — Require. Antispyware — Require.
- Microsoft Defender Antimalware: Signature must be up to date — Require. Real-time protection — Require.
- Defender for Endpoint: Require the device to be at or under the machine risk score — Medium. This integrates your EDR telemetry into compliance, which is the single highest-value setting on this page for incident response.
The Defender for Endpoint integration is the one I see clients skip most often. It requires you to connect Defender for Endpoint to Intune under Endpoint security → Microsoft Defender for Endpoint, flip Connect Windows devices to Microsoft Defender for Endpoint to On, and set a risk threshold. Once it is live, a device that Defender flags as High risk — active malware detection, suspicious process tree, credential theft attempt — gets marked noncompliant automatically. Conditional access blocks it from corporate resources. Your mean time to contain drops from hours to minutes for the endpoints that matter most.
When Built-In Settings Are Not Enough
Built-in compliance settings cover the common ground. They do not cover everything. An engineering firm we support needed to enforce that a specific CAD license daemon was running on every workstation — a third-party product with no Intune integration. Another client in financial services wanted to block any device with TeamViewer installed. Neither requirement maps to a built-in toggle.
The answer is custom compliance policies. The mechanism is a PowerShell discovery script paired with a JSON rules file. The script runs on the endpoint, outputs key-value pairs, and Intune compares the output to your JSON rules. Anything you can detect with PowerShell, you can enforce with compliance.
The skeleton of a discovery script looks like this:
$output = @{}
# Check if TeamViewer is installed
$teamviewer = Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -like '*TeamViewer*' }
$output['TeamViewerInstalled'] = if ($teamviewer) { 'true' } else { 'false' }
# Check CAD license daemon
$licd = Get-Service -Name 'CADLicenseDaemon' -ErrorAction SilentlyContinue
$output['CADDaemonRunning'] = if ($licd.Status -eq 'Running') { 'true' } else { 'false' }
# Check minimum RAM (in GB)
$ram = [math]::Round((Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB)
$output['RAMGB'] = $ram.ToString()
return $output | ConvertTo-Json -Compress
The paired JSON rules file tells Intune what the acceptable values are. A rule looks like:
{
"Rules": [
{
"SettingName": "TeamViewerInstalled",
"Operator": "IsEquals",
"DataType": "String",
"Operand": "false",
"MoreInfoUrl": "https://clients.sse.to/contact.php",
"RemediationStrings": [
{
"Language": "en_US",
"Title": "Unauthorized remote access tool detected",
"Description": "TeamViewer is not approved on corporate devices. Contact IT for the approved remote support tool."
}
]
}
]
}
Two practical notes from production rollouts. First, sign your discovery script with an internal code-signing certificate — Intune defaults to rejecting unsigned scripts in custom compliance. Second, test the script on a reference image before deploying. I have watched a badly-written script throw a non-terminating error, return $null, and mark 200 devices noncompliant overnight. Wrap your logic in try/catch and return sensible defaults on failure.
For more on how PowerShell buffers output in these contexts — which matters when you are piping between discovery steps — our breakdown of PowerShell OutBuffer covers the underlying mechanics.
The Triage Playbook for Noncompliant Devices
Once compliance is telling the truth, you will have a queue of noncompliant devices to work through. Treat it like alert triage. Not every red device is a security incident. Most are operational drift. The goal of the playbook is to route each device to the right response in under 15 minutes.
Step 1: Pull the Compliance Report
From Reports → Device compliance, export the noncompliant device list. Each row tells you the device, the user, the failing setting, and the last check-in time. Group the report by failing setting, not by device. You will see patterns — 80% of the failures are usually one of three settings.
Step 2: Classify by Cause
Map each failing setting to a cause bucket:
- Patch drift: Minimum OS version failures. Route to the update ring owner.
- Pending reboot: Signature out of date on a device that checked in recently. The update installed but the service did not restart. One reboot fixes it.
- Genuine control failure: BitLocker off, firewall off, Defender disabled. This is the bucket that matters. Treat each one as a potential indicator of compromise — an attacker disabling defenses (MITRE T1562.001, Impair Defenses: Disable or Modify Tools) looks identical to a user who ran a batch file from a forum.
- Stale enrollment: No check-in for greater than the validity period. The device is gone. Retire it from Intune and revoke the user’s sessions.
Step 3: Investigate the Control Failures
For the genuine control failures, pull the device into Defender for Endpoint and review the timeline for the last 48 hours. Look for process execution that matches MITRE ATT&CK T1562 sub-techniques. If Defender shows suspicious activity, the device is a potential intrusion — isolate it via Defender, rotate the user’s credentials, and escalate to incident response. If the activity is benign (user ran a “fix my internet” batch script), remediate the control and educate the user.
Our Sysinternals boot tracing guide covers how to dig deeper when a device has a service that will not stay enabled — useful when a Defender disable reappears after every reboot.
Connecting Compliance to Conditional Access
Compliance policies by themselves do nothing but raise flags. The enforcement layer is conditional access. Under Entra ID → Security → Conditional Access, create a policy that requires device to be marked as compliant for all cloud apps, applied to all users except break-glass accounts and your named service principals.
This is the step orgs forget. A client we picked up last year had 17 compliance policies configured, perfectly tuned, mapping to every CIS control. Zero conditional access policies keyed to compliance. Intune was generating beautiful reports that no one enforced. A noncompliant device could sign into Exchange, OneDrive, and Teams without resistance. The compliance posture was theater.
Start the conditional access rollout in Report-only mode. Let it run for two weeks. Review the sign-in logs for sign-ins that would have been blocked. You will catch shared mailboxes, service accounts authenticating as users, and third-party MDM enrollments that never checked into Intune. Fix those, then flip the policy to On. Your client portal users will notice nothing if you did the report-only phase properly.
Protecting the Data Behind the Devices
Compliance enforcement protects the endpoint. It does not protect the data if the endpoint falls out of policy scope. Mailbox compromises and OneDrive data loss happen on compliant devices too — through phishing, OAuth consent abuse, or legitimate-user-gone-rogue. This is why we pair every Intune compliance engagement with a separate data protection layer: Microsoft 365 backup for mailboxes and SharePoint sites, and email archiving for litigation hold and compliance retention. Intune tells you the device is safe. Backup and archiving tell you the data is recoverable if the device turns out not to be.
A Note on macOS, iOS, and Android
The principles transfer. The settings differ. On iOS/iPadOS you enforce passcode complexity, jailbreak detection, and minimum OS version — you cannot enforce encryption because it is always on. On macOS you enforce FileVault, System Integrity Protection, firewall, and gatekeeper. On Android corporate-owned devices you enforce passcode, encryption, and the play integrity attestation. Build a policy per platform. Do not try to make one policy span multiple OS families — the wizard does not let you, and for good reason.
What the Default Device Compliance Policy Actually Checks
Before I close out, one detail that trips up admins. Intune has a hidden Default Device Compliance Policy that runs underneath your custom policies. You cannot edit it directly. It checks three things: the device has a compliance policy assigned, the device is active (checked in within the validity period), and the enrolled user exists in Entra ID with a valid Intune license. If any of these fails, the device is noncompliant regardless of what your custom policies say.
This is the policy that catches stale enrollments where the user account was deleted but the device record remained. I have seen it save an audit — a departed employee’s laptop was still in Intune, still marked compliant by the custom policy, but the Default Device Compliance Policy correctly flagged it the moment the user account was disabled. Do not fight this policy. Understand it and let it do its job.
The Takeaway
Intune compliance policies are only as useful as the gap between their output and the truth. Flip the tenant defaults so the dashboard does not lie. Build policies that match the controls your auditor will actually test — BitLocker, Secure Boot, Defender, patch level, Defender for Endpoint risk score. Use grace periods so enforcement does not become the thing users learn to hate. Write custom compliance for the requirements Microsoft did not ship. Wire it all to conditional access so noncompliance has consequences. Review the noncompliance queue every week like any other detection queue — bucket by cause, investigate the control failures for signs of T1562, and retire stale enrollments.
Compliance engineering is detection engineering with a different output. Both are playbooks you own, tune, and version forever. If you need a second set of eyes on your Intune tenant or want us to run the tenant-default and conditional access review for you, reach out through the SSE contact form and we will scope it.
