Terraform secrets management still leaves state file exposure

At a glance

What this is: Infisical shows that Terraform state can still store secrets in plaintext even when code and console output are kept clean.

Why it matters: IAM and NHI teams need to treat Terraform as a secret-handling workflow, not just an infrastructure tool, because state storage, CI access, and backend controls determine the actual blast radius.

Context

Terraform state is the hidden control surface in infrastructure as code. It is the file that lets Terraform calculate diffs, but that same mechanism also records the values it reads or creates, which is why secrets can persist after they are removed from source files.

For identity and access teams, the issue is not whether Terraform can manage infrastructure securely in general. The issue is whether secret values are ever written into state, copied into CI, or left in a backend that is easier to read than the infrastructure itself.

The article shows that sensitive=true is only display hygiene, not storage protection. That makes Terraform secrets management an NHI and IAM governance problem as much as a tooling problem, because the credentials that let Terraform act are part of the same exposure path.

Key questions

Q: What fails when Terraform only uses sensitive=true for secrets?

A: Only the display changes. The secret can still be written into state, plan files, or outputs, so the underlying storage exposure remains even when the CLI shows redacted values. Teams should treat sensitive=true as a presentation control, not a protection boundary, and pair it with runtime retrieval or state hardening.

Q: When should teams prioritise ephemeral secret handling over data sources in Terraform?

A: Prioritise ephemeral handling when the value is only needed during the run and should not persist after apply. Data sources are useful when state persistence is acceptable, but credentials, passwords, and tokens that must not survive the execution window belong in ephemeral flows or outside Terraform entirely.

Q: What are the signs that Terraform secret handling is failing in practice?

A: Common warning signs include secrets appearing in version control, configuration files, logs, or Terraform outputs, along with teams sharing credentials across environments. Another indicator is repeated manual credential updates instead of controlled rotation. If state files are unencrypted or broadly accessible, secret handling is already outside an acceptable security boundary.

Q: How should teams govern Terraform credentials and state access together?

A: Govern them as one identity path. The credentials Terraform uses to reach cloud APIs or a secrets platform should be short-lived, while the state backend should be encrypted, versioned, locked, and readable only by the automation identity that needs it. That keeps execution access and storage access from collapsing into the same blast radius.

Technical breakdown

Why Terraform state stores secret values

Terraform state is a reconciliation record, not a vault. It stores resource attributes so Terraform can determine what already exists and compute the next change set. That includes inputs you pass, values Terraform generates, outputs derived from those values, and data source reads that must persist for stable plans. The sensitive flag changes presentation in the CLI and plan output, but it does not alter how the value is written to state. In practice, that means the plaintext copy is a byproduct of normal operation unless the run path is redesigned so the value never enters state at all.

Practical implication: treat state as a secret-bearing artifact and design workflows so sensitive values never reach it in the first place.

Why data sources still leave secrets behind

A data source is still a read, and Terraform records the result in state so later plans are deterministic. That is useful for stable infrastructure changes, but it becomes a secret exposure problem when the fetched value is a password, token, or other credential. In the article’s example, Infisical serves as the source of truth, while Terraform only pulls values at plan or apply time. That removes secrets from Git, but it does not remove them from state unless the value is fetched through a mechanism designed to avoid state persistence, such as an ephemeral resource.

Practical implication: use data sources only when you accept state persistence, and reserve ephemeral reads for values that must not be stored.

How ephemeral resources change the storage model

Ephemeral resources are the key architectural shift in the article. They let Terraform fetch a value during a run and then discard it so the secret is not written into state or the plan file. That changes the trust model from persistent storage to transient execution, which is a much better fit for passwords, credentials, and similar runtime inputs. The secret still exists long enough for the provider to use it, but it does not become part of Terraform’s durable record. That is the cleanest way to separate infrastructure state from secret state when the workflow supports it.

