Who should be accountable for third-party access removal?

Why This Matters for Security Teams

Third-party access removal is usually where governance assumptions meet operational reality. If accountability is unclear, dormant vendor accounts, API keys, and service tokens can remain active long after a contract ends or a task is complete. That creates a direct path for over-privileged access, especially since NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs from NHI Mgmt Group. The issue is not whether someone “meant” to revoke access. The issue is whether a named owner is responsible for proving revocation happened. This is why security teams should treat third-party offboarding as an identity lifecycle control, not a procurement closeout item. The OWASP community’s OWASP Non-Human Identity Top 10 reflects the same pattern: failures in NHI governance often emerge when credentials are distributed across teams with no single accountable owner. In practice, many security teams encounter residual vendor access only after an audit, incident, or contract dispute has already exposed the gap.

How It Works in Practice

Accountability should be split by function, but not diffused. The business owner who approved the third-party relationship should own the decision to end access, confirm the service is no longer required, and validate that the vendor’s work is complete. The identity team should own the technical revocation workflow, including disabling accounts, rotating shared secrets, removing API keys, and verifying that downstream entitlements are actually gone. A workable process usually includes:

• A clear offboarding trigger tied to contract end, scope change, or risk decision.
• A named access owner in the business unit who signs off on removal.
• Identity operations that execute revocation across IAM, PAM, vaults, and SaaS admin consoles.
• Evidence capture showing what was removed, when, and by whom.
• Exception handling for shared integrations, break-glass access, and regulated retention requirements.

This split aligns with the control emphasis in the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights how often secrets persist after they should have been removed. It also matches the operational guidance emerging from the OWASP Non-Human Identity Top 10, where ownership and lifecycle failures are recurring drivers of exposure. Procurement can confirm that a contract ended, but procurement rarely has the system privileges needed to revoke a token or certify that an integration path is closed. That is why current guidance suggests treating revocation as a technical control with business accountability, not a documentation task. These controls tend to break down when third-party access is embedded in automation pipelines because hidden secrets and shared integrations survive the formal offboarding request.

Common Variations and Edge Cases

Tighter access removal often increases coordination overhead, requiring organisations to balance fast deprovisioning against operational continuity. The most common edge case is a vendor that supports multiple business units or multiple environments, where one contract ends but another remains active. In that case, accountability should remain with the business owner for the terminated scope, while the identity team ensures the technical revocation is scoped correctly and does not break unrelated production access. Another frequent exception is shared service access. If a third party uses a common integration account, there is no universal standard for this yet: best practice is evolving toward per-vendor, per-task identities so accountability can be traced cleanly. For especially sensitive access, the removal decision may need a second control from PAM or a secrets manager rather than relying on directory deactivation alone. The broader lesson is that accountability must be explicit in the workflow, not implied by job title. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how quickly unmanaged identities become an attack path when revocation lags. Only 20% of organisations have formal processes for offboarding and revoking API keys, so the operational gap is common rather than exceptional. In practice, the safest model is a signed owner decision plus a verified technical revoke, with both steps recorded before the relationship is considered closed.

Related resources from NHI Mgmt Group

• Who should own third-party access removal in compliance programmes?
• Who is accountable when third-party remote access is overused in public safety environments?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a user grants a risky third-party app access?