Private access (ZTNA)
The access half of SASE: a remote person is bound to your own identity provider, granted the applications their groups say they may reach, and the traffic inside the tunnel meets the policy that would have applied in the office. Not a separate cloud with separate rules.
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.
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.
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.
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.
Four steps, and only the first two need anyone. Keys are generated on each device and never travel; the console distributes the public half and nothing else.
You
One site becomes the hub — usually the one with a fixed address and the room to inspect. Every other site is a spoke; nothing needs a fixed address but the hub. A second hub, direct tunnels between the spokes that need them, or full mesh are the other three shapes, and each one says on the card what choosing it costs.
You
Adding a site to the topology writes the configuration for both ends of the tunnel at once — the spoke and the matching change on the hub — so the two cannot drift apart.
Zedmos
Each spoke establishes the tunnel outbound to the hub. That is why a branch on a consumer line with a changing address works without anyone opening a port for it.
Zedmos
A remote person opens a one-time link and, if you require it, signs in at your own OpenID Connect provider first — a token without a multi-factor claim is refused. Their device makes its own key and is granted the named applications their directory groups allow, not a network. A deadline puts them back in front of the provider; losing a laptop revokes that device and leaves their others working.
Enrolment is a one-time link plus a separate password sent another way. The browser generates the keypair on the user's own machine and sends only the public half. There is no field for a private key anywhere in the system, because there is nothing to put in it.
By default only corporate ranges go through the tunnel. Full tunnel is a switch, and it is built as an explicit list of internet prefixes rather than a blanket default route, so the user's own home printer keeps working and the tunnel's own handshake is never routed back into itself.
Remote traffic lands on the hub and meets the whole engine there: application control, category and URL filtering, IDS/IPS, TLS inspection, data loss prevention and the AI gateway. A spoke used as an exit point forwards and translates; it does not inspect. Knowing which box does the work matters when you size them.
Out of the hub, out of a named site, or out of whichever site is nearest to where the user enrolled. Useful when a service only accepts connections from one country's address space.
Users and groups come from Active Directory, Azure AD or SCIM, and policy selects on them by name. A remote person is bound to your own OpenID Connect provider at enrolment — a token without a multi-factor claim is refused — and the device carries that identity afterwards, so the hub can name the person behind a packet. Their directory groups decide which named applications the hub opens, and a deadline puts them back in front of the provider. On the LAN, the domain-controller agent supplies the same binding for everyone else.
The engine works out what every device is from traffic it already sees — DHCP, mDNS, ARP, user agents, SSH banners — with no agent to deploy and nothing for the user to install. Policy selects on the result: this printer, that class of handset, anything unrecognised. For an enrolled remote device there is a second, separate judgement: the console reads its health from the Microsoft Intune or CrowdStrike Falcon you already run, and can switch the device off at the hub when that system calls it compromised. A machine neither system can speak for reads as unknown and keeps its access, unless you ask for the strict reading.
This page makes the argument. These say how it is actually done, screen by screen and setting by setting.
Every screen and every control in the console's SASE section, with captures: the canvas, node settings, private access, access applications, device posture, SD-WAN and the monitor.
What runs where: hubs, spokes, the overlay shapes, the failover decision, and the four questions private access answers.
What ships today, on which platform, and what is still being built.
Demo & pricing: info@zedmos.com
Request a demo