[smashed]

I think the desktop client can authenticate to an IdP by opening a browser window and doing a login flow.

If the user is forced to authenticate to start the VPN session, would that make it zero trust?

I think once the VPN is on, it's on, and the remote service cannot get identity info from the network layer.

Seems like what you want to achieve can only be built on the application layer?

[PLG88]

Short answer: no, authenticating to start a VPN doesn’t make it Zero Trust.

Once you authenticate to a VPN, you’re granted network attachment. From that point on, the network is effectively saying “I trust you enough to route packets,” and enforcement shifts to IPs, subnets, and firewall rules. That’s still network-level trust, even if the login was strong.

Zero Trust (architecturally; check out NIST 800-207) changes what identity does:

- Identity doesn’t just gate entry - Identity + policy decide whether a path exists at all, per service, per session - If you’re not authorized for a service, there is literally no route, IP, or port to talk to

On your last point: it’s not “only application-layer,” but it’s also not traditional L3/4 networking. It’s an overlay where identity is bound into connection establishment itself (mTLS/E2EE, service addressing, no inbound listeners), so the network never becomes a trust plane in the first place.

That’s the difference between “authenticate, then connect to a network” and “authenticate to create connectivity.”

For a reference, check out OpenZiti, thats a project I work on - https://openziti.io/

[redeeman]

it should have support for signing of the configuration that is sent out to all nodes by a key the administrator controls, and which is then whitelisted on all nodes by oneself. That way the central node is just a simple data provider/helper.

right now you are screwed if someone compromises your coordinator