How to Stop Windows Update Without Breaking Defender

Updated: October 2026

The supported way to stop Windows Update is to pause it, for a maximum of 35 days, and every other method is a fight with a component Microsoft does not document. This guide covers the pause, the policies that hold, the registry values people get wrong, and how to push any of it across a fleet. It also covers the part the search results skip: disabling Windows Update can starve Microsoft Defender of signatures, because Defender gets them through the same pipe.

TL;DR

• Pause is the supported off switch. Up to 35 days, then it resumes on its own.
• Active hours stops the restart, not the download. Metered connections still let priority updates through.
• Disabling the service does not hold. It is re-enabled by a component Microsoft has never documented.
• Defender rides the same pipe. Break Windows Update and signatures can go stale for seven days.

Pause Updates, the Only Supported Off Switch

On Windows 11 the path is Start > Settings > Windows Update, then Pick a date on the Pause updates control. Microsoft's pause documentation sets the ceiling at 35 days from the current date, and the calendar will not offer you a date beyond it. Extending resets to 35 days from today rather than adding to what you already used.

On Windows 10 the path is Start > Settings > Update & Security > Windows Update, then either Pause updates for 7 days or Advanced options and a resume date.

Two things worth knowing before you rely on it. Updates already in progress are cancelled when you pause. And when the pause expires the device checks, downloads and installs on its own, with no prompt.

There is a genuine contradiction in Microsoft's own documentation here. The Windows Update FAQ, last dated March 2026, says that after the pause limit you will need to install the latest updates before you can pause again. The pause article, dated May 2026, describes extending repeatedly inside a rolling 35 days. They also describe two different interfaces. Treat the behaviour as build-dependent and check the machine in front of you rather than trusting either page.

Active Hours Stops the Restart, Not the Update

Active hours is the setting people reach for when the real complaint is a reboot, not a patch. It does nothing to downloading or installing. Microsoft's own wording in the Update Policy CSP is that the PC will not automatically restart during the window, and that is the whole scope of it.

The range is configurable but bounded: between 8 and 18 hours, defaulting to 18, with a start default of 8 and an end default of 17. On Windows 11 it sits under Settings > Windows Update > Advanced options > Active hours, with an Adjust active hours dropdown offering Automatically or Manually. Windows 10 puts it behind Change active hours with a separate auto-adjust toggle.

One trap: the start and end values have no effect at all if either "No auto-restart with logged-on users for scheduled automatic updates installations" or "Always automatically restart at scheduled time" is enabled. If active hours appear to be ignored, check those two before anything else.

Metered Connection, and What It Does Not Block

A metered connection is a network Windows treats as having a data cap or a per-megabyte cost, so it holds back background downloads to save data. You set it per network: in Windows 11, go to Settings > Network & internet, open the Wi-Fi or Ethernet connection, and switch on Metered connection.

Marking a connection metered is the softest block available and the most misunderstood. Microsoft's metered connections page says Windows Update will only download priority updates, Store downloads might pause, and offline files might not sync.

Read that phrasing carefully. It is not "no updates" and it is not "security updates only" either, because Microsoft never defines what counts as a priority update on that page. Quote it as written when you explain it to a client rather than translating it into a promise you cannot keep.

Cellular connections are metered by default and Wi-Fi is not. There is also an explicit override at Settings > Windows Update > Advanced options > Download updates over metered connections, and a matching policy called "Allow updates to be downloaded automatically over metered connections", so a metered block can be quietly undone from either side.

Disabling the Service Does Not Hold

The advice that circulates most is to set the Windows Update service, wuauserv, to Disabled. It works until it does not.

Microsoft documents wuauserv, the Update Orchestrator Service UsoSvc, the Background Intelligent Transfer Service BITS and the Delivery Optimization service DoSvc. What it does not document, anywhere, is WaaSMedicSvc, the Windows Update Medic Service, which is the component that reverses the change. Searching Microsoft Learn for it returns community question threads and nothing else. There is no page describing what it does, when it runs, or how to stop it.

That absence is the argument. A method whose failure mode is undocumented cannot be tested, cannot be supported, and should not be standardised across a fleet. Microsoft's own position in the Windows Update FAQ is blunt: you cannot stop updates entirely, and they will eventually need to be installed regardless of your settings. If you need updates held, hold them with policy, where the behaviour is written down.

One r/sysadmin thread runs that experiment all the way to the end. The OP stops wuauserv, UsoSvc, WaaSMedicSvc and DoSvc, kills each process, disables four UpdateOrchestrator and WaaSMedic scheduled tasks and sets NoAutoUpdate to 1, and Windows still installs updates during shutdown. The workaround the replies converge on is not to fight the service at all: point Windows Update at a WSUS server that does not exist.

Group Policy, and the Tree That Moved

Nearly every article on this subject gives the path as Computer Configuration > Administrative Templates > Windows Components > Windows Update > Configure Automatic Updates. On current Windows 11 ADMX that is the old layout. There are now four subfolders under Windows Update:

Microsoft's own pages disagree about this, which is why the confusion persists. The Policy CSP reference, dated June 2026, gives the subfolder layout. "Manage additional Windows Update settings", dated February 2026, still prints the flat path. Both paths appear in the wild depending on the ADMX version in your central store, so look for the policy rather than the path.

Configure Automatic Updates itself offers options 2, 3 and 4 on Windows 11 client: notify for download and auto install, auto download and notify for install, and auto download and schedule the install. Option 5 exists in the documentation but Microsoft states it is unavailable on Windows 10 and later, and option 7 is Windows Server 2016 and later only.

