A device sits on "Securing your hardware" for a minute, then fails with 0x800705B4. That code is a generic timeout, which is unhelpful, because the actual problem is almost never a slow network. Self-deploying and pre-provisioning modes do something the user-driven mode does not: they authenticate the device itself into your tenant, with no user credentials involved at all. The only identity the device has for that is its TPM - and if the TPM cannot prove who it is, provisioning has nothing to work with.
"Securing your hardware" is TPM device attestation. Self-deploying and pre-provisioning modes require TPM 2.0 and a valid Endorsement Key (EK) certificate burned in by the TPM manufacturer, plus outbound HTTPS to a set of attestation URLs that differ per TPM vendor. Microsoft explicitly does not support these modes on virtual machines, including Hyper-V virtual TPMs - those fail with 0x800705B4 by design, not by misconfiguration. Check the TPM spec version and the EK certificate before blaming the network, and remember the failure is a timeout so it looks identical whether the cause is a missing EK cert or a blocked vendor URL.
The problem: a timeout that explains nothing
The visible symptom is always the same and always at the same place: the Enrollment Status Page shows "Securing your hardware", waits, and fails. 0x800705B4 translates to a timeout - it tells you something did not answer in time, not what.
What makes this genuinely confusing is that several very different root causes all produce that identical timeout:
- The device has no TPM 2.0 at all (or only TPM 1.2).
- The TPM is present but has no valid EK certificate - logs show a
NoValidEkCertstyle failure. - It is a virtual machine. Microsoft does not support these modes on VMs, including Hyper-V virtual TPMs.
- The TPM is fine, but outbound HTTPS to the TPM vendor's attestation URLs is blocked by a proxy or firewall.
Only the last one is a network problem, and it is the one most teams start with.
Why it happens: the device is the credential
In user-driven Autopilot, a human signs in, and their credentials authorise the Entra join. In self-deploying and pre-provisioning modes there is no human at that point in the flow - the device must authenticate on its own. TPM 2.0 attestation is the mechanism that makes that possible.
That means the requirements are hardware requirements, not policy ones, and they cannot be configured around:
- TPM 2.0. Not 1.2. The attestation protocol depends on TPM 2.0 primitives.
- A valid EK certificate. Provisioned at manufacture. If it is missing or damaged, there is nothing to validate.
- Support for TPM device attestation as a capability - Microsoft notes all new Windows devices should meet this, but "should" is doing real work in that sentence for older or unusual hardware.
- Reachable, vendor-specific attestation URLs. These are not one shared endpoint - the set differs per TPM provider, which is why a proxy allowlist built for one hardware model can silently break a different one.
How to verify: check the four prerequisites
Start with the TPM itself. Present and ready is not sufficient - you need the spec version:
Then the EK certificate, which is the part people rarely check and is frequently the actual cause:
ManufacturerCertificates.Count is 0, stop troubleshooting the network. No amount of firewall work will help a device that has nothing to attest with. That is a hardware or firmware problem - check for a TPM firmware update from the OEM, and confirm the TPM has not been cleared in a way that discarded its certificates.The fix: work through the prerequisites in order
Context: the order matters, because each step rules out a whole class of cause. Do not start with the firewall.
- Confirm it is not a VM. If it is, stop - use user-driven mode instead. Self-deploying and pre-provisioning are not supported on virtual machines, and Hyper-V's virtual TPM does not change that. This is documented behaviour, not a bug to work around.
- Confirm TPM 2.0. If the device reports 1.2, it cannot use these modes. Some hardware can be switched from 1.2 to 2.0 in firmware - check with the OEM, and expect that switch to clear the TPM.
- Confirm the EK certificate exists. If not, apply the OEM's TPM firmware update. Raise it with the vendor if the certificate is genuinely absent on new hardware, because that is a manufacturing issue.
- Only then look at the network. Allow outbound HTTPS to the TPM attestation URLs for every TPM vendor in your fleet, not just the one you piloted with. Microsoft publishes the set in the Autopilot networking requirements.
- Re-test with a real provisioning run. A device that passes the local checks has not yet proven it can complete attestation end to end - only an actual deployment does that.
Two more limitations worth knowing before you choose self-deploying
Neither is an attestation issue, but both surprise people who pick this mode:
- Self-deploying is Entra join only. It is not supported for Entra hybrid join. If your requirement is on-premises domain membership, this mode is not the answer.
- No primary user is set. Intune does not assign a primary user in self-deploying mode. That breaks user self-service BitLocker recovery key retrieval and Company Portal installation of user-assigned apps. You can set a primary user manually afterwards, but plan for it rather than discovering it.
Registry and TPM reference
The attestation result and its timeout are recorded on the device:
| Value / source | What it holds | Why it matters |
|---|---|---|
DevicePreparationCategory.Status › TpmAttestationSubcategory | The recorded attestation state and its on-screen text | The device's own record of whether "Securing your hardware" passed - readable long after the fact |
TpmAikTaskMaxTimeoutMilliseconds (REG_DWORD) | Attestation task timeout in milliseconds | Explains how long the device waits before producing the 0x800705B4 timeout |
TpmNgcWaitDelayMilliseconds (REG_DWORD) | Wait delay for TPM-backed credential operations | Context for timing-sensitive provisioning issues on slow TPMs |
Get-Tpm › TpmPresent/TpmReady | Live TPM state | The first thing to rule out - a not-ready TPM cannot attest |
Win32_Tpm › SpecVersion | TPM specification version | Must be 2.0; 1.2 disqualifies the device from these modes entirely |
Get-TpmEndorsementKeyInfo › ManufacturerCertificates | The EK certificate chain from the TPM vendor | Count of 0 means attestation has no identity to present - a hardware issue, not a network one |
Proof it worked: a real device that passes
A genuine run of Test-AutopilotTpmAttestationReadiness.ps1 from this series against a real Autopilot-provisioned device. The hardware model identifier is redacted; every TPM value is exactly as captured:
This is what all four prerequisites satisfied looks like. The TPM is an STMicroelectronics part reporting spec version 2.0. Crucially, Manufacturer certs: 1 confirms a real EK certificate is present - the single most commonly overlooked requirement. And the device's own historical record shows Securing your hardware (Completed), so attestation genuinely succeeded during its provisioning run rather than merely looking capable now.
The 60000 ms attestation timeout is worth noting too. That is the budget before you see 0x800705B4 - so a device that fails attestation typically sits on that screen for roughly a minute. If yours fails much faster than that, suspect a prerequisite that failed outright (no TPM 2.0, no EK cert) rather than a network timeout.
References
- Microsoft Learn - Windows Autopilot self-deploying mode - the TPM 2.0 requirement, the
0x800705B4VM limitation, and the primary-user caveat - Microsoft Learn - Windows Autopilot requirements (networking) - the per-TPM-vendor attestation URLs
- Microsoft Learn - Windows Autopilot known issues
Microsoft MVP community deep-dives
Verified and genuinely on-topic - the URL was fetched and confirmed before being cited here, not copied on trust:
| Author | Post | What it adds |
|---|---|---|
| Rudy Ooms (MVP, call4cloud.nl) | Step by Step: How Windows Retrieves the Autopilot Profile | Traces the full token-and-profile retrieval flow and independently documents the AutopilotPolicyCache registry key and wmansvc on-disk cache that these posts read from |
Script for this post is in Windows-Autopilot-Scripts.