☁️ Azure Managed HSM Key Terraform Module

Creates an HSM-protected key inside an Azure Key Vault Managed HSM. Creating it requires data-plane RBAC that Azure RBAC cannot grant. Targets hashicorp/azurerm ~> 4.0.

• ☁️ Creates one azurerm_key_vault_managed_hardware_security_module_key (the keystone this) — a key generated inside FIPS 140-2 Level 3 hardware.
• 🔴 Records the failure that catches everyone once: a Managed HSM has two independent authorization systems, and Owner on the resource grants no ability to create a key.
• 🔒 Emits no key material at all — not even the public half, unlike azurerm_key_vault_key. There is nothing here to redact and nothing to leak.
• 🔴 Flags both dates as a one-way door: once set, an expiry can never be unset, and deleting either date argument forces replacement -- moving one, in either direction, does not.
• 🧮 Emits both the unversioned id and the versioned_id, and explains which one a consumer should reference.

💡 Why it matters: every HSM key type here is hardware-protected, so the interesting risks are not about algorithm choice — they are about who is permitted to use the key, and which URI form a consumer pinned.

If this module saves you time:

• ⭐ Star the repository — it helps others find it.
• 🤝 Connect on LinkedIn: linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee: buymeacoffee.com/microsoftexpert

flowchart TB
  rg["terraform-azurerm-resource-group"]
  certs["terraform-azurerm-key-vault  emits certificate_ids for the security domain"]
  mhsm["terraform-azurerm-key-vault-managed-hardware-security-module  ARM Microsoft.KeyVault/managedHSMs"]
  ra["terraform-azurerm-key-vault-managed-hardware-security-module-role-assignment  LOCAL RBAC"]
  key["terraform-azurerm-key-vault-managed-hardware-security-module-key"]
  rot["terraform-azurerm-key-vault-managed-hardware-security-module-key-rotation-policy  at most ONE per key"]
  vid["versioned_id  changes on every rotation"]
  uid["id  the unversioned data-plane URI"]
  consumer["terraform-azurerm-disk-encryption-set  and other CMK consumers"]

  rg -->|"name and location"| mhsm
  certs -->|"certificate_ids for the security domain"| mhsm
  mhsm -->|"id as managed_hsm_id, an ARM path"| key
  mhsm -->|"id"| ra
  ra -.->|"Crypto User must exist first, or create fails"| key
  key -->|"id as managed_hsm_key_id, a data-plane URI"| rot
  key --> uid
  key --> vid
  uid -->|"follows rotations"| consumer
  vid -->|"pinned, does NOT follow rotations"| consumer

  classDef this fill:#0078D4,stroke:#004578,color:#ffffff;
  classDef keystone fill:#004578,stroke:#00243c,color:#ffffff;
  classDef neutral fill:#F3F2F1,stroke:#8A8886,color:#201F1E;
  class key this;
  class mhsm keystone;
  class rg,certs,ra,rot,vid,uid,consumer neutral;

Two edges deserve attention. The dotted one is a local-RBAC role assignment that must exist before this key can be created — a dependency no input on this module can express. And the split at the bottom is the choice between the unversioned id, which follows rotations, and versioned_id, which does not.

