A credential, token, API key, or certificate that still authorises real access when discovered. In NHI governance, a live secret matters more than its origin because it can still move data, change code, or invoke services until it is revoked everywhere it exists.
Expanded Definition
A live secret is not defined by where it came from, but by whether it still authorises real access at the moment it is found. In NHI operations, that means an API key, token, certificate, or service credential can remain live across code, CI/CD, configuration, vaults, and downstream replicas long after the owner assumes it is inert. This is why NHI Management Group treats live secret status as an operational condition, not a static label.
Industry usage is still evolving, but the practical distinction is clear: a secret can be exposed without being immediately exploitable, while a live secret can still call services, alter data, or mint new access. That makes it central to credential hygiene, incident response, and offboarding workflows. The concept aligns with guidance in the OWASP Non-Human Identity Top 10, especially where secret handling and revocation fail to keep pace with machine access sprawl.
The most common misapplication is treating “exposed” and “revoked” as the same state, which occurs when teams rotate the primary copy but leave valid replicas in code, pipelines, or integrations.
Examples and Use Cases
Implementing live-secret controls rigorously often introduces operational friction, requiring organisations to weigh fast automation against the risk of breaking active workloads.
- A GitHub token committed to a repository is discovered, but it remains live because it still has repository write permissions and has not been revoked in the source app.
- A certificate used by a service mesh is copied into multiple pods; one instance is rotated, but another still authenticates successfully until all trust stores are updated.
- An API key stored in a CI/CD variable is found during a scan, yet it continues to deploy code because the pipeline never revalidated the credential after exposure.
- A cloud access token appears in an incident report, but the token is still live in a third-party integration, so the blast radius extends beyond the original system.
These scenarios are frequently discussed in NHI incidents such as the Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack, where discovery alone did not eliminate access. Standards work such as the OWASP Non-Human Identity Top 10 helps teams frame the lifecycle questions: is the secret still valid, where else is it replicated, and what can it still do right now?
Why It Matters in NHI Security
Live secrets are dangerous because compromise becomes actionable immediately. A leaked credential that remains valid can move laterally, exfiltrate data, trigger workloads, or modify infrastructure before defenders finish tracing its spread. That is why secret visibility, revocation speed, and replica discovery are governance issues, not just hygiene tasks. NHI Mgmt Group reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly many environments actually neutralise exposure. The practical lesson is that discovery without invalidation leaves the attacker’s path open.
Live-secret risk also interacts with broader NHI sprawl. NHI Mgmt Group has found that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That pattern means one exposed secret can persist through many copies, backups, and automation layers. The operational answer is to pair detection with immediate revocation, propagation checks, and verification across every system that could still trust the credential.
Organisations typically encounter the true impact only after an incident shows that a “found” secret was still usable, at which point live secret status 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Live secrets are a core NHI secret-handling risk because validity and revocation determine exploitable access. |
| NIST CSF 2.0 | PR.AA-05 | Credential lifecycle and revocation map to authentication assurance and access maintenance practices. |
| NIST Zero Trust (SP 800-207) | Section 2.3 | Zero Trust requires continuous verification, which includes invalidating compromised machine credentials. |
| NIST SP 800-63 | AAL2 | Authenticator strength and lifecycle expectations inform how long a machine credential should remain trusted. |
| OWASP Agentic AI Top 10 | A4 | Agentic systems amplify harm when a live secret grants tool access after compromise or leakage. |
Set assurance and reauthentication requirements that force timely rotation and revocation of machine secrets.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
