Autopilot isn't your deployment strategy

Blog August 2025

What Autopilot actually does

Strip away the branding and Autopilot is a registration and hand-off mechanism. A device's hardware identity is registered to your tenant, the out-of-box experience is customised, the device joins Entra ID, enrols into Intune, and an Enrollment Status Page holds the user at the gate while policy and applications arrive. That is genuinely valuable: it replaces the imaging bench with the cloud, and it means a laptop can go from the manufacturer's box to a working desk without IT touching it.

But notice what is missing from that list. Autopilot does not package your applications, design your configuration, plan your update servicing, rationalise your app estate or validate your network. It hands the device to whatever you have built in Intune. If what you have built is incomplete, Autopilot delivers that incompleteness with perfect efficiency, to every user, on their first morning.

Where zero-touch projects actually fail

We are asked to rescue stalled Autopilot rollouts more often than we are asked to start fresh ones, and the failure points are remarkably consistent. Almost none of them are Autopilot.

Applications are not ready. The estate was never rationalised, so hundreds of applications sit unpackaged or half-migrated from ConfigMgr. Win32 and line-of-business installers are mixed in ways Microsoft explicitly warns against during ESP, dependencies are undeclared, and detection rules are wrong, so installs report failure after succeeding, or worse, the reverse.

The Enrollment Status Page is misconfigured. Teams either track every assigned application, so provisioning takes ninety minutes and trips the timeout, or track nothing, so users reach a desktop missing the VPN client and security agent they need to do anything at all. The ESP is a design decision. Most projects treat it as a checkbox.

Autopilot delivers whatever you have built in Intune, with perfect efficiency, to every user, on their first morning.

Drivers, firmware and updates are unplanned. The device arrives on whatever OS build left the factory, then immediately wants feature updates, driver updates and firmware, with no ring structure to govern when. Nobody decided how driver servicing works in the new world, because in the old world the image handled it.

Network assumptions are wrong. TLS-inspecting proxies quietly break TPM attestation for self-deploying mode. Authenticated proxies block the enrolment endpoints. A branch office with fifty devices provisioning on launch morning saturates a link nobody sized for it, because Delivery Optimization was never configured. And hybrid join, dragged along for legacy reasons when Microsoft's own guidance points firmly at Entra join, adds a domain controller dependency that defeats the point of provisioning anywhere.

What a real zero-touch strategy involves

A deployment strategy answers questions that Autopilot never asks. Which applications does the organisation actually use, and which of them earn a place in the new estate? On one engagement our discovery tooling took an inherited catalogue of around 26,000 application titles down to roughly 1,000 that mattered; packaging the other 25,000 would have been years of wasted effort. What must be present before a user may reach the desktop, and what can safely arrive afterwards? What is the identity model, the update ring structure, the driver servicing approach, the BitLocker and security baseline position, the support model for the device that fails at 9am in a home office?

Only once those answers exist does Autopilot configuration become straightforward: a deliberately small set of blocking applications on the ESP, everything else flowing post-desktop, pilot rings that measure real provisioning times on real networks before anyone commits a thousand devices, and pre-provisioning used where builds are heavy. The plumbing works beautifully when the building has been designed.

Where Autopilot genuinely shines

None of this is an argument against Autopilot. Done properly, it is transformative. Devices ship from the OEM or reseller straight to the user, and the build desk, the imaging estate and the courier loop to central IT all disappear. Every build is consistent and auditable because every build is the same cloud-delivered configuration. Reset and reprovision turns a leaver's laptop into a joiner's laptop without the device ever coming back to base. For a distributed or remote workforce, there is simply no better model.

With Windows 10 support ending this October, a great many organisations are refreshing hardware and moving to Windows 11 in the same motion, and Autopilot is the right provisioning engine for that work. Just be honest about what it is. It is the last mile. The strategy is everything you do before the box is opened.