VPN vs ZTNA
ZTNA vs VPN: what actually changes on day one?
Four things: latency, the login experience, how access is granted, and how much of your network is reachable from the internet. Skip the theory. Here is what zero trust remote access changes in practice, day one after cutover.
Four things your users and IT team feel immediately
The structural shift is from network-segment access to per-application, continuously-verified access.
| Dimension | With a VPN | With ZTNA |
|---|---|---|
| Latency | Backhauls traffic to one concentrator: Singapore users routed via Frankfurt. | Anycast edge routes to the nearest of 330+ cities |
| User experience | Login once, broad access all session; manual reconnect after sleep or Wi-Fi handoff. | WARP runs in the background, verifies continuously, no reconnect |
| Access management | Granted per network segment: “sales gets subnet X.” | Per app, per user, per device posture: one app, nothing else |
| Attack surface | Public IP accepts inbound: shows up in Shodan scans and CVE advisories every year. | Outbound-only tunnel, no inbound port, app invisible without a session |
Why the per-app model is the real shift
- A VPN puts an authenticated user on a network segment, not a single app: if the account is compromised, the attacker gets a map, not just a foothold.
- Per-app policy makes access reviews possible: you stop managing subnets and start managing who reaches what, and you finally find the twelve people with access to a finance server nobody remembers granting.
- Per-app tunnels don't share a failure domain: one broken app doesn't take down access to the other forty, unlike a single VPN concentrator that fails badly, all at once, for everyone.
This sits inside a broader SASE and Zero Trust architecture: identity-driven policy, secure edge and continuous verification working as one plane, not four bolt-on tools. The same identity groups that gate application access can drive data loss prevention policy too, controlling not just who reaches an app but what data can leave it. Pair it with continuous DDoS protection to defend the network layer the same way. Regulated teams get a second benefit from the same mechanism: per-app policy and continuous access reviews produce the access-control evidence a NIS2 audit asks for, instead of a subnet diagram.
Who it's for
Who needs ZTNA, and for which access problem?
Contractors, unmanaged devices, mergers and legacy non-HTTP applications, mostly. ZTNA earns its keep where a VPN is structurally the wrong tool, not everywhere someone works remotely. These four account for most of the migrations we run.
01
Contractors and third-party access
External teams need one application for the length of an engagement, not a subnet for as long as nobody revokes it. Per-app grants expire with the project, and the review that follows reads as a list of applications rather than a list of network ranges.
02
BYOD and unmanaged devices
Device posture becomes a policy input instead of a trust assumption: patch level, disk encryption and MDM enrollment are checked per request. A personal laptop can reach the wiki and nothing else, without an agent-heavy lockdown.
03
Mergers and acquisitions
Two networks that were never meant to route to each other, and a deadline. ZTNA publishes the handful of applications each side actually needs without joining the networks, which is a fraction of the work of a routed interconnect.
04
Legacy and non-HTTP applications
An ERP module, a SCADA interface, a proprietary-TCP finance app. These are the applications that keep a VPN alive long after everything else has moved, and the reason the hybrid pattern below exists.
If none of these describe your environment, secure remote access over a VPN may still be adequate and the migration can wait. The argument gets strong when standing access, device diversity and non-HTTP applications are all in play at once.
The architecture
Which ZTNA architecture should you choose?
Service-initiated for web apps behind NAT, endpoint-initiated for RDP, SSH and legacy TCP. Everything else is a variant of those two. Secure remote access solutions come down to two patterns that cover almost every real deployment, plus identity and one hybrid case. Picking wrong means re-architecting six months in.
01
Service-initiated (connector)
A lightweight connector behind your app opens an outbound-only tunnel to the edge: no public IP, no inbound rule. Cloudflare's cloudflared is the reference. The right default for self-hosted web apps and internal tools behind NAT.
02
Endpoint-initiated (client)
A client agent builds an encrypted WireGuard tunnel from the device before any app traffic flows. Cloudflare WARP is this piece, the model you need for RDP, SSH and legacy TCP/UDP apps never built for a browser.
03
Identity integration
Neither pattern replaces your IdP, they sit in front of it. Cloudflare Access federates with Okta, Entra ID or Google Workspace and adds device posture as a second signal. Clean IdP groups make this fast; fix messy ones first.
04
The hybrid: legacy, non-HTTP apps
Every environment has one: an ERP module, a SCADA interface, a proprietary-TCP finance app. WARP-to-Tunnel handles it: endpoint client for transport, cloudflared for the private side, Access policy on top. Still zero trust, no VPN fallback.
05
What to ask a ZTNA provider
Whether you shortlist ZTNA vendors or run it in-house, four questions separate a product from an operated service: who writes and maintains the policies? who triages an anomalous access attempt at 2am? how are legacy non-HTTP applications handled? and what happens to the VPN during the parallel run? Most ZTNA providers answer the first and stop there.
The readiness audit
What do you audit before a ZTNA rollout? Apps and users first.
Four things: which apps each group really uses, which of them speak HTTP, who holds standing access, and your device posture baseline. The biggest cause of a botched migration isn't the technology, it's starting without knowing what you have. Before writing a single Access policy, get answers to these:
What apps does each group actually use?
Not what the org chart implies, what people log into day to day. VPN logs rarely show this cleanly, since most configs grant subnet-wide access regardless of real usage.
Which apps are HTTP, and which aren't?
This decides whether an app needs Access (browser-based) or a WARP+Tunnel hybrid (legacy protocol). Get it wrong and you re-architect mid-rollout.
Who has standing access that shouldn't?
Contractors from a project that ended in 2023. Former staff whose VPN account never got revoked. This audit alone usually makes the argument for the whole migration.
What's your device posture baseline?
Managed vs BYOD, patch levels, whether MDM is even enrolled: ZTNA policy needs this as an input, not an afterthought.
Get these answers before writing a single policy: our team runs this app-and-access audit with you and hands back a prioritized rollout plan instead of a blank page. It's the fastest way to know what a realistic migration looks like for your environment.
The migration
How do you migrate from VPN to ZTNA without breaking user access?
In phases: by user group first, by application second, with the VPN running in parallel for 60 to 90 days. A VPN replacement is a change-management project before it is a networking one. Cutting an org from VPN to ZTNA in one weekend is how the helpdesk drowns by Monday 9am. Phased beats big-bang, every time we've run it.
Step 1
Sequence by group, not app
Start with a low-risk, high-tolerance group: IT itself, or a team comfortable with new tooling. Not the executive team, not finance, not anyone who'll escalate loudly if week one is slightly off.
Step 2
Then by app within the group
Move the simplest access patterns first, internal wikis, low-sensitivity dashboards, before anything tied to production systems or financial data.
Step 3
Run VPN and ZTNA in parallel
Don't decommission the VPN the day ZTNA goes live. Most successful migrations keep both for 60 to 90 days: a fallback for latecomers and breathing room to fix policy gaps in the field, not in a war room.
Step 4
Communicate the change, not just the tool
Users notice ZTNA even when it works perfectly: no more “connect to VPN” every morning. Tell them why before they ask, and give them a named channel for anything that breaks.
Step 5
Set a hard decommission date on metrics
Track adoption, device enrollment and migration-tied ticket volume. When tickets drop to baseline and adoption clears roughly 90%, that's your signal to retire the concentrator, not a date picked in advance on a project plan.
A phased rollout only works if someone owns it past go-live, which is why we run ZTNA as a managed service, not a one-time policy configuration.
The managed service
How does Brixio operate ZTNA day-to-day? 24/7 SOC, continuous access reviews.
We run ZTNA as a managed service, not a one-time policy configuration. In practice, that means:
Policies built per client
- Zero Trust policies tuned to actual app usage and identity structure
- Not a generic template applied to every environment we touch
- Maintained as your apps and groups change, not set once
24/7 SOC, follow-the-sun
- Monitoring across Luxembourg, Paris, Dubai and Singapore
- An anomalous 2am access attempt is triaged live in another region
- No alert waits for the next business day
Continuous access reviews
- Stale grants, orphaned contractor accounts and posture drift caught on a standing cadence
- Not an annual audit
- A recurring review of who can reach what, not a one-time cleanup
Identity & posture kept current
- New groups, offboarded staff and managed-device enrollments flow into policy
- No manual re-sync as your IdP structure changes
- Incident response tied straight into policy enforcement and the SOC workflow
Every user and app connects through the Cloudflare One edge, verified by identity and device posture per request, with Brixio operating and tuning policy 24/7 on Brixio One.
This runs on Brixio's standing security posture
Cloudflare
Authorized Service Delivery Partner (ASDP)
ISO 27001:2022
certified data handling
400+
delivered projects across EMEA & APAC
4 hubs
Luxembourg · Paris · Dubai · Singapore, follow-the-sun
This runs on top of Brixio's standing posture as a Cloudflare ASDP. The same follow-the-sun team runs our managed SOC on Cloudflare, which is where an anomalous access attempt gets triaged rather than queued. Talk to an expert to size a VPN-to-ZTNA migration against your own apps and identity structure.