Fix Autopilot TPM Attestation Error 0x80070490 on AMD ASP fTPM Platforms

If Windows Autopilot fails during self-deploying mode or pre-provisioning and the device throws TPM attestation error 0x80070490, treat it as an AMD ASP firmware TPM issue first.

Microsoft documents a separate known issue for AMD platforms with ASP fTPM where TPM attestation can fail with 0x80070490 on Windows systems. That matters because admins often burn hours on the wrong branch. They retry the deployment, tweak Enrollment Status Page settings, reassign apps, or reimport the hardware hash when the real blocker is lower in the trust chain.

This is not the same failure family as the more visible Autopilot TPM errors like 0x81039001, 0x81039023, or 0x81039024. In this branch, Microsoft is telling you the problem is tied to AMD ASP firmware TPM, and that later AMD firmware versions resolve it. That makes the troubleshooting order much simpler: prove you’re in the attestation path, capture the evidence, verify network and time prerequisites, then move quickly to firmware validation with the OEM.

Quick fix checklist

Use this sequence before you reset another bench device:

1. Confirm the failing deployment path is self-deploying mode or pre-provisioning.
2. Record the exact code shown on screen or in logs: 0x80070490.
3. Press Shift + F10 at the failure screen and export diagnostics before you change anything:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Temp\autopilot-amd-ftpm-0x80070490.cab

4. Check the Autopilot event log for Event ID 171 and 172.
5. Run Get-Tpm and tpmtool getdeviceinformation to confirm the TPM and firmware details.
6. Verify access to *.microsoftaik.azure.net and the AMD certificate endpoint https://ftpm.amd.com/pki/aia.
7. Sync the device clock with w32tm /resync /force if the device time is questionable.
8. Update the system to the latest OEM BIOS/UEFI and any available AMD firmware TPM update.
9. Retest one pilot device before reopening the wider rollout.

If those steps confirm AMD ASP fTPM plus 0x80070490, stop treating the incident like a Win32 app or ESP policy problem.

What Microsoft is actually saying

On the Windows Autopilot known issues page, Microsoft lists this issue explicitly:

TPM attestation isn't working on AMD platforms with ASP fTPM

Microsoft’s wording is direct:

TPM attestation for AMD platforms with ASP firmware TPM might fail with error code 0x80070490 on Windows systems. This issue is resolved on later versions of AMD firmware. Consult with device manufacturers and firmware release notes for which firmware versions contain the update.

That tells you three important things.

First, this is a known Microsoft-documented failure family, not a one-off tenant problem.

Second, the issue is tied to AMD firmware TPM, not generic Intune enrollment.

Third, the remediation path is firmware-led. Microsoft is pushing you toward the OEM and firmware release notes, not toward policy rebuilds.

For Autopilot admins, that is a strong signal to move the case out of the “maybe our profile is broken” bucket and into the “hardware trust path needs correction” bucket.

Why 0x80070490 breaks Autopilot so early

Microsoft’s Windows Autopilot self-deploying mode documentation says self-deploying mode uses the device’s TPM 2.0 hardware to authenticate the device into the organization’s Microsoft Entra tenant. The same doc states that devices must also support TPM device attestation.

The Windows Autopilot requirements page makes the dependency even clearer for both self-deploying mode and pre-provisioning:

The TPM attestation process requires access to a set of HTTPS URLs, which are unique for each TPM provider. Ensure access to this URL pattern: *.microsoftaik.azure.net.

Microsoft also calls out the provider-specific firmware TPM certificate URLs, including:

• Intel: https://ekop.intel.com/ekcertservice
• Qualcomm: https://ekcert.spserv.microsoft.com/EKCertificate/GetEKCertificate/v1
• AMD: https://ftpm.amd.com/pki/aia

That matters because self-deploying mode and pre-provisioning depend on a hardware trust handshake before the device can move on to the app and policy phase. If TPM attestation fails, nothing downstream matters yet. The deployment can stall while the help desk keeps looking at the wrong telemetry.

In practice, the pattern usually looks like this:

• one AMD-based model fails repeatedly while another model with the same profile succeeds
• the device never gets cleanly past the hardware verification phase
• repeated retries change nothing
• the same tenant, profile, and app stack work on unaffected hardware

When you see that pattern and the log gives you 0x80070490, stay on the TPM branch.

Logs and where to check

1. Export the Autopilot and TPM diagnostics first

From the failure screen, use Shift + F10 and collect the CAB before resetting the device:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Temp\autopilot-amd-ftpm-0x80070490.cab

Do this first. Once the device is reset, the best evidence is usually gone.

2. Check the Autopilot event log for Event IDs 171 and 172

Microsoft’s Windows Autopilot troubleshooting FAQ maps the key TPM attestation events this way:

• Event ID 171: AutopilotManager failed to set TPM identity confirmed. HRESULT=[error code].
• Event ID 172: AutopilotManager failed to set Autopilot profile as available. HRESULT=[error code].

Microsoft also notes that Event 172 is typically related to Event 171.

