My understanding is there are currently four options with Azure Key Vault / HSM to protect your keys. a) Key Vault Software Protected Keys (Standard Pricing) b) Key Vault HSM Protected Keys (Premium Pricing) c) Key Vault managed-HSM , own HSM partition d) Dedicated HSM (no Key Vault) obviously with option a the keys are not protected / stored within a HSM specially for the other options, I am very interested to have a documentation or "official" statement on the key handling using the options azure offers via CLI / web interface and explicitly not considering some BYO key scenario. generated (within HSM, outside HSM and imported) operation performed within HSM or outside HSM (eg.: hashing, encryption) is the key exportable from the HSM , if not how to validate this (eg.: key attributes?) basically I am not able to find answers online to these questions and I am not able to validate this myself as the web interface only allow limited access anyhow. most documentation refers to BYO key where obviously proterties can be set and validated outside Azure , but I don't own HSM myself, so the BYO option is not applicable or feasible. it would be really nice to get some statement / documentation that can be taken as evidence, for the key not able to leave the HSM and all operations are performaed within the HSM feel free to ask questions if something is not clear, many thanks and regards

Key Vault HSM

George L. Hickox 1

My understanding is there are currently four options with Azure Key Vault / HSM to protect your keys.

a) Key Vault Software Protected Keys (Standard Pricing)
b) Key Vault HSM Protected Keys (Premium Pricing)
c) Key Vault managed-HSM , own HSM partition
d) Dedicated HSM (no Key Vault)

obviously with option a the keys are not protected / stored within a HSM
specially for the other options, I am very interested to have a documentation or "official" statement on the key handling using the options azure offers via CLI / web interface and explicitly not considering some BYO key scenario.

generated (within HSM, outside HSM and imported)
operation performed within HSM or outside HSM (eg.: hashing, encryption)
is the key exportable from the HSM , if not how to validate this (eg.: key attributes?)

basically I am not able to find answers online to these questions and I am not able to validate this myself as the web interface only allow limited access anyhow.

most documentation refers to BYO key where obviously proterties can be set and validated outside Azure , but I don't own HSM myself, so the BYO option is not applicable or feasible.

it would be really nice to get some statement / documentation that can be taken as evidence, for the key not able to leave the HSM and all operations are performaed within the HSM

feel free to ask questions if something is not clear, many thanks and regards

Marilee Turscak-MSFT 33,801 Reputation points Microsoft Employee

2021-10-06T23:34:11.51+00:00

With Key Vault, Microsoft doesn’t see or extract your keys. This is covered in the product overview. If you would like to discuss this further, feel free to send me an email (added in the private comment below).
George L. Hickox 1 Reputation point

2021-10-07T04:58:59.84+00:00

many thanks for you response (I can't find a private comment unfortunately)

the statement in the product overview about " MSF doesn't see or extract your keys" is a good start but very high level and eg. for software protected keys I trust you don't see or extract the key, still one would be able to do so. therefor HSM protected keys with premium Key Vault exists. In case I mark a key not extractable during creation I can't download the private key within web console, but I don't have any way to validate (eg. based on key attributes) that the key is in fact created within HSM and all operation have to happen in HSM as the key is not extractable. so for me the audit trail, or evidence that a HSM protected key really is inside hSM and also MSF can't extract it is rather weak or non existence if we ignore mostly marketing statements like the one in the product overview.