Azure Attestation TPM sample reaches round 1 InvalidDataField — request Severity C support case

Question

Azure Attestation TPM sample reaches round 1 InvalidDataField — request Severity C support case

Murshid Abdurahiman 0

We purchased Azure Standard support to open a development Severity C technical case. The portal routes the request to Microsoft Q&A rather than allowing case creation. Please advise how to submit this Azure Attestation technical case securely if a private support case is required.

We are evaluating Azure Attestation for a development-only Windows 11 TPM 2.0 device-assurance path. No production workload, customer data, registered devices, or offline permits are involved.

On a physical Windows 11 TPM 2.0 device, AIK enrollment succeeds and Azure accepts protocol round 0. The evidence-bearing round 1 consistently returns HTTP 400 with the bounded server code invalid_data_field, and no attestation report is produced.

The final reproduction preserves the current Microsoft TPM sample's native construction: Microsoft Platform Crypto Provider, machine AIK, provider-default RSA-2048 request key, official ATT_TPM wrappers, and no other_keys. It uses Microsoft.Attestation.Client 1.1.133870390-preview, REST API 2020-10-01, and the Microsoft sample source baseline at commit 84a502dcbedb674b505262f3eee022fd88ebc3ef. A strict valid-AIK policy remains enabled.

Earlier managed and provider-default diagnostics produced the same round-1 result. The native parity result therefore makes our managed ABI and hardened request-key template unlikely leading causes on this device. Every bounded run cleaned up successfully; the final exact-prefix AIK count was zero. We retained no raw TPM evidence, token, key material, certificate, identifier, or response message.

Please confirm whether this package/API/sample combination is currently supported for TPM attestation; whether InvalidDataField at round 1 reflects evidence parsing or validation before policy evaluation; the relevant evidence field or compatibility condition; and the current supported client/sample/API combination. If raw evidence or identifiers are essential, please specify the minimum fields and an approved secure upload method before we collect them.

Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-08-17T10:54:41.7766667+00:00
Hi Murshid Abdurahiman,

Apologies for the delay in being assigned this case. I’ll be actively working on this case from now on.

Thank you for sharing the detailed information regarding the Azure Attestation TPM validation issue.

Based on the details provided, we understand that AIK enrollment and protocol round 0 are successful, but the evidence-bearing round 1 request consistently fails with HTTP 400 and the server code invalid_data_field.

Azure Attestation supports TPM-based attestation; however, the public error response does not provide enough information to identify the exact evidence field or compatibility condition causing this failure. Since this may require review of request/evidence details, we recommend handling this through a private support.

Please do not share raw TPM evidence, request payloads, certificates, identifiers, tokens, or key material in the public Microsoft Q&A thread.

I have contacted you through a private message. Kindly check and respond there so we can proceed further securely.

For reference, please review the below Microsoft documentation:

TPM attestation overview for Azure: https://learn.microsoft.com/en-us/azure/attestation/tpm-attestation-concepts

Azure Attestation troubleshooting guide: https://learn.microsoft.com/en-us/azure/attestation/troubleshoot-guide

Create an Azure support request: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

Manage an Azure support request: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-manage-azure-support-request

Best regards,

Manasa Akula

Microsoft Azure Support

1 answer

Your answer

Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-08-17T10:54:41.7766667+00:00

Hi Murshid Abdurahiman,

Apologies for the delay in being assigned this case. I’ll be actively working on this case from now on.

Thank you for sharing the detailed information regarding the Azure Attestation TPM validation issue.

Based on the details provided, we understand that AIK enrollment and protocol round 0 are successful, but the evidence-bearing round 1 request consistently fails with HTTP 400 and the server code invalid_data_field.

Azure Attestation supports TPM-based attestation; however, the public error response does not provide enough information to identify the exact evidence field or compatibility condition causing this failure. Since this may require review of request/evidence details, we recommend handling this through a private support.

Please do not share raw TPM evidence, request payloads, certificates, identifiers, tokens, or key material in the public Microsoft Q&A thread.

