Is configuration drift the same as configuration vulnerability?

These concepts are related but distinct. A configuration vulnerability represents a currently misconfigured setting; drift is the process of moving away from a secure baseline. Drift can produce vulnerabilities, but not every vulnerability results from drift.

Does drift detection require infrastructure-as-code?

Not necessarily. Lavawall® employs snapshot-based approaches: capture today's state as current-correct, then flag any changes. For MSPs lacking engineering capacity to maintain explicit IaC baselines, this approach is more practical.

How often should drift be checked?

High-severity object types (CA policies, role assignments) warrant continuous polling at 15 to 60 minute intervals. Lower-severity types can use hourly to daily checks. Lavawall® allows configurable per-object-type intervals.

What is configuration drift

What is configuration drift?

Configuration drift is the gradual divergence of a system's actual configuration from its intended baseline. In Microsoft 365, Entra ID, and Azure, drift means policies disabled, role assignments added, app registrations created with broad scopes, and NSG rules opened. It is how secure tenants quietly become insecure ones.

Start free, no credit card See how detection works

Baseline · continuous comparison · severity · attribution · rollback

Definition

Configuration drift describes how systems gradually move away from their intended settings. The concept originated in infrastructure-as-code practices, but it is now critical in cloud environments where configuration forms the security boundary and changes occur continuously.

In Microsoft 365, Entra ID, and Azure environments, drift manifests through disabled policies, modified role assignments, newly created app registrations with expanded permissions, loosened Intune profiles, and opened NSG rules. Individual changes may seem minor, but collectively they degrade security posture.

Why it matters

Security posture erosion happens silently through configuration drift. An organisation with a hardened baseline in 2024 may find that baseline measurably compromised by 2026, not from a single attack but from accumulated "temporary" changes never reverted, administrative shortcuts, and modifications that bypassed change-management processes.

Specific failure modes drift produces include:

Audit failures. Auditors expect tenant configuration to match documented baselines. Drift creates misalignment, causing failures under CMMC 2.0, SOC 2, ISO 27001, and HIPAA standards.
Stealthy compromise. Attackers who gain access often modify configuration to maintain persistence. Drift detection that identifies events like "CA policy disabled by user X at 2am from a new IP" reveals attacks before destructive payloads execute.
Cumulative privilege creep. Service principals added to Owner roles for one-time integrations, or admin elevation granted temporarily. Without active drift detection, these privileges remain indefinitely.
Inconsistent client baselines. For MSPs managing multiple clients, each tenant's actual security posture diverges from documented onboarding state. Multiplied across N clients, this creates an unmanageable visibility problem.

How drift detection works

Baseline. Intended configuration is captured either explicitly (documented expected settings) or implicitly (a snapshot of onboarding state, treated as correct).
Continuous comparison. Actual state is captured on a schedule and compared against the baseline or previous snapshots. Lavawall® uses the latter approach, since maintaining baselines across many tenants is challenging.
Severity assessment. Not all differences carry equal weight. Disabling Conditional Access ranks as critical; renaming a named location is informational. The detector must automatically triage.
Attribution. "Who changed this" matters as much as "what changed." Drift detection must correlate with audit logs.
Remediation. Detection requires a remediation path. Detection without remediation only creates more efficient anxiety.

How Lavawall® helps with configuration drift

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

The change feed serves as the primary drift-detection surface. Operators view every change with its severity level, the field paths modified, the JSON-level differences, the user who made the change (correlated from audit logs), their IP address, and the IP's geographic location.

Drift remediation operates through rollback workflows. Select a change (or all changes by a user, or an entire object's drift to a specific point in time), generate a plan, approve it, and execute it. Dry-run mode previews every Graph API call before execution, distinguishing between an actual rollback and an outage waiting to happen.

Start free →

Frequently asked

Is configuration drift the same as configuration vulnerability?: These concepts are related but distinct. A configuration vulnerability represents a currently misconfigured setting; drift is the process of moving away from a secure baseline. Drift can produce vulnerabilities, but not every vulnerability results from drift.
Does drift detection require infrastructure-as-code?: Not necessarily. Lavawall® employs snapshot-based approaches: capture today's state as current-correct, then flag any changes. For MSPs lacking engineering capacity to maintain explicit IaC baselines, this approach is more practical.
How often should drift be checked?: High-severity object types (CA policies, role assignments) warrant continuous polling at 15 to 60 minute intervals. Lower-severity types can use hourly to daily checks. Lavawall® allows configurable per-object-type intervals.