Infrastructure as code drift

Expanded Definition

Infrastructure as code drift is the divergence between a declared infrastructure state and the actual deployed state after templates are reused, edited, hotfixed, or partially applied. In NHI and cloud operations, drift is especially dangerous because identity bindings, secret references, network paths, and permission scopes can change outside the reviewed code path.

Definitions vary across vendors, but the operational meaning is consistent: the code says one thing, the environment does another, and security posture erodes silently over time. This matters most in environments that rely on reusable modules, CI/CD pipelines, and policy-as-code controls, where a small exception can be copied across many workloads. NIST Cybersecurity Framework 2.0 treats continuous monitoring and change governance as core discipline, which is why drift belongs in both configuration management and identity governance discussions. When drift touches NHI controls, the issue is often not the template itself but the gap between intended privilege and deployed privilege.

The most common misapplication is treating drift as a purely infrastructure reliability problem, which occurs when teams ignore the security impact of changed secrets, roles, or trust relationships.

Examples and Use Cases

Implementing drift control rigorously often introduces review overhead and reconciliation work, requiring organisations to weigh deployment speed against the cost of preventing repeated misconfigurations.

• A Terraform module is updated to remove broad storage access, but older workspaces keep the prior role assignment, creating hidden excess privilege.
• A Kubernetes manifest is patched in production to restore service availability, but the patch bypasses code review and leaves a long-lived API key exposed.
• A CI/CD pipeline template is reused across environments, yet one environment retains an older secret reference outside the secrets manager, creating inconsistency between policy and runtime.
• An organisation detects repeated authentication failures and discovers that a service account was manually exempted from rotation controls, even though the source repository still shows compliant settings.
• A post-incident review links the issue to the pattern described in the Salesloft OAuth token breach, where a changed control surface enabled token theft and downstream access.

Drift also appears in policy enforcement systems. The NIST Cybersecurity Framework 2.0 reinforces the need to identify, protect, detect, and respond to configuration changes rather than assuming declared state remains true.

Why It Matters in NHI Security

Drift is one of the fastest ways to turn a single identity mistake into a repeating control failure. If one service account is over-privileged in a template, that error can propagate through every cloned environment, every ephemeral workload, and every redeployment. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, while 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools. Those conditions make drift more than a hygiene issue, because each unreviewed change can expand attack paths and weaken offboarding, rotation, and zero-trust enforcement.

For NHI governance, drift also undermines trust in audit evidence. If the repository, approval record, and live environment do not match, responders cannot rely on static review alone. That is why drift management belongs alongside continuous discovery, entitlement review, and secret lifecycle control, and why frameworks such as NIST Cybersecurity Framework 2.0 are relevant when defining operational monitoring expectations. Organisations typically encounter the consequence only after a breach review or access investigation, at which point infrastructure as code drift becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Low-Code Integration
• How do teams know whether infrastructure as code is increasing privilege risk?
• What breaks when infrastructure-as-code is not part of cloud security architecture?
• Infrastructure As Code Privilege