Autopilot ESP timeout 0x800705b4: TPM attestation and Device Preparation before you wipe again

Most Autopilot pilots treat Autopilot ESP timeout 0x800705b4 as a single broken setting—raise the ESP timeout, clear the TPM, wipe the box, and try again. That version is why the same hex keeps landing on the next unit: Microsoft documents 0x800705B4 as a general timeout, not a diagnosis of which phase actually stalled.

Across tenants we assess after self-deploying, pre-provision, or hybrid Autopilot stalls with that code, the hang almost always collapses to three different failure modes—and another blind wipe without naming the phase just buys the same red screen.

Self-deploying / pre-provision "Securing your hardware" is TPM attestation, not a loose ESP slider

When self-deploying or technician pre-provision dies on Securing your hardware (Failed: 0x800705b4), you are in the TPM attestation path—not the later ESP Apps queue. Self-deploying mode requires TPM 2.0 and device attestation. Microsoft's known-issues and self-deploying docs are explicit: hardware that is not TPM 2.0 capable—including many Hyper-V / VM setups that only expose a vTPM—is a common way to land this timeout. Enrollment-errors guidance maps the same Securing your hardware failure to physical TPM 2.0 and OS build requirements.

A lab VM that "has a TPM" in Hyper-V Manager is not the same as a physical TPM 2.0 device that can complete Autopilot attestation against Microsoft's endpoints. Firmware that is mid-update, Secure Boot off when your baseline expects it on, or blocked attestation traffic will fail the same way. The fix is not another ESP timeout bump.

What breaks it:

• Confirm physical TPM 2.0 before self-deploying / pre-provision pilots — stop proving attestation on unsupported VM + vTPM paths that Microsoft already calls out.
• Run tpmtool getdeviceinformation on the failed unit and keep the output with the enrollment evidence.
• Prove reachability to attestation endpoints from that VLAN (proxy, SSL inspection, DNS) before you clear TPM and wipe again.

ESP / Device Preparation policy-provider and required-apps timeouts are a different 0x800705b4

A later Device Preparation or Enrollment Status Page stall that surfaces 0x800705b4 (or a sibling timeout) while the device is already past Securing your hardware is usually ESP waiting on a policy provider or a required app that never finishes—not attestation. Microsoft's ESP troubleshoot guidance is the playbook here: which phase is on screen, which tracked app or policy is still pending, and whether detection / content delivery ever completed.

Techs often collapse both screens into "ESP timed out" and raise the global timeout. That hides a packaging or assignment miss the same way un-tracking a bad Win32 greens the pilot without teaching you which package is broken. If the phase is Apps or Account setup, chase ESP / app installation evidence in Intune—not another tpmtool loop that already showed a healthy TPM.

If Autopilot keeps dying with ESP / Device Preparation timeout 0x800705b4 — TPM attestation stalls, self-deploying on a VM, or hybrid join hanging before apps — start with our Windows Autopilot Managed path instead of another one-off profile reset.

What breaks it:

• Name the ESP / Device Preparation phase from the screen and Intune ESP evidence before you touch timeouts or wipe.
• Separate TPM attestation failures from policy-provider / required-apps waits — same hex, different runbooks.
• Collect mdmdiagnosticstool.exe -area Autopilot;TPM (plus Autopilot / ESP logs) so the next change is tied to one enrollment, not an anonymous wipe.

Hybrid Autopilot can finish join and apps while ESP still times out

The third mode shows up in hybrid Autopilot shops: domain join, Entra, Intune enrollment, and even required apps look complete—yet ESP still times out or fails. Community threads on that pattern (hybrid completes AD / Entra / Intune and installs apps, ESP still fails) are a triage signal, not a root-cause claim. The point for your runbook is operational: do not wipe before you name which ESP row failed and whether the underlying work already succeeded.

If join and apps are healthy in Intune but ESP still failed the enrollment, you may be looking at ESP tracking / timeout configuration versus a real install miss. Another Autopilot profile reset that does not record the phase reprints the same ticket. Capture the ESP row, the Intune device timeline, and whether apps actually installed under the contexts ESP cares about—then decide if the timeout is noise on a successful enrollment or a real blocker you still have to fix.

What breaks it:

• Inventory the last failed hybrid enrollments: phase on screen, join state, app install state, ESP result—side by side.
• Do not wipe a unit whose join and apps already succeeded until you decide whether ESP tracking is lying or something still failed silently.
• Gate the next pilot wave on one named fix (ESP tracking, a single required app, or a real join miss)—not "reset profile + wipe."

What "good" looks like: the five-move baseline

If you do nothing else this quarter, these five moves dismantle the 0x800705b4 patterns above in order of impact:

1. Record the phase on screen — Securing your hardware vs Device Preparation / ESP Apps vs Account setup—before any wipe or timeout change.
2. Run tpmtool getdeviceinformation and keep it with the failed enrollment when attestation is in play.
3. Collect mdmdiagnosticstool.exe -area Autopilot;TPM (and ESP / Autopilot logs) so self-deploying, pre-provision, and hybrid failures share one evidence pack.
4. Match the mode before you change config — TPM / VM attestation, ESP policy-provider / required apps, or hybrid hang with successful join—then change one thing.
5. Re-test on a clean unit after that one change — not wipe + timeout bump + profile reshuffle in the same lab cycle.

None of this needs a new Autopilot SKU. It needs the discipline to treat 0x800705B4 as a timeout clock, not a root cause, and to stop burning hardware on an unnamed phase.