00 · Sovereignty
Four of the largest software companies on earth now ship a product with "sovereign" in its name. None of them mean the same thing by the word. None of them mean what the customers buying them think the word means. This page is the test. Five binary questions, sourced to each vendor's own public architecture documentation, with the verdict and the rationale on every line. If you can't point to the specific mechanism that makes each of these true, the product is not sovereign — no matter what the homepage says.
01 · The five-point definition
Each point is binary. Each one has a single mechanism that either does or does not exist in the product. Each one is verifiable by reading public architecture documentation or the source. There are no exceptions for "but the customer can opt in to…" or "in the future we plan to…"
The runtime makes no outbound network calls. Ever. Not for licensing, not for telemetry, not for control-plane heartbeat, not for crash dumps. If you unplug the cable, the gate keeps running.
The keys that authorize destructive actions are generated on customer hardware that the customer physically possesses, and never leave it. Not held-by-vendor. Not held-in-vendor-HSM. Held by the customer.
The runtime is open source under a license the customer can audit, fork, and rebuild from. Closed-source binaries are not sovereign. "Reference architecture available under NDA" is not sovereign.
Every decision lands in an append-only, hash-chained log on customer storage. Evidence is not shipped to a vendor SaaS for retention. The customer's auditor reads the customer's chain.
A single binary the customer deploys to their own machines, in their own network, under their own change-management. Not a managed service. Not a tenant in someone else's cluster. Yours.
02 · The rubric, applied
Each row is a product that uses the word "sovereign" in its name. Each column is one of the five mechanisms above — numbered legend below the table.
| Product | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Espada Sovereign Infrastructure Agent | ✓ | ✓ | ◐ | ✓ | ✓ |
| Microsoft Sovereign Cloud Azure | ✗ | ◐ | ✗ | ✗ | ✗ |
| AWS European Sovereign Cloud AWS | ✗ | ◐ | ✗ | ✗ | ✗ |
| Google Sovereign Controls Assured Workloads | ✗ | ◐ | ✗ | ✗ | ✗ |
| Salesforce Sovereign Data Cloud Salesforce | ✗ | ✗ | ✗ | ✗ | ✗ |
Meets Partial Does not meet
Azure services maintain control-plane connections to Microsoft endpoints. Azure Dedicated HSM and the Hold-Your-Own-Key option exist (criterion 2 partial), but the HSMs are racked in Microsoft facilities and operated by Microsoft personnel. The runtime is closed source. Audit substrate is Azure Monitor / Sentinel. Hardware is Microsoft's, even in the "Sovereign Landing Zone" and Azure Local SKUs.
Service endpoints remain reachable from inside the customer's VPC. KMS imported-key material and CloudHSM are available (criterion 2 partial), but the HSM cluster lives in an AWS facility under AWS operator access. AWS services are closed source. CloudTrail is the audit substrate. Hardware is AWS-owned and AWS-operated, including the announced EU sovereign region.
GCP control plane reachable from the workload. Cloud KMS with External Key Manager (Thales, Fortanix, etc.) is offered (criterion 2 partial), and partner-operated builds (T-Systems Sovereign Cloud, Thales Sovereign Cloud) shift physical operations away from Google — but the software stack, audit substrate (Cloud Logging), and source remain closed and remote.
A SaaS data product. The runtime is Salesforce's. The keys are managed within Salesforce's KMS. The source is closed. The audit substrate is Salesforce's. The hardware is Salesforce's. The customer's only sovereign control is regional residency.
03 · The pattern
Three of the four hyperscaler products score the same: FAIL on four out of five, PARTIAL on the key question. The pattern is consistent because the product is consistent — each is a managed service that offers a customer-key option layered over a vendor-operated runtime. The customer can pick where their data sits and who holds half of the key envelope. The runtime is still the vendor's. The audit is still the vendor's. The hardware is still the vendor's.
Salesforce Sovereign Data Cloud is the honest case: it does not pretend to offer a customer-operated mode. It is a SaaS with regional residency, sold to customers who need to say the data did not leave the EU. That is a useful product, but it is not sovereignty.
Espada is the only product on this page that scores PASS on all five — and that is not a marketing fact. It is the consequence of three architectural decisions we made before the runtime shipped:
Until those three statements are also true of the other products in the table, the word is doing work it cannot do.
04 · Methodology
Every PASS, FAIL, and PARTIAL on this page is sourced to the vendor's own public architecture documentation as of the publication date below, or — for Espada — to the commit hash of the runtime in this repository. We do not cite analyst reports, marketing pages, or sales decks. We cite the diagrams the vendors' own engineers publish for their own engineers.
A PARTIAL on criterion 2 reflects that the vendor does offer a customer-key option: Azure Dedicated HSM / Hold-Your-Own-Key, AWS KMS imported key material / CloudHSM, Google Cloud EKM with third-party HSM. We count these as partial because the underlying HSM is operated by the vendor or a vendor partner, not by the customer in a facility the customer physically controls.
If a vendor disputes a finding, email sovereignty@espadafirewall.com with the specific cell, the architecture document or published mechanism that contradicts the verdict, and the date of that document. We will update the cell, append a dated changelog at the bottom of this page, and credit the correction.
First published 2026-05-25. Next scheduled review 2026-08-25. No corrections received.
One binary. One install. One hour to your first signed action.