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.
NHIMG editorial — based on content published by Infisical: OpenTofu Secrets Management with Infisical: A Practical Integration Guide
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should teams keep OpenTofu secrets out of state files?
A: Use runtime secret retrieval patterns that fetch values only during execution, then discard them before the run completes.
Q: Why do OpenTofu workflows create secrets risk even when state is encrypted?
A: Because encryption at rest does not remove exposure during planning, applying, or logging.
Q: What do security teams get wrong about using environment variables for secrets?
A: They often assume environment variables are safer than files, which is only partly true.
Practitioner guidance
- Replace static secret injection with runtime retrieval Move sensitive credentials out of .tfvars files, hardcoded values, and long-lived environment variables.
- Adopt ephemeral resources for sensitive values Use ephemeral secret resources for database passwords, API keys, and other high-value credentials so they never persist in the state file.
- Prefer OIDC over stored pipeline credentials Configure CI/CD to exchange short-lived identity assertions instead of storing a reusable client secret.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- The provider configuration examples for both Terraform-compatible and OpenTofu-specific execution flows.
- The GitHub Actions workflow details that show how OIDC is wired into CI/CD authentication.
- The full Vault comparison, including the operational overhead the integration guide contrasts against.
- The production deployment example with directory layout, backend settings, and resource definitions.
👉 Read Infisical's OpenTofu secrets management integration guide →
OpenTofu secrets management and the governance gap teams miss?
Explore further
OpenTofu secrets management fails when teams confuse provisioning with credential governance. Infrastructure code can be correct while the identity layer remains unsafe, because plan output, apply execution, and state storage all create separate leak surfaces. That is why this topic belongs in NHI governance rather than pure DevOps practice. Practitioners should treat every IaC workflow as a credential handling workflow first.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: Who is accountable for OpenTofu secret handling in CI/CD pipelines?
A: Accountability sits with the team that owns the pipeline, the state backend, and the secret source, because all three shape the exposure boundary. A secure design should combine short-lived machine identity, narrow access scope, and separation between deployment access and secret administration.
👉 Read our full editorial: OpenTofu secrets management with Infisical: what changes