Encrypting Azure Event Hub Namespaces With Customer-Managed Keys

Azure Event Hubs encrypts all stored data at rest by default, so it is easy to assume the encryption box is already ticked. It is, technically. But there is a meaningful difference between Microsoft holding the keys and you holding them. The Event Hub Namespace Not Encrypted With CMK check looks for namespaces that depend solely on platform-managed keys and surfaces them so you can decide whether that meets your data-handling requirements.

For most teams streaming low-sensitivity telemetry, the default is fine. For teams pushing financial transactions, PII, or anything that lands under PCI DSS, HIPAA, or internal data classification policies, a customer-managed key is usually the expected control.

---

What this check detects

The check inspects each Event Hub namespace in your subscription and reports any namespace whose encryption is not configured with a customer-managed key. Concretely, it looks at the namespace's encryption property. When that property is empty or set to the default, Azure is encrypting your event data with a Microsoft-managed key.

When a CMK is configured, the namespace points at a specific key (or set of keys) in an Azure Key Vault, and Azure uses that key to wrap the data encryption keys that protect your streamed messages.

---

Why it matters

"It's already encrypted" is true but incomplete. The control you give up with platform-managed keys is not the encryption itself, it is the governance around the key. Here is what changes when you bring your own key.

You control revocation

If a namespace is compromised or you need to comply with a contractual data-destruction clause, a CMK lets you disable or delete the key. Once the key is gone, the encrypted data becomes unreadable, even to Azure. With Microsoft-managed keys you have no equivalent kill switch.

You control rotation on your schedule

Many compliance frameworks require key rotation on a defined cadence. With a CMK in Key Vault you can rotate keys automatically and prove it in an audit. Microsoft rotates platform keys too, but you cannot dictate the schedule or evidence it the same way.

You get a full audit trail

Every access to a CMK is logged through Key Vault diagnostic logs. That gives security teams visibility into when and how the key protecting your event data is used, which feeds directly into incident response and compliance reporting.

Real-world scenario

An attacker who gains read access to a storage layer but not to your Key Vault still cannot decrypt CMK-protected data. The same attacker against a platform-managed setup has nothing standing between them and the plaintext beyond Azure's own controls. CMK splits the trust so that compromising the data plane is not enough on its own.

---

How to fix it

Enabling a CMK involves three pieces: a Premium or Dedicated namespace, a Key Vault with a key, and a managed identity that lets the namespace reach the key.

Step 1: Confirm the namespace tier

List your namespaces and check the SKU.

az eventhubs namespace list \
  --query "[].{name:name, tier:sku.tier, rg:resourceGroup}" \
  --output table

If the namespace is on Standard or Basic, you will need to recreate it on Premium or migrate to a Dedicated cluster, since the tier cannot be upgraded in place to Premium.

Step 2: Create or pick a Key Vault and key

The Key Vault must have soft delete and purge protection enabled. Purge protection is mandatory for CMK scenarios.

# Create a Key Vault with purge protection
az keyvault create \
  --name kv-eventhub-cmk \
  --resource-group rg-streaming \
  --location eastus \
  --enable-purge-protection true \
  --enable-rbac-authorization true

# Create the key
az keyvault key create \
  --vault-name kv-eventhub-cmk \
  --name eventhub-cmk \
  --kty RSA \
  --size 2048

Step 3: Enable a managed identity on the namespace

The namespace needs an identity so it can authenticate to Key Vault. A system-assigned identity is the simplest option.

az eventhubs namespace identity assign \
  --name evhns-prod \
  --resource-group rg-streaming \
  --system-assigned

Step 4: Grant the identity access to the key

Grab the namespace's principal ID, then assign it the Key Vault Crypto Service Encryption User role (for RBAC-enabled vaults).

PRINCIPAL_ID=$(az eventhubs namespace show \
  --name evhns-prod \
  --resource-group rg-streaming \
  --query identity.principalId -o tsv)

VAULT_ID=$(az keyvault show \
  --name kv-eventhub-cmk \
  --query id -o tsv)

az role assignment create \
  --assignee "$PRINCIPAL_ID" \
  --role "Key Vault Crypto Service Encryption User" \
  --scope "$VAULT_ID"

Step 5: Attach the key to the namespace

KEY_ID=$(az keyvault key show \
  --vault-name kv-eventhub-cmk \
  --name eventhub-cmk \
  --query key.kid -o tsv)

az eventhubs namespace encryption add \
  --namespace-name evhns-prod \
  --resource-group rg-streaming \
  --encryption-config key-name=eventhub-cmk \
    key-vault-uri=https://kv-eventhub-cmk.vault.azure.net \
    user-assigned-identity=""

Terraform example

If you manage infrastructure as code, define the encryption block directly so it is enforced on every deploy.

resource "azurerm_eventhub_namespace" "prod" {
  name                = "evhns-prod"
  resource_group_name = azurerm_resource_group.streaming.name
  location            = azurerm_resource_group.streaming.location
  sku                 = "Premium"
  capacity            = 1

  identity {
    type = "SystemAssigned"
  }
}

resource "azurerm_eventhub_namespace_customer_managed_key" "prod" {
  eventhub_namespace_id = azurerm_eventhub_namespace.prod.id
  key_vault_key_ids     = [azurerm_key_vault_key.eventhub.id]
}

---

How to prevent it from happening again

Manual fixes drift. Bake the requirement into the platform so new namespaces cannot ship without a CMK.

Azure Policy

Use a built-in or custom policy with a deny effect on namespaces that lack CMK encryption. A custom policy rule looks like this:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.EventHub/namespaces"
      },
      {
        "field": "Microsoft.EventHub/namespaces/encryption.keySource",
        "notEquals": "Microsoft.KeyVault"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

CI/CD gates

Run a policy-as-code scanner against your Terraform or Bicep before merge. Tools like Checkov or tfsec can fail the pipeline when an Event Hub namespace resource has no associated customer-managed key configuration. A failing check blocks the PR rather than producing a finding after the fact.

---

Best practices

• Always enable purge protection on any Key Vault that backs a CMK. Without it, an accidental or malicious purge permanently destroys access to your data.
• Use a user-assigned managed identity for production at scale. It survives namespace recreation and can be shared across resources, which simplifies access management compared to per-resource system-assigned identities.
• Configure multiple keys for redundancy. Event Hubs supports up to three keys per namespace. If one becomes unavailable, the namespace uses another, reducing the availability risk a single key introduces.
• Enable diagnostic logging on the Key Vault and forward it to your SIEM so key access tied to event data is auditable.
• Match the control to the data. Not every namespace needs a CMK. Reserve the effort for namespaces carrying regulated or sensitive data, and document the classification decision so auditors and future engineers understand the rationale.
• Test key rotation in non-production first. Validate that autorotation works and ingestion stays healthy before relying on it in production.

Customer-managed keys are not about adding encryption where there was none. They are about moving the key, and the trust that comes with it, into your hands. For sensitive event streams that is often the difference between meeting a compliance requirement and explaining a gap to an auditor.