Cloud Computing Köln

External key management for Azure Managed HSM is now in public preview

Azure Key Vault Managed Hardware Security Module (HSM) provides strong sovereignty over your encryption keys. Keys are generated and stored in a single-tenant, FIPS 140-3 Level 3 HSM that only you control: Microsoft has no access to your key material, and you govern who can use each key. For most organizations, including those with stringent regulatory requirements, this level of control is sufficient.

Some organizations have a further requirement: the hardware that holds their key must reside physically outside Azure datacenters. External key management for Azure Key Vault Managed HSM is now in public preview to address that requirement, delivering on a commitment made a year ago.

Try External key management for Azure Key Vault Managed HSM

How Managed HSM delivers sovereignty today

Before looking at external key management, it’s worth being precise about the sovereignty Managed HSM already provides. Managed HSM is a single-tenant service: each instance is a dedicated cluster of FIPS 140-3 Level 3 validated HSM partitions for each customer—built on Marvell LiquidSecurity adapters. Keys are generated inside that hardware and never leave it in plaintext, making the keys inaccessible to Microsoft operators.

Control rests with you, not Microsoft:

Customer-specific security domain. Each HSM cluster is cryptographically isolated by a security domain that you generate and own. Microsoft can’t decrypt your key material or recover your HSM cluster without it. You are in full control of the security domain as it’s protection and safeguarding is outside of Microsoft.

Multiperson control. The security domain is protected by a quorum of RSA key pairs that you hold offline. Recovery requires your quorum, so no single person—and no Microsoft operator—can act alone.

Local role-based access control (RBAC). A data-plane authorization model, independent of Azure RBAC, governs who can perform each cryptographic operation.

Key attestation. You can obtain cryptographic proof that a key was generated and is used within the FIPS 140-3 Level 3 hardware boundary.

Managed HSM is built on FIPS 140-3 Level 3 HSMs and confidential computing technology based on Intel SGX, so request handling, access control, and key material are isolated in hardware enclaves and HSMs that no Microsoft operator—even one with administrative or physical access to the host—can read. Managed HSM provides redundancy, isolation, and protection—giving organizations the sovereignty assurances they need without compromising on key security, operational overhead or availability.

What external key management adds

Managed HSM already provides full customer control over your keys, with enterprise-grade availability, security, and operational simplicity. External key management adds one capability: the option to keep your key material on an HSM that you own and operate, either on-premises or with a trusted third party, completely outside Microsoft infrastructure.

External key management is designed for scenarios where regulation or contractual obligations mandate the cryptographic keys must reside outside the cloud provider’s environment. These requirements are sometimes found in highly regulated sectors such as government, financial services, and critical infrastructure, and in jurisdictions with strict data-sovereignty rules. External key management ensures the root of trust and key material remain on hardware you own and operate, outside Microsoft infrastructure, and under your direct physical control.

However, this model should only be adopted deliberately and only when required. For most workloads, Managed HSM keys remain the recommended approach, delivering higher native availability, reduced operational complexity, and a security posture that meets or exceeds sovereignty requirements without introducing additional risk or overhead. External key management is about meeting specific regulatory constraints, not increasing baseline security. When those constraints do not apply, Managed HSM provides a stronger, more reliable, and more operationally efficient solution.

How it works

External key management extends Managed HSM through a dedicated API endpoint that connects directly to the HSM you control. It allows cryptographic operations in Azure to invoke external key material without changing how applications interact with the service. The external key never resides in or passes through Microsoft infrastructure; only your hardware uses it. Because you control that hardware, you can disconnect it at any time to halt all cryptographic operations.

Integration is transparent to applications. Applications continue to use Managed HSM and the Azure Key Vault API with the customer-managed key envelope encryption pattern unchanged. When an data access requires your external key to decrypt local data encryption keys, Managed HSM forwards it to your hardware and returns the result.

You choose the hardware and partner. Because the external key management API is an open specification, you decide how to implement it. Your hardware, your partner, or your implementation.

