What WSUS, Intune, winget and Chocolatey each fail to patch
None of these four tools patches your firewall. Nor your hypervisor, your NAS, your managed switches or the management controller in your servers. All four are channels for getting software onto Windows endpoints. What each covers differs sharply; what all four leave out is identical — and in most estates nobody has measured how large that remainder is.
| Tool | Covers | Does not cover | Common misreading |
|---|---|---|---|
| WSUS | Microsoft products from Microsoft Update | third-party software nobody published into it | “deprecated means it stops working soon” |
| Intune | Windows Update content, plus apps you package or license | third-party apps without a package or the paid add-on | “we have Intune, so we are patched” |
| winget | apps on a running Windows box, once somebody triggers it | anything without a readable version; approval and reporting | “a scheduled upgrade --all is patch management” |
| Chocolatey | third-party Windows software somebody has packaged for it | organisational use straight off the community repository, barred from 01/01/2027 | “that repository is a distro repo for Windows” |
WSUS: what comes down Microsoft Update, and nothing else
Microsoft states the scope plainly: WSUS manages the distribution of updates released through Microsoft Update. Non-Microsoft software is not in that stream. Somebody has to publish it in — historically with System Center Updates Publisher, which Microsoft lists as unsupported since 31 January 2024, today via the third-party update catalogues in Configuration Manager or a commercial publishing tool.
The deprecation of 20 September 2024 is regularly read as a shutdown notice. It is not: Microsoft’s wording is that it is no longer investing in new capabilities while preserving current functionality and continuing to publish updates through the channel. The role still ships in Windows Server 2025, and the plan to end driver synchronisation in April 2025 was postponed without a new date. The dangerous misreading runs the other way: a WSUS console at full compliance is a statement about Microsoft software only. Browser, PDF reader, Java runtime, backup agent — none of them are in that number.
Intune: timing for Windows, packaging for everything else
Update rings and Windows Update client policies control when Windows Update content installs — quality updates, feature updates, drivers. Microsoft is explicit about the division of labour: Intune stores only the policy assignments, not the updates themselves. The setting Microsoft product updates widens the scan to app updates from Microsoft Update — which is still Microsoft software.
Third-party applications take one of two routes. Either you package them as Win32 apps — which Microsoft’s app-type table files under line-of-business, and the Updates column for that category reads: you must update the app. Or you license Enterprise App Management with its Microsoft-prepared catalogue of apps, which Microsoft describes as part of the Microsoft Intune Suite, available for trial and purchase and, in its own FAQ, as purchasable standalone as well. Even then Microsoft documents the limits of the automatic update path itself — no rollback, no rollout rings or phased deployment, catalogue data cached for up to one hour, so a revoked version can still reach devices inside that window. Related and easy to miss: for driver policies Microsoft notes that Intune doesn’t collect an inventory of installed drivers.
winget: an action, not a channel
winget updates installed applications. What it does not do is behave like a deployment service: no central approval, no deadline, no report telling you which machine last night’s run failed on.
It has two silent gaps as well. Microsoft’s documentation notes that some applications report no version and are therefore skipped by winget upgrade unless you add --include-unknown — with that option it reinstalls them without being able to tell whether that was necessary. Pinned packages need --include-pinned on top. A run reporting nothing to do is therefore not the same as a current machine. The default source is a community repository: vendors and contributors submit manifests, which Microsoft describes as automatically validated and possibly reviewed manually. That is a supply chain with a lag, and the lag is not published per package.
Chocolatey: community packages, with a deadline attached
choco outdated lists what is behind, choco upgrade all brings it forward. Together with winget this is the route that reaches third-party Windows software without you packaging it first — and the one carrying a rule change many estates have not noticed. Chocolatey Software has advised for years that organisations should not point production machines straight at the community repository, citing reliability, trust and control. With an update to the terms of service published on 1 June 2026, that becomes binding on 1 January 2027: organisations may not use the community repository directly to manage organisational computers and need an internal repository or a caching proxy serving packages from inside. Personal workstations stay exempt.
Two properties belong in the same breath. Because of distribution rights many community packages download the actual installer from the vendor at run time — if the vendor moves the URL, the package breaks until a volunteer fixes it. And the repository is rate limited at roughly 20 package requests per minute per IP address, a limit a fleet behind one shared outbound address can reach; the block that follows lasts an hour.
The devices none of the four is responsible for
Every tool above assumes a running Windows installation underneath it. That assumption excludes a whole tier of the estate:
- firewalls, VPN gateways, load balancers, switches, access points — firmware, by hand
- hypervisors, NAS boxes, backup appliances, tape libraries
- out-of-band management controllers, UPS network cards, printers, IP cameras
- container base images, and the runtimes and libraries inside them
For these there is no agent to roll out and no console to consolidate. The update is a firmware file, a web interface and a maintenance window. The only lever that exists before that point is knowing a new version shipped at all — and that is precisely what no deployment tool provides.
Three questions that measure your coverage
- How many distinct products run in the estate, and how many of them appear in any report from any of the four tools? The difference is the remainder. Write both numbers down before estimating either.
- Per product: who learns of a new version first, the tool or a person? Where the answer is a person, the update depends on somebody remembering to look.
- When an update fails, does it land in a report or only in a local log? A tool without feedback is a suggestion, not a control.
The honest limitation
A notification installs nothing. It closes no gap and replaces no deployment tool — it only tells you one is open. For everything WSUS or Intune already reaches, an extra email is noise; the channel is the better instrument there and should keep the job. The value sits entirely in the remainder, and the remainder is a different size in every estate. The vendor positions quoted here move as well, so every statement above carries the date it was checked.
patchletter watches vendor release sources and emails you when a new version appears — including for the products no deployment channel reaches. The two tools from this article are in the catalogue too: WinGet (latest recorded 1.29.280, vendor date 24/06/2026) and Chocolatey (2.7.3, 10/06/2026), both as of 19/08/2026. Tick what you run in the catalogue. Free, no account, one-click unsubscribe.
Vendor statements checked on 19/08/2026, each linked where it is used: Microsoft Learn and the Windows IT Pro blog on WSUS, Configuration Manager, Intune and WinGet; Chocolatey documentation plus its terms-of-service post of 01/06/2026. Version figures from our own dataset as of 19/08/2026.