Navigating the Spectrum of Sovereignty: A Strategic Guide to Public Cloud
The UK cloud landscape is undergoing a significant shift. With the Cyber Essentials Plus 2026 reset, the NCSC Secure by Design mandate, and the requirement for UK National Security vetting (SC/DV), the definition of sovereignty has moved beyond simple data residency.
For organisations in high-stakes sectors, "Native Cloud Sovereignty" involves using public hyperscalers while wrapping data in a robust digital boundary of encryption, policy, and governance. This approach allows access to higher-order PaaS and SaaS services while maintaining the control required for regulated environments.
The Three Pillars of Native Sovereignty
To achieve a sovereign posture in a public environment, three key drivers must be addressed.
1. Data Sovereignty (Regional Isolation)
This ensures data never leaves a specific jurisdiction. All major platform vendors provide services out of global regions. Sovereignty is achieved by choosing specific regions—such as London (europe-west2)—and enforcing policies that prevent teams from deploying workloads outside of these boundaries. These regions are typically configured in resilient pairs to ensure availability and disaster recovery without compromising residency.
There is, however, a critical caveat: not all providers offer their full suite of higher-order services in every region. Many vendors prioritise "favouring" specific regions for new feature releases, which can result in a significant time lag before those capabilities become available in your specific tenancy.
2. Operational Sovereignty (The People)
This is best understood through the "above the line/below the line" principle. Above the line represents your organisation: the staff you have vetted, authorised, and manage directly. Below the line represents the hyperscaler personnel who support the underlying hardware and software.
Because these individuals are not your employees, a sovereign strategy requires absolute visibility into the vendor support model. You must verify where support is located, the specific level of vetting held by their engineers, and whether foreign nationals have access. Without this clarity, you cannot ensure compliance with UK-specific regulations or guarantee that your "Above the Line" security remains uncompromised by the people managing the platform's foundation.
3. Technical Sovereignty (The Keys)
True sovereignty requires a "kill switch" through encryption. While platforms offer native keys, achieving technical sovereignty necessitates Bring Your Own Key (BYOK) or External Key Stores (XKS). By storing root keys in a physical Hardware Security Module (HSM) outside of the cloud provider’s infrastructure, the data remains unreadable to the vendor. Further security can be achieved through Confidential Computing enclaves and Key Access Justifications (KAJ).
Hyperscaler Comparison Matrix
The following table provides a strategic overview of how the primary providers deliver these pillars in the UK market.
| Pillar | Google Cloud (GCP) | Microsoft Azure | AWS | Oracle (OCI) |
|---|---|---|---|---|
| Isolation | Assured Workloads: Logical isolation pinning data to UK regions via policy. | Sovereign Cloud: Logical isolation and Entra ID tenant boundaries. | AWS ESC & Nitro: Physical and logical separation with hardware security. | Sovereign Realm: Dedicated UK realm physically isolated from commercial cloud. |
| Personnel | Assured Support: Support routed to staff meeting location and vetting criteria. | Sovereign Operations: Explicit customer approval required for maintenance. | Local Residents: Operations restricted to vetted residents (ESC model). | UK-Only SC: Exclusively UK-resident and SC-cleared personnel. |
| Encryption | External Key Manager (EKM) with Key Access Justifications (KAJ). | Customer-Managed Keys (CMK) and Confidential Computing Enclaves. | External Key Store (XKS) and Nitro Enclaves for data in-use. | External KMS with mandatory hardware-based isolation. |
Detailed Vendor Approaches
Google Cloud: Policy-Driven Residency
Google Cloud utilises Assured Workloads to enforce predefined policies. For UK customers, this package ensures customer-selected data at rest and support metadata are pinned to the London region. Their differentiator is Key Access Justifications (KAJ), which provides a granular "why" whenever an encryption key is requested. By using an External Key Manager (EKM), keys can be stored in a third-party, UK-based HSM outside of Google's infrastructure.
Microsoft: No Access by Default
Launched in 2025, the Microsoft Sovereign Cloud uses Regulated Environment Management to configure security features. Their strategy relies on the principle that the provider should have no access by default. This is bolstered by Confidential Computing, which utilises Intel TDX and AMD SEV-SNP hardware to encrypt data in RAM. Even with physical access to the server, an administrator cannot read data while it is being processed.
AWS: Hardware-Level Security
The AWS European Sovereign Cloud (ESC), available in 2026, offers a physically separate partition from global infrastructure. The foundation of this isolation is the Nitro System, which uses purpose-built hardware to create a security boundary. Nitro prevents any AWS employee from accessing customer data in memory or on disk. Their External Key Store (XKS) allows for a physical "kill switch" located on the customer's premises.
Oracle: The Sovereign Realm
Oracle’s approach differs by using a Realm architecture. The Oracle UK Sovereign Cloud exists in its own separate Realm, meaning identities and support tickets never leave the UK boundary. Residency is maintained through dual regions in London and Newport (Wales). Uniquely, their support is provided exclusively by UK-resident personnel who hold SC clearance, offering a higher level of assurance for Official-Sensitive workloads.
Conclusion
The choice of hyperscaler depends on specific business and regulatory needs. While some organisations may prioritise the physical separation offered by Oracle, others may require the specific PaaS capabilities of AWS or the policy-driven controls of Google. A multi-cloud strategy is often the most resilient approach, ensuring that regional failures do not impact critical operations.
For many, the next challenge is managing workloads that cannot leave the premises. The upcoming analysis in this series will explore Hybrid Cloud and how to connect on-premise air-gapped infrastructure with hyperscale providers without facing vendor lock-in.
Is your cloud strategy aligned with the 2026 security mandates?
Defended Solutions provides board-level strategy and fractional CTO guidance to de-risk digital transformation in regulated industries. Contact us today for a conversation on how to remain compliant in the cloud.
Frequently Asked Questions
What is the NCSC Secure by Design mandate?
The NCSC Secure by Design mandate requires that cyber security is integrated into the heart of a system from the start of its lifecycle, rather than being added as an afterthought. It is now a critical requirement for UK government and MoD digital projects.
How does AWS Nitro support UK National Security vetting?
The AWS Nitro System uses hardware-level isolation to physically prevent any cloud provider employee from accessing customer data. This "human-out-of-the-loop" model provides high levels of assurance for workloads requiring SC or DV clearance by reducing the risk of unauthorised internal access.
What is the significance of the Cyber Essentials Plus 2026 reset?
The 2026 reset updates the standards for how organisations must secure their infrastructure. For sovereign cloud users, it places a significantly greater emphasis on identity management, regional data controls, and the strict auditing of personnel who hold administrative access to the platform.
