Vendor Access Without Lifecycle Offboarding

What lifecycle offboarding means for vendor access

Vendor access without offboarding is not just an administrative miss, it is a control failure in the third-party relationship. Once the commercial need ends, access that remains active can preserve a path into production systems, shared data stores, admin consoles, and connected applications long after the vendor should be out of scope.

The core problem is that the access often looks legitimate. Accounts may still authenticate, OAuth grants may still work, API keys may still be accepted, and roles may still carry privileges that were granted for a prior engagement. That makes the issue easy to overlook until someone reviews the vendor inventory or sees evidence of dormant access being used.

Why stale vendor access is dangerous

Stale vendor access widens the attack surface because third-party permissions are usually broader than ordinary user access and often sit outside day-to-day monitoring. If a vendor account, service principal, or support credential is left behind, an attacker who compromises that material can inherit an already-trusted path into your environment.

This risk is especially serious when the access is tied to remote support, integrations, or privileged administration. NHIMG’s Third-Party, B2B and Contractor Access Guide shows why third-party access needs sponsorship, least privilege, time limits, and explicit offboarding as part of the original access design.

Leftover access can also become a governance blind spot. Organisations may remember the contract ended, but forget the linked accounts, delegated consents, or API credentials that keep working quietly in the background.

What to check when you suspect vendor access was not offboarded

The first step is to locate every place vendor access could persist, including IAM directories, SaaS admin panels, SSO assignments, API gateways, cloud roles, support portals, and shared vaults. The most common miss is a partial cleanup, where one account is removed but tokens, app consents, or secondary roles remain active.

NHIMG’s Vendor Offboarding and Termination Guide is a practical reference for this review because it centers on inventorying vendor access, revoking sessions, removing OAuth grants, rotating shared secrets, and confirming deletion obligations at contract end.

It also helps to compare the technical inventory against the commercial reality. If the vendor no longer has a business need, any surviving access should be treated as excess access until proven otherwise. That includes dormant support accounts, stale API tokens, and legacy integrations that were never formally decommissioned.

How organisations prevent the offboarding gap

Prevention depends on making vendor exit part of the access lifecycle, not an afterthought. Access should expire by default, be tied to a named sponsor, and be reviewed against the contract, the integration purpose, and the current support model.

NHIMG’s Employee Offboarding Security Guide and Joiner-Mover-Leaver (JML) Guide are useful here because the same lifecycle discipline applies to third parties: revoke sessions, remove old entitlements, and close out the credentials and agents that should not survive the relationship.

For higher-risk vendors, offboarding should also be contractually enforceable. Vendor contract clauses for credential revocation and breach notice helps formalise what should happen when vendor-held tokens or keys need to be revoked quickly, which is especially important when technical teams are not available on the day the commercial relationship ends.

How to verify cleanup and reduce residual exposure

Verification matters because a removed account is not the same as removed access. Organisations should confirm that sessions are invalidated, credentials are rotated where needed, shared secrets are replaced, and delegated permissions have actually disappeared from the target systems.

That is why Third-Party Access Policy Template and Top 10 Third-Party Risk Mistakes are both relevant. One gives the policy structure for time-bound, revocable access; the other highlights the common failure mode where organisations rely on questionnaires or contracts but do not actually remove the live technical access paths.

Where vendors used privileged remote access, the remaining exposure may include recorded sessions, cached credentials, or management-plane permissions that survived the formal exit. In those cases, cleanup is not complete until the access path itself is shut down, not merely the person or company name attached to it.

Related resources from NHI Mgmt Group

• Lifecycle Offboarding
• How should security teams automate identity lifecycle management without creating new access risk?
• How should security teams govern vendor access across the third-party lifecycle?
• How should security teams govern vendor access across the full lifecycle?