Your security metrics are getting better. Your security might not be.

Microsoft has announced that Windows Autopatch will enable hotpatch updates by default starting with the May 2026 security update. The numbers in the announcement are striking. Across companies running 30,000 to 70,000 devices, hotpatch took them from 90% patch compliance in 19 days to 90% in 7. From 25 days to 13. From 27 to 14. Same security fixes, no policy changes, half the time to compliance.

This is genuinely good engineering. It is also about to make several long-trusted security metrics look better for reasons that have nothing to do with your security improving.

The metrics are about to look better

Across most security programmes, a familiar set of numbers gets reported up the chain each month. Days to patch. Percent of estate compliant. Pending reboot count. Time from CVE publication to remediation. These numbers have been the working language of vulnerability management for the better part of two decades. They are in board decks, in audit responses, in regulator filings, in the SLAs that vendors are held to.

Starting in May, several of those numbers are going to improve sharply for organisations with significant Windows estates. Days to patch will compress. Pending reboot counts will fall toward zero for in-quarter updates. Compliance percentages will climb faster after each Patch Tuesday. None of this will be the result of better security work. It will be the result of Microsoft changing how the underlying mechanism functions.

That is not a criticism of hotpatch. Hotpatch is a clear improvement. The point is narrower and more uncomfortable: the metrics we have been using to measure progress were never measuring what we thought they were. They were measuring the friction in a specific delivery mechanism. When the friction goes away, the metrics improve, and the thing they were proxying for, actual exposure, may not have moved at all.

Three signals losing their meaning

Consider what is actually happening at the signal level.

The compliance percentage was useful when patch velocity was the bottleneck. In a hotpatch world, Windows OS-level patching stops being the slow part of the estate for a meaningful slice of devices. A high Windows compliance percentage in May 2026 means something different from what it meant in March 2026, even though the number on the dashboard looks the same or better. Comparing the two as if they measured the same thing is a category error.

Pending reboot was, for many organisations, the single most operationally useful security signal. It told you that a fix had been delivered but not yet activated. SOC dashboards counted it. Compliance frameworks asked about it. For Windows in-quarter updates, that signal is being retired. It is not being replaced with nothing. Hotpatch readiness, baseline alignment, and quarterly baseline restart status are all real signals. But they are not the same signal, and any reporting that treated pending reboot as a primary risk metric is now reporting on a metric that has structurally changed.

Patch SLA, measured as a single estate-wide number, was always a flattening of very different realities across asset classes. The 2025 Verizon DBIR is blunt about how uneven the picture is in practice: only 54% of edge device vulnerabilities were fully remediated across the year, with a median of 32 days to full remediation, despite organisations working hard to close them. Meanwhile, exploitation of vulnerabilities as an initial access vector grew 34% year on year and now accounts for 20% of breaches, with edge devices and VPNs the fastest-growing target category. When Windows endpoint patching gets twice as fast and edge device patching does not move, the blended SLA improves and the actual exposure surface, which lives where patching is slowest, does not.

In each case, the metric is not wrong. It is just no longer measuring what it used to measure.

This is not a hotpatch problem

Hotpatch is a useful illustration because the change is sharp, dated, and well documented. But the underlying issue has been building for years and is not specific to Windows.

Cloud-native infrastructure broke the asset inventory metric. The list of machines you owned at the start of the month is no longer the list you own at the end of it, and a compliance percentage calculated against a stale denominator is a number that means whatever you want it to mean.

SaaS adoption broke the perimeter scan metric. The systems holding the most sensitive data are increasingly outside the network you are scanning, and the configuration state of those systems is not visible to a vulnerability scanner at all.

Identity has become a primary attack surface, and almost none of the inherited vulnerability management metrics measure it. The 2025 DBIR found stolen credentials were the initial access vector in 22% of breaches, the single most common entry point, ahead of vulnerability exploitation. Errors and misconfigurations featured in more than 25% of incidents. A service account with excessive privileges is not a CVE. It does not appear in a patch report. It does not generate a pending reboot. It is, in many real incidents, the actual path to compromise.

The pattern is the same in each case. A metric that worked in a narrower world is being asked to describe a wider one, and is quietly losing fidelity. Hotpatch is just the most recent and most concrete example.

What continuous exposure management actually measures

In 2022, Gartner introduced Continuous Threat Exposure Management as a framework, and predicted that by 2026, organisations prioritising security investments based on a CTEM programme would be three times less likely to suffer a breach. We are now in 2026. The honest assessment from across the industry is that the prediction is directionally supported but has not been empirically validated, in part because the measurement infrastructure to test it does not yet exist. That is itself revealing. The prediction that should anchor the case for CTEM cannot be cleanly proven because the shared metrics needed to measure it are still being built.

The shift from vulnerability management to continuous threat exposure management is sometimes described as a faster version of the same thing. It is not. It is a different set of signals, chosen because the old ones are losing resolution.

Configuration state across the platforms that matter, not just the ones that are easy to scan. Identity and access posture as a first-class signal, not an afterthought. Asset truth that reflects what is actually in the estate this hour, not what was there at the start of the reporting period. Prioritisation that combines exploitability, exposure, and business context, rather than treating CVSS as a verdict. Continuous measurement, because the gap between two monthly snapshots is where most real exposure lives.

None of this is a rejection of patching. Patching matters. Hotpatch is a real improvement and organisations should adopt it. The argument is that the metrics built around patching were always a proxy, and the proxy is getting weaker. Programmes that lean on it as the primary measure of security progress are about to receive a flattering report that does not reflect a flattering reality.

The harder question

The interesting question for security leaders in the next two quarters is not whether to enable hotpatch. The default will handle that. The interesting question is which of the numbers currently in the monthly security report still measure what their name suggests they measure, and which ones have quietly drifted.

If a metric is going to improve in May for reasons unrelated to any security work the team has done, it is worth asking what that metric was ever telling you. And if the answer is "less than we assumed," it is worth asking what should be measured instead.

That is the work CTEM exists to do. Nanitor's continuous exposure management platform is built around the assumption that the useful signals in 2026 are not the ones that worked in 2010. If your security metrics are about to look better without your exposure changing, we should talk.