What is the difference between storing secrets in Terraform state and using an external secrets manager?

Why This Matters for Security Teams

Secrets in terraform state are not just a tooling preference issue. They change the blast radius of a compromise, because state files often become a shared dependency across CI/CD, operators, and automation. When sensitive values are written into state, any user or system with access to that backend may inherit exposure that was never intended for credential material. That is why NIST Cybersecurity Framework 2.0 is a useful lens: governance, access control, and protection of sensitive data must be designed into the workflow, not added after the fact.

The practical difference is also about lifecycle control. A secrets manager is built to issue, rotate, revoke, and audit secrets. Terraform state is built to reconcile desired infrastructure with actual infrastructure. When teams blur those roles, they often end up with credentials that are hard to rotate, hard to scope, and easy to replicate across environments. In practice, many security teams encounter secret sprawl only after a state backend is copied into a lower-trust environment or exposed through a misconfigured pipeline, rather than through intentional design.

How It Works in Practice

Terraform should treat secrets as dependencies, not as long-lived records of truth. In a well-structured workflow, Terraform provisions the resource, retrieves only what it needs to bind configuration, and stores at most a reference, identifier, or limited metadata in state. The actual secret lives in an external secrets manager that enforces access policy, rotation cadence, logging, and revocation. That separation supports both infrastructure automation and identity governance, including non-human identities that consume those secrets at runtime.

Operationally, teams usually implement this pattern in one of three ways:

• Terraform reads a secret at plan or apply time, but the secret is never output to logs or stored as a durable output.
• Terraform writes a pointer such as a secret ARN, version ID, or path, while an application or agent fetches the secret later at runtime.
• Terraform provisions the secret container or policy, while another workflow manages the secret value itself and its rotation.

This is where OWASP Non-Human Identity Top 10 becomes relevant: service accounts, pipelines, and agents that retrieve secrets are identities too, and they need least privilege and traceable authorization. If those identities are overly broad, the advantage of an external secrets manager is weakened because the retrieval path becomes the new weak point.

State protection still matters. Even when secrets are excluded from state, the backend should be encrypted, access should be tightly segmented, and remote state access should be audited. NIST SP 800-53 Rev 5 Security and Privacy Controls is helpful here because it maps the problem to access enforcement, auditability, and information protection rather than to Terraform alone. These controls tend to break down in shared build environments with broad pipeline privileges and long-lived backend credentials because the same automation account can read both state and secret sources.

Common Variations and Edge Cases

Tighter secret handling often increases workflow complexity, requiring organisations to balance deployment speed against stronger control over credential exposure. That tradeoff is real, especially when teams want deterministic infrastructure plans and repeatable applies without introducing brittle runtime lookups. Current guidance suggests that not every value fetched during infrastructure provisioning should be treated the same way, but there is no universal standard for this yet.

One edge case is bootstrap credentials. Some platforms need an initial secret to establish trust, seed a connection, or create the first managed identity. In those cases, the secret may exist briefly in state or pipeline memory, but best practice is evolving toward minimizing persistence and replacing the bootstrap with a managed identity as soon as possible. Another edge case is legacy tooling that cannot separate secret references from secret values cleanly. In those environments, compensating controls such as stricter backend isolation, short-lived credentials, and stronger approval gates become more important than ideal architecture.

The identity angle matters most when automation tools, agents, or ephemeral CI workers retrieve secrets on behalf of workloads. If the retrieval identity is not scoped to a narrow path, the external secrets manager can become another high-value target instead of a risk reducer. The distinction is simple in theory, but real programs fail when state backends, secret stores, and deployment identities are managed by different teams without a shared control model.

Related resources from NHI Mgmt Group

• What is the difference between keeping secrets in Sealed Secrets and using an external secrets manager with GitOps?
• What is the difference between storing secrets in docker-compose files and injecting them at runtime from a secrets manager?
• What is the difference between runtime protection and NHI lifecycle management?
• What is the difference between rotating a secret and revoking access?