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 is access granted to a supplier, contractor, platform partner, or other third party that is no longer actively needed but has not been removed. The key boundary is between an account that is merely inactive for a period and an account that should have been offboarded because the business relationship, integration, or delegated task has ended.
In practice, dormant access usually persists because access reviews are incomplete, ownership is unclear, or the system does not force timely removal when a contract changes. It differs from temporary inactivity: a vendor account can look harmless if it has not been used recently, yet still retain broad permissions, API reach, or administrative scope.
For security teams, the important distinction is lifecycle control rather than login frequency. An unused account is not automatically safe if it remains valid, trusted, and reachable. That is why vendor access should be interpreted as a governance and entitlement problem, not just a usage metric. For a machine-readable identity context, OWASP Non-Human Identity Top 10 is especially useful where the dormant access belongs to a service account, API client, or integration identity.
Examples and Use Cases
Dormant vendor access shows up most often where external parties support cloud systems, managed services, or application integrations. Typical examples include:
- A SaaS implementation partner keeps admin rights after go-live, even though day-to-day support has moved to an internal team.
- A payroll vendor retains API credentials after the organisation migrates to a new provider, but no one has revoked the old tokens.
- A contractor’s privileged account remains active after the engagement ends, because the offboarding request was never linked to the identity record.
- A monitoring or backup vendor still has broad tenant access long after the service contract changed, creating a lingering trust relationship.
- A CI/CD integration tied to a former supplier continues to authenticate with static secrets, even though the workflow is no longer required.
The common tradeoff is convenience versus control. Fast partner onboarding often creates standing access paths, and those paths are easy to forget when ownership moves or the system is restructured. In mature environments, the challenge is not proving that the access once made sense, but proving that it is still justified today.
Security Implications
Dormant vendor access matters because third-party accounts often carry elevated trust and broad operational reach. When those accounts remain active after need has passed, they become unnecessary entry points into cloud consoles, data stores, support tools, or automation workflows.
The main failure mode is that the organisation assumes “unused” means “low risk,” while the account still has valid credentials, permissions, and federation paths. If the vendor is compromised, or if credentials are reused or poorly protected, an attacker can inherit access that the business no longer actively monitors. This can expose sensitive data, allow configuration changes, or create a foothold for later movement across connected systems.
Operationally, dormant access also weakens audit confidence. Access reviews can appear complete while stale entitlements remain in place, and incident responders may struggle to tell whether a vendor account is truly in scope, retired, or still tied to an active dependency. In identity programmes, dormant third-party access is often a signal that deprovisioning and entitlement ownership are not consistently enforced.
Domain and Governance Relevance
In identity governance, dormant vendor access is a lifecycle control issue: access should expire when the business justification expires. That makes it especially relevant to vendor management, entitlement recertification, and offboarding workflows, where ownership often spans procurement, IT, security, and the business sponsor.
For NHI and automation-heavy environments, the same problem becomes more acute because vendor access is frequently tied to service accounts, tokens, or integrations rather than human logins. Those identities may not “go unused” in an obvious way, yet still remain trusted long after the workflow changes. That means governance must track not only who the vendor is, but which non-human identities or delegated access paths they still control.
Practically, the term belongs in the same control conversation as least privilege, access expiry, and periodic entitlement review. The governance question is simple: if the vendor no longer needs the access, who is accountable for removing it, and how is that removal verified?
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 CIS Controls v8 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-01 — Inventory and Ownership | Dormant vendor access often persists in service and integration identities. |
| NHI-03 — Secrets and Credential Management | Inactive vendor access is commonly retained through API keys, tokens, or certificates. | |
| NHI-06 — Access Review and Expiry | The core issue is stale third-party entitlement that should expire with the business need. | |
| Recommendation — Inventory vendor-owned non-human identities and remove orphaned or unowned access paths promptly. Rotate or revoke dormant vendor secrets before they can be reused or abused. Enforce time-bound vendor access and recertify every standing entitlement on a fixed cadence. | ||
| CIS Controls v8 | 6 — Access Control Management | Dormant vendor access is a direct access removal and least-privilege problem. |
| Recommendation — Remove vendor access immediately when the operational need ends and verify deprovisioning. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | This term centers on controlling third-party access lifecycle and authorization scope. |
| Recommendation — Maintain current access inventories and revoke vendor entitlements when authorization expires. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
