Sign in Get API keys
Concepts

Core concepts

The mental model you need to operate QuickZTNA confidently. If you've used Tailscale or ZeroTier, most of this will feel familiar — with one twist: every tunnel is post-quantum-encrypted by default.

ZTNA (Zero Trust Network Access)

Traditional VPNs treat "being on the network" as identity. Once you're connected, you can reach anything on that network. ZTNA flips this: every connection is verified against identity (who is the user?) and policy (is this specific action allowed?) regardless of the network path. No implicit trust from being inside a perimeter.

In QuickZTNA, "zero trust" is enforced on every packet via ACL rules that key on:

  • User identity — who signed in (email, SSO claims, groups)
  • Device posture — is the machine compliant (OS version, disk encryption, firewall)?
  • Tags — what labels the source and destination machines carry (tag:laptop, tag:prod)
  • Time + day — business hours only, weekends blocked, etc.
  • Geo — source country, CIDR ranges
  • Protocol + port — SSH yes, SMB no

PQC — Post-Quantum Cryptography

Classical Diffie-Hellman (including X25519, which WireGuard uses by default) is vulnerable to a future sufficiently-large quantum computer. Attackers today can capture encrypted traffic and decrypt it later — the "harvest-now-decrypt-later" threat.

QuickZTNA defeats this by running a hybrid key exchange on every tunnel: the classical X25519 ECDH AND NIST's ML-KEM-768 (FIPS 203) in parallel. The pre-shared key injected into WireGuard is derived from both shared secrets: 

PSK = HKDF-SHA256(
  X25519_shared || ML-KEM_shared,
  info = "quickztna-pqc-wg-psk-v1"
)

If a quantum computer breaks X25519 tomorrow, the attacker still can't derive the PSK without also breaking ML-KEM-768 — which the NIST PQC standardization process concluded is quantum-resistant.

PQC is not a plan feature Every tunnel — on every plan, Free included — uses ML-KEM-768. There is no toggle. See security reference for the derivation details.

Tailnet

Your tailnet is the private encrypted mesh of all machines in your organization. It has its own IP space — usually 100.64.0.0/10 (CGNAT range, so it doesn't conflict with RFC 1918 LAN ranges). Every machine gets one tailnet IP at registration and keeps it until deletion.

Tailnets are per-org. Machine A in org acme cannot see machine A in org widgetco even if they have the same tailnet IP — they're on different meshes.

Control plane vs data plane

Two completely separate pipes:

Control plane

Dashboard + REST API. Issues identities, distributes policies, tracks machines. Sees metadata (who connected when, which peers) but never your data traffic.

Data plane

WireGuard peer-to-peer tunnels. Traffic goes directly device-to-device, end-to-end encrypted. Server never sees it. Uses DERP relays only when P2P is blocked.

This split matters for privacy, compliance, and scalability. Traffic between your laptop and your prod DB stays on your WireGuard tunnel — QuickZTNA's servers literally can't read it.

MagicDNS

Every machine in your tailnet is automatically reachable by name at <hostname>.<org-slug>.zt.net. The agent runs a local DNS stub that resolves these names to tailnet IPs without leaking queries to external DNS. 

$ ztna dns query db-primary
100.64.1.12 (db-primary.acme.zt.net)

$ ssh db-primary
# works — resolved via MagicDNS

$ ping db-primary.acme.zt.net
# also works — full MagicDNS name

DERP — when P2P fails

Ideally every peer reaches every other peer directly via WireGuard. But symmetric NAT, CGNAT, and restrictive firewalls sometimes block that. When direct UDP fails, the agent falls back to a DERP relay: a WebSocket-over-TLS server that passes encrypted packets between peers.

QuickZTNA runs 4 global DERP regions:

  • BLR — Bangalore, India (139.59.26.108)
  • NYC — New York, US East (142.93.7.116)
  • LON — London, Europe (142.93.39.6)
  • SFO — San Francisco, US West (137.184.190.98)
DERP never decrypts traffic DERP relays are zero-knowledge — they see encrypted WireGuard packets but never the plaintext. The relay only knows "this packet goes from peer A to peer B"; it can't see either peer's identity or traffic content.

Tags

Tags are arbitrary labels on machines — tag:laptop, tag:prod, tag:ci, tag:eng. ACL rules frequently reference tags instead of hostnames because tags scale: a rule like "engineers can SSH to prod servers" is written once and applies to every tagged device.

Tags are applied at registration (--advertise-tags tag:laptop,tag:eng) or later via ztna set --tags. Admins can also tag machines from the dashboard.

Device posture

Posture signals are health checks the agent reports on every heartbeat: OS version, disk encryption, firewall status, screen lock, antivirus. Admins define posture policies that decide whether a machine is compliant.

Non-compliant machines can be quarantined automatically — their tailnet IP is still allocated but ACL rules that require posture deny all traffic. The user sees a clear message in the dashboard and the agent logs, not silent drops.

JIT access (Just-In-Time)

Instead of permanent access to sensitive resources, a user requests a time-bounded grant (e.g. "SSH to prod-db for 1 hour"). An approver (from a designated approver set) gets a notification; on approval the grant is active for the window and auto-revokes at expiry.

Every JIT request, approval, and revocation is audit-logged. Reports can be exported for SOC 2 evidence.

Organizations + roles

Every resource is scoped to an org (tenant). Users can belong to multiple orgs. Within each org, roles are:

  • Owner — full control, including billing and deleting the org
  • Admin — everything except billing and org deletion
  • Member — can use the tailnet, view own resources, request JIT

Role is enforced at every write endpoint — isOrgAdmin() returns 403 FORBIDDEN for members trying admin actions.

Where to go next

  • Architecture — how the pieces actually fit together at runtime
  • Security — the full crypto story and threat model
  • Glossary — definitions for everything on this page
Previous
Quickstart