Why do encrypted secrets still create risk in development workflows?

Encrypted secrets still create risk because developers and automation often copy, store, or retrieve them across many systems. If those retrieval paths are broad, poorly reviewed, or fragmented across tools, the secret can be exposed through misuse, leakage, or stale access even when the underlying data is encrypted.

Why This Matters for Security Teams

Encrypted secrets are often treated as safe once they are stored in a vault or protected by transport encryption, but the real risk sits around the secret, not inside it. Development workflows routinely copy tokens into CI jobs, shell histories, build logs, ticketing systems, and local caches. The result is broad retrieval paths, inconsistent approvals, and stale access that outlives the original task.

This is why NHI governance has become a practical control issue rather than an abstract hygiene issue. The OWASP Non-Human Identity Top 10 and NHIMG research on Guide to the Secret Sprawl Challenge both point to the same pattern: secrets become risky when they are duplicated, over-shared, and left available longer than the workflow requires. In practice, many security teams encounter exposure only after a token has already been copied into too many systems to contain cleanly.

How It Works in Practice

Security teams reduce encrypted-secret risk by controlling who can retrieve the secret, when, from where, and for what purpose. Encryption protects the stored value, but it does not automatically restrict retrieval, logging, reuse, or delegation. That is why current guidance increasingly favors short-lived access, workload identity, and tightly scoped secret delivery over long-lived shared credentials.

A practical workflow usually combines vault controls, CI/CD policy, and identity-based delivery:

• Use workload identity for machines and pipelines instead of embedding reusable static credentials.
• Issue secrets just in time, with short TTLs and automatic revocation after the task completes.
• Limit retrieval paths to approved runtimes, repositories, and deployment contexts.
• Prevent secrets from appearing in logs, chat tools, tickets, and code comments.
• Rotate or invalidate secrets when a pipeline, branch, or service account changes ownership.

The NIST Cybersecurity Framework 2.0 supports this broader view of access and monitoring, while NHIMG reporting in the 2025 State of NHIs and Secrets in Cybersecurity shows how often secrets are duplicated and exposed across collaboration systems and code workflows. The operational lesson is simple: encryption is necessary, but it is not a substitute for lifecycle control, context-aware access, and cleanup discipline. These controls tend to break down in fast-moving DevOps environments because developers reuse the same secret across multiple pipelines and environments, creating hidden dependencies that are hard to unwind safely.

Common Variations and Edge Cases

Tighter secret controls often increase delivery friction, so teams must balance developer velocity against exposure reduction. That tradeoff is especially visible when local development, ephemeral preview environments, and third-party integrations all need temporary access without creating permanent standing privilege.

Best practice is evolving, but a few patterns are consistently safer. Dynamic secrets are usually preferable for production workloads, while encrypted static secrets may still be acceptable for low-risk local tooling if the retrieval path is tightly governed. Secrets stored in a vault are also not automatically safe if every engineer, build agent, or app service can fetch them broadly. The issue is distribution, not just storage.

Edge cases include break-glass access, legacy applications that cannot consume workload identity, and vendor-managed automation with limited transparency. In those cases, security teams should narrow scope aggressively, add monitoring, and document exceptions with expiry dates. The Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly exposed secrets can be harvested once they enter build and repository ecosystems. There is no universal standard for this yet, but the direction is clear: reduce secret lifetime, reduce secret reuse, and reduce the number of places a secret can be retrieved.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• Why do encrypted secrets still create risk in cloud automation?
• Why do OpenTofu workflows create secrets risk even when state is encrypted?
• Why do encrypted playbooks still create secrets risk?