Why does third-party access become a security risk after a vendor relationship ends?

Third-party access becomes risky because accounts that were legitimate during onboarding can remain active long after the work is finished. Once the relationship ends, those accounts become ungoverned access paths to applications, documents, and shared resources. Without centralized visibility and revocation, security teams cannot reliably know where that access still exists.

Why Third-Party Access Becomes Risky After Offboarding

Third-party access becomes risky when the relationship has ended but the access path has not. During onboarding, vendors often receive legitimate entry to shared drives, support portals, SaaS tenants, APIs, or delegated admin tools so they can do the work. After the contract ends, those same accounts can persist as unreviewed exceptions, creating an access path that no longer has a business owner.

That matters because the original trust decision was conditional. Once the vendor is no longer performing services, the security team must treat every surviving account, token, and integration as residual exposure, not convenience. If the organisation cannot answer where the access exists, who can still use it, and what it can reach, it has lost control of the blast radius. The issue is not only unauthorised use by the former vendor; it is also the organisational inability to prove revocation across every connected system.

In practice, many security teams discover stale third-party access only after a contract closeout, audit request, or incident review reveals that the offboarding process was more administrative than technical.

How Third-Party Access Persists in Practice

Offboarding breaks down because third-party access is rarely concentrated in one place. A vendor may have a named account in the identity provider, an API key in a CI/CD pipeline, an OAuth grant in a SaaS application, a shared mailbox, and a service account embedded in a workflow. If termination is handled only as a procurement event, none of those assets is guaranteed to be revoked.

The security problem is compounded by delegated trust. A vendor may have created downstream access paths, temporary exceptions, or nested permissions that do not disappear when the relationship ends. Current guidance suggests treating this as a lifecycle problem: inventory the access, identify the owning business process, and verify revocation against the systems that actually enforce access rather than relying on a ticket closure.

This is where visibility becomes decisive. NHIMG research notes that The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how easily access can remain active in a shadowed layer of SaaS trust. For identity and access teams, that means the offboarding checklist must include entitlement review, token and secret rotation, partner connector removal, and log review for post-termination use. The OWASP Non-Human Identity Top 10 also helps frame the issue as a credential and lifecycle failure, not merely a vendor management problem. When offboarding is not tied to the actual identities and secrets in use, access survives the contract even when the business relationship is over.

Revoke access where it is enforced, not only where it was requested.
Check for embedded credentials, OAuth grants, automation hooks, and shared accounts.
Confirm that application owners, not procurement alone, sign off on closure.
Review activity logs after termination to spot delayed or hidden usage.

These controls tend to break down in SaaS-heavy environments with decentralized app ownership because access is granted across multiple consoles and rarely revokes from a single control plane.

Common Offboarding Gaps and Edge Cases

Tighter third-party controls often increase operational overhead, requiring organisations to balance fast vendor onboarding against stronger exit discipline. The hardest cases are not always malicious; they are the ones where access was created for support continuity, emergency admin, or one-time integrations and then forgotten.

There is no universal standard for this yet, but best practice is evolving toward time-bounded access, explicit ownership of every vendor entitlement, and routine review of dormant external accounts. Shared credentials are especially problematic because they can survive personnel changes on the vendor side and remain opaque to the customer. Similarly, federated access can appear harmless if the contract ends while the trust relationship in the identity provider remains intact.

OWASP Non-Human Identity Top 10 is useful here because it reinforces the need to govern credential lifecycle, privilege, and inventory together rather than as separate controls. Organisations that separate offboarding from access governance usually underestimate how many “temporary” integrations become permanent by default, especially in fast-moving SaaS and automation environments.

Risk and Threat Considerations

Residual third-party access creates an exposure window where former partners, displaced contractor accounts, or compromised vendor credentials can still reach internal resources. That risk is amplified when the original access was broad, privileged, or distributed across several systems, because the organisation may not notice the surviving path until after misuse has already occurred.

Failure mechanism: The usual breakdown is incomplete revocation across identity stores, SaaS connectors, secrets, and service accounts. Attackers do not need a new intrusion path if they can reuse a stale vendor account, an orphaned API token, or an unremoved federated trust relationship that still authenticates successfully.

Impact: The consequence can be unauthorised data access, integrity manipulation, persistence inside business systems, or lateral movement through trusted integrations. Even when no attacker is involved, the same failure means the organisation cannot confidently prove that access ended when 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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership	Third-party access persists when machine and delegated identities are not fully inventoried.
	NHI-02 — Secrets and Credential Management	Residual vendor access often survives through tokens, API keys, and shared credentials.
	NHI-07 — Authorization and Least Privilege	Former vendors may retain excessive rights after the business need ends.
Recommendation — Inventory every vendor identity and assign a clear owner before allowing any access to remain active. Rotate and revoke all vendor-linked secrets at offboarding, then verify no credential still authenticates. Remove unnecessary privileges immediately and confirm the surviving access matches the smallest required scope.
CIS Controls v8	5 — Account Management	Offboarding failures leave stale external accounts active beyond the vendor relationship.
	6 — Access Control Management	Vendor access must be revoked across apps, connectors, and shared resources when the relationship ends.
	8 — Audit Log Management	Post-termination activity can reveal surviving vendor access paths or abuse.
Recommendation — Disable or delete all third-party accounts as part of a documented account lifecycle process. Revoke third-party access centrally and confirm each downstream system no longer authorises the vendor. Review logs after offboarding to confirm no vendor identity continues to use protected systems.
NIST CSF 2.0	PR.AA-01 — Identity and Access Management	Vendor offboarding is an identity lifecycle and access governance issue.
	DE.CM-08 — Continuous Monitoring	Lack of monitoring allows surviving vendor access to go unnoticed after offboarding.
Recommendation — Enforce lifecycle-based access removal for external identities when the business relationship ends. Monitor third-party access paths continuously and flag activity from terminated vendors.
MITRE ATT&CK	T1078 — Valid Accounts	Attackers can abuse stale vendor accounts that still authenticate after offboarding.
Recommendation — Hunt for valid-account abuse and remove any surviving external credentials or delegated trust.

Practitioner Guidance

What to verify: Treat vendor offboarding as a control validation exercise, not a paperwork step. Verify that the vendor has no surviving accounts, tokens, certificates, OAuth grants, shared mailboxes, or automation credentials in any environment the relationship touched.

Decision rule: If a third party ever had privileged or machine-mediated access, require explicit revocation evidence from the systems of record before closing the engagement. If you cannot produce that evidence, treat the access as still active.

What practitioners underestimate: The hardest part is usually not the obvious user account but the hidden trust path, such as an integration account or delegated app consent that remains useful long after the business relationship ends. The right question is not “Did the vendor leave?” but “Can anything they created still authenticate?”

Practitioner takeaway: Offboarding is complete only when the trust relationship is technically removed everywhere it exists, not when the contract file says the work is done.