What happens when a former vendor still has active VPN access?

When a former vendor still has active VPN access, the organisation keeps an unnecessary path into internal systems open. That creates a window where the account may be abused for unauthorized access, privilege changes, or reconnaissance against other assets. The risk is especially high when access revocation is slow, shared passwords are common, or connection records are incomplete.

How active VPN access changes the risk profile after a vendor relationship ends

An active VPN account is not just a login, it is a trusted remote path into internal systems. If a vendor no longer needs that path, the organisation has effectively extended its trust boundary past the contract end date. The practical issue is not only access itself, but what the account can still reach, and whether that reach is visible, bounded, and revocable.

That matters because VPN access often sits behind other controls such as network segmentation, internal admin portals, file shares, and jump hosts. If the account remains valid, the former vendor may still be able to authenticate, enumerate services, and touch assets that were never meant to stay exposed outside the engagement window.

Former access is especially risky when the VPN is treated as a generic remote entry point rather than a tightly governed privilege. SonicWall VPN Mass Breach via Stolen Credentials illustrates how remote access credentials can become a broad internal foothold when they remain valid or are abused at scale. The same pattern applies when vendor accounts are not promptly disabled, reviewed, or tied to a clear owner.

What can a former vendor do with an uncleared VPN path?

An uncleared VPN account can support unauthorized access, privilege testing, and internal reconnaissance. In practice, that means the account may be used to probe subnets, discover administrative interfaces, identify weakly protected services, or attempt lateral movement if the vendor role carried broader reach than intended.

In some environments, the access path is more dangerous than the vendor’s original job role suggests. Shared credentials, reused passwords, or long-lived VPN profiles can turn what looked like a narrow support channel into a reusable entry mechanism. If logs are incomplete, it may be difficult to tell whether the access was used legitimately, accidentally, or maliciously.

When remote access is still active, the organisation also inherits an attribution problem. If the former vendor’s account was not individually assigned, or if session records are sparse, investigators may not be able to separate normal post-contract traffic from abuse. That weakens both detection and accountability.

Why revocation discipline matters more than the VPN product itself

The core control question is not which VPN platform is in use, but whether access removal is fast, complete, and provable. A clean offboarding process should disable the account, remove associated group membership, invalidate reusable credentials, and confirm that the former vendor cannot reconnect through alternate paths.

Remote access should be treated as a controlled privilege with a short lifecycle, not as a standing convenience. Where vendors need intermittent access, time-bounded approval, explicit ownership, and session visibility matter more than broad always-on connectivity. Privileged Session Management Guide is useful here because vendor remote access is often most defensible when sessions are brokered, recorded, and monitored rather than left as opaque direct connectivity.

Practitioners should also distinguish between access removal and exposure removal. Disabling the VPN account is necessary, but not sufficient if the vendor still has cached tokens, shared passwords, standing firewall exceptions, or unmanaged jump-host access. The goal is to remove every route that preserves trust after the relationship ends.

Risk and Threat Considerations

Unexpired vendor VPN access creates a classic residual-trust problem: an external party retains a live path into internal systems after the business relationship has ended. That increases the chance of unauthorized use, accidental misuse, and delayed detection if the account is later compromised or shared beyond the original user.

Failure mechanism: Revocation lags, shared credentials, or incomplete logging leave a valid remote entry point in place, which can be abused for internal reconnaissance, privilege escalation attempts, or lateral movement.

Impact: The organisation may face unauthorized access to sensitive systems, harder incident scoping, weaker forensic confidence, and a larger blast radius if the access is used maliciously.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Active VPN access depends on timely revocation and rotation of remote-access authenticators.
	AC-2 — Account Management	Former-vendor VPN exposure is an account lifecycle and deprovisioning failure.
	AC-6 — Least Privilege	Residual VPN access is dangerous when the account still reaches more than its business need.
Recommendation — Revoke and rotate VPN authenticators immediately on vendor offboarding. Disable vendor accounts promptly and verify all access paths are removed. Limit vendor VPN access to the minimum systems and functions required.
ISO/IEC 27001:2022	A.5.18 — Access rights	Access rights must be removed when a vendor relationship ends.
Recommendation — Review and revoke vendor access rights immediately at offboarding.
CIS Controls v8	CIS-6 — Access Control Management	Managing vendor VPN access requires prompt deprovisioning and least-privilege enforcement.
Recommendation — Remove dormant vendor access and validate least-privilege remote access.

Practitioner Guidance

What to verify: Confirm that offboarding removes the vendor from every VPN entitlement, not just the primary account. If the vendor used shared passwords, certificates, or secondary jump access, verify those routes were rotated or revoked as well.

What good looks like: You can show who approved the access, when it was removed, what systems it could reach, and whether any sessions were active at the time of termination. If you cannot produce that evidence quickly, the control is probably too weak for vendor remote access.

Decision rule: If an account can still reach production or administrative networks after the contract ends, treat it as a live exposure until proven otherwise. Prioritise revocation, session review, and credential rotation before debating whether the vendor ever misused the access.

Practitioner takeaway: The important question is not whether the access was once legitimate, it is whether the organisation can prove that every remaining remote path was removed as soon as the relationship ended.