Microsoft has quietly changed how Windows handles critical updates during the Out‑Of‑Box Experience (OOBE), introducing an “automatic installation” behavior for monthly security (quality) updates during initial setup — and then given administrators a way to block it. The move was intended to harden freshly deployed devices from the first boot, but the rollout and subsequent operational realities have prompted Microsoft to add control points, pause parts of the rollout in practice, and trigger fresh planning work for deployment teams responsible for Windows 11 and Windows Server 2025 installations.
Background / Overview
Out‑Of‑Box Experience (OOBE) is the final stage of Windows Setup where the newly installed OS configures itself, creates the first user, and applies device-level provisioning. Over the last two years Microsoft has broadened the OOBE responsibilities beyond onboarding and telemetry: the platform now can fetch and apply certain updates — including monthly quality updates — before handing the device to the end user.
The primary motivation is simple: a brand‑new device that connects to the internet during OOBE should contain recent security fixes and therefore present a smaller attack surface from day one. The operational effect, however, is more complex. Administrators, OEMs and large deployments value predictability, short provisioning windows, and strict control over exactly which updates get applied and when.
In late 2025 Microsoft documented and began enabling a capability that causes Windows OOBE to install the most recent monthly security updates (quality updates) as part of the setup flow. That capability was then integrated with Microsoft Intune’s Enrollment Status Page (ESP) and Windows Autopilot flows — and critically, Microsoft added a new setting to allow administrators to block that behavior.
Below I explain what was changed, why Microsoft took the step, what administrators and device teams saw in the field, and practical steps to manage the trade‑offs between security and operational control.
What Microsoft changed — the technical facts
- Microsoft updated its Windows Autopilot/Intune documentation to describe an OOBE behavior that installs monthly quality updates during setup. The documentation page that logs this change lists the addition on September 3, 2025 and shows it was subsequently updated in January 2026. Microsoft also indicated that the capability was included in a January 2026 quality update release for Windows, meaning devices with that servicing baseline are capable of the new behavior.
- To give administrators explicit control, Intune’s Enrollment Status Page (ESP) received a new option labeled Install Windows quality updates (might restart the device). The default for new ESP profiles is Yes, but Microsoft left previously created ESP profiles unchanged — they remain set to No until an admin edits them. The design intent: allow organizations who want immediate, in‑setup hardening to enable the behavior, while not surprising long‑standing ESP configurations.
- Microsoft’s guidance clarified that monthly security releases are the unit of installation during OOBE — not every category of update. The goal is to install the latest cumulative monthly quality/security update so new systems receive recent fixes before they reach production use.
- In practice, parts of the staged rollout and the behavior that triggers downloads and installs at OOBE were pulled back or paused in some channels after administrators reported operational problems. Community reporting and independent Intune/Autopilot bloggers documented a temporary rollback of the automatic install pathway pending fixes and additional controls. Microsoft’s documentation updates and subsequent inclusion of the ESP toggle are the formal response to those operational concerns.
Note: Microsoft’s service and documentation updates reflect the official engineering posture; community reporting captured the real‑world impacts and the practical need for the ESP control. Where specifics diverge, prioritize Microsoft’s official guidance for policy and procedure decisions.
Why Microsoft introduced automatic installation during OOBE
Microsoft’s stated rationale is straightforward:
- Security from first boot. Applying the latest monthly security updates during OOBE reduces exposure to recently discovered vulnerabilities and helps protect devices that join networks immediately after provisioning.
- Zero‑day mitigation at scale. For targeted zero‑day or rapidly exploited problems, enabling early update application on new devices is a faster mitigation vector than waiting for device lifecycle management teams to patch devices after deployment.
- Simpler end‑user experience. For consumers and smaller organizations, the trade‑off of a longer initial setup for a more secure out‑of‑the‑box state is favorable; the device arrives in a more secure condition without extra steps from the user.
These benefits are real — but they come at operational costs that matter in enterprise, imaging, and server environments.
What administrators and deployment teams experienced
Once the feature began to appear in the ecosystem, IT teams reported a variety of operational outcomes. The most consistent themes were:
- Longer OOBE/p rovisioning times. Downloading and installing a quality update during OOBE obviously increases the time-to-desktop. Depending on network bandwidth, device storage speed and the size of the cumulative update, OOBE can be extended by many minutes — sometimes long enough to trip timeouts in enrollment flows or confuse technicians who expect quick provisioning.
- ESP and Autopilot timeouts. Enrollment Status Page profiles and Autopilot flows are often configured with timeouts and blocking apps. When OOBE began performing update downloads and installs, customers encountered ESP timeouts or perceived failures in the Autopilot sequence because installs exceeded estimated windows.
- Edge cases with older imaging strategies. Organizations that rely on offline images, pre-provisioning, or tightly controlled curated images found the automatic OOBE update behavior redundant or disruptive. Some teams prefer to inject a known update set into their image catalog and keep OOBE minimal; automatic installs during OOBE changed that calculus.
- Server and role‑specific concerns. Windows Server deployments — including Windows Server 2025 — have stricter uptime and configuration expectations than client laptops. Administrators reported concerns about server roles receiving unexpected updates during OOBE that could affect services or driver stacks.
- Rollbacks, pauses and fixes. Community reporting documented that Microsoft paused or rolled back aspects of the feature rollout while the company added controls, improved ESP integration, and sorted out timeout and error conditions. Those pauses weren’t always clearly announced to end users, which increased confusion.
These reports prompted Microsoft to make the ESP toggle the canonical way administrators can
block the automatic install behavior for their enrollment flows.
The operational trade‑offs: security vs control
The new behavior is a classic trade‑off.
- Pros
- New devices are less likely to be exploited immediately after provisioning.
- Critical fixes are applied before user sign-in, reducing the window for opportunistic attacks.
- For consumers and small businesses, the experience reduces post‑setup update tasks.
- Cons
- Longer provisioning windows increase the chance of human error, timeouts, or failed enrollments.
- Automated update installs during setup reduce deterministic control for organizations that require tested, curated images.
- Servers and specialized systems can be more fragile during an initial untested patch application at OOBE.
The right answer is environment dependent: a consumer or kiosk device benefits from automatic security installs; a carefully audited server image seldom should.
Practical guidance — how to manage or block the behavior
If you are responsible for Windows deployment, follow these steps to control the new OOBE automatic‑install behavior and limit operational surprises.
- Review current ESP profiles in Intune immediately.
- Edit any existing ESP profile you use for Autopilot or OOBE flows and confirm the setting Install Windows quality updates (might restart the device). By default Microsoft left older profiles at No; new profiles created after Microsoft’s change are set to Yes.
- Set the value to No for profiles you do not want to install monthly security updates during OOBE.
- For environments not using Intune/ESP, incorporate an alternative plan.
- If you use pre-provisioning, on‑prem imaging, WSUS, or Configuration Manager, document how updates will be staged and applied so OOBE‑time updates are either redundant or explicitly managed.
- If you want controlled OOBE installs, increase ESP and Autopilot timeouts.
- When OOBE installs updates, it can extend the time needed to complete blocking apps or provisioning. Increase timeouts and adjust blocking-app lists to avoid false failures.
- Build and test an updated image that includes the January 2026 baseline.
- Embedding the known quality update baseline into deployment images removes the need for OOBE to fetch the same update at setup time. Update images in your ring strategy and validate drivers, services and role behavior.
- For servers, separate imaging from OOBE update installs.
- For Windows Server deployments, schedule quality updates as part of post‑provisioning change windows rather than during OOBE. Servers often require role-specific validation before updates.
- Monitor telemetry and pilot broadly.
- Before rolling any change broadly, pilot it to representative hardware in each class (consumer laptops, corporate laptops, lineage servers, branch devices). Watch for OOBE time, network load, ESP events and unexpected restarts.
- Prepare user/infrastructure guidance.
- Inform technicians that the first boot may take longer and provide checklists: verify network connection, check ESP progress, and allow time for feature updates (if enabled).
- Where bandwidth is constrained, use local update caching or pre-stage updates.
- If many devices will provision simultaneously on the same network, use caching or a local update service to reduce bandwidth spikes and improve predictability.
Step‑by‑step: how an admin blocks automatic OOBE installs (high‑level)
- Open the Intune admin center and navigate to Enrollment > Enrollment Status Page.
- Select the ESP profile used for your Autopilot flows.
- Locate the setting Install Windows quality updates (might restart the device).
- Set the value to No to prevent monthly security (quality) updates from being installed during OOBE.
- Save and assign the updated profile to the required device groups.
- Test the change with a small pilot fleet to ensure enrollment times and ESP behavior are acceptable.
This is the supported control path Microsoft provided; it preserves the security choice for organizations while acknowledging operational realities.
Known risks and gotchas to watch for
- Hidden defaults for new profiles. If you create new ESP profiles after Microsoft’s change, the default will allow OOBE installs. That can trip teams that create profiles on the fly without reviewing defaults.
- Long download/install windows. If your ESP has strict timeouts, automatic installs during OOBE can trigger false failures. Adjust timeouts or disable OOBE installs until you’ve tested.
- Driver and imaging mismatches. Quality updates sometimes include driver or firmware changes. Installing them during OOBE before you can validate device‑specific firmware/driver interactions may have unintended consequences, especially on specialized hardware.
- Server roles and service impact. Some server roles expect a controlled update window. OOBE installs could change package order or force restarts at unexpected times during provisioning.
- Dependency on internet connectivity. The automatic install behavior requires a functioning internet connection. A lack of connectivity can leave setup in an indeterminate state or extend setup as the device retries. Pre‑staging updates in images avoids this dependency.
- Historical update delivery issues. Microsoft has previously adjusted how updates are packaged and delivered to Windows 11 and Windows Server 2025, and there have been well‑documented problems with MSU standalone installers and other edge cases in recent years. That history reinforces the need for controlled testing of any change to update timing.
Wherever the documentation and community reports diverge on specific operational incidents, prioritize your own test results and Microsoft’s published guidance.
Risk mitigation checklist for busy admins
- Confirm ESP setting state across all profiles right now.
- Add a standard pilot policy that runs a mix of device types and locations.
- Pre-stage the January 2026 (and later) quality update baseline into your deployment images.
- Adjust ESP timeouts and expand blocking app time budgets where OOBE installs are allowed.
- For servers and specialized endpoints, disable install‑during‑OOBE and schedule patching after deployment.
- Monitor Windows Update and Setup logs (including SetupDiag) when you run pilots.
- Communicate expected provisioning times and troubleshooting steps to help desk staff.
Critical analysis — strengths, weaknesses and longer‑term implications
Strengths
- Making it easy to apply critical security updates during OOBE is a responsible engineering choice: it reduces the window of vulnerability for devices that immediately connect to networks.
- The addition of an explicit Intune/ESP toggle acknowledges the diversity of deployment practices and gives enterprise administrators the control they need.
- Incorporating quality updates into Autopilot flows can be a win for smaller organizations that lack dedicated imaging or patch management teams.
Weaknesses and risks
- The automatic install behavior mixes two traditionally separate operational domains: image/OS deployment and ongoing patch management. Mixing them increases complexity and the chance that an unexpected update introduces regressions in the enrollment flow.
- Microsoft’s incremental rollout and the need to pause or “pull back” pieces of the feature for fixes highlights the operational danger of enabling platform‑wide behaviors without extensive enterprise field testing.
- Defaults matter. New ESP profiles defaulting to Yes can surprise admins who create profiles and expect prior behavior; defaults should favor least surprise in enterprise settings.
Longer‑term implications
- Expect more features to appear at OOBE as Microsoft tries to secure devices earlier — device hardening at first boot is a continuing trend. Engineering teams must coordinate image management, OEM drivers, and enrollment tooling more tightly than in the past.
- The dynamic between rapid security hardening and controlled change windows will push organizations to modernize image and update practices: more frequent image refreshes, better staging channels, and improved pre‑provisioning will be required for teams that want tight control.
- Vendors of imaging and provisioning tools will likely add explicit guards and observability around OOBE updates to help admins avoid surprises.
What to tell management and procurement teams
- The capability to install security updates during OOBE is intentional and is intended to reduce risk for newly provisioned devices. However, it is not a drop‑in replacement for a tested enterprise update process.
- Procurement and device lifecycle owners should insist on acceptance testing from OEMs and hardware vendors for devices destined for critical roles. Don’t assume OOBE installs are safe for every server or specialized appliance.
- Plan a short window to update deployment images and policies. Even if you block OOBE installs, you must keep images current — the difference is whether you apply fixes in a controlled image or during the OOBE moment.
Conclusion
Microsoft’s decision to enable automatic installation of monthly security updates during OOBE reflects a reasonable security posture: fewer devices that leave the factory or provisioning center with known, unpatched vulnerabilities is an unalloyed win —
if the operational fallout is contained. Enterprises and server teams, however, rightly demanded more control and predictability, which is why Microsoft extended Intune’s Enrollment Status Page with a specific toggle to
allow or block the behavior.
The practical lesson is simple and urgent: assume OOBE can do more than it used to. Review your enrollment profiles, update your imaging strategy, and pilot the change across representative hardware now. If your devices must be validated before accepting updates, explicitly block OOBE installs and stage the required updates in your images. If you want the fastest possible hardening for consumer or distributed devices, evaluate using the OOBE installs but extend ESP timeouts and monitor coverage.
Finally, treat documentation changes and community reporting as signals: Microsoft’s documentation, the Intune ESP toggle and the community’s reporting of a staged pullback together tell the same story — the feature is real, the control is available, and the operational trade‑offs must be managed deliberately. Act now to make that choice explicit in your deployment plans rather than discovering it under pressure on a mass provisioning day.
Source: Neowin
Microsoft blocking a Windows 11 & Server 2025 automatic installation feature