Terraform and OpenTofu expose the same secrets governance gap

At a glance

What this is: This comparison shows that Terraform and OpenTofu differ mainly in license and distribution model, while both leave secrets management outside the core IaC workflow.

Why it matters: It matters because IAM, NHI, and platform teams still need separate controls for secrets, machine identities, and certificate lifecycle even when infrastructure provisioning is standardised.

👉 Read Infisical's comparison of Terraform and OpenTofu for secrets-driven infrastructure

Context

Terraform and OpenTofu are declarative infrastructure as code tools, which means they define infrastructure through code rather than repeated manual API calls. That makes them efficient for provisioning, but it also means they sit beside, not inside, the identity and secrets controls that secure the runtime state they create.

The governance gap is straightforward: IaC can create the environment, but it does not by itself control the secrets, certificates, or machine identities used inside that environment. For IAM and NHI teams, that means provisioning standardisation does not remove the need for lifecycle control, rotation, and auditability.

In practice, the article is not really about which IaC tool is better. It is about how quickly teams can confuse infrastructure portability with security portability, which is a typical problem in modern platform engineering programmes.

Key questions

Q: How should security teams govern machine identities used by IaC tools?

A: Treat every provider credential, token, and certificate as a non-human identity with an owner, a scope, and a revocation path. Put those identities under lifecycle control, rotate them on a defined cadence, and make sure deployment automation can fail safely when access is withdrawn.

Q: Why do Terraform and OpenTofu still create secrets risk if the infrastructure model is declarative?

A: Declarative infrastructure defines what should exist, not how secrets are stored or protected. The risk remains because credentials still need issuance, rotation, audit, and offboarding, and those controls sit outside the IaC file itself. That makes the surrounding NHI governance model more important, not less.

Q: What do teams get wrong about secret management in infrastructure pipelines?

A: They often assume the provisioning tool is also the security control. In practice, IaC tools orchestrate resources, while secrets platforms govern the credentials that let automation act. If those responsibilities blur, static secrets spread into repositories, pipelines, and provider configs.

Q: How can organisations reduce the blast radius of deployment automation?

A: Reduce the permissions attached to each machine identity, separate environments, and avoid shared credentials across projects or teams. The goal is to ensure one compromised pipeline cannot touch unrelated systems. Lifecycle reviews should verify that no deployment credential has broader access than it truly needs.

Technical breakdown

Licensing split between Terraform and OpenTofu

Terraform moved from an open source model to a Business Source License, while OpenTofu preserved a permissive fork based on the last open Terraform release. The practical effect is not a technical divergence in infrastructure modelling so much as a distribution and ecosystem split. Both tools still express infrastructure declaratively and both remain close enough that feature parity has continued to narrow the visible gap. That makes the licensing question important for procurement and tooling strategy, but not for the underlying identity or secrets controls surrounding the platform.

Practical implication: treat license choice as a platform decision, not a security control substitute.

Why IaC does not solve secrets management

Infrastructure as code describes desired state, but secrets are operational artefacts that still need storage, rotation, access governance, and detection. When teams embed credentials in provisioning workflows or provider configurations, they move the problem rather than eliminate it. The article’s core point is that IaC tools are orchestration layers, while secrets managers own the security lifecycle. That separation matters for NHI governance because machine credentials often outlive the deployment that created them.

Practical implication: decouple provisioning pipelines from secret lifecycle ownership and rotate externally managed credentials on a defined schedule.

Machine identity is the real dependency in provisioning pipelines

The example configuration uses machine identity credentials to authenticate the provider, which is a reminder that IaC systems are always operating through non-human identities. Those identities need scoped access, revocation paths, and audit trails, especially when they are used to instantiate cloud backends or application infrastructure. The security boundary is not the HCL file or the provider name. It is the credential issued to the automation path and the controls around its lifetime.

Practical implication: inventory the service accounts and tokens behind provisioning workflows and govern them as first-class NHIs.

NHI Mgmt Group analysis

IaC standardisation does not equal identity standardisation: Terraform and OpenTofu can normalise how infrastructure is created, but they do not normalise how secrets and machine identities are governed. That distinction matters because the provisioning layer often gets modernised faster than the access layer. The implication is that platform teams still need a separate identity control plane for the non-human credentials that drive deployment.

Secrets management remains a separate security domain from infrastructure orchestration: The article correctly draws a line between provisioning backends and managing the secrets used to access them. That line is where many programmes fail, because credentials become implicit dependencies of build and deploy pipelines. When secrets lifecycle is treated as part of IaC syntax rather than as an NHI governance function, visibility and revocation both become weaker.

