Sovereign and self-hosted options in SASE: what vendors describe

Some organizations must keep traffic inspection, logs or keys inside a country or inside their own facilities. Public sector bodies, defence suppliers and some regulated industries face rules like these. For them, a cloud-only service may be ruled out, or acceptable only in certain regions.

Fortinet describes a "FortiSASE Sovereign" option deployed "by end users in their own data centers", alongside agent-based and agentless access and thin edges.

Source: Fortinet FortiSASE

Fortinet's FortiAIGate is also described as self-hosted, with data and logs on the customer's infrastructure.

Source: Fortinet FortiAIGate

Cato describes protection for homegrown AI applications "through the Cato cloud, the AI gateway you already run, or on-prem with Outposts".

Source: Cato AI security

Its SASE service itself is described as a cloud service on its own backbone.

Source: Cato global private backbone

Netskope states its NewEdge locations include Mainland China, with all SASE services in every location.

Source: Netskope NewEdge

That is a regional answer rather than a self-hosted one.

Palo Alto Networks, Zscaler and Cisco do not describe self-hosted or sovereign SASE options on the pages we read.

Running the service in your own data centers brings back some of the work a cloud service removes: capacity planning, hardware, upgrades and, depending on the model, patching. It may also limit which features are available, since some functions rely on the vendor's shared cloud for threat intelligence or scale. Ask the vendor for a feature comparison between its cloud and sovereign editions, and who patches what.

If your rules are about data residency rather than physical control, a cloud service with in-region processing and logging may meet them with less effort. Ask where inspection happens, where logs are stored, where keys are held, and whether support staff in other countries can access your data. Combine the answers with the certifications each vendor lists.

Our question is about the least operational overhead, which favours services the vendor runs. Sovereign options are still valuable, so they score under deployment options, which carries 10% of the total. The weighting lab has a must-have filter for platforms that describe a self-hosted or sovereign option.

Many enterprises will run both: a cloud service for most users and sites, with a sovereign or self-hosted deployment for a restricted environment. In that case, one policy model across both matters more than the location of any one component. Ask to see a rule applied in both places.

Sovereignty questions often turn on two details: where inspection logs are stored and who holds the keys used to decrypt traffic. A service can run in a region and still copy logs elsewhere for analytics or support. Ask for a data flow diagram that shows where each type of data goes, how long it stays and who can reach it, and keep it with your compliance records.

Also ask how the vendor handles lawful access requests from authorities in the countries where it operates, and whether it publishes a transparency report. Those answers sit outside the product, but they often decide whether a legal team signs off on a cloud service.

Sovereign and self-hosted options exist, but on the pages we read they are described by few vendors and they bring back operational work. Decide whether your rules require physical control or only regional processing before you weight this criterion.