How should organisations handle third-party remote access when VPNs expose too much of the network?

Why third-party remote access should be treated as a separate control problem

VPNs are designed to extend trust, which is exactly why they become risky when used as the default path for vendors. A third party usually needs a narrow, time-bound way to reach one system or workflow, not broad reach into the internal network. The control question is therefore not “how do we let them on the VPN?” but “what is the smallest safe path to the resource they actually need?”

That distinction matters because vendor access often spans different trust boundaries, business owners, and support models than employee access. If organisations reuse the same remote-access pattern for both, they tend to inherit overbroad routing, weak session separation, and poor accountability for external activity. A tighter model makes the access decision explicit instead of letting network connectivity stand in for authorisation.

One practical way to frame this is through NIST SP 800-207 Zero Trust Architecture, which pushes access toward explicit verification and smaller trust zones, rather than implicit network reachability. That same principle is echoed in CIS Controls v8, where access control, account management, and logging are treated as operational controls, not side effects of remote connectivity.

What a safer third-party access pattern actually changes

Safer third-party access usually means the vendor connects to a brokered service, jump environment, or application-specific gateway instead of joining the broader corporate network. The vendor gets only the application, system, or administrative path required for the task, while everything else stays outside reach. This reduces the blast radius if a vendor account, token, or endpoint is compromised.

Stronger authentication is part of that design, but authentication alone is not enough. The important change is that authentication and routing are separated from blanket network trust, so each session can be constrained, logged, and revoked independently. That is why controls around session scoping, short-lived access, and explicit approval matter as much as the login method itself.

For vendors that authenticate to APIs or platform services rather than to a full desktop session, RFC 6749: The OAuth 2.0 Authorization Framework is relevant because it supports narrower delegated access patterns than shared network access. Where stronger client binding is required, RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens shows how token use can be tied to the client that received it.

How to design vendor access so monitoring and containment still work

The best designs preserve visibility at the level where decisions are actually made. If every vendor session lands inside a broad VPN segment, it becomes harder to distinguish legitimate maintenance from lateral movement, and harder to prove what an external user could reach. If instead the access path is specific to the target system, logs can show the exact resource, session, and action trail needed for review or incident response.

Organisations should also avoid credential sharing, long-lived standing access, and shared vendor accounts. Those patterns make it difficult to attribute actions, rotate access cleanly, or determine whether a credential was reused elsewhere. A dedicated account or federated identity per vendor, paired with minimum permissions and explicit expiry, gives the security team something it can actually govern.

For organisations that need a broader identity and privilege baseline, ISO/IEC 27001:2022 Information Security Management is useful because it anchors access control, authentication, and privileged access as formal controls rather than informal practices. If the environment is API-driven, OWASP ASVS provides a stronger lens for verifying authentication, session handling, and authorization boundaries than a network-only model.

Risk and Threat Considerations

When third-party access is delivered through a broad VPN, the main risk is that one approved connection can become a pathway into systems that the vendor never needed to touch. That creates unnecessary exposure to lateral movement, overreach after compromise, and weak accountability if the same access path is used by multiple suppliers or support teams.

Failure mechanism: The access layer grants network reach instead of narrowly scoped resource access, so a stolen credential, exposed token, or compromised vendor endpoint can be reused to probe adjacent systems or escalate into internal services.

Impact: A single third-party compromise can turn into broader internal access, slower detection, and a much larger containment problem because the organisation cannot easily distinguish legitimate vendor activity from abuse.

Practitioner Guidance

What to prioritise: Start by classifying every third-party use case by the specific system or workflow being supported, then decide whether it needs application access, administrative access, or temporary interactive support. Do not begin with the VPN pattern and try to fit vendors into it.

What to verify: Confirm that each vendor session is tied to a named vendor identity, a bounded target, and an expiry condition. If the access path cannot be clearly revoked, monitored, and reviewed, it is too broad for third-party use.

What practitioners underestimate: The biggest mistake is treating remote access as a connectivity problem when it is really a trust and containment problem. The right outcome is not “vendors can get in”, but “vendors can only reach what they were approved to use, and nothing else.”

Practitioner takeaway: If a third party needs more than a narrowly scoped route to a specific service, the organisation is probably granting network access where it really needs controlled delegation.

Related resources from NHI Mgmt Group

• What happens when organisations rely on VPNs and shared passwords to manage remote and third-party access?
• How should organisations tighten third-party access in environments where vendors and contractors need legitimate network access?
• How do organisations measure whether third-party remote access controls are actually working?
• How should organisations design remote desktop access for hybrid work without expanding network trust too broadly?