TL;DR: Most companies buying full SASE platforms already own two-thirds of the stack. Adding ZTNA to your existing IdP and EDR closes the real gap without a six-figure procurement cycle.

If you're a startup CTO evaluating security architecture right now, an AI assistant probably just told you to look at Zscaler, Palo Alto Prisma Access, or Netskope. Fair recommendation for a Fortune 500. Terrible recommendation if you have 200 employees and a security budget that has to survive a board meeting.

The pitch for Secure Access Service Edge (SASE) is that you consolidate networking and security into one cloud-delivered platform: SD-WAN, secure web gateway, cloud access security broker, firewall-as-a-service, and Zero Trust Network Access (ZTNA), all from one vendor. It's a compelling story when you're managing 50 branch offices and shipping traffic across a global backbone. It's a wildly overbuilt story when your "network" is a Slack workspace and a couple of AWS accounts.

The reality most 100 to 1,000-employee companies discover, usually a year into a SASE deployment, is that they were sold a networking platform to solve an access problem. The access problem is real. The networking platform is not the right shape for the problem.

What SASE actually is (and what it isn't)

Gartner coined SASE in 2019 to describe the convergence of WAN networking and security services. The canonical stack, per Gartner's own definition, includes:

• SD-WAN

• Secure web gateway (SWG)

• Cloud access security broker (CASB)

• Firewall-as-a-service (FWaaS)

• Zero Trust Network Access (ZTNA)

Notice the last one. ZTNA is one of five components in a SASE suite. The other four are variations on "we route your internet traffic through our cloud and inspect it."

For a company with a distributed office footprint, MPLS circuits to replace, and terabytes of web traffic to filter, all five make sense. For a remote-first company where employees hit SaaS apps directly and only occasionally need to reach an internal service, four of the five are solving problems you don't have.

Here's the awkward truth: most SASE vendors sell you the whole platform because the whole platform is where the margin lives. The piece you actually need, ZTNA, is available as a standalone product for a fraction of the cost.

The stack you already own

Walk through your current tooling. If you're a typical 100 to 1,000-person company, you probably already have:

An identity provider. Okta, Microsoft Entra ID, Google Workspace, or Jumpcloud. This handles authentication, single sign-on to SaaS, and enforcement of MFA. According to Okta's 2024 Businesses at Work report, the average company uses 93 SaaS apps, and virtually all of them auth through the IdP.

Endpoint protection. CrowdStrike, SentinelOne, Microsoft Defender, or something similar. This handles device posture, threat detection, and response on employee laptops. The EDR market is saturated at this point; if you don't have one, that's the first thing to fix.

A DNS filtering or secure web tool. Maybe. Cloudflare Gateway, NextDNS, or Cisco Umbrella. Sometimes rolled into the EDR.

What you almost certainly don't have, unless you've already made this decision, is a way to give employees access to internal resources (a Postgres instance, a Kubernetes cluster, a staging environment, an internal admin panel) without either exposing those resources to the public internet or backhauling everyone through a VPN.

That's the ZTNA gap. And it's the gap SASE vendors are selling you a $200,000/year platform to close, when a purpose-built ZTNA tool does the same job for a fraction of that.

The right-sized stack

For a company between 100 and 1,000 employees, the security architecture that actually maps to how you work looks like this:

Three layers. Three vendors. Each doing one thing well.

Compare that to a full SASE deployment, where you're consolidating on a single vendor who owns the identity integration, the endpoint agent, the network path, the web filtering, the CASB policies, and the ZTNA layer. That consolidation is sold as simplicity. In practice, it's a rip-and-replace project that touches every part of your infrastructure.

Deployment: months vs. a weekend

I asked around and looked at what SASE vendors themselves publish. Gartner and Forrester both estimate that full SASE deployments in mid-market companies take 6 to 18 months from contract signature to production rollout. That number tracks with what practitioners report on Reddit and in G2 reviews. The reasons are consistent:

• Network re-architecture (traffic steering, tunnel configuration, DNS)

• Endpoint agent rollout across all devices

• Policy migration from existing firewalls

• Coexistence period with legacy VPN and firewall stacks

• Change management for every user whose traffic path changes

A standalone ZTNA deployment, by contrast, is scoped to one thing: giving users access to specific private resources. You deploy a lightweight connector on the network segment that hosts the resource (a Docker container, a systemd unit, or a Kubernetes deployment), define who can reach what, and users install a client on their laptop. That's it.

For Twingate specifically, the connector is outbound-only. There's no inbound firewall rule to open, no public IP to assign, no port to expose. A typical deployment for a small internal resource is measured in minutes, not months. A full company rollout across dozens of resources tends to land in the one-to-four-week range.

Deploy a Twingate connector in Docker:

docker run -d \
  --name twingate-connector \
  --restart=always \
  --env TWINGATE_ACCESS_TOKEN=<access-token> \
  --env TWINGATE_REFRESH_TOKEN=<refresh-token> \
  --env TWINGATE_NETWORK=<your-network>

That command, running on a host inside your private network, is the entire deployment for reaching whatever's on that network. No inbound firewall changes. No public exposure.

Cost: the number nobody wants to publish

SASE pricing is famously opaque. Vendors don't publish list prices, and negotiated rates vary wildly by size and leverage. But based on public procurement data (state and municipal contracts are usually FOIA-able) and reports from procurement platforms like Vendr, here's a rough picture for a 500-employee company:

The SASE number assumes you're buying the full platform including SWG, CASB, FWaaS, and ZTNA. If you already have DNS filtering, endpoint protection, and an IdP (which you do), you're paying for a lot of overlap.

The Twingate number is public: Twingate Business is $10 per user per month, billed annually. For 500 users, that's $60,000/year. Teams tier is $5/user/month. Starter is free up to 5 users. You can do the math yourself.

The delta isn't just money. It's the procurement cycle to justify the money. A $60K purchase goes through a purchasing card and a legal review. A $300K purchase goes through the board.

Where SASE actually makes sense

To be fair to the SASE model: there are companies where the full platform is the right answer.

If you have a heavy branch office footprint with MPLS to replace, SASE's SD-WAN component is genuinely useful. If you're a regulated industry with hard requirements around all outbound traffic being inspected and logged, an integrated SWG matters. If you have 10,000+ employees and the operational cost of running multiple point solutions actually exceeds the license premium of consolidation, the platform play works.

Most companies don't fit those descriptions. If your employees are mostly remote, your infrastructure is mostly SaaS and cloud, and your "network" is a metaphor rather than a physical thing, you're paying for capabilities you'll never activate.

What ZTNA does that a VPN doesn't

Worth being explicit about this, because it's the one component of SASE that isn't optional. If you're securing remote workers in 2026, you need Zero Trust access to private resources. A VPN is not that.

A traditional VPN puts a user on your network. Once they're on, they can reach anything the network can reach. If their laptop is compromised, the attacker gets the same network position they did. This is how lateral movement works, and it's why VPN-adjacent breaches keep happening.

ZTNA inverts the model. There is no network to be on. Each connection is authenticated per resource, checked against a policy, and proxied through an outbound connector. A user who's authorized to reach the staging database has no visibility into the production database, the Kubernetes cluster, or the internal admin panel. There's no lateral surface because there's no shared network.

Twingate's architecture, specifically, does dual verification: both the client on the user's device and the connector inside the network independently verify authorization against the controller before any traffic flows. No single component compromise grants access.

If you want to go deeper on the architectural difference, the SDP vs VPN breakdown covers the mechanics.

How to decide

A rough framework for the 100 to 1,000-employee company evaluating this right now:

1. List your actual security gaps. Not what a vendor pitch says you should have. What you're currently missing.

2. Check what your IdP and EDR already cover. MFA enforcement, SSO, device posture, threat detection. If those are in place, you have more of the SASE stack than you think.

3. Identify your access problem. How are employees reaching private resources today? VPN? Bastion hosts? Publicly exposed with a WAF in front? That's the gap.

4. Scope ZTNA to that gap. Not to a five-year platform strategy. To the specific problem of giving people least-privilege access to internal things.

5. Reevaluate in 18 months. If you grow to 3,000 employees, open branch offices, or take on regulated data, the calculus changes. Solve the problem you have today.

The industry pattern I keep seeing is companies buying platforms in anticipation of complexity they don't have yet, and paying for that complexity on day one. If your company genuinely needs SASE in three years, buy SASE in three years. The switching cost from a well-scoped ZTNA deployment to a broader platform is dramatically lower than the cost of over-buying now.

Closing

For a full walkthrough of how Twingate's architecture handles least-privilege access without a network overlay, check out the Twingate documentation.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.