Nothing has to leave your jurisdiction
The question is not only where your traffic is inspected. It is where the point that decrypts it sits — and where everything the system writes down about you ends up.
What actually crosses a border
In a conventional SSE, your traffic is decrypted inside a vendor's point of presence. Even when that PoP is in your country, the control plane usually is not: policy, device inventory, audit records, identity mappings and operational telemetry live in the vendor's cloud, under the vendor's jurisdiction and reachable by that jurisdiction's legal process.
The distinction disappears because the wrong question gets asked and answered. "Do you store our traffic?" is easy to say no to. The one that decides sovereignty is what do you keep, and where does it live — and the metadata is the part that quietly leaves.
Three things, all of them yours to place
- The decryption point. The Edge terminates TLS. It runs on hardware you own or in a region you chose, and there is no path through anyone else's.
- The control plane. Policy, the identity and non-human-identity registry, admission and revocation. It sits beside your Edge, not in our cloud — because we do not have one.
- The record. Every decision is audited as metadata, and that audit is written where your deployment writes it. It is not shipped anywhere to be useful.
The certificate authorities belong on that list too: they are generated on your machine at install time rather than issued to you, so the root of trust for your fleet never existed outside your control in the first place.
Multi-region is what makes residency more than a preference
Placing one deployment in one country is the easy case. An operator serving several countries needs each customer's traffic decrypted, and each customer's records written, inside that customer's country — while still running one service.
That is what the residency boundary is for: revocation scoped to a region rather than replicated globally, an identity mesh across regions that does not require pooling the identities, per-region interception roots so one region's decryption authority is not another's, and geo-steering so endpoints reach the edge they are supposed to reach. It is in the open-source scope, not a commercial tier — the status page says what has actually shipped.
Stays inside the region
Written there, read there, and never replicated outward.
- Decrypted trafficIt exists only at the edge that decrypted it.
- Audit recordsWritten where that deployment writes them.
- The interception rootOne region's decryption authority is not another's.
- Device inventory and posture
Crosses between regions
The short list, and the reason the boundary is a boundary.
- Identity assertionsThe mesh carries the claim, not the identity store.
- Revocation, scopedThat a credential is refused, where that applies — not a global replica.
- Where an endpoint should steerSo a device reaches its own region's edge.
What we can see: nothing
There is no licence server and no phone-home. A deployment that cannot reach us keeps working. We do not receive your policy, your device inventory, or your audit log.
That is not a commitment in a privacy policy, which is a document a vendor can revise. There is no code path for it — search the published source for a destination belonging to us and you will find none. A promise you can grep is a different kind of promise.
What this does not do
Worth saying, because sovereignty is exactly the topic where a vendor is most tempted to let you assume more than was claimed.
- It does not make your other relationships local. An external identity provider, an upstream resolver, the SaaS your users actually visit — those remain wherever they are. What changes is that the decryption and the record no longer add another country to that list.
- It does not decide your compliance question. Residency requirements differ by country, sector and contract, and nothing on this page is legal advice. What the product supplies is the ability to place things — not an opinion about where yours must go.