What should organisations do when a third-party identity is no longer needed?

What offboarding should actually remove

When a third-party identity is no longer needed, the goal is not just to “disable access” in the abstract. Organisations should remove the credential or token, strip the permissions that made the relationship useful, and confirm there are no hidden dependencies before the account or integration is retired. If a system still relies on it, offboarding has to be sequenced, not rushed.

That means treating the identity like any other business dependency with an owner, scope, and end date. If the identity is a contractor login, partner account, API credential, or federated third-party session, the shutdown needs to cover the credential, the entitlement set, and any downstream process that authenticates through it.

Where the relationship is contractual, the cleanest pattern is to tie deprovisioning to contract closure, supplier exit, or workflow completion rather than waiting for a periodic review cycle. This is the point where access becomes stale: the approval may remain technically valid even though the business reason has expired.

Why delayed offboarding is a security problem

Delayed removal creates a larger attack window than most teams expect. A third-party identity that remains active after the work is done can be reused, abused, or forgotten, especially when ownership has moved across teams or the original sponsor has left. The longer the gap, the more likely the identity becomes an orphaned path into systems that were assumed to be closed.

Third-party access also tends to accumulate hidden reach over time. One login or token may bridge into SaaS platforms, support tools, or shared workflows, so a stale identity can still access data long after the project it supported has ended. That is why access revocation and permission removal need to be validated together, not treated as separate administrative chores.

For organisations that rely heavily on federated access or external integrations, it is worth using a structured third-party access guide such as Third-Party, B2B and Contractor Access Guide to align sponsorship, time limits, reviews, and offboarding. The broader lifecycle perspective in NHI Lifecycle Management Guide is useful here because offboarding is only safe when it is part of a complete lifecycle, not a one-time revocation event.

How to end the relationship without leaving residual access

Good offboarding starts with inventory. You need to know which systems the identity can touch, which credentials exist, and which processes depend on them. In practice, that means checking direct logins, API tokens, service connections, delegated admin rights, and any embedded secrets that may continue to authenticate after the human or vendor relationship has ended.

Then remove access in the right order. If the identity is used by automation or integrations, rotate or retire the credential first, remove the permissions second, and only then close the account or external relationship. That sequence reduces the chance that a dependent process breaks unexpectedly while still ensuring the old credential cannot keep working.

Foundational guidance in IAM and IGA Basics helps explain why access reviews, entitlement removal, and joiner-mover-leaver discipline matter even for non-employee accounts. For organisations that manage many external identities, Top 10 NHI Issues is a useful reminder that stale access, over-privilege, and poor ownership are the common failure patterns that keep third-party identities alive too long.

Risk and Threat Considerations

Residual third-party access is attractive to attackers because it often sits outside normal employee offboarding controls, yet still reaches valuable systems or data. A forgotten token, dormant contractor account, or unused partner integration can become a low-noise entry point if the credential is stolen, shared, or simply never revoked.

Failure mechanism: The organisation removes the business relationship but leaves one or more authentication paths, permissions, or delegated trust links active, so the identity continues to work after ownership has effectively ended.

Impact: Attackers or former users can continue accessing data and systems, and defenders may not notice quickly because the access appears to belong to a legitimate third party. The result can be unauthorized data exposure, lateral movement through connected systems, or a difficult-to-trace breach path.

Practitioner Guidance

What to verify: Before offboarding is signed off, verify the identity has no active credential, no live entitlements, and no downstream service dependency that still authenticates through it. If any system still relies on it, treat the offboarding as incomplete, not pending cleanup.

Implementation sequence: Revoke the credential, remove permissions, confirm session or token invalidation where relevant, and then close the third-party relationship. If the identity is tied to an integration, validate the replacement path before final shutdown so the business does not preserve risky access just to avoid downtime.

Common mistake: Teams often remove the user record or terminate the contract but forget the token, API key, shared mailbox, delegated admin right, or automation hook that still authenticates independently. That is the step that usually turns “offboarded” into “still reachable.”

Practitioner takeaway: Third-party offboarding is only complete when access removal, dependency validation, and business closure all happen together, because stale approval is a control failure even if no abuse has been observed yet.

Related resources from NHI Mgmt Group

• How should organisations govern third-party identity access more tightly?
• Should organisations treat third-party access as a privileged identity risk?
• How can organisations reduce third-party identity risk without slowing operations?
• When should organisations recertify third-party identity applications?