In terms of access, yes. The terraform_remote_state data source returns only root module outputs, but HashiCorp notes that whoever uses it must have access to the entire state snapshot, which often includes sensitive information. Publishing shared values to a separate store lets you apply different access controls.
What the data source does
Teams often split infrastructure into several Terraform configurations: networking in one, applications in another. The application config needs the subnet IDs. The terraform_remote_state data source reads the latest state snapshot from the backend and hands back the output values.
The catch is how it reads them. It fetches the state, so the identity running the consuming configuration needs permission to read the whole state object. State can hold initial database passwords and API tokens, as HashiCorp's guidance on sensitive data explains.
Why this is a least privilege problem
If a pipeline for a low risk application can read the networking state, it can also read everything else in that file. Anyone who compromises that pipeline gets the same access. The data source is convenient, but it turns a need to know one subnet ID into read access to a whole snapshot.
HashiCorp recommends, when possible, publishing data explicitly to a separate location so you can use different access controls for shared information and state snapshots. For HCP Terraform and Terraform Enterprise it recommends the tfe_outputs data source, which does not require full access to workspace state.
Alternatives the documentation lists
| Where to publish | Resource that writes it | Reader |
|---|---|---|
| Amazon SSM Parameter Store | aws_ssm_parameter resource | aws_ssm_parameter data source |
| Amazon S3 | aws_s3_object resource | aws_s3_object data source |
| Private DNS records | DNS record resources | Normal DNS lookups |
| Kubernetes ConfigMap | kubernetes_config_map resource | kubernetes_config_map data source |
| HCP Terraform outputs | Normal outputs | tfe_outputs data source |
A side benefit the documentation points out: other systems can read these stores too, such as configuration management tools or workloads, which they cannot do with a state file.
How to move off it
- List every configuration that uses terraform_remote_state and which outputs each really reads.
- Choose a store for each kind of value. IP addresses and hostnames suit DNS. Small settings suit a parameter store.
- Publish those values from the producing configuration.
- Switch consumers to the matching data source, ideally behind a small data only module so you can change the store later.
- Remove state read permission from consumer roles and confirm the pipelines still pass.
See also why sensitive true does not keep secrets out of state.
Quick check
If I only read outputs, is my access limited to outputs?
Not through this data source. The documentation says the user must have access to the entire state snapshot.
Is the fix to mark outputs as sensitive?
No. That redacts CLI display. It does not change who can read the state object itself.
Safeguard runs policies and gates on pull requests, so a failed rule can hold a merge, and its dependency and SBOM scanning covers the packages your infrastructure code pulls in. You can try a free scan at gold.safeguard.sh/scan.
Sources
- The terraform_remote_state data source, HashiCorp
- Manage sensitive data in your configuration, HashiCorp
Last reviewed: 19 October 2026.
