A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
Expanded Definition
A secret manager is a control plane for storing credentials, retrieving them at runtime, and sometimes rotating them on a schedule. In NHI operations, it is a delivery mechanism, not a full governance model: it can reduce hard-coded secrets and centralise access, but it does not automatically define ownership, entitlement context, break-glass rules, or revocation accountability. That distinction matters because a vault can be technically sound while the underlying identity remains overprivileged, orphaned, or shared across systems. NHI Management Group treats secret management as one layer in a broader lifecycle that also includes inventory, offboarding, and continuous review, as outlined in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. Industry usage is still evolving, and definitions vary across vendors that bundle vaulting, rotation, and policy enforcement into one product label. The most common misapplication is treating a secret manager as proof of governance, which occurs when teams assume secure storage alone resolves access risk.
Examples and Use Cases
Implementing secret management rigorously often introduces operational friction, requiring organisations to weigh reduced exposure against rotation complexity, application refactoring, and service downtime risk.
- A CI/CD pipeline pulls short-lived deploy tokens at build time instead of embedding them in code, reducing the blast radius if a repository is exposed. Cases like the CI/CD pipeline exploitation case study show why pipeline credentials need strict handling.
- An application retrieves database credentials from a vault and rotates them automatically, but the team still must verify who can request the secret and under what role.
- An operations group centralises API keys in a vault after a leak, then uses the NIST Cybersecurity Framework 2.0 to map access control, recovery, and monitoring responsibilities.
- A security team reviews secret sprawl across code, config files, and build tooling using the Guide to the Secret Sprawl Challenge, then removes legacy secrets that were never onboarded into the manager.
- A platform team uses a secret manager for certificates, but still applies policy checks from the OWASP Non-Human Identity Top 10 to reduce overexposure of service identities.
Why It Matters in NHI Security
Secret managers are often introduced after a breach or audit finding, when organisations realise that credentials have been scattered across code, CI/CD tools, and admin consoles. That is not a minor hygiene issue: the underlying exposure is frequently systemic. NHI Management Group reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows that storage controls alone do not guarantee timely remediation. Secret management matters because it supports rotation, auditability, and separation of duties, but it only becomes effective when paired with entitlement review, lifecycle ownership, and fast revocation. The Top 10 NHI Issues and the NHI Lifecycle Management Guide both reinforce that governance gaps usually begin before the vault is even involved. Organistically, organisations typically encounter the true cost of secret management only after a leak, expired token failure, or service abuse, at which point secret manager governance becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses improper secret handling and exposure across non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Secret managers support access control by limiting who can retrieve credentials. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification beyond merely storing secrets securely. |
Inventory secrets, restrict access, and enforce rotation and removal for every NHI credential.
