What should teams do when a contractor or vendor no longer needs access?

They should revoke it immediately, confirm the account is disabled across all connected systems, and validate that no shared tokens, linked roles, or dormant permissions remain. The goal is to remove the access path completely, not just mark it inactive in one system.

Why Offboarding Must Reach Every Connected System

Access removal only works when it is complete. A contractor or vendor can still reach data, admin functions, or shared infrastructure if one connected app, delegated role, or old session survives the first disablement. The practical issue is not whether the account is “inactive” somewhere, but whether every path that could still be used has been closed.

This is why teams should treat offboarding as a cross-system state change, not a single-ticket update. The access decision has to propagate through identity providers, application permissions, federation links, API grants, and any shared secrets or certificates that were issued to the external party.

What Needs to Be Removed, Not Just Disabled

For external access, the target is to revoke the entire access chain. That usually includes the primary account, any linked roles, group memberships, delegated admin paths, API tokens, SSH keys, certificates, and reusable approvals that were granted for the engagement. If the contractor used an SSO path, teams should verify that the downstream application has also stopped trusting that session or assertion.

Shared access is especially important to inspect because it can outlive the named account. A disabled login does not help if the person still has a shared token in a script, a role assumption path in a cloud console, or a dormant permission assignment in a separate system. The access review must follow the actual ways work was done, not only the directory record.

Disable the named account and confirm the change propagated.
Revoke any tokens, keys, certificates, or session-based access tied to that identity.
Remove linked roles, groups, and delegated permissions in connected platforms.
Check for shared or inherited access that was not attached to the primary account.

How Teams Prevent Leftover Access from Becoming a Residual Risk

Teams should build offboarding around verification, not assumption. A clean deprovisioning step is only reliable when someone checks the account state in the source system and the consuming systems, then confirms that no fallback path remains. That matters because “disabled” in one console can still leave effective access alive elsewhere.

Good practice is to pair revocation with a short validation pass that looks for remaining credentials, dormant entitlements, and any other accounts the contractor may have used during the engagement. If the vendor had privileged access, that check should also cover privileged session tooling and any standing exceptions that were created for support or maintenance.

Risk and Threat Considerations

Residual third-party access can turn a routine offboarding miss into unauthorized access, data exposure, or a persistence path for abuse. The biggest failure mode is partial revocation: one system shows the user as disabled while another still trusts a token, linked role, or shared credential.

Failure mechanism: Access remains effective because removal did not reach every trust point, so the contractor or a party that finds the leftover secret can still authenticate or act under the original permissions.

Impact: The organisation keeps an unnecessary attack surface, and any forgotten access path can be used for data theft, privilege misuse, or later compromise long after the contract ended.

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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Directly addresses lingering third-party access after offboarding.
	NHI-02 — Secret Leakage	Offboarded contractors may retain secrets, keys, or tokens that still authenticate.
	NHI-05 — Overprivileged NHI	Vendor access often persists through excess roles or inherited permissions.
Recommendation — Revoke all tied access paths and verify no leftover tokens or roles remain. Rotate or revoke exposed secrets and confirm none remain usable. Remove unnecessary privileges and validate least-privilege access after offboarding.
NIST SP 800-53 Rev 5	AC-2 — Account Management	Requires disabling and removing accounts when access is no longer needed.
	IA-5 — Authenticator Management	Covers revoking tokens, keys, and other authenticators tied to departed users.
Recommendation — Terminate accounts promptly and validate deprovisioning across all systems. Revoke authenticators and rotate shared credentials after offboarding.
CIS Controls v8	CIS-5 — Account Management	Focuses on account lifecycle hygiene and removing stale access.
Recommendation — Inventory and remove stale external accounts and related access artifacts.
CSA Cloud Controls Matrix	IAM — Identity & Access Management	Cloud vendor access offboarding depends on removing identities, roles, and tokens.
Recommendation — Revoke cloud identities, roles, and credentials when access is no longer required.
MITRE ATT&CK	T1098 — Account Manipulation	Residual contractor access can be abused by altering or retaining accounts and permissions.
Recommendation — Monitor for lingering or modified accounts that preserve unauthorized access.

Practitioner Guidance

What to verify: Do not stop at “account disabled.” Verify the effective access state in each connected system, including SaaS apps, cloud roles, remote access tools, and any place where the contractor could have stored reusable secrets or linked approvals. If you cannot prove the access path is gone, treat the offboarding as incomplete.

Decision rule: If the contractor or vendor had privileged, federated, or token-based access, require a post-revocation check for dormant permissions and shared credentials before closing the ticket. If the engagement used a sponsor model or shared admin path, assign ownership for confirming that every inherited path has been removed.

Practitioner takeaway: Offboarding is successful only when no remaining identity, token, role, or shared path can still reach the environment, because “inactive” is not the same as “unusable.”