Who is accountable when a third party retains access after offboarding?

Why This Matters for Security Teams

Offboarding is not a clerical task. When a third party retains access after the relationship ends, the real risk is not just lingering credentials, but an unmanaged path into regulated systems, data, and production workflows. Under outsourcing governance, the institution still owns the control obligation, even if the provider still holds the secret.

That distinction matters because offboarding failures often stay invisible until an audit, an incident, or an access review exposes them. The NHIMG The 2025 State of NHIs and Secrets in Cybersecurity report found that 91% of former employee tokens remain active after offboarding, which is a strong signal that lifecycle control breaks are common across identity programs. The same pattern applies to vendors and contractors when ownership of access termination is unclear.

Security teams should treat third-party access persistence as a governance failure, not a vendor convenience. Standards such as the OWASP Non-Human Identity Top 10 reinforce that credential lifecycle and ownership are core control issues, not optional hygiene. In practice, many security teams encounter retained access only after a post-incident review or an audit finding, rather than through intentional offboarding verification.

How It Works in Practice

Accountability should be mapped to the party that owns the outsourcing relationship, the system access, and the risk acceptance decision. In regulated environments, that usually means the bank, insurer, or other institution must define the offboarding standard, confirm who can approve revocation, and verify that access is actually removed from every control point.

A defensible offboarding process usually includes identity, credential, and session termination across the full stack. That means disabling human accounts, revoking API keys and service tokens, rotating shared secrets, closing federation trust links, and confirming that privileged group membership, VPN access, and SaaS entitlements are removed. The NHI Lifecycle Management Guide is a useful reference for treating revocation as a lifecycle event, not a one-time ticket.

Controls work best when they are tied to evidence. Teams should require an offboarding checklist, a dated revocation record, and a final access validation step that proves the third party no longer has an active path. The 52 NHI Breaches Analysis shows how identity failures repeatedly turn into exposure events when lifecycle discipline is weak.

• Assign an internal owner for every third-party identity and credential.
• Require revocation across IAM, PAM, SaaS, and secret stores.
• Verify that federation, API tokens, and backup access paths are also removed.
• Retain evidence of completion for audit and incident response.

These controls tend to break down when access is decentralized across multiple business units and the institution cannot prove who has authority to revoke each path.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance fast supplier disengagement against formal validation and evidence capture. That tradeoff is real, especially when contracts end abruptly or when the third party manages production support for multiple environments.

There is no universal standard for every edge case, but current guidance suggests the same accountability principle should still apply when access is indirect. For example, if a supplier uses federated sign-in, the institution still needs a kill switch at the trust boundary. If the third party holds shared service credentials, the organisation should rotate or replace them rather than assume deletion happened. If a contractor’s tooling is embedded in CI/CD or admin automation, revocation must include pipeline secrets and automation roles, not just interactive accounts.

Supply-chain exposure is often the hardest variation because access may persist through nested providers or inherited integrations. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both support the same operational point: the organisation must be able to trace every active access path to an accountable owner. Best practice is evolving, but the expectation remains that retained access after offboarding is a control exception the institution must detect and close, not a responsibility it can shift outward.

Related resources from NHI Mgmt Group

• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a third party keeps access after the work ends?
• Who is accountable when third-party access remains active after the task is complete?
• Who is accountable for access cleanup after ransomware recovery?