The Vulnerability Surge Is Real: What It Means for Staffing, Tooling and FedRAMP's New VDR/VER Rules
Ask anyone running continuous monitoring for a FedRAMP-authorized cloud service offering right now how their open vulnerability count is trending, and “flat” is not the answer you’ll get. Across our Continuous Monitoring (ConMon) and advisory engagements, we’ve observed active vulnerability counts climb by double or triple digits, month over month, since roughly May of this year. Translated to real world examples, that’s 100 more vulnerabilities sitting open at the end of the month, every month. A program running around 300 active vulnerabilities in May looked closer to 400 in June, 500 in July, and 600 in August.
This isn’t an isolated story, and it isn’t just Fortreum noticing. It shows up in the volume of CVEs published industry-wide, in the size of Microsoft’s own monthly patch releases, and in the CISA KEV catalog’s growth. The vulnerability management function most organizations built five or ten years ago wasn’t designed for this environment and the government has already begun rewriting its rules because of it. Here’s what the data shows, why it matters, and what we think needs to change in tooling, staffing, and how developers think about patching.
1. Industry-wide numbers are showing the reality
Reported vulnerabilities hit a ninth consecutive annual record in 2025, with roughly 48,000 CVEs published, a 20% increase over 2024’s approximately 40,000 (CVE.org). FIRST.org’s mid-year forecast update, published in June, revised its full-year 2026 projection upward to roughly 66,000 CVEs. This is 46.3% above their original estimate and points to AI-assisted vulnerability discovery tools, including Anthropic and OpenAI’s latest versions, as a major driver of the acceleration, alongside a structural expansion of CVE-issuing bodies. For example, GitHub Security Advisories (GHSA) volume is up 449% year over year and VulnCheck is up over 3,000% (FIRST.org).
2. Microsoft’s own release cadence tells the same story
If you want a single, well-documented proxy for how much the patching workload has grown, Microsoft’s monthly Patch Tuesday cadence is a good one. Microsoft patched 1,009 CVEs across all of 2024. In 2025, that rose to roughly 1,130, a 12% increase, making it the second year in a row over 1,000 (Tenable, 2025 Year in Review). 2026 has broken that pattern entirely:
| Month (2026) | Microsoft CVEs patched | Note |
| January | 114 | Typical seasonal uptick after a quiet December |
| February | 59 | Nearly in-line with 2025 |
| March | 82 | Spiking beyond 2025 numbers already |
| April | 164 | Another large spike beyond 2025’s April |
| May | 130 | Normal relative decrease, but still far beyond 2025’s May |
| June | 206 | New single-month record, up from the prior record of 172 set in October 2025 |
| July | 622 | New record again, larger than the three previous months combined |
| August | 415 | Framed by outlets as a “smaller” month relative to July, yet still far above 2025’s 107 |
Sources: CrowdStrike
For scale: a Patch Tuesday of 150–175 CVEs was considered unusually large as recently as late 2025. In 2026, that volume is a below-average month. As one Ivanti security executive put it when June’s release nearly tripled the previous record, the industry isn’t approaching a “patch apocalypse”, it’s already in one (Ivanti). Researchers across the industry now expect 100+ CVE months to be the new floor, not the ceiling, for the rest of 2026 and beyond.
3. KEVs are on the rise, too
CISA’s Known Exploited Vulnerabilities catalog is the closest thing the industry has to a “these are actually being used against you right now” list, and its growth has its own history. The catalog launched in November 2021 with 311 entries. After an initial spike in 2022, per-year totals reset, but have been on the rise and recent trends do not show this trajectory changing.
| Year | KEV entries added | Cumulative total |
| 2021 (launch) | 311 | 311 |
| 2022 | 555 | 866 |
| 2023 | 187 | 1,053 |
| 2024 | 186 | 1,239 |
| 2025 | 245 | 1,484 |
2025’s 245 additions already represented a roughly 24% jump over the 2023-2024 average, but 2026 is on track to outpace even that.
| Month (2026) | KEV entries added |
| January | 17 |
| February | 28 |
| March | 26 |
| April | 31 |
| May | 21 |
| June | 23 |
| July | 26 |
| August (through Aug 28) | 29 |
| Total through August | 201 |
Month-by-month KEV additions this year show an average of roughly 25 new KEV entries per month, with the most recent months (26 in July, 29 in August) trending above that average rather than below it. Extending that trajectory across the remaining four months of the year puts 2026 on pace to add somewhere in the neighborhood of 300-320 new KEV entries, which would make 2026 the second-largest single-year jump in the catalog’s history, trailing only its 2022 growth spurt, and a meaningful step up from 2025’s 245. While this is a trend projection, it’s also important to note that it’s based on CISA’s own published data, and it directly undercuts assumptions that the “actionable” subset of vulnerabilities is staying flat while only the noisy top-line CVE count grows.
4. The status quo won’t hold
The patterns shown here reflect what OpenAI’s recent publication shows and what a coalition of more than 100 technology, security, and AI companies are describing in the open letter calling for a coordinated surge in cyber defense (OpenAI, “A call for collective action on cyber defense”). Its first and arguably most important point: the status quo isn’t going to hold. Years of accumulated unpatched software, misconfigurations, excessive permissions, weak authentication, and plain technical debt have left critical systems exposed, and security teams, especially the ones protecting critical infrastructure, have been chronically under-resourced for the scale of what they’re now facing.
5. What actually has to change
Most vulnerability management programs, as currently staffed and tooled, are unable to absorb this rate of growth by working harder within the same structure. The scale is unsustainable. Three things need to move, and realistically all three need to move together.
Tooling. The scan-monthly, report-monthly model was built for a world where the backlog grew slowly and CVSS score alone was a workable proxy for priority. That world is gone. Programs need to move toward continuous, exploitability-weighted triage, factoring in whether a finding is internet-reachable, whether it’s KEV-listed, and whether it’s realistically automatable, so that human analyst time gets spent on the genuinely dangerous subset of the backlog, not spread evenly across all of it. This is also, not coincidentally, exactly the direction FedRAMP and CISA have moved (more on that below). AI tools absolutely have an edge here and if your company isn’t looking into optimizing or even completely redoing their workflows with AI-input, the technical debt will only increase.
Staffing. There is a real argument for a substantial hiring push in security testing and vulnerability remediation roles specifically. This increase should focus on people whose job is to triage, validate, and fix the ever-increasing vulnerability count. You can have the best tooling in the world at your disposal, but if you don’t have the people to follow through with validation and remediation, you’ll end up with an increasing backlog.
How developers think about patching. The alternative, or, more realistically, the complement, to hiring more dedicated security remediation staff is shifting a meaningfully larger share of existing engineering time toward patching and vulnerability fixes, rather than treating it as work that happens after feature development. FIRST.org’s own analysis makes a related point: software maintainers (such as open-source maintainers) should expect to roughly double the work they’re doing in their release cycles, even if the live, day-to-day operational remediation burden for asset owners stays comparatively more contained. For a cloud service provider, that distinction mostly collapses, you are simultaneously the software maker and the system operator for your own service offering, so you inherit both sides of that equation. If organizations do shift developer time meaningfully toward patching, they need to be honest that this comes at a cost to feature velocity, and the organizations that want to hold both feature output and patch cadence steady will need to grow their engineering headcount to do it, not just reallocate the headcount they already have.
6. FedRAMP has answered the call: VDR and VER
If this all sounds a little familiar, it probably should. In June, FedRAMP published Public Notice NTC-0014, responding directly to CISA’s Binding Operational Directive 26-04, which reprioritizes federal vulnerability remediation around actual exposure, exploitability, and KEV status rather than CVSS severity alone. FedRAMP’s response is a pair of rulesets: Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER).
The mechanics are a significant departure from the legacy model:
- Vulnerabilities must be evaluated for internet-reachability and realistic exploitability, not just scored by CVSS.
- Beyond just reachability and exploitability, multiple other factors must be evaluated: Criticality, Detectability, Prevalence, Privilege, Proximate Vulnerabilities, and Known Threats.
- Under VER’s “assume it’s automatable” rule, providers must treat an exploit as automatable by default unless they can demonstrate otherwise.
- The legacy monthly-scan-and-report cadence is explicitly called out as insufficient; detection and evaluation timeframes now run in days, not weeks, scaled to the FedRAMP class of the system.
- POA&Ms, as a standalone FedRAMP artifact, are being phased out, replaced by rapidly available and machine-readable exports.
Both rule sets become mandatory for every cloud service offering obtaining or maintaining FedRAMP Certification effective December 7, 2026, with a grace period running through March 7, 2027. The FedRAMP PMO has stated that CSPs not meeting the December 7th deadline will be issued a PL-2 control finding, but not necessarily immediately placed on a corrective action plan (CAP), counter to FedRAMP’s NTC-0014 announcement. However, if a CSP is still missing support for both rule sets by March 7th, both a CAP and potential FedRAMP marketplace delisting is possible. In other words: FedRAMP isn’t asking CSPs to consider modernizing vulnerability management as a best practice, it’s making it a condition of keeping your authorization, on a fixed and fairly near-term clock.
What to do next
- Baseline your current trend now, not in November. If your active vulnerability count has been climbing month over month since the spring, plot it and understand your own trajectory before you’re forced to potentially explain it under a corrective action plan.
- Map your current scanning and ConMon process against the actual VDR/VER rule text. The gap between “we scan monthly and file POA&Ms” and what VDR and VER require is larger for most legacy Rev5 programs than it initially appears.
- Build or buy exploitability-aware triage tooling now, so every required evaluation factor is informing prioritization before December 7, not after.
- Make a deliberate staffing and workload decision. Decide, explicitly, how much of the coming remediation load will be absorbed by new tooling, new headcount, and reallocated developer time. Budget for the fact that it is very likely all three, not just one.
How Fortreum can help
This is exactly the intersection Fortreum works in every day: the technical reality of a vulnerability management program and the compliance framework it has to satisfy. As an accredited FedRAMP 3PAO with advisory and ConMon practices working alongside each other, we see both sides of this shift. The raw scan data climbing across the industry, and the new rulesets that now govern how that data has to be evaluated and reported, are not going away.
Our advisory team helps CSPs right-size the combination of tooling, staffing, and process changes this moment actually requires. Kovr, our AI-native compliance automation platform, turns that vulnerability and gap data into managed action, centralizing vulnerability and POA&M management, assigning ownership, tracking remediation progress, and maintaining risk visibility across your program, with continuous monitoring support that keeps findings and evidence current between formal reviews. And separately, through a distinct engagement, our 3PAO team helps CSPs prepare for and pass the assessments that confirm the work is done.
If you’re trying to figure out where your program stands against VDR and VER, or whether your current vulnerability management staffing and tooling can absorb where your numbers are heading, our team is happy to talk it through.
