A device shipped straight from the supplier to a home in Kochi, ready on first sign-in, with nobody in IT having touched it. That is what Autopilot is for.
Windows Autopilot lets a device configure itself out of the box: it enrols into Intune, applies your policies, installs your applications and lands in a compliant state before the user reaches the desktop. Since January 2026 it can apply Windows quality updates during that first setup, and the application limit during setup rose from ten to twenty five. For a device refresh of any size, and for any organisation with remote staff or distributed sites, it is the difference between a rollout that takes weeks and one that consumes an engineer for a year.
- Zero touchNo engineer at the desk
- 25 appsDuring setup, up from 10
- Updates in OOBESince January 2026
- Ship directSupplier to user, anywhere
Eight things that decide whether Autopilot works on the first device or the fiftieth.
Device registration, and who does it
Every Autopilot device is registered against your tenant by its hardware hash before it boots. The clean path is registration by the supplier or OEM at purchase, so devices arrive already known to your tenant. The fallback is capturing the hash from an existing device and uploading it, which works and does not scale. Getting the supplier to register at purchase is a procurement conversation worth having before the order, not after.
Deployment profiles that match how you work
The profile decides the experience: user-driven or self-deploying, Entra joined or hybrid, which setup screens the user sees, whether they get local administrator rights, and the device naming convention. Most organisations need two or three profiles rather than one, because a knowledge worker laptop, a shared shop-floor device and a kiosk have different answers to every one of those questions.
Intune configuration that is ready to receive
Autopilot hands the device to Intune, and Intune has to have the policies, compliance rules, security baseline and application assignments ready. A device that enrols into a tenant with half-built configuration lands in a half-built state. The Intune work is the majority of an Autopilot engagement, and it is what makes the resulting device actually usable rather than merely enrolled.
Application packaging, and the twenty five that matter
Applications installed during setup have to be packaged for Intune, tested, and assigned correctly, and since January 2026 up to twenty five can be installed during the out-of-box experience. Choosing which twenty five is a real decision: what the user needs on first sign-in against what can arrive afterwards. Line-of-business applications with awkward installers are where packaging effort concentrates.
Network, and the places devices will actually boot
Autopilot needs internet access during setup, which is straightforward in an office and needs thinking about for a device booting on a home network, a hotel, or a site with a captive portal. It also needs the tenant endpoints reachable, which a restrictive corporate proxy or firewall can block. Testing from the real locations devices will be delivered to is not optional.
Identity, and the sign-in the user will actually do
The user signs in during setup with their work account, which means the account has to exist, be licensed, and have multifactor authentication registered or a path to register it during setup. Conditional access policies that block unknown devices can block the enrolment itself if not scoped correctly. This is where a first pilot device most often stalls, and it is entirely avoidable.
Enrolment status page, and what the user waits for
The enrolment status page shows the user progress and can block access to the desktop until required applications and policies have applied. Configured well it delivers a device that is ready when the user reaches it. Configured badly it delivers a device that either times out on a slow connection or lets the user through before the security policies have landed. The timeout and blocking settings need choosing for your real network conditions.
Reset and reuse, which is the second half of the value
Autopilot is not only for new devices. An existing device can be reset and re-provisioned through Autopilot for a new user, which turns a leaver device into a joiner device in under an hour with no engineer involved. For organisations with turnover, this is frequently worth more than the initial rollout, and it depends on the same profiles and configuration being right.
Eight failures we see in Autopilot rollouts, and how each is prevented.
The device is not registered
It boots into a standard consumer setup because the hardware hash was never uploaded, or was uploaded to the wrong tenant. Common when suppliers say they registered devices and did not.
- Verify registration in the tenant before shipping, not after
- Agree the registration process with the supplier in the order
- Keep a fallback procedure for capturing the hash from a device
Sign-in fails during setup
The account is unlicensed, multifactor is required but not registered, or a conditional access policy blocks the enrolment. The user sees an error they cannot act on.
- Provision and license accounts before devices ship
- Scope conditional access to allow enrolment explicitly
- Test with a real user account, not an admin account
The network blocks something
A proxy, a firewall or a captive portal prevents the device reaching the tenant endpoints. Works in the office, fails at the home address the device was shipped to.
- Test from the locations devices will actually boot in
- Publish the required endpoints to whoever manages the network
- Have a guidance note for home networks and hotel wifi
The enrolment status page times out
Applications take longer to install than the timeout allows, usually on a slow connection, and the user is left with an error or an incomplete device.
- Measure real install time on the slowest realistic connection
- Set the timeout from that measurement, not from the default
- Keep the blocking application set small and move the rest to post-setup
An application fails to install
A packaging error, a dependency that was not assigned, or an installer that needs a reboot the setup process does not provide. Blocks the enrolment status page if the application was marked required.
- Test every packaged application through a full Autopilot run
- Only mark as required during setup what is genuinely needed on first sign-in
- Line-of-business installers need the most attention
The device lands non-compliant
Enrolled successfully, but a compliance policy or security baseline has not applied yet, so conditional access blocks the user from the applications they need.
- Sequence compliance policies to apply before the user reaches the desktop
- Test the full path from setup to opening Outlook
- Give the user a note about what to expect in the first hour
Wrong profile assigned
A shared shop-floor device gets the knowledge worker profile, or a laptop gets the kiosk profile. Dynamic group membership based on device attributes is usually the cause.
- Use group tags at registration to drive profile assignment
- Verify the assigned profile in the tenant before shipping
- Keep profiles few and their differences documented
Devices arrive before the tenant is ready
Procurement moves faster than configuration, hardware is in boxes, and the pressure to ship overrides the pilot. This is how a fifty device failure happens.
- Do not ship a device to a user until a pilot has passed end to end
- Pilot on a device from the actual order, not a lab machine
- Procurement and configuration timelines need agreeing together
We configure Intune for a living, and Autopilot is mostly Intune.
Microsoft Partner, building this in client tenants regularly
Profiles, compliance, baselines, application packaging and the enrolment status page are configuration we do for clients continuously. The parts that stall a first Autopilot rollout, conditional access scoping, application packaging, timeout tuning, are the parts we have already been through.
We pilot properly before anything ships
A full run on a device from the actual order, in a location a real user would boot it, signed in as a real user, judged on whether a work application opens. It is slower than shipping and it is the difference between a rollout and a rescue.
We sort out supplier registration as part of the engagement
Getting the supplier to register devices at purchase is the difference between zero touch and one touch per device. We know what to ask for in the order and how to verify it in the tenant before the boxes ship.
We build it as part of the refresh, not as a separate project
Autopilot on its own is a capability. Autopilot inside a device refresh with a procurement schedule is what makes the refresh finish. We design the profiles for the devices actually being bought and the users actually receiving them.
Who benefits most from Autopilot.
Distributed and remote workforces
Staff across cities with no local IT. A device ships from the supplier to the home address and is ready on first sign-in, which is the only sensible way to provision for a workforce nobody can hand a laptop to.
Device refresh programmes
A Windows 11 refresh of any size. Without Autopilot, every new device needs an engineer and the rollout takes a year; with it, the rollout is paced by delivery.
Retail and multi-site
Many small sites, point-of-sale and back-office devices, no IT on site. Self-deploying profiles for fixed-purpose devices and user-driven for the office, shipped direct.
Organisations with turnover
Reset and re-provision turns a leaver device into a joiner device in under an hour without an engineer. For anyone onboarding regularly, this is often worth more than the initial rollout.
Shop floor and kiosks
Self-deploying mode for shared and fixed-purpose devices that need no user sign-in during setup and a locked-down configuration afterwards.
Education
Large device counts, seasonal onboarding and thin IT teams. Bulk provisioning through Autopilot with profiles per device role is the only way the numbers work.
The choices in a deployment profile, and which answer fits which device.
| Decision | Knowledge worker laptop | Shared or fixed-purpose device | |
|---|---|---|---|
| Deployment mode | User-driven. The user signs in during setup and the device is theirs. | Self-deploying. No user sign-in during setup, device configures itself for shared or kiosk use. | |
| Join type | Entra joined, unless a specific on-premises dependency forces hybrid. | Entra joined. Hybrid join adds complexity that fixed-purpose devices rarely justify. | |
| Local administrator | Standard user. Elevation through a managed mechanism when needed, not standing rights. | Standard user, and usually a restricted shell or kiosk configuration on top. | |
| Setup screens shown | Minimal. Skip the consumer prompts, show only what the user must complete. | None. Self-deploying mode shows no interactive screens at all. | |
| Device naming | A template with a prefix and serial or random suffix, so support can identify it. | A template that encodes location or purpose, so a support ticket says where it is. | |
| Applications during setup | The productivity core the user needs on first sign-in, up to twenty five, the rest afterwards. | The single-purpose application set, and nothing else, so setup is fast and predictable. |
Imaging and hands-on setup against Autopilot.
| Feature | Dimension | Imaging and hands-on | Autopilot |
|---|---|---|---|
Engineer time per device | Hours, including collection and handover | None, once configured | |
Where setup happens | An IT room, then delivery to the user | Wherever the box is opened | |
Remote and distributed staff | Ship to IT, configure, ship again | Ship direct from supplier to user | |
Image maintenance | A golden image to rebuild every cycle | No image, policies and applications applied live | |
Consistency | Depends on who did it and when | Every device gets the same configuration | |
Leaver to joiner | Collect, wipe, reimage, redeliver | Reset and re-provision, no engineer | |
Rollout of fifty devices | Weeks of engineer time | Days, paced by delivery | |
Where it fails | Quietly, in inconsistency | Visibly, in front of a user, if the pilot was skipped |
Pilot on a device from the actual order, in a place a real user would boot it.
Autopilot works reliably once it is configured correctly, and the way to find out whether it is configured correctly is a full run on a real device from the real supplier in a real location, followed by opening a real application. Lab tests on an engineer laptop in the office pass and prove nothing about a home network in Kochi with a different model from the same order. The fifty device failures we are asked to rescue almost always trace back to a pilot that was skipped under procurement pressure or run on the wrong device in the wrong place.
- The pilot device comes from the order, not from a cupboard
- Boot it somewhere a user would, including a home connection
- Sign in as a real user, not an administrator
- Success is opening Outlook, not reaching the desktop
Five stages, and the pilot is the one that cannot be skipped.
- 1
Design the profiles for the devices you are actually buying
Device types, user types, join model, naming, local administrator position, and which applications must be present on first sign-in. Usually two or three profiles. Agreed with the people who will support the devices, not only the people ordering them.
- 2
Build the Intune configuration to receive them
Compliance policies, the security baseline, configuration profiles, application packaging and assignment, and the enrolment status page tuned for your real network conditions. Conditional access scoped so enrolment is allowed. This is the majority of the work.
- 3
Sort out registration with the supplier
Agree hardware hash registration at purchase in the order, with group tags that drive profile assignment. Verify registration in the tenant before anything ships. Establish the fallback for capturing a hash from an existing device.
- 4
Pilot end to end on a real device
A device from the actual order, booted in a location a real user would boot it, signed in as a real user, through setup to opening a work application. Repeated per profile and per device model. Timeout and blocking settings adjusted from what the pilot measured.
- 5
Roll out, paced by delivery, and hand over reset-and-reuse
Devices shipped direct with a one-page note for the user, support capacity for the first days, and the reset-and-reuse procedure handed to your team so leaver devices become joiner devices without anyone calling us.
Twelve things that must be true before a device goes to a user.
Registration and identity
- Device hashes registered and visible in the tenantVerified, not assumed from the supplier
- Group tags applied so the right profile assignsWrong profile is a common silent failure
- User accounts provisioned and licensedBefore the device, not on the day
- Conditional access scoped to allow enrolmentTest with a real user account
Configuration
- Deployment profiles built and assignedTwo or three, documented, not one
- Compliance policies and security baseline readyThe device should land compliant
- Required applications packaged and tested through a full runEvery one, not a sample
- Enrolment status page timeout set from real measurementsOn the slowest realistic connection
The pilot
- Full run completed on a device from the actual orderNot a lab machine
- Tested from the locations devices will boot inHome networks, sites, not only the office
- Path tested from setup to opening a work applicationEnrolled is not the same as usable
- A one-page note for the user about what to expectHalves the support calls
Windows Autopilot, answered plainly.
What sits either side of this.
Windows 11 migration
The programme Autopilot provisions for: fleet sorting, the refresh, the security posture and evidenced disposal.
Learn moreDevice refresh planning
The procurement side: standardisation, phasing, and getting the supplier to register devices at purchase.
Learn moreMicrosoft Intune
The platform Autopilot hands devices to, and where most of the configuration work in an Autopilot engagement actually lives.
Learn moreOfficial documentation
- Windows Autopilot documentation, Microsoft Learn
- Microsoft Intune documentation, Microsoft Learn
Get the profiles right before the boxes arrive.
Procurement moves faster than configuration, and the pressure to ship is how a fifty device failure happens. Tell us what you are buying and who is receiving it, and we will design the profiles and the pilot around the actual order. Remote-first from Hyderabad, serving all of India.
Related Services
Explore more solutions that work great with this service
Windows 11 Migration
Sort the fleet, bridge the exceptions, provision without hands
Learn moreMicrosoft Intune
Device management and endpoint security
Learn moreDevice Refresh Planning
Standardise, phase, register at purchase, dispose with a certificate
Learn moreSCCM to Intune Migration
Co-management to cloud-native device management
Learn more