August 11, 2026
Posted by Akeyless
Key Takeaways
- OpenTofu has no built-in secrets manager; it relies on marking variables sensitive, remote state, and optional state encryption, none of which was purpose-built for secrets specifically.
- OpenTofu v1.11 (December 2025) added ephemeral resources and write-only attributes, letting compatible providers hand OpenTofu a secret living only in memory and never touching the state or plan file.
- Even combined, OpenTofu’s native tools leave two things unresolved: automated rotation and a centralized audit trail of who accessed which secret.
- Local OpenTofu state is stored as plain-text JSON by default; remote state removes the local-disk copy but still depends on the backend for encryption.
- Akeyless’s OpenTofu and Terraform provider issues static, dynamic, and rotated secrets plus PKI and SSH certificates through scoped auth methods, though the secrets it returns still land in state today, the way most provider data sources do.
Quick Answer: How Do You Manage Secrets Securely in OpenTofu?
OpenTofu has no built-in secrets manager. Local state stores secrets in plain text by default, and even encrypted state only protects data at rest, not while OpenTofu is actively using it. Production use needs ephemeral resources, a dedicated secrets manager, or both, to keep credentials out of state and add the rotation and audit logging OpenTofu doesn’t provide on its own.
- Don’t store long-lived static secrets in .tfvars files or hardcode them into a configuration.
- Use ephemeral resources (OpenTofu v1.11+) with a compatible provider, following the same just-in-time principle, to keep a secret out of state entirely.
- Encrypt state and plan files for anything that still lands in state, and restrict who can read the backend.
Quick Facts
| Category | Data Point |
| Secrets sprawl | 28.65 million new hardcoded secrets were added to public GitHub commits in 2025, a 34% increase year over year (GitGuardian State of Secrets Sprawl 2026) |
| Internal exposure | Internal repositories are roughly 6 times more likely than public ones to contain hardcoded secrets, the kind of private backend most OpenTofu state lives in (GitGuardian State of Secrets Sprawl 2026) |
| Remediation lag | At least 64% of secrets confirmed valid in 2022 were still active and exploitable when GitGuardian retested them in January 2026 (GitGuardian State of Secrets Sprawl 2026) |
| Native state storage | Local OpenTofu state is stored as plain-text JSON by default, with sensitive resource attributes readable to anyone with file access (OpenTofu’s own language documentation) |
| Newest native fix | OpenTofu v1.11.0, released December 9, 2025, introduced ephemeral resources and write-only attributes, the first native language features built specifically to keep secrets out of state (OpenTofu’s own release blog) |
OpenTofu, the open-source fork of Terraform, inherits the same core limitation as its parent: no built-in way to manage secrets, so how a team handles credentials determines whether a compromised pipeline or leaked state file becomes a minor incident or a full breach.
Every pipeline authenticates to cloud providers, provisions databases, and configures services. Nearly every one of those steps depends on a credential OpenTofu is holding somewhere, in a variable, a provider block, or the state file itself.
Most teams reach for OpenTofu because it keeps Terraform’s mature ecosystem without the licensing risk behind the fork. The provider registry, the module ecosystem, and the language itself all carry over largely intact. The continuity stops at secrets, though. OpenTofu secrets management is left entirely to the teams running it, the same way Terraform always left it, and unmanaged credentials are exactly how secrets sprawl starts.
The rest of this guide covers how OpenTofu handles secrets natively and where the native model breaks down. It closes with what a practical path to production-grade OpenTofu secrets management actually looks like.
What Is OpenTofu Secrets Management, and How Does It Work Natively?
No single feature in OpenTofu is built for secrets management; marking a variable as sensitive, storing state remotely, and enabling state encryption are the tools available natively.
Marking a variable sensitive = true hides its value from console output and the CLI’s plan and apply summaries. The value is still written to the state file in plain text underneath the redaction.
Storing state remotely, in an S3 bucket, a Terraform Cloud-compatible backend, or similar, keeps OpenTofu from persisting a local copy to disk. The backend can add its own encryption and access controls if configured to do so. Local state, by contrast, is stored as plain-text JSON with no protection beyond file permissions.
Enabling state and plan encryption, an OpenTofu-native feature, wraps state and plan files with a configurable key provider and encryption method. It protects the data at rest regardless of backend.
None of these three tools was designed around secrets specifically. Sensitive marking is a display setting, remote state is a storage location, and encryption addresses only data at rest, not a credential while OpenTofu is actively using it.
How Do You Keep Secrets Out of OpenTofu State?
OpenTofu v1.11 added ephemeral resources and write-only attributes. Compatible providers can now hand OpenTofu a secret living only in memory for the length of one run, never touching the state or plan file.
An ephemeral resource requests a secret from a provider at the moment OpenTofu needs it and discards it when the run finishes:
ephemeral "aws_secretsmanager_secret_version" "db_credentials" {
secret_id = aws_secretsmanager_secret.db.id
}
provider "postgresql" {
host = aws_db_instance.main.address
username = jsondecode(ephemeral.aws_secretsmanager_secret_version.db_credentials.secret_string)["username"]
password = jsondecode(ephemeral.aws_secretsmanager_secret_version.db_credentials.secret_string)["password"]
}Write-only attributes work alongside ephemeral resources for values a resource needs only when they change, an initial database password, for example, rather than on every read.
Ephemeral resources require the provider to implement support for them specifically. A provider exposing only standard data sources still writes fetched values to state the way it always has. Check whether a given provider supports the ephemeral resource type before relying on it.
Credentials helpers get confused with general secrets management, and they’re worth separating out here. A credentials helper is a distinct OpenTofu mechanism for authenticating to remote services like module registries. It doesn’t apply to secrets a configuration fetches for provisioning resources.
Why OpenTofu’s Native Secrets Handling Isn’t Enough for Production
Even the best combination of native safeguards still leaves two things unresolved: automated rotation and an audit trail of who accessed what.
Secrets can also leak at three separate points along the way: unmarked variables printed during plan, credentials exposed to provider calls and logs during apply, and resource attributes written to state after apply.
Any variable not explicitly marked sensitive can appear in plan output, console logs, and CI pipeline output, exactly where a reviewer or an attacker with log access would look first.
During apply, OpenTofu passes credentials to provider plugins and to any provisioner in the configuration. A provisioner command including a credential can print that value to the apply log the same way a plain console statement would.
After apply, every resource attribute gets written into the state file, including any value placed in a regular argument instead of an ephemeral one, whether or not it was ever marked sensitive.
Marking variables sensitive, encrypting state, and adopting ephemeral resources everywhere a compatible provider allows still leaves two things unresolved. Nothing in OpenTofu rotates a credential automatically, and nothing in OpenTofu logs who read a given secret from state or from a provider call. The same two problems show up across CI/CD pipelines generally, not just OpenTofu runs. Missing rotation has a measurable cost: at least 64% of secrets confirmed valid in 2022 were still active and exploitable when GitGuardian retested them in January 2026, a sign that unrotated credentials tend to stay that way.
A Practical Checklist for Securing OpenTofu Secrets
Securing OpenTofu secrets means enabling state encryption and restricting state access immediately, then rebuilding the credential-fetching pattern around ephemeral resources or a dedicated secrets manager for anything long-term.
Immediate fixes: enable state and plan encryption using a key provider and method suited to your security requirements, and treat the encryption key itself as a secret with its own backup and rotation plan. Store state in a remote backend with server-side encryption enabled rather than leaving it on local disk. Mark every genuinely sensitive variable and output, even though the value still lands in state, since it at least keeps the value out of console and CI logs.
Long-term fixes: move to ephemeral resources for any provider supporting them, so new secrets stop landing in state going forward. Adopt a dedicated secrets manager for credentials needing automated rotation, scoped access control, or an audit trail, none of which OpenTofu provides natively. Avoid .tfvars files and hardcoded values entirely; both persist a secret in a location OpenTofu never intended to protect.
What Are the Different Approaches to OpenTofu Secrets Management?
Every approach to OpenTofu secrets trades setup effort against how much gets automated. Three questions decide it: whether secrets ever touch state, how they rotate (static, rotated, or dynamic), and whether there’s an audit trail of access.
| Approach | How It Works | Secrets in State? | Rotation | Audit Trail |
| Sensitive variables + state encryption | Native OpenTofu features; values are masked in output and encrypted at rest | Yes | Manual | None built in |
| Ephemeral resources (OpenTofu v1.11+) | Compatible provider hands OpenTofu a secret existing only in memory for one run | No | Depends on the source system | Depends on the source system |
| Dedicated secrets-manager provider | OpenTofu fetches static, dynamic, or rotated secrets and certificates from a SaaS secrets manager at runtime | Depends on provider support for ephemeral resources | Automated, policy-driven | Centralized, outside OpenTofu |
Why Keeping Secrets Out of State Isn’t the Whole Solution
Ephemeral resources solve where a secret is stored during a single run, not who can request it, how often it rotates, or whether a certificate gets issued alongside it.
A secret that never touches state can still be a long-lived, unrotated credential handed to anyone who can run tofu apply. Ephemeral resources change where the value sits, not how tightly it’s controlled.
OpenTofu configurations frequently need more than passwords and API keys. SSH keys signed for a specific host and PKI certificates issued for mutual TLS both need the same scoping and auditing as secrets. Neither is something ephemeral resources or state encryption were built to issue.
A team that adopts ephemeral resources everywhere a provider allows has solved secret storage. Access control, rotation, and certificate issuance are still separate problems.
How Akeyless Secures OpenTofu Secrets and Certificates
The Challenge
Keeping a secret out of OpenTofu state solves half the problem; the other half is controlling who can request it, rotating it automatically, and issuing the certificates a deployment needs from the same governed source.
The Approach
Akeyless’s Terraform and OpenTofu provider scopes access through auth methods including Universal Identity, AWS IAM, Azure AD, and GCP. It fetches static, dynamic, and rotated secrets, and issues PKI and SSH certificates from the same provider. A dynamic-secret data source like akeyless_producer_tmp_creds returns short-lived, auto-expiring credentials instead of a static value:
provider "akeyless" { api_gateway_address = "https://api.akeyless.io" uid_login { access_id = var.akeyless_access_id uid_token = var.akeyless_uid_token }}
data "akeyless_producer_tmp_creds" "db" { name = "/opentofu/prod-db-producer"}The Outcome
As of provider version 2.0.2, the secrets Akeyless’s data sources return still land in OpenTofu state, the way most provider data sources do. The provider’s registry listing shows no ephemeral resource type yet, unlike the newest hashicorp/aws and similar providers. Dynamic and rotated secrets narrow the exposure window since a leaked value expires or gets replaced on its own. Pairing the provider with OpenTofu’s own state encryption covers the rest.
How Enterprises Already Trust Akeyless With Credential Management
Neither Progress’s case study nor Cimpress’s names OpenTofu specifically, but both describe the same operational shift this guide recommends for OpenTofu pipelines: moving off manual, static credential handling and onto centrally governed secrets management.
Progress Software, a global software company operating in 16 countries, adopted Akeyless to fight secrets sprawl across a multi-cloud environment inherited through acquisitions. Their published case study credits “frictionless DevOps integration,” citing fast adoption “with no code changes” and CI/CD pipelines connecting “instantly with no rework or delays.” Richard Barretto, Chief Information Security Officer and VP at Progress, put it simply: “Akeyless is true SaaS that allows you to scale. It’s purpose-built to live in the cloud. We saved 70% of our maintenance and provisioning time with Akeyless.”
Cimpress’s experience points at the other half of the equation, credential rotation specifically. Conor Mancone, Principal Application Security Engineer at Cimpress, described the shift away from manual rotation directly: “We set Akeyless up nine months ago and we haven’t had to worry about credential rotation. We haven’t had to worry about credential leakage. All of our software that’s running, it just works, we haven’t really had to think about it since then.” Cimpress’s deployment isn’t OpenTofu-specific either, but the underlying problem is exactly what an OpenTofu pipeline runs into as usage grows: static credentials that someone has to remember to rotate.
How Do You Choose the Right Approach for Your OpenTofu Deployment?
The right approach depends on the deployment, not a fixed rule from either case study.
A low-risk internal tool with scoped, well-audited access can often run on native sensitive variables and encrypted state alone. A deployment touching production data, customer information, or a compliance-regulated system needs more: ephemeral resources or a dedicated secrets manager, automated rotation, and an audit trail that a leaked state file or a compromised run can’t simply expose.
The deciding factor is exposure: how many resources does a single credential touch, and how long does it stay valid if it leaks. The more a credential can reach, and the longer it stays valid, the less native OpenTofu tools should be trusted alone.
FAQs About OpenTofu Secrets Management
Do Ephemeral Resources Work With Every OpenTofu Provider?
No. A provider has to implement the ephemeral resource type specifically; OpenTofu’s own examples use hashicorp/aws, and support varies by provider and version. Before relying on ephemeral resources for a given secret, check that provider’s own documentation for an ephemeral resource type rather than assuming every data source has an ephemeral equivalent.
Does State Encryption Protect a Secret While OpenTofu Is Running, Not Just at Rest?
No. OpenTofu’s own documentation is explicit: encryption protects data at rest. Once OpenTofu decrypts state or plan data to run a command, the sensitive values are available in memory to whoever is running the command. Encryption stops an attacker who steals the file, not a person with legitimate access to the run.
Can HashiCorp Vault Fill the Same Role as a Native OpenTofu Secrets Manager?
Yes, through the same kind of provider integration Akeyless and other secrets managers use. Vault’s Terraform provider works with OpenTofu because both share the same registry protocol, and it can supply dynamic secrets and manage the credential lifecycle Vault is configured to handle. Running Vault itself is a separate operational commitment from the provider integration: cluster setup, unsealing, and policy management.
Is a Local Passphrase Good Enough for State Encryption, or Does It Need a Key Management System?
It depends on how many people need direct access to the state file. A single-developer project can reasonably use a passphrase-based key provider. Larger teams should move to a key management system with automatic rotation instead. Some encryption methods reach a safe usage limit the more they’re used, and OpenTofu’s own encryption documentation recommends planning key rotation before that happens.
Does Migrating From Terraform to OpenTofu Affect Existing Secrets in State?
Not directly. OpenTofu reads existing Terraform state files up through the versions it supports, so secrets already sitting in state carry over unchanged. Migrating is a good moment to add state encryption or move to ephemeral resources, since a state file inherited from Terraform is exactly as exposed as one OpenTofu created natively.
