What "Applicable" Really Means on Windows Update | TridentStack Blog<br>Back to BlogPatch ManagementWindowsWindows UpdateWUAWSUS AlternativeEndpoint ManagementVulnerability Management<br>What "Applicable" Really Means on Windows<br>Adam CurtisJuly 28, 2026

Which updates does this machine need? The question sounds like a database lookup, and it is one of the hardest in endpoint management, because every source you would trust to answer it is wrong in a different way. This is a long, technical walk through why that is true and what a correct answer requires. It is written for people who patch fleets for a living.

When we started building patch management for Windows, we assumed the applicability problem was already solved. Windows ships with an entire update stack. There is a documented client API for it. There is a Settings page any user can open. Microsoft publishes a catalog of every update it has ever released. Surely, somewhere in there, is an authoritative answer to "does KB5066835 apply to this machine?"

There is not. Not in any one of those places. We spent months learning that the hard way, one production incident at a time, and the conclusion we reached is the thesis of this post: on Windows, applicability has to be computed from primary evidence and then reconciled against reality, because there is no single source of truth to look it up in.

To be precise about the claim, because precision matters here: the Windows update stack is a remarkable piece of engineering that keeps a billion machines patched, and the problem I am describing is narrower and more interesting than "the Windows Update Agent is bad." Each of the three sources you would reach for to answer the applicability question, the Windows Update Agent COM API, the Windows Update Settings UI, and the Microsoft Update Catalog's own metadata, is authoritative for a slightly different question than the one you are asking. When you use any of them as your answer, the gap between the question they answer and the question you asked shows up as a wrong patch decision. Sometimes that means offering an update that will never install. Sometimes it means hiding one the machine needs.

The first half of this post is the three sources and how each one diverges. The second half is the mechanism that works, built up in layers. Throughout, the examples come from production: KB numbers, error codes, and build numbers out of our own incidents.

Part 1: the three false authorities

False authority #1: the Windows Update Agent COM API

The Windows Update Agent, WUA, is the client-side engine that Windows Update itself runs on. It exposes a COM automation surface: Microsoft.Update.Session, IUpdateSearcher, IUpdateInstaller, and friends. It is what WSUS clients talk to, it is a large part of what Intune drives, and it is the first thing nearly every RMM reaches for, because it is right there and it is what Windows uses. We started there too. Our very first update code was PowerShell calling New-Object -ComObject Microsoft.Update.Session, and we later ported the same calls into a native Rust module against the COM interfaces directly.

WUA is good at what it is designed for. The trouble starts when you treat its answers as ground truth for whether an update applies and whether an install succeeded. Two divergences, both of which cost us time.

The install "succeeded" but the machine did not change. When you call IUpdateInstaller.Install() for a cumulative update, the immediate result you get back can be orcSucceeded (that is OperationResultCode value 2). It is tempting to treat that as "the update is installed." For any update that requires a reboot, that return tells you only that the pre-reboot phase, the staging of the payload into the component store, completed. The real work, where Component-Based Servicing (CBS) commits the new component versions into the running OS, happens during the reboot, in a kernel-mode servicing pass you have no synchronous handle on.

If CBS rejects the update during that reboot pass, and it can, for reasons that have nothing to do with whether WUA "installed" it, the update rolls back. The build number never advances. And here is the part that makes automation dangerous: WUA's own history will, after the fact, log that same update as orcFailed (OperationResultCode 4). So the API told you orcSucceeded at install time and orcFailed after the reboot, for one update, and if your tooling trusted the first answer it now believes a machine is patched that is not. We watched this exact pattern on Windows 11 24H2 with a cumulative update (KB5066835) staging cleanly on build 26100.1742 and then failing to commit. The API was answering "did staging succeed?" while we were asking "is this machine patched?" Those are different questions, and WUA does not distinguish them for you at the point where you make the decision.

Supersedence it will not reliably tell you. A superseded update is one that a newer update fully replaces. You should never...