Configuration Drift in Microsoft 365: How to Detect and Fix It

You set up Conditional Access policies last month. You deployed Intune configurations across your tenants. Everything was locked down and compliant. Then someone changed a policy, a new admin adjusted a setting, or Microsoft updated a default. Now your security baseline is silently out of sync.

TL;DR: Configuration drift, the gradual divergence between your intended security settings and what is actually deployed, is one of the most common and least visible risks in Microsoft 365. We built automated drift detection to help us (and our users) stay on top of it.

What is configuration drift?

Configuration drift happens when the actual state of your Microsoft 365 environment no longer matches your intended configuration. It is the gap between "what should be deployed" and "what is actually deployed", sometimes called Microsoft 365 policy drift or, on the device side, Intune configuration drift.

Common causes:

• Manual changes by admins who bypass change management
• Microsoft updates that modify default behaviors
• Tenant-level overrides that conflict with your baseline
• Failed deployments that partially apply configurations
• Multiple admins making independent changes without coordination

In a single-tenant environment, you can usually keep track. When you manage dozens or hundreds of tenants, it gets out of hand quickly.

The quiet part

The frustrating thing about configuration drift is not that configurations change. It is that they change silently. There is no built-in alert in Microsoft 365 that tells you "your Conditional Access policy no longer matches your baseline."

Here is a scenario we have seen more than once:

1. You deploy a Conditional Access policy requiring MFA for all administrators
2. Three weeks later, an admin adds an exclusion for a service account
3. That exclusion creates a gap
4. Nothing flags the change

Across the tenants we have worked with, drift from approved baselines is one of the most common findings. Policies that were compliant at deployment are often no longer compliant a few weeks later. It is not negligence, it is just the reality of environments with multiple admins and constant change.

How we think about drift detection

We are not claiming to have solved this perfectly, but here is the approach we have landed on after iterating on it for a while.

Baselines as the source of truth

Everything starts with a baseline, your approved configuration state. You can create one from a discovery scan of your current tenant, from a template you have built, or by copying from another tenant that is already in good shape.

The baseline captures every policy setting in detail. Comparing the live tenant against it makes differences visible.

Automated scanning

Manual audits catch drift at a point in time. Scheduled scanning catches it continuously. We run drift scans on a schedule so changes surface within hours rather than at the next quarterly review.

Granular remediation

Finding drift is only useful if you can do something about it. We built three options:

• Push an entire baseline to bring a tenant back into alignment (with a preview of what will change first)
• Push a single policy when only one thing drifted
• Accept the current state when the drift was intentional (updating the baseline to match reality)

The push logic only touches policies that have actually drifted. Unchanged configurations are left alone.

What drift looks like in practice

When a scan completes, you get a straightforward summary:

For drifted policies, you get a side-by-side diff showing exactly which settings changed and how.

The multi-tenant reality

For a single tenant, you could check this manually. Open the admin portal, compare settings against your documentation, note the differences. An hour or two of work.

For 50 tenants? That is a lot of hours. Most teams do this quarterly at best, which means drift goes unnoticed for months. Automated scanning helps, but it is worth being honest: no tool catches everything, and the real work is still in deciding what to do about the drift you find.

What we cover

Drift detection currently covers:

• Conditional Access policies - MFA requirements, device compliance, location-based access
• Intune Settings Catalog - Device configuration policies

Each type has its own comparison logic because Microsoft's Graph API handles them differently. Settings Catalog policies in particular require a full replacement rather than incremental updates, which was one of the more tedious parts to get right.

Configuration drift and Identity Security Posture Management (ISPM)

Identity Security Posture Management (ISPM) is the practice of continuously assessing and hardening your identity configuration. In Microsoft 365 that means Entra ID, Conditional Access, and admin roles, measured against best-practice recommendations. ISPM answers "is this configured well?"

Drift detection answers the adjacent question ISPM usually misses: has a setting changed away from the state you approved? ISPM can tell you a Conditional Access gap exists today. Drift detection tells you the policy was compliant three weeks ago and someone added an exclusion since. The two are complementary, posture management for the quality of the configuration, drift detection for its stability over time.

A related but distinct question is conformance: does a tenant match your standard regardless of how its policies are named? If you are validating tenants you did not build yourself, see baseline conformance, which compares the underlying settings rather than the policies that deployed them.

Frequently Asked Questions

How often should you scan for configuration drift?

Daily works for most organizations. High-security environments or tenants with many admins might want more frequent scans. The key is consistency.

Does fixing drift require downtime?

No. Policy updates through Microsoft Graph API are applied live. That said, always review the preview before pushing changes to Conditional Access policies, since those directly affect user access.

Can you track who caused the drift?

Drift detection shows what changed, not who changed it. For attribution, pair it with Microsoft 365 audit logs.

What if drift is intentional?

Not all drift is bad. Sometimes an admin makes a legitimate change that should become the new baseline. Accepting the current state updates your baseline to match, acknowledging the change as approved.

How is this different from Microsoft Secure Score?

Secure Score measures your tenant against Microsoft's general recommendations. Drift detection measures your tenant against your own approved baseline. Different questions, both useful.