Why healthy Windows devices fell out of Intune compliance after the July 2026 updates
Windows builds from 14 July 2026 left newly provisioned devices stuck noncompliant, with BitLocker, Secure Boot and code integrity all failing on one missing attestation result. Here is how to tell it apart from real drift.
One missing certificate flipped three separate compliance rules at once, and Conditional Access did the rest.
Windows builds released on 14 July 2026 (KB5101650 for 24H2 and 25H2, KB5101649 for 26H1) carried a regression that Microsoft describes plainly in its own release notes: newly provisioned or newly recovered devices that enroll in an MDM service such as Microsoft Intune could remain in an incorrect noncompliant state and be unable to access corporate resources.
In the console it looked worse than that. Administrators reported Require BitLocker, Require Secure Boot and Require code integrity all failing together with the same result, 2016345708 (0x87d10194, SyncML 404), on devices where those protections were genuinely enabled. Nothing in the baseline had changed. Those three settings are not measured independently. Intune evaluates all of them from the Windows Device Health Attestation result, so when the health attestation certificate never comes back, all three report failure at the same moment.
Microsoft shipped the correction in the 28 July preview updates: KB5101684 (builds 26100.8973 and 26200.8973) and KB5101681 (build 28000.2608).
Telling this apart from real drift
- All three attestation rules fail on the same device with an identical error code, rather than a mix of results.
- The rule returns an error rather than a clean noncompliant verdict.
- Non-attestation rules on the same device, such as firewall, antivirus and OS version, still report normally.
- Affected machines cluster around recent Autopilot builds, reimages and recoveries.
- The change is fleet-wide and lines up with a patch window instead of appearing gradually.
Two changes worth making now
Give attestation-backed rules a grace period. Every compliance policy includes the Mark device noncompliant action set to zero days by default, so a single failed attestation becomes a Conditional Access block immediately. One or two days of grace absorbs a bad boot cycle without weakening the requirement.
Then check that your update rings can actually carry a preview or out-of-band fix before the next monthly cycle, rather than leaving tenants exposed for two more weeks.
If this had hit every tenant you manage on the same morning, how quickly would you have known it was Windows and not your baseline?