Fix Autopilot Securing Your Hardware Failed 0x800705B4

Securing your hardware (Failed: 0x800705B4) is one of the Autopilot errors that looks vague on the device and specific in the logs. The screen usually shows the next Autopilot steps as skipped or failed because the hardware security step failed first. Microsoft documents 0x800705B4 as a timeout, and in self-deploying or pre-provisioned deployments the common trigger is TPM attestation not completing.

Do not start by deleting every device record. Treat this as a TPM, deployment-mode, network, and profile-assignment problem. The device must be able to prove its TPM identity, reach the required attestation endpoints during OOBE, and receive one correct Autopilot profile. If any of those fails, the technician flow or self-deploying flow can stop before Intune enrollment gets far enough to install apps or policies.

Use this runbook when Autopilot fails during OOBE at Securing your hardware, especially for self-deploying mode, kiosk-style deployments, shared devices, or pre-provisioning performed by a depot or field technician.

What 0x800705B4 means in Autopilot

In Windows, 0x800705B4 generally means a timeout. In Autopilot, the important question is what timed out. Microsoft lists the self-deploying mode error as a timeout and calls out TPM 2.0 capability as a common cause. The Intune enrollment troubleshooting article shows the visible failure text:

Securing your hardware (Failed: 0x800705b4)
Joining your organization's network (Previous step failed)
Registering your device for mobile management (Previous step failed)

That sequence matters. The device is not failing because an app install timed out. It is failing before the later Autopilot stages get a fair chance. In self-deploying mode and pre-provisioning, Autopilot relies on TPM attestation to identify the device without a user signing in first. If the TPM cannot attest, if the device has only TPM 1.2, if the TPM is virtual, or if required URLs are blocked, the process can time out at the hardware step.

Microsoft’s documented requirements are strict:

Self-deploying mode and pre-provisioning require a physical TPM 2.0 chip.
Virtual TPMs, such as Hyper-V VMs, are not supported for those flows.
Pre-provisioning requires Windows Pro, Enterprise, or Education on a supported Windows version.
An Enrollment Status Page profile must be targeted to the device for pre-provisioning.
TPM attestation must be able to reach Microsoft and TPM vendor endpoints during OOBE.

If you are testing Autopilot self-deploying mode inside a VM, stop there. That lab is useful for user-driven testing, but it is the wrong test bed for this error.

Quick triage checklist

Start with one failed device. Capture the exact screen, serial number, hardware hash state, profile name, and network used during OOBE before making tenant-wide changes.

Confirm the deployment mode is self-deploying or pre-provisioned. 0x800705B4 at this stage is most relevant to those modes.
Confirm the device has physical TPM 2.0 enabled in firmware. Do not accept a vendor spec sheet as proof. Check the actual device state.
Confirm the device is running a supported Windows client edition and build for Autopilot.
Check whether the same device is in multiple groups that assign different Autopilot profiles.
Verify the Autopilot device record exists and has the intended profile assigned.
Test OOBE on an open network or a known-good corporate network path.
Allow access to *.microsoftaik.azure.net and the TPM vendor certificate endpoints.
Confirm SSL inspection, captive portals, and proxy authentication are not interfering during OOBE.
Collect diagnostics from the failure screen or from Intune if the device uploaded logs.
Reset only after you have enough evidence to compare the next attempt.

This is also where you separate hardware population issues from tenant configuration issues. If one model fails and another works on the same network and profile, suspect TPM firmware, OEM image state, or model-specific endpoint access. If every model fails on the same network, suspect firewall, proxy, or profile assignment.

Validate TPM and attestation access

Autopilot self-deploying mode and pre-provisioning use the TPM as the identity anchor. The TPM must be present, enabled, owned correctly by Windows, and capable of attestation. For a technician standing at the device, the fastest first check is firmware setup and Windows TPM state after a reset or from a test boot.

On a running Windows device, check:

Get-Tpm
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer

You want TpmPresent, TpmReady, and TpmEnabled to be true, with TPM 2.0 confirmed through tpm.msc, vendor tools, or the OEM management stack. If the device was previously used, clear stale provisioning state through the supported Autopilot reset or re-registration path rather than random registry cleanup.

Network access is the next failure point. Microsoft documents that TPM attestation for Autopilot self-deploying mode and pre-provisioning requires this URL pattern:

*.microsoftaik.azure.net

Firmware TPM devices also need to retrieve certificates from the provider on first use. Microsoft gives these examples:

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

Do not test these only from an admin laptop after it has the full corporate proxy profile. The OOBE device does not have your post-enrollment certificate store, proxy policy, VPN client, or trusted root changes yet. If the network requires authentication or breaks TLS before enrollment, Autopilot can fail before Intune has a chance to fix the network.

A practical test is to run the same model on a simple wired network with direct internet egress. If the device succeeds there but fails on the build bench VLAN, the Autopilot profile is probably not the root cause. Fix the OOBE network path, then retest the production VLAN.

Check profile assignment and conflicting deployment modes

The next common trap is profile ambiguity. Microsoft calls out a related pattern in enrollment troubleshooting: if the same device is in two assigned groups and each group applies a different Autopilot profile, remove the wrong assignment and leave the intended profile.

For a failed device, check this path:

