The state file is OpenTofu’s record of what it has created and which values it has tracked. By default, local state is plain text JSON, so sensitive attributes can be read by anyone with file access. Remote state moves the file elsewhere, but the backend still must be secured.
Expanded Definition
OpenTofu state is the file or backend record that maps declared infrastructure to real deployed resources and stores tracked attributes needed for subsequent plans. In OpenTofu operations, the state becomes the source of truth for drift detection, update planning, and lifecycle coordination, which is why its confidentiality and integrity matter as much as the configuration itself. When state is stored locally, it is often plain text JSON and may expose secrets, identifiers, endpoints, and other sensitive values to anyone with file access. When state is stored remotely, the risk shifts from endpoint exposure to backend exposure, so the storage layer, access controls, encryption, and auditability all become part of the security boundary. Definitions and implementation patterns vary across vendors and backend types, but the core principle is consistent with NIST Cybersecurity Framework 2.0: protect the integrity of assets that govern system change and access.
The most common misapplication is treating state as a harmless build artifact, which occurs when teams commit it to shared repositories or leave backend access broadly open.
Examples and Use Cases
Implementing OpenTofu state rigorously often introduces coordination overhead, requiring organisations to weigh deployment convenience against stricter access control and backend governance.
- A platform team stores remote state in a locked-down backend so only the deployment role can read or modify it, reducing exposure of sensitive tracked values.
- An operations team reviews state after a failed plan to identify drift between intended and actual infrastructure, using it as a troubleshooting reference rather than a general-purpose inventory.
- A security engineer checks whether outputs in state contain API keys, tokens, or certificates, then refactors the workflow so secrets are sourced from a proper secrets system instead of state.
- A cloud team compares OpenTofu state handling to the governance issues described in the Ultimate Guide to NHIs to ensure service accounts and automation identities are not overexposed through infrastructure metadata.
- An auditor verifies that backend access logs, encryption settings, and recovery controls support change traceability and align with NIST Cybersecurity Framework 2.0 expectations for protected system records.
Why It Matters in NHI Security
OpenTofu state is highly relevant to NHI security because it can contain the very details that attackers use to pivot across automation, including service account references, secret-bearing outputs, and backend credentials. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations such as code, config files, and CI/CD tools, which makes careless state handling part of a much wider secret-sprawl problem. The same research notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, so state exposure is not a theoretical risk. If state is left readable, copied casually, or backed by an insecure remote service, the consequence is often privilege escalation through the automation plane rather than simple data disclosure. NHI governance depends on knowing where machine identities are represented, what they can reach, and which tracked values should never be broadly accessible. Practitioners also have to remember that remote state does not remove risk, it relocates it into the backend security model and the access policies around it.
Organisations typically encounter the operational impact only after a plan failure, a leaked backend credential, or an unexpected infrastructure change, at which point OpenTofu state becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | State files often expose secrets and sensitive NHI metadata. |
| NIST CSF 2.0 | PR.AC-4 | State access should follow least-privilege and strong access governance. |
| NIST Zero Trust (SP 800-207) | SC-7 | Remote state backends need explicit trust boundaries and access verification. |
| NIST SP 800-63 | AAL2 | Strong authentication is needed for systems that can read or modify state. |
| NIST AI RMF | State integrity supports reliable AI and automation governance. |
Store state in secured backends and remove secret-bearing values from tracked outputs.
Related resources from NHI Mgmt Group
- How should teams keep OpenTofu secrets out of state files?
- Why do OpenTofu workflows create secrets risk even when state is encrypted?
- Who is accountable when an AI agent exposes credentials or changes identity state?
- How should security teams implement state, nonce, and PKCE together in OIDC flows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
