Intune Policy Not Applying: Why Silent Failures Keep Coming Back

A device shows as compliant, the policy shows as assigned, and the setting still is not there. That is the specific shape of the Intune complaint that keeps coming back — not "Intune is hard to learn," but "Intune says this worked and it did not, and nothing tells me why."

The admin center's deployment status tells you a policy reached a device. It does not tell you why a setting did not land — but the per-setting view does, and most admins never open it. That is the difference between troubleshooting by elimination and reading the answer off a screen.

In short

Most "Intune is broken" tickets are not broken policies. They are assignment, applicability, check-in or registration problems, or a conflict that Intune reports at the individual-setting level. Work from the device outward — assignment, sync, per-setting reports, registration and then policy design — before changing a configuration at random.

Where the silent failures come from

Three sources account for most of the "it should be working" tickets.

Policy conflict, not policy failure. Intune handles conflicts by policy type. Compliance settings take precedence over matching configuration settings; multiple compliance policies use the most restrictive setting; conflicting configuration settings are shown as conflicts in Intune and require manual resolution. Inspect per-setting reports and every policy surface, including endpoint security and baselines, before changing a policy. Microsoft's documented workflow is the order to follow: check the deployment report for error or conflict flags, list every policy type touching the same setting, then read the device-level per-setting status to see which policy actually applied. That is where the answer is, not on the policy's own configuration screen.

Assignment or applicability, not a mysterious sync fault. Confirm the target group, assignment filter, platform and OS support, licence prerequisites, and whether the setting applies to that device. Treat a suspected Entra or licensing-state problem as a case to verify with evidence, not as the default explanation.

Device check-in timing. Policy changes usually do not wait for the scheduled check-in. Assigning, updating or deleting a policy triggers a change-based sync: Intune notifies online devices, and Learn puts that notification anywhere from immediately to a few hours out. A device that is powered off or otherwise offline misses the notification and then waits for the next maintenance sync, which Learn estimates at roughly every 8 hours across platforms, with no more than one maintenance sync per 6.5 hours. That gap is where "it is not working" is often just "it has not checked in yet." Forcing a sync from the Company Portal confirms whether timing rather than configuration is the actual issue.

When App Protection stops being detected by Conditional Access

A specific and disproportionately painful failure: a Conditional Access policy requiring an approved client app or App Protection Policy starts rejecting a device that Intune still shows as protected. The workaround that circulates — remove all corporate apps and reinstall starting with Microsoft Authenticator — points at the wrong layer. App protection is a MAM control, and Learn states plainly that Intune app protection policies do not require an MDM service at all. The device's compliance state and its Entra device object are not what that grant control reads.

What breaks is the app's own registration with the Intune MAM service. Run the documented check before anyone reinstalls anything: confirm the user is licensed for Intune and targeted by the policy, confirm the specific app is listed in that policy, and confirm the user has actually checked in. All of it is visible under Apps > Monitor > App protection status for that user, including the last sync time. Then check delivery timing. Learn documents retry intervals of 12 hours for a user who is unlicensed or not targeted, 24 hours for a tenant that is not onboarded, and roughly 30 minutes once MAM registration has succeeded. An app that has gone 90 days without contacting the Intune MAM service may be deregistered automatically, and re-registers on next launch. Reinstalling every corporate app is a way to force that last case; it is not a diagnosis. Device registration state only matters here if the same Conditional Access policy also requires a compliant device.

A practical troubleshooting order

Work from the device outward rather than from the policy inward:

Force a device sync and let the check-in cycle complete before troubleshooting anything else
Check for assignment conflicts across every policy targeting that device or its groups
Confirm the user's license state in Entra ID matches expectations, and check sync status if it looks stale
Review the device's compliance and registration state in Entra ID directly, not just the Intune compliance dashboard
Only then treat it as a genuine policy configuration issue

Most tickets resolve somewhere in steps 1 to 4, before anyone opens the policy.

Autopilot: front-loading the pain, not removing it

Autopilot solves real deployment friction — zero-touch provisioning genuinely beats imaging. What it does not solve is lifecycle. A device enrolled via Autopilot still needs deliberate handling when it is reassigned, retired or wiped, and its registration can persist past the point the device is actually in use, leaving stale records that complicate re-enrolment later. The documented order matters: delete the device from Intune first, then deregister it from Windows Autopilot, and do not delete the Entra device object by hand. Learn is explicit that skipping steps or removing records out of order produces orphaned or unrecoverable devices. Autopilot removes work at deployment. It does not remove the need for a process at the other end.

Bottom line

Intune's failures are rarely visible where you would expect to find them — the policy's own configuration screen. Most of what looks like a broken policy is a conflict, a stale license sync, or a device that has not checked in. Working from the device outward finds the cause faster than staring at the same deployment status screen a second time.

Glossary

Policy conflict: Two or more Intune policies targeting the same setting. Resolution is policy-type specific: compliance settings can take precedence, while conflicting configuration settings are reported and require manual resolution.
Check-in cycle: The interval at which a managed device contacts Intune for policy. Assigning or changing a policy notifies online devices to sync; a device that was offline waits for the next maintenance sync, estimated at roughly every 8 hours, unless a sync is forced.
App Protection Policy (MAM): Policy that protects corporate data inside apps, on managed or unmanaged devices, without managing the whole device.
Device registration state: The device's identity record in Entra ID. It governs Conditional Access grant controls that require a compliant or joined device — but not app protection, which is evaluated from the app's MAM registration instead.
Autopilot: Zero-touch provisioning that self-configures a new device on first sign-in. Covers deployment, not device lifecycle or retirement.

Frequently Asked Questions

Why are my Intune policies not applying to devices?

Most commonly a conflicting policy silently wins, the device has not checked in since the policy changed, or the license and compliance state synced from Entra ID is stale. Genuine misconfiguration is real but less frequent than these three.

Why is Intune App Protection suddenly not detected by Conditional Access?

Most often the app's MAM registration lapsed rather than anything about the device. Check that the user is still licensed for Intune and still targeted by the policy, that the app is listed in the policy, and when the app last checked in — Intune deregisters an app that has gone 90 days without contacting the MAM service. Verify that under Apps > Monitor > App protection status before touching the Conditional Access policy.

How do I troubleshoot Intune policy deployment failures systematically?

Force a device sync, check for assignment conflicts, verify license and sync status in Entra ID, then review the device's compliance and registration state — in that order — before treating it as a policy configuration problem.

Can Entra sync issues break Intune licensing and policy behaviour?

Yes. Intune reads license state from Entra ID, and sync lag or stale data there produces policy behaviour that looks like an Intune fault but originates in the identity layer. Checking sync status is a legitimate early step, not a detour.

Is Intune Autopilot enough for full device lifecycle management?

No. Autopilot handles provisioning at deployment, not reassignment or retirement. Stale Autopilot records that outlive actual device use are a common source of later re-enrolment problems.