Separate workload identity from the attestation decision that releases an asset key

Source facts

Microsoft’s cross-tenant asset-protection pattern keeps the vault and attestation authority with the publisher. A valid publisher-tenant identity token does not bypass the key’s attestation policy. The release gate does not itself protect an asset after decryption inside the guest; the pattern separately hardens that image. Its base design trusts the host, while optional confidential computing addresses host-memory access. Microsoft Learn.

Applicability

Use this review for an asset distributed into a consumer-controlled subscription, not as a generic assurance that any Trusted Launch VM conceals every secret. Identify the publisher, consumer, image owner, and accepted host threat model. Check the complete pattern and supported components before implementation.

DSE recommendation

Review identity authorization and the attestation release policy as separate decisions. Ask the asset owner to document which attested image measurements are acceptable and who may change that policy. Review the post-decryption guest controls alongside the key-release design. Do not close the security review merely because workload federation successfully obtained an identity token.

Verification

In an approved test, compare release behavior for the intended image and a deliberately nonmatching attestation condition. Preserve the decision and policy version without retaining the released key or protected asset in test logs. Examine the consumer’s remaining management and network paths separately. Record any accepted host-level risk explicitly instead of describing identity, measured boot, and confidential memory as interchangeable protections.

Official references

Microsoft Learn: Attestation-gated Secure Key Release pattern. Source reviewed September 9, 2026.