A standing secret is a long-lived credential that remains valid until it is manually replaced or revoked. In practice, it expands attack exposure because the secret can outlive the service change process, especially when ownership and usage tracking are incomplete.
Expanded Definition
A standing secret is a credential that persists beyond the moment it was needed, so it continues to authenticate long after the business event, deployment, or ownership change that introduced it. In NHI operations, that usually means API keys, tokens, certificates, or service credentials remain live because no automated expiry, rotation, or offboarding workflow is attached to them.
Definitions vary across vendors, but the operational distinction is straightforward: a standing secret is not just “stored” somewhere, it is still valid and usable. That makes it different from dormant inventory records or vaulted material that cannot authenticate without a release process. In Zero Trust Architecture, long-lived credentials work against the goal of limiting standing access; this is why guidance around OWASP Non-Human Identity Top 10 treats secret lifecycle discipline as a core control area rather than a housekeeping task.
The most common misapplication is calling any stored credential “standing” even when it is short-lived or automatically rotated, which occurs when teams ignore expiry semantics and only inspect the storage location.
Examples and Use Cases
Implementing standing-secret controls rigorously often introduces lifecycle friction, requiring organisations to weigh deployment speed against the operational cost of rotation, revocation, and dependency updates.
- A CI/CD system injects a deployment key into build jobs, but the key never expires and survives after the pipeline changes. The CI/CD pipeline exploitation case study shows how that pattern turns a convenience credential into a durable entry point.
- A developer leaves a service account key in a repository variable after the application is retired. That is the same secret-sprawl pattern described in the Guide to the Secret Sprawl Challenge, where ownership gaps keep old credentials alive.
- An AI agent is granted tool access through a long-lived token so it can call APIs unattended. In practice, that token should be treated as an NHI credential with explicit expiry, consistent with Ultimate Guide to NHIs — Static vs Dynamic Secrets and the lifecycle expectations in OWASP guidance.
- A third-party integration keeps using an API key after the vendor relationship changes. This is a typical offboarding failure, especially when the key is hard-coded into scripts or stored outside a secrets manager.
Standing secrets matter most in environments where service ownership is shared, rotations are manual, and dependency maps are incomplete. In those cases, the credential remains valid because nobody is sure which system will fail if it is removed.
Why It Matters in NHI Security
Standing secrets are dangerous because they convert temporary access into indefinite access. That extends the window for misuse, makes compromise harder to contain, and undermines least privilege when teams cannot confidently prove who still needs the secret. The risk is especially sharp for secrets embedded in code, CI/CD tooling, and third-party workflows, where revocation often requires coordinated change across multiple systems. NHI Management Group research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which is a strong signal that remediation processes lag behind detection.
That gap explains why standing secrets are central to governance, not just technical hygiene. They intersect with Secrets management, PAM, RBAC, and JIT access because the control objective is to make access intentional, bounded, and traceable. They also fit directly into zero standing privilege programs: if a service does not need ongoing access, its secret should not remain continuously usable. In incidents such as the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, long-lived credentials became the thing attackers could rely on after initial compromise.
Organisations typically encounter the consequences only after a breach review or emergency rotation exercise, at which point standing secret cleanup 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 Zero Trust (SP 800-207) 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 | Standing secrets fall under improper secret lifecycle and exposure controls. |
| NIST Zero Trust (SP 800-207) | Zero Trust rejects indefinite access and favors continuous verification over standing credentials. | |
| NIST CSF 2.0 | PR.AC-1 | Persistent credentials undermine least-privilege and access control governance. |
Inventory every long-lived secret, rotate it, and remove any credential not tied to current need.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