flowchart TB
  name["name  force-new, rejects both a Resource ID and a URI"]
  hsmid["managed_hsm_id  force-new, ARM path, rejects the hsm_uri form"]
  kt["key_type  force-new, EC-HSM or oct-HSM or RSA-HSM, all HSM-protected"]
  opts["key_opts  a SET, case-sensitive, empty is allowed and reported"]
  curve["curve  required for EC-HSM only"]
  size["key_size  required for RSA-HSM and oct-HSM only"]
  dates["expiration_date  a ONE-WAY DOOR  plus not_before_date"]
  tags["tags  present here, absent on the rotation policy"]

  res["azurerm_key_vault_managed_hardware_security_module_key.this"]

  uri["id  a DATA-PLANE URI, not an ARM Resource ID"]
  vid["versioned_id  changes on every rotation"]
  nopub["no_public_key_material_is_emitted_by_this_resource"]
  rbac["creating_this_key_requires_data_plane_rbac_that_azure_rbac_cannot_grant"]

  name --> res
  hsmid --> res
  kt -->|"decides which of the two below applies"| curve
  kt --> size
  kt --> res
  opts --> res
  curve --> res
  size --> res
  dates --> res
  tags --> res
  res --> uri
  res --> vid
  res --> nopub
  res --> rbac

  classDef this fill:#0078D4,stroke:#004578,color:#ffffff;
  classDef neutral fill:#F3F2F1,stroke:#8A8886,color:#201F1E;
  class res this;
  class name,hsmid,kt,opts,curve,size,dates,tags,uri,vid,nopub,rbac neutral;

Nine arguments plus timeouts. key_type decides which of curve and key_size applies — and forbids the other.

Schema notes that bite:

• 🔴 Creating a key is a data-plane operation. Azure RBAC governs the control plane only; keys need Managed HSM local RBAC. Azure's own security baseline records "Azure RBAC for Data Plane: Supported — False" for this service.
• 🔴 This resource emits no key material, not even the public key. No public_key_pem, no public_key_openssh, no e/n/x/y — all of which azurerm_key_vault_key does emit. Fetch the public key from the data plane instead.
• 🔴 id is a data-plane URI, https://<hsm>.managedhsm.azure.net/keys/<name>, not an ARM Resource ID. Meanwhile managed_hsm_id is an ARM path. One family, two conventions.
• 🔴 expiration_date can never be unset once set — the provider states the API restores the purged key, so even destroy-and-recreate brings it back.
• 🔴 Both dates are force-new in one direction only, and the direction is REMOVAL. The CustomizeDiff predicate is old value non-empty, new value empty, so deleting expiration_date or not_before_date replaces the key. Moving a date is an in-place update whichever way it moves. Under the provider defaults a replacement soft-deletes the key and then recovers it -- same material, same versions, old properties restored -- so the edit is churn and a no-op. Only with purge_soft_deleted_hsm_keys_on_destroy enabled and HSM purge protection off is the key genuinely purged and a new one generated, and only then is anything wrapped under it unrecoverable.
• 🔴 There is no software key type. Only EC-HSM, oct-HSM and RSA-HSM; the plain RSA and EC values from Key Vault do not exist here.
• ⚠️ key_opts is case-sensitive and is a set here where Key Vault uses a list. wrapKey, not wrapkey.
• ⚠️ There is no inline rotation_policy block, unlike azurerm_key_vault_key — rotation is a separate resource, which is why the sibling module exists.
• ⚠️ Destroy behaviour depends on the caller's features {} block — purge_soft_deleted_hardware_security_module_keys_on_destroy.
• ⚠️ Force-new: name, managed_hsm_id, key_type, key_size, curve, and expiration_date / not_before_date when removed.
• ⚠️ key_size and curve are ExactlyOneOf each other -- a cross-field rule absent from the binary schema. This module's key_type-keyed checks are stricter and imply it in both directions.
• ⚠️ curve carries a diff suppression: a stored SECP256K1 equals a configured P-256K. Same curve, old and new names; there is nothing to correct.
• 🔴 Any update rotates the version. versioned_id is marked newly-computed whenever key_opts, either date or tags change -- so editing a tag produces a new key version.
• ⚠️ All four timeouts exist. A misspelled key is discarded silently.

Two planes, and only one of them is Azure RBAC.

🔴 Owner or Contributor on the Managed HSM grants nothing here. Microsoft documents a dual-plane model: control-plane access does not confer data-plane access. The identity running Terraform needs a local RBAC assignment, and without it the apply fails on authorization while every Azure RBAC check looks correct.

⚠️ And that assignment is an ordering problem, not just a permissions one. A configuration that creates the HSM and this key in one pass will try to create the key before the identity is permitted to. See example 3.

