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.
Why This Matters for Security Teams
Terraform and OpenTofu reduce configuration drift, but they do not solve the lifecycle problem around secrets. The moment a deployment depends on API keys, certificates, cloud tokens, or service credentials, the real risk shifts to issuance, storage, rotation, revocation, and audit. That is why declarative infrastructure can still leave high-value secrets exposed in state files, pipelines, logs, and environment variables, especially when teams treat infrastructure code as the control boundary instead of the identity layer.
NHIMG’s research on secret sprawl shows why this matters operationally: 88% of security professionals are concerned about secrets sprawl, and nearly half of exposed secrets can live outside source code in CI/CD logs, collaboration tools, and messaging platforms, according to The 2024 State of Secrets Management Survey and The NHI and Secrets Risk Report. That pattern aligns with the risks called out in the OWASP Non-Human Identity Top 10, where secrets exposure is rarely a coding mistake alone.
In practice, many security teams encounter secret leakage only after a pipeline, module, or deployment artifact has already been reused outside its intended trust boundary.
How It Works in Practice
Declarative IaC describes desired end state, but it does not guarantee how the deployment system authenticates to cloud APIs or how downstream workloads receive secrets. Terraform and OpenTofu often need credentials to create resources, and those credentials can be long-lived unless the surrounding platform issues short-lived access on demand. That is why the practical control set sits around the IaC runner, not inside the code alone.
A stronger pattern is to separate infrastructure definition from credential delivery. The IaC runner should authenticate with workload identity, obtain just-in-time access for the task, and avoid writing reusable secrets to disk. Runtime controls should then govern whether a resource can request a secret at all, whether the secret is dynamic or static, and whether it is automatically revoked when the task ends. This is consistent with current guidance from the NIST Cybersecurity Framework 2.0, which emphasises identity, access, and continuous governance rather than assuming secure code alone is enough.
For teams managing non-human identities, the most effective design usually combines:
- Short-lived workload identity for the Terraform or OpenTofu runner.
- Ephemeral secrets issued per plan or apply, not shared across projects.
- Policy checks at request time, so access is evaluated against context, environment, and target resource.
- Centralised logging for secret issuance, use, and revocation.
NHIMG’s Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce the same operational point: static credentials tend to outlive the automation that depends on them. These controls tend to break down in legacy pipelines where state files are shared, service accounts are reused across environments, and secrets are injected manually into build jobs because the deployment system was never designed for per-task identity.
Common Variations and Edge Cases
Tighter secret controls often increase pipeline complexity and can slow releases, so organisations have to balance developer velocity against blast-radius reduction. Best practice is evolving here, especially where modules span multiple clouds or where external SaaS integrations still require vendor-issued tokens rather than fully dynamic credentials.
One common edge case is Terraform state. Even if the configuration is clean, state backends, plan artifacts, and debug output may still capture sensitive values unless redaction and encryption are enforced end to end. Another is third-party providers that only support static API keys. In those cases, current guidance suggests compensating with constrained scopes, aggressive TTLs where possible, and strong monitoring around use and revocation rather than pretending the risk disappears because the code is declarative.
For security teams, the practical test is simple: if a secret can survive beyond the exact task that needed it, the IaC model has not removed the secret risk, it has only relocated it. The right question is not whether Terraform or OpenTofu is declarative, but whether the identity and secret lifecycle around it is ephemeral enough to match the workload.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Declarative IaC still depends on secret lifecycle control and rotation. |
| NIST CSF 2.0 | PR.AC-4 | Secret risk here is fundamentally an access control and identity issue. |
| CSA MAESTRO | Infrastructure automation needs runtime governance for machine identities. |
Use short-lived NHI credentials and enforce rotation, revocation, and audit outside the IaC file.