The Numbers That Mean Two Different Things

This is the trap worth reading twice, because it produces the opposite of what you intended and it does so silently.

The same policy is expressed on two different integer scales. In the registry, under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU, the value AUOptions uses one scale. In the MDM and CSP world, AllowAutoUpdate uses another.

Read row five. Someone who finds AllowAutoUpdate = 5 in the CSP reference and writes AUOptions = 5 into the registry has not turned updates off. They have set a mode Microsoft says does not work on this operating system. Microsoft does not publish a cross-walk between these scales, so do not convert between them; take each from its own reference.

The straightforward registry switch in that same key is NoAutoUpdate, a REG_DWORD where 0 is enabled and 1 is disabled. Microsoft's warning on the CSP equivalent is worth carrying to a client: that option is for systems under regulatory compliance, because you will not get security updates either.

Deferral Across a Fleet

Deferral is what the request usually means when someone says stop. It holds an update back for a defined window without breaking the mechanism, and the limits are firm.

Quality updates defer for a maximum of 30 days, via DeferQualityUpdatesPeriodInDays. Feature updates defer for up to 365 days on the General Availability Channel and 14 days on prerelease channels, via DeferFeatureUpdatesPeriodInDays. Both sit under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, and in Group Policy they are "Select when Quality Updates are received" and "Select when Preview Builds and Feature Updates are received".

Microsoft publishes a number here that is useful to quote in a patch SLA: to help ensure devices stay secure, configure quality update deferral to be less than three days.

Pausing by policy is also capped at 35 days, using PauseQualityUpdatesStartTime and PauseFeatureUpdatesStartTime, which take a string in yyyy-mm-dd form. Pausing feature updates does not pause quality updates; those keep being offered. In Intune the same controls appear as update rings, with a quality deferral range of 0 to 30 days, a feature deferral range of 0 to 365, and the same 35-day pause.

Two operational details from Microsoft's Intune documentation save real trouble. A device that is switched off when you issue a pause may download and install a scheduled update when it powers on, before it checks in. And deleting an update ring does not revert anything: the device keeps the settings it already has, with no record of what it held before.

What a working ring config looks like is worth reading from someone running one. In this thread an admin describes a 14-day deferral on Windows servers with a separate 3-day ring for test and low-risk production boxes, weekly cadence, and one escaped issue in about seven years. Another admin in the same thread describes a validation ring with no test instance of the critical servers and no functional checks, shipping to production a week later regardless, which is the useful half: a ring is only worth the testing that happens inside it.

Turning Off Updates Turns Down Defender

This is the part almost every guide on this keyword misses, and it changes the recommendation.

Microsoft Defender Antivirus does not have its own independent update channel by default. Microsoft states it plainly in an Important callout on the Defender update sources page: security intelligence updates and platform updates are delivered through Windows Update.

There is a fallback, and the timing is the problem. If the Microsoft Update source is the working one and you break it, the security intelligence page fallback only kicks in when the current update is considered out of date, which Microsoft defines as seven consecutive days of not being able to apply updates. Security intelligence normally refreshes several times a day. So the realistic outcome of disabling the service on an endpoint is up to a week of stale detection content on a machine whose owner believes only patching stopped.

Defender is genuinely independent only if you have explicitly configured the fallback order to include the security intelligence source, a file share or an internal definition server, and then verified it. That is a two-minute check with Set-MpPreference -SignatureFallbackOrder, and it is worth doing before you disable anything.

How to Confirm It Took

Do not trust the Group Policy editor for pause state. Microsoft documents that GPEdit will not reflect an expired pause period: the device resumes after 35 days, and the checkbox stays ticked anyway.

Check the status keys instead, under HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings. The values PausedQualityStatus and PausedFeatureStatus read 0 for not paused, 1 for paused, and 2 for automatically resumed after a pause. PausedQualityDate and PausedFeatureDate give the start date. That 2 is the one to look for when a client insists updates were held and the machine patched anyway.

Should You Stop Windows Update at All?

Usually the ticket is about the reboot rather than the patching, and active hours plus a deadline settles it without disabling anything.

Where it matters most right now is version support rather than monthly patching. Windows 11 24H2 Home and Pro reach end of servicing on 14 October 2026, which means a fleet sitting behind a long feature-update deferral is heading for unsupported machines rather than merely delayed ones. Deferral is a delay, not a block, and it does not extend a lifecycle.

The risk side is not abstract either. CISA's Known Exploited Vulnerabilities catalogue, as of its 16 September 2026 release, carries 177 entries for Microsoft Windows products, and 49 of those are flagged as used in known ransomware campaigns. One entry added on 8 September 2026 is a privilege escalation in the Windows Update stack itself. Our guide to patch management software covers the tooling side of keeping that window short.

If ring-based deferral is where you land, this walkthrough builds the pilot, early adopter and production rings in Intune, with separate deferral periods for feature and quality updates and deadline policies for install and restart.

What to Do Next

Pause if you need a short, supported hold and you accept the 35-day ceiling. Use deferral policy if you need a repeatable window across machines, and keep quality deferral tight. Use active hours and deadlines if the complaint is about restarts.

If you are managing more than a handful of endpoints, do it from update rings rather than per-device settings, and confirm the result in the status keys rather than in the policy editor. Our endpoint management comparison covers the platforms that push this centrally.

And before you disable anything on a client machine, check where Defender is getting its signatures. That is the failure nobody reports as an update problem, because it does not look like one.