Distributed enforcement, central policy, automatic failover and failback.
The same engine that runs on a single box in standalone mode runs at your hubs in SASE mode. Spokes dial in over an encrypted overlay. Policy enforces at ingress. Identity travels with the user. Failover is automatic: the console waits out a configurable silence threshold, confirms with a health check, then moves every spoke in one operation.
Four shapes, one overlay. The estate decides which.
No new protocols to learn: the Zedmos engine you already understand, wrapped in a managed overlay that connects branches, cloud egress points and remote people to a shared policy plane. Which shape it takes is a choice on the canvas — one hub, a hub pair, direct tunnels between the spokes that need them, or every site to every site. Where both ends of a pair sit behind a NAT that rewrites ports, a relay in the console's own stack carries the packets without ever holding a key.
Hub and spoke
Everything reaches one place. Start here unless you have a reason not to.
Traffic between two sites takes the long way round — and is inspected on the way.
Dual hub
An outage at the hub site must not take the other sites with it.
A second listening hub to run. It holds host routes only until it is needed.
Spoke shortcut
Two sites talk to each other enough that the detour costs real time.
That pair's traffic stops passing the hub, so it stops being inspected there.
Full mesh
Every pair talks to every other. Capped at eight sites.
Every site carries a peer for every other, and one node still brokers the pairs.
When the primary hub stops answering, the console moves the sites — and moves them back.
The console's monitor watches each primary hub's agent link. After the topology's silence threshold it moves every spoke to the backup hub in one operation, and moves them back after the primary has been healthy for a stable window. You can also trigger the swap yourself, with a preview of exactly what will change.
Four questions about every connection, not one.
A key proves a device, and nothing more. Remote access here answers four things instead: who the person is, what they may reach, whether that is still true today, and what state the machine is in. Those are four of the five claims the industry files under ZTNA 2.0 — the fifth, one data policy that reaches into SaaS tenants, we do not make: inspection is inline, so what passes the hub is inspected and what already rests in a SaaS tenant is not.
Who the person is
Enrolment can require a sign-in at your own provider before a key is ever generated, with multi-factor demanded through the token's amr claim. The device carries that identity afterwards, and the hub can name the person behind a packet.
What they may reach
An access group grants named applications — an address and the ports it answers on — rather than the network the service sits on. The hub writes one rule per application per person and drops the rest, and the client is told to route only what it may reach.
Whether it is still true
A deadline puts the device into re-authentication, a reminder goes out, and when it passes the device is switched off at the hub until the person signs in again. A directory that reports the account disabled does the same, without waiting for the deadline.
What machine they are on
Device posture is read from the management system you already run — Microsoft Intune or CrowdStrike Falcon — and never from an agent of ours. A machine reported non-compliant is switched off and let back in by itself once it is healthy; a machine nobody can speak for keeps its access unless you ask for the strict reading.
What this is not: there is no reverse proxy and no browser-only access, so every person connects with a standard WireGuard client and grants are per application rather than per URL. Nothing scores behaviour. Allowed traffic is still inspected at the hub — intrusion prevention, URL filtering, TLS inspection, data-loss prevention — which is the part most access brokers leave out.
Five steps to a live SASE overlay
A hardened orchestrator manages topology, policy distribution, identity mapping, and failover. It runs on a single node for smaller deployments or as a redundant pair for production.
- Multi-tenant-ready topology model
- Hardened data store with role-based access
- Central source of truth for policy and identity
Hub nodes host the Zedmos engine in routed posture with a dedicated encrypted interface. Every spoke flow passes through DPI, policy, TLS inspection, and logging at the hub.
- Same engine as Console — one binary, one behaviour
- Inline DPI and policy enforcement at ingress
- Primary and backup hubs ship as an active-standby pair
A spoke can be an OPNsense or pfSense appliance at a branch, a compact Linux gateway, or a remote user with a standard WireGuard client. Appliances register with a token; remote users enrol with a one-time link.
- Token-based registration for branch appliances
- Standard WireGuard clients for remote users
- Automatic reconnection and re-keying
Directory services feed users, groups, and recognised devices into the hub. Every flow is tagged at inspection time, so policy can distinguish between people, not just addresses. A separate connection binds a remote person at enrolment: your own OpenID Connect provider, with a multi-factor claim demanded before a key exists.
- Active Directory via domain-controller agent
- Entra / Azure AD via Microsoft Graph
- SCIM integration with Okta and compatible IDPs
- Your own OpenID Connect provider for enrolment, MFA required
- Device health from Microsoft Intune or CrowdStrike Falcon
Opt in per topology: the console watches the primary hub's agent link and, after the silence threshold and a health check, moves every spoke to the backup hub. Failback is automatic once the primary has been stable.
- Silence threshold and cooldown per topology
- Preview before a manual swap
- Automatic failback to the preferred hub