Detecting Intune configuration drift across customer tenants

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.

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 people ask

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's behaviour described above was read from these pages on the dates shown. Claims that come from our own testing against a live Azure subscription carry that date inline.

• Microsoft Learn: configurationPolicy resource type (Settings Catalog, Graph beta) (read September 10, 2026)
• Microsoft Learn: change notifications overview (the supported-resources list) (read September 10, 2026)

Related

• GovernanceConditional Access baselines across MSP-managed tenants
• PlatformMicrosoft Graph throttling when you manage dozens of tenants
• GovernanceHow to manage Microsoft 365 across many customer tenants