✅ Plan access here is not credential access. Refreshing this resource needs data-plane read, but the provider returns no key material — so an identity granted plan rights learns metadata and never bytes. That is unusual enough in this library to be worth stating explicitly.

🔒 Assign administrative roles to Entra security groups rather than individuals, which Microsoft recommends to avoid locking yourself out of an HSM when an account is deleted, and consider PIM for just-in-time elevation.

• An existing Managed HSM, activated with its security domain downloaded. See terraform-azurerm-key-vault-managed-hardware-security-module.
• A Managed HSM local-RBAC role assignment granting the Terraform identity Crypto User at /keys, created before this key. Use terraform-azurerm-key-vault-managed-hardware-security-module-role-assignment, and order it with depends_on — nothing in this module's inputs can express that dependency.
• Microsoft.KeyVault registered in the subscription.
• Network reachability of the HSM's data plane if it restricts public access — the data-plane endpoint is what Terraform talks to, not management.azure.com.
• The caller configures the provider "azurerm" { features {} } block, auth, and subscription; this module declares none of these.

terraform-azurerm-key-vault-managed-hardware-security-module-key/
├── providers.tf     # required_version + pinned azurerm; no provider block
├── variables.tf     # 10 inputs, 17 validations
├── main.tf          # the keystone `this` + ID-parsing and reporting locals
├── outputs.tf       # id first, then what the module cannot grant or verify
├── README.md        # this file
├── SCOPE.md         # the cross-module contract
├── LICENSE          # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

module "hsm_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-storage-cmk"
  managed_hsm_id = module.managed_hsm.id

  key_type = "RSA-HSM"
  key_size = 4096
  key_opts = ["wrapKey", "unwrapKey"]

  tags = { environment = "prod" }
}

🔴 This will fail unless the Terraform identity already holds Crypto User on the HSM's /keys scope. Example 3 shows the full ordering.

💡 wrapKey / unwrapKey only. A key used to protect another key does not need sign or encrypt.

Consumes

Emits

module "hsm_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-storage-cmk"
  managed_hsm_id = module.managed_hsm.id

  key_type = "RSA-HSM"
  key_size = 4096
  key_opts = ["wrapKey", "unwrapKey"]
}

module "hsm_signing_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-code-signing"
  managed_hsm_id = module.managed_hsm.id

  key_type = "EC-HSM"
  curve    = "P-384"
  key_opts = ["sign", "verify"]
}

data "azurerm_client_config" "current" {}

module "managed_hsm" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module.git?ref=v1.0.0"

  name                = "hsm-prod"
  resource_group_name = module.rg.name
  location            = "eastus2"
  tenant_id           = data.azurerm_client_config.current.tenant_id
  admin_object_ids    = [data.azurerm_client_config.current.object_id]
}

# Managed HSM Crypto User -- lets the identity create and delete keys.
module "crypto_user" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-role-assignment.git?ref=v1.0.0"

  managed_hsm_id     = module.managed_hsm.id
  name               = "1e243909-064c-6ac3-84e9-1c8bf8d6ad22"
  scope              = "/keys"
  role_definition_id = "/Microsoft.KeyVault/providers/Microsoft.Authorization/roleDefinitions/21dbd100-6940-42c2-9190-5d6cb909625b"
  principal_id       = data.azurerm_client_config.current.object_id
}

module "hsm_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-storage-cmk"
  managed_hsm_id = module.managed_hsm.id
  key_type       = "RSA-HSM"
  key_size       = 4096
  key_opts       = ["wrapKey", "unwrapKey"]

  # Nothing in this module's inputs can express this dependency: the role
  # assignment is a sibling resource, and the key does not reference it.
  depends_on = [module.crypto_user]
}

output "read_this_before_granting_access" {
  # Always true.
  value = module.hsm_key.creating_this_key_requires_data_plane_rbac_that_azure_rbac_cannot_grant
}

