Microsoft Sovereign Cloud, October 2026: what Data Guardian, External Key Management and the Sovereign Control Panel change

What was announced, by status

Microsoft points out that availability differs by service, region and SKU and that timelines can change. Before any of these capabilities becomes a prerequisite of an architecture, its availability for the specific service should be confirmed.

Data Guardian and Production Touch Ledger: oversight of Microsoft access

Two existing controls govern when Microsoft engineers may access production systems. Just-in-Time Access grants time-bound access, and Customer Lockbox additionally requires customer approval whenever customer data is in scope. What is new are two steps that apply after approval.

Data Guardian has qualifying remote access by Microsoft engineers to production systems in EU and EFTA regions monitored in real time by European-resident personnel. Production Touch Ledger keeps a tamper-evident record of the actions performed during that access. The Microsoft Learn page on Data Guardian names Azure confidential ledger as the basis for the tamper-evident log.

One detail deserves a closer look. The 20 October announcement refers to oversight by a trusted EU partner. The Microsoft Learn page on Data Guardian, however, describes authorised Microsoft personnel residing in the region. If you need oversight independent of Microsoft for contractual or regulatory reasons, ask for written confirmation of how it is implemented.

Neither capability changes the legal position, for example which authorities can demand access to data. They make technical access more controllable and provable.

More on this: Data sovereignty: assess the architecture, not just the location

External Key Management: the key stays outside Microsoft

With External Key Management the key encryption key remains in an HSM that the customer operates or has a third party operate. Managed HSM remains the Azure-facing service for authorisation and key management, but delegates wrapping and unwrapping of data keys to the external HSM through an EKM proxy run by the customer.

The external HSM, the proxy and the connection are therefore on the critical path. If the external HSM is unreachable, Azure services cannot decrypt the affected data. Microsoft recommends testing availability, failover, key rotation, rewrapping and recovery before production use.

Microsoft Learn describes External Key Management as a last-resort option for organisations with a hard legal or contractual mandate, not as a general upgrade over keys in Managed HSM. For most requirements, customer-managed keys in Managed HSM are sufficient. On 23 October the Learn overview still listed the capability as preview, while the announcement and Azure Updates list it as generally available.

Sovereign Control Panel: evidence from the portal

The Sovereign Control Panel is meant to show the sovereignty posture of an environment in the Azure portal: which controls are in effect, where the gaps are and how to close them. Microsoft structures it into Discover, Control and Act. Portability evaluations add a view of how dependent a workload is on specific services if it has to move to another operating environment.

For audits by internal audit, regulators or customers, this is the most practical part of the announcement. Such evidence is usually assembled today from policy reports, Defender, Purview and spreadsheets. The panel can only be assessed once the public preview is out. Until then, Azure Policy, for example through the Sovereign Landing Zone, remains the basis for enforced requirements.

What this means for Azure customers in Austria and Switzerland

Austria East is in the EU and Switzerland North is in an EFTA state. Both regions therefore fall within the scope Microsoft names for Data Guardian and Production Touch Ledger. The announcement does not say whether a specific service in a specific region is already covered. That has to be checked per service.

Austria East has availability zones but no region pair. Continuity beyond a regional outage requires a deliberately chosen second region, including the question of which services and controls are available there. The new Sovereign Business Continuity guidance and the new management group for Azure Local in the Sovereign Landing Zone address the same question: how to build a workload in the public cloud so that a later move to Azure Local remains possible.

Five questions for your own environment

• Which workloads have a documented requirement for data location, key control or operator access, and where is it recorded?
• Is Customer Lockbox enabled for the affected services, and who in the organisation approves requests?
• Does a contract or a regulator require the key to reside physically outside Microsoft? Only then is External Key Management worth considering.
• Is there a tested recovery into a second region or environment for the most important workloads?
• Are sovereignty requirements enforced through Azure Policy or only described in documents?

Deciding per workload

An architecture review maps each workload to the controls its requirements actually call for and checks whether they are available in the chosen region and for the services in use. The result is a reasoned decision per workload, not a blanket rating of the whole environment. Introducing and running the controls stays with you or your service provider.