#!/bin/sh — keep the keys on your floor

2026-09-05 · sovereign-cloud · managed-hsm · ekm

Howzit. Let’s talk about the feature every regulated-industry architect in Riyadh, Abu Dhabi, and Sandton is going to ask about this quarter: External Key Management on Azure Key Vault Managed HSM.

Preview. Gated. Not a personality trait. And if your first sentence is “we need EKM because sovereignty”, I’m going to ask you to sit down, drink some rooibos, and tell me which clause in SAMA CSF, NCA, NDMO, ADHICS, or POPIA actually says the Key Encryption Key must live in a box you can unplug in your own building.

Because most of the time, it doesn’t. Most of the time you want customer-managed keys in Managed HSM, FIPS 140-3 Level 3, single-tenant, you own the security domain, Microsoft never sees the key material. That already satisfies a shocking amount of “we must control the keys” conversation in KSA, the UAE, South Africa, Kenya, Nigeria, Egypt — the whole lot.

EKM is the extra gear. The one you only engage when a contract, a regulator, or a national-security brief says the KEK may not physically sit on Microsoft iron. Then — and only then — you keep that KEK in your HSM, on your floor, in Riyadh or Dubai or Johannesburg, and Azure still encrypts storage, databases, disks, the usual CMK story.

What actually happens

Azure Storage (or whatever CMK consumer you picked) still thinks it is talking to a normal Managed HSM key. Managed HSM still does identity, RBAC, and the Azure-shaped key URI. The cryptographic wrap/unwrap of the data encryption key gets forwarded to a proxy you run, and that proxy talks HSM-vendor to the box in your rack.

Azure service (CMK)
  -> Managed HSM   # authz, key URI, audit
    -> EKM Proxy   # you run this, mTLS, public FQDN in preview
      -> your HSM  # KEK never leaves this thing

# wrapKey / unwrapKey only
# disconnect the HSM = cryptographic kill switch
# also: you just inherited availability

The KEK does not transit Microsoft. Microsoft does not get a copy. That is the whole point, and it is a real one for digital sovereignty conversations in the GCC and across Africa. You can yank the network, power down the HSM, and every wrap/unwrap for that key stops. That is a kill switch. It is also how you take production down with one bad change window, so don’t get cute with it.

Do not use this unless you have to

I will say this louder for the people at the back of the boardroom.

Do not run EKM as a flex. Official guidance calls it a last-resort, gated option, and they are not being dramatic.

No SLA on the external key, the proxy, or your HSM. Managed HSM’s SLA covers Managed HSM up to the call. After that, it is your circus.
Every crypto op now includes a network round trip. Preview budget is 250 ms. Miss it and the unwrap fails. Storage doesn’t mount. Someone’s Friday is ruined.
Wrap and unwrap only. No sign, verify, encrypt, decrypt, Secure Key Release, Confidential VM launch. If you needed those, stay on Managed HSM keys.
You patch, scale, monitor, and prove the proxy. Microsoft does not ship one. Vendors do. You can write your own against the public API. Either way, ops is on you.
Preview access is gated through your account team. There is a serious commercial bar on it. This is not “turn it on in the portal because the slide looked lekker.”

If POPIA, SAMA, NCA ECC, NDMO, or ADHICS can be met with Managed HSM keys plus the right landing zone, residency, and logging story — do that. EKM is for the day a supervisor, a ministry, or a contract literally requires physical custody outside the cloud operator.

Trust model, without the fairy tales

Preview networking is blunt: the proxy needs a public FQDN, public IPv4, TCP 443, TLS 1.3, mutual TLS. Managed HSM source IPs are not static, so you cannot firewall “only Azure”. The handshake is the gate. Your proxy presents a server cert chained to a CA you register on the connection. Managed HSM presents a Microsoft-issued client cert. You pin the subject name and the root CAs, not a fingerprint, because they rotate the client cert.

That last bit matters for sovereignty conversations in KSA and the UAE. You own the KEK. You do not own the caller identity that Managed HSM uses to knock on your proxy. AuthZ for “which Azure service may use this key” lives in Managed HSM RBAC. Your on-prem HSM sees wrap and unwrap from the proxy. It does not see the storage account’s managed identity. If you were hoping the Luna or nShield would be the identity-aware bouncer — eish, no. It is a crypto engine. The bouncer is still in Azure.

So you design it like a grown-up: tight RBAC on the Managed HSM, least-privilege managed identities, proxy that only accepts that client cert, WAF and logging in front, HSM that is actually HA, runbooks for cert rotation, and a tested “we pulled the kill switch” drill that does not also brick the bank.

Where this actually shows up

This is the pattern I expect to argue about with customers in:

Saudi Arabia — NCA, NDMO, SAMA CSF, and the broader national-data conversation. Residency in country is not the same thing as “Microsoft never holds the KEK”. Separate those two in the architecture decision record or you will have a messy steering committee.
UAE — ADHICS and sector regulators who want a story for cryptographic control, not just a region checkbox.
South Africa — POPIA, FSCA-shaped conversations, and boards that still hear “the cloud has our keys” and stop listening. Managed HSM keys usually land the plane. EKM is the exception that needs a lawyer and an ops team, not a slogan.
Rest of the continent — Kenya, Nigeria, Egypt, and anyone writing a digital-sovereignty paper this year. Same rule: start with Managed HSM. Escalate to EKM when the requirement is physical custody, not vibes.

Azure public regions are in scope for the preview. The sovereign clouds are not. If your design assumed “this only exists in a special cloud”, update the slide.

If you still have to do it

Then do it properly. Vendor-supported proxy from someone who has actually implemented the spec — Entrust, Thales, Fortanix, Securosys, Futurex, Utimaco, Eviden, and whoever else is on the current list — or a proxy you are prepared to own like production software. HA HSM. HA proxy. Cert lifecycle. 250 ms path from Managed HSM to the box. Logging on both sides. A restore story that does not include “restore the external key from Managed HSM backup”, because that is not supported and can leave the pool in a state you will not enjoy.

A mate of mine already published a lab walkthrough of standing the proxy up and watching wrap/unwrap on the wire. Different post, same feature, he did the messy bits with a real endpoint. I’m not photocopying his homework. Read his write-up if you want the lab scars. Then come back here when the conversation is “does SAMA actually require this, or do we just like the kill switch on the slide.”

Opinions mine. Preview features move. Check current docs before you promise a regulator anything.