Autopilot Error 0x80280009: TPM Attestation. What is going on?

In this blog, we’ll explore why 0x80280009 (aka TPM_E_FAIL) is becoming a more common headache, particularly in virtual machines. We’ll look at what’s really going on inside the TPM when this error hits, why your Hyper-V VMs aren’t playing nice with Autopilot for pre-provisioned deployments, and, just maybe, how a new feature on the horizon, VTpmAttestation, might change the attestation game.

Introduction

When it comes to TPM attestation failures during Windows Autopilot, you’re probably familiar with the classic 0x800705b4 error, yep, the notorious timeout.

You’ve likely seen it pop up after retrying TPM attestation again and again, only to watch it fail as the clock runs out. But, besides the famous time-out error, another player also makes an appearance: error 0x80280009.

This one’s a little different. Instead of a timeout, 0x80280009 translates to TPM_E_FAIL, which means something is going wrong inside the TPM itself.

So, what’s the deal with this error? And why is it showing up more frequently, especially in virtual environments like Hyper-V? Let’s dive into this lovely error and why it’s driving you nuts.

What Does Error 0x80280009 Even Mean?

Good question. Error 0x80280009, better known as TPM_E_FAIL, is a sign that the device’s TPM attestation has failed. TPM attestation is crucial for establishing trust during Autopilot enrollment, basically proving that your device is trustworthy enough to go through the whole process.

When this error pops up, it’s usually because of a couple of common culprits:

• Missing Endorsement Key (EK) Certificate: If the TPM doesn’t have a valid EK cert, attestation isn’t going anywhere. I’ve covered this whole EK certificate mess in more detail here, so if you’re not familiar with it, check that out.
• TPM Version Confusion: If your device is stuck with TPM 1.2 (I know, why even?), it might not support the level of attestation required. TPM 2.0 is the bare minimum if you want things to work smoothly—more on that in my previous post here.
• Network Glitches: TPM attestation needs to call home to Microsoft’s servers. If your network setup is blocking this communication, guess what? Attestation fails.
• Unready TPM: If your TPM is in a not-ready state (because someone forgot to initialize it properly), you’re in for a rough ride.

All of that can lead to this error, which means the device is not ready for attestation.

But when it comes to virtual machines, well… let’s just say you’re fighting a whole different battle.

Hyper-V and Autopilot White-Glove: Why Your VMs Aren’t Playing Nice

So, you’ve fired up a Hyper-V virtual machine to test Autopilot, and now you’re staring down errors 0x800705b4 and 0x80280009. Here’s the deal:

Autopilot expects your device to have a physical TPM for attestation. Hyper-V can give you a virtual TPM (vTPM), but here’s the kicker, it doesn’t come with the Endorsement Key (EK) certificate that Autopilot requires to prove the device’s identity.

Without that EK certificate, your vTPM is as useful as a chocolate teapot. In other words, attestation is going to fail every time. And that’s why Hyper-V just doesn’t cut it when it comes to Autopilot for pre-provisioned deployments.

Again… as small summary of what’s happening:

1. No Physical TPM: Virtual TPMs lack the security hardware that physical devices have.
2. Missing EK Certificate: Virtual TPMs don’t get an EK certificate issued by a manufacturer, which means Autopilot refuses to trust them. I’ve written about this exact issue with TPM attestation failures here, and trust me, it’s a headache.
3. Attestation Rejected: Even if your virtual TPM is configured perfectly, Autopilot will reject it because it doesn’t meet the security standards.

So, yeah. If you hope to use Autopilot on a Hyper-V VM, I hate to break it to you, but you’re out of luck. For now, there are no workarounds, no magical registry tweaks, and no hidden Intune policies to make it all work.

But Wait… What’s This About VTpmAttestation? (Feature ID: 31368561)

Now, before you throw in the towel, there’s a feature on the horizon called VTpmAttestation (Feature ID: 31368561). Sounds like Virtual TPM Attestation to me?

Sounds promising, right? Maybe it’s the light at the end of this gloomy Autopilot tunnel?

Not so fast.

If you’re hoping that this feature will finally bring real TPM attestation to virtual machines in Hyper-V, I’ve got some doubts. I mean, are we really expecting vTPMs to suddenly start performing full-on hardware-backed attestation? My guess: probably not.

Here’s the more likely scenario! This feature will end up ignoring attestation checks for virtual TPMs rather than performing the full attestation process during Autopilot for pre-provisioned deployments. It could be designed for something beyond scenarios where attestation isn’t as critical but still relies on TPM validation. It’s possible we’ll see VTpmAttestation help in environments where some degree of trust is needed, but don’t expect it to suddenly make Hyper-V VMs fit for secure Autopilot deployments.

But then again, I could be totally wrong but one thing is for sure, keep an eye out for my next blog post about vTpmAttestation! All the lovely details about what this VTpmattestation feature is all about will be in that blog, and even a small teaser of what else is coming!

Conclusion

So, while this feature sounds like a step in the right direction, I wouldn’t bet on it solving our Autopilot woes anytime soon. Stay tuned for more details as it unfolds, but until then, if you need Autopilot with TPM attestation, stick to physical hardware.

Keep an eye on VTpmAttestation, though. It might help in other areas, but when it comes to Hyper-V and Autopilot? Don’t hold your breath just yet.