TL;DR: Akeyless says Terraform can move secrets out of code and into controlled retrieval flows, but runtime lookups still leave exposure in Terraform state unless storage, access, and credential lifecycle are governed together. The real control boundary is state discipline, not just where the secret originates.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Akeyless's blog post: Terraform-based secrets management reduces hardcoding, but retrieved secrets can still land in state files and create a governance gap.
Why it matters: For IAM, PAM, and NHI teams, this matters because infrastructure as code only stays safe when secret storage, retrieval, and state-file controls are treated as one lifecycle.
👉 Read Akeyless' analysis of Terraform secrets management and state file discipline
Context
Terraform users often assume that moving secrets out of source files removes the exposure problem. In practice, the governance gap shifts rather than disappears, because runtime retrieval, provider state, and backend storage can still preserve sensitive material longer than intended.
This is a secrets management and infrastructure as code problem first, not a tooling comparison. The operational question is whether state files, access paths, and secret lifecycles are controlled as one system, because once they split, the exposure surface grows even when the code looks clean.
The article's core point is that secure IaC depends on more than avoiding hardcoded credentials. If retrieved values persist in state or are protected only by ad hoc process, Terraform becomes a delivery mechanism for secrets rather than a governed control plane.
Key questions
Q: What breaks when Terraform retrieves secrets but state protection is weak?
A: The security model breaks because the secret may survive in state after the apply finishes, even if it never appeared in source code. That creates a durable exposure surface that outlives the original workflow. Teams should treat state storage as part of the secrets boundary, not a separate infrastructure detail.
Q: Why do secrets retrieved at apply time still create risk?
A: Because the secret can exist in multiple places during execution, including provider memory, local values, downstream resources, and the state file. If any of those locations are retained or exposed, the secret remains recoverable. Runtime retrieval reduces hardcoding, but it does not remove lifecycle governance.
Q: How should teams separate Terraform bootstrap access from runtime secret use?
A: Use one credential to create or configure the secrets system, then rotate or revoke that credential before Terraform starts consuming secrets for actual infrastructure. This prevents long-lived setup access from becoming embedded in the operating workflow. The two phases should be governed as different identities.
Q: When is Terraform the wrong place to carry sensitive values?
A: Terraform is the wrong place when the value must remain hidden from state, logs, outputs, or downstream metadata. In that case, teams should redesign the workflow so the value is fetched only where it is immediately needed and never persisted longer than necessary.
Technical breakdown
Why Terraform state becomes the weak link in secrets workflows
Terraform state records resource attributes so future plans can compare desired and current infrastructure. When a secret is read during apply, that value can be captured in state even if it never appears in code. The security issue is not Terraform itself, but the persistence model around state: a secret that is temporary in runtime can become durable in metadata. That turns state backend security into part of the secrets management boundary, not a separate admin concern.
Practical implication: Protect state as if it contains secrets, because in many workflows it effectively does.
Why runtime retrieval does not eliminate credential exposure
Fetching a secret from a manager at apply time reduces hardcoding, but it does not remove the need for trust in the execution path. The provider, local values, downstream resources, and debug output can all handle sensitive data before the apply is complete. If the workflow masks values only in code while still passing them through state or tags, the exposure point moves rather than disappears. Effective governance depends on knowing exactly where the secret exists during each phase of execution.
Practical implication: Map every hop where a secret is materialised, then remove or lock down the ones that persist.
How lifecycle controls change in IaC-driven secret use
Secrets used by infrastructure as code need the same lifecycle discipline as any other non-human identity credential. That includes issuance, storage, rotation, revocation, and offboarding of the access path used by Terraform itself. The article also highlights a critical reset between setup and runtime credentials, which is the right instinct: deployment credentials should not be the same credentials that remain in long-lived state or persistent automation context. Without that separation, secret lifecycle and infrastructure lifecycle become inseparable risks.
Practical implication: Separate bootstrap credentials from runtime credentials and treat both as governed identities.
Threat narrative
Attacker objective: The attacker aims to recover long-lived secrets from Terraform state or related execution artifacts and reuse them outside the IaC workflow.
- Entry occurs when Terraform retrieves a secret at apply time and the value is introduced into the execution path rather than kept outside it.
- Credential access then persists because the secret can be written into Terraform state, backend storage, or resource metadata that outlives the run.
- Impact follows when that state is exposed, copied, or reused, giving an attacker a durable path to the secret even after the original code was cleaned up.
Breaches seen in the wild
- Toyota T-Connect key exposure 2022: A subcontractor left a T-Connect server key on public GitHub from 2017 to 2022; 296,019 customers' emails were exposed, misuse unknown.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Terraform state is now part of the secrets control plane: When retrieved credentials are written into state, the state backend stops being a passive record and becomes a regulated secrets surface. That is why encrypted storage and tightly governed access are not optional implementation details. The practitioner implication is simple: if your IaC flow can read a secret, your state handling must be designed as if it can also leak one.
State file discipline, not tool choice, determines whether Terraform is safe for secrets: The article frames Akeyless as operationally simpler, but the deeper point is that simplicity only helps if the workflow preserves boundaries between bootstrap access, runtime retrieval, and persistent storage. A secret manager does not solve exposure once Terraform serialises sensitive values into execution artefacts. Teams need to judge the full lifecycle, not the front-end abstraction.
Static secrets in IaC create credential persistence debt: API keys, database passwords, and configuration blobs are especially dangerous when they are passed through automation because they tend to survive beyond the task that created them. That persistence is the real problem, not just where the value originated. The practitioner conclusion is to reduce how often Terraform has to carry a secret, and to narrow how long any one credential remains usable.
Bootstrap and runtime identity must be separated: The article's credential reset between parts is the right pattern because the identity used to create secret infrastructure should not be the same identity that later consumes it. When those roles are collapsed, Terraform state can inherit privileges that were only meant to exist briefly. Teams should treat setup credentials and operating credentials as different governance objects, not convenience variants of the same account.
Runtime retrieval changes the risk model for NHI governance: Terraform is effectively acting on behalf of a machine identity, so the issue is not just secret storage but how that identity is authorised, observed, and retired. OWASP-NHI and NIST-style access controls both point in the same direction: the lifecycle of non-human credentials must be managed at the point of issuance and at the point of persistence. Practitioners should govern Terraform as a credential-bearing workload, not a neutral deployment script.
From our research library:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
- Read next: Secrets Management Buyer's Guide
What this signals
Credential persistence debt: The article shows why infrastructure as code creates a specific governance burden when secrets are retrieved at runtime but retained in state. Teams should assume every secret-handling workflow has two control planes: the secret manager and the execution artefacts that record what happened.
The practical consequence is that state backend hardening becomes an identity control as much as an infrastructure control. If automation can read sensitive values, the access path to its state must be governed with the same discipline as the secret store itself.
For practitioners
- Protect Terraform state as a sensitive secret store Encrypt remote state, restrict backend access, and assume any value read during apply may persist there unless proven otherwise.
- Separate bootstrap and runtime credentials Use short-lived setup access for provisioning, then rotate or revoke it before the workflow begins consuming secrets for production infrastructure.
- Minimise secret materialisation in apply workflows Prefer patterns that avoid passing raw credentials through locals, outputs, tags, or debug logs when Terraform retrieves values at runtime.
- Treat Terraform as a governed NHI workload Inventory the automation identity, scope its permissions to the exact secret paths it needs, and recertify access on the same cadence you apply to other machine identities.
Key takeaways
- Terraform-based secrets workflows reduce hardcoding, but they do not eliminate exposure if state files retain retrieved values.
- The risk is not theoretical because state, locals, logs, and outputs can all extend the life of a secret beyond the apply window.
- Teams need to govern bootstrap access, runtime retrieval, and state protection as a single lifecycle, or Terraform becomes a secrets persistence problem.
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 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-02 — Secret Leakage | The article centres on secrets exposed through Terraform state and execution artefacts. |
| NHI-07 — Long-Lived Secrets | The post warns that credentials used in IaC can outlive their intended use if retained in state. | |
| Recommendation — Scan Terraform state and execution paths for exposed secrets, then remove or rotate any value that persists. Shorten secret lifetime in IaC workflows and revoke credentials that remain usable after provisioning. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Terraform credentials and runtime secrets require lifecycle management under authenticator controls. |
| Recommendation — Apply authenticator lifecycle controls to provisioning credentials and rotate them before they enter steady-state use. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article's core risk is durable access to secrets via Terraform state and related artefacts. |
| Recommendation — Hunt for credential exposure in IaC artefacts and prioritise compromised state backends for containment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The workflow depends on tightly scoped access to secret paths and state backends. |
| Recommendation — Scope permissions to the exact secret paths and state resources each Terraform workflow requires. | ||
Key terms
- Terraform State: Terraform state is the record that links declared infrastructure code to the live resources actually running in the cloud. It is the mechanism that makes reconciliation, drift detection, and controlled change possible, and it becomes critical when existing resources are imported rather than recreated.
- Bootstrap Credential: A bootstrap credential is a temporary secret used to get a new identity into its first trusted session when normal access paths are not yet ready. In identity governance, it should be time-bound, single-use, and auditable so it does not become a permanent side channel.
- Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.
- Secret Persistence Debt: Secret persistence debt is the growing security liability created when exposed credentials remain valid for too long after they are discovered or copied. It is a lifecycle problem, not just a detection problem, because every extra hour of validity expands the window for cloud abuse and data exfiltration.
What's in the full article
Akeyless' full blog post covers the implementation detail this post intentionally leaves for the source:
- Terraform code examples for creating static secrets, RBAC rules, and provider authentication
- The full two-part demo showing how secrets are stored, retrieved, and passed into AWS resources
- Practical notes on state file exposure, encryption at rest, and access restriction for remote state
- The complete walkthrough of how retrieved secrets are used in DynamoDB deployment and item creation
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org