Your VPN was designed for a world where the office was the perimeter and remote work was the exception. One tunnel, one login, and the laptop is on the corporate network as if it were plugged into a socket in the building. That model made sense. It does not survive laptops in living rooms, contractors on unmanaged devices, and stolen session tokens.
Zero trust gets sold as a product purchase. It is not. It is a redesign of who reaches what, and the hard part is discovering how many things on your network have never had an access rule written for them. Here is how to sequence it so remote work does not break on day one.
Flat VPN access is the liability, not the VPN itself
The VPN is fine as a transport. The problem is what happens once the tunnel is up: the connected device gets broad network reach, so one compromised laptop or one stolen credential yields the same access as sitting in the office. Attackers do not break the VPN, they log into it.
In practice: an infostealer on a contractor machine harvests the saved VPN credential and the browser session tokens. The attacker connects, passes whatever multifactor exists, and can now see file servers, the ERP, the hypervisor console and the backup server. Lateral movement is just normal network usage.
Two problems compound it:
- ▸The VPN appliance is itself an exposed edge device. That is its job, which puts it in the class of internet-facing appliances that get mass scanned and mass exploited, tracked in the CISA Known Exploited Vulnerabilities catalogue.
- ▸Access is granted at connect time and never re-evaluated. Device health, user risk and location are checked once, if at all, then the session runs for hours.
The goal is not to remove remote access. It is to stop granting network reach as a proxy for application access.
What zero trust actually requires
Zero trust means no implicit trust based on network location. Every request is authenticated, authorised and evaluated against current context, then granted the minimum access needed. It is an architecture, not a product, and the authoritative description is NIST SP 800-207 Zero Trust Architecture.
Stripped of vendor language it needs four things, most of which you part own:
- ▸A single strong identity source. One directory of record for humans and machines, with groups that reflect real job function rather than years of exceptions.
- ▸Device signals you trust. You need to know whether the requesting device is managed, patched and healthy, and that must influence the decision.
- ▸A policy decision point in front of resources. Something between user and application that weighs identity, device and context, then issues short lived access to that application, not a network.
- ▸Logging that ties requests to identities. If you cannot answer who reached what, you do not have zero trust, you have a new login page.
Zero trust is compatible with legacy systems, which is why it is a good first modernisation step even when the applications cannot be replaced yet.
The inventory you need before touching anything
You cannot write access policy for systems you have not listed. Before any migration, build a table of every internal application, who genuinely needs it, how it authenticates today, and whether it can speak to your identity provider. Two weeks of unglamorous work saves six months of failed rollout. Record for each:
- ▸The business owner, a named person, not a department.
- ▸The user groups that need it, with a realistic count, and whether contractors are included.
- ▸How it authenticates now: modern single sign on, directory integration, a local password database, or nothing at all because it trusts the network.
- ▸What it talks to, especially databases, file shares and other internal services.
- ▸Whether it is still supported, because an end of life application that cannot take modern authentication is a replacement decision, not a policy one.
That last row is where the honest conversation happens: some systems will not survive the audit, and the answer there is a migration project, not a wrapper. If several are rented platforms you have outgrown, Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software covers planning that without disruption.
Phase one: fix identity and device trust, change no networking
Start where leverage is highest and the risk of breaking remote work is zero. Consolidate identity, enforce phishing-resistant multifactor, and get device management onto every machine touching company data. The VPN stays exactly as it is, and nobody outside IT notices.
1. Consolidate directories. One identity provider, every application that can federate pointed at it, local password databases retired wherever possible. 2. Roll out phishing-resistant multifactor, administrators first. Push approvals and SMS codes are defeated by proxy phishing and fatigue techniques now in commodity use, and the CISA guidance on implementing phishing-resistant MFA explains why a bound credential differs in kind. 3. Enrol devices in management so you can prove patch level, disk encryption and endpoint protection at request time. 4. Clean up groups and privileged accounts. Remove standing administrative rights, kill shared accounts, expire vendor access. 5. Shorten session lifetimes on anything privileged and require reauthentication for sensitive actions.
Phase one alone removes a large share of real attack paths, because credential theft and session replay stop being sufficient. It is also the phase most organisations skip, then wonder why their expensive broker only checks a password.
Phase two: move applications behind a broker, one at a time
Now put a policy decision point in front of individual applications so users reach the app, never the network. Migrate one low risk internal application first, in a pilot group, with the VPN still there as fallback. Then repeat. This is a queue, not a cutover.
Pick a pilot with moderate usage, a tolerant user group and an owner who answers the phone. Run both paths in parallel for a few weeks, then work the queue in this order:
- ▸Web applications that already federate, because they are nearly free to onboard.
- ▸Web applications with legacy authentication, wrapped by the broker so the application itself does not change.
- ▸Administrative interfaces for hypervisors, backup consoles and network gear, which deserve the strictest policies and should never be reachable from a staff subnet.
- ▸Non web protocols such as remote desktop, SSH and database clients, which brokers handle but which need testing.
- ▸Third party and contractor access, moved off the VPN entirely so external parties get one application and nothing else.
Every application you move is one fewer reason to be on the flat network. Track the queue publicly, because this phase runs for months and invisible progress gets cut.
Phase three: starve the VPN down to a stump
The VPN does not get switched off, it gets starved. As applications move behind the broker, remove the routes no longer needed until the tunnel reaches almost nothing. What remains is a break glass path for the few legacy systems that cannot be brokered yet.
1. Remove routes, not users. Each time an application is fully brokered, delete its subnet from the VPN routing table. Users keep working, reach quietly shrinks. 2. Split the remaining population. Most staff should end up with no VPN profile, leaving a small engineering and operations group. 3. Harden what is left: phishing-resistant MFA, managed devices only, tight session limits, full logging. 4. Put the appliance on an emergency patch path, since it stays exposed and stays a target. 5. Set a decommission date for the last legacy systems behind it, owned as a budget line rather than a permanent exception.
That stump is the honest measure of your legacy debt. If it never shrinks, the blocker is not network design, it is applications nobody wants to fund replacing.
What breaks, and how to keep remote work running
Things break predictably: hard coded internal addresses, applications that expect a specific source IP, printing, file shares, and anything that authenticates against the network rather than a user. None of it surprises you if you tested, and all of it is survivable while the VPN fallback exists.
- ▸Never cut over without a fallback. Run both paths in parallel per application, not per organisation.
- ▸Pilot with real users doing real work, not the IT team on a test account.
- ▸Expect the source IP problem. Vendors that allowlist your office address need a defined egress point. Solve it before, not during.
- ▸Keep the rollback documented and test it once, so a bad policy push does not become an outage.
The discipline that makes a website migration boring makes an access migration boring, the same habits described in Leaving WordPress: A Migration Playbook That Does Not Lose Your SEO, applied to infrastructure instead of content.
What this costs, and what it buys
Budget for people and sequencing, not licences. The phase one identity and device work is largely configuration on tools you already pay for, and the broker is a running cost. The real spend is discovery, policy design, and the legacy applications the audit exposes.
What you get back is measurable. Blast radius drops, because a stolen credential reaches one application instead of a network. Contractor access stops being a permanent hole. Audit questions become answerable, since decisions are logged per request, which matters if you fall in scope of the EU NIS2 Directive. Mapping the programme onto the NIST Cybersecurity Framework also gives your board a vocabulary for progress that is not vendor specific.
Remote work gets faster too, once users stop routing everything through a saturated tunnel. For the layers around this, see The Small Business Website Security Checklist for 2026.
How TuniCyberLabs helps
We run the discovery, design the access policies, and phase the migration so remote work keeps functioning throughout, then deal with the legacy applications the audit exposes: rebuilt, wrapped or retired, each with a date attached. We are registered in Estonia, our engineers are in Tunisia, and we serve the EU and North Africa.
Still granting network access when you meant to grant application access? See how we approach infrastructure modernisation.