What do organisations get wrong about third-party offboarding?

Why Third-Party Offboarding Fails in Practice

Third-party access is often granted for speed, then removed through a slow human process that assumes someone will remember to act. That is the core mistake. Offboarding is not a courtesy task after the contract ends; it is a control objective tied to risk reduction, evidence, and time. When revocation depends on a ticket queue or a final handoff meeting, access can persist long after business need has disappeared.

That gap is especially dangerous because third parties frequently touch shared secrets, API keys, service accounts, and production systems. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, while 92% expose NHIs to third parties. The practical lesson is that vendor access must be designed to expire, not merely expected to be removed.

Security teams also underestimate how often offboarding failures involve stale credentials outside the IAM console, which is why lifecycle governance has to include secrets stores, CI/CD, vaults, and shared admin paths. The OWASP Non-Human Identity Top 10 frames these lifecycle failures as a recurring identity risk, not an isolated process miss. In practice, many organisations discover third-party access still working only after the relationship has already ended.

How Strong Offboarding Should Work

Effective third-party offboarding starts before onboarding does. The access grant should carry an owner, a business purpose, an expiry date, and the exact systems it covers. At termination, the control should trigger revocation automatically across all identity surfaces: SSO accounts, VPN, privileged access tools, cloud roles, tokens, SSH keys, certificates, webhook secrets, and any shared service accounts. Manual review can verify completion, but it should not be the mechanism that makes revocation happen.

A mature workflow usually includes:

• Time-linked access with a hard expiry aligned to the contract or statement of work.
• Automated deprovisioning across IAM, PAM, secrets managers, and cloud control planes.
• Replacement or rotation of any shared secret the third party could have seen or used.
• Evidence capture showing what was revoked, when, and by whom or by what system.
• Exception handling for legal holds, regulated handovers, or service continuity cases.

NHIMG’s NHI Lifecycle Management Guide emphasises that lifecycle control is only real when provisioning, rotation, and offboarding are linked. That aligns with guidance in the OWASP NHI material and with current best practice in secrets hygiene, where stale credentials are treated as active risk until proven otherwise. Organisations that also follow the 52 NHI Breaches Analysis will recognise that many incidents begin with credentials that outlive the relationship they were meant to support.

These controls tend to break down when third parties share generic admin accounts or when revocation depends on systems that the offboarding team cannot directly control.

Common Exceptions, Tradeoffs, and Failure Modes

Tighter offboarding often increases operational overhead, so organisations have to balance speed with assurance. There is no universal standard for every exception, but current guidance suggests that exceptions should be narrow, time-bound, and explicitly approved. The most common edge case is service continuity: a vendor may still need read-only access during migration or remediation, but that access should be separated from production privileges and tracked as a temporary exception.

Another failure mode is incomplete asset discovery. If the third party used embedded credentials in scripts, CI pipelines, or integration tools, removing only the user account leaves the real access path intact. The Top 10 NHI Issues highlights this broader lifecycle blind spot, where organisations believe an identity has been removed even though a token, key, or certificate remains valid elsewhere.

Offboarding also becomes difficult when procurement, legal, IT, and security operate on different timelines. Best practice is evolving toward shared offboarding triggers that start from contract termination, not from a separate security request. The key question is not whether the account was deleted, but whether every path the third party could still use has been revoked and verified. That distinction is where many programmes fail first.

Related resources from NHI Mgmt Group

• What do organisations get wrong about third-party privileged access?
• What do organisations get wrong about third-party access in hybrid environments?
• What do organisations get wrong about AI-enabled third-party apps?
• What do security teams get wrong about secrets in third-party code and integrations?