For years the standard was a golden image: build one machine perfectly, capture it, and reimage every new laptop from that file. It worked until the image was six months old, the driver pack was wrong for the new model, and the technician spent an afternoon per device anyway.
Zero-touch provisioning flips the model. The laptop ships with the manufacturer's clean Windows, the user signs in, and policy does the rest. This post explains how that works with Windows Autopilot and Intune, and what you need in place first.
What 'standard device' means now
A standard device is no longer a file on a share. It is a set of policies: which apps install, which settings apply, how BitLocker is enforced, which accounts get local admin, what the hostname pattern is. The OS itself comes from the vendor and gets updated by Windows Update, so it is never stale.
Define your standard as a document before you touch Intune. One page per device role: Office worker, Engineer, Shared kiosk, Executive. For each role, list the required apps, the optional apps the user can pick from the Company Portal, and the security baseline.
- Required apps: Microsoft 365 Apps, browser, VPN client, endpoint protection, RMM agent
- Security: BitLocker with key escrow to Entra ID, Windows Hello for Business, firewall on
- Identity: Entra joined, user is standard, IT group has local admin via LAPS or a policy
- Naming: a prefix per client or site plus serial number, for example CLI-%SERIAL%
- Support: helpdesk shortcut, support contact in Settings, RMM remote control enabled
Autopilot in practice
Autopilot needs the device's hardware hash registered in the tenant before the user powers it on. Vendors and resellers can register devices at purchase, which is the true zero-touch path. For devices you already own, collect the hash with a PowerShell script and upload the CSV in the Intune admin center under Devices, Enrollment, Windows Autopilot devices.
Assign a deployment profile that sets the join type (Entra joined, or hybrid if you still have on-premises AD), skips the privacy and EULA screens, names the device, and makes the user a standard user. Then an Enrollment Status Page holds the device until the required apps and policies land, so the user does not start working on a half-built machine.
- Collect the hardware hash on an existing device and upload it to Intune
- Create a deployment profile: User-driven, Entra joined, naming template set, user account type Standard
- Assign the profile to a dynamic group based on a group tag (for example ZTDId or a custom tag per client)
- Configure the Enrollment Status Page to block until required apps install
- Reset a test device and walk the out-of-box experience yourself, timing it
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile C:\\Temp\\hash.csvApps and configuration that follow the user
Package apps as Win32 (.intunewin) rather than relying on the Microsoft Store where you need control over version and install order. Set install order with dependencies: endpoint protection and the RMM agent first, then the big suites, then everything else. Mark the required apps as required for the device group, and let the optional ones appear in Company Portal.
Settings come from configuration profiles and the Settings Catalog. Start with the Microsoft security baseline for Windows and Edge, then adjust. BitLocker policy, Defender policy, and Windows Update rings are separate objects; assign all of them to the same device group so a new laptop gets the full set on first boot.
Where a real image still makes sense
Some devices still need a traditional image: lab machines with heavy scientific software, shop-floor PCs that never see the internet, or environments where the vendor's preinstalled Windows is cluttered enough that you prefer a clean build. In those cases keep the image thin, apply Autopilot on top of it, and rebuild it on a schedule rather than patching the file.
Macs follow the same idea with Apple Business Manager and an MDM: the device is assigned to the MDM at purchase, and enrollment happens during Setup Assistant. The policies differ, the workflow does not.
- Keep a thin image only where the vendor OS is unusable or the device is offline
- Use Autopilot for the identity join and app delivery even on imaged devices
- Rebuild the image on a schedule, with a changelog
- Store the image and its build steps in the same documentation as the policies
Frequently asked questions
Does Autopilot work with on-premises Active Directory?
Yes, through hybrid Entra join, but it needs the Intune Connector for Active Directory and line of sight to a domain controller during setup. If you are not tied to on-premises AD, plain Entra join is simpler and more reliable.
How long does a zero-touch setup take for the user?
It depends on the app payload and the connection. Measure it on a test device with the full set of required apps and tell users to expect roughly that long, plugged in and on a good network.
What if a user needs local admin?
Use Windows LAPS for a per-device rotating admin password held in Entra ID, and hand it out through the helpdesk when justified. Standing local admin for users defeats most of the security baseline.
Takeaway
The standard device is now a set of policies, not a file. Register hardware with Autopilot, define a deployment profile and an enrollment page, package apps with install order, and assign everything to one device group. A new laptop then builds itself, and the technician's afternoon is free.