When IAM changes happen outside Terraform, the declared state can diverge from the real environment. That drift makes reviews unreliable, increases the chance of orphaned permissions, and can leave third-party integrations or active workloads with access that no longer matches policy. The result is weaker control over identity posture.
Terraform Drift in IAM: What Actually Stops Being Trustworthy?
Once IAM resources are changed outside Terraform, the plan no longer reflects the full truth of the environment. That matters because identity controls are not just configuration objects, they define who can authenticate, what can be authorised, and which integrations continue to function. For teams running access governance through infrastructure as code, the first failure is usually not outage but loss of confidence in the declared state that reviewers and automation depend on. NIST Cybersecurity Framework 2.0
In practice, many security teams encounter this only after access reviews or incident triage reveal that the live IAM posture no longer matches the repository.
How IAM Drift Breaks Access, Review, and Recovery Workflows
Terraform works best when it is the authoritative source for intended state, but IAM is especially vulnerable to side changes because small edits can have broad reach. A manually added role, policy, trust relationship, group membership, or federation setting can survive long after the change that prompted it, because it is invisible to the workflow that generated the approved plan. The result is not only configuration drift but governance drift: the people who sign off on access no longer know whether the reviewed policy is what is actually enforced.
That creates several concrete breakdowns. Review and approval become unreliable because the codebase no longer describes the active permissions. Orphaned access can persist after the original business need has ended. Third-party integrations and workload identities may continue to function even when their access should have been narrowed, rotated, or removed. In cloud environments, that means a local exception can become a durable permission path that automation will never reconcile unless the unmanaged change is discovered and brought back under control.
- Plans lose evidentiary value because they no longer represent the deployed identity boundary.
- Drift detection becomes a required control, not an optional housekeeping step.
- Rollback gets harder because the team must distinguish intentional exceptions from unauthorised edits.
- Access removal can fail silently when the unmanaged object is still attached to live dependencies.
NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames the need to maintain controlled configuration baselines and monitor unauthorised changes, which is the operational issue drift creates. Where teams have mixed manual and coded changes, the guidance breaks down unless they can continuously reconcile declared and live identity state.
When Exceptions, Emergency Fixes, and Multi-Team Ownership Change the Answer
Tighter Terraform governance often increases short-term friction, requiring teams to balance delivery speed against the need for a single trusted source of identity truth.
Not every outside-the-pipeline IAM change has the same meaning. Emergency fixes, break-glass access, migration work, and vendor-managed adjustments can all introduce legitimate exceptions, but only if they are time-bound, recorded, and later folded back into managed code. The hard boundary is whether the exception remains visible to the governance process. If it does not, the issue is no longer just drift, it is an untracked access path.
Shared ownership is another edge case. IAM often spans platform, security, and application teams, which makes it easy for one group to assume another will codify the change. That assumption is where gaps appear: permissions remain effective, but the source of record, reviewer accountability, and change history become fragmented. The more sensitive the role or trust relationship, the less acceptable that fragmentation becomes.
What teams get wrong most often is treating manual edits as harmless because the access still “works.” The real question is whether the access still fits the approved control model. When it does not, the environment may function while the governance layer has already failed.
Risk and Threat Considerations
Uncontrolled IAM changes create a material exposure because they can leave permissions, trust relationships, or service dependencies active after the approved policy has changed. That weakens least-privilege enforcement and can preserve access that should have been removed, especially for third-party integrations and non-human identities.
Failure mechanism: A manual or out-of-band change bypasses the declarative workflow, so Terraform state, review evidence, and live access diverge. If no one reconciles the difference, stale permissions and hidden trust paths remain in place and can be reused by insiders, compromised accounts, or dependent workloads.
Impact: Orphaned access, failed access reviews, and inaccurate rollback all become more likely. In the worst case, a trusted identity retains broader reach than policy allows, making containment and accountability harder after a compromise or administrative mistake.
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 | 5 — Account Management | Out-of-band IAM edits can leave accounts and access paths unmanaged. |
| 4 — Secure Configuration of Enterprise Assets and Software | Terraform drift is a configuration-control failure that weakens the approved baseline. | |
| Recommendation — Enforce controlled account lifecycle changes and remove unmanaged access paths quickly. Continuously compare live IAM settings against the approved configuration baseline. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | IAM drift directly changes who can access what outside intended authorisation. |
| CM-3 — Configuration Change Control | Untracked manual IAM edits bypass change control and create state divergence. | |
| Recommendation — Review and enforce current authorisations against the declared access model. Require authorised change control for every IAM modification. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Secrets and Credential Lifecycle | IAM drift often preserves machine and integration access longer than intended. |
| Recommendation — Track and revoke non-human access when Terraform no longer matches live IAM state. | ||
Practitioner Guidance
What to prioritise: Treat drift between declared and live IAM state as a control failure, not a documentation issue. The first question is whether the unmanaged change affects authentication paths, privilege scope, or trust relationships; those are the changes that can create lasting exposure.
What to verify: Confirm that every exception has an owner, an expiry, and a path back into code. If a manual IAM change cannot be explained in change records and cannot be reconciled to Terraform, it should be treated as an exception condition requiring review, not a normal operating state.
Practitioner takeaway: The real break is not that Terraform is “out of date”; it is that the organisation stops having one dependable answer to what access exists and why.
Related resources from NHI Mgmt Group
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
