Microsoft will begin installing the latest Windows quality updates during the out-of-box experience (OOBE) for managed Windows 11 enterprise and education devices starting in September 2025. The change aims to ensure every device is patched and hardened before a user ever reaches the desktop, but IT teams will need to navigate longer provisioning times, potential authentication token expirations, and new dependencies between update policies and Autopilot profiles.

What's changing in the OOBE update process

The new capability automatically checks Windows Update on the final page of the OOBE. If an applicable monthly cumulative update is available, it downloads and installs the patch—along with any necessary reboots—before the first sign-in. Feature updates and driver packages are explicitly excluded. Users see a progress page during the download and installation, and Microsoft estimates the extra time at roughly 20 minutes, though real-world duration depends on network speed and hardware performance. This behavior supplements, but does not replace, the existing Zero Day Package (ZDP) mechanism that delivers critical out-of-band fixes.

The feature targets Windows 11 devices running version 22H2 or later on Pro, Enterprise, Education, and SE editions. Only Microsoft Entra-joined (Azure AD) or hybrid-joined devices managed through Intune or a compatible MDM that integrates with Autopilot and the Enrollment Status Page (ESP) are affected. Unmanaged consumer PCs and devices not enrolled in such management are not impacted.

Administrator controls and critical defaults

IT admins manage the behavior via the Intune admin center under Devices > Enrollment > Enrollment Status Page, where a new setting—"Install Windows quality updates (might restart the device)"—can be set to Yes or No. The defaults, however, demand immediate attention:

  • New ESP profiles created after the change default to Yes (enabled).
  • Existing ESP profiles keep their current value, which is typically No until manually edited.
  • The Intune default ESP profile, which applies when no other profile is assigned, may behave similarly; admins must verify its state.
  • Devices that lack an ESP profile entirely—for example, those using Autopilot device preparation policies—will have the OOBE update installed by default, and it cannot be disabled. This is a critical caveat for organizations that rely on custom imaging or third-party provisioning.

Additionally, the update behavior respects Windows Update for Business policies (deferrals, pause windows) only when those Update Rings are assigned to the same device group as the ESP profile. Inconsistent group assignments can lead to unexpected update behavior, making tight group alignment a new operational dependency.

Why Microsoft is pushing patches during provisioning

Microsoft frames the change as a direct response to enterprise feedback: administrators want devices secure and consistent before users start working. The primary benefits are:

  • Immediate security hardening: Devices arrive at the desktop with the latest cumulative updates, reducing exposure to known vulnerabilities from the first moment.
  • Fewer post-deployment support tickets: Common helpdesk calls about unexpected restarts, update prompts, or compatibility issues drop significantly when devices are fully patched before handoff.
  • Compliance alignment: Regulated industries benefit from a consistent, auditable baseline that matches organizational update policies without lag.
  • Integration with Windows Update for Business: When rings are properly aligned, the OOBE update pull respects approved deferral windows, keeping newly provisioned devices on the same patch version as the rest of the fleet.

For large-scale deployments, these gains translate into streamlined provisioning, fewer security gaps, and reduced variance across device fleets.

The operational trade-offs IT must plan for

The benefits are real, but the shift introduces several risks that demand deliberate mitigation:

1. Longer provisioning timelines

An extra 20 minutes per device may seem minor, but when multiplied across hundreds or thousands of units, the cumulative delay can disrupt rollout schedules. In environments like school deployments or retail kiosk setups, where dozens of devices are often configured simultaneously on limited bandwidth, the added network load can balloon setup times beyond 30 minutes.

2. Temporary Access Pass (TAP) expiry

Autopilot enrollments often use TAPs with set lifetimes. The extended OOBE process can cause those passes to expire before the user completes sign-in, effectively stranding the provisioning flow. Microsoft recommends extending TAP validity or adjusting enrollment workflows to account for the longer sequence.

3. Update failures during automated provisioning

If a monthly quality update contains a hardware-specific regression, a whole batch of devices could hit the same failure during OOBE. Without manual intervention, this could stall large deployments. Traditional staged rollout rings become even more critical, and IT must have a rollback or reimaging playbook ready.