All connections are mutually authenticated and encrypted. Traffic between Azure and your hardware is secured with mutual TLS, ensuring a secure and trusted connection between Azure and your HSM.

HSM ecosystem

A growing ecosystem of HSM vendors support integration with the Managed HSM external key management API, as many providers are actively enabling compatibility for their platforms.

Microsoft doesn’t build or operate the connecting integration proxy itself. Instead, you benefit from an open model: you can use a vendor provided implementation, reply on a partner to operate it, or build your own.

Responsibilities and tradeoffs

External key management deliberately shifts a portion of operational responsibility to you. This is the direct consequence of extending the trust boundary beyond Azure: you gain control over the root of trust, and with it, ownership of the systems that enforce it.

Availability of your hardware. The Managed HSM SLA applies up to the point Managed HSM calls your external HSM proxy. Availability of your proxy and HSM is your responsibility. Any disruption on your side directly impacts cryptographic operations and Azure service data accessibility.

Scope of operations. External key management focuses on the operations used to protect data at rest. It does not expose the full set of key operations available with Managed HSM keys, reflecting a deliberate trade-off between control and functionality.

Hardware operations. Provisioning, securing, scaling, monitoring, and recovery of your proxy and HSM become your responsibility, whether operated directly or through a partner.

Error transparency. Failures originating on your side of the connection are surfaced in Managed HSM logs, but remain your responsibility to diagnose and resolve.

This is the core trade-off: more control means more responsibility.

Public preview scope

Availability: all Azure public regions at preview launch.

Access: gated. Your Microsoft account team enables external key management on your Managed HSM—contact them to request it.

Use case: protecting data at rest for Azure services that support customer-managed keys with Managed HSM.

Pricing: standard Managed HSM pricing, with no additional Microsoft surcharge. You cover the cost of your own hardware and any partner licensing.

Get started

Start with: What is Managed HSM external key management?

Review the SLA and shared-responsibility model

Try the Azure CLI quickstart

External key management is the latest step in giving customers granular control over how and where their keys are protected. During public preview, your feedback will directly shape the feature on its path to general availability — including the operational guidance, vendor integrations, and scenarios we prioritize next.

Take control of your encryption keys

Explore external key management for Managed HSM and keep your key material outside Azure while maintaining secure, scalable operations.

Get started

The post External key management for Azure Managed HSM is now in public preview appeared first on Microsoft Azure Blog.
Quelle: Azure

Built to bounce back: How Azure resiliency evolved

In this article

Resiliency as a shared responsibility, not a handoffPlatform foundations that reflect reality: zones, regions, and sovereigntyAzure features and capabilities strengthen resiliency outcomesBridging intent to execution through experiences on AzureHow you can build Resilience in AzureAzure Essentials

Resiliency in the cloud is often described in terms of availability, such as how quickly a system fails over, how many replicas exist, or what a service-level agreement guarantees. But for most organizations today, especially those operating in regulated, sovereign, or geopolitically sensitive environments, resiliency is something far more fundamental. It is the ability to continue operating under pressure, protect what matters most, and recover safely when the unexpected happens.

A useful way to think about this is not a system problem, but a city problem. A modern city does not depend on a single power source, a single road, or a single control system. It is designed to withstand disruptions, whether from infrastructure failures, natural events, or security incidents. It has redundancy—but more importantly—it has governance, control, and recovery mechanisms that reflect local realities. Cloud resiliency operates in much the same way. It is not just about avoiding outages; it is about ensuring systems can adapt, recover, and keep functioning within real-world constraints.

Get started with Resiliency in Azure

On Azure, resiliency is not something Microsoft delivers to customers. It is something Microsoft builds with them. The platform provides deeply resilient infrastructure and increasingly intelligent capabilities, but resiliency outcomes only emerge when those are intentionally designed, aligned with sovereignty constraints, and continuously validated against real-world conditions. Last year, we explained how at its core, Azure approaches resiliency across three interconnected pillars: infrastructure resiliency, data resiliency, and cyber recovery.

Infrastructure resiliency: ensuring applications remain available through failure conditions.

