# Detecting Intune configuration drift across customer tenants _Updated 2026-09-10. Canonical page: https://rugged.sh/learn/intune-configuration-drift/_ **Question:** How do I detect when a customer's Intune configuration has drifted from my baseline? **Short answer:** Read the policy state on a schedule, hash or diff it against a stored golden baseline, and alert on the difference. There is no change feed for Intune Settings Catalog policies, so detection is a polling problem, not an event problem. The practical approach is to treat each policy's settings JSON as an opaque document, compare it structurally rather than field by field, and remediate by writing the baseline back through the policy PATCH. ## Drift is not a failure, it is the normal state of a tenant Someone loosens a policy to unblock a user on a Friday. A new admin turns something on to test it. A Microsoft default changes underneath an unmodified policy. None of this is malicious and all of it moves a tenant away from the state you signed off on. The point of drift detection is not to prevent changes. It is to make sure nobody is surprised by one, especially not during an audit or after an incident. ## Why this is a polling problem Microsoft's list of resources that support Graph change notifications covers mailboxes, groups, users, drives, Teams and a handful of others. Intune configuration policies are not on it, and neither are Conditional Access policies (list read 2026-09-10). There is no subscription to create, so detection is a scheduled read, and the design questions become how often, how much it costs in API calls, and how you compare two reads without generating noise. Frequency is a genuine trade. Hourly gives you a tight window and a large call volume across a fleet. Daily is usually enough for policy, which changes on the order of weeks, and leaves room in the throttling budget for everything else you need Graph for. ## Treat the policy as an opaque document It is tempting to model every setting type and compare fields semantically. It is also a losing race: the Settings Catalog is large, Microsoft adds to it continuously, and a schema-aware comparer breaks every time something new appears. The approach that survives is schema-agnostic. Read the policy and its settings, normalize the JSON, hash it, and compare. When the hash changes, diff the documents to show a human what moved. You never need to understand what a setting means to notice that it changed, and a setting type you have never seen is handled correctly by default. > **Two things to know before building on this.** The Settings Catalog surface, deviceManagement/configurationPolicies, is documented on the Graph beta endpoint, and Microsoft's own note says beta APIs are subject to more frequent change and to prefer v1.0 where possible. Keep it behind an adapter. Separately, the Intune Graph API requires an active Intune licence on the tenant: when a trial lapses, the reads start failing with 401 and it looks like a permissions bug rather than a licensing one. ## Remediating without making it worse Detection is the easy half. Writing a baseline back into a live tenant is where you can cause an outage, so the rules that matter are about restraint. - **Report before you remediate:** Run in detect-only mode long enough to learn what normal churn looks like in that tenant. Auto-remediating on day one turns every legitimate local change into a fight. - **Know which surfaces you can safely write:** Not every area supports a clean partial update. A remediator that cannot correctly write a given area should record that and stop, not improvise. - **Keep the audit trail:** Every remediation is a change to a customer's environment. Who, what, when and the before state, or it did not happen. - **Never auto-remediate a policy you did not author:** A policy the customer created is theirs. Detect it, report it, leave it alone. ## Doing this across a fleet The per-tenant version of this is a script. The fleet version needs batching to stay inside Graph's throttling limits, per-tenant scoping so results never bleed between customers, and a way to express one baseline that applies to many tenants without becoming thirty forked copies. rugged.sh runs the scan per customer on a schedule, stores a golden baseline per area, treats the policy JSON as the document of record, and raises drift as an activity you can act on, with opt-in remediation that writes the baseline back and records what it did. ## Questions and answers **Can I get notified when an Intune policy changes?** Not through a change feed for the Settings Catalog. Detection is done by reading policy state on a schedule and comparing it against a stored baseline. Daily is usually sufficient, since org policy changes on the order of weeks and more frequent polling consumes throttling budget you need elsewhere. **What is the best way to compare Intune policies across tenants?** Compare the settings JSON as an opaque document rather than field by field. Normalize and hash it to detect that something changed, then diff for a human-readable explanation. This survives Microsoft adding new setting types, which a schema-aware comparer does not. **Should drift remediation be automatic?** Start in detect-only mode. Automatic remediation is reasonable for policies you authored and for baselines the client has explicitly signed off on, but it should never silently overwrite policies the customer created, and every write should land in an audit trail. ## Sources - Microsoft Learn: configurationPolicy resource type (Settings Catalog, Graph beta): https://learn.microsoft.com/graph/api/resources/intune-deviceconfigv2-devicemanagementconfigurationpolicy (read 2026-09-10) - Microsoft Learn: change notifications overview (the supported-resources list): https://learn.microsoft.com/graph/change-notifications-overview (read 2026-09-10) ## Related - Conditional Access baselines across MSP-managed tenants: https://rugged.sh/learn/conditional-access-baselines/ - Microsoft Graph throttling when you manage dozens of tenants: https://rugged.sh/learn/microsoft-graph-throttling/ - How to manage Microsoft 365 across many customer tenants: https://rugged.sh/learn/manage-multiple-microsoft-365-tenants/ _Published by rugged.sh, a multi-tenant control plane MSPs use to deploy and scale AVD and Windows 365 and to manage Microsoft 365 configuration across customer tenants. Priced per customer tenant, not per user (Microsoft 365 management: $10/tenant/month; Azure (AVD / Windows 365): $50/tenant/month; Microsoft 365 + Azure: $60/tenant/month), with a free tier for 1 tenant and 5 users. https://rugged.sh/_