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.
When Terraform or OpenTofu Is Asked to Do Secret Work It Was Not Built For
Terraform and OpenTofu are strong at declaring infrastructure, but secret management is a different job. The break happens when teams expect the IaC layer to own secret lifecycle decisions such as creation, rotation, expiry, revocation, certificate handling, and leakage detection. At that point, the tool stops being a provisioner and starts masquerading as a control plane it does not have.
That confusion matters because infrastructure definitions are designed to be repeatable, not to be the authoritative system of record for sensitive values. Once secrets are embedded in variables, state, outputs, or surrounding automation, they become harder to rotate cleanly and easier to copy into places no one is tracking.
What Actually Breaks in the Delivery Pipeline
The first failure is lifecycle ownership. IaC can distribute a secret to resources, but it does not manage the full secrets management lifecycle, so no one gets a reliable revocation path when a credential leaks or a certificate must be replaced. The second failure is blast-radius control: the same value may end up repeated in state files, CI logs, environment variables, and modules, which turns one secret into many recoverable copies.
The third failure is false confidence. Teams may believe they have centralised control because the secret appears in code review or deployment automation, but that only means the secret is being transported by infrastructure tooling. It does not mean the organisation can prove who can read it, when it expires, or whether it has already been exposed elsewhere. Secret sprawl is usually the visible symptom of this mistake.
When the secret is an API credential, the control gap is even sharper. Terraform or OpenTofu can create or reference the resource that consumes the credential, but the organisation still needs an external process for scoping, rotation, and revocation. That is why a dedicated API key management lifecycle matters even in infrastructure-heavy workflows.
Why the Problem Becomes a Security and Governance Issue
Using IaC as a pseudo-vault usually converts a bounded secret into long-lived, distributed exposure. State backends, plan artifacts, module outputs, and pipeline caches can all become unintended secret repositories, especially when teams do not separate deployment permissions from secret-reading permissions. The organisation also loses clear ownership, because the infrastructure team, application team, and platform team may each assume someone else is handling rotation.
That is why the issue belongs in a broader identity and access discussion as well. A secret is often the mechanism that authenticates a workload, service, or automation path, so mishandling it can create standing access long after the original deployment need has passed. NHIMG’s Secrets Management Buyer’s Guide is useful here because it frames the control problem as a tooling and lifecycle decision, not just a storage decision.
For practitioners, the key governance failure is assuming that “it is in code” means “it is controlled.” Code may describe desired infrastructure, but it does not by itself enforce secret expiry, detect reuse, or guarantee that a stale credential has been withdrawn everywhere it was copied. Once that gap exists, remediation becomes forensic and reactive rather than procedural.
Risk and Threat Considerations
Secrets placed into IaC workflows tend to spread into more systems than teams expect, and every extra copy increases the chance of disclosure, stale access, or accidental reuse. The risk is not just theft; it is also persistence, because a leaked secret that is embedded in state or pipeline history can remain usable long after the original deployment ticket is closed.
Failure mechanism: The infrastructure tool provisions resources, while the secret itself is propagated through state, logs, templates, and automation artifacts without a separate lifecycle owner, so rotation and revocation are delayed or incomplete.
Impact: Attackers or insiders may gain durable access paths to cloud services, CI/CD systems, or downstream applications, and defenders may struggle to prove where the secret lives or whether every copy has been replaced.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-57 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secrets in IaC state and logs create direct exposure risk. |
| NHI-07 — Long-Lived Secrets | Treating IaC as secret manager often leaves credentials unrotated and persistent. | |
| NHI-05 — Overprivileged NHI | Embedded deployment secrets can grant more access than the infrastructure task requires. | |
| Recommendation — Move secrets out of IaC artifacts and scan state, plans, and logs for leakage. Replace long-lived credentials with short-lived alternatives and enforce rotation. Scope deployment credentials to the minimum permissions needed for each system. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | API credentials managed poorly through IaC undermine authentication lifecycle control. |
| Recommendation — Separate API credential issuance and revocation from infrastructure deployment. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation, revocation, and storage are authenticator lifecycle controls. |
| AC-6 — Least Privilege | Secret distribution through pipelines often expands access beyond necessity. | |
| AU-6 — Audit Review, Analysis, and Reporting | Leakage monitoring and exposure detection require reviewable logging and alerting. | |
| Recommendation — Apply lifecycle management to credentials, keys, and secrets outside IaC state. Limit who and what can read deployment secrets and state data. Review logs and alerts for secret exposure, reuse, and unauthorized access paths. | ||
| NIST SP 800-57 | Key Management | Certificate and key handling are part of the lifecycle break caused by misusing IaC. |
| Recommendation — Manage cryptographic material through a dedicated key lifecycle process. | ||
| OWASP ASVS | V9 — Self-contained Tokens | Token handling through build and deployment artifacts affects secret exposure and lifetime. |
| Recommendation — Keep tokens out of build artifacts and use appropriate token lifecycle controls. | ||
Practitioner Guidance
What to prioritise: Treat every secret used by Terraform or OpenTofu as an external dependency with its own owner, rotation schedule, and revocation path. If you cannot answer who rotates it, who can read it, and what happens when it leaks, it is already outside acceptable control.
What to verify: Check whether secret values are present in state, plan output, variable files, pipeline logs, or module outputs, and confirm that your backend, access model, and retention settings do not preserve readable copies longer than necessary. Also verify that certificates and API keys have replacement procedures, not just creation procedures.
Practitioner takeaway: IaC should reference secrets, not impersonate the secret system of record; once a deployment tool is trusted to manage lifecycle controls it does not own, you usually get hidden sprawl instead of control.