What Is VPN?

A VPN creates an encrypted tunnel between a device and a network, extending that network to the remote user. It solved the remote access problem of its era well, and the assumption underneath it — that being on the network implies trust — is precisely the assumption modern architectures reject.

The practical consequence is that a compromised device with VPN access is inside, with whatever reachability the network offers.

The structural weaknesses

Access is granted at network level rather than per application, so a user who needs one internal system receives reachability to everything on that segment. Full-tunnel configurations route all traffic through the corporate network, creating a performance and capacity problem that pushed many organisations to split tunnelling — which then bypasses corporate inspection for most traffic.

The concentrator is also a single point of failure and a high-value target. Vulnerabilities in remote access appliances have repeatedly been exploited at scale, precisely because compromising one yields network access to an entire organisation.

What still argues for it

Site-to-site connectivity between locations remains a legitimate and well-suited use. Legacy applications that require network-level reachability and cannot be published individually may leave no alternative. And for organisations without the identity maturity to operate per-application access, a well-configured VPN with strong authentication is considerably better than nothing.

Where it is retained, the improvements that matter are phishing-resistant multi-factor authentication, device posture checking before connection, and segmenting what the VPN can reach rather than landing users on a flat internal network.

Split tunnelling is a decision, not a default

Full tunnelling routes everything through the corporate network, preserving inspection and consuming bandwidth. Split tunnelling sends only corporate traffic through the tunnel, improving performance and removing most traffic from any corporate inspection.

Neither is universally right. What matters is that the choice is deliberate and its consequences are covered: if split tunnelling is used, the endpoint needs its own web filtering and DNS controls, because the network ones no longer apply.

The failure is choosing split tunnelling for performance during a capacity crisis and never revisiting the security assumptions that the previous design depended on.

Capacity planning is the operational lesson of recent years. Concentrators sized for a minority of staff working remotely became the constraint when that became the majority, and the responses under pressure — split tunnelling, relaxed inspection, temporary exemptions — were security decisions made for availability reasons. Planning for a sustained peak avoids making those choices in a hurry.

A common mistake worth avoiding

Whatever else is on the list, the answer worth establishing first is what a connected user can reach beyond the systems they actually need. It is a question that can be settled in a day, it requires no procurement, and the answer determines whether the rest of the programme is addressing the largest exposure or a smaller one that happened to be easier to see.

Where to start

Establish what a VPN-connected user can actually reach. In most organisations the answer is far more than their role requires, and narrowing it is achievable without replacing the technology.

See zero trust network access for the alternative model, and secure remote work. GuardsArm runs security program reviews.