# Control plane -- Azure RBAC. Does NOT let you create a key.
az role assignment create --role "Managed HSM Contributor" --assignee <id> --scope <hsm resource id>

# Data plane -- Managed HSM local RBAC. This is the one that matters.
az keyvault role assignment create --hsm-name hsm-prod \
  --role "Managed HSM Crypto User" --assignee <id> --scope /keys

output "what_you_can_and_cannot_get" {
  value = {
    # Available.
    unversioned = module.hsm_key.id
    versioned   = module.hsm_key.versioned_id

    # NOT available -- this resource emits no key material at all.
    no_public_key = module.hsm_key.no_public_key_material_is_emitted_by_this_resource
  }
}

# The only way to obtain the public key.
az keyvault key download --hsm-name hsm-prod --name key-code-signing --file public.pem

module "hsm_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-tde"
  managed_hsm_id = module.managed_hsm.id
  key_type       = "RSA-HSM"
  key_size       = 3072
  key_opts       = ["wrapKey", "unwrapKey"]

  # Setting this cannot be undone. Read the output below first.
  expiration_date = "2027-12-31T23:59:59Z"
}

output "understand_before_setting_an_expiry" {
  value = module.hsm_key.expiration_date_can_never_be_unset_once_set
}

# Rejected -- this is the parent module's `hsm_uri` output, not its `id`.
managed_hsm_id = "https://hsm-prod.managedhsm.azure.net/"

# Rejected -- a KEY VAULT, not a Managed HSM. A vault key is azurerm_key_vault_key.
managed_hsm_id = ".../providers/Microsoft.KeyVault/vaults/kv-prod"

# Accepted.
managed_hsm_id = ".../providers/Microsoft.KeyVault/managedHSMs/hsm-prod"

# And in the other direction -- `name` rejects the URI this resource EMITS.
name = "https://hsm-prod.managedhsm.azure.net/keys/key-tde"  # rejected
name = "key-tde"                                             # accepted

# Rejected -- differs from a documented operation only by case.
key_opts = ["sign", "wrapkey"]

# Rejected -- same reason.
key_opts = ["WrapKey"]

# Accepted -- correct casing.
key_opts = ["wrapKey", "unwrapKey"]

# ACCEPTED -- unrecognised, so possibly an operation added since.
key_opts = ["sign", "somethingNew"]

module "hsm_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-placeholder"
  managed_hsm_id = module.managed_hsm.id
  key_type       = "EC-HSM"
  curve          = "P-521"

  # Accepted by the provider, and therefore accepted here.
  key_opts = []
}

output "almost_certainly_a_mistake" {
  value = module.hsm_key.key_permits_no_operations
}

almost_certainly_a_mistake = true

module "legacy_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-legacy-interop"
  managed_hsm_id = module.managed_hsm.id
  key_type       = "RSA-HSM"
  key_size       = 1024
  key_opts       = ["wrapKey", "unwrapKey", "sign"]
}

output "worth_challenging" {
  value = module.legacy_key.rsa_key_size_is_below_the_modern_2048_bit_floor
}

worth_challenging = true

# A disk encryption set that should FOLLOW rotations.
module "disk_encryption" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-disk-encryption-set.git?ref=v1.0.0"

  name                = "des-prod"
  resource_group_name = module.rg.name
  location            = "eastus2"

  # The UNVERSIONED uri -- resolves to whatever the current version is.
  managed_hsm_key_id = module.hsm_key.id
}

output "pinning" {
  value = {
    follows_rotation = module.hsm_key.id
    pinned_forever   = module.hsm_key.versioned_id
  }
}

variable "keys" {
  type = map(object({
    key_type = string
    key_size = optional(number)
    curve    = optional(string)
    key_opts = set(string)
  }))
  default = {
    storage_cmk = { key_type = "RSA-HSM", key_size = 4096, key_opts = ["wrapKey", "unwrapKey"] }
    sql_tde     = { key_type = "RSA-HSM", key_size = 3072, key_opts = ["wrapKey", "unwrapKey"] }
    signing     = { key_type = "EC-HSM", curve = "P-384", key_opts = ["sign", "verify"] }
  }
}

