Cloud drift is the gap between the intended state of cloud infrastructure and what is actually running. It happens when resources, configurations, or permissions change over time without being brought back under policy control, often creating avoidable spend, security exposure, and operational inconsistency.
Expanded Definition
Cloud drift describes divergence between a cloud environment’s approved baseline and the state that actually exists in production. That divergence can appear in infrastructure, identity and access settings, network rules, storage exposure, policy exceptions, or service configuration that persists after the original change window. It is broader than a one-time misconfiguration because the key issue is unmanaged change over time.
In practice, cloud drift is often discussed alongside configuration drift and policy drift, but the cloud setting adds scale, speed, and shared-responsibility complexity. A team may intend to enforce one IAM pattern, one encryption posture, or one network boundary, yet the live estate gradually accumulates exceptions. The common boundary mistake is treating drift as purely technical when it also reflects process failure, such as missing ownership, weak review, or inconsistent change control.
For a useful external reference on the identity side of cloud drift, see OWASP Non-Human Identity Top 10.
Examples and Use Cases
- A storage bucket is temporarily opened for troubleshooting and never returned to its intended access policy, leaving an avoidable exposure in place.
- An application team adds permissive firewall or security-group rules during a deployment, then the live network path remains broader than design documentation.
- Service account permissions are expanded to support a new workload and are not later reduced, so privilege accumulates outside the approved access model.
- Tags, regions, or resource classes drift away from standard architecture, making inventory, cost allocation, and control enforcement harder.
- Infrastructure-as-code templates are updated, but manual console changes continue in parallel, so the deployed state no longer matches the source of truth.
A common implementation trade-off is speed versus consistency: teams use short-lived exceptions to unblock delivery, but every exception increases the burden of reconciliation later. In cloud environments, that reconciliation matters because small discrepancies can spread across many accounts, subscriptions, or projects before anyone notices.
Security Implications
Cloud drift becomes a security problem when the live environment no longer reflects the controls that were assumed during design, review, or audit. The result is often hidden exposure rather than an obvious outage. Untracked permission growth can weaken least privilege, stale network exceptions can widen the attack surface, and forgotten storage or service settings can reveal data paths that teams believed were closed.
Drift also undermines detection and response. If the security team relies on a baseline that no longer matches production, alerts and reviews may miss the most relevant deviations. A practitioner observation that matters here is that drift is rarely one large failure; it is usually many small changes that look harmless in isolation but create material inconsistency at scale.
The operational symptom is usually mismatch: one view in code, another in dashboards, and a third in the live platform. That mismatch makes incident scoping slower, change attribution harder, and recovery less reliable.
Domain and Governance Relevance
Cloud drift matters because cloud governance depends on being able to prove what should exist, what does exist, and who can change it. Without that alignment, policy becomes advisory rather than enforceable. This is especially important where multiple teams, automation pipelines, and third-party services all touch the same environment.
In identity-heavy cloud estates, drift frequently shows up through permissions and trust relationships. Temporary roles become standing access, service identities keep obsolete rights, and approval workflows fail to capture exceptions that outlive the task they were created for. That makes drift a governance issue as much as a configuration issue, because the control failure is usually in ownership, review, and continuous reconciliation.
For NHI and agentic workflows, the relevance is sharper still: non-human identities often operate at machine speed, so permission drift can expand silently and persist longer than a human reviewer would expect. The practical question is not just whether the system was built correctly, but whether the live access model is still the one the organisation intends to trust.
Risk and Threat Considerations
Cloud drift creates material exposure when live cloud state diverges from approved controls and that divergence is not continuously detected. The main risk is silent control decay, where exceptions, permissions, and service settings accumulate until the environment no longer matches the security model that governance relies on.
Failure mechanism: Unreviewed manual changes, automation gaps, and inconsistent ownership allow state to drift away from policy. Attackers can then exploit broader-than-intended access, stale network paths, or exposed services that remain reachable because the live configuration was never reconciled.
Impact: The organisation can lose least-privilege discipline, expand blast radius, miss compliance obligations, and respond more slowly because the trusted baseline no longer reflects reality.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Cloud drift is often configuration drift across live assets and software. |
| 6 — Access Control Management | Permission drift often expands cloud access beyond intended privilege. | |
| Recommendation — Continuously compare cloud assets to hardened baselines and correct unauthorized configuration changes. Review and remove excess cloud access regularly to keep permissions aligned with least privilege. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Cloud drift reflects breakdowns in baseline control and change discipline. |
| PR.AC — Access Control | Drift in identities and permissions directly weakens access control assumptions. | |
| Recommendation — Enforce baseline change management so production state is reconciled against approved configurations. Revalidate cloud access rules and revoke standing exceptions that no longer have business justification. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Non-human identities and their privileges commonly drift without clear ownership. |
| Recommendation — Maintain an authoritative inventory of cloud NHIs and assign owners for periodic access reconciliation. | ||
Practitioner Guidance
What to watch for: Cloud drift deserves attention when change is happening faster than review, or when teams depend on manual console edits to finish deployments. Those are the conditions where divergence tends to become normalised rather than corrected.
Governance implication: Ownership must extend beyond deployment into reconciliation. If no team is clearly accountable for comparing intended state to live state, drift becomes an accepted operating condition rather than an exception.
Practitioner takeaway: Treat drift as a control-state problem, not just a configuration defect, because the real failure is the environment quietly leaving the boundary of what the organisation believes it has approved.
