Practice
Choosing a VPN replacement and planning the migration
By the time you are evaluating a VPN replacement, picking a vendor is rarely the hard part. The specifications are readable and the comparison tables all say roughly the same thing. What nobody answers is the layer underneath: the current VPN carries several hundred accounts, a dozen contractors and one server nobody is willing to touch, and all of it has to move without going dark.
This article is not an architecture comparison — that is covered in comparing traditional VPN, gateway-based ZTNA and SDP. What follows is the path after the decision has been made: inventory, parallel running, batching, verification, and finally the point at which that inbound port can actually be closed.
When a VPN replacement is worth putting on this year’s plan
Three signals. Any one of them is enough.
Patching cannot keep up with disclosure. For remote access appliances, the window between an advisory and mass exploitation is now measured in days. Count the remote-access entries in the CISA Known Exploited Vulnerabilities catalog: what these products have in common is that they must keep a port open to the entire internet, which makes every disclosure an emergency.
The permission model no longer matches the shape of the organisation. A VPN grants reachability to a network segment. Once the user population expands from employees to consultants, resellers, equipment maintenance vendors and short-term project staff, you start patching authorisation with firewall rules — and the rule count grows past the point where anyone can say who asked for a given line.
Customers have started asking. Nearly every vendor security questionnaire has a field on how remote access is controlled and how third-party connections are isolated — and how easy that field is to answer is decided by the architecture, not by the wording.
The four inventories to complete before anything moves
Without these four lists, a migration stalls in week three and starts over.
| Inventory | What it has to establish | The usual surprise |
|---|---|---|
| Identity | Who actually connects, how often | Dormant accounts, shared credentials |
| Services | Which addresses and ports see traffic | Daily use by something undocumented |
| Endpoints | Company-managed, BYOD, or vendor-owned | Vendor laptops you do not control |
| Legacy | Whether anything can be installed | Contracts forbidding changes to devices |
Two practical notes. First, the service inventory has to be per service, not per segment: writing down “finance segment” is not an inventory, whereas “this port on this host, used by these five people” is. Second, build it from connection logs rather than from a survey. A survey returns the usage people remember; only the logs contain shadow IT.
These four lists are also the precondition for least privilege to mean anything. Without them, a new architecture simply reproduces the old over-broad grants.
Why a single cutover is not an option, and how to run the parallel period
Nobody can afford to switch the VPN off on a Monday morning. The workable approach is parallel running: the VPN stays as it is while the new architecture carries one small group of users to one small group of services, with both paths live for a bounded period.
Parallel running has a cost that has to be stated plainly: during this window the attack surface is larger, because both paths are reachable. Parallel running is therefore a transition, not a steady state. Three things get written down before it starts.
- Exit criteria. What has to be true before the inbound VPN port closes — for example, the first three batches migrated and two consecutive weeks with nobody falling back.
- A schedule in weeks, not quarters. A parallel period running past one quarter usually means the exit criteria were written too vaguely.
- A rollback path. Every batch must be reversible on the same day, and the reversal has to have been rehearsed once.
- VPN inbound port still open
- Batches moved to the new path
- Parallel period and exit criteria
Text version of this diagram
Two paths on one time axis: the existing VPN on top, the new path below, and in the middle the period when both are reachable.
Top lane — the existing VPN
- The inbound port is open from the start of the axis; this stretch is drawn in red.
- The red runs all the way to the exit point, meaning VPN exposure is not reduced at all during the overlap.
- After the exit point it becomes a dim dashed line with a cross on it: the port is closed and the service no longer answers.
Bottom lane — the new path
- It starts later than the VPN and advances in three marked batches: batch one with 5–20 users, then batches two and three.
- Each batch has a rollback arrow pointing back at the VPN lane, labelled "every batch reversible same day".
- The new lane continues past the exit point, as the only path left.
The box in the middle — the parallel period
- The box runs from just before batch one to the exit point, titled "parallel period: both paths reachable, attack surface temporarily larger".
- The exit point states a condition rather than a date: "exit criteria met → close the inbound VPN port".
- The axis is explicitly labelled in weeks, not quarters.
One more check: if the existing VPN uses split tunnelling, client-side routing and DNS behaviour will fight the new path. This is the single largest source of support tickets during the parallel period.
Which services belong in the first batch
The purpose of the first batch is not to protect the highest-risk asset. It is to run the whole process once at the lowest possible cost: issue the grants, deploy to endpoints, hit a problem, roll back, fix it. So the selection criterion is representative but survivable.
| Good first batch | Bad first batch |
|---|---|
| 5–20 users you can contact directly | A core system the whole company uses |
| Simple protocols (HTTP, RDP, SSH) | Multi-port, dynamic-port, broadcast-dependent |
| A named business owner | Nobody can say who uses it |
| An hour of downtime is survivable | An outage means notifying customers |
A common mistake is choosing something nobody uses. Nothing breaks, but nothing is learned either, and two weeks later the services that matter still have no precedent to follow.
- Where the first batch comes from
- Later batches
- Teaches nothing, or inventory unfinished
Text version of this diagram
A four-quadrant grid: the vertical axis is how heavily a service is used (daily versus barely), the horizontal axis is the cost of downtime (an hour is fine versus an outage means notifying customers).
Top left — used daily, downtime survivable
- Labelled "pick the first batch here".
- The whole process runs once, and mistakes are recoverable.
Top right — used daily, cannot stop
- Labelled "leave for batch two or three".
- High value and high risk; earn the experience on earlier batches first.
Bottom left — barely used, downtime survivable
- Labelled "looks safe, teaches nothing".
- Nothing breaks, but nothing useful is learned either — the most common wrong choice.
Bottom right — barely used, cannot stop
- Labelled "check whether it is still needed".
- Unused but undroppable usually means the inventory is unfinished.
On sequencing, the CISA Zero Trust Maturity Model splits the work into five pillars — identity, devices, networks, applications, data — with maturity stages for each, which makes it a usable way to decide which pillar to advance next. For a fuller implementation record, NIST SP 1800-35 documents laboratory builds of several zero trust architectures, configurations and problems included.
What to do about systems that cannot run an agent
Every migration meets the same set of things: printers, NAS boxes, industrial control hosts on the shop floor, medical devices whose contracts forbid modification, and an old Windows server that still runs but has no owner.
The workable answer is to cover them with a separate node: the node sits in front of the system and makes only outbound connections, while the system itself is untouched, uninstrumented and unreconfigured. This is the standard way software-defined perimeter (SDP) architectures handle legacy estates in practice; Merak’s node mode works this way, and the mechanism is described in how a zero trust network actually works.
- Authorised access
- Outbound connection from the node
- Still flat behind the node
Text version of this diagram
Covering a system that cannot run an agent with a node, and what that cover does not solve.
What is protected
- An authorised user opens one connection to the node, labelled "authorised access".
- The node only dials outbound to the control plane, which makes the authorisation decision; it opens no inbound port.
- Behind the node sits the system that cannot run an agent — a PLC or NAS — untouched and unmodified.
What is not
- The area behind the node is enclosed in a dashed red box titled "the segment behind the node is still flat".
- Inside it, alongside the protected system, are another host on the segment and another legacy device.
- Dashed red arrows connect the protected system to both: lateral movement here is unaffected by the node.
- The conclusion: a node makes an unmodifiable system protectable; it does not isolate what sits behind it.
The limit has to be equally explicit: the segment behind the node is still flat. Authorisation granularity stops at “who may reach this service behind this node”, and if other hosts sit between the node and the protected system, lateral movement between them does not disappear because a node was installed. Systems in this category belong on a medium-term replacement or isolation plan as well, not just behind a cover.
How to verify the old path is really gone
“It does not answer a scan” is the first check, not the conclusion. A batch is done when all four are done.
- Scan from an external network. Scanning from the office LAN tests the firewall, not the exposure. Run the port scan from a genuinely external address and confirm the old service endpoint no longer responds.
- Look for residue. DNS records, certificate transparency logs and cloud load balancer configurations tend to retain old hostnames, and scanners find them.
- Test authorisation, not just reachability. Connect with an identity that should have no grant. The expected result is no response at all, rather than a refusal and a failed-login line in a log.
- Hunt for the bypass. Jump hosts, a VPN a vendor set up for themselves, a cloud security group rule left open — one bypass makes the first three checks meaningless.
The fourth is the one worth outsourcing, because finding a bypass takes an attacker’s perspective rather than an architecture diagram. That is exactly the scoping question in red team versus penetration testing.
The failure modes worth naming in advance
The gateway changed, the permission model did not. Replacing a VPN with a different public gateway while still granting access by segment leaves the reachable blast radius untouched. The test is simple: ask how many services one stolen account can reach. If the answer matches the pre-migration answer, nothing was migrated.
Grants issued by department instead of by service. “Sales can reach CRM and the file server” becomes “sales can reach fourteen services” within a quarter, because cloning an existing group is the cheapest way to onboard a new service.
No exit criteria, so the VPN stays forever. Two systems running side by side for two years: double the cost, no reduction in attack surface. This is the most common outcome of all.
No availability design for the control plane. Authorisation decisions depend on the control plane, which puts it on the critical path. Establish what happens to established and to new connections when it is unavailable, and plan for it as a single point of failure.
Monitoring blind spots left unaddressed. Once traffic is encrypted point to point, detection that relied on mirroring at the gateway cannot see inside it. The replacement is to move detection to endpoints and authorisation logs — planned alongside the migration, not bolted on afterwards.
Terms and further reading
| Term | In one sentence | Source |
|---|---|---|
| Known Exploited Vulnerabilities | Vulnerabilities confirmed as exploited in the wild | CISA KEV |
| Shadow IT | Systems in use without IT approval | Shadow IT |
| Least privilege | Granting only the access a task requires | Principle of least privilege |
| Split tunnelling | Sending only some traffic through the VPN | Split tunneling |
| Zero trust architecture | Trust not derived from network location | What zero trust architecture is |
| Zero Trust Maturity Model | Five pillars with staged maturity levels | CISA ZTMM |
| Zero trust implementation guide | Laboratory builds of several architectures | NIST SP 1800-35 |
| Software-defined perimeter | Access architecture separating the two planes | CSA SDP specification v2 |
| Lateral movement | Spreading from one internal host to the next | MITRE ATT&CK TA0008 |
| Port scan | Probing which ports on an address respond | Port scanner |
| Single point of failure | One component whose failure stops everything | Single point of failure |
The difficulty in a VPN replacement is almost never the technology choice; it is the completeness of the inventory and the clarity of the exit criteria. If you would like the migration sequence assessed against an existing environment, or the resulting exposure checked from the outside, get in touch — or start with the Merak platform architecture.