Intune admin center > Devices > Windows > Windows enrollment > Devices

Open the Autopilot device record and confirm:

The serial number matches the device in hand.
The hardware hash was uploaded for this physical device.
The profile status is assigned before OOBE starts.
The assigned profile is the one you expect for self-deploying or pre-provisioning.
The device is not also targeted by a conflicting user-driven or hybrid profile.

For pre-provisioning, also confirm that an ESP profile is targeted to the device. Microsoft states that pre-provisioning requires an Enrollment Status Page profile. Without it, the technician flow is not a valid test of your intended deployment.

If you are using dynamic groups, allow enough time for evaluation and assignment before booting the device into OOBE. A rushed test can look like a TPM error when the profile simply was not ready. For depot workflows, build a waiting step into the intake process: import hash, wait for group membership, confirm profile assignment, then start the technician flow.

Collect useful logs before resetting

Resetting immediately can erase the timeline you need. When Autopilot fails, collect diagnostics from the device if the option is available. Microsoft notes that diagnostics are automatically collected on Autopilot failure by default, and Windows 11 can show an Autopilot diagnostics page when enabled in the ESP profile.

Enable this before the next pilot wave:

ESP profile > Show app and profile configuration progress: Yes
ESP profile > Turn on log collection and diagnostics page for end users: Yes

On Windows 11 user-driven scenarios, the diagnostics page can be opened with View Diagnostics or Ctrl + Shift + D when supported. Even when the full diagnostics page is not available for your exact flow, the failure screen and collected logs are better than a screenshot alone.

Review these areas:

Event Viewer > Applications and Services Logs > Microsoft > Windows > Provisioning-Diagnostics-Provider
Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin
Event Viewer > Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider
Registry: HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

Autopilot event IDs around profile download and TPM identity are especially useful. Microsoft documents event 171 as AutopilotManager failed to set TPM identity confirmed, which points back to TPM attestation. It also documents events such as 807 for a device that is not properly registered and 815 for no assigned profile. Those are different repairs, so do not lump them all under one generic Autopilot timeout.

The registry path can confirm whether the device received tenant and profile data. If tenant fields are blank or IsAutopilotDisabled is set, investigate profile download, registration, and network access rather than app assignment.

Repair workflow for one failed device

Use this sequence when you have a device on the bench and need a clean answer.

Photograph the failure screen and record the serial number.
In Intune, confirm the Autopilot record and assigned profile.
In group membership, remove any conflicting profile assignments.
Confirm the profile mode matches the hardware. Use physical TPM 2.0 for self-deploying and pre-provisioning.
Move the device to a known-good OOBE network with direct access to Microsoft and TPM vendor endpoints.
Reset the device from the failure flow or reinstall with a clean supported Windows image if the OEM image is suspect.
Start OOBE again and watch the hardware step.
If it still fails, collect diagnostics and look for TPM identity, profile assignment, and registration events.
Update BIOS and TPM firmware for the affected model, then retest one device before changing the fleet.
If the device was reused or previously enrolled, follow the supported Autopilot cleanup path for Intune, Entra ID, and the Autopilot record before re-registering.

For hardware models with known TPM attestation issues, check OEM advisories and firmware notes. Microsoft’s Autopilot known issues page has previously tracked model and TPM-family issues, including TPM attestation failures on some ST Micro and Nuvoton TPMs and AMD firmware TPM problems resolved by later firmware. That does not mean every 0x800705B4 is an OEM bug, but it does mean firmware belongs in the troubleshooting path.

Limitations and caveats

0x800705B4 is a timeout, not a full root cause. The same visible code can be produced by unsupported hardware, blocked network paths, delayed profile assignment, stale device records, or firmware behavior. Fix the evidence you have, not the code alone.

Pre-provisioning has timing caveats too. Microsoft says the user flow should wait at least 90 minutes after technician flow in lab and testing scenarios so tokens refresh properly. Running the user flow immediately after technician flow can create confusing follow-on errors that are separate from the original hardware step.

Hybrid join adds another layer. Microsoft recommends cloud-native Microsoft Entra join for new devices and does not recommend Microsoft Entra hybrid join for new Autopilot deployments unless there is a real requirement. If your tenant still uses hybrid join, separate domain connectivity and Intune Connector issues from TPM attestation. A failed hardware step happens earlier than many hybrid join repairs.

Finally, do not rely on Intune policy to fix OOBE proxy behavior. Microsoft warns that deploying proxy settings through Intune policy is not fully supported for Autopilot because the policy arrives too late for early provisioning needs. Configure the network path outside the device where possible.

Conclusion

Securing your hardware (Failed: 0x800705B4) should push you toward TPM attestation and early OOBE dependencies first. Confirm physical TPM 2.0, remove profile conflicts, allow Microsoft and TPM vendor endpoints before enrollment, and collect diagnostics before each reset. Once one device succeeds on a known-good network and profile, move the fix back into the production build process: update firmware, clean up assignments, document the required firewall rules, and make profile assignment verification part of every Autopilot intake checklist.

Sources: Microsoft Intune Windows enrollment troubleshooting, Windows Autopilot known issues, Windows Autopilot pre-provisioned deployment, Windows Autopilot requirements, and Windows Autopilot troubleshooting FAQ.