TL;DR: Terraform and OpenTofu are functionally similar IaC tools, but neither is a secrets manager, so provisioning workflows still depend on external controls for rotation, certificates, and repository hygiene, according to Infisical. The real governance issue is that infrastructure automation can scale secret distribution faster than teams can govern secret lifecycle and exposure windows.
At a glance
What this is: This is a comparison of Terraform and OpenTofu that finds the real identity-security gap is not the IaC choice itself, but the fact that both tools still rely on separate secrets governance.
Why it matters: IAM, NHI, and platform teams need to treat IaC as a secrets distribution channel, not a secrets control plane, or provisioning will outpace rotation, revocation, and auditability.
Context
Terraform and OpenTofu are declarative infrastructure-as-code tools, which means they provision infrastructure from code rather than from manual API calls. That model speeds delivery, but it does not create a governance layer for the secrets, certificates, and machine credentials those deployments rely on.
The practical problem is not whether teams choose Terraform or OpenTofu. The problem is that both can multiply secret distribution across environments faster than security teams can control rotation, revoke access, or audit exposure.
For identity programmes, this is an NHI governance issue because the credentials used in provisioning are machine-bound and often reused across pipelines, providers, and self-hosted environments. The article’s starting point is typical for modern IaC adoption: the tool choice changes licensing and packaging more than it changes the underlying secrets-risk profile.
Key questions
Q: What breaks when Terraform or OpenTofu is treated as a secrets manager?
A: The organisation loses lifecycle control. IaC can provision infrastructure, but it does not govern secret rotation, revocation, certificate handling, or exposure monitoring. Once teams assume the tool owns those controls, credentials tend to spread through pipelines, state files, and configuration artifacts without a clear owner or replacement path.
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: How can security teams tell whether IaC secret governance is working?
A: Look for short-lived credentials, centrally managed issuance, and a clean separation between provisioning code and secret storage. If the same token or certificate appears across multiple environments, or if state files and logs contain secrets, governance is not working as intended.
Q: Should organisations standardise on Terraform or OpenTofu for secrets safety?
A: Not as the primary security decision. The more important choice is whether provisioning is wired to a governed secrets lifecycle. Organisations should prefer whichever IaC tool fits their platform model, then enforce separate control over issuance, rotation, revocation, and audit for the credentials it uses.
Technical breakdown
Why IaC tools do not solve secrets governance
Terraform and OpenTofu describe desired infrastructure state, but they do not manage the lifecycle of the secrets used to reach that state. A provider may authenticate with tokens, client secrets, certificates, or other machine credentials, yet the IaC engine only consumes those inputs during execution. That distinction matters because governance has to cover issuance, storage, rotation, revocation, and audit separately from provisioning. In practice, the control gap appears when teams assume the deployment layer also functions as the credential governance layer. It does not.
Practical implication: separate provisioning workflows from secrets lifecycle controls and treat the IaC runner as a consumer of managed credentials, not their owner.
Where Terraform and OpenTofu create identical secret exposure patterns
Because the two tools are operationally similar, they inherit the same exposure patterns around provider configuration, backend state, and pipeline automation. Secrets can appear in environment variables, state files, CI logs, or copied configuration blocks when teams optimise for convenience. That is why the category risk is stable even when the product branding or license changes. The governance question is whether the organisation can inventory where machine credentials live, who can read them, and how quickly they are replaced when exposed. Tool parity does not remove that exposure surface.
Practical implication: map every Terraform and OpenTofu execution path to the secret sources it consumes, then close any path where credentials can persist outside managed storage.
Why external secrets platforms become the control point
The article’s key architectural point is that a separate secrets platform is needed when infrastructure code must use ephemeral or centrally managed credentials. That platform becomes the place where rotation, dynamic generation, certificate handling, and repository scanning are governed. This is the real separation of duties: IaC provisions resources, while a secrets system governs the credentials that authorise that provisioning. Without that split, teams often end up embedding long-lived credentials into workflows that were designed for speed, not lifecycle control.
Practical implication: route Terraform and OpenTofu authentication through managed secret issuance and rotation services instead of embedding reusable credentials in project code.
Breaches seen in the wild
- HashiCorp GPG key exposure 2021: Codecov's poisoned Bash Uploader exposed the GPG key HashiCorp used to sign download checksums; HashiCorp rotated it and re-signed its releases.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
IaC choice is not the control plane. Terraform and OpenTofu sit on the execution side of provisioning, not on the governance side of credential lifecycle. That means the real control failure is assuming declarative infrastructure can also govern the secrets it consumes. The practitioner conclusion is simple: identity and secrets controls have to sit outside the IaC engine.
Secrets governance debt accumulates inside automation pipelines. When a provisioning workflow scales faster than rotation and revocation, the organisation builds exposure into the delivery model itself. This is not a Terraform-versus-OpenTofu problem, because the same lifecycle weakness persists across both. Teams need to see provisioning automation as an amplifier of existing secret governance maturity, not a substitute for it.
Machine credential reuse is the hidden blast-radius multiplier. In IaC environments, the same client secret, token, or certificate often supports multiple environments and execution paths. That creates broad reuse across pipelines and makes compromise or leakage materially more expensive. The practitioner implication is that credential scope, not just tool selection, determines how far a provisioning compromise can travel.
Identity lifecycle discipline must extend into DevOps execution paths. The article underscores a common blind spot: operational teams often govern human access tightly while leaving provisioning identities less structured. That split is increasingly untenable because machine credentials now sit on the critical path for infrastructure change. The field should treat secrets rotation, certificate handling, and repository hygiene as core identity lifecycle work, not adjacent hygiene.
Secrets distribution is the real governance gap: IaC tools can replicate configuration everywhere, but they do not themselves decide how credentials are issued, reused, or retired. That distinction explains why teams can have mature deployment automation and still fail at exposure control. The practitioner conclusion is to design governance around where secrets move, not around which IaC syntax is in use.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
Secrets governance debt: Declarative provisioning scales change, but it also scales the spread of machine credentials unless lifecycle controls sit outside the IaC workflow. Teams that treat Terraform or OpenTofu as the control layer will keep rediscovering the same exposure pattern in new repositories and environments.
The more reusable the credential, the larger the blast radius when it leaks into state, logs, or provider configuration. That makes secrets issuance and revocation the decisive control point for IaC-heavy programmes, not the choice between two near-identical tools.
For practitioners
- Separate provisioning from credential governance Define IaC as an execution layer and assign secrets issuance, rotation, and revocation to a dedicated control path outside the pipeline.
- Inventory every machine credential used by IaC Map client secrets, tokens, certificates, and other non-human credentials across Terraform and OpenTofu workflows, including state, CI, and provider configuration.
- Move reusable credentials out of code repositories Replace embedded credentials in project files and environment scaffolding with centrally managed secret references and short-lived access wherever possible.
- Audit repository and pipeline exposure paths Check whether state files, logs, plan outputs, and shared variables are exposing secrets beyond the intended execution boundary.
Key takeaways
- Terraform and OpenTofu create the same governance problem when teams confuse infrastructure provisioning with secrets lifecycle control.
- The exposure risk comes from how machine credentials are handled across pipelines, state files, and repositories, not from the IaC syntax itself.
- Practitioners should separate provisioning from secrets issuance, rotation, and revocation if they want IaC automation without secret sprawl.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed machine credentials in IaC workflows. |
| NHI-07 — Long-Lived Secrets | Reusable credentials in Terraform and OpenTofu workflows create persistent exposure windows. | |
| Recommendation — Scan IaC pipelines and state paths for secret leakage and remove exposed credentials immediately. Replace long-lived provisioning secrets with short-lived credentials and enforce rotation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is the core control issue in the article. |
| Recommendation — Apply IA-5 to govern credential issuance, storage, rotation, and revocation for IaC execution. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is about managing machine access used by provisioning workflows. |
| Recommendation — Use CIS-5 to inventory and remove unnecessary IaC accounts and credentials. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Leaked provisioning credentials create a credential-access path for attackers. |
| Recommendation — Map exposed IaC secrets to TA0006 and prioritise any workflow that reveals reusable credentials. | ||
Key terms
- Infrastructure as Code coverage: The share of infrastructure that is created, changed, and governed through code rather than manual console actions. In practice, it measures how much of the environment can be reviewed, reproduced, and remediated through a controlled delivery path instead of ad hoc operator behaviour.
- Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
- Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.
- Repository Hygiene: Repository hygiene is the practice of keeping source code, configuration, and build artifacts free from exposed secrets and other sensitive operational data. For IaC programmes, it is the difference between managed deployment metadata and an accidental credential distribution channel.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org