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.

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.

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.

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.

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/