What is Enclave?¶
The following covers the high-level differences between legacy connectivity and Enclave.
Legacy VPNs and Identity-Based-Networks function by moving your traffic through a single concentrator before connecting on to the actual resource you want to use, i.e. the classic hub and spoke model:
Classic VPNs have well-documented downsides around scalability, latency, and security on a publicly-exposed endpoint. See VPN Liability for details.
Enclave, on the other hand, uses a peer-to-peer virtual overlay model; instead of having any central concentrator, all connectivity is built directly, between peers, more like this:
This means there is no additional component needed in your network to route traffic, reducing maintenance, bottlenecks, and costs. It also means Enclave never sees your data - it moves directly between your devices - and you get the lowest possible latency.
Enclave is primarily an agent-based solution, where the Enclave agent is installed on each device that wishes to connect to your virtual Enclave Network. There are exceptions to that rule (namely Enclave Gateway), but generally you will need an agent on each device.
Once the agent is deployed and enrolled in your organisation, you define policy that allows it to connect to any other peer in your virtual network, from behind completely closed firewalls. Enclave doesn't require any open ingress ports in order to function, and can be deployed without needing any changes to the existing network.
Enclave vs. traditional VPNs¶
| VPN | Enclave | |
|---|---|---|
| Deployment | ❌ VPN server required Hardware or software at every site |
✅ No infrastructure Works over the network you've already got |
| Firewall changes | ❌ Open ports required (e.g. udp/500, tcp/443, udp/1194) |
✅ No open ports Outbound only. Firewalls stay closed |
| Multi-site management | ❌ Per-site configuration Each site needs its own VPN setup and maintenance |
✅ Managed centrally Policy-driven, no per-site configuration |
| Security | ❌ Allows lateral movement VPN places hosts directly onto the network |
✅ Zero Trust No lateral movement, reduced attack surface |
| Connectivity | ❌ Always on, hub and spoke All traffic routes through a central server |
✅ Direct, on-demand Peer-to-peer tunnels between systems, no backhauling |
| IP management | ❌ DHCP and reservations Static IPs require manual configuration |
✅ Static IPs built-in Private, static IP addresses out of the box |
| DNS | ❌ Bring your own DNS No native support |
✅ DNS built-in No nameservers required |
| Dynamic environments | ❌ Site-to-site requires ACLs Complex isolation for dynamic IPs |
✅ Works with dynamic IPs No need to know where the other side is ahead of time |
What this means for MSPs¶
With a traditional VPN, onboarding a new customer site means shipping or configuring hardware, opening firewall ports, and setting up site-specific VPN profiles. That often requires a site visit or, at minimum, coordinating with someone on-site who can make the changes. Enclave removes that step entirely - the agent installs on the systems that need connectivity and works over the existing internet connection, with no infrastructure to deploy.
Firewall changes are one of the most common sources of support tickets and onboarding delays. Every site has its own firewall, its own rules, and its own way of doing things. Because Enclave uses only outbound connections, there are no ports to open and no firewall rules to write. The customer's firewall stays exactly as it is.
Instead of maintaining a separate VPN configuration for each customer site, Enclave lets you define connectivity through centralised policies. Tags and policies replace per-site ACLs and routing tables, and changes propagate across your entire customer base in seconds. When a customer adds a new office or a new device, you update policy once - not once per site.
The operational difference compounds as your customer base grows. Each new VPN customer adds another set of servers to monitor, certificates to rotate, and configurations to keep current. With Enclave, adding a new customer or a new site is the same lightweight process every time: enrol the systems, apply policy, and connectivity is live. Your operational overhead stays flat instead of scaling linearly with your customer count.
Building connectivity¶
Enclave doesn't need any open ingress ports. Connectivity is built on the principles of ICE (Interactive Connectivity Establishment, RFC 8445), the same framework that underpins direct connections in video calling and WebRTC. A hosted component called the Discovery Service knows the reachable endpoints of both peers, and when policy allows, introduces them to each other. Both peers then use hole punching to establish a direct, end-to-end encrypted tunnel.
Each peer reports connection candidates to the Discovery Service: local network addresses, public addresses (as observed by the Discovery Service), and relay servers as a last resort. Enclave tries all candidates in priority order and uses the best connection that succeeds. When direct connections are not possible — typically due to Symmetric NAT — traffic is forwarded through geographically selected relay servers that cannot decrypt the data passing through them.
For a detailed explanation of NAT traversal, hole punching, connection candidates, and relay servers, see NAT traversal and connectivity.
Info
The V88RY and 968K2 labels in that diagram are unique system identifiers. When a system enrols, Enclave issues it a certificate containing a globally unique Subject Distinguished Name - a short, human-readable identifier used to reference the system in APIs, the portal, and policy. For more on how certificates and cryptographic identity work, see Identity and Cryptography.
Enclave Discovery Service¶
The Discovery Service fulfils two main roles:
- Enabling introductions
- Enforcing policy
As described above, the Discovery Service maintains a connection to both peers and knows their public addresses. When both peers are ready to communicate, and are allowed to communicate, the Discovery Service facilitates the introduction.
Once the introduction has happened, the Discovery Service is no longer required for exchange, only to build new connectivity, so temporary outages of the Enclave platform will not affect existing data pathways.
That allowed to communicate piece brings us to the second part of the Discovery Service's role. When you manipulate policies, tags, enrol, revoke or otherwise manipulate your virtual network configuration in the Enclave portal (or via the APIs), the Discovery Service updates the resultant set of policy for your network.
The resultant set of policy is the outcome of all your configuration, and describes the intended virtual network you wish to establish, including policy options, trust requirements, and any other settings.
When the resultant set of policy changes, the discovery service issues policy updates to any affected peers instructing them to bring up, tear down or amend the ACLs on a connection to another peer.
The Discovery Service also continuously re-evaluates policies applied to systems, to check whether the trust requirements of a policy are still met. If a trust requirement for a policy is no longer met for a peer, the Discovery Service issues the appropriate disconnect instructions if needed, and prevents further introductions until the trust requirement is met.
Enclave propagates policy changes and updates connectivity pathways in less than 1 second after a change in the portal - no waiting for routing tables to refresh or caches to expire.
Further reading¶
- An MSP's guide to ZTNA - what Zero Trust Network Access means in practice and why it matters for MSPs
- SSE vs SASE: a practical guide for MSPs - where ZTNA fits in the broader security architecture landscape
Last updated August 1, 2026