The problem
Your Azure data key still lives in Azure
A Customer-Managed Key in Managed HSM is yours to manage, but it sits with the provider that stores the data.
Azure SQL Database and other services can encrypt with a Customer-Managed Key, yet the key that wraps their data keys is still inside Azure. When a regulator or a board asks who could unwrap the data, or how you would cut access, the answer depends on the same provider that holds the data.
Key next to the data
The key-encryption key and the encrypted data share one provider.
Provider-side off switch
Cutting access goes through the provider's own controls.
Sovereignty questions
Reviewers ask where the key lives and under which jurisdiction.
Audit evidence
Proving who can use the key is harder when it sits inside the cloud.
How it works
Azure asks DuoKey to wrap and unwrap. The KEK stays with you.
With Azure's External Key Manager (EKM) protocol, Managed HSM delegates the wrap and unwrap of Data Encryption Keys (DEKs) to a key manager you run. Services with a Customer-Managed Key on Managed HSM call that endpoint every time they protect or recover a DEK.
Request · Azure to DuoKey, on every DEK operation
Azure SQL and CMK workloads
Need a DEK
Azure Managed HSM
Delegates wrap / unwrap
DuoKey EKM endpoint
/azureekm/{slug}
Key operation · inside DuoKey
Mutual TLS
Client cert chains to your CA
KEK in DuoKey vault
Never exposed to Azure
Wrapped or unwrapped DEK
Returned to Azure
Azure only ever sees the DEK it sent and the result it gets back. The Key Encryption Key (KEK) is never exposed to Azure.
Capabilities
A built-in EKM proxy in DuoKey Cockpit
Azure EKM is an app in the Cockpit Apps catalog. You deploy an endpoint, link it to a key in your DuoKey vault and decide which algorithms it accepts.
Implements Azure EKM API version 0.1-preview
Wrap and unwrap
KEK stays in DuoKey
Azure sends the DEK to be wrapped or unwrapped with your KEK. The KEK itself is never exposed to Azure.
Mutual TLS
Client certificate required
Every request is authenticated with a client certificate that must chain to a CA you configure. You can also pin the expected client name.
Algorithm choice
A256KW · A256KWP · RSA-OAEP-256
AES Key Wrap, with or without padding, for AES-256 keys, or RSA-OAEP-256 for RSA keys.
Self-test and health
Wrap / unwrap round trip
A built-in wrap and unwrap test, plus a structured health check for the endpoint.
Access follows the key you hold
Because the KEK lives in DuoKey and not in Azure, disabling or revoking it in DuoKey means Managed HSM can no longer wrap or unwrap DEKs with it.
Setup
From Cockpit to a live EKM endpoint in five steps
- 01
General
In Cockpit, open Apps, Create new app, Azure EKM. Name the proxy; the endpoint slug is an auto-generated GUID.
- 02
Mutual TLS
Upload the CA that issued Azure's client certificate. mTLS is on by default; optionally pin the client name.
- 03
Key
Pick the vault and the key that acts as the KEK: AES-256 or RSA.
- 04
Algorithms
Choose the wrap algorithms the endpoint accepts, or leave all unchecked to allow every compatible one.
- 05
Review and deploy
Run Test Connection for a wrap and unwrap self-test, then deploy the EKM proxy.
- An Azure Managed HSM, with services using a Customer-Managed Key on it, such as Azure SQL Database TDE
- The CA certificate that issued Managed HSM's client certificate
- An AES-256 or RSA key in a DuoKey vault to act as the KEK (or the right to create one)
- An ingress that terminates mutual TLS and exposes the endpoint to Azure
Deep dives
Field guides for your programme
Engagement
Keep the key to your Azure data outside Azure
See a DuoKey EKM endpoint wrap and unwrap Managed HSM keys, with mutual TLS, algorithm control and a live self-test in Cockpit.
Request a demoDiscuss the decisions that matter most to your security programme.
Tell us where control is difficult today. We will help you identify a practical next step.