Is configuration drift the same as configuration vulnerability?

Related but distinct. A configuration vulnerability is a setting that's currently misconfigured — drift is the process of moving away from a secure baseline. Drift can produce vulnerabilities; not every vulnerability is the result of drift.

Does drift detection require infrastructure-as-code?

Not necessarily. Lavawall®'s approach is snapshot-based: capture today's state as the 'current correct' state, then flag anything that changes. For MSPs without the engineering capacity to maintain explicit IaC baselines, this is a more practical pattern.

How often should drift be checked?

For high-severity object types (CA policies, role assignments), continuous polling at 15-60 minute intervals is appropriate. For lower-severity types, hourly to daily is fine. Lavawall® uses configurable per-object-type intervals.

What is configuration drift?

Definition

Configuration drift is the gradual divergence of a system's actual configuration from its intended baseline. The term originated in infrastructure-as-code and traditional system administration but has become especially relevant in cloud environments where configuration is the security perimeter and changes happen continuously.

In Microsoft 365, Entra ID, and Azure, configuration drift takes the form of policies modified or disabled, role assignments added or removed, app registrations created with new scopes, Intune profiles loosened, NSG rules opened — small changes that individually seem benign but cumulatively erode the security posture.

Why it matters

Drift is the silent killer of security posture. A tenant that started 2024 with a hardened baseline can end 2026 with that baseline measurably eroded — not from a single attack, but from accumulated “temporary” changes that never got reverted, junior-admin shortcuts, and well-intentioned modifications that bypassed the change-management process.

The specific failure modes drift produces:

Audit failures. Auditors expect tenant configuration to match documented baselines. Drift means the tenant doesn't match. CMMC 2.0 / SOC 2 / ISO 27001 / HIPAA all care about this.
Stealthy compromise. Attackers who gain a foothold often modify configuration to maintain access. Drift detection that flags “CA policy disabled by user X at 2am from a new IP” catches the attacker before the encryption payload runs.
Cumulative privilege creep. Service principals added to Owner role for a one-time integration; admin elevation granted “just for today.” Without active drift detection, those privileges persist indefinitely.
Inconsistent client baselines. For MSPs serving many clients, drift means each tenant's actual security posture diverges from what was documented at onboarding. Multiply by N clients and the visibility problem becomes unmanageable.

How drift detection works

Baseline. The intended configuration is captured — either declaratively (an explicit list of expected settings) or implicitly (a snapshot of “the state at onboarding, this is correct”).
Continuous comparison. Actual state is captured on a schedule and compared against baseline (or against the previous snapshot — Lavawall®'s approach is the latter, since baselines are hard to maintain across many tenants).
Severity assessment. Not every difference matters equally. Disabling CA = critical; renaming a named location = informational. The drift detector has to triage automatically.
Attribution. “Who changed this” matters as much as “what changed.” Drift detection has to correlate with the audit log.
Remediation. The detector has to offer a path back. Detection without remediation is just a more efficient way of being scared.

How Lavawall® helps with configuration drift

Lavawall®'s M365 / Entra / Azure configuration change monitoring & rollback module is built around drift detection. It snapshots ~25 object types across Microsoft 365, Entra ID, Intune, and Azure subscriptions on a configurable schedule. Each snapshot is compared against the previous one; differences are computed as JSON Patch operations and rated for severity.

The change feed is the primary drift-detection surface. Operators see every change with severity, the field paths that changed, the JSON-level diff, the user who made the change (correlated from the audit log), the IP they made it from, and the country that IP belongs to.

Drift remediation is the rollback workflow: select a change (or all changes by a user, or an entire object's drift to a point in time), generate a plan, approve it, and execute it. Dry-run mode lets you preview every Graph API call before any are made — the difference between “rollback” and “outage waiting to happen.”

Frequently asked

Is configuration drift the same as configuration vulnerability?: Related but distinct. A configuration vulnerability is a setting that's currently misconfigured — drift is the process of moving away from a secure baseline. Drift can produce vulnerabilities; not every vulnerability is the result of drift.
Does drift detection require infrastructure-as-code?: Not necessarily. Lavawall®'s approach is snapshot-based: capture today's state as the “current correct” state, then flag anything that changes. For MSPs without the engineering capacity to maintain explicit IaC baselines, this is a more practical pattern.
How often should drift be checked?: For high-severity object types (CA policies, role assignments), continuous polling at 15-60 minute intervals is appropriate. For lower-severity types, hourly to daily is fine. Lavawall® uses configurable per-object-type intervals.