The old process took forty minutes of someone's attention per machine. Unbox, image, join the domain, install the agent stack, name it, log in once to confirm, ship it. Multiply that by a hiring plan and you have a full-time job nobody wanted.
Zero-touch means the box goes from the vendor to the user and the only human step is opening it. Everything else — enrollment, policy, apps, security baseline — happens between first boot and first login.
What actually has to be true
Three things, and they are less about tooling than about discipline.
- Hardware identity is registered before the box ships. The vendor uploads the hardware hash at order time. If you are collecting hashes yourself after delivery, you do not have zero-touch, you have deferred touch.
- Policy is deterministic. Every device in a given group resolves to exactly the same end state, every time, with no ordering surprises.
- Failure is loud. A device that silently half-provisions is worse than one that fails outright, because it reaches the user looking fine.
The enrollment path
The device boots, hits the network, and identifies itself against the registration record. From there the profile drives everything: the join type, the naming convention, the account setup, and whether the user sees a status page while it works.
We show the status page. It costs nothing and it converts "my laptop is broken" tickets into "my laptop is still setting up" patience.
Device boot
-> Network
-> Autopilot profile match
-> Entra join
-> Enrollment Status Page (blocking)
-> Security baseline
-> Certificates + Wi-Fi
-> Required app set
-> User desktopThe blocking step matters. If you let the user onto the desktop before the required set lands, they will start working, and the first policy-driven restart will interrupt them.
Sequencing the app set
This is where most of the pain lives. Apps have dependencies, some need reboots, and a few will fight each other if they install in parallel.
We split the catalog into two tiers. Required is the smallest set a person cannot start their day without: the browser, the identity agent, the VPN, the endpoint agent. Everything else is available — published to the portal, installed on demand.
The instinct is to preload everything. Resist it. Every app in the required tier is another thing that can fail during provisioning, and a failure there blocks the whole device.
Cutting the required tier from nineteen apps to six took our average provisioning time from just over an hour to nineteen minutes, and dropped the failure rate more than the time saving alone would suggest.
Naming and the small stuff
Device naming looks trivial and turns into an archaeology problem two years later. We settled on a prefix for the fleet, a location code, and the serial. It sorts correctly, it is greppable, and it survives a reimage because the serial is the anchor.
Certificates and Wi-Fi profiles deploy before the app set. A device that finishes provisioning and then cannot reach the corporate network is a device that comes back to you.
What broke
Honest list.
- Vendor hash uploads lagged. Two orders shipped before the records landed, and those machines fell through to the standard out-of-box path. Now we verify registration before the order is marked fulfilled.
- A driver update inside the blocking phase forced a restart mid-enrollment. Moved it to the available tier.
- Regional Wi-Fi profiles were scoped too broadly, so devices pulled a config for a site they would never see. Scoping is now driven by the same location code as the device name.
Where it stands
New hires get a machine that arrives sealed and is ready before their first standup. Reimaging a broken device is a wipe command, not a bench appointment. The provisioning runbook is four sentences long, and three of them are about what to do when it fails.
The work that used to be forty minutes of someone's afternoon is now a record in a portal and a status page the user watches for nineteen minutes. That is the whole win.