They confuse encryption with governance. Encrypting a secret in state is useful, but it does not provide per-secret access control, temporary access, or lifecycle enforcement. Teams still need policy, rotation, and audit controls outside the IaC tool.
Why This Matters for Security Teams
Teams usually overestimate what encryption inside infrastructure code actually delivers. It protects a value at rest, but it does not create governance around who can use the secret, when it should be available, or whether it should still exist. That gap matters because secrets become operational authority the moment they are decrypted, and infrastructure pipelines are exactly where authority is easiest to overextend.
NHIMG’s Guide to the Secret Sprawl Challenge shows why this problem is persistent: secrets rarely fail only because they are stored badly, they fail because they spread across repositories, build systems, and deployment paths faster than teams can govern them. The same pattern appears in supply chain incidents such as the Reviewdog GitHub Action supply chain attack, where the issue was not merely exposure but the operational blast radius created when secrets were reachable in the wrong place.
Practitioners also need to distinguish between encrypted storage and secret lifecycle control. The OWASP Non-Human Identity Top 10 treats secret handling as an identity problem, not just a storage problem, because a secret is a bearer capability once retrieved. In practice, many security teams discover that their “encrypted” secrets were still effectively long-lived, broadly retrievable, and audit-poor only after a pipeline compromise or repo leak has already expanded access.
How It Works in Practice
The practical fix is to treat encrypted secrets in IaC as one control layer, not the control plane. A stronger design separates storage, retrieval, authorization, and audit. The infrastructure code may reference a secret placeholder, but the actual secret should be issued, scoped, and revoked by an external secrets authority or workload identity system. That aligns with current guidance from the OWASP Non-Human Identity Top 10, which frames non-human access as something that must be governed continuously, not merely encrypted at rest.
In mature setups, teams commonly use:
- Short-lived credentials instead of static secrets embedded in state or variables.
- Per-workload identity so a deployment job proves what it is before receiving access.
- Policy checks at retrieval time, not only at commit time.
- Rotation and revocation that are independent of the IaC tool.
This is where Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful: dynamic secrets reduce the window of misuse because the secret is valid only for a narrow task and a narrow duration. That is especially important in CI/CD, where a compromised runner can reuse a static value far longer than the original change window. Secrets management platforms should therefore enforce TTL, audience restrictions, and automatic revocation, while the IaC layer only declares desired access patterns.
For teams formalising this, the better operational model is policy-as-code plus runtime enforcement. A change request might be valid in one environment but denied in another, depending on tool, actor, branch, cluster, or approval state. In other words, encryption makes disclosure harder, but governance determines whether the secret should have been usable in the first place. These controls tend to break down when the same encrypted secret is copied into multiple pipelines, because no single system can then enforce consistent issuance and revocation.
Common Variations and Edge Cases
Tighter secret handling often increases deployment overhead, requiring organisations to balance fast automation against stronger lifecycle control. That tradeoff becomes visible in edge cases where teams want the convenience of encrypted IaC state but also need emergency access, cross-account deployments, or shared service credentials. There is no universal standard for every workflow yet, so guidance remains to minimise standing access and prefer time-bound retrieval wherever possible.
One common exception is legacy tooling that cannot consume ephemeral credentials directly. In those environments, encrypted secrets may still be used as a transitional control, but they should be paired with compensating measures such as rapid rotation, scoped retrieval roles, and strong audit logging. Another edge case is multi-team platform engineering, where a single secret serves many services. That pattern often looks efficient until a single compromise creates a shared blast radius. The NHIMG 52 NHI Breaches Analysis is a useful reminder that this kind of concentration is a recurring failure mode, not an isolated mistake.
The emerging consensus is clear even if the tooling varies: encryption is a storage safeguard, not an access model. Teams should assume any secret reachable by automation can be abused by automation, and design so retrieval is conditional, logged, and short-lived. That matters most in environments with fast scaling, shared runners, and infrastructure code that is reused across many accounts or tenants.
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 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-01 | Encrypted secrets still need lifecycle and access governance. |
| NIST CSF 2.0 | PR.AC-1 | Access control must govern who can retrieve decrypted secrets. |
| NIST AI RMF | GOVERN | Secret handling in automation needs accountable governance decisions. |
Map secret retrieval to access policies, not just encrypted storage, and review entitlements regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
