Who is accountable for removing access when a contractor or vendor leaves?

Why This Matters for Security Teams

Offboarding is not just an HR event. For contractors and vendors, access often spans SaaS apps, cloud consoles, CI/CD systems, and shared secrets, so the real risk is not whether someone left, but whether revocation happened everywhere it needed to. Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group points to lifecycle ownership as a control problem, not a courtesy task. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why access lingers after departure.

Accountability should sit with the business owner who approved the access and the governance function that enforces revocation, not with the departing contractor, an informal manager reminder, or a ticket that can be lost in queue. That distinction matters because third-party access is often broader than the original request, especially when secrets are reused or permissions were granted outside a central identity workflow. In practice, many security teams discover lingering vendor access only after an audit finding or incident, rather than through intentional offboarding control.

How It Works in Practice

The cleanest operating model is shared accountability with clear handoffs. The business owner confirms that the contractor or vendor no longer has a valid need, while the identity, security, or governance team executes and verifies revocation across all systems of record. That includes user directories, PAM vaults, cloud roles, SaaS entitlements, API keys, certificates, and any machine credentials issued to the third party. The point is to remove access at the source, not simply disable one account and assume the rest follows.

Strong lifecycle workflows usually include:

• Predefined offboarding triggers tied to contract end dates, termination notices, or project closure.
• Central ticketing or workflow approvals that assign a single revocation owner.
• Automated checks for secrets, tokens, and keys that remain valid after the relationship ends.
• Evidence capture showing what was revoked, when, and by whom.
• Follow-up verification against systems where third parties may have received direct access outside the main IAM path.

For non-human access, the strongest practice is to prefer short-lived credentials and workload identity over standing secrets. NHI Management Group’s Key Challenges and Risks analysis highlights how persistent credentials and weak visibility keep exposure alive long after a vendor relationship ends. That is why revocation should be enforced by policy, not memory, and why teams increasingly pair offboarding with JIT credential expiry, secret rotation, and continuous discovery. These controls tend to break down when vendors are integrated directly into production systems without a central inventory, because no one can prove where the access actually exists.

Common Variations and Edge Cases

Tighter offboarding controls often increase operational overhead, requiring organisations to balance speed of vendor delivery against revocation assurance. The tradeoff is most visible with outsourced support, temporary integrators, and emergency access for incident response. In those cases, guidance suggests the business owner still carries approval accountability, but the security or governance team may need automated enforcement because manual review is too slow and too error-prone.

There is no universal standard for this yet, but current best practice is to treat every third-party relationship as having an explicit end state: account disablement, token expiry, vault cleanup, and certificate revocation. If contractors were granted access through local team processes, the cleanup must still be reconciled centrally. That is especially important where shared admin accounts, embedded secrets in code, or vendor-managed service accounts exist, because one offboarding action may not cover the full access chain.

NHIMG’s research shows why this matters operationally: The NHI Market context reinforces that third parties are deeply embedded in modern identity ecosystems, while the 52 NHI Breaches Analysis illustrates how often missed revocation becomes a breach enabler rather than a paperwork issue.

Related resources from NHI Mgmt Group

• Who is accountable when access governance gaps appear during digital transformation?
• Who is accountable when access is over-provisioned across cloud and on-premises systems?
• Who is accountable when a terminated user still has access?
• Who is accountable for access cleanup after ransomware recovery?