Where patch posture data comes from, which threat intelligence is worth using, and how to put the two together.
1. The problem
A vulnerability management program can be a delicate balance. On one side, a Defender view of a mid-sized tenant can show thousands of missing updates and open CVEs (Common Vulnerabilities and Exposures) across devices and installed software, and the count resets upward every Patch Tuesday. On the other side, each patch consumes testing time and a maintenance window, sometimes a reboot, and occasionally a rollback when an update breaks something. It is difficult to close that gap in a month, and the next month there is always a new gap. The practical question is therefore not whether to patch but what to prioritize.
That default sort is CVSS (Common Vulnerability Scoring System) which can be a poor proxy for risk. CVSS scores what a vulnerability could represent under standardized assumptions, not whether anyone is using it. Joint research by the Cyentia Institute and FIRST found that only about 6 percent of published CVEs have ever been observed exploited in the wild [1], and VulnCheck counted 768 CVEs first exploited during 2024, around 2 percent of that year's publications [2]. The exploited ones do not cluster neatly at the top of the severity scale either: a joint Securin, Ivanti, CSW, and Cyware analysis of ransomware-linked vulnerabilities found 57 of them carrying low or medium CVSS scores that would deprioritize them [3]. Sort by CVSS and you could spend months patching things nobody attacks while some of the vulnerabilities ransomware crews actually use sit in the middle of your list.
The real job is joining two data sets: an inventory of what is deployed and missing, and evidence of what attackers are actually doing right now. This paper covers where both come from and what we learned combining them.
2. Getting the posture data
If devices are enrolled in Intune, the patch posture data already exists. Microsoft's management plane holds it, and the Graph and Defender APIs expose it. Nothing new needs to be installed on the endpoints.
Three sources cover it:
- Defender for Endpoint: the threat and vulnerability management module reports, per device, which KB-level security updates are missing and which CVEs the device is exposed to. It is computed on the endpoint by the Defender sensor rather than inferred from version strings.
- Intune: the managed-device inventory (OS build, last sync, ownership) plus the detected-applications inventory, which lists what software is actually installed across the fleet. Third-party software gets patched on its own cadence, or not at all, so the app inventory is where a lot of the real exposure hides.
- Windows Update policy: update rings, update profiles, and Autopatch deployments. Posture tells you what is missing; policy tells you whether the thing that is supposed to be fixing it is even pointed at the right devices. An update ring with no assignments looks perfectly healthy until you check.
Reading the management plane instead of deploying agents means measurement costs nothing to roll out. Coverage is simply Intune coverage. That cuts both ways: a device Intune does not manage is a device this method cannot see, and you need something else for those.
3. The intelligence sources
Posture answers what is missing, these sources answer which of it matters. Several deliberately overlap, which turns out to be useful when one of them lags or goes down.
MSRC
Microsoft publishes machine-readable security update data (the CVRF documents) mapping each update to the CVEs it fixes, with severity and the Exploitability Index [4][5]. The index is Microsoft's own call on whether exploitation is detected or likely, and since nobody has better Windows telemetry than Microsoft, an "exploitation more likely" rating is worth acting on. It is often available on Patch Tuesday itself, before the public feeds catch up.
CISA KEV
The Known Exploited Vulnerabilities catalog only lists CVEs with confirmed in-the-wild exploitation [6]. That makes it the highest-precision free signal there is. If it is on KEV, the argument about whether it is theoretical is over. Entries carry remediation due dates under Binding Operational Directive 22-01 [7], which bind U.S. federal agencies and make a defensible SLA for everyone else, plus a flag for known ransomware use.
EPSS
Exploit Prediction Scoring System (EPSS), from FIRST.org, estimates the probability a CVE gets exploited in the next 30 days, updated daily [8]. KEV is retrospective, while EPSS is the forward-looking complement. Its real value is ordering the big middle of the list, the thousands of CVEs that are not on KEV, where a 40 percent probability and a 0.04 percent probability deserve very different treatment even when the CVSS scores are identical.
CISA SSVC
Stakeholder-Specific Vulnerability Categorization (SSVC) decision data, published into the MITRE CVE records through CISA's Vulnrichment program [9], carries CISA's exploitation status (none, proof of concept, active) along with automatability and technical impact. An active status corroborates KEV and sometimes arrives first.
Public exploit evidence
A public working exploit changes the economics: the vulnerability stops requiring research capability and becomes available to anyone who can run a script. Two open sources make this visible. Nuclei templates [10] mean a CVE is detectable, and usually exploitable, at scale with a free tool. Public proof-of-concept indexes track exploit code as it lands on GitHub [11]. Either one on a CVE present in your environment is a good reason to move the patch up.
CIRCL
CIRCL (Computer Incident Response Center Luxembourg) runs a free CVE API with CVSS vectors, CWE (Common Weakness Enumeration) classifications, and descriptions, and its rate limits are generous enough for bulk enrichment. NVD (NIST National Vulnerability Database) would be the traditional choice here, but at 5 unauthenticated requests per 30 seconds [12] it cannot enrich a few thousand CVEs per scan, so CIRCL does that job instead.
VulnCheck KEV
VulnCheck maintains an exploited-vulnerability catalog that is a superset of CISA KEV [13]. It picks up CVEs with observed exploitation that CISA has not listed yet, and adds ransomware association, counts of independent exploitation reports, and links to exploit code. It needs an API token, so we treat it as an optional layer: the free feeds establish the baseline and VulnCheck widens the exploited set.
endoflife.date
End-of-life is a different kind of finding. Software past vendor support will never be patched again, so any vulnerability in it is permanent, and the gap can grow every month. The endoflife.date project publishes machine-readable support timelines for Windows and hundreds of third-party products [14].
Two things bit us here and are worth passing on. Windows support dates are edition-specific: build 22631 is Windows 11 23H2 for everyone, but it leaves support a full year earlier for Home and Pro than for Enterprise and Education [15], and the device inventory records the build, not the edition. Flag on the earliest date and you will tell an enterprise fleet its OS is dead a year early. The safe rule is to flag a build only when every edition shipping it is out of support. Second, some product feeds declare end-of-life as a bare boolean with no date. Treat that as "end of life", not "unknown", or those products silently never fire.
4. Why exploitation evidence should lead
CVE publication set another record in 2024: 40,009 published, a 38 percent jump over 2023 [16]. Against that, the fraction with observed exploitation stays in the low single digits: roughly 6 percent ever [1], and about 2 percent within a given year [2]. NIST's work on Likely Exploited Vulnerabilities draws the same picture from a different angle [17], as does VulnCheck's decade-long retrospective of exploitation [18]. Any signal that isolates that small fraction (KEV membership, an active SSVC status, a vendor exploitation index) concentrates your effort where it changes outcomes. Rank by exploitation evidence first, predicted exploitation second, exploit availability third, and raw severity last, and ten patches will generally buy more risk reduction than a hundred picked by CVSS. The same ordering turns a new Patch Tuesday release from a wall of updates into a short day-one list.
Ransomware association is the extreme case. Those CVEs are being used by crews whose whole model is fast, indiscriminate, and destructive, and for most organizations they should preempt the rest of the queue outright.
End-of-life findings do not slot into this ranking; they are a migration to plan rather than a patch to push. But they belong on the same report, because they are the findings that only ever get worse.
5. Engineering notes
A few things we learned building this:
- Download bulk indexes where they exist (MSRC CVRF, the KEV catalogs, EPSS batches), cache the assembled CVE index with a multi-week TTL, and save per-CVE queries for a bounded set of high-interest CVEs, meaning the ones that already show an exploitation signal. Enriching everything individually can run into rate limits.
- Fail open. Intelligence feeds are context, not the measurement. When a feed is down or throttling, proceed with what you have. A missing enrichment should degrade the ranking, never the inventory, and never the scan.
- Be a polite client: exponential backoff with Retry-After, and an explicit User-Agent. At least one CDN-fronted API in this set rejects requests with no User-Agent before auth even runs, and hands back an unexplained 403 that looks like a bad token.
- Let the sources overlap. MSRC exploitability, KEV, SSVC, and public exploit evidence confirm each other constantly. That redundancy is what keeps a feed's blind spot or outage from silently dropping the signal.
6. Making it a program
Joined and ranked, the data supports answers to the questions that actually get asked:
- How exposed are we? Affected endpoints over total managed endpoints, and vulnerable apps over total installed apps. Coverage ratios can be tracked month over month, raw finding counts cannot be compared to anything.
- What do we fix first? The exploitation-led short list. The top of it will be ransomware-linked and actively exploited items, and it will be short.
- How big is the job? Aggregate per-finding remediation-time estimates by category. Maintenance windows are planned in hours, not finding counts.
- What deadline applies? BOD 22-01 dates on KEV entries. Federal agencies have to meet them, everyone else can borrow them as externally defensible targets.
- Why does it keep coming back? Audit the update rings, profiles, and Autopatch deployments next to the device posture. Recurring gaps almost always trace back to a policy that is unassigned or misconfigured, not to devices mysteriously refusing patches.
- What changed this month? Each Microsoft Patch Tuesday drops into the same pipeline: rank the new updates by exploitation evidence the day they land and the month's must-do items surface immediately. The live version of that view is the Senserva Patch Tuesday tracker.
7. Implementation note
The approach in this paper is implemented in Siemserva by Senserva, a security advisor for Microsoft 365, Intune, Defender, and Entra ID. It reads the posture sources from section 2 through the Microsoft APIs, enriches with the feeds from section 3 including the edition-aware end-of-life handling, and reports the coverage, ranking, and effort metrics from section 6. The KB-to-CVE mapping behind the prioritization is browsable at senserva.com/patch-tracker.html, and each monthly release gets the same exploitation-first analysis on the Patch Tuesday page the day it ships.
What people are searching for right now
Search demand is the audience side of the same story: while the intelligence feeds above say what attackers are doing, these are the CVEs and Microsoft updates practitioners are actively looking up. The lists are rebuilt from live Google and Bing search data multiple times a day, so they are a running answer to "which patches is everyone else worried about this week?" The full ranking, threat signal blended with search demand, lives on the hottest CVEs and patches page and the Microsoft patch tracker.
- 1. CVE-2008-4250 High (Microsoft, actively exploited)
- 2. CVE-2007-3010 Critical (Alcatel, actively exploited)
- 3. CVE-2014-1761 High (Microsoft, actively exploited)
- 4. CVE-2026-45504 High (Microsoft)
- 5. CVE-2026-48282 Critical (Adobe, actively exploited)
- 6. CVE-2013-0631 High (Adobe, actively exploited)
- 7. CVE-2012-0151 High (Microsoft, actively exploited)
- 8. CVE-2019-0808 High (Microsoft, actively exploited)
- 9. CVE-2026-45503
- 10. CVE-2016-0151 High (Microsoft, actively exploited, ransomware-linked)
- 1. KB5094123 Critical (Windows 10 Version 1809 for 32-bit Systems, fixes 89 CVEs)
- 2. KB5094122 Critical (Windows 10 Version 1809 for 32-bit Systems, fixes 76 CVEs)
- 3. KB5093998 Critical (Windows 10 Version 1809 for 32-bit Systems, fixes 158 CVEs)
- 4. KB5002874
- 5. KB5094041
- 6. KB5094144 High (Microsoft Exchange Server 2019 Cumulative Update 14, fixes 8 CVEs)
- 7. KB5078883
- 8. KB5073724 Critical (Windows 11 Version 25H2 for x64-based Systems, fixes 73 CVEs)
- 9. KB5082417
- 10. KB5073696
References
- Cyentia Institute and FIRST, A Visual Exploration of Exploitation in the Wild (2024): about 6 percent of published CVEs observed exploited. Coverage: IT Security Guru and Tenable.
- VulnCheck 2024 exploitation trends: 768 CVEs first exploited in the wild in 2024, up 20 percent from 639 in 2023. Coverage: The Hacker News.
- Securin, Ivanti, CSW, and Cyware, Ransomware Spotlight Report 2023: 57 ransomware-associated vulnerabilities with low and medium CVSS scores; 76 percent of ransomware-exploited vulnerabilities discovered before 2020. Ivanti press release.
- Microsoft Security Response Center, Microsoft Exploitability Index. https://www.microsoft.com/en-us/msrc/exploitability-index
- Microsoft Security Updates API (programmatic CVRF access to security update and CVE data). https://github.com/microsoft/MSRC-Microsoft-Security-Updates-API
- CISA Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- CISA Binding Operational Directive 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities. https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
- FIRST.org, Exploit Prediction Scoring System (EPSS). https://www.first.org/epss/
- CISA Vulnrichment (SSVC decision points added to CVE records). https://github.com/cisagov/vulnrichment
- ProjectDiscovery Nuclei community templates. https://github.com/projectdiscovery/nuclei-templates
- PoC-in-GitHub (indexed CVE proof-of-concept code). https://github.com/nomi-sec/PoC-in-GitHub
- NVD Developers, Start Here: public rate limit is 5 requests per rolling 30 seconds without an API key. https://nvd.nist.gov/developers/start-here
- VulnCheck KEV. https://vulncheck.com/kev
- endoflife.date. https://endoflife.date
- Microsoft product lifecycle: Windows 11 Home and Pro vs Windows 11 Enterprise and Education (edition-specific end-of-support dates). Home and Pro and Enterprise and Education.
- Jerry Gamblin, 2024 CVE Data Review (40,009 CVEs published in 2024, a 38 percent increase over 2023). https://jerrygamblin.com/2025/01/05/2024-cve-data-review/ See also the CVE Program metrics page.
- NIST CSWP 41, Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.41.pdf
- VulnCheck, State of Exploitation: A Peek into the Last Decade of Vulnerability Exploitation. https://www.vulncheck.com/blog/state-of-exploitation-a-decade