Trusted Launch Windows: signed AK-to-VM binding and read-only retrieval

Question

Trusted Launch Windows: signed AK-to-VM binding and read-only retrieval

Klooless 0

Is a Microsoft-signed binding between the existing vTPM AK and immutable Azure vmId supported for this non-confidential Trusted Launch Windows configuration? If yes, please identify the exact supported evidence and verification method. If not, please state that limitation explicitly.

For an existing non-confidential Trusted Launch Windows Server 2022 Gen2 Standard_D4as_v5 VM, what supported Microsoft-signed certificate field—including its exact OID/ASN.1 semantics—or attestation structure binds the existing vTPM AK public key/TPM Name to immutable Azure vmId; who signs it, how must an independent verifier validate its chain, signature, freshness and identity, and which supported read-only retrieval path and minimum Windows/TBS/TPM permissions obtain it without key creation, persistence, renewal or enrollment? Specifically, do the pinned SDK’s NV 0x01c101d0 and handle 0x81000003 reads apply to this configuration?

Referenced SDK source revision: feec5c9b0ea54f9e70021616358e313a587c0c95—not a claim about the latest release or a tested binary.

This question is based on public source/documentation inspection only, not a live test, confirmed defect or security vulnerability. No key-creation, enrollment or mutating quote helper has been invoked. A separate signed VM-identity document or a valid AK certificate chain alone is not being assumed to establish a signed relationship between the two.

Relevant public references:

0 comments

1 answer

Your answer

Answer 1

Hello Klooless

For an existing non-confidential Azure Trusted Launch Windows VM, I cannot find a publicly documented Microsoft-supported structure that cryptographically binds the existing vTPM Attestation Key (AK) or TPM Name to the Azure vmId.

Microsoft documents two separate artifacts:

the AK certificate chain, which establishes trust in the vTPM AK;

the IMDS attested document, which is Microsoft-signed and contains vmId.

However, the public documentation does not define a signed field, certificate OID, or attestation structure that links the AK to that vmId. Therefore, validating both artifacts independently does not prove that the AK is bound to that VM identity.

For the pinned SDK revision feec5c9b0ea54f9e70021616358e313a587c0c95:

NV 0x01C101D0 is used to read the AK certificate.

Handle 0x81000003 is used to read the AK public key.

These paths are read-only and do not create or persist a new AK.

So the concise conclusion is:

Yes, the pinned SDK provides read-only retrieval of the existing AK certificate/public key for Trusted Launch. No, the published Microsoft documentation does not currently define a supported Microsoft-signed AK-to-vmId binding for this configuration.For an existing non-confidential Azure Trusted Launch Windows VM, I cannot find a publicly documented Microsoft-supported structure that cryptographically binds the existing vTPM Attestation Key (AK) or TPM Name to the Azure vmId.

Klooless 0 Reputation points

2026-09-19T15:48:40.8233333+00:00

Thank you. To distinguish an official support limitation from a documentation gap: is the absence of a supported Microsoft-signed binding between an existing vTPM AK and immutable Azure vmId officially confirmed for non-confidential Trusted Launch Windows Server 2022 Gen2 (Standard_D4as_v5), or are you reporting only that no public documentation was found? Please cite the supporting Microsoft statement/documentation or identify an explicit Microsoft product-team confirmation. If a supported binding exists, please identify its signed field/structure and verification method. Separately, is the stated Trusted Launch applicability of the pinned existing-key reads documented by Microsoft, or inferred from source inspection?