Who is accountable for third-party access after a campaign or project ends?

Why This Matters for Security Teams

Third-party access does not end when the project ends on paper. If an agency still has API keys, VPN access, SaaS tokens, or privileged service accounts, the business has retained an active external identity with no live operational need. That is an NHI problem as much as an access review problem. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s 52 NHI Breaches Analysis both point to the same pattern: access that is not actively governed becomes attack surface.

The accountability question matters because removal is usually split across teams. Security can define the control standard, IAM can disable the account, and procurement can close the contract, but none of those steps guarantee the relationship is actually terminated. The sponsoring business owner is the only party with enough context to confirm that the work is complete, the vendor no longer needs access, and every lingering credential has been revoked. NHIs exposed through weak offboarding often survive in backups, shared folders, CI/CD pipelines, and dormant integrations long after the project deliverable ships. In practice, many security teams encounter this only after a vendor account is reused, not through an intentional closeout.

How It Works in Practice

Operationally, the sponsoring team should own the offboarding checklist, while security sets the minimum standard for removal. That means the business owner confirms the project is closed, lists every system the third party touched, and signs off that access is no longer required. Then IAM or platform teams revoke the specific identity, not just the named user. Where possible, this should include JIT replacement for any standing access, token revocation, secret rotation, and removal from shared workspaces, CI runners, and support tools.

For third-party NHIs, the cleanup is rarely just one action. Current best practice is to treat the external party as a workload identity that must be tracked from creation to retirement, especially when it has tool access or automated execution rights. NHIs, not just human users, should be catalogued with ownership, purpose, expiry, and revocation path, as described in NHIMG’s Ultimate Guide to NHIs. If the account supports automation, use workload identity and short-lived credentials rather than long-lived secrets. If the access is tied to data pipelines or deployments, align the closeout with policy controls and review patterns discussed in the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack.

A practical control set includes:

• named business owner sign-off before access is removed
• inventory of every third-party account, token, and integration
• revocation of credentials, certificates, and API keys at project end
• secret rotation where shared credentials may have been exposed
• evidence capture for audit and incident response

These controls tend to break down when access is embedded in vendor-managed automation or inherited through shared service accounts because the real owner is unclear and the revocation path is undocumented.

Common Variations and Edge Cases

Tighter offboarding increases coordination cost, so organisations must balance clean revocation against delivery speed and vendor friction. That tradeoff is real, but it does not change accountability: the sponsor still owns the closeout even when IT executes the technical removal. Current guidance suggests that shared responsibility models should be explicit at contract time, not improvised after the relationship ends.

Some environments create edge cases. A contractor may retain read-only access for warranty support, or a managed service provider may need break-glass credentials for incident response. In those cases, the account should be time-bound, documented, and reviewed separately from the original campaign. There is no universal standard for every vendor scenario yet, but the direction from OWASP Non-Human Identity Top 10 and NHI governance practice is consistent: no standing access without a current business purpose. NIST AI Risk Management Framework and CSA-MAESTRO are especially relevant when the third party operates autonomous tooling or agentic workflows, because ownership must cover not only access but also the actions an agent can execute on the sponsor’s behalf. The DeepSeek breach shows how quickly secrets and exposed systems can expand impact when controls are not removed at the end of use. In mature programs, the closeout record becomes the proof that accountability was actually exercised, not merely assigned.

Related resources from NHI Mgmt Group

• Who should own third-party access risk in a banking GRC programme?
• Third-Party Access
• What should teams do when an AI agent keeps access after a project ends?
• How should security teams handle third-party access that looks legitimate after a supplier breach?