The difference is architectural; Tailscale is a mesh VPN, whereas OpenZiti is an identity-first, zero trust overlay network. This makes OpenZiti service-centric and deny-by-default, not network-centric. Instead of “join a private network,” you get access only to explicitly authorised services — with no ambient reachability at all. Its also 100% open source. If you want a simple productised, SaaS experience, NetFoundry, the company behind OpenZiti provides that.
That’s a fair framing, with one important distinction.
Overlay ACLs give you network-scoped microsegmentation, not service-scoped Zero Trust (as intended in NIST 800-207). You’re limiting which IPs/ports can talk after a node is attached, not deciding whether a service path exists at all per identity and per session.
The crypto isn’t the issue - WireGuard keys are strong. The issue is scope. A node identity that grants network reachability is different from a capability-scoped identity that creates only explicit service connectivity. NIST also warns that IP-based enforcement tends to reintroduce ambient trust once a device is attached. In that model, lateral movement is reduced, not eliminated.
A simple litmus test:
- If authenticating gives you an IP and routes, you’ve built network trust with segmentation.
- If authenticating only creates explicit service paths, you’ve built Zero Trust.
Mapping this to Wireguard and overlays, I’d say:
- WireGuard + identity + ACLs = good overlay microsegmentation
- Identity-first connectivity (no IP reachability, no inbound listeners) = Zero Trust by construction
If you adopt the latter, the former becomes unnecessary for Zero Trust — because identity creates connectivity directly instead of attaching nodes to a network. Bringing it back to the topic, microsegmentation manages risk inside a network. Identity-first connectivity removes the network from the trust model altogether.
You could use a solution that allows you to have E2E with private sovereign keys on the endpoint, as well as bring your own IdP/PKI, so the provider does not have your keys. Would that be good enough?
Check out OpenZiti. Its open source, runs at prodution scale, and recently someone who used to work at Twingate said OpenZiti is many times more powerful than TG.
OpenZiti is promising but their desktop and mobile clients are very incomplete.
The feature set varies greatly between platforms.
If you are supporting a single platform (example desktop windows) it could work. Even better if you have the resources to write your own clients using the SDK, like it's meant to be.
From memory: oAuth login flow
(browser based) was only supported on the windows client. For a Zero trust solution, having the only auth truly supported be a permanent JWT/Cert on the machine is doing device authentication, not user authentication, thus completely failing your primary objective.
UX was overall atrocious. Our users could not comprehend it at all. It was deemed that a custom client was required to be made.
The SDK first approach was an overall major plus point, allowing for a full customization to a specific use case.
Don't get me wrong we were overall impressed with the technology and the architecture choices. It's not a finished product, but something that does all the infra and you just need to apply the final veneer on top.
Ahh, I see, thanks for clarifying. That was correct, now any OIDC-compatible identity provider (Auth0, Okta, Azure/Microsoft Entra, Google, Keycloak, etc.) is supported on all the tunnelers to my knowledge.
Lots of work continues to go into the UX, but I would note that we focus most of the UI/UX work into NetFoundry, our commercial product.
The problems we had is users could not reliably tell when they were connected/disconnected, how to initiate the login flow, get network status (why is that service not working, but this other one is?), tell to which router they were connected, etc etc. I know these are big asks, and I suspect a lot of these troubleshooting and status info are probably available in the commercial offering.
That being said I think OpenZiti/NetFoundry is in a different class entirely and any lurkers here should consider it for their use. It's not really the same thing as NetBird or Tailscale.
Yeah, definitely more on the commercial side of the product.
And agreed, I like NetBird/Tailscale/Wireguard, but they are better VPNs, not identity-first, zero trust overlays as OpenZiti/NetFoundry is. That's why companies like Siemens have adopted it and many more will.
Fair, I was being loose with my language. What I should have said is that it does not come fully featured open source, that you need to do a certain amount of rolling your own.
Right, but if certificates are a fundamental part of your design, you should include the functional mechanisms to manage them imho (i.e., key distribution, auth/login). The developers created it, but they keep it in the commercial product. Other overlays which use PKI include those functions in the FOSS.
I like Netbird, its a better VPN, but its not zero trust networking. Zero Trust requires identity to create connectivity itself—per service, per session—rather than granting network reachability and constraining it with routes and rules. I have had this conversation on Reddit many times... curious if anyone agrees/disagrees.
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/
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
NetBird doesn't require network reachability (it used relays for NAT traversal) and creates the keys itself. It doesn't do any routing. It uses wireguard underneath.
Why do you think thats against the principles of zero trust? Wireguard is a wire transport, it has no control plane... I think what you are alluding to is the centralised control plane which makes it possible to operate at scale (and much more).
You have more or less described OpenZiti. Just mint a new identity/JWT for the user, create a service, and viola, only that user has access to your machine. Fully open source and self-hostable.
The difference is architectural; Tailscale is a mesh VPN, whereas OpenZiti is an identity-first, zero trust overlay network. This makes OpenZiti service-centric and deny-by-default, not network-centric. Instead of “join a private network,” you get access only to explicitly authorised services — with no ambient reachability at all. Its also 100% open source. If you want a simple productised, SaaS experience, NetFoundry, the company behind OpenZiti provides that.