Zero Trust vs VPN: What Zero Trust Actually Requires
If you took a drink every time a vendor stamped “zero trust” on a product page, you wouldn’t survive the first hour of a security conference. The term has become the “organic” of cybersecurity — applied to everything, guaranteeing nothing. Most “zero trust” products are traditional security tools with a fresh coat of marketing paint.
So let’s be precise: what zero trust actually requires, why the VPN model it replaces is failing, and what a real implementation looks like.
Why the VPN model fails
Traditional network security is castle-and-moat. Build a perimeter, put a drawbridge (the VPN) at the front, and trust everything inside. That model has three structural flaws, and none of them can be patched.
The castle doesn’t exist anymore
Your infrastructure is in AWS, your code is in GitHub, your identity provider is SaaS, and half your team works from home. The VPN is defending a perimeter that no longer contains the things it was built to protect. You’re paying to guard an empty castle while the crown jewels sit in three different clouds.
Once they’re in, they’re everywhere
The VPN’s core assumption — inside means trusted — is exactly what ransomware crews exploit. The playbook is depressingly consistent:
- Phish one employee and steal their credentials
- Log in to the VPN
- Land inside the “trusted network”
- Scan for internal systems
- Move laterally to database servers
- Exfiltrate data, then deploy ransomware everywhere the network reaches
One phished credential becomes total compromise, because the network — not the identity — is the unit of trust. The clock from initial VPN access to network-wide compromise is measured in hours, not weeks.
The user experience is terrible
Poll any developer about their VPN: it’s slow, it breaks constantly, and everyone has screamed at their laptop when it dropped mid-download. Bad UX isn’t just an annoyance — it’s a security problem, because people route around controls that slow them down.
Zero trust vs VPN: side-by-side
| VPN (castle-and-moat) | Zero trust | |
|---|---|---|
| Trust model | Trust by network location — inside the perimeter means trusted | Never trust, always verify — every request authenticated and authorised |
| Network exposure | Whole network segments reachable after one login | No network-level access; connections are per-resource and per-protocol |
| Credential model | Long-lived passwords and shared secrets | Short-lived certificates bound to a verified identity |
| Session audit | Connection logs, at best | Per-session audit trail, including full session recording |
| Blast radius | One phished credential enables lateral movement everywhere | Compromise is scoped to one identity’s current, time-limited role |
| User experience | Clients, drops, split-tunnel debugging | SSO login, native tools, no client juggling |
What zero trust actually requires
The term was coined by John Kindervag at Forrester Research in 2010, built on one principle: never trust, always verify. Stripped of vendor gloss, a zero trust architecture requires:
- Explicit verification for every access request — no ambient trust based on network location
- Least-privilege enforcement — users get exactly what they need, for as long as they need it, and nothing more
- An assume-breach mentality — design as if attackers are already inside, because eventually they will be
- Identity as the security perimeter — cryptographic identity for users, devices, and workloads
- Encryption everywhere — all traffic encrypted in transit, no “internal traffic is safe” exceptions
Spoiler: adding MFA to your VPN doesn’t make it zero trust. It makes it a VPN with MFA — a stronger front door on a building with no interior walls.
How Teleport implements zero trust
Teleport is an open-core access platform that provides a single point of identity-aware access to SSH servers, Kubernetes clusters, databases, internal web applications, and Windows hosts. It’s worth seeing how each zero trust requirement maps to a concrete mechanism, because this is where most “zero trust” products quietly fail.
Certificate-based, short-lived credentials. Teleport replaces passwords and long-lived keys with certificates that are issued at login and expire within hours. There is no standing credential to phish, leak in a repo, or crack offline. When an engineer’s certificate expires, their access expires with it — offboarding becomes a non-event rather than a scavenger hunt through authorized_keys files.
Identity-aware access to every protocol. Every connection — SSH, kubectl, a database client, a browser session — is authenticated against your identity provider first. Access decisions follow the person, not the IP address. ThinSky typically pairs this with a managed Keycloak deployment as the identity layer, so the same SSO identity governs both your applications and your infrastructure — see managed Keycloak. Okta’s per-user model makes that same SSO layer expensive at scale — the 2026 Okta pricing breakdown shows how the meter compounds.
Per-session audit and recording. A VPN can tell you that someone connected. Teleport can tell you what they did: every session is logged, and interactive sessions can be recorded and replayed. When an auditor asks “who touched the production database in March, and what did they run?”, you have an answer instead of a shrug.
Role-based access control with time constraints. Permissions are defined as roles mapped from your identity provider’s groups, and elevated access can be granted just-in-time — requested, approved, and automatically expired. Nobody holds standing admin rights because revoking them is too much paperwork.
No standing network access. This is the structural difference. Teleport never puts a user “on the network.” Each connection is brokered to one specific resource over one specific protocol, so a compromised account exposes exactly what that identity’s current role allows — not every routable host behind a perimeter.
The CyberArk question
Teams evaluating Teleport are often really evaluating an alternative to a privileged-access-management renewal — usually CyberArk’s. That comparison is commercial as much as architectural: CyberArk’s model vaults standing credentials, Teleport’s model eliminates them, and a managed Teleport deployment typically lands at a fraction of a CyberArk-class PAM bill. We’ve written the full, honest comparison — including where CyberArk genuinely wins — in CyberArk alternatives: why teams are moving to Teleport.
Why ThinSky Managed Teleport
You could run Teleport yourself — but then you own high-availability architecture, certificate authority management, identity-provider integration, and upgrades, forever. ThinSky Managed Teleport takes all of that off your plate: a fully managed, highly available Teleport cluster, integrated with your identity provider, with session recording, just-in-time access workflows, device trust enforcement, and Canadian data-residency options. Pricing is scoped to your environment — request a quote.
A typical pilot runs four weeks: we stand up the cluster, deploy agents to one team’s infrastructure, the pilot team uses Teleport exclusively for two weeks, and at the end you either roll it out or walk away. The goal: developers prefer it, security trusts it, the VPN gets decommissioned — and six-figure legacy access renewals come off the books.
FAQ
Is a VPN with MFA zero trust?
No. MFA hardens the authentication event, but everything after login is unchanged: the user still lands on a trusted network with broad reachability, credentials are still long-lived, and lateral movement is still possible. Zero trust requires verifying every request to every resource — not verifying one login harder.
What is the difference between zero trust and a VPN?
A VPN authenticates you once and grants access to a network; what you can reach is then governed by network topology. Zero trust authenticates and authorises every request to every individual resource, using identity and short-lived credentials instead of network location. The practical differences — exposure, blast radius, auditability — are in the table above.
Do I have to rip out my VPN on day one?
No, and you shouldn’t. Sensible migrations run zero trust access in parallel with the VPN: start with the highest-value infrastructure (production SSH, Kubernetes, databases), move teams over incrementally, and decommission the VPN once nothing depends on it. The VPN’s last job is usually legacy systems that take longer to migrate — that’s fine.
Is Teleport open source?
Partly, and it’s worth being precise. Teleport’s community edition is source-available under a restrictive licence rather than a classic open-source licence, and advanced features are commercial — “open-core” is the honest label. What you’re evaluating is the architecture and the operational model, not a free-software badge; if licensing posture matters to your procurement process, we’ll walk you through exactly what’s included.
Ready to see what zero trust looks like in your environment? Email sales@thinsky.com or request a consultation and we’ll scope a pilot. If you’d rather start with evidence, the free external audit shows you what your perimeter — VPN endpoints included — looks like from an attacker’s side of the fence.