Who should own third-party access revocation when a vendor relationship changes?

Who should own third-party access revocation when a vendor relationship changes?

Ownership should sit with both the business system owner and the identity governance function, with procurement triggering the process and security verifying closure. If revocation is left to informal coordination, access often persists after the contract, project or integration ends. The goal is to make offboarding a control, not a courtesy.

What ownership model actually works

Third-party access revocation fails when it is treated as someone else’s cleanup task. The business owner knows whether the vendor still needs access, the identity function can remove entitlements and tokens, and procurement or vendor management often has the earliest signal that the relationship changed. Those roles need a defined handoff, not parallel assumptions.

In practice, ownership should be explicit enough that one function can initiate revocation, another can execute it, and a third can confirm it is complete. That division matters because access can persist in more than one place: application roles, federation trust, API tokens, shared accounts, remote support tooling and related secrets. If any one of those paths is omitted, the vendor may still retain effective access.

A useful way to think about it is that the business owner owns the decision, identity governance owns the control, and procurement owns the event trigger. Security should not be the only team expected to discover the issue after the fact. For a broader control baseline on IAM and IGA Basics, revocation belongs to the same lifecycle discipline as provisioning, entitlement review and joiner-mover-leaver controls.

Where revocation usually breaks down

The weakest point is usually not the technical removal step, but the lack of a reliable trigger. When contracts end, scopes change or integrations are retired, teams often assume another group will notify the right owners. That is how dormant vendor accounts, long-lived tokens and stale federation links survive past the relationship that justified them.

The second failure mode is fragmented ownership across platforms. A vendor may lose access in one application while keeping API credentials, support portal access or a remote admin path elsewhere. That is why the process must be tied to the full access surface, not just a single ticket closure. Third-Party, B2B and Contractor Access Guide is relevant here because it frames time limits, sponsorship, least privilege and offboarding as part of the same third-party control model.

The third failure mode is ownership ambiguity. If the business says it is “security’s job,” security may not know whether the vendor relationship is actually over. If identity teams are left to infer business intent, they may revoke access too early or leave it untouched. Clear ownership prevents both over-revocation and lingering access.

Why offboarding has to be treated as a governed control

Third-party revocation is not just administrative hygiene, it is a boundary control. Once a vendor relationship changes, any standing access that remains becomes difficult to justify and easier to abuse. That matters most where the vendor had broad privileges, shared credentials, or integration tokens that can be reused outside the original business context.

This is also why offboarding should be linked to the access governance process, not only to the commercial relationship. If revocation depends on informal follow-up, the control weakens exactly when the relationship is in transition. A stronger model forces closure evidence, such as confirmation that accounts, tokens, support paths and delegated permissions have all been removed. For incident patterns that show how vendor access can become the attack path, see Scania insurance portal breach 2025 and Caesars Entertainment breach 2023, both of which illustrate how third-party access paths can outlive trust.

Good ownership also makes audit and recovery easier. If there is ever a dispute about whether access should have been removed, the organisation can point to a defined process, an accountable owner and a closure record rather than a chain of emails. That is the difference between a managed control and an improvised reaction.

Risk and Threat Considerations

When third-party access revocation is not owned clearly, the residual exposure is often broader than teams expect. A vendor may retain authentication paths, API credentials, support tooling or federated access long after the business need has ended, which creates unnecessary standing access and widens the blast radius of a later compromise.

Failure mechanism: Weak handoffs let expired vendor access remain active across systems that are not closed together, especially when contract changes, project exits or integration shutdowns are not tied to a mandatory revocation workflow.

Impact: The organisation keeps an access path alive after the trust relationship has changed, increasing the chance of unauthorized use, lateral movement, data exposure or difficult-to-contain vendor-related compromise.

Practitioner Guidance

What to verify: Confirm that every vendor relationship has a named business owner, a named technical revoker and a closure trigger that comes from procurement, contract management or service decommissioning. If you cannot name who closes access, the process is not actually owned.

Decision rule: If the vendor can still authenticate anywhere after the relationship changes, treat revocation as incomplete until accounts, tokens, federation links and support paths are all closed. Do not accept “the request was sent” as evidence of control closure.

Practitioner takeaway: The right ownership model is one that makes revocation unavoidable, provable and time-bound, because third-party access risk comes from what is left behind after the relationship changes.

Related resources from NHI Mgmt Group

• Who is accountable for third-party access when a vendor relationship ends?
• How should security teams handle third-party NHI access that outlives the vendor relationship?
• Who should own revocation for third-party non-human access?
• Why does third-party access become a security risk after a vendor relationship ends?