In this blog post Keeping Your Keys Yours with External Key Management in Azure we will explain how organisations can keep critical encryption keys outside Microsoft’s infrastructure, what that changes for data sovereignty, and where the operational risks sit.
For many CIOs, the concern is no longer whether cloud data is encrypted. It is whether the organisation genuinely controls the keys, can prove that control to customers and regulators, and can still operate if part of the key-management chain fails.
Microsoft’s external key management capability for Azure Key Vault Managed HSM addresses this concern. Managed HSM, or Managed Hardware Security Module, is a dedicated service for protecting important encryption keys. External key management allows the most sensitive key material to remain in hardware operated outside Microsoft’s infrastructure.
Our earlier article on why Managed HSM external keys matter for Australian sovereignty covers the strategic case. Here, we will focus on how the technology works and the decisions leaders need to make before using it.
What external key management actually does
Think of encrypted data as valuable documents inside a locked safe. Azure can operate the safe, but your organisation controls the master key needed to unlock the key that protects those documents.
Azure services normally encrypt data using a data encryption key. This is a fast, short-purpose key designed to protect the actual files, records or database information.
A second key, called a key encryption key, protects that data encryption key. With external key management, this higher-level key stays in an external hardware security module, or HSM, which is a tamper-resistant device designed specifically to protect encryption keys.
Azure service
↓
Azure Managed HSM checks identity and permission
↓
External Key Management proxy translates the request
↓
Your external HSM approves or rejects the key operationThe proxy is a controlled connection between Azure Managed HSM and the external HSM. It translates Azure’s request into a format the external device understands, but it is not supposed to store the key itself.
The important point is that the external master key does not move into Azure. Azure receives only the result needed to protect or access the service’s data encryption key.
Key sovereignty is not the same as data residency
Data residency asks where information is physically stored. Key sovereignty asks who controls the encryption keys, where those keys exist and who can authorise their use.
You can store data in an Australian Azure region and still have questions about key custody. Conversely, holding a key in Australia does not automatically resolve every privacy, contractual or cross-border data issue.
External key management can strengthen four areas of control:
- Custody: The key material remains in an HSM operated by your organisation or an approved provider.
- Authority: Your organisation controls the systems and processes that allow the external key to be used.
- Evidence: Logs can show when key operations were requested, approved or rejected.
- Exit control: Access to protected data can be restricted by withdrawing access to the external key, subject to the behaviour of the Azure service using it.
This can be valuable when a government contract, customer agreement or industry rule requires physical separation between the cloud provider and the organisation holding the key.
However, external keys do not automatically make a system compliant. The Australian Privacy Principles require covered organisations to take reasonable technical and organisational steps to protect personal information. Key control may support that obligation, but it does not replace access management, monitoring, secure devices, backups or incident response.
The same applies to Essential Eight, the Australian government’s cybersecurity framework for reducing common attack paths. External key management is not an Essential Eight checkbox. It is an additional control for workloads with unusually strict sovereignty requirements.
The strongest control can become the biggest dependency
Keeping the key outside Azure creates stronger separation, but it also introduces more components that must remain available.
If Azure Managed HSM cannot contact the proxy, or the proxy cannot reach the external HSM, key operations may fail. Depending on how the Azure service uses and caches encryption keys, that could eventually interrupt access to the protected workload.
Microsoft’s service commitment covers Managed HSM itself. It does not cover the complete external chain, including your proxy, network connection and external HSM. Azure could therefore be operating normally while your application remains unavailable because the external key cannot be reached.
There are also recovery limitations to plan around. Managed HSM geo-replication is not supported for external keys, and Azure backup and restore does not protect the external key material. Your HSM backup, recovery and regional resilience become your responsibility.
If that external key is permanently lost without a usable backup, the data it protects may become permanently inaccessible. This is why external key management should be treated as a business continuity programme, not simply a security configuration.
A practical Australian business scenario
Consider a 220-person Australian software company bidding for work involving sensitive government and critical-infrastructure data. Its Azure environment is secure, but the customer’s contract requires encryption keys to remain outside the cloud provider’s infrastructure.
Moving the whole application back on-premises would increase hosting costs, slow delivery and create a larger support burden. Standard customer-managed keys inside Azure may also fail to satisfy the exact wording of the contract.
An external key architecture allows the application and data platform to remain in Azure while the key encryption key stays in a separately operated HSM. The company can demonstrate a clearer separation of control without rebuilding its entire platform.
The business outcome is not simply “better encryption.” It is the ability to qualify for the contract while retaining the scalability and productivity benefits of Azure.
But the company must also fund redundant proxy services, HSM recovery, monitoring and round-the-clock ownership. If the contract does not genuinely require external custody, the added complexity may cost more than the risk it solves.
Questions CIOs should ask before approving the design
- Is there a written requirement? Identify the law, contract, customer control or risk decision that requires keys to remain outside Microsoft infrastructure.
- Does the Azure service support it? External keys work with supported Azure services that can use Managed HSM customer-managed keys. Compatibility must be checked workload by workload.
- Who operates the external HSM? Decide whether it will be managed internally, by an HSM vendor or by another approved provider.
- What happens during an outage? Document the impact of losing the proxy, external HSM, network connection, certificates or supporting identity services.
- How will keys be recovered? Test backup, restoration and replacement processes before production data depends on them.
- Who can disable or delete a key? Separate approval, administration and operational roles so one compromised account cannot cause a major outage.
This separation of duties matters just as much as the technology. The safeguards described in our article on security and governance in fast-moving engineering environments are particularly important when teams can affect encryption keys.
A safer way to introduce external keys
Start with one clearly defined workload rather than applying external key management across the organisation. Confirm the service supports the required key type, identity model and encryption configuration.
Next, design redundant proxy and HSM connectivity. The connection uses mutual TLS, meaning Azure and the proxy verify each other with digital certificates before exchanging a request. Azure Private Link can add private network isolation, although its external key management integration remains in preview at the time of writing.
Enable audit logs across Managed HSM, the proxy and the external HSM. Your team needs to follow one failed request through all three layers without guessing where the problem occurred.
Certificate expiry, key rotation and emergency recovery should also be rehearsed. Small lifecycle mistakes can create large outages when Azure’s key reference and the actual external key fall out of sync.
Key-related software dependencies must be maintained as well. Our discussion of the Azure Key Vault SDK issue CIOs should assess shows why encryption controls need ongoing review rather than a one-time deployment.
When standard Managed HSM is the better decision
For most organisations, keys stored directly in Azure Managed HSM provide strong customer control with lower latency, simpler recovery and fewer external dependencies. External key management is not automatically the more secure option.
It makes sense when physical external custody is a firm requirement and the business value justifies the operating cost. If the requirement is simply “we must control our keys,” standard Managed HSM may already provide the appropriate balance.
The right decision comes from comparing sovereignty requirements, outage risk, recovery capability and total operating cost. It should not be driven by fear or by choosing the most complicated architecture available.
Keep control without creating a new blind spot
External key management gives Australian organisations a practical way to keep critical key material outside Microsoft infrastructure while continuing to use supported Azure services. That can reduce sovereignty concerns and help satisfy strict customer or contractual requirements.
It also transfers significant responsibility back to your organisation. The proxy, external HSM, backups, certificates, monitoring and recovery process all become part of the production service.
CloudProInc combines more than 20 years of enterprise IT experience with hands-on work across Azure, Microsoft 365, Microsoft Defender and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations determine whether stronger key separation will reduce real risk or simply add cost and complexity.
If you are unsure whether external key management is necessary for your workloads, we are happy to review the requirement and current Azure design with you — no strings attached.