Who is accountable when external access is left active after a supplier relationship changes?

Accountability should sit with the business owner of the relationship, the IAM or NHI control owner, and the security function that validates removal. External access must be governed as lifecycle data, not a one-time approval. Without that shared accountability, dormant tokens and third-party accounts tend to survive long after the business need ends.

Why This Matters for Security Teams

When external access remains active after a supplier relationship changes, the issue is not just a missed cleanup task. It becomes an accountability failure across business ownership, access governance, and validation. That matters because third-party accounts, API keys, service tokens, and delegated access paths often bypass the normal employee leaver process and are easy to overlook once procurement, operations, or delivery teams move on.

Security guidance consistently treats access removal as part of the full identity lifecycle, not a one-time approval. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties access control, account management, and monitoring to ongoing operational responsibility rather than informal memory. For non-human access, the OWASP Non-Human Identity Top 10 highlights the risk that machine credentials outlive the business purpose they were created for. Current practice suggests that the real accountability question is not who requested the access, but who owns its continued legitimacy after the relationship changes.

In practice, many security teams encounter this only after a contract change, a vendor dispute, or an incident review has already exposed the stale access.

How It Works in Practice

Accountability works best when it is assigned at three layers. The business owner confirms whether the supplier relationship still justifies access. The IAM or NHI control owner ensures the entitlement, token, certificate, or account is removed or rotated. The security function independently verifies that the revocation happened and that residual paths such as shared secrets, federation trusts, and application-specific permissions are also closed.

This is especially important for NHI because access is often embedded in automation, integrations, and pipeline tooling. A supplier may no longer be active commercially, but its credentials can still authenticate to cloud services, source code repositories, ticketing platforms, or data feeds. That means offboarding must include both human and machine identities, with evidence captured for audit and incident response. Under NIST SP 800-53 Rev 5 Security and Privacy Controls, organisations should be able to show account lifecycle handling, access review, and configuration management discipline.

A practical workflow usually includes the following:

• Confirm the contract or service change that triggers access review.
• Inventory all supplier-linked accounts, secrets, tokens, and privileged roles.
• Revoke access through the authoritative system of record, not ad hoc requests.
• Validate revocation by checking logs, authentication events, and downstream integrations.
• Document who approved removal, who executed it, and who signed off on closure.

Where mature programmes exist, this process is tied to joiner-mover-leaver controls for both people and machines, with periodic recertification for long-lived integrations. These controls tend to break down when supplier access is created outside the normal IAM workflow because no single system owns the full inventory of active entitlements.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance speed of supplier onboarding against stronger offboarding discipline. That tradeoff is real, especially where procurement, engineering, and security all touch the same relationship.

There is no universal standard for every supplier scenario yet. For example, a low-risk SaaS integration may justify simple revocation on contract end, while a critical managed service may need staged decommissioning, rollback windows, and temporary exception handling. Best practice is evolving around whether shared responsibility matrices should explicitly name who owns revocation for each access type, especially for non-human credentials that can be copied into scripts or CI/CD systems.

Edge cases also appear when the supplier relationship changes but the technical relationship does not. A vendor may be acquired, subcontracted, or repurposed across business units, and access may still be valid technically even when it is no longer valid contractually. In those cases, the business owner should trigger review, the control owner should remove or constrain access, and the security function should confirm closure across all active systems. Emerging guidance from the OWASP Non-Human Identity Top 10 reinforces that unmanaged machine identities are often the hardest to retire because they lack a human owner visible in daily operations.

The clean rule is simple: if accountability for removal is not named before the relationship changes, stale access will persist after the business case has gone.

Related resources from NHI Mgmt Group

• Who is accountable when access is left active after a role change or departure?
• Who is accountable when Office 365 access stays active after role changes?
• Who is accountable when third-party credentials remain active after a healthcare relationship changes?
• Who is accountable when vendor access remains active after a banking engagement ends?