Patch posture

Which machines are behind on updates?

It is the most common question at the boundary between asset management and security, and VerOps already has the agent, the alerting engine and the dashboards to answer it. Update posture takes what the agents report about each machine's OS update state and reduces it to one of four buckets you can filter, chart, alert on and report.

This article covers the platform side: how the buckets are decided and where posture surfaces. What the agents actually collect — and the strict limits on how they collect it — is documented in Update posture (VerOps Scout).

Requirements

• VerOps Scout 0.4.0 or later on workstations, or Machine Agent 0.3.0 or later on servers. Both report identical fields with identical bucketing, so a mixed fleet is measured the same way.
• The patch posture collection module enabled in your policy (it is on by default).

The four buckets

Bucket	Means
Current	Nothing in the machine's reported update state meets a behind or critical condition.
Behind	Measurably out of date, but not yet at the level that warrants urgency.
Critical	Far enough behind to be treated as a security exposure.
Unknown	Not measured — the agent predates the module, the module is switched off, or nothing usable was reported.

Unknown is not a failure state, and it is deliberately never Current. A machine running an older agent, or one with the module disabled, reads Unknown — VerOps will not score a machine as healthy on no evidence. A false "healthy" is more dangerous than an honest "not measured". Expect Unknown to be your largest bucket immediately after upgrading, and to shrink as agents roll out.

The exact rules

Windows

Bucket	Any of these conditions
Critical	Last update installed more than 90 days ago · a reboot has been pending continuously for more than 14 days · (with a build catalog loaded) the reported build is two or more releases behind the latest for its Windows version
Behind	Last update installed more than 45 days ago · (with a build catalog loaded) the reported build is one release behind · the Windows Update service is stopped or disabled
Current	None of the above

Linux

Bucket	Any of these conditions
Critical	More than 10 security updates pending · a reboot has been required continuously for more than 14 days
Behind	At least one security update pending · or, when the package manager cannot distinguish security updates, more than 25 upgradable packages in total
Current	None of the above

Boundaries are strict

Every day comparison is strictly greater than, so a machine sitting exactly on a boundary falls on the safe side of it:

Days since last Windows update	Bucket
45 days	Current
46 days	Behind
90 days	Behind
91 days	Critical

The same applies to the 14-day pending-reboot rule.

"No security updates" and "cannot tell" are different answers. When a package manager genuinely reports zero pending security updates, that counts as zero. When it cannot distinguish security updates from ordinary ones — for example because the advisory metadata is not present in the local cache — the agent reports nothing at all rather than zero, and VerOps falls back to the total upgradable count. Sending zero in that situation would silently score an unmeasured machine as clean.

macOS

macOS hosts always resolve to Unknown. There is no macOS agent in this release, and a macOS host is never scored with Windows or Linux rules.

The OS build catalog

Two of the Windows rules — one and two releases behind — depend on knowing what the latest build actually is. VerOps does not call out to any vendor feed for this. Instead you may upload a manual OS build catalog as a CSV under Inventory → Policy:

os_version,latest_build,release_date
Windows 11 23H2,22631.4317,2026-06-10
Windows 11 22H2,22621.4317,2026-06-10
Windows 10 22H2,19045.4894,2026-06-10

Behaviour with and without a catalog:

• No catalog — every catalog-derived rule is simply a no-op. Posture still works fully from the agent's own facts (update age, pending reboot, service state, security counts). This is a perfectly reasonable way to run.
• Catalog loaded — build comparison activates for the versions you listed. Versions absent from the catalog are unaffected.

The reported build number counts as a signal only when a catalog is loaded — otherwise a machine that reported nothing but its build number would be scored Current on no real evidence.

The installed hotfix count is informational: it appears on the asset detail page but is not an input to the bucket.

Where posture surfaces

Surface	What you get
Hosts tab	An Update posture pill column with a per-bucket tooltip and "since" text, plus a filter strip to narrow to a bucket. The hosts API accepts a posture filter too, for your own tooling.
Overview	An Update posture KPI tile — the critical count, with the behind count as its hint.
Asset detail	An Update posture card in the Hardware/OS area showing the raw reported facts, the bucket and how long it has held, rendering only the fields relevant to that machine's OS.
Timeline	An update posture changed event, filterable with the Patch chip.
Dashboards	Fleet bucket counts, labelled by OS family and bucket, exported hourly — chartable alongside your own metrics.
Reports	The patch_posture scheduled report — worst offenders plus fleet counts, as CSV or PDF.

Bucket counts always sum to your fleet size: machines with no posture record are counted as Unknown rather than dropped, so the numbers reconcile.

Alerting on posture

Posture plugs into the existing policy and alerting engine. Under Inventory → Policy → OS update posture you set two thresholds:

Threshold	Default	Raises a violation when
Critical hosts	more than 0	Any machine at all is critical
Behind hosts	more than 25	More than 25 machines are behind

"Any critical machine is a violation" is the security-sensible default; raise it if your estate needs a grace period. The violation is fleet-level: a whole fleet falling behind produces one violation per bucket, not one per machine, so a bad month does not generate hundreds of alerts. It appears on the Violations tab, fires through your normal alerting, and auto-resolves once the fleet recovers.

Event behaviour

An update posture changed event is written only when a machine's bucket actually changes, and announcements are limited to at most one per hour per machine. A machine flapping between buckets within an hour produces one event, not several — while the record itself always reflects the true current bucket.

What this feature is not

Update posture measures; it does not act. There is no patch deployment or remediation, no WSUS, SCCM or Intune integration, and no per-KB vulnerability mapping. VerOps tells you which machines need attention and lets you alert on it — applying updates remains the job of your existing patching tooling.