Zero-touch provisioning: what it actually removes

The pitch is that a device ships from the vendor directly to the user, who signs in and is productive twenty minutes later without IT touching the hardware. That is genuinely achievable, and it is a real improvement over a build room.

What it does not do is remove work. It relocates it: from repeated per-device effort to a substantial one-off investment in configuration design, application packaging and testing. Teams that skip that investment end up doing both.

Modern management handles the operating system and the settings well. Line-of-business applications are the hard part, particularly older ones with installers that assume an administrator sitting in front of the machine.

Budget the majority of the project effort here. Packaging, testing and ring-based deployment for a hundred-application catalogue is months of work, and it is the thing that determines whether users experience zero-touch or zero-applications.

Zero-touch assumes a device can reach the internet before it is joined to anything. Certificate-based Wi-Fi that requires a domain-joined machine creates a chicken-and-egg problem that only appears when the first remote user tries to enrol from home.

Design the enrolment network path explicitly, and test it from a genuinely cold device on a domestic connection rather than from a bench in the office.

Track time from device dispatch to first productive session, per user, and watch the tail rather than the median. A median of twenty minutes with a 95th percentile of two days means a meaningful minority of new starters are having a poor first day.

That tail is almost always application availability or network path, and both are fixable once you are measuring the right thing.