A buyer’s guide · Operating since 2002
A VPN grants access to a network. Once the tunnel is up, the device is inside, and it can reach whatever the network can reach. That is why a working VPN credential without multi-factor is among the most reliable ways into an organisation, and why it is priced accordingly by the people who buy such things.
Zero trust network access grants a session to one named application after checking who is asking and what they are asking from. Everything else is not merely blocked — it is never exposed. This page is about that difference, where SASE and SSE fit around it, and the cases ZTNA genuinely does not cover.
The difference
Network access versus application access
The same user, the same authentication, two architectures. What differs is what a stolen credential reaches.
Why the blast radius matters more than the tunnel
Both approaches encrypt traffic competently. That was never the difference. The difference is where the session terminates: on a network, or at an application.
A compromised VPN account gives an attacker a position inside, from which lateral movement is ordinary network activity. A compromised ZTNA account gives them one application, and the rest of the estate was never reachable to be scanned in the first place.
What this does not fix
ZTNA is only as strong as the identity behind it. A brokered session authorised by a weak credential is a well-architected path to the same compromise, so multi-factor and device posture are part of the design rather than options within it.
And it moves a dependency: the broker now sits in the path of every application session. That is a fair trade for most organisations and it is a real availability question, covered in the RFP list below.
The acronyms
ZTNA vs SSE vs SASE vs SD-WAN vs VPN
Five things quoted interchangeably that sit at different layers. Two are security, one is transport, one is a bundle of both, and one is what you already have.
Scroll the table sideways →
| Layer | What it is | What it is for | The honest limitation |
|---|---|---|---|
| ZTNAzero trust network access | Brokered access to a named application, per session, after checking identity and device. | Replacing VPN for application access, and shrinking what a stolen credential reaches. | It is one component, not an architecture. And it does not cover everything a VPN did — see the exceptions below. |
| SSEsecurity service edge | The security half delivered from the cloud: secure web gateway, CASB, ZTNA, often DLP. | Organisations that want cloud-delivered security without changing how their WAN works. | No networking component at all. If your branch connectivity is the problem, SSE does not address it. |
| SASEsecure access service edge | SSE plus the network side — usually SD-WAN — converged into one platform and contract. | Buying both halves from one vendor with one policy model and one console. | Convergence is the selling point and the lock-in. Ask what happens if you want the security half from someone else later. |
| SD-WAN | The transport layer: steering each application across the links you have. | Making branch connectivity cheaper and more resilient. | Purely transport. It creates the branch internet edge that SSE then has to secure — see SD-WAN. |
| VPNwhat you have now | An encrypted tunnel that places a remote device onto the internal network. | Simple, universal, and still the only option for some legacy and administrative cases. | Grants network access rather than application access. One stolen credential reaches whatever the network reaches. |
The distinction that saves money is SASE versus SSE. SSE is the security half alone. If branch connectivity is already solved — you have SD-WAN, or you simply do not have many branches — SSE may be the whole answer, and buying the converged product to use half of it is a common and expensive way to start.
The exceptions
Four things ZTNA does not replace
Vendors say ZTNA replaces VPN. It mostly does, and these four are where “mostly” lives — each one has ended a migration that assumed otherwise.
None of the right-hand column is an argument against ZTNA. They are the things a rollout is regularly assumed to cover, discovered later, and budgeted for twice.
Infrastructure administration
Switch, router and hypervisor management over SSH or a console, plus anything needing raw IP reachability rather than an application session. Some ZTNA products handle this; many handle it awkwardly.
Site-to-site connectivity
Joining two networks together is a different problem from giving a person access to an app. That remains a VPN or SD-WAN job, and ZTNA does not address it.
Legacy and thick-client applications
Applications using non-standard ports, dynamic ports, or peer-to-peer callbacks. Many work through ZTNA connectors and some do not, and finding out which is discovery work rather than an assumption.
Devices that cannot run an agent
Contractors, unmanaged machines, appliances and anything embedded. Agentless browser-based access covers web applications well and covers everything else poorly.
Plan to run both for a period, and treat full VPN decommissioning as an outcome rather than a dated milestone. A programme that announces a switch-off date before discovery has committed to a date it does not yet have the information to set.
Straight answers
What buyers get wrong about zero trust
A VPN grants network access; ZTNA grants application access
This is the entire difference and everything else follows from it. Once a VPN session is established the device is on the network and can reach whatever the network reaches. A ZTNA session connects one authorised user to one authorised application, and the rest of the estate is never exposed — it is not merely blocked, it is not reachable to be attacked.
This is why stolen VPN credentials are worth so much
A working VPN credential without multi-factor authentication is one of the most reliable initial-access routes there is, and it is priced accordingly in criminal markets. What makes it valuable is not the tunnel; it is that the tunnel ends inside a flat network.
“Can ZTNA replace our VPN entirely?”
Mostly, eventually, and rarely completely. Infrastructure administration, site-to-site links, some legacy thick clients and unmanaged devices are the recurring exceptions. Any vendor answering this with an unqualified yes has not yet met your legacy application.
“Is this SASE or SSE?”
SSE is the security half delivered from the cloud. SASE is SSE plus the network half, usually SD-WAN, converged into one platform. If your branch connectivity is already solved, you may only need SSE — and paying for the converged product to use half of it is a common and expensive mistake.
Zero trust is a model, not a product
No purchase makes an organisation zero trust. It is an approach — identify what needs protecting, understand how it is legitimately accessed, and permit exactly that per session — and ZTNA is one control that implements part of it. Vendors selling zero trust as a SKU are selling a component and naming it after the philosophy.
“Where is our traffic decrypted?”
Cloud-delivered inspection necessarily decrypts your traffic somewhere. Which provider, which region, which jurisdiction, and whether you can constrain it, are legitimate questions with real regulatory consequences, and they are much easier to ask before signing.
Before you sign
Ten questions for any SASE or ZTNA provider
Use these on us and on everyone else. Question ten is the one that decides whether the rollout finishes.
Which of our applications will ZTNA actually reach?
Ask for the discovery, not the claim. Web applications are straightforward. Thick clients, dynamic ports and administrative protocols are where deployments stall, and that stall happens after the contract is signed.
What stays on VPN, and for how long?
Almost every organisation ends up running both for a period, and some run both permanently. A plan that assumes complete VPN removal on a date is a plan that will slip publicly.
What is actually checked, and what happens when the check fails?
Posture is much of the value. Ask which signals are read, how often they are re-evaluated during a session, and whether failure blocks or merely warns.
Agent or agentless, and what does agentless cost us in capability?
Browser-based access is excellent for web applications and limited beyond them. Deciding this per application group is better than deciding it once for the whole estate.
Where does traffic get decrypted, and in which country?
Cloud-delivered inspection means your traffic is decrypted in someone else’s data centre. Establish which one, under which jurisdiction, and whether you can pin it.
What happens to access when the broker is unreachable?
You are placing a cloud service in the path of every application session. Ask for the availability history, the failure mode, and whether a local break-glass path exists.
How does this integrate with our identity provider and MFA?
ZTNA is only as good as the identity behind it. A brokered session authorised by a weak credential is a well-architected route to the same compromise.
If SASE, can we take the security half elsewhere later?
Convergence is the value proposition and the lock-in. Understand the cost of separating them again before signing a multi-year term.
What logs do we get, in what format, and how do we get them out?
Session and policy logs belong in your own SIEM. A platform whose logs only live in its own console is a visibility gap you are paying for.
Can we run a real pilot with a difficult application?
Piloting with a modern web app proves nothing. Insist on the awkward legacy one, because that is the application that will decide whether the rollout finishes.
Working with us
How we run this
We have run enterprise remote access since long before it was called zero trust, and we operate the centre that watches it afterwards. We are a Fortinet partner and say so — read the vendor answer above with that in mind.
Discovery before dates
We establish which applications ZTNA will actually reach before anyone commits to a VPN switch-off date. The awkward legacy application is found in week one, not month six.
Piloted on the hard case
Piloting with a modern web app proves nothing. We pilot the application most likely to fail, because that is the one that decides the programme.
Identity first
ZTNA is only as good as the credential behind it. Multi-factor and posture are part of the design, not an upsell after go-live.
Logs into your SIEM
Session and policy logs land in a platform you own, not only in a vendor console you rent.
Break-glass planned
The broker sits in the path of every session. What happens when it is unreachable is designed, documented and tested.
Questions we get asked
SASE and ZTNA, answered
What is ZTNA?
Zero trust network access brokers a connection between a user and a specific application, after verifying identity and typically some device posture, for that session only. The user is never placed on the internal network. Applications are not published to the internet, so they cannot be scanned or attacked by anyone the broker has not already authorised.
What is the difference between ZTNA and a VPN?
A VPN grants access to a network; ZTNA grants access to an application. After a VPN connects, the device sits on the internal network and can reach whatever that network reaches, which is why a stolen VPN credential is such a valuable thing for an attacker to hold. A ZTNA session reaches one application and the rest of the estate is not merely blocked but never exposed. The diagram above shows exactly that difference.
Can ZTNA fully replace our VPN?
For most user access to most applications, yes, and that is where the value is. Complete replacement is rarer than vendors suggest. The recurring exceptions are infrastructure administration over SSH or console, site-to-site network joins, some legacy and thick-client applications using dynamic or non-standard ports, and devices that cannot run an agent. Plan for running both for a period, and treat full decommissioning as an outcome rather than a milestone.
What is SASE?
Secure access service edge converges cloud-delivered security with cloud-delivered networking — broadly the security service edge plus SD-WAN — into a single platform, policy model and contract. The idea is that users and branches get consistent security wherever they connect from, without a security stack in every office.
What is the difference between SASE and SSE?
SSE is the security half only: secure web gateway, cloud access security broker, ZTNA and usually data loss prevention, delivered from the cloud. SASE is SSE plus the networking half. If your branch connectivity is already solved — you have SD-WAN, or you simply do not have many branches — then SSE may be all you need, and buying the converged product to use half of it is a common and expensive mistake.
How does SD-WAN relate to this?
SD-WAN is transport: steering traffic across the links you have. It creates the problem SASE solves, because local internet breakout at every branch means every branch becomes an internet edge that needs inspecting. They are complementary and separately purchasable, and we cover the transport side on the SD-WAN page.
Is zero trust just a marketing term?
The philosophy is genuine and predates the marketing: verify explicitly, grant least privilege, assume breach. What is marketing is any claim that a product delivers it. Zero trust is an approach to designing access, and ZTNA is one control implementing part of it. Treat “zero trust platform” on a datasheet as a category name rather than a description of what you will have after buying it.
How do you actually implement zero trust?
Start narrow and specific. Pick one thing genuinely worth protecting, establish who legitimately accesses it and how, write policy permitting exactly that, enforce it, and then monitor what the policy actually blocks. Then take the next thing. Programmes that begin with an estate-wide architecture diagram tend to produce an estate-wide architecture diagram; programmes that begin with one protected application tend to produce protected applications.
What device posture checks are worth requiring?
The ones you can act on and remediate: disk encryption enabled, endpoint protection running and current, operating system within a supported patch range, and the device being one you actually manage. Beyond that the returns fall off quickly, and every additional check is a support call from someone who cannot work until it is resolved.
Where does our traffic get decrypted?
In the provider’s cloud, wherever that is, and it is a question worth asking early. Which regions handle your traffic, whether that can be constrained, and what the jurisdictional position is all have real consequences — particularly where data residency obligations apply. It is a much easier conversation before a contract than after one.
What happens if the ZTNA broker goes down?
Access stops, which is why this deserves attention rather than a footnote. You are placing a cloud service in the path of every application session. Ask any vendor for their availability history rather than their target, what the documented failure mode is, and whether a break-glass path exists for the applications that genuinely cannot wait.
Do users need an agent installed?
It depends on the application. Agentless browser-based access works well for web applications and needs nothing installed, which makes it ideal for contractors and unmanaged devices. Agent-based access covers a much wider range of applications and protocols and gives better posture signal. Most organisations use both, decided per application group rather than once for everything.
Which platform do you deploy?
We are a Fortinet partner and deploy FortiSASE most often, particularly where Fortinet is already in the estate and the policy model can be shared with existing firewalls and SD-WAN. We also work with other platforms. As with firewalls, what your team can operate confidently usually matters more than a feature comparison — see technology partners.
How is this priced?
Per user for the security services, usually with tiers by feature set, plus any networking component if you take the converged product. The things that move the number are which SSE components you take, whether ZTNA is agent or agentless, and inspection volume. Compare quotes on identical component sets — two SASE quotes with different bundles are not comparable numbers.
Next step
Name the application you think will break
Every organisation has one — the thick client on a dynamic port, the tool the finance team refuses to give up, the machine that has to be reached over SSH. Tell us what it is along with your user count and identity provider. We will establish whether ZTNA reaches it before anyone commits to a date, because that application decides the whole programme.