Who offers affordable zero-trust network access for a growing organization? The short answer: Cloudflare Access, Tailscale, and Twingate all deliver genuine ZTNA starting free or in the $5–7/user/month range — a fraction of the enterprise suites (Zscaler, Palo Alto Prisma, Netskope) that made everyone assume ZTNA was out of reach. If your identity already lives in Google Workspace or Microsoft Entra, you may already own a capable option. The cost was never the blocker. The sequencing is.
Is ZTNA just a fancier VPN?
No — it inverts the VPN’s trust model. A VPN is a moat: connect once, and you’re trusted on the network behind it. That assumes the attacker is outside. But the attacker’s most reliable way in is a phished employee credential, and the moment that credential is on the VPN, a flat network hands them everything.
Zero-Trust Network Access (ZTNA) is the productized form of never trust, always verify: instead of admitting you to a network, it brokers access to one application at a time, re-checking who you are (identity) and what you’re on (device posture) on every session. A phished credential on an unmanaged laptop reaches the one app it was authorized for — and, if device posture is enforced, not even that.
| Legacy VPN | ZTNA | |
|---|---|---|
| Trust model | Connect once → trusted on the whole network | Every request re-verified: identity + device, per app |
| Blast radius of a stolen credential | The entire flat network | Only the authorized app — nothing lateral |
| Access granularity | Network / subnet | Application / resource |
| Device posture | Rarely checked | Checked each session |
| User experience | VPN client, reconnects, backhauled traffic | Usually clientless (browser) or a light agent |
| Offboarding | Revoke VPN, hope nothing else lingers | Revoke identity → access disappears everywhere |
If you’ve read our broader piece on zero-trust for regulated SMBs, ZTNA is Phase 3 — retiring the VPN-as-moat — made concrete. It only pays off once Phases 1 and 2 (identity and device) are in place, which is the trap most rollouts fall into.
Who offers affordable ZTNA for a growing team?
These are the options that clear the “real ZTNA, SMB-priced” bar. Prices are list and move around — treat them as order-of-magnitude, not quotes.
| Tool | Best for | Starts at | Identity (SSO) | Device posture | Pick it when |
|---|---|---|---|---|---|
| Cloudflare Access (Cloudflare One) | Internal web apps, SSH/RDP, dashboards | Free ≤ 50 users, then ~$7/user/mo | Any OIDC/SAML — Google, Entra, Okta | Yes (WARP + posture checks) | You want clientless, browser-based access to internal apps live this week |
| Tailscale | Engineer + machine access: SSH, databases, private services | Free for small teams; ~$6/user/mo business | Google, Entra, Okta, GitHub | Device-based (the tailnet itself) | Developers need SSH/DB access without standing up a bastion |
| Twingate | Resource-level access across a mixed fleet | Free tier; ~$5–10/user/mo | Google, Entra, Okta | Yes (trust profiles) | You want simple per-resource rules with a lightweight agent |
| Google BeyondCorp Enterprise | Shops already all-in on Google Workspace | Bundled into Workspace tiers | Yes (context-aware access) | Workspace is your identity spine | |
| Microsoft Entra Private Access | Shops already on Entra ID / M365 | Part of the Entra Suite | Entra | Yes (Conditional Access) | M365/Entra is your identity spine |
| Enterprise (Zscaler ZPA, Prisma Access, Netskope) | Large, complex estates with a security team | Six figures | — | — | You’re past ~500 seats — most growing teams are not |
A useful shortcut: pick the ZTNA that sits closest to the identity you already run. On Google Workspace, BeyondCorp is a short hop. On Entra, Private Access is already half-configured. Independent of both, Cloudflare Access (great for HTTP apps and SSH) and Tailscale (great for raw infra access) compose well — many teams run both: Cloudflare Access fronts the web tools, Tailscale carries the engineers’ SSH and database access. Twingate is the easy middle if you want one clean per-resource model.
Where to start (don’t buy ZTNA before Phase 1)
The reason ZTNA projects stall isn’t the product — it’s buying the access proxy while identity is still a mess. ZTNA verifies identity, so it’s only as strong as the identity underneath it. Sequence it:
- Consolidate identity first. One SSO provider fronting your apps, MFA on 100% of accounts, phishing-resistant MFA (passkeys/FIDO2) for admins. ZTNA keyed to a weak identity layer is theater. (This is the same Phase 1 from the zero-trust guide, and it leans on the same discipline as killing long-lived credentials.)
- Put your most sensitive internal app behind the proxy first. The admin console, the internal dashboard, the database — not the marketing wiki. Gate it on SSO and a device check. This is a day-one change with one tool, not a migration.
- Retire the VPN for that path. Once the app is reachable through the ZTNA broker with identity + device verified per session, remove its VPN route. Prove the pattern on one app before you generalize.
- Expand app by app, then decommission the concentrator. Each app you move shrinks the VPN’s blast radius. When the last sensitive path is off it, the VPN — and its licence cost — goes away. ZTNA is frequently cheaper than the concentrator it replaces.
Good-enough bar for a growing team: your sensitive internal apps are reachable only through an identity- and device-checked proxy, the flat “VPN = trusted” path to them is gone, and offboarding a person removes their access everywhere in one revocation. That bar is reachable this quarter with tools you can start free.
The Template
A VPN-to-ZTNA migration checklist. Work top to bottom — the prerequisites are load-bearing, and moving apps before identity is solid is how rollouts fail.
Prerequisites (do not skip)
- Single SSO provider fronts the apps you’re about to protect
- MFA on 100% of human accounts; passkeys/FIDO2 on every admin
- Shared/role logins eliminated — named accounts only
- An inventory of internal apps + who legitimately needs each
Pick + pilot
- ZTNA tool chosen to sit closest to your existing identity (table above)
- First app = your most sensitive internal tool, not the easiest one
- Access policy = SSO group AND device posture (managed/encrypted)
- Pilot with a small group; confirm clientless/agent UX is acceptable
Cut over
- App reachable through the ZTNA broker for the pilot group
- VPN route to that app removed (not just deprioritized)
- Access logs flowing to your central logging/SIEM
- Break-glass path documented and tested before you rely on it
Expand + retire
- Next apps migrated one at a time, each with per-app policy
- Device-posture enforcement tightened (block unmanaged where required)
- Conditional access on anomalies (new geo/device) challenged or blocked
- VPN concentrator decommissioned once the last sensitive path is off it