What breaks when third-party access is not offboarded cleanly?

The organisation loses control of who can still reach sensitive systems after the business need has changed. That creates audit gaps, weakens incident containment, and leaves supplier access outside normal review cycles. In a NIS2 context, unrevoked vendor access is not just a security problem, it is a governance failure.

Why This Matters for Security Teams

When third-party access is not offboarded cleanly, the breakage is operational as much as it is technical. Supplier accounts, service accounts, API keys, and delegated tokens can keep working long after a contract ends, a project closes, or a vendor relationship changes. That leaves access outside normal review, weakens segregation of duties, and creates blind spots in incident response. In practice, this is exactly where governance and security drift apart, because the organisation assumes access was removed when the business process stopped, but the credentials did not. The risk is amplified by the fact that only 20% of organisations have formal processes for offboarding and revoking API keys, according to the Ultimate Guide to NHIs. That gap is consistent with the patterns described in the 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10, both of which highlight lifecycle failure as a recurring root cause. In practice, many security teams discover lingering supplier access only after an audit, a breach, or a failed containment effort has already exposed the weakness.

How It Works in Practice

Clean offboarding should remove every access path tied to the third party, not just the obvious user account. That means revoking API keys, disabling service accounts, rotating shared secrets, removing federated trust, and validating that no downstream automation still depends on the old identity. For non-human identities, the lifecycle has to be explicit: issue, use, monitor, rotate, and retire. The NHI Lifecycle Management Guide treats retirement as a control point, not an administrative afterthought, because secrets and machine credentials often survive longer than the vendor relationship that created them. OWASP guidance also aligns with this lifecycle-first model, and the OWASP Non-Human Identity Top 10 is useful for mapping where unrevoked access tends to persist.

• Inventory all third-party NHI entry points, including CI/CD tokens, cloud roles, vault entries, and delegated OAuth grants.
• Revoke at the source, then verify no replicas, caches, or fallback credentials remain active.
• Rotate any shared secrets that may have been exposed to the departing supplier.
• Confirm with logs and access telemetry that the identity is no longer authenticating.

This is where Zero Trust and least privilege become practical, not theoretical. If access is not tied to a clear owner, a TTL, and a review cadence, it becomes orphaned. The breach patterns covered in the The 52 NHI breaches Report show that lingering credentials often remain usable even after remediation is assumed complete. These controls tend to break down in heavily automated environments where supplier tokens are embedded in pipelines, code, or unmanaged vaults because there is no single place to revoke all copies.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance fast vendor turn-down against the need for complete credential retirement. That tradeoff is especially visible when a supplier supports shared infrastructure, embedded SaaS integrations, or emergency break-glass access. In those cases, best practice is evolving, and there is no universal standard for every topology yet, but the direction is clear: shorten standing access, make exceptions time-bound, and document explicit revocation ownership. The Ultimate Guide to NHIs is clear that visibility is a prerequisite for retirement, while the Top 10 NHI Issues highlights how misconfigured vaults and weak lifecycle controls prolong exposure. For regulated environments, unrevoked supplier access can also become a compliance issue under OWASP Non-Human Identity Top 10 informed governance, even where the formal obligation sits elsewhere. The hardest edge case is shared credentials in legacy systems, because revoking them can break production dependencies and expose hidden coupling. In those environments, offboarding has to be staged, verified, and paired with dependency discovery before the final cutover.

Related resources from NHI Mgmt Group

• Who should own third-party access risk in a banking GRC programme?
• Who is accountable for third-party access after a campaign or project ends?
• Why do manufacturing environments need stricter third-party access controls than standard IT environments?
• Who is accountable when a user grants a risky third-party app access?