I have contacted you through a private message. Kindly check and respond there so we can proceed further securely.

For reference, please review the below Microsoft documentation:

TPM attestation overview for Azure: https://learn.microsoft.com/en-us/azure/attestation/tpm-attestation-concepts

Azure Attestation troubleshooting guide: https://learn.microsoft.com/en-us/azure/attestation/troubleshoot-guide

Create an Azure support request: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

Manage an Azure support request: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-manage-azure-support-request

Best regards,

Manasa Akula

Microsoft Azure Support

Answer 1

Hello @Murshid Abdurahiman

Thank you for providing such a detailed reproduction. Given the testing you've already performed, I don't think additional generic TPM provisioning or certificate troubleshooting would add much at this stage.

The important part of your reproduction is that:

AIK enrollment succeeds.
Azure Attestation accepts round 0.
The evidence-bearing round 1 consistently returns HTTP 400 with invalid_data_field.
The behavior remains when using the Microsoft TPM sample's native construction.
The final successful prefix-AIK count is zero.
No TPM evidence, token, certificate, identifier, or response payload has been posted publicly.

Azure Attestation does support attestation of TPM-backed platforms, according to Microsoft's Azure Attestation documentation. However, the public REST API documentation doesn't provide enough information about the internal validation that produces invalid_data_field to determine from the error alone which evidence element failed validation.

For that reason, I think this has reached the point where Microsoft engineering needs to inspect the request/evidence or confirm the currently supported TPM client/sample/API combination.

Regarding the support-routing issue: what you're seeing appears consistent with Microsoft's current Priority Community Support (PCS) workflow for Severity C Azure technical requests.

Microsoft documents that some technical requests are initially handled through Microsoft Q&A. If the issue requires deeper investigation, a Microsoft engineer can create a support ticket on the customer's behalf.

Microsoft also explicitly advises customers not to post sensitive customer information publicly. If logs, TPM evidence, identifiers, request bodies, certificates, or other customer-specific diagnostic data are required, a Microsoft engineer can contact you through a private channel to collect them securely.

So I would not post the raw TPM evidence or complete request payload in this thread.

At this point, I would ask the Microsoft moderator/engineer reviewing this thread to determine whether escalation is required and, if so, initiate the private support workflow.

For the engineering investigation, I think the key questions are:

Is Microsoft.Attestation.Client 1.1.133870390-preview with the 2020-10-01 Attestation REST API currently a supported combination for Windows 11 TPM 2.0 attestation?
Does InvalidDataField at evidence-bearing round 1 occur during request/evidence deserialization or cryptographic validation before policy evaluation?
Which evidence field or compatibility requirement can produce this response when AIK enrollment and round 0 have already succeeded?
Is there a newer supported Microsoft TPM sample/client/API combination that should be used instead?
If engineering needs the raw round-1 request/evidence to identify the failing field, can they provide a private upload or support-case channel for it?

Your successful round 0 followed by a deterministic failure only when the evidence-bearing request is submitted is particularly useful information. It narrows the problem considerably, but I don't think the public error response provides enough diagnostic detail to identify the offending field safely from Q&A alone.

Microsoft's Azure support documentation also confirms that support requests can contain diagnostic files and other troubleshooting information once a support case is established.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Murshid Abdurahiman 0 Reputation points

2026-08-09T01:33:34.9633333+00:00

Thank you, Allan Allan Solomon Mejia. Your assessment is very helpful, and I appreciate the detailed response. As the issue remains unresolved, I will leave the question open until a Microsoft Azure Attestation moderator or support engineer can determine whether it should be converted to a private support case, since any required evidence cannot be posted publicly.
Allan Solomon Mejia 5,420 Reputation points

2026-08-09T03:28:32.1666667+00:00

Hi @Murshid Abdurahiman

Once assisted by a moderator, please don't forget to "Accept the Answer" if this information helped you. This will help us and others in the community as well.