The ZTNA and SSE buyer's guide
For most companies this purchase starts with a specific irritation: the VPN. It is slow, everyone is on it from everywhere now, it gives whoever connects a wide view of the internal network, and it keeps showing up in the news as the thing attackers exploited to get in and launch ransomware. At some point a CTO decides the VPN's time is up, goes looking for what replaces it, and falls into a thicket of three-letter acronyms: ZTNA, SSE, SASE, SWG, CASB, FWaaS. The thicket is the main reason this decision is harder than it should be.
Cut through it and the core idea is simple. Instead of putting someone on the network and trusting them because they are inside, you grant access to specific applications based on who they are and what device they are on, and they never get the network, just the app they are entitled to. That is zero trust network access, ZTNA, and it is the actual replacement for the VPN. Everything else, the secure web gateway, the cloud access controls, the firewall-as-a-service, is additional security that vendors increasingly bundle around ZTNA and sell as a platform called SSE, or wrap with networking and call SASE. So the real question is how much of the bundle you actually need.
- ZTNA grants access to a specific application based on who you are and what device you are on, without putting you on the network; it is the actual replacement for the VPN.
- SSE is the bundle around ZTNA (adding a secure web gateway and cloud access controls), and SASE adds the networking layer; you can buy just ZTNA, and many companies should start there.
- The most common mistake is buying the platform when you needed the point: a painful VPN and a mostly cloud workforce often needs ZTNA alone, not a sprawling SSE or SASE suite.
- The agent assumption catches buyers out: if a chunk of your access is from contractors and unmanaged devices, agentless or browser-based access becomes a primary requirement.
- For a European company, where the provider's points of presence sit and whether traffic and data stay in the EU is both a performance and a compliance question.
- The prerequisite under every decision is that you cannot design access you cannot see, so map what people actually need to reach, from what devices, and where your apps live before you shop.
what these things actually are
The acronyms hide simple ideas. ZTNA gives a user access to a specific application, after checking their identity and the security state of their device, without putting them on the network: if they are entitled to the finance app they reach the finance app and nothing else is even visible, and the security upside is large because a compromised user or device cannot roam an internal network that is not there to roam. SWG, a secure web gateway, inspects and filters web traffic going out, blocking malicious sites and enforcing acceptable-use policy. CASB, a cloud access security broker, gives visibility and control over the SaaS apps people use, overlapping with SaaS governance. FWaaS, firewall-as-a-service, delivers firewall capability from the cloud rather than a box in your office. SSE, security service edge, is the bundle: ZTNA plus SWG plus CASB and often more, delivered together from the cloud. SASE is SSE plus the networking layer, SD-WAN, converging security and wide-area network into one cloud-delivered thing, which pulls in the networking team. The pattern to hold onto: ZTNA is the access decision, SSE is the security bundle around it, SASE adds the network, and you can buy just the first.
where buyers go wrong
The first mistake is thinking ZTNA means zero trust is done. ZTNA is one expression of zero trust, the network-access part, and a valuable one, but it does not cover identity governance, SaaS sprawl, machine identities, or data, so buying it and declaring zero trust achieved leaves most of the model unbuilt. The second is buying the platform when you needed the point: the pressure to purchase a full SSE or SASE suite is intense because that is what vendors want to sell, but if your actual problem is a painful VPN and a mostly cloud workforce, ZTNA alone may be the right scope. The third is the agent assumption: many ZTNA tools need a piece of software on the user's device, which is fine for employees on managed laptops and a problem for contractors and partners on devices you do not control, so if a chunk of your access is from unmanaged devices, agentless or browser-based access becomes a primary requirement. The fourth is ignoring performance and where the vendor's infrastructure sits, because ZTNA and SSE route traffic through the provider's points of presence, and if those are far from your users everything feels slow, which for a European company is both a performance and a compliance question. The fifth, quieter mistake is not deciding who owns this, because ZTNA and especially SASE sit on the seam between security and networking, and a purchase nobody clearly owns tends to stall. Under all of them is the prerequisite: you cannot design access you cannot see.
before you shop: map your access
Start with what people actually need to reach. List the applications that currently require remote access, where they live (your own data center, a cloud you run, or SaaS), and who needs them; the mix matters, because a company whose apps are all SaaS has a much lighter problem than one with critical applications in an on-premises data center the VPN was reaching. Then characterize the access: how much is employees on managed laptops, and how much is contractors, partners, and people on unmanaged or personal devices, because that ratio drives the agent-versus-agentless question more than anything else. Then be honest about scope: a VPN replacement is a focused project, while a broader move to converge security and networking is a multi-year platform commitment that touches the network team, and conflating the two is how companies end up over-buying.
what's right for your size and situation
For a lean or small company under about 50 people, if your apps are mostly SaaS you may need very little: single sign-on plus conditional access covers a lot, a focused ZTNA handles the few private apps, and your IdP or cloud may already include an app proxy; skip a full SSE or SASE platform, which is far more than the problem. For a growing mid-market of 50 to 500, ZTNA to replace the VPN for private-app access, identity-and-device based, with agentless options for contractors, plus a secure web gateway or cloud controls only where you have a specific need; skip buying the whole bundle to solve a VPN problem. For a larger or multi-entity company of 500 to 2000, an SSE platform starts to make sense if you genuinely need converged web, cloud, and private-app security with device posture feeding access decisions; skip letting bundle creep add modules you will not operate. For an enterprise or multi-site business above 2000, full SASE may be justified when converging security and networking across many sites and a global workforce; skip a platform whose points of presence leave a chunk of users with poor performance.
A few situations change the answer regardless of size. Heavy contractor and third-party access: ZTNA is genuinely excellent here, giving an outside party access to one application based on identity and device without a VPN, so weight agentless ZTNA heavily. Mostly SaaS, cloud-only: you may need very little ZTNA, and single sign-on and conditional access do most of the work. Significant on-premises apps: ZTNA's ability to publish them securely is the core of the value, and you want to test exactly those apps in any trial. Branch offices and a distributed network: this is where SASE's networking convergence earns its keep and the conversation legitimately widens into the network team's world.
sourcing: four ways to get there
Use what your IdP and cloud include: for a SaaS-heavy company, single sign-on plus conditional access, and an app proxy your IdP or cloud may already offer, can cover a surprising amount without a dedicated ZTNA product, so check this first. Buy focused ZTNA: the right scope for many companies, replacing the VPN, publishing private apps securely, supporting agentless access for contractors, and stopping there until there is a reason to add more; this is often the highest-value, lowest-regret move. Buy an SSE platform: justified when you genuinely need converged private-app, web, and cloud security in one place and have the team to run it. Go to SASE, or bring in help: full SASE is a larger commitment best made with the network team and often with outside help, and a co-managed or advisor-led rollout through an MSSP or VAR also fits the common case of replacing a VPN cleanly without locking people out mid-transition.
the decision criteria that actually matter
App coverage: does it handle all your apps, web and non-web, modern and legacy, SaaS and the ones in your own data center, tested against your hardest app rather than the easy one? Agentless access: can it give access from unmanaged and personal devices through the browser, or does it only do agents? Identity and device integration: does it tie access cleanly to your identity provider and read device security posture? Performance and points of presence: where is the provider's infrastructure, and will your users, especially in Europe, get good performance rather than VPN-grade lag? Bundle fit: are you buying only what you need or a platform whose extra modules you will actually use? VPN migration: how does the tool support a staged retirement without a disruptive cutover? Data residency and EU: does traffic and metadata stay in the EU? Ownership and operation: is it clear who runs this and does it fit that team? If you take one row, take app coverage tested against your real applications, especially the awkward on-premises ones, because a ZTNA that handles your easy web apps and chokes on the critical legacy system has not replaced your VPN at all.
how it's priced, and the real cost
ZTNA and SSE are usually priced per user per month, with SSE and especially SASE costing more as you add modules and networking. The temptation, and the vendor's incentive, is to sell the bundle, so price against the scope you will actually use rather than the platform you might grow into. The license is rarely the whole cost: budget for VPN migration, which is the real project and where year-one effort goes; app publishing, since connecting each private app, especially legacy ones, takes work and connectors have to be deployed and maintained; bundle creep, where modules you do not need get switched on and billed; and networking, for SASE, which is a cost and a project in its own right. Think in total cost over a couple of years for the scope you will really run, and the case for starting with focused ZTNA over a full platform usually holds for anyone whose core problem is the VPN.
how to run the evaluation
Shortlist against your actual scope, including the option of leaning on your existing single sign-on and conditional access if you are SaaS-heavy, and focused ZTNA against a full SSE platform. Ask scope-revealing questions: can you publish our specific on-premises and legacy apps, not just web apps; do you support agentless access for contractors on unmanaged devices; how does access tie to our identity provider and device posture; where are your points of presence and will our European users get good performance with data staying in the EU; how do you support a phased VPN retirement? Then run a proof of concept against your real environment: publish a few of your actual private apps including a difficult on-premises one, test contractor access from an unmanaged device through the browser, measure performance from where your users actually are, and run a small group fully off the VPN to see what breaks, setting success criteria up front with agentless access and real-app coverage among them. Then take references focused on the migration: how the VPN retirement went, what broke, and whether the bundle they bought matched what they ended up using.
the traps the pilot won't surface
The signature failure is buying a platform to solve a VPN problem, then using a fraction of it while paying for all of it. Close behind is the agent wall: a ZTNA that works for managed employees and cannot cleanly serve the contractors and partners who turn out to be a big part of your remote access. Then there is the performance surprise, where the provider's points of presence are far enough from your users that the new thing feels as slow as the VPN it replaced; bundle creep, modules switched on and billed without ever being operationalized; the legacy app the ZTNA cannot publish well, so the VPN never actually gets retired and you run both; and the ownership vacuum, where security and networking each assume the other has it. The deepest one is mistaking ZTNA for finished zero trust and leaving identity governance, SaaS, and data untouched. What runs under every one: ZTNA replaces the VPN, and only the VPN, and the value comes from scoping it honestly rather than buying the biggest bundle on offer.
where this meets the rules
Secure remote access is squarely in scope for the regulations. NIS2 expects access control and secure handling of remote access among its risk-management measures, and a flat VPN that drops users onto the network sits awkwardly against that. DORA expects financial entities to control access including remote and privileged access, which ZTNA's per-app, identity-and-device model supports far better than network-level trust. Insurers increasingly scrutinize remote access, because exploited VPNs are a well-worn ransomware path. None of these names a product, but the direction, away from network-level trust and toward identity-based per-app access, matches where the regulations and the threat both point. This is context for prioritizing, not legal advice, and the specifics depend on your sector and country.
a sequenced path
This rewards scoping tightly and retiring the VPN deliberately rather than chasing the full platform on day one. Crawl: replace the VPN for your highest-risk remote access with ZTNA, granting per-app access based on identity and device, starting with the access that would hurt most if abused and leaning on your existing single sign-on and conditional access for the SaaS side. Walk: extend ZTNA to cover your private apps broadly, bring contractors onto agentless access, and retire the VPN properly rather than running both, adding a secure web gateway or cloud controls only where you have a specific need. Run: if your situation genuinely calls for it, converge toward a full SSE or SASE platform with device posture feeding every access decision, branch connectivity, and broad points of presence, tied into the wider zero trust model of which this is the network-access component rather than the whole.
where to start
ZTNA is one of the clearer security upgrades available, because replacing network-level trust with per-app, identity-based access removes a whole class of risk and solves a real daily irritation at the same time. The trap is buying far more platform than the problem needs. So the honest first move is to map what people actually need to reach and from what devices, scope the purchase to that, and treat the VPN replacement as the win rather than reaching for the full bundle before you need it.
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there
+48 783 762 997
julian@unshadowit.com