Data resiliency: ensuring data remains protected, durable, and recoverable.

Cyber recovery: ensuring organizations can recover safely from compromised states.

Together, they ensure not only that systems remain available, but that they remain recoverable and trustworthy—even when failure modes are unpredictable. These pillars are operationalized through a lifecycle approach that helps organizations design, improve, and continuously validate their resiliency posture.

What differentiates Azure is how these elements come together. Azure provides not just resilient infrastructure, but a unified approach that spans platform capabilities, observability, validation, and intelligent remediation, allowing organizations to move from designing for resiliency to continuously operating and improving it.

Resiliency as a shared responsibility, not a handoff

In any city, infrastructure providers ensure that roads, utilities, and foundational systems are reliable. But how buildings are designed, how emergency plans are executed, and how critical services are protected; those remain the responsibility of the city and its operators.

Azure’s shared responsibility model follows the same principle. Microsoft is responsible for delivering a resilient cloud platform foundation like regions, physical datacenters, networking, isolation boundaries, and engineering systems that reduce blast radius and improve durability at scale. This includes capabilities such as Availability Zones, regional isolation, and services like Azure Backup and Azure Site Recovery. Customers then build on Azure enabled experiences to configure the right capabilities and achieve their desired resiliency outcomes. This includes how applications are architected, how dependencies are managed, how recovery objectives are defined, and how backup and disaster recovery are configured and tested. In sovereign and regulated environments, this responsibility becomes even more critical where customers explicitly define where data resides, how it moves, and how recovery aligns with compliance and jurisdictional requirements.

Platform foundations that reflect reality: zones, regions, and sovereignty

Modern Azure resiliency starts with a zone-first design approach, where applications are built to tolerate the loss of an entire Availability Zone. This significantly reduces the likelihood of localized infrastructure failures impacting application availability.

However, resilience does not stop at zones. Regions themselves are not uniform, and assuming uniformity is one of the most common causes of design fragility.

Some Azure regions are paired, with predefined recovery regions aligned for disaster recovery.

Others are non-paired, often due to sovereignty, regulatory, or geographic constraints.

This distinction fundamentally shapes resiliency architecture.

Paired region scenario (predictable recovery): Azure provides a spectrum of durability options from locally redundant storage (LRS) to zone redundant (ZRS) and geo‑redundant storage (GRS), enabling customers to align data protection strategies with their availability, compliance, and data sovereignty requirements. For example, a financial services application deployed in West Europe can leverage its paired region (North Europe) for disaster recovery. Using Azure Site Recovery (ASR), workloads are continuously replicated and orchestrated to enable application-level continuity during a regional disruption.

The predefined region pairing offers predictable failover behavior, along with well-understood Recovery Point Objective (RPO) and Recovery Time Objective (RTO) trade-offs. However, modern Azure resiliency guidance has evolved beyond strict reliance on region pairs. As outlined in the Modern Azure Resilience with Mark Russinovich blog, customers are increasingly adopting flexible multi-region architectures, including non-paired region strategies based on factors such as service availability, capacity, latency, and data residency requirements. These patterns emphasize that disaster recovery is no longer bound to predefined pairs, but instead is a design choice aligned to workload-specific needs.

In such scenarios, Azure Site Recovery plays a critical role by providing consistent, application-aware replication and failover orchestration across any chosen region, paired or not. This allows customers to standardize their recovery strategy while retaining the flexibility to meet evolving business, regulatory, and scale considerations.

Non-paired region scenario (sovereign constraint): a government workload operates in a sovereign region with no predefined pair. Cross-region recovery is restricted. The architecture prioritizes zonal high availability and restore-based recovery using backup to region of choice, ensuring data remains within jurisdictional boundaries. Recovery is slower but fully compliant.

Asymmetric recovery scenario (regulated enterprise): a multinational enterprise deploys in a constrained geography where only subsets of data can leave the region. For example, Azure Site Recovery enables failover for critical services, while sensitive data relies on Azure Backup for in-boundary recovery. The result is an intentionally asymmetric resiliency model, balancing compliance with business continuity.

