Encrypt Terraform state at rest with OpenTofu

Not automatically. A consumer that reads another configuration's outputs through terraform_remote_state only sees decrypted data if it runs an OpenTofu version that can decrypt that state and has the matching key configuration. The OpenTofu migration overview warns that configurations sharing data this way typically need additional care during migration and links a separate guide for that case, so follow that guide before you change encryption on shared state. Confirm each consumer's behavior in your own environment by running a read against a test copy of the state before you switch the producing configuration.

Yes, if they read state through OpenTofu or read the encrypted file directly. Any job that needs decrypted values must have access to the same key provider, such as an AWS KMS key, a GCP KMS key, an OpenBao transit key or a PBKDF2 passphrase, with permission limited to what the job needs. Scripts that only parse plan output or call tofu output in a runner already authorized for the key will keep working, while jobs that parse raw state JSON without the key will fail. Inventory every job that touches state, grant key access per job, and test each one in a non-production workspace.

The state versions API is a source of state only during the migration, and its behavior depends on what the workspace stores. HCP Terraform exposes each workspace's current state through its state versions API, including a JSON state download URL for states created by Terraform 1.3 or later, and that is how state leaves the platform. Once you encrypt state in OpenTofu, the file you write locally or to your backend is encrypted, so you must decrypt it with the same key configuration before you can read it. Export the state while it is still plaintext, verify the export, then enable encryption. Confirm with HashiCorp's API documentation which download formats are available for your state version before you rely on them.

Plan files are encrypted too, so the runner that writes and later applies a saved plan must have access to the same key provider. Atlantis runs plans from pull requests and applies the saved plan after approval, so the Atlantis server needs the key configuration for the plan file it creates. Terrakube runs plans and applies inside its own executors, which also need the key. Store plan artifacts only where the workflow requires them, set retention, and confirm with each tool's documentation and a test pull request that plan and apply succeed with encryption enabled and that a plan written by one runner can be read by the next step.

Only if the tool supports OpenTofu state encryption and holds the key. Drift detection that runs tofu plan in refresh-only or read-only mode uses the same decryption path as the CLI, so it works when the runner has the key. Tools that read the state file directly, without OpenTofu, will see ciphertext and report errors or false results. Ask each drift or compliance vendor whether it reads OpenTofu encrypted state, which key providers it supports and whether it writes state back. Run a drift check against a copy of an encrypted state before you rely on its output.

Auditing tools should read decrypted state only inside a controlled runner, and the audit output should be scoped to what the auditor needs to see. Encryption at rest protects state in storage, but anyone or anything with the key can still decrypt it, so the key policy is the control that matters. Document which principals can use each key, log key usage in your cloud or secrets platform, and confirm that auditors' tooling reads state under the same access rules as your pipelines. Preparing this evidence is part of compliance readiness work, but an independent auditor or certification body decides whether the controls meet a given requirement.

Test the consumers that read state across boundaries first, because they fail in ways that are hardest to see. Start with terraform_remote_state dependencies, then CI jobs that read outputs, then pull request workflows that create and apply plans, then drift and audit tools. For each one, record the OpenTofu version, the key provider, the principal used and the expected output, and run the same read before and after the change. Keep a rollback path that uses the exported plaintext backup, and confirm the order of steps with your platform team and the migration guides from OpenTofu.

The platform or security team should own the key policy, and each consuming team should request access for a named job or service identity. Ownership should be written down so that a rotation or a new consumer does not depend on one engineer's knowledge. Key rotation requires updating every consumer that holds a key reference, so a register of consumers is part of the operating model. Ask any implementation partner to state in the written scope who maintains the register, who approves access changes and how rotation is tested before it reaches production.

The cost is made up of separate components, and only some of them are paid to a vendor. The OpenTofu CLI is free to use under the Mozilla Public License 2.0, so the encryption feature itself carries no license fee. Cloud KMS usage is billed by your cloud provider and depends on the number of keys and requests your workspaces generate. If you use OpenBao as the key provider, you pay for the hosting and for the people who operate it, either your own staff or a partner. Implementation effort rises with the number of workspaces, backends and state consumers. Ask any partner to price each component separately in a written quote, and to state which costs are one-time and which recur each month.

The duration depends on scope, mainly the number of workspaces and the number of tools and pipelines that read state. A single backend with one team is a much smaller task than a multi-account estate where state is shared across several groups. Work usually includes choosing the key provider, configuring the encryption block, migrating existing state, testing a plan against encrypted state, and updating every consumer. Ask for a written timeline with milestones tied to the scope you agree, and ask which tasks depend on other teams being available.

You need three things ready before the work starts. First, access to every state backend, including the storage buckets, databases or remote backends where state is kept, with rights to read and rewrite state. Second, named key administrators who can create, rotate and revoke keys in KMS or OpenBao and who approve changes to key policies. Third, a current list of state readers, meaning every pipeline, script, dashboard and tool that reads state, including any workspace that uses the terraform_remote_state data source. Missing readers are the most common cause of delays, because they fail once state is encrypted unless they are updated first.

Yes, for simple setups. A small number of workspaces with one key provider, one backend and a single team can usually be handled in-house by engineers who already run OpenTofu. Multi-account estates, shared backends, several key providers and many state consumers are a better fit for a fixed-scope engagement. In that case, the partner should document the design, the key rotation procedure and the test plan in writing before any state is changed. Whichever route you take, test the change on a non-production workspace first and keep a tested rollback path.

No. Encryption protects state at rest, but it does not replace access control on the backend. Anyone who can read the storage location and who holds the key can still decrypt state, so the key policy is as important as the encryption itself. Keep backend permissions narrow, separate the people who manage keys from the people who manage state, and log key use in your cloud or OpenBao audit trail. Use encryption together with least privilege, not as a substitute for it.

Tools that read state directly will fail until they support the encrypted format or receive the key. This includes custom scripts, reporting tools and any consumer that parses the raw state file. Check each consumer against the OpenTofu encryption documentation before you change the backend. Also confirm that the key provider is reachable from every runner, that CI jobs have permission to call the KMS or OpenBao endpoint, and that a plan against migrated state shows no unexpected changes.

Key rotation depends on the key provider you choose. In OpenTofu, you add the new key as a fallback before you remove the old one, so state can be decrypted during the transition. Confirm the exact steps for your provider in the OpenTofu encryption documentation and test them on a copy of state. Record who approved each rotation, schedule rotations under a written policy, and keep the previous key available until every consumer has moved to the new one.

A useful quote lists the scope in concrete terms: the number of workspaces, backends, key providers and state consumers covered. It should separate one-time work, such as design, migration and testing, from recurring work, such as key rotation, upgrades and monitoring. Ask for the deliverables in writing, including the encryption configuration, the rotation runbook, the rollback plan and the list of consumers updated. Ask which cloud or OpenBao costs are excluded and who pays for them, and confirm what happens if scope grows during the work.