Should production secrets live in environment variables or a secrets manager?

Why This Matters for Security Teams

Environment variables are convenient for application configuration, but convenience is not a control. If a production secret sits only in an environment variable, it can be exposed through process dumps, debug output, misconfigured build logs, inherited shell sessions, or overly broad access to runtime hosts. A secrets manager changes the security model by centralising access, supporting rotation, and preserving auditability. That matters because secret sprawl is already a measurable failure mode: GitGuardian reported 62% of all secrets are duplicated and stored in multiple locations in The State of Secrets Sprawl 2026.

The operational issue is not whether env vars can work, but whether they can be the only place a production secret lives. For modern NHI programs, current guidance suggests treating env vars as ephemeral delivery plumbing, while the source of truth remains in a secrets manager. That aligns with the broader lifecycle view in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the secret handling patterns in Ultimate Guide to NHIs — Static vs Dynamic Secrets. In practice, many security teams discover secret leakage only after a deployment artifact, ticket, or runtime host has already been exposed.

How It Works in Practice

The usual pattern is to keep the secret in a managed vault, then inject it into the workload at runtime for the shortest period practical. That can mean a sidecar, init container, agent, or workload identity flow that fetches a token only when the service starts. The key distinction is that the environment variable becomes a transport mechanism, not the durable storage layer. This matches the identity and lifecycle approach described in Guide to the Secret Sprawl Challenge, where duplication and uncontrolled distribution are treated as root causes rather than symptoms.

In practice, teams should combine the vault with workload identity, RBAC, and short TTLs. NIST’s NIST Cybersecurity Framework 2.0 emphasises access control, monitoring, and recovery, all of which improve when a leaked secret can be revoked centrally without redeploying every consumer. The OWASP Non-Human Identity Top 10 also reinforces that machine credentials need stronger lifecycle management than static application config. A practical baseline is: store once, fetch just in time, scope narrowly, rotate automatically, and log every access.

• Use a secrets manager as the source of truth, not a mirrored copy.
• Inject credentials only at runtime and keep TTLs short enough to limit blast radius.
• Prefer workload identity over long-lived shared secrets where the platform supports it.
• Separate read access for operators from retrieval rights for workloads.
• Trigger rotation and revocation on offboarding, compromise, or policy change.

These controls tend to break down when legacy applications require static startup configuration because the app cannot re-fetch or refresh secrets without code change.

Common Variations and Edge Cases

Tighter secret handling often increases operational overhead, so organisations must balance stronger containment against delivery complexity. Not every environment can move to full dynamic issuance immediately, and there is no universal standard for this yet in older application stacks. The common compromise is to use env vars only as a temporary injection path, while keeping the secret’s lifecycle in the manager and limiting the runtime’s exposure window.

Edge cases appear in batch jobs, air-gapped systems, and poorly containerised legacy services. Those systems may still need bootstrap credentials, but those credentials should be narrowly scoped, time-bound, and replaced as soon as a stronger pattern is available. The entitlement model should also reflect non-human identity reality: if one secret is reused across multiple apps, the blast radius grows quickly, a pattern highlighted in The 2025 State of NHIs and Secrets in Cybersecurity and the incident patterns covered in Reviewdog GitHub Action supply chain attack. The practical rule is simple: if an environment variable is the only surviving copy of a production secret, the organisation has already accepted avoidable risk.

Related resources from NHI Mgmt Group

• How should security teams protect HMAC secrets in production systems?
• Why do secrets create disproportionate risk in NHI environments?
• How should teams reduce the risk from exposed NHI secrets?
• How does OneDrive auto-sync create secrets exposure in SharePoint?