Dormant vendor access is unused or no longer needed access that remains active after a relationship, integration, or workflow has changed. It is a common governance gap in SaaS ecosystems because standing permissions can linger even when the operational need has ended, creating avoidable exposure and audit risk.
Expanded Definition
Dormant vendor access describes third-party credentials, tokens, API keys, or privileged roles that remain active after the vendor no longer needs them. In NHI governance, the term is broader than simple offboarding because it also covers integrations that were re-scoped, paused, migrated, or silently replaced by a new workflow.
Definitions vary across vendors, but the operational concern is consistent: standing access continues even when business intent has changed. That makes dormant vendor access a lifecycle failure, not just an inventory issue. It overlaps with third-party access management, secrets hygiene, and privileged access review, but it is distinct because the access may still be technically valid while being functionally unnecessary. Guidance in the OWASP Non-Human Identity Top 10 and control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce that access must be continuously revalidated, not merely issued once.
The most common misapplication is treating dormant vendor access as harmless because the vendor has not used it recently, which occurs when teams confuse inactivity with revocation and skip entitlement review after workflow changes.
Examples and Use Cases
Implementing dormant-access controls rigorously often introduces coordination overhead, requiring organisations to balance operational continuity against the cost of constant entitlement review.
- A SaaS analytics vendor no longer pulls data after a platform migration, yet its API key still has read access to production records.
- A consulting firm’s admin account remains enabled after the contract ends because no one owns the offboarding step.
- A payment processor integration is replaced, but the old service account still has write permissions in CI/CD and secrets storage.
- A support vendor keeps emergency access in a break-glass role that was never time-bound or revalidated after a ticketing change.
- A cloud automation partner stops using a token, but the token stays valid and appears only during the next audit or incident review.
These cases show why dormant vendor access is best handled as a lifecycle control tied to inventory, owner review, and revocation triggers. NHI Mgmt Group’s Ultimate Guide to NHIs stresses that offboarding and visibility are foundational, while the 52 NHI Breaches Analysis shows how neglected non-human access repeatedly appears in real compromise paths. In standards language, the same idea aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls expectations for access enforcement and periodic review.
Why It Matters in NHI Security
Dormant vendor access matters because third-party identities often carry broad permissions, long token lifetimes, and weak ownership clarity. Once a vendor relationship changes, any unrevoked credential becomes an open path for misuse, accidental access, or lateral movement. NHIMG reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which explains why dormant access persists as a recurring governance gap rather than an isolated mistake.
The security impact is not limited to breach risk. Dormant access also undermines audit evidence, complicates Zero Trust enforcement, and obscures accountability when vendors change roles or ownership. A credential that is technically valid but operationally obsolete can still satisfy an attacker, an insider, or an overprivileged automation path. This is why dormant vendor access must be linked to inventory freshness, entitlement reviews, and explicit revocation events, not just annual compliance checks. The same risk pattern appears in NHI security research where unused access survives long after the business need has ended.
Organisations typically encounter the fallout only after a vendor disconnect, audit finding, or incident investigation, at which point dormant vendor access 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, 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 | Dormant vendor access is a form of stale NHI entitlement and secret governance failure. |
| NIST CSF 2.0 | PR.AA-01 | Access authorization must be current; dormant vendor access violates ongoing access validation. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification rather than trusting dormant third-party access. | |
| NIST SP 800-63 | IAL2 | Identity assurance principles support strong lifecycle controls for non-human vendor identities. |
Reconfirm vendor access need after workflow changes and remove credentials that no longer serve a business purpose.
