Entra config drift: scenarios and how to detect it

2026-07-18 · ~5 min read · by the Just Software engineering team

"Config drift" sounds abstract until you've been bitten by a specific instance of it. This guide makes it concrete: the drift scenarios that actually occur in Entra ID tenants, what each one looks like when it happens, and the three practical approaches to detecting them — from reading audit logs to full configuration-as-code. It's the ground-level companion to the broader tracking and governing Azure changes guide.

Scenario 1: the Conditional Access policy that quietly changed

Conditional Access is where drift does the most damage, because CA policies are your tenant's access control posture, and editing them is trivially easy for anyone holding the right role.

The recurring patterns:

The troubleshooting exclusion that became permanent. Sign-ins are failing for a team; under pressure, an admin adds their group to a policy's exclusions "temporarily". The incident resolves, the exclusion stays. Six months later that group — which has since grown — bypasses MFA requirements, and nobody remembers why.
Report-only forever. A policy is created in report-only mode for evaluation and never flipped to enforced. Everyone believes the control exists; it observes and does nothing.
The disabled policy. During a suspected-outage panic, a policy gets switched off to rule it out as a cause. The panic ends; the policy doesn't come back.
Scope erosion. A policy targeting "all users" gets rescoped to specific groups during a change, and new-joiner groups never get added. Coverage silently decays as the organisation grows.
Break-glass drift in the other direction. Someone "tidies up" exclusions and removes the emergency access accounts from a block policy's exclusion list — creating the lockout risk the exclusion existed to prevent.

What makes CA drift dangerous is its silence: weakening a policy breaks nothing. There's no error, no ticket, no failed sign-in. The only observable effect is that something is now permitted which shouldn't be — which is only observed by an attacker or an audit.

Every OAuth consent grant changes what data can leave your tenant, and grants accumulate:

User consent to over-reaching apps. If user consent is enabled (even with limits), users grant real permissions to third-party apps at a steady trickle. Each grant is individually defensible; the accumulated surface is something nobody has reviewed.
Admin consent under time pressure. A vendor onboarding stalls until someone with Global Admin clicks "Grant admin consent" on a permission list they read for eight seconds. Application-level permissions (the ones that work without a signed-in user, like Mail.Read for the whole tenant) deserve minutes, not seconds.
Credentials added to existing app registrations. A new client secret on an existing, already-consented app registration is functionally a new set of keys to whatever that app can reach. Attackers who gain a foothold love this move precisely because it hides inside an app that already looks legitimate.
Orphaned apps. The integration is decommissioned; the service principal, its permissions and its credentials remain. Standing access with no owner is drift in its purest form.

Scenario 3: roles, groups and the rest

A quick tour of the remaining repeat offenders: privileged role assignments made "temporarily" outside PIM and never removed; security group membership changes where the group gates something important (app assignment, CA exclusions, RBAC); changes to the authentication methods policy or legacy MFA settings; cross-tenant access settings loosened for one partner collaboration and left broad; named locations edited so a "trusted location" now covers half a country. None of these announce themselves either.

Detection approach 1: audit logs

Everything above lands in the Entra audit log the moment it happens — with actor, timestamp, and typically the modified property values. Audit logs are your real-time detection layer and your forensic record. To use them well:

Export them first. Default retention (30 days with a premium licence) is shorter than the lifetime of most drift. Stream to Log Analytics or storage via diagnostic settings before anything else.
Alert on the small set of high-severity operations: CA policy create/update/delete, admin consent grants, credentials added to service principals or app registrations, privileged role assignments, changes to authentication methods policy. These are low-volume events; alerting on them is high signal, low noise.
Know the limits. Logs tell you a change occurred; they don't tell you whether it was sanctioned, and reconstructing full historical state from an event stream is impractical. Logs are necessary, not sufficient.

Detection approach 2: export-and-diff

The highest value-to-effort detection technique available: periodically export the configuration you care about as JSON via Microsoft Graph, store it with a timestamp, and diff consecutive exports.

Conditional Access policies, named locations, app registrations with their credentials and permission grants, directory role assignments and authentication methods policy are all a few Graph calls each (the Microsoft Graph PowerShell SDK covers all of them). A scheduled script that exports nightly and emails a diff when anything changed is a weekend project, and it catches every change regardless of who made it or how — portal, API, Microsoft support, compromised admin account alike.

Practical notes from teams who run this:

Normalise before diffing. Sort arrays and strip volatile metadata (timestamps, ETags) or you'll drown in false diffs.
Diff review needs an owner. A diff nobody reads is a snapshot archive, which is still worth having (it answers "what did this look like in March?") but detects nothing.
Store exports somewhere the admins being monitored can't quietly edit — a repo with history, or write-once storage. The record's value depends on its integrity.
The open-source ecosystem has ready-made help here: Microsoft365DSC can export large swathes of tenant configuration to a comparable format, and community tools exist specifically for CA policy backup and comparison. Evaluate them before writing everything yourself.

Detection approach 3: configuration as code

The strongest posture inverts the model: the repository becomes the source of truth, changes happen through pull requests, and any difference between repo and tenant is by definition drift.

Terraform (the azuread provider), Microsoft365DSC, and Graph-based deployment pipelines can all manage Entra configuration this way, with varying coverage. You get intent capture (the PR description), review (the approval), rollback (revert the commit), and drift detection (a scheduled plan/compliance run flags divergence) as properties of the workflow rather than bolted-on processes.

The honest costs: coverage is incomplete — not every Entra setting is expressible in every tool, so you'll run IaC for some surfaces and export-and-diff for the rest; the discipline cost is real — one "quick portal fix" outside the pipeline and your source of truth is lying until reconciled; and the skills requirement moves the work from admins to something closer to platform engineering. IaC pays off best for the configuration that changes deliberately and rarely — CA policies being the canonical example — and least for high-churn operational objects like group memberships.

A pragmatic combination

You don't pick one approach; you layer them by change severity:

Everything: audit logs exported to durable storage — the universal safety net.
Sensitive configuration (CA, app permissions, roles, auth methods): nightly export-and-diff with a human reviewing changes, plus real-time alerts on the highest-severity operations.
Deliberate, low-churn policy (CA above all): graduate to configuration-as-code when the team is ready.

Then close the loop organisationally: every detected change gets classified as expected (matches a ticket or PR) or unexplained (investigate — was it well-intentioned-but-unrecorded, or something worse?). The ratio of unexplained to expected changes is the single most honest metric of how much control you actually have over your tenant — and watching it fall as the practice beds in is one of the more satisfying experiences in this line of work.