Pull those events with PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Where-Object { $_.Id -in 171,172 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

If Event 171 carries 0x80070490, you have much stronger evidence that the device is failing at TPM attestation and not later in ESP.

3. Confirm the TPM state and firmware details

Get-Tpm | Format-List *

tpmtool getdeviceinformation

Capture at least:

• TPM manufacturer text
• firmware or specification version
• whether the TPM is present, enabled, activated, and ready
• BIOS/UEFI version
• device model and SKU

The useful comparison is not one device in isolation. Compare a failed AMD device against a working device on a different hardware family using the same Autopilot profile.

4. Verify the required HTTPS endpoints

For self-deploying mode and pre-provisioning, Microsoft says the attestation path requires access to the shared Microsoft endpoint pattern:

• *.microsoftaik.azure.net

For AMD firmware TPM specifically, Microsoft also says the device must be able to reach:

• https://ftpm.amd.com/pki/aia

Quick connectivity tests:

Test-NetConnection login.live.com -Port 443
Test-NetConnection ztd.dds.microsoft.com -Port 443
Test-NetConnection ftpm.amd.com -Port 443

Those checks do not prove firmware is healthy, but they help you avoid chasing a firmware issue while a proxy or outbound filter is blocking certificate retrieval.

5. Check the clock

Clock skew creates noisy TPM attestation symptoms. If the device sat powered off for months or the bench network has poor time access, resync it:

w32tm /resync /force

If your staging network is tightly controlled, also verify that time sync is not being silently blocked.

A practical remediation workflow

Step 1: Prove the issue is model-specific, not profile-specific

Before changing any profile assignments, compare:

• one failing AMD-based device
• one working device on another platform
• both using the same Autopilot path and policy set

If only the AMD line fails and the error stays at 0x80070490, that is the strongest signal that the profile is not the primary issue.

Step 2: Move to the OEM firmware baseline

This is the most important step in the whole workflow.

Microsoft says the issue is resolved on later AMD firmware versions and tells admins to consult device manufacturers and firmware release notes for the versions that include the update. That means your next escalation point is typically the OEM support matrix for the exact model, not more Intune experimentation.

Look for updates that mention any of the following:

• BIOS or UEFI trust fixes
• AMD PSP or ASP firmware TPM fixes
• TPM attestation reliability fixes
• security processor firmware updates

If your fleet includes multiple OEMs, do not assume the same AMD generation behaves the same way across vendors. The remediation package may be vendor-specific even when the failure signature looks identical.

Step 3: Retest with one clean pilot

After the firmware update:

1. reconnect the device to a known-good network
2. sync the clock
3. confirm the device can reach *.microsoftaik.azure.net and ftpm.amd.com
4. rerun self-deploying mode or pre-provisioning
5. recheck Event IDs 171 and 172

If the error disappears after firmware remediation, you have your root cause.

Step 4: Quarantine the bad hardware baseline

If you are in the middle of a deployment wave, do not keep feeding devices with the same failing firmware into the bench queue. Pause that hardware family, document the minimum fixed firmware baseline, and keep the help desk from repeating a failure that has already been explained.

Step 5: Only then review secondary causes

If the firmware is current and the device still fails, then review the adjacent causes that can complicate attestation:

• blocked outbound HTTPS to TPM certificate endpoints
• broken proxy design for privileged Autopilot deployments
• stale or invalid device records during repeated pre-provisioning reuse
• broader TPM health issues outside the AMD known issue itself

But do that after the firmware branch is closed, not before.

What not to waste time on

When this exact AMD ASP fTPM known issue is in play, these are the usual dead ends:

• retuning Enrollment Status Page timeouts before proving attestation works
• changing Win32 app targeting before the device clears hardware trust
• reimporting hardware hashes as a first move
• assuming every TPM failure should be handled like 0x81039001 or 0x81039024
• pushing proxy settings by Intune policy and expecting privileged Autopilot flows to behave cleanly

Microsoft’s own networking guidance warns that implementing proxy settings through Intune policy is not fully supported for these privileged deployment paths. If the network is part of the problem, fix it at the proxy or firewall layer.

Prevention

To stop 0x80070490 from turning into a repeat outage:

1. Validate one device per AMD-based model during pilot intake.
2. Record the shipping BIOS/UEFI and TPM-related firmware versions before broad rollout.
3. Add a preflight check for access to *.microsoftaik.azure.net and https://ftpm.amd.com/pki/aia.
4. Keep a known-good staging network for self-deploying mode and pre-provisioning validation.
5. Track the minimum approved firmware baseline by model, not just by CPU generation.
6. Escalate repeated Event 171 plus 0x80070490 to hardware engineering or the OEM fast.

Bottom line

If Windows Autopilot fails with TPM attestation error 0x80070490 on an AMD ASP fTPM platform, do not treat it like a generic Intune enrollment issue.

Microsoft documents this as a known AMD firmware TPM problem and says it is resolved in later firmware versions. The fastest path is to confirm the attestation events, collect the CAB, verify access to *.microsoftaik.azure.net and https://ftpm.amd.com/pki/aia, then move straight to OEM firmware validation and pilot retest.

That gets you to a real fix faster than another round of profile edits ever will.

Sources

• Windows Autopilot known issues
• Windows Autopilot troubleshooting FAQ
• Windows Autopilot self-deploying mode
• Windows Autopilot requirements
• Windows Autopilot for pre-provisioned deployment