The compliance number goes up, nobody can say which devices or why, and the working theory becomes "Intune is wrong". Intune is rarely wrong. It is usually reporting something true about a setting nobody meant to turn on.
Start in the right place. Open the device itself in Intune, not the summary chart, and look at its compliance policies setting by setting. Every policy assigned to it is listed with a per setting state. That one screen answers most of these in under a minute, and it stops the guessing.
The five causes that account for nearly all of it
No compliance policy is assigned at all. There is a tenant wide setting called "Mark devices with no compliance policy assigned as", and depending on when the tenant was built it may be set to Not compliant. Every device outside your assignment groups then reports non compliant while being perfectly healthy. Check the setting, then check whether your policy is actually assigned to the group those devices are in.
The device has not evaluated yet. Compliance is not live. A freshly enrolled device, or one that has been off for a week, reports against whatever it last reported. Look at the last check in time before drawing any conclusion from the state.
BitLocker is still working. A device encrypting a large drive reports as not encrypted until it finishes, and a device whose recovery key never escrowed to Entra will keep failing the check even after encryption completes. The encryption report under Devices, Monitor tells you which of the two it is.
Antivirus signatures are stale. "Require antivirus signature to be up to date" is a genuine fail on a machine that has been off, or one whose updates are blocked. It clears itself once the device updates, which is why this one comes and goes and makes the chart look unstable.
Secure Boot and Code Integrity cannot be attested. These two settings do not read the local machine. They rely on the Device Health Attestation service, which the device has to reach over the internet. A proxy or firewall that blocks it means the device cannot prove anything, so the check fails on a device where Secure Boot is plainly on. This is the one that wastes the most time, because the setting on the machine looks correct.
The part people get backwards
A device showing non compliant in Intune is not necessarily being blocked from anything. Blocking is Conditional Access, and only if a policy requires a compliant device. Plenty of tenants have a red compliance chart and no enforcement at all, which is the worst of both: the reporting annoys everyone and protects nothing.
The reverse trap exists too. Turn on a Conditional Access policy requiring compliance while any of the five causes above is live, and you lock out working devices at nine in the morning. Report only mode for a week exists precisely for this.
What good looks like
One compliance policy per platform, assigned to a group that actually contains the devices, with the tenant wide default set deliberately rather than by accident. A grace period so a device gets a chance to fix itself before it is marked. Somebody looking at the per device detail once a month rather than at the percentage. And Conditional Access turned on only once the number is honest.
That monthly look is most of what Managed Intune is, and the configuration and compliance page lists the rest.