Machine identities behind deployment tooling deserve the same lifecycle discipline as human access: Provider credentials, universal client secrets, and certificate material should be governed as non-human identities, not as disposable configuration details. Reusing the same access patterns across Terraform and OpenTofu does not reduce the governance burden. Practitioners should therefore treat the deployment path as an NHI estate with its own lifecycle, not as a developer convenience layer.

Open source continuity changes distribution risk, not credential risk: The license split between Terraform and OpenTofu is a commercial and ecosystem issue, but it does not resolve the underlying trust model for provisioning workloads. The same access patterns, secrets exposures, and certificate dependencies remain in place whichever tool is chosen. Teams should focus on where identity is embedded in automation rather than on the branding of the orchestrator.

Identity blast radius is defined by the credential, not the IaC engine: The named concept here is the identity blast radius, which is the maximum damage a provisioning credential can do if abused. That blast radius is shaped by the scope of the machine identity, the resources it can reach, and the lifetime of its permissions. Practitioners should measure the credential boundary, not the syntax boundary.

From our research:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
• That same survey found 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• For a broader lifecycle lens, see the NHI Lifecycle Management Guide, which frames how provisioning, rotation, and offboarding should be handled across machine identities.

What this signals

Identity blast radius is the right lens for IaC governance: when a provisioning tool depends on a machine credential, the real control question is how far that credential can reach before it is rotated or revoked. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per The 2026 Infrastructure Identity Survey, the broader lesson is that automation often scales entitlement faster than governance.

Teams should watch for convergence between IaC, secrets management, and workload identity controls. The operational boundary is no longer the code repository alone, because deployment credentials now sit inside a much larger non-human identity estate that must be inventoried, reviewed, and retired on lifecycle terms.

For practitioners, the next step is to treat deployment tooling as one consumer of identity governance, not the owner of it. That means aligning provisioning pipelines with the NIST Cybersecurity Framework 2.0 functions for identify, protect, detect, respond, and recover, while keeping secrets custody in a separate control layer.

For practitioners

• Separate provisioning from secrets custody Keep IaC repositories free of long-lived credentials and route secret material through a dedicated secrets platform that can rotate and audit usage independently of deployment code.
• Inventory machine identities used by IaC pipelines Map every provider credential, token, and certificate used by Terraform or OpenTofu into an NHI register, including ownership, scope, and revocation path.
• Limit deployment credentials to narrow resource scopes Scope provider access to the smallest viable set of cloud accounts, subscriptions, and namespaces so compromise of one automation path does not expose the whole platform.
• Audit repository and pipeline exposure points Scan for hardcoded secrets, stale environment variables, and shared service account material in build pipelines, then remove or replace any static credential that can persist across runs.

Key takeaways

• Terraform and OpenTofu differ mainly in licensing and ecosystem direction, but the identity and secrets problem underneath them is the same.
• Declarative infrastructure does not remove the need for lifecycle control over provider credentials, certificates, and other machine identities.
• Practitioners should govern the automation path as an NHI estate and keep secrets custody separate from provisioning logic.

Key terms

• Infrastructure as code: Infrastructure as code is the practice of defining servers, networks, databases, and related resources in code rather than configuring them manually. It improves repeatability, but it does not by itself govern the credentials used to apply that code or the identities that automation depends on.
• Machine identity: A machine identity is a non-human credential used by software, services, or automation to authenticate and act. In IaC workflows, it is the provider credential or token that allows deployment actions, and it must be governed with the same lifecycle discipline as any other privileged identity.
• Secrets management: Secrets management is the controlled storage, distribution, rotation, and retirement of credentials such as tokens, API keys, and certificates. It is a separate discipline from provisioning because the goal is to keep credentials short-lived, auditable, and limited to the systems that truly need them.
• Identity blast radius: Identity blast radius is the amount of access damage a credential can cause if it is misused or stolen. For automation, the blast radius depends on privilege scope, environment reach, and credential lifetime, so reducing it means governing the identity behind the tool, not just the tool itself.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Side-by-side configuration examples for Terraform and OpenTofu provider setup.
• The article's licensing history and fork timeline in more detail, including the Business Source License shift.
• Practical notes on how Infisical integrates as a secrets platform alongside provisioning workflows.
• Examples of certificate and secret management features that sit outside IaC itself.

👉 The full Infisical post covers the licensing split, provider compatibility, and secrets handling details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.