module "hsm_keys" {
  source   = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"
  for_each = var.keys

  name           = "key-${each.key}"
  managed_hsm_id = module.managed_hsm.id

  key_type = each.value.key_type
  key_size = try(each.value.key_size, null)
  curve    = try(each.value.curve, null)
  key_opts = each.value.key_opts

  tags = { purpose = each.key }
}

provider "azurerm" {
  features {
    # DECIDES whether destroying a key soft-deletes or purges it.
    key_vault {
      purge_soft_deleted_hardware_security_module_keys_on_destroy = false
    }
  }
}

data "azurerm_client_config" "current" {}

variable "location" {
  type    = string
  default = "eastus2"
}

module "rg" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-resource-group.git?ref=v1.0.0"

  name     = "rg-hsm-prod"
  location = var.location

  tags = { environment = "prod" }
}

# The security domain needs three certificates; the key-vault module owns them.
module "kv_security_domain" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault.git?ref=v1.0.0"

  name                = "kv-hsm-sd"
  resource_group_name = module.rg.name
  location            = var.location
  tenant_id           = data.azurerm_client_config.current.tenant_id

  # Three self-signed certificates, generated in the vault. The security domain is
  # encrypted to these public keys, and the private halves are what let you restore
  # the HSM -- so treat them as the HSM's root of recovery.
  certificates = {
    for k in ["sd1", "sd2", "sd3"] : k => {
      certificate_policy = {
        issuer_parameters = { name = "Self" }
        key_properties = {
          exportable = true
          key_type   = "RSA"
          reuse_key  = false
          key_size   = 2048
        }
        secret_properties = { content_type = "application/x-pkcs12" }
        x509_certificate_properties = {
          subject            = "CN=hsm-security-domain-${k}"
          validity_in_months = 12
        }
      }
    }
  }
}

module "managed_hsm" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module.git?ref=v1.0.0"

  name                = "hsm-prod-eastus2"
  resource_group_name = module.rg.name
  location            = var.location
  tenant_id           = data.azurerm_client_config.current.tenant_id
  admin_object_ids    = [data.azurerm_client_config.current.object_id]

  security_domain_key_vault_certificate_ids = values(module.kv_security_domain.certificate_ids)
  security_domain_quorum                    = 2

  tags = { environment = "prod" }
}

# Local RBAC -- the data-plane grant Azure RBAC cannot give.
module "crypto_user" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-role-assignment.git?ref=v1.0.0"

  managed_hsm_id     = module.managed_hsm.id
  name               = "1e243909-064c-6ac3-84e9-1c8bf8d6ad22"
  scope              = "/keys"
  role_definition_id = "/Microsoft.KeyVault/providers/Microsoft.Authorization/roleDefinitions/21dbd100-6940-42c2-9190-5d6cb909625b"
  principal_id       = data.azurerm_client_config.current.object_id
}

# THIS MODULE.
module "hsm_key" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key.git?ref=v1.0.0"

  name           = "key-storage-cmk"
  managed_hsm_id = module.managed_hsm.id

  key_type = "RSA-HSM"
  key_size = 4096
  key_opts = ["wrapKey", "unwrapKey"]

  # No expiration_date on purpose -- the rotation policy below handles expiry,
  # and setting it here would be irreversible.

  tags = { environment = "prod" }

  depends_on = [module.crypto_user]
}

# Rotation, as a separate resource -- there is no inline block on a Managed HSM key.
module "hsm_key_rotation" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-key-vault-managed-hardware-security-module-key-rotation-policy.git?ref=v1.0.0"

  # The DATA-PLANE URI, which is this module's `id` -- not an ARM path.
  managed_hsm_key_id = module.hsm_key.id

  expire_after       = "P90D"
  time_before_expiry = "P30D"
}

