Skip to main content
Let’s look at the key features introduced in OpenTofu v1.7.0 and how to use them safely. This release focuses on state protection and flexible state management, with two notable additions:
  • State encryption for protecting state and plan files at rest (local and backend).
  • The removed block to forget resources from state without destroying the underlying infrastructure.
These are features the community has asked for to improve security and operational control over infrastructure as code.
A presentation slide titled "Upcoming Features" showing two feature cards: an orange "State Encryption" card with a lock icon and a purple "Removed Block" card with a document-and-trash icon.

Overview

  • State encryption ensures tfstate and plan artifacts are stored encrypted at rest, both for local storage and when using a backend. It also works with the OpenTofu remote state data source.
  • The removed block provides a safe method to stop OpenTofu from managing a resource while leaving the resource intact in the provider.
For more background on OpenTofu concepts and commands, see the official OpenTofu documentation: OpenTofu Documentation (reference).

State encryption

State encryption protects sensitive data that may be present in state or plan files. Before you enable encryption on an existing state, make a full backup of your current state file (for example, terraform.tfstate or any backend snapshot). Enabling encryption without retaining the key will make existing and future encrypted state and plan files unrecoverable.
Encryption makes your state and plan files unreadable without the corresponding key. Always back up your state and ensure you securely store the encryption key before enabling encryption.

Example: AES-GCM with PBKDF2 key provider

This HCL example configures OpenTofu to use a PBKDF2-derived key provider and AES-GCM encryption. Important: when migrating an existing unencrypted state, include an empty fallback {} block so OpenTofu can read the prior unencrypted data during the migration step. Remove fallback {} after the migration is complete.
Best practices and important notes:
  • Store your passphrase (or derived key) in a secure secret manager or key vault. If you lose it, encrypted state and plan files cannot be decrypted.
  • After validating the migration to encrypted state, remove the fallback {} block to stop accepting the legacy unencrypted format.
  • Test the full workflow (plan/apply and remote state reads) in a non-production environment before rolling out to production.

Migrating back to an unencrypted state

Reverting to an unencrypted state is supported but requires explicit configuration: set the target unencrypted method and include the prior encryption method in fallback during migration. As with enabling encryption, back up state, validate changes, and verify recoverability after migration.

The removed block

The removed block is for cases when you want to stop managing a resource with OpenTofu but keep the actual resource running with the provider. Typical workflow:
  1. Create and apply a managed resource as usual.
  2. Remove the resource block from your configuration when you no longer want OpenTofu to manage it.
  3. Add a removed block that points to the resource address via the from attribute.
  4. Run tofu plan and tofu apply — OpenTofu will remove the resource from state without issuing a destroy to the provider.
Use removed when you need to hand off management of a resource to another tool or manage it manually. Always test the removal in a safe environment and keep state backups.

Example: create then stop managing a local file resource

  1. Define a managed resource:
  1. Create the resource:
  1. Stop managing the resource but retain the file:
  • Remove the local_file.test resource block from your configuration.
  • Add the removed block that refers to the resource address.
  1. Run a plan to confirm the state change:
OpenTofu will indicate that the resource is being forgotten from the state (no destroy will be performed on the underlying resource). After tofu apply, the resource is removed from the state file but the physical file test.txt remains on disk.

Quick reference table

Summary and recommendations

  • OpenTofu v1.7.0 brings state encryption (AES-GCM example shown) and the removed block for safer operational control.
  • Always back up state files and securely store encryption keys before enabling encryption.
  • Test encryption and removal workflows in a non-production environment, verify remote state reads, and remove fallback {} only after successful migration verification.
  • Refer to the OpenTofu docs for more details and provider-specific considerations: OpenTofu Documentation.

Watch Video