A credential stored and handled through a controlled process rather than embedded in code or exposed to developers broadly. In this pattern, API keys and client IDs still need protection because they can be used to request tokens or interact with the broker on behalf of the application.
Expanded Definition
A managed secret is a credential that is stored, retrieved, rotated, and revoked through a controlled process instead of being embedded in source code or handed out informally. In NHI environments, this usually applies to API keys, client IDs, client secrets, certificates, and tokens that support machine-to-machine access.
The key distinction is governance: the secret is not merely “stored somewhere,” it is bound to an operating model with access controls, lifecycle ownership, rotation expectations, and auditability. That makes it different from general secret storage and from broader identity concepts such as service accounts. Industry usage still varies, so some teams treat managed secret as a platform pattern while others treat it as a security control outcome. For a practical baseline, the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both reinforce that credentials must be protected, monitored, and recoverable throughout their lifecycle.
The most common misapplication is calling a secret “managed” when it is only copied into CI/CD variables or config files without enforced rotation, ownership, or revocation when the workload changes.
Examples and Use Cases
Implementing managed secrets rigorously often introduces operational friction, requiring organisations to weigh faster developer access against tighter control, more approvals, and more frequent rotation.
- A deployment pipeline retrieves a short-lived API token from a secrets manager at runtime instead of storing it in a repository, reducing exposure during code review and cloning.
- A service account certificate is rotated automatically on a schedule, with renewal tied to the application lifecycle so expired credentials do not break production.
- A production client secret is scoped to one application and one environment, then revoked immediately after a migration or incident response event.
- Security teams review secrets sprawl across build tools, containers, and ticket attachments, using Guide to the Secret Sprawl Challenge to identify uncontrolled storage locations.
- Engineering teams align secret handling with the control expectations in the OWASP Non-Human Identity Top 10 and with lifecycle guidance from the NHI Lifecycle Management Guide.
In practice, managed secrets are most valuable where workloads must authenticate repeatedly, where credentials change often, or where broad distribution would make incident response slow and unreliable.
Why It Matters in NHI Security
Managed secrets are central to NHI security because they are often the practical gatekeepers for service accounts, automation, and agentic workloads. When they are mismanaged, attackers do not need to defeat a sophisticated identity system, they only need to find a leaked token, extract a hardcoded secret, or abuse a forgotten credential that still has standing access.
This matters at scale because NHI risk is usually invisible until compromise. NHI Mgmt Group reports that Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That pattern turns ordinary deployment convenience into a durable breach path. Good secret management also supports Zero Trust expectations by making authentication revocable, observable, and time-bounded instead of permanent. This is why controls around inventory, rotation, and offboarding matter as much as encryption.
Organisations typically encounter the cost of poor secret handling only after a secrets leak, at which point managed secret practices become operationally unavoidable to contain reuse and restore trust.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Managed secrets are central to this control’s guidance on secret storage and exposure reduction. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and credential management underpin secure machine authentication workflows. |
| NIST CSF 2.0 | PR.AC-1 | Least-privilege access applies to who can retrieve, use, and rotate managed secrets. |
Govern service credentials so every workload secret has ownership, scope, and traceable lifecycle actions.
