What should security teams do after a third-party partner leaves or no longer needs access?

Security teams should remove every account, credential, and permission tied to that partner as part of a formal offboarding process. That includes direct users, shared systems, and any lingering access in connected applications or file stores. Teams should verify revocation, document the removal, and confirm that sensitive data is no longer reachable through stale permissions.

Third-party access rarely lives in one place. A partner may have a direct account, a shared mailbox, API tokens, OAuth grants, file-store permissions, or access inherited through connected apps. If any of those survive after the relationship ends, the partner can still reach data or systems long after the business need has expired.

That is why offboarding should be treated as a full access withdrawal, not a simple account disablement. The practical goal is to eliminate every path that still authenticates, authorises, or delegates access on behalf of that partner, including anything embedded in integrations that may not be obvious from the user directory.

What a complete partner-offboarding review has to cover

A clean offboarding review starts by enumerating every identity and every credential associated with the partner, then tracing where those rights were propagated. That includes direct accounts, service accounts, tokens, certificates, shared secrets, application grants, and permissions inside SaaS tools, document repositories, and file stores.

Security teams should also look for indirect access. A partner may have been removed from one system but still be reachable through delegated roles, group membership, synced directory objects, or an application connection that was never revoked. The review is not complete until the team can explain where access existed, where it was removed, and what evidence shows the removal succeeded.

For partner-driven access, the strongest practical control is to verify the revocation in the system of record, then test the affected path if the business process allows it. A documented change is useful; a confirmed denial of access is better.

Why stale third-party permissions are a security problem, not an administrative nuisance

Stale partner access creates avoidable exposure because the original trust decision no longer matches reality. The partner may have changed staff, changed ownership, been acquired, or simply no longer need the data. Any surviving permission becomes dormant access that can be abused accidentally, opportunistically, or maliciously.

The risk is highest where the partner had access to sensitive business data, production systems, or connected cloud applications. In those cases, a forgotten token or overlooked shared folder can preserve a live route into the environment even after the relationship has formally ended.

Good offboarding therefore includes both removal and verification. Teams need to be sure that access has been revoked everywhere it could still function, not just in the most visible admin console.

Risk and Threat Considerations

Residual third-party access can become an active compromise path if a former partner account, token, or integration secret is left in place. That creates an unnecessary trust boundary that an insider, attacker, or former contractor can abuse to reach data or pivot into connected systems.

Failure mechanism: The organisation removes the obvious user account but misses delegated access, cached credentials, API grants, or permissions embedded in downstream applications, so the partner can still authenticate or retrieve data.

Impact: Sensitive information remains reachable, access reviews become inaccurate, and a departed partner can retain a path to production or shared content that the business believes has been closed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Directly addresses lingering access after a partner leaves.
	NHI-02 — Secret Leakage	Stale partner secrets can still authenticate after offboarding.
	NHI-07 — Long-Lived Secrets	Lingering credentials outlive the business need after partner exit.
Recommendation — Revoke every account, token, and grant and verify no residual access remains. Rotate and revoke exposed secrets tied to the departed partner. Shorten secret lifetimes and remove credentials when access ends.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Partner offboarding requires revoking and rotating authenticators and secrets.
	AC-2 — Account Management	Offboarding is an account lifecycle action covering deletion and disablement.
Recommendation — Revoke or rotate authenticators tied to the departing partner. Disable or remove partner accounts and confirm the state change.
ISO/IEC 27001:2022	A.5.16 — Identity management	Partner access removal is an identity lifecycle governance activity.
	A.5.18 — Access rights	The core task is to revoke access rights when the partner no longer needs them.
Recommendation — Remove partner identities from all systems and integrations. Revoke obsolete access rights and confirm they no longer apply.
CIS Controls v8	CIS-5 — Account Management	CIS account lifecycle control supports timely removal of stale partner access.
Recommendation — Maintain a complete account inventory and promptly disable departed partner access.

Practitioner Guidance

What to verify: Confirm the revocation in every system that can independently grant access, not just in the directory. If the partner used shared systems or integrations, verify that tokens, app consents, and file permissions were removed or expired as well.

What good looks like: The offboarding record should show the identities removed, the credentials rotated or revoked, the applications checked, and the date and owner of each confirmation. If you cannot produce that evidence, treat the offboarding as incomplete.

Practitioner takeaway: After a partner leaves, the real control is not “disable the account”, it is proving that no surviving credential, grant, or inherited permission still lets that partner reach your data or systems.