TL;DR: OpenTofu has no built-in secrets management, so credentials often leak across plan, apply, and state workflows unless teams use external controls, according to Infisical’s integration guide. Ephemeral resources and OIDC reduce exposure, but the real shift is treating secrets handling as an identity governance problem, not a configuration convenience.
At a glance
What this is: This is a practical integration guide showing how OpenTofu users can move secrets handling out of .tfvars files, environment variables, and state storage by using Infisical, ephemeral resources, and OIDC-backed machine identity.
Why it matters: It matters because identity and infrastructure teams need to control where secrets appear during provisioning, not just where they are stored, or they will keep leaking into CI, logs, and state files.
Context
OpenTofu does not natively manage secrets, which leaves teams to bridge a governance gap across planning, deployment, and state handling. In practice, that means credentials can surface in files, pipeline logs, and runtime memory even when the infrastructure code itself is otherwise well structured.
The article frames this as an operational identity problem, not just an IaC convenience issue. Once secrets are introduced into a provisioning workflow, the question becomes which identity is allowed to fetch them, when they exist, and whether they persist long enough to be copied into state or logs.
Key questions
Q: What breaks when OpenTofu workflows rely on .tfvars files or environment variables for secrets?
A: Secrets can leak into Git history, CI logs, crash reports, and state files, which turns a deployment convenience into a persistent exposure path. The failure is not just storage, but uncontrolled propagation across planning, execution, and recovery artefacts. Teams need a runtime retrieval model instead of static injection.
Q: Why does OIDC reduce secrets risk in OpenTofu pipelines?
A: OIDC removes the need to store a long-lived credential just so a runner can authenticate to the secrets platform. That matters because bootstrap secrets are often the weakest link in CI/CD, especially when multiple systems can read pipeline variables or logs. Short-lived identity exchange narrows the exposure window.
Q: How do teams know whether OpenTofu secrets handling is actually safe?
A: Safe handling means secrets are fetched only when needed, are not written to state, and do not survive in logs or pipeline variables after execution. If a credential can be recovered later from state or build output, the control is not working as intended. Persistence is the clearest warning sign.
Q: What is the difference between ephemeral resources and data sources for secrets?
A: Ephemeral resources fetch secrets during execution and avoid persisting them to state, while data sources still store the returned values in state. The practical difference is recoverability: anything in state can be exposed later to anyone who can read it. Use ephemeral resources for sensitive credentials and data sources only for low-risk values.
Technical breakdown
Why OpenTofu plan, apply, and state create secrets exposure points
OpenTofu workflows touch secrets at three different stages. During plan, variable values can appear in output if they are not marked sensitive. During apply, provider calls and automation logs can capture values as they are used. In state, resource attributes may store secret material unless the workflow avoids persistence entirely. Native state encryption helps at rest, but it does not remove exposure during execution, so the control problem is lifecycle management rather than file protection.
Practical implication: Treat plan, apply, and state as separate exposure zones and design controls for each one.
Ephemeral resources vs data sources in OpenTofu
Ephemeral resources change the secrets model by fetching values at runtime without writing them to state, which is the right pattern for high-value credentials. Data sources still work for older versions or lower-sensitivity values, but they reintroduce state exposure. The architectural difference is simple: ephemeral resources keep secrets transient, while data sources make them retrievable again later through the state file. That distinction matters because persistence, not just encryption, drives blast radius.
Practical implication: Use ephemeral resources for credentials that should never be recoverable from state, and reserve data sources for lower-risk values.
OIDC removes the bootstrap secret problem
OIDC solves the bootstrap issue by letting the CI platform prove the runner's identity directly, so the pipeline does not need to store long-lived authentication material just to reach the secrets platform. That breaks the common pattern where one secret is stored in order to retrieve another secret. Universal Auth is a fallback, but it still depends on a stored credential and therefore keeps residual exposure in the pipeline.
Practical implication: Prefer OIDC-backed machine identity whenever the CI environment supports it, because it removes the standing secret required for access.
Threat narrative
Attacker objective: The objective is to capture reusable infrastructure credentials that can be abused beyond the OpenTofu workflow.
- Entry occurs when teams place .tfvars files, environment variables, or hardcoded values into OpenTofu workflows, creating multiple opportunities for credential exposure during provisioning.
- Credential access happens when those values surface in Git history, CI logs, crash reports, or state files, giving an attacker or insider usable secrets rather than just configuration context.
- Impact follows when exposed credentials can be reused outside the provisioning path to access downstream systems, modify infrastructure, or retrieve additional sensitive data.
Breaches seen in the wild
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
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
OpenTofu secrets handling is really lifecycle governance, not file hygiene: the control question is where a credential exists, who can fetch it, and whether it persists beyond the task that needs it. When teams rely on .tfvars files or environment variables, they are governing a secret by convention rather than by lifecycle boundary. The practitioner conclusion is that provisioning workflows need explicit issuance, use, and disposal rules.
Ephemeral secrets create a smaller identity blast radius than stored secrets: the important shift is not just encryption but non-persistence. If a secret is never written to state, it cannot be recovered from state later, which removes an entire post-deployment exposure path. That makes ephemeral fetches a stronger governance primitive than static injection for sensitive infrastructure credentials.
OIDC changes the trust model for CI/CD runners: the pipeline no longer needs a standing credential simply to prove it is allowed to ask for one. That reduces the number of artefacts security teams must inventory, rotate, and monitor. The practical implication is that machine identity policy moves closer to the moment of execution.
Runtime retrieval boundary: this is the key concept for OpenTofu secret governance because it marks the point where secrets move from stored artefacts to transient session data. Once teams define that boundary clearly, they can separate low-risk configuration from credentials that should never touch state. The practitioner implication is to design every OpenTofu workflow around retrieval at use time, not storage before use.
From our research library:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
- Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets
What this signals
Runtime retrieval boundary: OpenTofu governance should be built around the moment a secret is fetched, not around where it is stored after the fact. When credentials exist only during execution, the attack surface collapses from long-lived artefacts to short-lived session state, which is materially easier to govern.
OIDC-backed machine identity is the right pattern when CI/CD systems need to prove who they are without carrying reusable bootstrap secrets. That approach also aligns better with broader non-human identity governance, because the runner becomes an authenticated actor with a bounded task rather than a container for standing credentials.
For practitioners
- Use ephemeral resources for sensitive credentials Fetch high-value secrets at plan or apply time and avoid writing them into state files, console output, or intermediate variables.
- Adopt OIDC for CI/CD authentication Let the runner present a short-lived identity token instead of storing long-lived secrets in pipeline variables or repository settings.
- Keep data sources for lower-risk values only If you must use data sources on older OpenTofu versions, restrict them to non-sensitive configuration and rely on encrypted remote state for everything else.
- Separate read and write identities Give deployment jobs read-only access to the secrets they need, and reserve write permissions for a separate secrets administration workflow.
- Scope machine identities by project and environment Create narrowly bounded identities for each workspace or environment so a compromised pipeline cannot pivot across unrelated secrets sets.
Key takeaways
- OpenTofu does not remove the secrets problem by default, because the exposure risk moves through plan, apply, and state rather than disappearing.
- Ephemeral resources and OIDC reduce that exposure by keeping credentials out of state and out of long-lived pipeline storage.
- The governance question is who can fetch a secret, when it exists, and whether it survives long enough to be copied into logs or reused elsewhere.
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 escaping into files, logs, and state during OpenTofu runs. |
| NHI-07 — Long-Lived Secrets | The guide contrasts static credentials with ephemeral and OIDC-backed approaches. | |
| NHI-04 — Insecure Authentication | OIDC versus stored pipeline secrets is a core authentication design choice in the article. | |
| Recommendation — Scan OpenTofu workflows for leaked secrets and remove any credential path that writes to logs or state. Replace standing OpenTofu credentials with short-lived tokens and runtime secret fetches. Use federated authentication for CI/CD runners instead of stored bootstrap credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article repeatedly addresses credential lifecycle, rotation, and replacement. |
| Recommendation — Apply authenticator lifecycle controls to eliminate static secrets from provisioning workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The guide stresses narrow scoping for machine identities and read versus write access separation. |
| Recommendation — Restrict secret access to the minimum entitlement needed for each OpenTofu job. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is secrets exposure that enables credential access through logs, state, or source control. |
| Recommendation — Map exposed OpenTofu secrets to credential-access tactics and prioritise removal from persistent artefacts. | ||
Key terms
- 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.
- Retrieval Boundary: The set of permissions and scope limits that determine what information an AI assistant can search, summarise, or expose on behalf of a user. When retrieval boundaries are too broad, the model can reconstruct information that the user should not directly access.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Bootstrap Secret: A bootstrap secret is the initial credential used to retrieve or mint other credentials in a workload identity flow. It is often the weakest point in the chain because it must exist before the stronger, short-lived identity can be established, so it needs strict isolation and lifecycle control.
Deepen your knowledge
NHI governance, machine identity security, and secrets management 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 or secrets governance 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