Configuration drift occurs when live systems gradually diverge from the approved baseline through manual changes, exceptions, or inconsistent updates.
Configuration drift is the gradual divergence between an approved secure configuration and the way the live system or cloud resource is actually running. In plain language, it means the environment slowly stops matching the intended baseline because of manual changes, exceptions, emergency fixes, or inconsistent updates.
Configuration drift matters because security programs depend on predictable control states. If servers, cloud policies, container settings, or workload identities drift away from the approved design, exposures can appear without anyone deliberately choosing them.
It also matters because drift makes troubleshooting, auditing, and incident response much harder. Teams may believe a control is in place because it was documented correctly months ago even though the live environment no longer matches that design.
Configuration drift appears in cloud infrastructure, containers, endpoint fleets, identity policy, Cloud Security Posture Management, and infrastructure-as-code programs. Teams usually notice it when a live resource behaves differently from the approved template, baseline, or policy expectation.
It connects closely to Security Baseline, Change Management, Security Misconfiguration, Secure Configuration, and Patch Management.
It is a common root cause behind environments that were once secure on paper but no longer match the intended model in production.
| Source | How it creates drift |
|---|---|
| Manual changes | Hot fixes that never return to baseline. |
| Emergency exceptions | Temporary access that becomes permanent. |
| Inconsistent templates | Different versions applied across teams. |
| Shadow automation | Scripts that bypass approved pipelines. |
Drift control usually works best when the intended state is expressed in version-controlled templates, the live state is checked continuously, and exceptions have owners and expiration dates. That keeps drift from becoming an invisible backlog of security debt.
Teams should distinguish between harmless metadata differences and control-relevant drift. A missing tag may be operational debt, while a public endpoint, disabled log, or expanded role can directly change security risk.
A cloud storage bucket was originally private, but a later manual change opened broader access for troubleshooting and the setting was never restored. Months later, the live environment no longer matches the documented security baseline, and the team falsely assumes the original protection still exists.
Configuration drift is not the same as an approved change. Approved change can be healthy and controlled, while drift describes divergence that is no longer aligned with the desired baseline or no longer properly governed.
It is also broader than one misconfiguration. Drift is the accumulation of differences over time, often across many resources or settings.
Configuration drift is also not limited to cloud infrastructure. It can affect identity settings, endpoint policy, access rules, and any environment where the live state changes faster than governance catches up.