How should security teams govern Terraform-managed identities in IGA programs?

Why This Matters for Security Teams

Terraform changes the governance problem because access is no longer only provisioned through a ticket and then reviewed later; it is continuously recreated from code and state. For IGA programs, that means the identity record must reflect both the declared intent and the live infrastructure result. If security reviews lag behind plan/apply activity, stale access can persist even when the configuration has already moved on. This is especially risky when service accounts, API keys, or cloud roles are embedded in IaC modules or passed into pipelines as secrets.

NHIMG research shows why this matters: 71% of NHIs are not rotated within recommended time frames, and 30.9% of organisations store long-term credentials directly in code, which makes infrastructure workflows a common path for credential exposure. Current guidance suggests treating Terraform-managed access as part of the identity lifecycle, not as a deployment side effect, and pairing that with governance patterns described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the NIST Cybersecurity Framework 2.0.

In practice, many security teams encounter orphaned Terraform credentials only after a module has already been reused across environments and the original owner has long since changed.

How It Works in Practice

Effective governance starts by mapping each Terraform-managed identity to an owner, a business purpose, and a revocation path. That includes the Terraform Cloud or CI/CD connector credential, any cloud provider role assumed by the pipeline, and the downstream service identities created by the code. IGA should not only ask who approved the access, but also what infrastructure state justified it, what module created it, and what event will trigger review. This aligns with the lifecycle discipline in NHIMG’s NHI Lifecycle Management Guide and the control objectives in NIST Cybersecurity Framework 2.0.

• Bind each Terraform workspace or module to a named identity owner and an approver.
• Track connector secrets, cloud roles, and generated credentials as separate governed assets.
• Reconcile IGA entitlements against actual cloud state after every meaningful apply.
• Use time-bound access for pipeline operators where possible, and revoke on module retirement.
• Require evidence from plan/apply logs before attestation is marked complete.

Where teams need a stronger audit lens, NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful for framing why state-based review is more defensible than snapshot-based review. The practical test is simple: if Terraform destroys a resource but the IGA record still shows standing access, the governance model is already behind reality. These controls tend to break down when multiple pipelines share one credential because ownership, attribution, and revocation all become ambiguous.

Common Variations and Edge Cases

Tighter state-aware governance often increases review overhead, requiring organisations to balance cleaner entitlement data against faster delivery pipelines. That tradeoff is manageable in single-account environments, but it gets harder when teams use reusable modules, ephemeral test environments, or cross-account role chaining. Best practice is evolving here, so there is no universal standard for how much of Terraform state should be mirrored into IGA. Security teams should focus on the minimum evidence needed to prove who can create, change, or revoke a given identity at a given time.

One common edge case is drift: the Terraform state says one thing, but the live environment has manual changes or emergency access that never flowed back into the code review process. Another is short-lived infrastructure, where resources disappear before a traditional review cycle can run. In those cases, the control should shift from periodic certification to event-driven attestation, backed by change logs and connector inventory. The Top 10 NHI Issues article is a useful reminder that over-privilege and poor visibility remain the recurring failure modes, even when automation is in place.

For organisations formalising this in a broader trust model, the NIST Cybersecurity Framework 2.0 supports tying identity governance to continuous monitoring rather than annual cleanup. The governance model should be strict enough to catch drift, but flexible enough to avoid freezing every pipeline for manual approval.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?