Drift source is the identity or tool responsible for a Terraform drift event. That source may be a human operator, a remote team member, a developer, or an automated system acting outside the Terraform path. Identifying it helps teams move from detection to root cause and remediation.
Expanded Definition
Drift source names the actor or tool that introduced a configuration change Terraform later reports as drift. In practice, it is less about the symptom and more about the origin of the change: who or what modified the live environment outside the expected Terraform workflow, and whether that change was intentional, accidental, or automated.
The term is usually used in infrastructure-as-code operations, where the boundary matters between drift detection and root-cause analysis. A drift source can be a person using a console, a script run by another pipeline, a teammate working in a different tooling path, or an automated process that was never aligned with Terraform state. The useful distinction is that the change happened outside the Terraform control loop, even if it was valid from another operational perspective.
A common misunderstanding is to treat drift source as the same thing as drift itself. Drift is the state mismatch; drift source is the upstream cause that explains why the mismatch exists. That distinction is what turns a noisy alert into a governance question about ownership, process, and change discipline.
Examples and Use Cases
Drift source is most useful when teams need to trace an unexpected state change back to the path that created it. That trace often reveals whether the issue is a one-off exception or a repeatable operational pattern.
- A production load balancer is changed in a cloud console during an outage, and Terraform later reports the difference. The drift source is the emergency operator action, not Terraform itself.
- A CI pipeline from a separate repository updates a security group rule, creating an unmanaged change that Terraform flags in the next plan.
- A developer applies a manual fix to a database parameter while waiting for an infrastructure ticket, leaving the live setting out of sync with code.
- An automated remediation job adjusts tags or policy settings directly in the platform, producing drift that points to an orchestration tool rather than a person.
In all of these cases, the practical question is not only what changed, but which workflow owns the change path. That is often the difference between a fast correction and recurring configuration churn.
Security Implications
When drift source is unknown, teams lose a key control signal. A configuration mismatch may be harmless, but it may also indicate bypassed approval, unauthorized privilege use, or an automation path that was never brought under governance. The security issue is not merely inconsistency, but the absence of accountability for who altered a controlled asset.
That uncertainty can widen blast radius in several ways. Repeated manual fixes can normalize shadow operations. Untracked automation can keep reintroducing the same change after remediation. A trusted operator account can mask whether the change was deliberate, mistaken, or the result of compromised credentials. In each case, drift detection finds the symptom, while drift source determines whether the environment has a control problem or a trust problem.
A practitioner should also watch for patterns where the same class of resource drifts repeatedly. That often signals a gap between policy design and the way teams actually operate, which is a governance failure as much as a technical one.
Domain and Governance Relevance
Drift source matters because Terraform is only one part of the real control boundary. In a mature environment, the question is whether all change paths that can affect infrastructure are known, owned, and reviewable. If not, drift becomes a symptom of fragmented authority rather than a simple configuration defect.
The identity angle is especially important when the source is a person, service account, or automation pipeline with independent access to the same infrastructure. That is where change ownership and access governance intersect: the ability to modify live resources outside the IaC path should be deliberately limited, monitored, and explainable. For NHI-heavy environments, the same logic applies to non-human actors that can mutate infrastructure without a human in the loop.
This makes drift source a useful governance concept for platform teams, security teams, and infrastructure owners alike. It helps them decide whether to tighten access, align alternate tooling, or formalise exceptions so that future drift is attributable rather than mysterious.
Risk and Threat Considerations
Drift source becomes a security concern when unmanaged change paths can modify production infrastructure outside the approved workflow. The main risk is not just configuration inconsistency, but loss of attribution and control over who or what can change protected assets.
Failure mechanism: Manual console edits, alternate pipelines, or automated remediators can bypass IaC review and state management, creating persistent mismatches that hide unauthorized or unintended changes. If the modifying identity is over-privileged or poorly monitored, the same path can be reused for broader abuse.
Impact: Teams may fail to distinguish legitimate emergency work from shadow change, weakening incident investigation, compliance evidence, and rollback confidence. Repeated unseen changes can also undermine security baselines across many resources at once.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 — Roles, Responsibilities, and Authorities | Drift source depends on knowing who owns and changed the resource. |
| PR.AC-04 — Access Permissions and Authorizations | Unauthorized or excessive access often creates unmanaged drift. | |
| Recommendation — Assign clear change ownership for infrastructure paths that can alter live state. Restrict modification rights to approved identities and automation only. | ||
| CIS Controls v8 | 6.3 — Access Grants and Revocation | Drift source often traces to stale or overbroad change permissions. |
| 4.1 — Establish and Maintain a Secure Configuration Process | Terraform drift source is tied to configuration control outside the approved path. | |
| Recommendation — Review and revoke unnecessary infrastructure modification access. Use a controlled configuration process to keep live changes attributable. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Compromised or altered accounts can become the source of unauthorized drift. |
| Recommendation — Map unexpected state changes to account abuse and investigate the modifying identity. | ||
Practitioner Guidance
Governance implication: Treat drift source as an ownership question, not just a detection output. The useful operational decision is which identities, tools, and workflows are allowed to alter infrastructure outside Terraform, and under what documented exception process.
What to watch for: Recurrent drift from the same account, pipeline, or team is usually a sign that the approved deployment path is incomplete or that the exception path has become normal practice. That pattern deserves review because it often precedes larger control erosion.
Practitioner takeaway: A drift alert is incomplete until the source is identified, because remediation without attribution tends to repeat the same failure.
Related resources from NHI Mgmt Group
- How should security teams scale open-source detection tooling without creating operational drift?
- What breaks when OCSF mappings drift from upstream source schemas?
- Who is accountable when authorization replicas drift from the source of truth?
- Why do groups become a major source of least privilege drift in mature identity programs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