Practical implication: move run-time-only values to ephemeral flows and keep durable state for infrastructure metadata, not credentials.

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.
• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

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

State file exposure is a lifecycle failure, not a display problem: Terraform’s sensitive flag solves visibility on screen, but it does not solve where the secret lives after the run. The article shows that a secret can be hidden in the plan and still be plain text in state, which means the governance failure sits at storage and lifecycle boundaries. Practitioners should stop treating redaction as protection and start treating state as a governed credential repository.

Ephemeral runtime access is the boundary that matters: If the secret must only exist while Terraform is executing, then persistent state is the wrong control plane. The article’s ephemeral resource pattern reframes secret handling from retention to transient use, which is the correct discipline for NHI and automation workflows that only need a value long enough to complete a task. The implication is that control design must follow data residency, not just workflow convenience.

Secret sprawl now includes infrastructure state: The article makes clear that secrets do not just sprawl across repos and CI logs, they also spread through backend copies, local files, and artifacts. That creates multiple recovery and revocation points for the same value, which expands the blast radius of a single leak. NHI governance has to account for every durable copy, not only the original secret source.

Terraform credentials are themselves part of the identity problem: The credentials used to authenticate Terraform to Infisical and cloud platforms are often more sensitive than the secrets Terraform is meant to retrieve. Short-lived OIDC-based identity reduces standing access and removes one more stored secret from the pipeline. That aligns machine access with least privilege and makes the Terraform execution path easier to govern.

Identity blast radius is now tied to state backend design: The article’s state backend guidance shows that encryption, versioning, locking, and access scoping are not generic hygiene. They are the controls that decide whether a leaked state file remains readable, recoverable, and shareable. Practitioners should treat backend design as part of the identity boundary, because the file that records access is also the file that can expose it.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• Read next: Secrets Management Buyer's Guide

What this signals

Secret sprawl now includes infrastructure state: Terraform’s control problem is not limited to source code. When data sources, generated values, and outputs all write into state, every backend copy becomes part of the credential lifecycle, which means state access must be governed like secret access.

The practical shift is to move from display redaction to storage avoidance. Ephemeral resources change the unit of control from durable persistence to transient run-time use, which is the right model when a secret should exist only long enough for Terraform to complete a task.

For practitioners

• Use ephemeral resources for run-time-only secrets Reserve Terraform data sources for values that can safely persist in state, and move passwords or tokens that only need to exist during a run into ephemeral flows.
• Remove secret values from code and variables Store real secret values in a dedicated secrets manager and pass references or environment bindings into Terraform instead of hardcoding values in .tf or .tfvars files.
• Harden the state backend as a sensitive store Encrypt the backend, enable versioning and locking, and restrict read access to the identities that actually run Terraform, because state may still contain readable secret material.
• Replace standing CI credentials with short-lived identity Use OIDC-based federation for pipeline authentication so the job can fetch required values without keeping long-lived client secrets in the runner, secrets store, or repository.

Key takeaways

• Terraform state can hold secret values in plain text even when the plan and console output look safe.
• The article’s example shows that sensitive=true hides a value from display but does not remove it from storage or backend copies.
• The control that changes the outcome is not redaction, but moving secret handling to ephemeral runtime flows and locking down the state backend.

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.
• Ephemeral Resource: A cloud resource that exists briefly and may be created, changed, and deleted within a short operational window. These resources are common in serverless, autoscaling, and automation-heavy environments, and they challenge inventory, tagging, and compliance processes that assume longer-lived assets.
• Sensitive value: A sensitive value is a Terraform marking that redacts display in plans, outputs, and logs. It does not encrypt the underlying data, prevent state storage, or change who can retrieve the value from backend copies, so it is useful hygiene but not a storage control.
• State Backend: A state backend is the storage location where Terraform keeps its state file, whether local or remote. Because the backend may hold plaintext secret values, it must be encrypted, access controlled, versioned, and locked with the same care applied to other sensitive identity data.

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.