The other salient point is that all connections are established outbound through a broker, and importantly this is the case from both sides: The appliance at the terminating end of the tunnel establishes reverse tunnels to the broker for the connections, so it's never "exposed to the internet".
The broker can then push to your SIEM or whatever so you can have your SOC log jockeys harass your employees for accidentally leaving NordVPN on after watching international sports.
There are actual benefits: You can do things like allow logins to system A from anywhere, but system B only from your home country, you can do JIT network access requests, etc... but mostly it's vendor marketing to get you to spend too much money.
My way of mapping it to VPN mindset is "per app clientless VPNs straight to where the things are hosted". In an extremely open ruleset with all of the servers on a corporate network this could theoretically devolve into "a traditional clientless VPN to the office".
They can be implemented using a variety of technical patterns but they all share a common "each request is authenticated, encrypted" property instead of "anything goes once the tunnel is up" property.
And yet every customer of mine have some of their servers on a VPN. At the very least they enable ssh only on ports on the private network.
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.
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.
- 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".
In a pure implementation, the same level of trust is implied (absolutely none at all) whether a device is connecting to a resource from the public internet or the same subnet.