Overview
Configuration drift is the gap between what a device's security policy is supposed to be and what it actually is, right now. It's rarely caused by one dramatic event. It accumulates from small, individually reasonable changes that nobody tracks back against the original baseline. A fleet that was fully compliant on the day a policy was set can be meaningfully out of compliance a few months later, with no single moment where that happened.
How drift actually happens
Drift almost never comes from someone deliberately weakening security. It comes from ordinary operational activity that has a side effect nobody's tracking.
- Manual troubleshooting. A technician disables a firewall rule or local admin restriction to resolve a ticket, intending to revert it, and doesn't.
- OS and application updates. An update resets a setting to its default, silently undoing a custom baseline.
- Exceptions that outlive their reason. A temporary exemption for one device during a migration never gets removed once the migration is done.
- New devices enrolling slightly out of spec. A device provisioned through a slightly different process than usual doesn't pick up the full baseline.
- Shadow changes. Local changes made outside the managed process entirely, such as a user with local admin rights adjusting a setting themselves.
Why it matters more than it looks like it should
Drift is easy to underestimate because each instance is small. But it matters for two specific reasons.
- It's where a lot of real incidents start. A compromised endpoint frequently traces back to a control that was supposed to be enforced and had quietly drifted out of enforcement, not to a control that was never designed in the first place. Attackers don't need every device to be exposed; they need one drifted device to find.
- It's the gap between your documented policy and your actual posture. Security policy documents and compliance frameworks describe what's supposed to be true. Drift is what makes that description increasingly inaccurate over time without anyone deciding that it should be. An organization can have a genuinely well-designed policy and a genuinely non-compliant fleet at the same time, simply because nothing is checking whether the two still match.
How drift is typically detected, and where that falls short
Most organizations catch drift one of two ways: a scheduled audit, or an incident that exposes it. Both have the same structural problem. They find drift after it's existed for a while, not when it happens.
A quarterly audit that finds a device out of compliance can't tell you whether that device drifted the day after the last audit or the day before this one, which matters, because that's the difference between a small exposure window and a multi-month one. And audits sample; they rarely check every device against every control, which means some amount of drift is essentially invisible until it causes a problem.
Detecting drift continuously instead
The alternative is treating policy compliance as something checked continuously against a declared baseline, rather than something verified periodically. This requires three things to exist together.
- A clear, versioned baseline. A specific, retrievable definition of what "compliant" means for a given device or group, not a general policy document.
- Regular, automated comparison. Comparison of actual device state against that baseline, not relying on someone remembering to check.
- A record of what drifted. When it was detected, and how it was resolved, so the detection produces evidence, not just a fixed device with no trace of what happened.
Why the record matters as much as the fix
The third point matters as much as the first two. A drift-detection process that silently fixes problems without logging them solves the immediate exposure but leaves you unable to answer how often this happens and what usually causes it, which is exactly the pattern you'd want to catch before it becomes a bigger problem.
What good drift handling looks like day to day
- Deviations are checked against baseline frequently enough that the exposure window is measured in hours, not weeks.
- Low-risk, well-understood drift, such as a setting reset by a routine update, gets corrected automatically.
- Higher-risk or unusual drift, such as an unexpected change to admin group membership, gets flagged for review rather than silently auto-corrected.
- Every drift event, auto-corrected or flagged, is retained as a record, so patterns become visible over time rather than each instance being an isolated surprise.
Why this connects to policy-as-code and review
Drift detection works best when there's a clear, versioned baseline to detect drift against, which is exactly what declaring policy as structured configuration provides. It's much harder to detect that a device no longer matches its intended policy when the intended policy only exists as institutional memory or a settings page with no history. The two practices reinforce each other: declared, reviewed policy gives drift detection something precise to check against, and continuous drift detection is what keeps a declared policy meaningful after the day it was approved.
Related resources
- See the GitOps for Endpoint Compliance pillar guide for how declared policy and reconciliation work together to close this gap.
- See Audit Evidence from Versioned Security Workflows for how drift detection records become audit evidence.