VPN to zero trust network access
We move companies off remote-access VPN and onto zero trust network access, app by app. VPN logs show who reaches what. Private apps are published through Microsoft Entra Private Access or your existing ZTNA service, and access depends on identity, device health and Conditional Access. Each wave cuts more VPN reach, until the last real user is gone and the VPN goes off.
- 01Usage map
- 02Policy design
- 03Connectors and pilot
- 04Waves by app type
- 05Decommission
The story
Told without the client's name or anything that could identify them.
A professional services firm's network team ran a remote-access VPN where a contractor's session could reach domain controllers and databases, and the appliance had needed emergency patches more than once. Most users connected only to reach a few internal web apps, and VPN sign-in sat outside Conditional Access. We mapped VPN logs and flow data to see who reached which apps and protocols, then wrote access policy per app from identity, group, device compliance and risk. Connectors went in near each app and a pilot group tested web apps first. Later waves moved thick clients and file shares, the matching VPN routes came out after each one, and the appliances were retired once the last real user was gone.
why it was urgentCISA's Emergency Directive 24-01, issued 19 January 2024, ordered federal agencies to mitigate Ivanti Connect Secure VPN flaws. Then they had to disconnect affected appliances by 2 February and treat domain accounts as compromised. CISA's Zero Trust Maturity Model 2.0 points the same way, toward per-application access and away from broad tunnels.
- openA contractor's VPN session can reach domain controllers and databases.
- recurringThe VPN appliance has needed emergency patches more than once this year.
- blockedUsers connect to the VPN just to reach a handful of internal web apps.
- openConditional Access protects SaaS, but VPN sign-in sits outside it.
The estate, before and after
Before: a VPN tunnel onto a flat network
Employees and contractors connected through a VPN appliance that gave broad network reach, including domain controllers and databases. Conditional Access covered SaaS sign-ins only, so VPN access sat outside identity and device policy.
Read the diagram as text
- Employees → VPN appliance: tunnel
- Contractors → VPN appliance: tunnel
- VPN appliance → Internal web apps: network route
- VPN appliance → Thick clients and SMB shares: network route
- VPN appliance → Domain controllers, databases: flat reach
- Employees → Entra Conditional Access: SaaS sign-in
- Entra Conditional Access → SaaS apps: token
After: per-application access through Entra Private Access
Each sign-in to a private app goes through Conditional Access, checking identity, device compliance and risk. We route the traffic through Entra Private Access or the existing ZTNA service to connectors placed near each app. Admins reach servers through PAM sessions.
Read the diagram as text
- Employees → Entra Conditional Access: sign-in
- Contractors → Entra Conditional Access: sign-in
- Entra Conditional Access → Entra Private Access: per-app policy
- Entra Private Access → App connectors: app traffic
- App connectors → Internal web apps: web apps
- App connectors → Thick clients and SMB shares: thick client · SMB
- Administrators → PAM-brokered sessions: admin session
- PAM-brokered sessions → Servers: brokered session
- Break-glass path → Servers: emergency only
How we run it, phase by phase.
5 phases take you from Remote-access VPN with flat network reach to Zero trust network access per application. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Usage map
Pull VPN logs and flow data and see which users and groups actually reach which apps, ports and protocols. Then sort the apps into web, thick-client and legacy protocols like SMB and RDP, because each group moves differently.
- phase 02
Policy design
Write access policy per app, based on identity, group, device compliance and risk, in Conditional Access or your ZTNA's policy engine. Then decide which admins need PAM-brokered sessions instead.
- phase 03
Connectors and pilot
Deploy connectors near each app, publish a few web apps for a pilot group, and test sign-in, performance and support calls before widening.
- phase 04
Waves by app type
Move web apps, then thick clients and file shares, then the hard cases. Remove the matching VPN routes after each wave so reach actually shrinks.
- phase 05
Decommission
Agree exit criteria such as no active users for a set period, keep a small break-glass path if policy requires one, then retire the appliances.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Users reach applications, not the network
We published private apps through Entra Private Access or the existing ZTNA service, one policy per app, so each session reaches the app it was granted and nothing else.
- result 02
Every private app sign-in passes Conditional Access
We set policy per app to check identity, group, device compliance and risk, using the same controls that already protected SaaS sign-ins.
- result 03
Admin access goes through brokered sessions
We moved admins who need servers onto PAM-brokered sessions instead of a VPN tunnel with broad reach.
- result 04
Network reach shrank with every wave
VPN routes matching each wave were removed as it landed, and the appliances were retired against agreed exit criteria with a small break-glass path where policy required one.
Risks we plan for
-
Apps nobody knew about
Expect flow data to surface apps nobody had on a list. Find each one an owner and a policy, or the VPN can't be switched off.
-
Legacy protocols
Some older client-server apps break behind ZTNA connectors. They're tested early so the plan doesn't stall in the last wave.
-
Device posture gaps
A policy that requires compliant devices will lock out contractors on unmanaged laptops. Design them a separate path, a browser-isolated app or a virtual desktop, before the policy goes live.
-
Two tunnels at once
VPN and ZTNA clients on the same laptop can fight over routing. Test pilot devices with both installed before rollout.
Where AI helps, and where it needs guardrails
Where your ZTNA or Conditional Access tooling offers AI help with drafting policy, it can speed up turning VPN usage data into per-app rules, but every policy is reviewed by a person and tested on a pilot group before it ships. AI agents that need internal apps get their own identities and per-app access through the same policies as people, never a shared VPN account or a network-wide route.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- document01
VPN usage map by user group, application and protocol
yours to keep - guide02
Per-application access policy set
yours to keep - code03
Connector placement and pilot results
yours to keep - plan04
Wave plan with VPN route removals per wave
yours to keep - design05
Decommission criteria and break-glass design
yours to keep
Platforms and services on this move
Services involved
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Conditional access
- Rules evaluated at each sign-in that look at conditions such as user, device or location, and then allow, block or demand more proof.in context →
- 02Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
- 03Exit criteria
- Named capabilities your team must show before a partner engagement is allowed to end. Extending the landing zone would be one.in context →
- 04Zero trust
- A security model where nothing is trusted just because of where it sits. Every request gets checked against current evidence about the user, the device and the context.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Do we need to buy a new product?
Often not. If you're on Microsoft 365, Entra Private Access may already be licensed or easy to add, and plenty of firewall and SSE vendors include ZTNA. We start with what you own and only compare products if it can't cover your apps.
02How long does it take to retire the VPN?
It depends on how many apps sit behind it, how many use legacy protocols and how many unmanaged devices connect. Web apps move fast. The last few thick clients usually set the end date.
03Is zero trust a product?
No. NIST SP 800-207 treats it as principles plus an architecture. ZTNA covers one piece. Identity, device management and segmentation are others.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study2208ddb9 - 01CISA: ED 24-01, Mitigate Ivanti Connect Secure and Ivanti Policy Secure vulnerabilities (19 Jan 2024)cisa.gov ↗
- 02CISA Zero Trust Maturity Model, Version 2.0 (April 2023)cisa.gov ↗
- 03NIST SP 800-207: Zero Trust Architecturecsrc.nist.gov ↗
- 04Microsoft Entra blog: Microsoft Security Service Edge now generally availabletechcommunity.microsoft.com ↗
- 05Microsoft Learn: What is Global Secure Accesslearn.microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it