The result is a shift from one-size-fits-all architectures to workload-driven resiliency design, where recovery strategies are intentionally aligned to business, regulatory, and operational constraints.

Azure features and capabilities strengthen resiliency outcomes

Resiliency in Azure is not delivered by a single service, but it is achieved through a set of capabilities and services. These capabilities work together to ensure applications remain available, data remains protected, and systems can recover even under infrastructure failures, regional disruptions, or cyber-attacks. It begins with zone-resilient foundations that reduce exposure to localized failures, and extends through autoscaling, load balancing, and health-aware traffic management that keeps applications responsive under stress.

For broader infrastructure or regional disruptions, Azure Site Recovery enables continuity through replication and failover orchestration. Equally important, Azure Backup addresses a different class of risk like corruption, accidental deletion, compliance retention, and cyber compromise by enabling recovery to a trusted point in time when failover is not enough. These capabilities are most effective when paired with strong observability and rehydration-friendly design, where systems can detect issues early, recover automatically, and rebuild quickly. The result is a more complete view of resiliency: not just maintaining uptime but sustaining trust and recoverability under real-world failure conditions.

Bridging intent to execution through experiences on Azure

Customers had tools but lacked a unified way to measure and improve their resiliency posture. Introduced at Microsoft Build 2026 and available in public preview, Azure Infrastructure Resiliency Manager addresses this challenge. It provides an application-centric and resource-centric view of resiliency, bringing together Resiliency in Azure, Azure Advisor, Azure Chaos Studio, and Azure Monitor into a single, cohesive experience.

A key starting point is zonal resiliency posture. It helps customers understand whether their workloads are truly zone-resilient, identify hidden dependencies, and pinpoint gaps between intended architecture and actual deployment.

It introduces a lifecycle approach to resiliency:

Start resilient: design workloads with the right foundational posture.

Get resilient: identify and close gaps in existing systems.

Stay resilient: continuously validate and improve through drills and monitoring.

At the core of Azure Infrastructure Resiliency Manager is the Resiliency Agent, which brings intelligence and automation into the lifecycle. The agent evaluates workloads holistically and identifies risks, surfaces misconfigurations, and explains trade-offs across cost, availability, and compliance. But its role extends beyond analysis. This represents a shift from reactive guidance to proactive and increasingly autonomous resiliency management.

In addition to guiding remediation, the Resiliency Agent can generate Infrastructure-as-Code (IaC) templates, enabling teams to directly implement recommended changes in their deployment pipelines. This is a fundamental shift: resiliency moves from being advisory to executable. It becomes embedded in DevOps workflows; codified, repeatable, and consistently applied.

In addition to this, with the Azure Backup MCP Server, these capabilities become programmable. Organizations can integrate backup posture validation, recovery readiness checks, and policy-driven restore workflows into automated systems while maintaining full control within sovereignty boundaries.

How you can build Resilience in Azure

On Azure, this evolution reflects a shift from predefined constructs to intentional architectures, from fragmented tools to unified experiences, and from guidance to execution. As organizations navigate increasing complexity, regulatory constraints, and unpredictable failure modes, the path forward is clear: build resilience into the foundation, validate it continuously, and automate it wherever possible. With Azure’s platform capabilities, application-centric experiences, and intelligent agents, resiliency is not just achievable but operationalized to deliver with confidence.

Explore Azure Essentials to get started with a unified resiliency experience across your applications and infrastructure. Azure Essentials, Microsoft Unified, and Azure Accelerate help organizations move from resiliency design to operational execution across every stage of the lifecycle.

Azure Essentials

Create secure, resilient, and cost-efficient projects.

Get started

Related resources

Announcing Azure Infrastructure Resiliency Manager Public Preview

Resiliency documentation

Modern Azure Resilience with Mark Russinovich

Reliability guides for Azure services

Cloud Resiliency

Proving application resilience on Azure with Chaos Studio

The post Built to bounce back: How Azure resiliency evolved appeared first on Microsoft Azure Blog.
Quelle: Azure