# A consumer that SHOULD follow rotations, so it takes the unversioned uri.
module "disk_encryption" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-disk-encryption-set.git?ref=v1.0.0"

  name                = "des-prod"
  resource_group_name = module.rg.name
  location            = var.location

  managed_hsm_key_id       = module.hsm_key.id
  auto_key_rotation_enabled = true

  tags = { environment = "prod" }
}

output "posture" {
  value = {
    hsm              = module.hsm_key.managed_hsm_name
    operations       = module.hsm_key.permitted_operations
    weak_rsa         = module.hsm_key.rsa_key_size_is_below_the_modern_2048_bit_floor
    permits_nothing  = module.hsm_key.key_permits_no_operations
    no_public_key    = module.hsm_key.no_public_key_material_is_emitted_by_this_resource
    rotation_trigger = module.hsm_key_rotation.rotation_trigger
  }
}

variable "name" { type = string }

# Anchored, case-insensitive on managedHSMs; rejects hsm_uri and a Key Vault ID.
variable "managed_hsm_id" { type = string }

# Closed set -- every option is HSM-protected. No software RSA or EC exists here.
variable "key_type" { type = string }

# Near miss rejected, unknown allowed. A set, not a list.
variable "key_opts" { type = set(string) }

variable "key_size" {
  type    = number
  default = null
}

variable "curve" {
  type    = string
  default = null
}

# Carries the inverted-date cross-check, referencing not_before_date.
variable "expiration_date" {
  type    = string
  default = null
}

variable "not_before_date" {
  type    = string
  default = null
}

variable "tags" {
  type    = map(string)
  default = {}
}

variable "timeouts" {
  type = object({
    create = optional(string)
    read   = optional(string)
    update = optional(string)
    delete = optional(string)
  })
  default = null
}

🔒 Nothing is marked sensitive, because there is nothing to mark. The provider emits no key material — see no_public_key_material_is_emitted_by_this_resource.

A Managed HSM has two independent authorization systems, and the one that matters here is not Azure RBAC. Microsoft documents a dual-plane model: the control plane at management.azure.com is governed by Azure RBAC, and the data plane at <hsm-name>.managedhsm.azure.net is governed by Managed HSM local RBAC. Creating, reading, rotating or deleting a key is a data-plane operation, so Owner or Contributor on the Managed HSM resource confers no ability to create this key — Azure's own security baseline records "Azure RBAC for Data Plane: Supported — False" for the service. The identity running Terraform needs a local-RBAC assignment, typically Crypto User to create and delete and Crypto Officer to purge or rotate, at scope /keys or /keys/<key-name>.

That grant is also an ordering problem this module cannot express. The provider's own example wires depends_on from the key to two role-assignment resources, because a configuration creating the HSM and the key in one pass will otherwise attempt the key before the identity is permitted to. No input on this module can carry that dependency — the role assignment is a sibling resource owned by terraform-azurerm-key-vault-managed-hardware-security-module-role-assignment — so it belongs in the composition, ordered explicitly. depends_on is valid on a module block; it is lifecycle that is not.

The resource emits no key material whatsoever, not even the public half, and that is a categorical difference from azurerm_key_vault_key. A Key Vault key emits public_key_pem, public_key_openssh and the raw components e, n, x and y. A Managed HSM key emits none of them; its only cryptographic identifiers are the two URIs. So there is nothing here to mark sensitive and nothing to leak — a stronger position than redaction, since this suite's usual practice is to emit a public key unredacted and keep the private half out of Terraform, and here the provider has removed the question. The consequence is practical: if you need the public key to pin a certificate or hand to a partner, fetch it from the data plane with az keyvault key download, and expect any pipeline that assumes a key resource yields a PEM to need rewriting. It is also worth remembering what sensitive = true would have bought anyway — it redacts plan output and does not encrypt state.

