Device Compliance Issues — Day 3 of the Microsoft Intune Real-Time Troubleshooting Series
Day 3 of the Microsoft Intune Real-Time Troubleshooting Series
Welcome to Day 3 of the Microsoft Intune Real-Time Troubleshooting Series — 15 days, 15 real-world scenarios, 15 practical solutions.
Day 1 was a device that would not enroll. Day 2 was a user who could not sign in to the Company Portal. Today the device is enrolled, the user can sign in — and the device is still locked out. The difference is one word: compliant. Intune has decided the device does not meet the organization’s security requirements, and Conditional Access is doing exactly what it was told to do with that decision.
The failure is rarely on the device in front of you — it lives in the gap between what the policy requires, what the device reports, and what Entra ID believes when the user signs in.
1. Real-World Scenario
It is Monday morning, and the security team has just tightened the company’s Windows compliance policy. The minimum OS version is now Windows 11 23H2 — the Windows 10 fleet lost support on October 14, 2025, and the policy finally caught up. BitLocker is now required, not recommended. Secure Boot and TPM 2.0 are required. Microsoft Defender must be on with up-to-date signatures.
By 9 a.m. the help desk has 90 tickets with the same shape: a user opens Outlook or Teams and gets “Your device doesn’t meet your organization’s requirements” — or, on the sign-in page, error AADSTS53000: “Device is not in required device state. Conditional Access policy requires a compliant device, and the device is not compliant.” The Company Portal app shows the same verdict in plain language: “Your device isn’t compliant.”
But it is not every device. Roughly half the fleet is fine. Some of the failing laptops are brand-new Windows 11 machines. Nobody can see a pattern yet, and the security team is being asked whether to roll the policy back.
2. Root Cause Analysis
A noncompliant verdict has a short list of causes, and they fail in a predictable order of likelihood. Work through them in this sequence before touching the device.
1. The minimum OS version was raised, and the device is below it. The most common cause after a policy change. A Windows compliance policy checks the OS version in major.minor.build.revision format, and any device below the minimum is noncompliant. After Windows 10 reached end of support, any fleet still on it fails the moment the policy requires Windows 11.
2. BitLocker is required but not enabled — or still encrypting. The trap: a compliance policy that requires BitLocker only checks for encryption. It does not turn BitLocker on — that needs a separate disk-encryption configuration policy on the same devices. And encryption takes time: a device mid-encryption reports noncompliant until it finishes.
3. Secure Boot or TPM attestation is failing. Compliance policies can require Secure Boot and a TPM, reported through device health attestation. A device with Secure Boot disabled in firmware, a TPM present but not ready, or a failed attestation reports noncompliant even though Windows runs fine.
4. Defender is off, stale, or reporting a high risk score. The policy can require Defender Antivirus on, real-time protection enabled, signatures up to date, and the Defender for Endpoint risk score below a threshold. Paused real-time protection, stale signatures, or an active high-severity threat all fail.
5. A single setting returns an error instead of a result. Compliance is evaluated per setting, and one setting erroring out can sink the whole device. The best-known example is the firewall check returning error 0x87D101F4 (-2016345612, SyncML 500).
6. The device has not checked in within the validity period. Compliance expires. The tenant-wide Compliance status validity period defaults to 30 days (1 to 120). If a device does not successfully report on all its compliance policies inside that window, Intune treats it as noncompliant — even if nothing on the device changed.
7. No compliance policy is assigned to the device at all. The tenant-wide setting Mark devices with no compliance policy assigned as defaults to Compliant — Microsoft describes this as the security feature being off. A device that never received a policy sails through Conditional Access as “compliant” without ever being checked. Or the policy exists but targets a group the device is not in.
8. The device is in its grace period. Not every noncompliant device is blocked. The Mark device noncompliant action has a schedule, and delaying it creates a grace period: the device shows InGracePeriod, keeps its access, and only becomes effectively noncompliant when the deadline passes.
9. Two policies disagree, and the stricter one wins. When several compliance policies apply to one device, Intune assigns the status with the highest severity. And when a compliance policy and a configuration profile set the same setting differently, the compliance policy wins.
10. The state Intune shows is not the state Entra ID used. Compliance is evaluated by Intune, reported to Entra ID, and consumed by Conditional Access at sign-in time — three steps that do not happen at the same instant. If Intune says compliant and the sign-in log says otherwise, suspect the sync, not the device.
3. Step-by-Step Troubleshooting
Work in this order: confirm what the verdict actually is, find the exact failing setting, then fix that setting — not the whole device.
1. Read the exact verdict in the Company Portal. On the device, open the Company Portal app. It names the failing area in plain language — “Encryption required,” “Minimum OS version,” “Antivirus not enabled.” If the portal says no compliance policies have been assigned, you have cause 7, not a device problem.
2. Check the per-setting status in the admin center. In the Intune admin center, go to Devices > All devices, open the device, and select Device compliance. This shows the status per policy — and, crucially, the status per setting. One red setting among ten green ones is the whole diagnosis.
3. Check the sign-in log for the block. In Microsoft Entra, go to Monitoring & health > Sign-in logs and find the failed sign-in. The Conditional Access tab names the blocking policy, and the error code tells you why: AADSTS53000 means the device is not compliant.
4. Confirm the policy assignment. Open the compliance policy and check its assignments: is the device — or its user — actually in the targeted group? Then check the tenant-wide Compliance policy settings: unassigned devices pass silently if Mark devices with no compliance policy assigned as is set to Compliant.
5. Verify the OS version against the policy. If the policy requires Windows 11 23H2 (build 22631) and the device reports Windows 10 22H2 (build 19045), the diagnosis is done: the device needs an OS upgrade or a feature update. Do not lower the minimum to make the red go away.
6. Check BitLocker, Secure Boot, and the TPM. Run them from Section 4. If BitLocker is off, the fix is a disk-encryption policy, not a compliance edit. If Secure Boot is off, it is a firmware setting: reboot into UEFI and enable it. If the TPM is present but not ready, initialize it.
7. Check Defender’s real state. Open Windows Security, or check via PowerShell: is real-time protection on, are signatures current, is there an active threat? A device with an unresolved high-severity detection stays noncompliant until the threat is remediated — by design.
8. Check the validity period. If the device has been offline or unused, check the last check-in date. In the admin center, Devices > Monitor > Setting compliance shows the Is active setting — if it fails, the device has not reported inside the 30-day validity period.
9. Force a sync and a fresh evaluation. On the device, go to Settings > Accounts > Access work or school, select the work account, click Info, then Sync — or use the Company Portal’s sync option. Then wait for the next check-in before re-checking.
10. Read the grace period before you escalate. If the device shows InGracePeriod, open the policy’s Actions for noncompliance tab and read the schedule on Mark device noncompliant.
11. If Intune and Entra disagree, prove which one is stale. When the admin center says compliant but sign-ins still fail with 53000, compare timestamps: the device’s last sync, the last evaluation in Intune, and the sign-in event. Force a sync, wait for a fresh evaluation, and re-test. If it persists, check for a duplicate or stale device object in Entra ID — Day 14’s territory.
4. PowerShell Commands
Each of these is a real command an admin runs on the device or against the tenant. Run the device-side ones in an elevated prompt where noted.
# Check Entra join state and whether the device holds a valid PRT
dsregcmd /status# Check BitLocker status on every volume: is it encrypted, and is protection on?
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentage# Check the TPM: present, ready, enabled, and activated
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, TpmActivated# Confirm Secure Boot is actually enabled (returns True or False)
Confirm-SecureBootUEFI# Check Defender's real state: service, real-time protection, signatures, last scan
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusEnabled, RealTimeProtectionEnabled,
AntivirusSignatureLastUpdated, QuickScanAge, FullScanAge# Check whether the Windows Firewall profiles are enabled
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction# Check the OS product, version, and build number against the policy minimum
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber# Show recent MDM client events, including policy sync and compliance reporting
Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, Message# Generate a full MDM diagnostic bundle (includes compliance state; report lands in C:\Temp)
mdmdiagnosticstool.exe -zip "C:\Temp\MDMDiag.zip"# From the admin side: check the device's compliance state as Intune sees it (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes 'DeviceManagementManagedDevices.Read.All'
Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'LTP-0142'" |
Select-Object DeviceName, ComplianceState, LastSyncDateTime, ManagementState# From the admin side: list the compliance policies and their assignments
Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
Get-MgDeviceManagementDeviceCompliancePolicy | Select-Object DisplayName, Id, CreatedDateTime5. Important Log Locations
| Location | What it tells you |
|---|---|
| Intune admin center > Devices > Compliance > Monitor tab | The compliance dashboard: overall status, the Noncompliant devices report, and devices without a compliance policy. Start here for the fleet view. |
| Intune admin center > Devices > All devices > [device] > Device compliance | Per-device, per-policy, and per-setting compliance status — the single most useful screen in this episode. Shows the failing setting and the last evaluation time. |
| Intune admin center > Devices > Monitor > Setting compliance | Setting-level report across the fleet. The Is active setting here is the validity-period check — if it fails, the device has not reported within 30 days. |
| Microsoft Entra admin center > Monitoring & health > Sign-in logs | The failed sign-in event. The Conditional Access tab names the blocking policy; error AADSTS53000 means the device is not compliant. |
| Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin | The MDM client log. Confirms policy sync and compliance reporting actually happened on the device. No recent events means the device has not checked in. |
| C:\ProgramData\Microsoft\IntuneManagementExtension\Logs | Intune Management Extension log (IntuneManagementExtension.log). Confirms the device is talking to Intune at all. |
| C:\Users\Public\Documents\MDMDiagnostics | Output of mdmdiagnosticstool.exe and the Settings > Access work or school > Create report bundle, including MDMDiagHtmlReport.html — the readable summary of management state, certificates, and policy status. |
| Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational | Defender’s own log. Event ID 5007 marks antivirus configuration changes; Event IDs 1000/1001 record scan results and detections. Use it when the failing setting is antivirus or threat level. |
| HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State | The UEFISecureBootEnabled value (1 = Secure Boot on). The registry evidence behind a Secure Boot compliance failure. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion | DisplayVersion, CurrentBuildNumber, and UBR — the exact OS version the minimum-OS-version check evaluates. |
6. Practical Resolution
Back to the 90 tickets. The troubleshooting above narrows it down fast, and it is not one cause — it is three.
First, the largest group fails on minimum OS version: forty-one devices still on Windows 10 22H2. The policy now requires Windows 11 23H2, and Windows 10 is out of support — these devices are noncompliant by design. The fix is the Windows 11 feature update, rolled out in waves starting with the users who need Outlook and Teams most.
Second, twenty-two devices fail on BitLocker. The compliance policy requires encryption, but no disk-encryption policy was ever assigned to this group — the check was doing its job, and nothing was doing the encrypting. The fix: assign an endpoint security disk-encryption policy to the same group, and set the compliance policy’s Mark device noncompliant action to a 3-day schedule so devices still encrypting are not flagged on day one.
Third, the rest are ones and twos: six devices with Secure Boot disabled in firmware from an old imaging process, eight with Defender signatures weeks out of date, three laptops that sat unused past the 30-day validity period, and two with the firewall error 0x87D101F4, cleared after a sync and a reboot.
The fix, in order:
- Confirm the per-setting failures in the admin center before changing anything — three causes, not one.
- Start the Windows 11 feature update for the Windows 10 group; do not lower the minimum OS version.
- Assign the disk-encryption policy to the BitLocker group and give encryption a 3-day grace period.
- Re-enable Secure Boot in firmware, update Defender signatures, and power on and sync the stale laptops.
- Verify per device in the admin center after the next check-in, then confirm one user can sign in to Outlook without a 53000.
- Document the three settings in the compliance runbook, and put the next policy change through a pilot group with the Conditional Access policy in report-only mode first.
The policy was not the problem. It told the truth about the fleet: encryption had never been deployed, Secure Boot had been off for months, and Windows 10 was still everywhere. The 90 tickets were the audit.
7. Interview Questions
Q1: What is the difference between a configuration policy and a compliance policy?
A configuration policy enforces settings — it sets the value. A compliance policy checks settings and reports a verdict — compliant or not — and that verdict is what Conditional Access consumes. A compliance policy that requires BitLocker does not encrypt the drive; it only fails the device until something else encrypts it.
Q2: A user is blocked with AADSTS53000. What are your first three steps?
First, open the Entra sign-in log and confirm the Conditional Access tab names the compliance policy — 53000 means the device is not compliant. Second, open the device in the Intune admin center and read the per-setting compliance status to find the exact failing setting. Third, check the last evaluation and sync: if the verdict is stale, force a sync and wait for a fresh evaluation.
Q3: What is a compliance grace period, and how do you configure one?
A grace period is the delay between Intune detecting noncompliance and actually marking the device noncompliant. Configure it on the policy’s Actions for noncompliance tab, by setting a schedule on the Mark device noncompliant action — 0 days means immediate, 3 days means the device shows InGracePeriod for three days and keeps its access.
Q4: Intune shows the device as compliant, but Entra still blocks sign-ins with 53000. Why?
The three systems are not in lockstep: Intune evaluates, reports the state to Entra ID, and Conditional Access reads it at sign-in time. The usual cause is sync lag — the device has not checked in since the fix, and Windows checks in roughly every 8 hours — or a stale evaluation timestamp. Force a sync, wait for a fresh evaluation, and compare the timestamps.
Q5: The compliance policy requires BitLocker, but the device is noncompliant and BitLocker is off. Why doesn’t Intune just turn it on?
Because compliance policies only check — they never remediate. Turning BitLocker on is the job of a disk-encryption configuration policy (under Endpoint security), assigned to the same devices.
Q6: What does “Mark devices with no compliance policy assigned as” do, and what should it be set to when you use Conditional Access?
It is a tenant-wide setting that decides how Intune treats enrolled devices that never received a compliance policy. It defaults to Compliant — Microsoft describes this as the security feature being off — so unpoliced devices pass a “require compliant device” Conditional Access policy without ever being checked. When you use Conditional Access, set it to Not compliant, so only devices confirmed by a real policy can access resources.
Day 3 done. Tomorrow, Day 4: Configuration Profile Failures — when the policy reaches the device and the device says no.
Follow the series here on ongoingideas.com — one scenario a day, for 15 days.
Missed the start of the series? Begin with Day 1: Windows Device Not Enrolling into Intune, then Day 2: Company Portal Login Failures.