Gartner’s How to Achieve the Minimum Viable AI Governance
Blog
Change Control and Configuration Drift Management
Configuration Drift
Endpoint Hardening
Exposure Management & CTEM
Security Misconfigurations
Configuration drift is usually described as a hygiene problem. That puts it too gently. In modern environments, configuration drift is a change management problem. It is the gradual erosion of the security state you thought you had. It's caused by updates, overrides, temporary exceptions, policy conflicts, redeployments, and ordinary operational stress.
The policies are still intact. The tools are still licensed. The dashboards may still be green. But the environment is no longer as hard as you think it is.
A 2026 Reach Security study found that 97% of organizations experienced incidents or near misses related to misconfiguration in the past 12 months, with remediation taking more than 8 days, on average.
At the same time, Absolute Security reports that one in five enterprise endpoints is outside a protected, enforceable state on any given day. On average, an enterprise device spends some 76 days per year outside of its intended security state.
Configuration Drift Is Not Just Deviation from Baseline
Most definitions of drift are technically correct and operationally incomplete. NIST’s guidance on security-focused configuration management defines configuration drift management as the effort to orchestrate and oversee system settings with the goal of achieving adequate security while supporting business functionality and services.
CISA’s Configuration Settings Management guidance describes drift in practical terms as the gap between desired state and actual state, and makes clear that attackers target improperly configured assets because they are easier to exploit.
That does not mean every difference from the baseline is drift. A deviation may be intentional, approved, and necessary for the system or business process it supports. The security problem begins when the effective state diverges from the intended state without a current justification.
In that sense, configuration drift is better understood as unjustified variance from the intended security state, not simply variance from a standard configuration.
As the old saying goes, change is the only constant. A secure state is defined. Then the environment changes. Updates shift defaults. A support team adds an exclusion. A new app needs broader permissions. A GPO or Intune policy loses precedence. A patch rollback reopens a setting. A re-imaged endpoint comes back with an older template. A cloud-connected control stops reporting.
Nothing dramatic happens. No breach yet. But the secure state is weaker than it was.
Operationalize continuous compliance across CIS, NIS2, and MITRE
Stop Drift Before It Becomes Exposure
Get the Guide
Consider a simple example. An organization requires the host firewall to be enabled across its Windows estate. Months later, an application deployment disables a firewall profile on 180 endpoints to resolve a connectivity issue. The security policy still exists, and the management console may still show those systems as targeted by it. But the effective security state has changed.
Finding the deviation is only the first step. The organization still needs to determine what changed it, whether any of those systems legitimately require an exception, restore the intended state everywhere else, and verify that the correction survives subsequent deployments and policy refreshes. Otherwise, the same drift can simply return.
The More Mature the Stack, the More Dangerous Drift Becomes
Security leaders often assume drift is mostly a problem for immature programs. In reality, mature environments may be more exposed to drift because they have more tooling, more policy layers, more integrations, more delegated administration, and more change velocity.
According to Gartner, "cybersecurity leaders have a mean of 43 cybersecurity tools in their product portfolio." With a regular update cadence, those tools result in more than 700 production changes each year, on average. That's an incredible amount of change to manage safely - and that's just among the tools that are actually designed to improve security. Across the broader technology stack, those numbers explode, providing a huge amount of places for drift to hide:
- Policy precedence
- Role changes
- Agent health
- Exclusions and overrides
- Inherited identity permissions
- Deployment templates
- 3rd-party management tools
- Emergency operational decisions that never got rolled back
It should come as no surprise then that in over 90% of breaches, preventable gaps such as limited visibility, inconsistently applied controls, or excessive identity trust play a key role in the intrusion.
Not all of those are "configuration drift" in the narrow sense. But many are the downstream result of it.
Configuration Drift Management Is Really About Preserving Trust In Security Controls
Controls can exist on paper and still fail in practice. ISACA’s 2026 piece on Microsoft Defender hardening makes this point well, explaining the need for enforceable controls with evidence, rollback capability, and sustained drift visibility
What security teams are really trying to preserve is not configuration purity. It is trust in the operating state of the environment. Trust that baseline policies were actually applied. Trust that exceptions are known and time-boxed. Trust that changes are authorized. Trust that reporting still reflects reality. And trust that curbing drift will not adversely affect production.
That is why configuration drift management is more a discipline in change control than compliance reporting.
Mondoo’s 2025 State of Vulnerability Remediation report found that 44% of respondents see vulnerabilities reintroduced during redeployment, while 40% said more than 5% of vulnerabilities recur after remediation.
When the environment repeatedly reintroduces an insecure state, you have a governance loop problem.
The image may be wrong, the policy baseline stale, or the exception process too loose. The change process may be bypassed, the rollback path may feel safer than the forward path, or the tool may report that a setting is “set” without proving it is enforced. And if the control plane itself is not hardened, it can reintroduce the same weakness at scale.
To get ahead of the problem, ask yourself which:
- Controls are most likely to silently decay between reviews?
- Changes are being introduced without durable validation?
- Exceptions are still active beyond their business justification?
- Controls look compliant but are not reliably enforceable?
- Forms of drift most directly expand the attack surface or identity trust?
- Business processes are creating the most policy entropy?
The Architecture of Good Configuration Drift Management
We've focused a lot on enforcement in this article, and rightfully so. But it should not be forgotten that a good amount of the work involved in proper configuration drift management starts at the design stage. Policies must be designed thoughtfully and practically.
If your policies are not themselves sufficiently thorough or strict, you can have policy conformance without delivering any real security assurance. A system can be compliant and still be operationally weak. Which is why teams should regularly review not only their drift but the strength and resilience of their defined baselines.
With a strong policy design in place, good drift management is mostly a function of your diligence in the following six practices.
1. Define a meaningful desired state
CISA’s guidance emphasizes establishing and maintaining secure images, approved configuration checklists, and authoritative desired state definitions per device role.
Good teams go further. They ensure that the desired state reflects actual operating conditions, approved exceptions, and business context - not just vendor recommendations copied into a spreadsheet.
If the desired state is not realistic, it will be bypassed. Policies must be set with practicality in mind.
2. Separate baseline from variance
Every environment has justified differences. The problem starts when those differences are unauthorized, unexplained, or allowed to persist beyond their justification.
Having clearly defined and well-respected ownership is particularly critical. Some drift originates in support, some in engineering, some in procurement, some in identity administration, some in endpoint operations.
If you do not know which workflow generated the drift, you do not know how to reliably prevent or remove it.
Once found, drift should be categorized by the specific failure mechanism:
- Baseline never applied
- Baseline applied, then overridden
- Temporary exception not removed
- Reporting/control health degraded
- Redeployment reverted security state
- Policy conflict changed effective setting
- Unmanaged asset fell outside control plane
Finding drift tells you what is wrong. Classifying the drift mechanism tells you what has to change so it does not happen again. Otherwise teams can repeatedly remediate the endpoint while leaving the mechanism that recreated the exposure untouched.
3. Monitor for enforceability, not just presence
A setting that was once applied is not the same thing as a setting that still governs behavior.
Control health, policy precedence, reporting freshness, endpoint reachability, and actual protective effect matter more than whether a management system shows the right checkbox.
Recurring drift is rarely a remediation-volume problem. It is evidence that the generating mechanism remains intact.
It may sound dramatic, but you'd do well to treat recurrence as a board-level signal. If the same class of drift keeps returning, you are not closing risk. You are circulating it.
4. Measure and reduce drift half-life
The risk of drift is not only what changed. It is how long the weakened state existed before anyone knew.
That is why NIST’s continuous monitoring guidance remains relevant: organizations need ongoing awareness of security, vulnerabilities, and threats to support risk decisions rather than relying on point-in-time reviews.
Drift half-life is the time it takes an organization to eliminate 50% of a deviation cohort. Half-life is your starting point and a key health metric, but you should not stop there. You'll want to separately track the long tail, such as the percentage still unresolved after 7, 30, or 90 days.
This changes what “good” configuration drift management looks like. Two organizations may experience the same number of configuration deviations in a month, but carry very different risk. If one typically leaves drift in place for 30 days while the other detects and corrects it within hours, their finding counts may look similar while their exposure is not.
That makes drift half-life a more useful operational measure than a point-in-time compliance percentage. The objective is not necessarily to prevent every deviation from occurring. In a changing environment, that may be unrealistic. The objective is to continuously compress the amount of time that security-relevant drift is allowed to persist.
A rising drift half-life is also an early warning that the change-control system itself is degrading. Detection may be slowing, exceptions may be accumulating, remediation may be getting stuck, or controls may no longer be reliably enforceable. The metric therefore measures more than configuration hygiene – it measures how quickly the environment can recover its intended security state after change.
5. Build safe remediation paths
A configuration drift management program only works if operators trust the correction path.
If every reversal risks outages, business teams will delay fixes, widen exceptions, and normalize weak state. Remediation needs versioning, rollback, visibility, and enough context that people can act without guessing.
6. Harden the control plane itself
If your endpoint management system, identity policy plane, or configuration orchestration layer is under-governed, then drift can be introduced centrally and at scale.
For example, temporary exceptions are like ticking time bombs. They are waiting to be forgotten and to become permanent; which is why conscientious teams review them regularly.
From a process point of view, the piece is put in motion by time-boxing exceptions as they first emerge. When those exceptions reach their specified expiration dates, they need to be formally reapproved or altogether removed.
A Change-Aware Approach to Drift
Drift management cannot stop at observation. A system that continuously discovers deviations but leaves correction to tickets and periodic cleanup still allows the exposure window to accumulate.
Which is why the real measure of configuration security is not whether the environment reached a secure state, but whether that state survives change.
Systems will be patched, re-imaged, upgraded, integrated, exempted, and administered. Configuration drift management is the discipline that keeps those ordinary changes from quietly becoming security regressions.
The objective is controlled variance, safe correction, and a security state that continuously reasserts itself through the next update, next exception, next rollout, and next admin change.
FAQ
How should security teams distinguish acceptable configuration variance from configuration drift?
The distinction is authorization plus lifecycle. A configuration difference is acceptable variance when it has a documented business or technical justification, an accountable owner, appropriate compensating controls where necessary, and a defined review or expiration condition. It becomes problematic drift when the difference is unauthorized, unexplained, no longer justified, or persists after the condition that required it has disappeared. Mature programs therefore evaluate variance in context rather than treating every deviation from a baseline as an equivalent security failure.
Who should own configuration drift when multiple systems can change the same setting?
Ownership should follow the mechanism that governs the setting, not simply the team that discovers the deviation. An endpoint setting might be influenced by GPO, MDM, an endpoint management platform, application installation, local administration, deployment tooling, or an exception workflow. Security can define the required control state, but remediation ownership must account for which system actually has authority over that state. Otherwise teams can repeatedly correct an endpoint while another control plane continues putting the insecure configuration back.
Why does configuration drift sometimes return immediately after remediation?
Recurring drift usually indicates that the endpoint is not the real source of the problem. A policy conflict, deployment template, management tool, inherited permission, exception, or other upstream mechanism may still be asserting the unwanted state. Correcting the endpoint removes the symptom but leaves the generating mechanism intact. Recurrence should therefore trigger root-cause investigation rather than simply another remediation cycle.
How should temporary configuration exceptions be managed?
Treat exceptions as expiring changes rather than permanent exclusions from policy. Each exception should have a specific justification, owner, scope, approval record, expiration condition, and expected return state. The important control is what happens at expiry: the environment should either return to the desired state or require an explicit decision to renew the exception. An exception that can survive indefinitely without reassessment is effectively an undocumented alternative baseline.
What should security teams measure to determine whether configuration drift management is improving?
Finding counts are weak evidence because the same number of deviations can represent very different levels of exposure. More useful measures include drift half-life, recurrence rate, exception age, percentage of deviations with an identified generating mechanism, and the proportion of controls whose effective state can be continuously verified. These measures expose whether the organization is shortening the period in which insecure states persist and eliminating the mechanisms that cause them to return.
When is it safe to automate configuration drift remediation?
Automation is strongest when the desired state is unambiguous, the cause of the deviation is understood, dependencies can be evaluated, the change can be validated after execution, and a safe recovery path exists. Higher-risk changes should use staged deployment, maintenance windows, approval gates, or other controls appropriate to their operational impact. The objective is not to automate every correction. It is to automate the changes for which the organization can establish enough context and reversibility to make remediation repeatable without transferring security risk into availability risk.
About Author
