Is it normal for some Intune policies to apply instantly while others take forever?

Some Intune policies do apply much faster than others, and the behavior described matches how the service actually works rather than a random issue.

Key points to understand and explain:

1. Device check-in and refresh cycles are not real-time
   • Standard “maintenance” syncs happen on a schedule of about every 8 hours for all platforms, including Windows. Devices are also limited to one maintenance sync every 6.5 hours.
   • Newly enrolled devices sync more frequently for a short period (for Windows: every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then around every 8 hours). After that, they fall back to the normal cadence.
   • Manual syncs help, but they still rely on the device actually processing and applying the policy, which can be affected by device state and load.
   Reference behavior:
   • “The estimated check-in schedule for all platforms is about every 8 hours… Independent of the client schedule, devices are only allowed one maintenance sync every 6.5 hours.”
   • Newly enrolled Windows devices: “Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, and then around every 8 hours.”
2. Different policy types and reports update on different timelines
   • Endpoint security policies: devices check for updates every eight hours by default (Windows), and security‑critical policies typically apply within minutes after a sync, but full application still depends on setting complexity and device state.
   • Some policy reporting views can lag significantly. For example, device assignment status reports can take 24–48 hours to reflect recent assignment or group membership changes, especially in large tenants.
   • App Control for Business policy overview tiles (Device status / Device status trend) can take up to 24 hours to update, and even the device-based view can take several minutes after the device receives the policy.
   This means:
   • A wallpaper/profile might appear to “hit instantly” because the device was in a high-frequency post-enrollment window or just happened to check in, and the setting is simple to apply.
   • A security configuration might actually be applied on the device but not yet reflected in all reporting views, or it might be waiting on the next allowed maintenance sync.
3. “Assigned” ≠ “Applied”
   • In the Intune admin center, “Assigned” only means the policy has been targeted to a group that includes the device or user.
   • Actual device state is visible via Device and user check-in status and Per setting status on the policy:
     • Succeeded – policy applied.
     • Error – failed with an error code.
     • Conflict – competing settings.
     • Pending – device hasn’t checked in to receive it.
     • Not applicable – device/OS/edition doesn’t support the setting.
   • For some settings, “Not applicable” is expected if the Windows version or edition doesn’t support the underlying CSP.
4. Platform and applicability constraints
   • Some settings only work on specific Windows versions or editions. If a registry-backed CSP isn’t supported on a given build or SKU, the setting will never apply and will show as Not applicable.
   • This can make it look like “half the machines” are ignoring the policy when in reality they’re on an unsupported OS version/edition.
5. Dynamic groups and assignment delays
   • If policies are assigned to dynamic device groups, there can be a minutes-to-hours delay before a newly enrolled or renamed device is actually added to the group.
   • Until the device is in the group, the policy is technically “Assigned” at the group level but not targeted to that device at check-in.
   • For faster, more predictable delivery in enrollment scenarios, policies should be assigned to user groups, which are pre-populated and don’t depend on dynamic evaluation.
6. How to frame this to a CISO
   A concise, accurate explanation could be:
   • Intune is event- and schedule-driven, not a real-time GPO replacement. Windows devices typically check in about every 8 hours, with a hard limit of one maintenance sync every 6.5 hours.
   • Security policies are prioritized and usually apply within minutes after a sync, but the overall timing depends on device check-in, OS support for the setting, and group membership evaluation.
   • The portal’s “Assigned” state means the policy is targeted, not that it has been enforced. Enforcement status is visible in the per‑device/per‑setting reports, which themselves can lag up to 24–48 hours in some views.
   • For critical controls, the operational pattern should include: targeting via stable user groups, forcing device syncs where possible, and validating via per‑setting status and compliance/endpoint security reports rather than relying solely on the “Assigned” label.

This turns the narrative from “cloud-native is random and slow” into “cloud-native is eventually consistent, with documented sync and reporting intervals that must be designed around.”

References:

• Common questions, answers, and scenarios with policies and profiles in Microsoft Intune
• Manage endpoint security in Microsoft Intune
• View and monitor device configuration policies in Microsoft Intune
• Manage approved apps for Windows devices with App Control for Business policy and Managed Installers for Microsoft Intune