Delayed revocation leaves an unnecessary entry point open after the work is finished. That creates lingering exposure to sensitive systems, increases the chance of accidental misuse, and gives attackers more time to exploit an account that should already be closed. The problem gets worse when one vendor account is shared by multiple people.
Why Delayed Revocation Becomes a Security Failure
When a vendor engagement ends, access should end with it. If revocation lags, the account remains a live path into systems that no longer need outside involvement. That creates unnecessary exposure to production data, admin consoles, and shared tools, especially when the vendor used broad privileges or credentials that were reused across tasks. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often this step is missed in practice.
The risk is not limited to intentional misuse. A dormant account can be reused accidentally, left active in automation, or targeted by an attacker who knows offboarding is incomplete. Guidance from the OWASP Non-Human Identity Top 10 treats delayed deprovisioning as a core identity risk because the account remains valid after the business need ends. NHIMG’s Ultimate Guide to NHIs places lifecycle control and offboarding at the centre of NHI governance. In practice, many security teams discover the gap only after a contract ends and the vendor account is still usable days later.
How Revocation Should Work in Practice
Effective offboarding is a workflow, not a ticket closure. The access path should be mapped before the engagement ends, then removed across identity provider, application, secrets store, VPN, and any delegated administrative roles. For non-human identities, that means revoking the credential itself, not just disabling a human mailbox or account placeholder. Current guidance suggests pairing deprovisioning with secrets rotation so that any copied tokens, API keys, or certificates stop working even if they were exported elsewhere.
Practitioners should treat revocation as a sequence:
- Identify every account, token, key, and certificate tied to the vendor.
- Remove entitlements first, then invalidate active sessions and refresh tokens.
- Rotate any shared secrets that may have been exposed during the engagement.
- Log the offboarding event and verify closure against all connected systems.
That aligns with NIST’s Security and Privacy Controls, which emphasise account management, least privilege, and timely termination of access. It also matches NHIMG research showing that secret and account lifecycle failures are among the most common sources of persistent exposure. These controls tend to break down when vendor access is spread across multiple SaaS tools and unmanaged shared secrets because no single owner can confirm full revocation.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, requiring organisations to balance speed against the need to avoid breaking legitimate dependent processes. That tradeoff becomes visible when a vendor supports integrations, support bots, or scheduled jobs that still rely on the same identity after the contract formally ends.
There is no universal standard for this yet, but best practice is evolving toward short-lived access, explicit expiry dates, and context-aware approval for any extension. The hardest cases are shared vendor accounts, service accounts embedded in scripts, and outsourced teams that reuse one credential across multiple staff members. In those environments, revocation of the visible account is not enough if tokens, cached sessions, or copied secrets remain valid elsewhere.
NHIMG’s breach analysis resources show that lingering credentials often survive handoff and termination events long enough to be exploited. When the account must be retained for audit or transition, the safer pattern is to strip privileges down to read-only, require re-approval, and force secret rotation before any new use. Delay is especially dangerous in high-turnover support arrangements because the organisation may assume the vendor has already removed access while the credentials are still live.
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 SP 800-63, NIST AI RMF 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-01 | Covers lifecycle and deprovisioning of non-human identities after vendor work ends. |
| NIST CSF 2.0 | PR.AC-1 | Addresses identity and credential management for timely access termination. |
| NIST SP 800-63 | Identity assurance depends on revoking credentials when the authorised relationship ends. | |
| NIST AI RMF | AI RMF stresses governance and accountability for access decisions and lifecycle risk. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous verification and rapid removal of no-longer-needed access. |
Build offboarding checks into access control workflows and confirm termination across all systems.
Related resources from NHI Mgmt Group
- Who is accountable when vendor access remains active after a banking engagement ends?
- Who is accountable when third-party access remains active after the engagement ends?
- Who is accountable when contractor badge access is still active after the engagement ends?
- What breaks when temporary admin access is not removed after the task ends?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