4. Policy synchronization complexity

The requirement to assign Update Rings and ESP profiles to the same device group adds a layer of operational hygiene. Misalignment can lead to OOBE pulling unapproved updates or bypassing pause policies, potentially violating change control procedures.

5. Vendor and image dependencies

Devices imaged with older Windows builds may require larger cumulative downloads, extending OOBE times further. Organizations that receive vendor-imaged hardware must ensure images include the June 2025 non-security update (or later) to minimize download size and avoid surprises.

Practical rollout checklist for IT teams

To adopt the new capability while minimizing risk, follow a staged, tested approach:

  • Pilot cohort: Create a small device group representing key hardware models and deployment paths, enable the setting in their ESP profile, and validate the full OOBE + update sequence.
  • Verify prerequisites: Confirm devices run Windows 11 22H2 or later and have the August 2025 OOBE ZDP or the June 2025 non-security update preinstalled.
  • Align update rings: Ensure Windows Update for Business policies are assigned to the same Autopilot/ESP groups to maintain deferral and pause compliance.
  • Adjust authentication: Extend TAP lifetimes or switch to alternative enrollment flows to avoid mid-OOBE expiry.
  • Test recovery: Document a plan for failed updates, including reimaging steps, network isolation options, and vendor escalation paths.
  • Communicate with stakeholders: Notify procurement, vendors, and end users of the potential extra setup time and update any handoff SLAs.
  • Monitor telemetry: Use Intune diagnostics and Windows Update logs to detect anomalies during the pilot before scaling to broader rings.

Real-world scenarios: wins and gotchas

Enterprise laptop refresh (win): A global sales team receives new laptops with the ESP setting enabled. Devices are fully patched at first sign-in, conditional access policies are satisfied immediately, and follow-up reboots and helpdesk tickets plummet.

Classroom rollout (gotcha): A school orders 200 laptops to hand out on the first day. On-site Wi‑Fi can't handle 200 simultaneous multi-gigabyte downloads, OOBE times balloon, and TAPs expire. The result: students miss lessons while IT scrambles. Staggering the rollout or using Delivery Optimization could have prevented the crisis.

Vendor-imaged desktops (surprise): A vendor ships desktops with an older base image. Because the receiving organization uses Autopilot device preparation policies without an assigned ESP profile, the OOBE updates run by default, forcing a large download and multiple restarts. The IT team hadn't coordinated image expectations with the vendor, delaying device acceptance by hours.

Policy, compliance, and security implications

Installing security updates during OOBE aligns with zero-trust principles by reducing the window of unpatched exposure from day one. For regulated industries, the change simplifies audits: devices delivered to users are immediately at the approved patch level, and the consistent baseline strengthens conditional access posture. However, the flip side is that a flawed monthly update could now impact devices during provisioning rather than post-deployment, making pilot testing non-negotiable for high-stakes environments.

Technical edge cases

  • Network constraints: Branch offices and classrooms may suffer bandwidth saturation; local caching via Delivery Optimization or WSUS can mitigate the problem.
  • Non-Intune MDMs: While the control surface is currently exposed in Intune, other MDM providers supporting Autopilot may offer equivalent toggles. Confirm vendor support before proceeding.
  • Extremely old images: Devices imaged with builds significantly older than 22H2 will face larger download payloads, making pre-staging with updated media a best practice.
  • ZDP interaction: The OOBE quality update feature works alongside ZDP but does not replace it; ZDP still fires independently for out-of-band critical fixes.

The bottom line for IT decision-makers

The September 2025 change is a logical, security-first evolution of Windows provisioning. It closes a gap that has long frustrated enterprise administrators: freshly unboxed devices sitting unpatched until after the user logs in. The technical design is sound, and the integration with Autopilot ESP gives admins a familiar control surface. But the operational impact is real. Longer provisioning, TAP expiration, and the potential for update-induced failures demand rigorous planning, not a casual toggle flip.

Organizations that treat this as a "set it and forget it" config will likely hit friction. Those that invest in pilot programs, align policies carefully, and communicate with procurement and vendors will turn the change into a powerful tool for delivering secure, compliant devices right out of the box.