The converse of all that is a pleasant one: plan access here is not credential access. Refreshing this resource requires data-plane read on the key, but since the provider returns no material, an identity granted plan rights learns the key's metadata and never its bytes. In much of this library the opposite holds, so the distinction is worth stating rather than assuming.

expiration_date is one of the few genuinely irreversible edits in this library. The provider states that once set it cannot be unset even if the key is deleted and recreated, because the underlying API restores the purged key rather than creating a fresh one. On top of that, both dates are force-new in one direction only — and the direction is removal, not direction of travel. The CustomizeDiff predicate is old value non-empty, new value empty, so deleting either date argument replaces the key, while moving a date is an ordinary in-place update whichever way it moves. The two facts compound: under the provider defaults the replacement soft-deletes and then recovers the key, which brings the old expiry back, so deleting the line churns the resource and does not clear the expiry. Only with purge_soft_deleted_hsm_keys_on_destroy enabled and HSM purge protection off is the key genuinely purged and regenerated. The remedy is to express expiry through the sibling rotation policy instead, as a duration applied to each newly rotated version.

Two ID conventions live in one family, and each module rejects the other's. This resource's managed_hsm_id is an ARM Resource ID; its own id is a data-plane URI, and the sibling rotation policy consumes that URI. The parent module emits both an ARM id and an hsm_uri, both legitimate somewhere, which is precisely why the wrong one is easy to pass — so managed_hsm_id rejects the URI form by name, and name rejects the URI form too. The managedHSMs segment is matched case-insensitively, because Azure returns it capitalised while other tooling lower-cases it and a case difference is not a real error.

Every key type is hardware-protected, which shifts where the risk sits. EC-HSM, oct-HSM and RSA-HSM are the only options; the plain RSA and EC types that Key Vault accepts do not exist, and passing one is the predictable mistake when adapting a Key Vault configuration. key_type also decides which sizing argument applies — curve for EC, key_size for RSA and oct — and this module rejects supplying the wrong one as contradictory rather than merely redundant. Both halves of that pairing are placed on the argument they constrain, because a validation may only reference its own variable, which means an error can name a field the caller was not editing; the messages say so.

Two facts are reported rather than enforced, for different reasons. An empty key_opts produces a key that permits nothing: the provider documents no minimum, so refusing it would invent a constraint, and the failure would otherwise surface only when an application tried to use the key. An RSA-HSM key below 2048 bits is below every current recommendation, but the provider's own documentation offers 1024 as an example key_size — so this module declines to override its source of truth on a published point and surfaces the fact instead. That flag is key_type-aware, so a 256-bit oct-HSM AES key correctly reads false. A documentation wrinkle sits underneath it: the provider describes key_size as bytes and then gives bit values as examples, and Azure reads it as bits.

Finally, what happens on destroy is not this module's decision. Whether the key is soft-deleted or purged depends on purge_soft_deleted_hardware_security_module_keys_on_destroy in the caller's features {} block, so the same module can leave a recoverable key in one configuration and permanently destroy it in another. A purged key is unrecoverable, and anything encrypted under it is unrecoverable with it.

terraform init -backend=false
terraform validate
terraform fmt -check

Pin the module with ?ref=v1.0.0 — never a branch. Plan-only; a human applies from CI.

Before the first apply — the grant Azure RBAC will not give you:

az keyvault role assignment create --hsm-name hsm-prod \
  --role "Managed HSM Crypto User" --assignee <object-id> --scope /keys

# Confirm it landed.
az keyvault role assignment list --hsm-name hsm-prod --assignee <object-id> --scope /keys

After the apply:

# Metadata, including the current version.
az keyvault key show --hsm-name hsm-prod --name key-storage-cmk

# The public key -- which Terraform will not give you.
az keyvault key download --hsm-name hsm-prod --name key-storage-cmk --file public.pem

What the offline gate proves: that the configuration parses against the pinned provider, that formatting is canonical, and — via terraform console with variables files grouped by which variables each validation references — that all 17 validations fire on the input each targets. Grouping mattered here: key_size and curve both reference key_type, and expiration_date references not_before_date.

