Think machine certs (stored in a TPM). Plus perimeter-enforced username/password/2FA. Plus additional policy checks, like making sure your machine is up to date on security patches.
It doesn’t matter what network you are connecting from, but it does matter that you’re connecting from a company-issued laptop that’s in a trustworthy state.
Sounds like multiple single points of failure to make a security infrastructure so hostile to the end user it would be considered the equivalent of being under persistent attack.
The big difference is once you’re in, with a VPN you have direct access to the whole network.
With a zero trust setup, access has to be granted to you (or your ACL group) on a per-application basis. It makes it much harder for an attacker to move laterally when everything is default-deny.
But you can combine VPNs with SSO and limited permissions. Real networks all work that way these days. Logging into the VPN doesn't get you very far, you'll need to be provisioned with specific apps and permissions too.
- You must "VPN in" to access any corporate resources of any type, even ones on the corporate network when you're sourcing from the corporate network
- The client forms a separate "VPN connection" (can be clientless, but same concept) per app you access, rather than assuming a single parent VPN server can get them to any resource
- Every default ruleset started with deny all and only specific allow rules were added over time
Then you've got enough to call it a zero trust implementation. You can also take things the other way, i.e. you could "deconfigure" a zero trust setup to look and function almost exactly as a normal corporate VPN tunnel.
Rather than go through this whole thread each time, people just refer to all of this as "zero trust networking".
It doesn’t matter what network you are connecting from, but it does matter that you’re connecting from a company-issued laptop that’s in a trustworthy state.