Zedmos
SASE MODE · HUB-SPOKE

Distributed enforcement, central policy, continuous failover.

The same engine that runs locally in Console 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 atomic and measured in seconds.

Test phaseEncrypted overlayCentral orchestrationSub-10s failoverIdentity-aware accessMulti-tenant ready
TOPOLOGY

Spokes dial out. Hubs inspect. Policy follows the user.

No new protocols to learn. The Zedmos engine you already understand, wrapped in a managed overlay that connects branches, cloud egress points, and roaming users to a shared policy plane.

TESTIDENTITY SOURCESAD DC AgentAzure GraphSCIM (Okta)pull → user tagsPRIMARY HUBZedmos engine (routed)10.201.0.1/24 · orchestratedactiveBACKUP HUBStand-by engine10.201.1.1/24stand-bystate syncSpoke 1 · HQ10.0.1.0/24tunnel upSpoke 2 · Branch10.0.2.0/24tunnel upSpoke 3 · Remote10.0.3.0/24tunnel upSpoke 4 · Roaduser · roamingtunnel upEncrypted tunnelsegress
CONTINUOUS FAILOVER

When the primary hub degrades, traffic moves before a voice call drops.

The failover daemon runs inside the hub itself — not as a scheduled task. Probes run on a sub-second cadence with a composite score across ICMP, HTTP, and DNS. At threshold, peer and routing changes execute atomically, with no cleartext leak and no peer overlap.

HUB PEER HEALTH · 0–10 sTESTswitchover complete @ 8.2 s0s1s2s3s4s5s6s7s8s9s10sthreshold · 25%primary upprobe 1 failsprobe 2 failsprobe 3 fails — threshold hitpeer swap primary → backup (atomic)routing change committedtraffic flowing through backupProbes: ICMP 250 ms · HTTP /health 1 s · DNS 500 ms · composite score · hysteresis on
ADOPTION PATH

Five steps to a live SASE mesh

01
Stand up the hub backend

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
02
Deploy hub nodes

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
03
Onboard spokes

A spoke can be an OPNsense appliance at a branch, a compact Linux gateway, or a per-user roaming agent. Enrolment is token-based and fully automated from the hub.

  • Zero-touch enrolment for branch appliances
  • Roaming-user agent for hybrid workforces
  • Automatic reconnection and re-keying
04
Connect identity sources

Directory services feed users, groups, and device posture into the hub. Every flow is tagged at inspection time, so policy can distinguish between people, not just addresses.

  • Active Directory via domain-controller agent
  • Entra / Azure AD via Microsoft Graph
  • SCIM integration with Okta and compatible IDPs
05
Enable continuous failover

A sub-second probing daemon runs inside the hub. When the primary degrades below threshold, the backup takes over atomically — no cron, no human, no cleartext leak.

  • Composite health score across ICMP, HTTP, and DNS
  • Hysteresis-aware switching to prevent flap
  • Atomic peer swap with packet continuity
WHEN TO PICK SASE

Best fit

Multi-site organisations
Branch networks, retail, franchises, and hybrid campuses. One policy set, one source of truth, global enforcement.
Hybrid and remote workforces
Roaming users dial into the nearest hub. Identity and device posture travel with the user, not the IP address.
Active-standby high availability
Primary and backup hubs stay in sync. Failover is measured in seconds, not minutes — and no human is in the loop.
Central SOC, distributed enforcement
One SIEM pipeline, one policy set, one identity graph. Global rollouts propagate in seconds across every hub.