Terraform sensitive = true hides secrets from output, not from state

No, sensitive = true does not keep a secret out of Terraform state. It only redacts the value in CLI and UI output. The value is still stored in the state file and in saved plan files. Protect those files like credentials, and use ephemeral values where your providers support them.

What the flag actually does

Setting sensitive = true on a variable or output tells Terraform to mask that value when it prints a plan or apply. Terraform also treats any expression that references a sensitive value as sensitive, so the mask spreads to derived values.

That is a display feature. HashiCorp's documentation says Terraform stores sensitive values in both state and plan files. It also notes that the output command with -json or -raw shows the value in plain text.

So the flag helps with one risk: someone pasting a CI log into a ticket. It does nothing for the risk that someone can read the state file.

Where the secret ends up

Think of every place a state file or plan file can land.

• The remote backend bucket or storage account.
• Backups and versioned copies of that bucket.
• A local terraform.tfstate on a laptop, which is plaintext.
• CI artifacts, when a pipeline uploads a saved plan for review.
• Anyone with read access to the backend, including broad admin roles.

A database admin password created by Terraform is the usual example. The password is generated or supplied at apply time, passed to the resource, and then recorded in state so Terraform can compare it next time.

A practical order of fixes

1. Do not commit state or plan files to Git. Add them to your ignore file.
2. Use a remote backend with encryption at rest, narrow read access and audit logs.
3. Restrict who can run terraform output and who can read the backend. Reading state is equivalent to reading every secret in it.
4. Stop putting secrets in configuration when you can reference them. Let the resource pull a secret from a secrets manager at runtime instead of passing the value through Terraform.
5. Where a provider supports it, use ephemeral values or write-only arguments, covered in the next section.

Ephemeral values are the newer answer

Terraform 1.10 added ephemeral values and ephemeral resources, which exist only at runtime and are omitted from state and plan files. Terraform 1.11 added write-only arguments, which pass a temporary value to a managed resource without persisting it. These arguments usually end in _wo and pair with a _wo_version argument that you bump to trigger an update.

There are limits. Providers decide which resources offer write-only arguments, so check each one. Ephemeral values cannot be used on root module outputs, and they do not persist, so anything you need later must live somewhere else.

You can combine ephemeral with sensitive to omit a value from state and redact it in the CLI.

What to look for in review

When reviewing a Terraform change, ask whether a new variable holds a credential, and where that credential comes from. If it arrives through a variable file in the repository, that is the first thing to fix, whatever flag is set on it. If the resource supports a write-only argument for that field, prefer it.

Safeguard can help here at the edges: its dependency and SBOM scanning covers the providers and modules your configuration pulls in, and its policies and gates can block merges that fail checks you define. It does not replace protecting your state backend.

Quick check

Sources

• Manage sensitive data in your configuration (HashiCorp Terraform)
• terraform plan command reference (HashiCorp Terraform)

Last reviewed: 19 October 2026.