Technical Comparison — April 2026
Tailscale is a well-engineered overlay network with identity attached. Zsub is an identity and trust architecture from which secure networks emerge. Understanding the difference matters for choosing the right tool.
Tailscale and Zsub are often compared because both enable secure peer-to-peer connectivity. But they answer different foundational questions, and that difference propagates through every design decision each makes.
Tailscale asks: how do we make it easy to securely connect devices that already exist, run by organizations that already have identity infrastructure?
Zsub asks: what does a complete, self-sovereign identity and trust system look like, and what kinds of secure connectivity and interaction emerge naturally from it?
Neither question is wrong. But they lead to architectures with fundamentally different properties — especially for environments where the trust model itself is the security requirement, not just the transport.
In Tailscale's model, the identity and network layers are distinct systems that interoperate. In Zsub, they are the same system: every connection, relationship, and access grant is a direct expression of a key that derives from a single seed root. There is no separate identity provider, no control plane to trust, and no seam between authentication and network access.
Tailscale's coordination server is the source of truth for which peers can connect and what keys they hold. Even when connections are peer-to-peer via WireGuard, the control plane mediated their establishment. This creates several concrete dependencies:
Self-hosting Headscale moves the control plane under your management but does not eliminate it. You still have a centralized coordinator that peers depend on, a new service to operate and secure, and a trust boundary between your identity provider and your network. The architectural dependency is relocated, not resolved.
Tailscale's control plane is a deliberate and reasonable design choice for its target use case: organizations with existing IAM infrastructure who want a simple, managed overlay network. The tradeoff is an explicit third-party trust dependency in the path between your identity system and your network. For most organizations, that tradeoff is acceptable. For environments where the network itself is a trust-critical asset, it deserves scrutiny.
Tailscale delegates identity entirely to an external IdP. You authenticate via Google, Okta, GitHub, or similar, and Tailscale translates that authentication into network membership and WireGuard key distribution. The identity system is your IdP; Tailscale handles the mapping to network access.
This is pragmatic: most organizations already have an IdP, and Tailscale doesn't ask them to replace it. The consequence is that Tailscale's identity model is only as strong, as auditable, and as self-sovereign as the IdP it delegates to — which is typically a third-party SaaS.
Identity in Zsub begins with a single seed — a cryptographic root that belongs entirely to its holder, with no registration, no third-party issuance, and no central authority. From this seed, a full hierarchy of keys is derived deterministically using Blake3-based hierarchical derivation with context strings. Every context — mesh membership, peer relationship, individual connection, session — has its own isolated key derived from this root.
The properties this creates are not incremental improvements on Tailscale's approach. They are different in kind:
Tailscale handles access control through ACLs: a configuration file (or admin console) defines which devices and users can reach which resources. This is operationally familiar and easy to reason about. It is also fundamentally administrative — trust is a policy decision maintained in a configuration, not a property of the cryptographic relationship itself.
Zsub's trust model works differently. The Heavy protocol encodes trust as a privacy-preserving chain of Schnorr proofs over Pedersen commitments. In practice this means:
In Zsub, a trust proof doesn't say "this device is on the allowed list." It says "this key is cryptographically descended from an accountable root, through a chain of human-authorized relationships, verified without revealing the chain." Authorization isn't an ACL entry that an admin writes — it's an unforgeable proof that traces back to a human who holds a seed.
Because trust chains can be configured to mirror organizational relationships — a manager's key authorizing reports, a security officer's key governing audit access, a contractor's key scoped to specific contexts — the access model is an expression of how your organization actually works, not a separate policy layer that has to be kept synchronized with it.
Access is governed through layered attestation lifetimes rather than explicit revocation. Organizational-level attestations renew on a days-to-weeks cadence. Shorter-lived status attestations — issued by highly available attestation services and expiring in hours or minutes — handle operational state like current employment or active role. An attacker with a compromised credential has a window defined by the attestation lifetime, not by how quickly an admin notices and acts. Where tighter guarantees are needed, parallel trust chains can issue independent short-lived attestations, shrinking the window further without adding a revocation oracle to the architecture.
Trust verification in Heavy produces proofs of approximately 1 KB that verify in under 1.3 ms for a 5-hop chain. Critically, verification reveals that a valid trust relationship exists without revealing who is in the chain. This is not metadata reduction — it is structural privacy for the organizational relationships themselves.
Tailscale's ACL model is operationally excellent for its purpose. The distinction is that ACLs are a description of who should be trusted, maintained outside the cryptographic system and applied to it. Zsub's trust chains are the cryptographic system — there is no separate policy layer to keep in sync, audit separately, or misconfigure.
The assumption that an established product is necessarily easier to adopt than a new one deserves scrutiny here, because the underlying models have meaningfully different overhead curves.
Tailscale doesn't ask you to model your organization — it asks you to configure a system to approximate it, primarily through your IdP and ACL rules. That configuration is a representation of your organizational structure, not the structure itself. It has to be actively maintained to stay accurate: every new hire, role change, contractor engagement, and offboarding requires a corresponding reconfiguration. The organization changes continuously; the configuration doesn't update itself. The gap between them is where security debt accumulates and where mistakes happen — silently, because a misconfigured ACL looks exactly like a correct one until something goes wrong or someone audits it.
There is a second consequence of this model that is easy to overlook: anyone who can modify the configuration can modify access. That makes IdP admins, helpdesk staff, and anyone with ACL write access into privileged targets. Phishing an admin, social-engineering a password reset, or compromising a helpdesk account can translate directly into unauthorized access grants — because access is controlled by people operating a configuration, and people can be manipulated.
Zsub inverts this. You model the organizational structure itself — people, roles, relationships, trust boundaries — and access arises from that structure directly through attestations. There is no configuration layer to manipulate, because there is no configuration layer. Helpdesk staff don't administer access because access isn't administered — it is a cryptographic property of real relationships between real keyholders. People establish their actual direct relationships, and security is bound to those relationships cryptographically. You cannot social-engineer your way into a trust chain you don't belong to. The human attack surface collapses to the relationships themselves, which is exactly where it should be.
The practical consequence is that Tailscale's operational overhead scales continuously with organizational change, while Zsub's does not. This is not an implementation difference — it is a structural one. Whether initial setup is faster in one system or the other is a genuinely open question; both require you to think carefully about your organizational structure. But after that point the overhead profiles diverge sharply and do not converge again.
Any system that maintains access policy as a configuration separate from organizational structure will accumulate drift over time. This is not a Tailscale-specific problem — it is inherent to the model. Security audits of mature ACL configurations routinely surface permissions that outlived the roles that justified them, access grants nobody remembers authorizing, and rules whose interactions the current team doesn't fully understand. The older the system, the larger the gap tends to be.
Zsub does not accumulate this class of debt because there is no separate policy layer to drift. The trust hierarchy is the access model. What it says at any moment reflects the organizational relationships that exist — not the ones that existed when someone last updated a config file.
The practical summary: setup overhead is plausibly comparable — both require careful organizational modeling. Ongoing overhead is structurally lower in Zsub, not as an implementation optimization, but because the organizational model and the access system are the same thing. One is maintained; the other maintains itself.
This is perhaps the sharpest architectural difference, and it follows directly from the identity model.
Tailscale requires network connectivity to function. The control plane must be reachable to establish connections, distribute keys, and enforce policy. This is not a limitation of Tailscale's implementation — it is a consequence of designing around a centralized coordination model. An airgapped deployment of Tailscale is not really Tailscale.
Zsub is offline-first by design. Because identity and trust are properties of keys, not of a running service, the entire identity and trust layer operates without network connectivity:
The practical consequence: audit logs can transit the live network encrypted to cool keys, meaning nothing on the network can decrypt them. They can only be read on an air-gapped device by someone with deliberate physical access. This is not a configuration option — it is a structural property of the key hierarchy. Similarly, a SeedSigner can generate the root seed and authorize cool-tier operations entirely offline, before a single network packet has been sent. The identity infrastructure is established before the network exists.
For security-critical infrastructure — operational technology, mining facilities, financial systems, physically distributed assets — the ability to establish identity and trust independently of network connectivity, and to keep audit and authorization operations physically isolated from the live network, represents a meaningfully different threat model than anything achievable with a network-first architecture.
Both systems provide forward secrecy. Zsub's Keel protocol uses a double ratchet (Blake3 symmetric, ECDH asymmetric) that provides both forward secrecy and post-compromise recovery — if a session key is compromised, past messages remain protected and future messages recover security as soon as the next ratchet step occurs. Keys rotate continuously at configurable intervals.
Tailscale's ACL model segments access administratively. An attacker who compromises credentials with broad network access retains that access until an administrator explicitly revokes the device via the control plane — which itself must be reachable. Revocation is prompt when it works; it is also a single operational dependency that can be slow, missed, or unavailable.
Zsub trades arbitrary revocation for anchor-free verification: proofs are verified entirely locally, with no call to a revocation service and no availability dependency in the critical path. The tradeoff is managed through attestation lifetime design — short-lived status attestations mean a compromised credential's window is bounded by its expiry, not by administrative response time. There is no revocation oracle to attack, surveil, or take down. Per-relationship key isolation further limits blast radius: lateral movement requires compromising each cryptographic relationship independently, and compromise of a hot-tier key does not expose the trust chain above it.
Tailscale trusts devices that have been enrolled via the control plane. Device identity is WireGuard keypair plus control plane registration.
Zsub's device identity derives from the HD key hierarchy. A device's keys trace back through the organizational trust chain to an accountable human root. Rogue device enrollment requires forging a trust proof — computationally infeasible without the parent key — rather than just gaining access to the enrollment flow.
WireGuard uses static public keys for device identity in its handshake. Those keys are persistent and device-bound, meaning handshakes are linkable across time and across observers — anyone watching the wire can correlate sessions between the same pair of devices even without breaking the payload encryption. This is a deliberate WireGuard design tradeoff for simplicity, not a flaw, but it means the metadata layer tells a story regardless of how well the content is protected. Tailscale does not add obfuscation beyond WireGuard's native properties.
Zsub's Keel protocol handshake is built on a different model entirely. An ephemeral key exchange happens first, establishing an encrypted channel. The Heavy proof establishing mutual trust is then exchanged inside that channel — it is never visible to a third-party observer on the wire. There are no persistent device identifiers in the handshake; an observer sees an ephemeral exchange between two parties they cannot identify, with no information linking it to any previous or future session between the same parties.
A second layer of unlinkability comes from attestation lifetimes: even an adversary who could hypothetically observe proofs would find no stable fingerprint to track across sessions, because attestations expire and renew. The proof presented in one session is not the proof presented in the next.
After the handshake, Keel uses a double ratchet — Blake3 symmetric, ECDH asymmetric — for session encryption. This is meaningfully stronger than WireGuard's static-key-derived session encryption: every message advances the ratchet state, providing forward secrecy and post-compromise recovery as per-message properties rather than per-session ones. If a session key is somehow compromised, past messages remain protected and future messages recover security at the next ratchet step without any re-handshake.
The combination — ephemeral handshake, trust proof invisible to third parties, no stable proof fingerprint across sessions, per-message double ratchet — represents a categorically different threat model for the link layer, not an incremental improvement over WireGuard.
Further layers are added in later phases: Keel uses uniform 512-byte packets to resist traffic analysis by payload size. Phase 6 adds Ramp (multi-hop onion routing) and Submerge+ (path scattering and session multiplexing), extending these properties to the routing and flow layers.
On maturity: Zsub is in active development. Phase 0 (key management, runtime architecture) is complete and in use. Phase 1 (StarfortDB identity + Heavy trust) is near release. Phase 2 (Keel connectivity, NAT traversal, overlay networks) follows. Tailscale is a mature, battle-hardened product. Organizations evaluating Zsub today are evaluating a protocol at an early stage, with the corresponding tradeoffs in tooling maturity, ecosystem, and audit history — though formal audits are underway. All Zsub code is open source.
If the requirement is a reliable, easy-to-operate overlay network for an organization that already has identity infrastructure, Tailscale is an excellent answer. It does exactly what it says, it works today, and its tradeoffs are well understood.
If the requirement is a trust infrastructure that cannot be compromised through a third-party control plane, that operates independently of network connectivity, that encodes organizational accountability at the cryptographic level, and from which secure networking is one of several emergent properties — that is a different question, and Tailscale is not designed to answer it.
Zsub is not a better Tailscale. It is an answer to a different question: what does it look like when identity, trust, connectivity, audit, and organizational accountability are unified in a single cryptographic architecture, with no trusted intermediaries, from seed to session?
Further reading
Zsub whitepaper and protocol specifications: zsubmesh.net/whitepapers/
Source code (Zig, zero external dependencies): codeberg.org/zsub/rebased