Secrets Management

Expanded Definition

Secrets management is the operational discipline of controlling credentials, tokens, API keys, certificates, and other sensitive material across build systems, applications, infrastructure, and AI-connected services. In NHI security, it sits between identity lifecycle governance and runtime access enforcement, because a secret is often the practical proof that a machine identity is trusted. The term is used broadly, but definitions vary across vendors: some products emphasise vaulting, others focus on rotation, discovery, or policy enforcement. For NHI programs, the most useful definition includes storage, distribution, rotation, revocation, and auditability, not just encryption at rest. That aligns with the intent of the NIST Cybersecurity Framework 2.0, which stresses governance, protection, and recovery across the asset lifecycle, and with the OWASP Non-Human Identity Top 10, where secret exposure is a recurring root cause of NHI compromise.

The most common misapplication is treating secrets management as a vault deployment, which occurs when teams centralise storage but leave hardcoded secrets, weak rotation, and broad access paths untouched.

Examples and Use Cases

Implementing secrets management rigorously often introduces integration and rotation overhead, requiring organisations to weigh developer convenience against tighter control and shorter credential lifetimes.

• Application pipelines pull ephemeral database credentials from a central vault at deploy time, reducing the need for long-lived static secrets in code repositories. This pattern is especially relevant where Ultimate Guide to NHIs — Static vs Dynamic Secrets is the design reference.
• CI/CD systems inject short-lived tokens only for the duration of a job, then revoke them automatically. That aligns with the lifecycle thinking described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, especially where automation accounts need tightly bounded authority.
• Security teams scan repositories and build logs for exposed credentials after incidents such as the Reviewdog GitHub Action supply chain attack, then rotate affected secrets and invalidate related sessions.
• Cloud service accounts are provisioned with unique secrets per environment, rather than reusing the same token across dev, test, and production. That reduces blast radius when a single environment is compromised.
• Operational teams use policy-based access to separate human administrators from NHI workloads, mirroring the segmentation practices discussed in Guide to the Secret Sprawl Challenge.

Why It Matters in NHI Security

Secrets management is one of the fastest ways to convert abstract NHI risk into measurable control failure. When secrets are duplicated across repositories, pipelines, and endpoints, an attacker does not need to defeat the identity system itself; they only need one valid secret to impersonate a workload, access data, or move laterally. NHIMG research in The 2024 State of Secrets Management Survey found that 88% of security professionals are concerned about secrets sprawl, which reflects how common this exposure has become in practice. That concern is reinforced by public incidents such as the 230M AWS environment compromise and the Shai Hulud npm malware campaign, where exposed secrets amplified the scope of compromise.

For NHI programs, the core issue is not just concealment but governance: who can mint secrets, where they live, how quickly they expire, and whether compromise can be detected before reuse. Organisations typically encounter the real cost only after a leaked token is abused in production, at which point secrets management becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is NHI posture management?
• How does NHI lifecycle management differ from human identity lifecycle management?
• What is secrets sprawl and why does it create security risk?
• What is a secrets vault and which tools are available?