A dormant integration credential is an authentication secret that still works even though the related system, prototype, or use case is no longer active. These credentials are dangerous because they are often forgotten, poorly monitored, and still able to unlock connected SaaS platforms or internal services through trusted relationships.
Expanded Definition
A dormant integration credential is not simply an old secret. It is a live authentication artifact tied to an integration that has been retired, paused, replaced, or forgotten, yet it still authorises access to SaaS platforms, APIs, databases, or internal services. In NHI operations, the risk comes from the credential’s residual trust: the system may be inactive, but the secret can still succeed because no one revoked it, rotated it, or removed its downstream permissions.
Definitions vary across vendors on whether a dormant credential must be completely unused or merely associated with an inactive workload, but the security meaning is consistent: if the secret can still authenticate, it remains an attack path. This aligns with the broader NHI guidance in the OWASP Non-Human Identity Top 10, where lifecycle control and secret governance are central concerns. It also fits the NIST view in NIST SP 800-63 Digital Identity Guidelines, which treats authenticators as security assets that must be bound to current, intentional use.
The most common misapplication is assuming that decommissioning the application automatically invalidates its credential, which occurs when teams retire a service without revoking the associated secret or cleaning up trust relationships.
Examples and Use Cases
Enforcing dormant-credential hygiene often adds operational overhead because teams must track credential state across code, pipelines, and downstream platforms, but that cost is usually lower than the blast radius of an overlooked secret.
- A proof-of-concept API key created for a pilot remains valid months after the pilot ends, allowing access to production-adjacent data stores.
- A CI/CD service account used for an abandoned deployment path still has permission to publish artifacts, creating a hidden supply chain entry point. This pattern is consistent with incidents discussed in the Reviewdog GitHub Action supply chain attack and the CI/CD pipeline exploitation case study.
- An integration token for a legacy SaaS connector is left in a secrets manager after the connector is replaced, so the old token can still query customer records.
- A test environment credential is copied into a shared message thread and never revoked, echoing the insecure sharing patterns highlighted in the Guide to the Secret Sprawl Challenge.
- A machine-to-machine certificate issued for a short-lived internal migration remains trusted by a backend service long after the migration is complete.
For teams designing lifecycle controls, the practical lesson from the Ultimate Guide to NHIs — Static vs Dynamic Secrets is that static credentials are hardest to retire safely unless ownership, expiry, and revocation are tracked from issuance to deletion.
Why It Matters in NHI Security
Dormant integration credentials are dangerous because they create “ghost access” that bypasses normal change management. Attackers do not need to break authentication if a forgotten secret still works. Once discovered, these credentials can be used to pivot into cloud services, internal APIs, or data pipelines that were assumed to be out of scope. In practice, this undermines least privilege, breaks asset inventory accuracy, and weakens the trust boundaries that NHI programs depend on.
NHIMG research shows that only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities, while 88.5% say their non-human IAM practices lag behind or merely match their human IAM efforts. That gap matters because dormant credentials are usually found only during incident response, audits, or access reviews, not during ordinary operations. The issue becomes sharper in environments with hybrid systems, shared secrets, and long-lived automation. A dormant credential that still works can also complicate compliance evidence because no one can prove when access truly ended.
Organisations typically encounter the impact only after an unexpected access event or breach review, at which point dormant integration credential 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 SP 800-63, 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 | Dormant credentials are a direct secret lifecycle and sprawl risk. |
| NIST SP 800-63 | Authenticators must be managed so only current, intended use remains valid. | |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance requires current authorization, not stale trust. |
| NIST Zero Trust (SP 800-207) | SP 5 | Zero trust requires continuous validation of every credential and session. |
Continuously verify that machine identities still need access and can be revoked quickly.
Related resources from NHI Mgmt Group
- When should organisations revoke a SaaS integration credential?
- What is the difference between rotating an API key and revoking an integration credential?
- What breaks when a SaaS integration credential is left active after a project ends?
- What breaks when organisations rely on a third-party integration layer without continuous credential lifecycle management?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
