Skip to main content
Version: v0.25.0 (Latest)

Connect Azure KMS with BYOK and BYOC

Issuer credentials, status lists and verifier request objects are all signed with a KMS resource and key alias. This journey reads what KMS material the tenant already has, then configures Azure Key Vault or Managed HSM so keys stay in Azure while EDK references them.

Complete first: Onboard a tenant.

Steps and why they come in this order​

StepWhy here
1. Read KMS offerings and resourcesThe offerings say whether the deployment permits the Azure kind at all, and the resource list shows what the tenant already signs with.
2. Configure the Azure Key Vault providerA key reference needs a provider that holds the Azure coordinates and a credential reference, so the provider comes before any key.
3. Register an existing Azure key (BYOK)Signing settings select a key alias. The alias must be registered and readable before issuer, status-list or verifier settings reference it.
4. Register the certificate chain (BYOC)mdoc signing and x5c-based credentials need a public chain linked to the key. Register it after the key so the link can be checked.
5. Remove references safelyRemoval is last because it only makes sense once you know which configuration still selects a key or chain.

Three identifiers that get confused​

IdentifierOwned byWhat it selects
kmsResourceHandle (krh_...)Platform configurationThe configured resource an administrator attaches, validates, rotates or retires
providerIdKMS runtimeThe concrete provider that signs; this is what applications send
key alias or canonical kidAzureThe key inside that provider, referenced without copying it

Issuer, status-list and verifier settings select a resource handle plus a key alias. Runtime key and certificate calls use the provider id plus the alias. A handle never stands in for a provider id.

BYOK here means registering a reference to a key that already exists in Azure. BYOC means registering public certificate material or a reference to a certificate Azure already holds. No operation in this journey exports an Azure private key, and deleting an EDK reference never deletes the Azure object.

Deeper reference​

Azure KMS, BYOK, and BYOC has the full provider lifecycle, shared-vault tagging rules and captured calls. The optional 05 Azure KMS, BYOK, and BYOC (opt-in) Postman folder runs against an explicitly approved environment only.

Next journey​

Continue with Configure the authorization server.