Why do encrypted secrets still create risk in cloud automation?

Because encryption protects storage, not entitlement. If a Terraform role, Kubernetes controller, or CI pipeline can decrypt broadly, the secret is still operationally available to any process that inherits that access. Risk falls only when decryption rights, retrieval rights, and secret lifetime are all tightly scoped.

Why This Matters for Security Teams

Encrypted secrets still matter because cloud automation rarely stops at storage. Terraform runners, Kubernetes controllers, and CI jobs need to retrieve, decrypt, and pass credentials into other services, which means the real risk sits in entitlement and execution paths, not in the ciphertext itself. When those paths are broad, any process that inherits the role can become an access point, even if the secret is “secure at rest.”

This is why NHIMG research on the Guide to the Secret Sprawl Challenge and the 2024 Non-Human Identity Security Report keeps pointing to the same operational gap: organisations often improve storage protections faster than they improve access scoping, rotation, and revocation. That gap is also reflected in the OWASP Non-Human Identity Top 10, which treats over-permissioned machine access as a core control failure, not an encryption failure. In practice, many security teams encounter secret exposure only after a pipeline, controller, or workload has already reused the credential in ways nobody intended.

How It Works in Practice

In cloud automation, encryption protects the secret while it is stored, replicated, or backed up, but the automation runtime still needs authority to unlock it. That authority is usually granted through IAM roles, workload service accounts, KMS permissions, or vault tokens. If the decryption scope is too wide, the secret is available to far more code paths than the security team expects.

A better control model is to treat secret access as a just-in-time entitlement problem. The automation identity should prove who or what it is, request only the secret needed for the current task, receive a short-lived credential, and have that access automatically expire when the job ends. This aligns with the emerging guidance in NIST Cybersecurity Framework 2.0 and with NHIMG’s reporting on dynamic access patterns in the 2024 Non-Human Identity Security Report.

• Scope decryption to the exact workload, not to the whole pipeline or cluster.
• Issue ephemeral secrets or tokens per task instead of reusing long-lived static values.
• Bind retrieval rights to workload identity, not just to a network location or shared role.
• Revoke access automatically when the job, pod, or deployment step completes.
• Log every decrypt and retrieval event as a distinct entitlement decision.

NHIMG case material on the CI/CD pipeline exploitation case study shows why this matters: once a pipeline token can decrypt broadly, it can usually pivot into artifact stores, package registries, or downstream infrastructure. These controls tend to break down when shared runners, cluster-wide service accounts, or legacy secrets managers are forced to support many teams because the decryption boundary becomes too coarse to enforce least privilege.

Common Variations and Edge Cases

Tighter decryption scoping often increases operational overhead, so organisations have to balance usability against blast-radius reduction. That tradeoff is most visible in multi-cloud estates, legacy automation, and hybrid environments where different teams still expect one secret to serve many jobs. Current guidance suggests that this is where static secrets cause the most residual risk, but there is no universal standard for how fast every environment should move to fully ephemeral models.

Some environments need temporary exceptions. Disaster recovery tooling, air-gapped systems, and vendor-managed integrations may still require longer-lived credentials, but those exceptions should be explicit, reviewed, and time-bounded. The Aembit research found that 59.8% of organisations see value in dynamic ephemeral credentials, which reflects the direction of travel even where maturity is uneven. For broader context on the pattern of exposure, NHIMG’s 52 NHI Breaches Analysis and Shai Hulud npm malware campaign both show how quickly a single exposed secret can turn into broader compromise when automation trust is assumed instead of continuously verified.

The practical test is simple: if a secret can be decrypted by a role that is reused across many workflows, the organisation has reduced storage risk but not entitlement risk.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• Why do static roles create risk in cloud and hybrid environments?
• When does shift left create more risk than it reduces?
• How should teams reduce the risk from exposed NHI secrets?