Mimic published three research pages on real production data, and together they make one argument most vendor content never finishes. Here it is, end to end.
What a trusted binary can do versus what it should do
Start with a fact about servers that defenders rarely use. A production database host runs a narrow, predictable set of software. The set of binaries that should execute on it is small and stable. The set that can execute is enormous. That gap is the attack surface.
Attackers work inside it through living off the land, abusing trusted signed binaries already present on the system. PowerShell, WMI, certutil, and regsvr32 are all legitimate. They are also how an intruder runs code, moves data, and stays resident without dropping anything a scanner flags as malware. On a laptop, the range of normal is wide enough that this behavior hides easily. On a server, it does not have to.
Our Server Threat Library catalogs these techniques for servers specifically, drawing on LOLBAS, GTFOBins, and MITRE ATT&CK. The point it keeps returning to: the predictability of a server is a defensive advantage, and almost nobody spends it. You already know what should run on that host. The question is whether anything enforces it.
Why the action list is short when the CVE list is not
Now take the other side of the problem. CISA maintains the Known Exploited Vulnerabilities catalog, a record of vulnerabilities confirmed exploited in the wild, with a flag for those tied to ransomware campaigns. Most teams read it as a list of things to patch. Our Exploit Path research asks a different question of the same data: not which vulnerability was used, but what an exploit of that class has to do on a host to work.
The answer is consistent. To succeed, an exploit generally has to write a file, load code, modify a protected resource, or elevate privilege. Track vulnerabilities one by one and you get a list that outruns remediation. Track required actions and you get a short, stable set, because the techniques underneath thousands of CVEs collapse into a handful of things an attacker must accomplish on the machine.
Exploit Path states its own limit plainly, and so will we. Constraining what an exploit can do on a protected host does not remove the underlying vulnerability, and it is not a substitute for patching where a patch is available. The reframe changes your prioritization. It does not erase your patch queue.
What the patch cycle leaves behind
The third page measures the residue. Missing Patches is a continuous assessment of vulnerability exposure across the production server estates we monitor. Two things make it different from a typical scan report.
First, findings are observed, not reported. It reads the software actually present on disk and matches it to CPE entries, then compares against NVD CVE records and CISA known-exploited status. It is not trusting an inventory system's record of what should be installed. It is looking at what is.
Second, the population is production only. Development machines, proof-of-concept boxes, and internal systems are excluded, so the picture reflects environments that matter rather than lab noise.
The pattern it surfaces is the useful part. Broad exposure is close to universal. Nearly every estate carries a large raw CVE count. But the urgent portion, the known-exploited and ransomware-flagged subset, is tightly concentrated. The genuinely actionable backlog is smaller and more specific than a raw count implies. And the riskiest software is rarely what anyone is thinking about. It is the virtualization guest agent or the legacy runtime installed on every host and owned by no one.
Missing Patches is candid about what it does not claim, and that candor is worth repeating. An exposure finding is not an exploitability verdict. Absence from the assessment is not evidence of safety. The Windows cumulative-update figure is an estimate. Provenance is split: the CVE data is NVD's, the exploited status is CISA's, and the observation layer is ours. Live figures on the page require sign-in, so the working surface is gated even though the page itself is public and substantive.
How to use each page this week
None of this requires talking to us. Here is what a security team can do with these three pages in the next few days, for its own benefit.
Reprioritize your remediation queue by required action. Take your current backlog to Exploit Path and re-sort it. Group findings by what an exploit would have to do on the host rather than by CVSS score alone. The items that enable write, load, modify, or elevate on a production system move up. The long tail that a raw count inflates moves down. You will end the exercise with a shorter, defensible top of the queue.
Audit which trusted binaries are permitted on your production hosts. Use the Server Threat Library as a checklist against a representative production server. For each technique it catalogs, ask whether the binary it abuses actually needs to run on that host. Most of the time the answer is no, and you have just found a piece of attack surface you can close without a single patch.
Check whether the concentration pattern holds in your own estate. Run the numbers on one production environment: total CVE exposure against the known-exploited and ransomware-flagged subset. Missing Patches shows the pattern we see across the estates we monitor, and it is a fair bet yours looks similar. If the urgent slice is a small, specific fraction of the whole, you have a smaller real backlog than the dashboard number suggests, and a much clearer place to start.
Where enforcement fits
When the interval to a working exploit is shorter than the interval to a deployed patch, the exposure is structural. It is not a diligence failure, and no amount of patching faster fully closes it, because some systems cannot take a maintenance window and some vulnerabilities have no vendor fix at all.
This is where known-good enforcement has a defined role. Enforcement constrains what an exploit can do on a protected host by holding that host to its approved operational behavior. It does not remove the vulnerability, and it does not replace patching where patching is available. It covers the interval, and it covers the end-of-life platforms and third-party software where no patch is coming. The three pages describe the exposure honestly; Virtual Patching is how we address the interval they measure. The disclosure-to-exploitation window is the reason the interval matters.
The industry named the same gap
This is not only our framing. On August 27, 2026, OpenAI published an open letter on collective cyber defense signed by more than 100 organizations, including Anthropic, Microsoft, Google, AWS, CrowdStrike, Palo Alto Networks, and Visa. One of its principles reads: where a system cannot be patched without disrupting essential services, apply and verify compensating controls. That is more than a hundred organizations putting their names to a description of the gap these pages measure, and to the response it calls for.
The conclusion
The vulnerability list will keep growing. The required-action list will stay short. When exploits arrive faster than patches ship, the teams that do well are the ones that prioritize by what an attacker has to do on the host, close the trusted-binary surface they already control, and treat the urgent, concentrated slice of their exposure as the real backlog. The three pages are built to be used exactly that way, whether or not you ever contact us.
Frequently asked questions
What is living off the land on a server?
+Living off the land is an attack technique that abuses trusted, signed binaries already installed on a system instead of dropping new malware. On servers, tools like PowerShell, WMI, certutil, and regsvr32 are legitimate administrative utilities, which is exactly why attackers use them to run code, move data, and stay resident without triggering signature-based detection. Because a server runs a narrow, predictable software set, the binaries that should execute on it are a short list.
Why do server attacks differ from endpoint attacks?
+A laptop runs a wide, changing range of software, so unusual behavior blends in. A production server runs a narrow, stable set, so the gap between what should execute and what can execute is both smaller and more definable. That predictability is a defensive advantage most teams never use. The same living-off-the-land technique that hides easily on an endpoint stands out far more clearly against a server's known-good baseline.
How should I prioritize remediation when the CVE list is unmanageable?
+Stop ranking by raw CVE count and rank by required action instead. An exploit generally has to write, load, modify, or elevate something on the host to succeed, and that list stays short even as the vulnerability count grows. Grouping findings by which of those actions they enable produces a shorter, more stable top of the queue than CVSS score alone, and it concentrates effort on the exposures that actually let an attacker act.
What actions does an exploit require on a host?
+To succeed, an exploit generally has to do one of a few things: write a file, load code, modify a protected resource, or elevate privilege. The specific vulnerability changes constantly, but the underlying actions do not. This is why tracking required actions produces a short, stable list while tracking vulnerabilities individually produces one that grows faster than any team can remediate.
What is the CISA Known Exploited Vulnerabilities catalog?
+It is a catalog maintained by CISA of vulnerabilities confirmed to be exploited in the wild, with a flag identifying those linked to ransomware campaigns. It is more actionable than a raw vulnerability feed because it reflects real-world exploitation rather than theoretical severity. Reading it by required action, rather than vulnerability by vulnerability, turns a growing list into a short set of things an exploit must accomplish on a host.
What does observed vulnerability exposure mean?
+Observed exposure means a finding based on the software actually present on disk, read directly and matched to CPE entries, rather than a finding taken from an inventory system's record of what should be installed. It is then compared against NVD CVE data and CISA known-exploited status. Observed data catches drift between what an organization believes is deployed and what is actually running, which is where a lot of real exposure hides.
Why does patching faster not close the gap?
+Because when a working exploit exists before a patch is deployed, the exposure is structural rather than a diligence failure. Some systems cannot take a maintenance window, some run end-of-life software with no vendor fix coming, and the disclosure-to-exploitation interval keeps compressing. Patching remains essential, but faster patching alone cannot cover the interval between a public exploit and a deployed fix on every system.
What is a compensating control?
+A compensating control is a measure that reduces the risk of a vulnerability without removing the vulnerability itself, used when patching is not immediately possible. The August 27, 2026 collective cyber defense open letter, signed by more than 100 organizations, calls for exactly this: where a system cannot be patched without disrupting essential services, apply and verify compensating controls. The verify step matters: a compensating control you cannot demonstrate is not a control you can rely on.
Does enforcement replace patching?
+No. Enforcement constrains what an exploit can do on a protected host, but it does not remove the underlying vulnerability and it is not a substitute for patching where a patch is available. The two address different parts of the problem. Patching eliminates the flaw when a fix exists and can be deployed; enforcement covers the interval before that happens and the systems where no fix is coming at all.
What software is riskiest on a production server?
+Rarely the software anyone is thinking about. The highest-risk exposure is usually a component installed nearly everywhere and owned by no one, a virtualization guest agent or a legacy runtime that sits on every host outside any single team's remit. Because it is ubiquitous and unowned, it drifts out of patch cycles quietly, which is what makes it both easy to overlook and valuable to an attacker.
