Terraform Drift

Expanded Definition

Terraform drift is the divergence between the infrastructure state declared in code and the environment actually running in production. In NHI and cloud governance contexts, the term matters because drift can affect not only servers and networking but also service accounts, IAM bindings, secrets storage, and agent permissions that were supposed to be created or constrained by the sanctioned module path. The issue is not simply that a resource changed; it is that the change escaped the lifecycle controls that make infrastructure auditable, reproducible, and safe to remediate. Definitions vary across vendors on whether drift includes expected manual hotfixes, but in mature practice the operational meaning is clear: unmanaged deviation from approved state. The control objective aligns with NIST Cybersecurity Framework 2.0, especially integrity, change management, and continuous monitoring expectations. The most common misapplication is treating drift as a purely platform engineering issue, which occurs when teams ignore identity and secret changes made outside Terraform.

Examples and Use Cases

Implementing drift detection rigorously often introduces release friction, requiring organisations to weigh deployment speed against assurance that the declared state still matches reality.

• A platform team updates an IAM role manually in the console so an incident can be resolved quickly, but Terraform still reflects the old trust policy and future applies risk undoing the fix.
• A secrets backend is rotated outside the module workflow, leaving dependent workloads pinned to stale values and creating a hidden failure path for NHI authentication.
• An engineer adds a permissive security group rule during troubleshooting, and the rule remains after the ticket closes because no drift review reconciles the change.
• A production service account is granted extra privileges directly in cloud IAM, creating a mismatch between declared least privilege and effective access.
• The Salesloft OAuth token breach illustrates how drift in token handling and sanctioned deployment paths can become a direct data-access risk when controls are bypassed.

In practice, drift detection is often paired with tools and standards that define desired state enforcement, such as infrastructure policy checks and the change-verification guidance in NIST Cybersecurity Framework 2.0. The same logic applies when teams review whether a Terraform-managed secret, role, or workload identity still matches the intended access model.

Why It Matters in NHI Security

Terraform drift is a security problem because NHIs are often the first assets to accumulate silent exceptions: tokens extended for convenience, roles widened for emergencies, and secrets copied into nonstandard locations. When those exceptions are not reconciled, the organisation loses confidence that the declared state reflects real access. NHI Mgmt Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, a pattern that often coexists with drift in Terraform-managed environments. That combination makes remediation harder, because the gap is not only technical but procedural: the environment no longer has a single trustworthy source of truth. Drift also weakens incident response, because teams cannot reliably tell which identities, permissions, or dependencies were supposed to exist at the moment of compromise. It directly affects auditability under frameworks such as NIST Cybersecurity Framework 2.0 and governance practices discussed in NHI Mgmt Group. Organisations typically encounter the impact only after an unexpected privilege escalation, failed rotation, or breach investigation, at which point drift becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How can security teams reduce privilege drift in Kubernetes RBAC?
• Runtime Drift
• Privilege Drift