Suppression was demonstrated, not assumed. A file with a bad key_type and a negative key_size and the invalid curve P-512 produced exactly one error — every validation on key_size and curve was skipped because both reference the failed key_type. Re-running with a valid key_type then produced all of them. The same happened with the dates: a malformed not_before_date suppressed expiration_date's own shape check, so that check was only proved once not_before_date was left unset. A short error list is not proof a check is missing.

Proved with a failing value each: an empty name, a Resource ID in name, and the data-plane URI in name; hsm_uri in managed_hsm_id and a Key Vault ID in the same argument; key_type = "RSA"; key_opts containing wrapkey; key_size negative, fractional, missing for RSA-HSM, and present for EC-HSM; curve = "P-512", missing for EC-HSM, and present for RSA-HSM; both dates malformed; and a not_before_date a year after expiration_date.

The near-miss rule was proved in both directions in one file: wrapkey rejected while somethingNew passed.

Every derived value was printed rather than reasoned about, against all four key_type shapes. rsa_key_size_is_below_the_modern_2048_bit_floor read true for RSA-HSM/1024 and false for RSA-HSM/4096, EC-HSM and oct-HSM/256 — confirming the flag is key-type-aware rather than a bare numeric comparison. key_permits_no_operations read false with three operations and true with an empty set. permitted_operations came back sorted. The parsed HSM name, resource group and subscription were confirmed against two different Resource IDs.

What only an apply exercises: whether the HSM exists and is activated, and whether the identity holds the local-RBAC role — the most likely failure and one no offline check can reach.

What no Terraform run exercises at all: whether the key is actually usable by the applications that need it, and what the features {} toggle will do on a future destroy.

Outputs:

creating_this_key_requires_data_plane_rbac_that_azure_rbac_cannot_grant = true
curve = null
destroy_behaviour_depends_on_a_provider_features_toggle_the_caller_owns = true
expiration_date = null
expiration_date_can_never_be_unset_once_set = true
id = "https://hsm-prod-eastus2.managedhsm.azure.net/keys/key-storage-cmk"
key_permits_no_operations = false
key_size = 4096
key_type = "RSA-HSM"
managed_hsm_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-hsm-prod/providers/Microsoft.KeyVault/managedHSMs/hsm-prod-eastus2"
managed_hsm_name = "hsm-prod-eastus2"
managed_hsm_resource_group = "rg-hsm-prod"
name = "key-storage-cmk"
no_public_key_material_is_emitted_by_this_resource = true
not_before_date = null
permitted_operations = [
  "unwrapKey",
  "wrapKey",
]
rsa_key_size_is_below_the_modern_2048_bit_floor = false
tags = {
  "environment" = "prod"
}
versioned_id = "https://hsm-prod-eastus2.managedhsm.azure.net/keys/key-storage-cmk/9a8b7c6d5e4f3210"

• azurerm_key_vault_managed_hardware_security_module_key provider reference
• Microsoft Learn — Access control for Managed HSM
• Microsoft Learn — Managed HSM local RBAC built-in roles
• Microsoft Learn — Secure your Managed HSM deployment
• Parent: terraform-azurerm-key-vault-managed-hardware-security-module — supplies managed_hsm_id from its id output, and also emits hsm_uri, which is not what this module wants.
• Sibling: terraform-azurerm-key-vault-managed-hardware-security-module-key-rotation-policy — consumes this module's id (the data-plane URI). At most one per key, where an HSM holds many keys.
• Related: terraform-azurerm-key-vault — supplies certificate_ids for the HSM's security domain, and owns azurerm_key_vault_key for software- or vault-HSM-protected keys.
• Consumer: terraform-azurerm-disk-encryption-set — has a managed_hsm_key_id input; wire it to id so it follows rotations.
• This module's SCOPE.md.

💙 "Infrastructure as Code should be standardized, consistent, and secure."