Microsoft Sovereignty 2026: Technical Architecture & Control Models — Part 9
Event-Driven Reality: What I Learned at Microsoft Digital Sovereignty Day Finland
On May 5, 2026, I attended Microsoft Digital Sovereignty Day Finland at Mall of Tripla in Helsinki. It was a packed room of enterprise architects, compliance officers, and infrastructure leaders — all asking the same question: "What does sovereignty actually look like today?"
The good news: Microsoft has shipped real, operational solutions. The technology works. I spoke with customers running Bleu in France, Delos in Germany, and pilot programs with Azure Local in the Nordics. These aren't theoretical — they're production-grade.
The not-so-ready news: the ecosystem is still crystallizing. National operators have different models and exit terms. Integration points are unclear. And most critically, the operational complexity is being vastly undersold by vendors. Organizations hear "sovereign cloud" and imagine it's like regular Azure but in a different region. It's not. It's infrastructure operations.
This series is what I wish I'd had in my hand at that event. Part 9 covers the technical architecture — the encryption layers, compliance requirements, and operational realities that most vendor presentations gloss over. Part 10 deals with the practical choices: what can you actually disconnect, where are the hard limits, and whether you genuinely need this.
The event clarified one thing: sovereignty is becoming table stakes for certain industries and regions. If you're in finance, critical infrastructure, or public sector in Europe, you'll be asked about this. So let's get specific about what it actually entails.
What's Actually Changed?
Microsoft's sovereignty solutions didn't appear yesterday. They've existed for four years. What changed is geopolitics — and suddenly everyone's asking about them.
The problem is, most of what's being said is either incomplete or marketing-focused. You hear "customer managed keys" and "sovereign cloud" without hearing about the actual operational costs, infrastructure requirements, or the fact that some pieces don't work together the way marketing suggests.
So let's cut through that. Here's what sovereignty actually means, what you need to run it, and whether you actually need it.
Customer Managed Keys: The Reality
Customer Managed Keys means the encryption key lives on your infrastructure, not Microsoft's. If someone — criminal or government — gains access to Microsoft's datacenters, your data remains encrypted and locked.
This is genuinely important. It matters. And you should implement it if you're handling sensitive data.
But it's not a single button.
In an M365 environment with CMK, you need:
- Two separate paid Azure subscriptions (redundancy requirement — you can't use free or trial subscriptions)
- Multiple Azure Key Vaults — up to six if you deploy across different workloads
- Separate onboarding engagement with Microsoft for each workload (Exchange, SharePoint, Teams, etc.)
- Dedicated infrastructure and monitoring
Important: Free, Trial, MSDN, or Legacy Support subscriptions aren't eligible for CMK. This is Enterprise E5-level infrastructure work, not a quick rollout. Budget accordingly.
Here's what it looks like in terms of subscription requirements:
| Component | Requirement | Why |
|---|---|---|
| Primary Key Vault | Paid Azure subscription | Production key storage |
| Secondary Key Vault | Separate paid Azure subscription | Disaster recovery / failover |
| Access Control | Managed Identity or Service Principal | M365 services authenticate to Key Vault |
| Monitoring | Azure Monitor / Log Analytics | Track key access and audit trail |
Cost-wise, you're looking at roughly $240-400/month in Azure infrastructure alone, before any licensing for M365 E5 or professional services to set it up.
Three Levels of Encryption Control
When people talk about "sovereignty," they're usually talking about this spectrum of encryption key control:
| Level | Description | Key Location | Complexity |
|---|---|---|---|
| CMK / Managed HSM | Key is yours, stored in Azure infrastructure | Azure datacenter (FIPS 140-3 Level 3) | Medium |
| BYOK | Generated on your HSM, securely transferred to Azure | Azure after import | Medium-High |
| External Key Management (EKM) | Key never leaves your hardware — Azure calls your HSM for every crypto operation | Your premises (customer-controlled HSM) | High |
External Key Management is the most extreme: your key physically never leaves your hardware. Every single encryption and decryption operation requires Azure to call back to your HSM. You maintain complete control, but you also own the latency and network dependency.
Microsoft partners with Thales, Utimaco, and Futurex to support EKM. If you're serious about this level of control, you need an HSM from one of these vendors on your premises and someone who knows how to run it.
Reality Check: Even with the key physically on your hardware, Azure still intermediates every encryption operation. That network connection always exists. Trust extends further than just where the key sits. You're trading Azure's infrastructure control for your own infrastructure and network dependency — it's a different risk profile, not zero risk.
Double Key Encryption (DKE) is the most extreme model: two root keys, both required to decrypt data. Microsoft alone cannot decrypt your content — you and the key holder must both cooperate. It's theoretically powerful, but practically complex and slower. This is the absolute ceiling of encryption control — and it comes with operational complexity most organizations don't need.
Sovereign Landing Zone: Architecture Foundation
Encryption features alone don't give you sovereignty. You need them working together as a unified architecture that enforces data residency, prevents unauthorized movement, and audits everything.
So here's Sovereign Landing Zone (SLZ) — Microsoft's reference architecture for bringing this all together. It's not just a feature checklist; it's a governance framework that runs on top of standard Azure Landing Zone.
What SLZ Actually Covers
- Data residency controls: Subscriptions locked to specific regions, all data stays within boundary
- Customer Managed Keys integration: CMK in dedicated Key Vaults with strict access policies
- External key management support: Hookup for BYOK (Bring Your Own Key) and EKM (External Key Management)
- Encryption enforcement: Encryption at rest, in transit, and during processing (confidential computing)
- Policy governance layer: Azure Policy + governance rules preventing unauthorized data movement
- Audit and compliance logging: Centralized audit trails for all data access, key operations, and policy violations
- Network isolation: Private endpoints, Virtual Network service endpoints, and regional data boundaries
SLZ Governance Model
The architecture sits on three control layers:
Layer 1 — Identity & Access: Role-Based Access Control (RBAC) with zero-standing access (everything requires just-in-time elevation), Managed Identity for service-to-service authentication without human credentials flowing around.
Layer 2 — Data Plane Control: Customer Managed Keys that we covered earlier — CMK, BYOK, or EKM depending on your control requirements. The encryption happens in the customer's root of trust, not Microsoft's.
Layer 3 — Operational Governance: Policy enforcement that prevents deviation — subscription can't be moved to different region, data can't be exported without explicit audit trail, backup destinations must stay in-country.
SLZ vs. Standard ALZ
SLZ doesn't replace the standard Azure Landing Zone — it builds on top of it. Standard ALZ gives you subscription organization, networking baseline, and cost management. SLZ adds the sovereignty-specific overlay: data residency enforcement, encryption mandates, and audit requirements that go beyond normal operations.
If you're building a serious sovereignty posture, SLZ is your foundation. Turning on individual features without this architecture is like having a good door lock but no walls.
Root of Trust: Who Controls What
Here's something that doesn't get discussed clearly: even with CMK, there's a distinction between the control plane and the data plane.
Data plane: Your encrypted data at rest, encrypted in transit. If you've implemented CMK or EKM correctly, this is yours. Microsoft cannot read it.
Control plane: The service management layer — API calls, policy enforcement, access logs, configuration. Microsoft still manages this. The question is: how much insight does Microsoft need into the control plane?
With CMK, Microsoft still has administrative access to audit systems, network configuration, and infrastructure-level controls. You've protected the data, but Microsoft still controls the environment.
With EKM or DKE, you push the control boundary further — Microsoft's engineers cannot decrypt your content even if they access the infrastructure. But they still manage the service lifecycle, updates, and availability.
CMK doesn't achieve "complete isolation from Microsoft" — that's not its job. What it actually does: prevents infrastructure-level compromise from exposing your data keys. A corporate-level CLOUD Act order? CMK doesn't solve that. You need different layers for that: DPA/Data Guardian at the legal level, EKM at the technical level, national operators at the jurisdiction level. No single control solves all of this.
FIPS 140-3 Level 3 and What It Actually Requires
You've seen the claim: "FIPS 140-3 Level 3" hardware. What does that mean practically?
FIPS 140-3 is a US government cryptographic standards publication. There are four implementation levels:
| Level | Requirements | Where You See It |
|---|---|---|
| Level 1 | Basic cryptographic algorithms. No tamper detection. | Commodity software |
| Level 2 | Role-based access control, tamper detection | Smart cards, basic HSMs |
| Level 3 | Physical tamper evidence, critical security parameters are encrypted, identity-based access | Enterprise-grade HSMs (Thales, Utimaco) |
| Level 4 | Active tamper response (physically destroys keys if breach detected), withstands extreme environmental conditions | Military and classified government use |
Level 3 means the hardware will show evidence if it's been tampered with, and all sensitive data on the device is encrypted. That's why Azure Managed HSM and customer-owned HSMs for EKM require Level 3 — it's the compliance baseline that actually matters.
Level 4 is overkill for most commercial use and adds significant complexity.
Important Note: FIPS 140-3 is newer than FIPS 140-2 (which most deployments still use). If you're evaluating HSM vendors or Azure services, check which level they're certified at and when that certification was issued. Older hardware may only meet 140-2.
Industry-Specific Sovereignty Mandates
Not all industries care equally about sovereignty. Some have explicit legal requirements:
Healthcare (HIPAA, GDPR)
HIPAA doesn't explicitly require data to be in the US or CMK to be enabled. But it does require "encryption of data at rest" and "access logging." CMK + Data Guardian + audit trails satisfy HIPAA requirements. GDPR adds the dimension that EU data must have EU-level protections — which is where CMK + data residency enters the picture.
Financial Services (PCI-DSS, Basel III)
PCI-DSS (for payment card processing) requires strong encryption but doesn't mandate CMK. However, banks increasingly adopt CMK as a control to satisfy audit requirements for "proof that even the cloud provider can't access our data." Basel III compliance is more about operational resilience and doesn't explicitly require CMK, but regulators like the Fed appreciate seeing it.
Critical Infrastructure & Defense (CMMC, EAR)
Critical infrastructure (utilities, energy, telecommunications) often falls under government oversight and may be subject to EAR (Export Administration Regulations) or ITAR (International Traffic in Arms Regulations). These can mandate sovereign infrastructure — data cannot leave specific jurisdictions, HSM keys cannot be held by foreign entities, and full control must remain in-country. CMK/EKM + Azure Local are the only way to meet these mandates.
Government (FedRAMP, IL5/IL6)
US government agencies require FedRAMP Impact Level 5 or 6 for classified data. This mandates on-premises infrastructure, cryptographic controls, and no cloud services. This is where Azure Local or fully disconnected environments become mandatory, not optional.
The Operational Reality: HSM Staffing & Performance
Here's what vendors don't emphasize: running EKM or BYOK at scale requires operational expertise and dedicated staffing.
HSM Staffing & Expertise
If you're deploying Thales, Utimaco, or Futurex HSMs on your premises for EKM, you need:
- 1-2 full-time personnel trained on HSM operations (vendor certification recommended)
- Key management procedures: generation, backup, rotation, disaster recovery
- Network isolation for HSM connectivity (it can't be on a standard network)
- Physical security (HSM should be in a controlled room, not a random server cabinet)
- Monitoring and alerting for HSM health, key usage, and tampering
This isn't something your Azure team can handle. You need cryptography specialists.
Performance & Latency
When Azure calls your HSM for every encryption and decryption operation, latency happens. A local HSM might add 10-50ms per operation. At scale (millions of transactions), this compounds.
- Exchange Server with EKM: Search operations slow down because every email metadata lookup triggers encryption/decryption.
- SharePoint with EKM: File operations (upload, download, preview) incur HSM latency.
- Teams with EKM: Message search and compliance operations are impacted.
Microsoft publishes HSM vendor recommendations, but real-world deployments report that organizations often accept performance degradation as the cost of sovereignty.
Backup & Disaster Recovery
Here's a problem that surprises many organizations: if your on-premises HSM fails, can you recover? If you're running EKM with the key never leaving your hardware, there's no cloud backup of the key. You must maintain a separate HSM for failover, and you must manage key backup policies that satisfy your compliance requirements.
Honest Assessment: Some organizations implement CMK (key in Azure) because EKM is too complex operationally. CMK is the 80/20 choice: you get sovereignty over the key without the staffing and performance burden of running your own HSM.
What's Next
So far we've covered the encryption architecture. Part 10 gets into the hard reality: Sovereign Private Cloud, what actually works disconnected from Microsoft's cloud, the operational limitations, and whether you actually need any of this.
Coming in Part 10: Sovereign Private Cloud (Azure Local, M365 Local, Foundry Local), what's genuinely disconnected vs. what still needs a cloud connection, multitenancy gaps, and a practical decision framework for your organization.