Azure Managed HSM Attestation Extraction, Non-Extractability and PoP

Hello @Vjaceslavs

For Azure Key Vault Managed HSM, Microsoft now provides key attestation, which provides cryptographic evidence that a key was generated and remains protected within the Managed HSM's FIPS 140-3 Level 3 hardware boundary.

For your first question, you can retrieve the attestation for a Managed HSM key with:

az keyvault key get-attestation \
  --hsm-name <hsm-name> \
  --name <key-name> \
  --version <key-version> \
  --file attestation.json

The resulting JSON contains the key properties, attestation blob, and certificates required to validate the attestation. The supplied validation tooling extracts the blob and certificates, builds the certificate chain back to the Marvell HSM vendor root, verifies the Microsoft-signed certificate, and parses the attested key attributes. For asymmetric keys, it provides both public- and private-key attestation information.

So this is substantially stronger than simply retrieving a public JWK and trusting an Azure API response: the attestation is designed to be independently cryptographically validated.

Regarding non-extractability, Managed HSM key attestation provides proof that keys are generated and processed within the FIPS 140-3 Level 3 boundary. Regular Managed HSM keys are nonexportable; the HSM doesn't release private key material in an unmasked state. Secure Key Release is a separate exception for keys deliberately created with an appropriate key-release policy.

However, be careful about translating that directly into the PKCS#11 statement CKA_EXTRACTABLE=false for a QTSP. Whether the current attestation binary contains the exact attribute/evidence your QTSP requires and whether the QTSP accepts Microsoft's Marvell/Microsoft certificate chain as proof of that requirement should be validated against the QTSP's specific PoP policy. The validator parses key attributes, but it doesn't by itself establish that every third-party QTSP will interpret the evidence as an attested PKCS#11 CKA_EXTRACTABLE=false assertion.

For the PKCS#10 CSR part, separate CSR generation from key attestation. A CSR does not require the private key to leave the HSM: your application can construct the PKCS#10 CertificationRequestInfo, hash it, ask the Managed HSM key to perform the signing operation, and then assemble the resulting signature into the CSR.

In other words, the important property is that the signature operation occurs with the HSM-protected private key, not that the private key is exported to whatever component constructs the CSR. Managed HSM is explicitly designed to perform cryptographic operations while keeping normal private key material nonexportable.

I haven't found current Microsoft documentation describing a native Managed HSM operation that simply returns a complete standards-compliant PKCS#10 CSR for an arbitrary Managed HSM key. Therefore, implement CSR construction client-side and use the Managed HSM signing operation, unless your QTSP specifically requires the entire CSR construction process to occur inside the certified boundary.

One final distinction: this answer applies specifically to Azure Key Vault Managed HSM. Don't assume Key Vault Premium exposes the same attestation evidence/API without verifying it separately.

References:

Validate Azure Managed HSM keys with key attestation

Azure CLI - az keyvault key get-attestation

Azure Managed HSM overview

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.