CISA Cut Patch Deadlines to Three Days. NIST Cut the Score You'd Use to Pick Them.
November 9, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Two federal decisions, arriving within months of each other, quietly ended the idea that a government source will score your vulnerabilities and tell you what to patch first. CISA now requires federal agencies to fix the riskiest flaws in three days under a new four-factor model, while NIST has stopped automatically enriching most new CVEs with severity scores at all. If your patch queue still runs on "wait for the CVSS number," both changes just removed the ground it stood on.
What did CISA actually change about patch deadlines?
CISA's Binding Operational Directive 26-04, described in the agency's own Patch Smarter, Not Harder announcement, replaces the prior one-size-fits-all remediation clock with a tiered model built on four risk factors. The agency found that the greatest risk comes from vulnerabilities that combine public exposure, presence on the Known Exploited Vulnerabilities catalog, the ability for an attacker to fully automate exploitation, and the chance of full or partial system control after exploitation.
Vulnerabilities hitting three or more of those four criteria now carry a three-day remediation window, a sharp compression from the roughly two-to-three-week deadlines federal agencies previously worked against, as Forrester analyst Erik Nost told TechTarget. Lower-risk flaws get longer timelines, and some are explicitly allowed to wait until the next system upgrade. In CISA's own pilot at one large civilian agency, that meant only about 1% of vulnerability instances fell into the urgent three-day bucket, while more than 60% qualified for deferral, according to CSO Online's reporting on the briefing.
That split is the real story. CISA is not asking teams to patch faster across the board. It is asking them to sort vulnerabilities into tiers using a defined model, then move fast on a small slice and consciously defer the rest. BOD 26-04 technically binds only federal civilian agencies, but CISA explicitly encourages broader adoption of risk-based remediation, and the logic behind it, tying urgency to exposure, exploitability, and impact rather than a flat severity number, applies just as well inside a private-sector vulnerability management program.
Why did NIST stop scoring most new CVEs?
NIST made the second change for a blunter reason: volume. In its own announcement explaining the shift, NIST stated that CVE submissions increased 263% between 2020 and 2025, and that even after enriching nearly 42,000 CVEs in 2025, 45% more than any prior year, the backlog kept growing. Rather than keep promising full coverage, NIST moved to a narrower enrichment criteria set and began labeling everything else "Not Scheduled."
That status is not a minor technicality. A CVE marked Not Scheduled gets no NIST-assigned severity score, no product mapping, and no structured enrichment data until someone specifically requests it, as Help Net Security's coverage of the announcement lays out. For years, the National Vulnerability Database's CVSS scores functioned as the default triage signal most organizations leaned on, whether they realized it or not. That default coverage is now gone for the majority of newly disclosed vulnerabilities, leaving teams to either build their own scoring pipeline or accept a widening gap in the data their tools depend on.
Put the two changes side by side and the pattern is unmistakable. The federal government is stepping back from being the single authority that tells you both how bad a vulnerability is and how fast to fix it. CISA's directive replaces a fixed clock with a model you have to apply yourself. NIST's enrichment cutback removes the free severity score that model, and most commercial scanners, used to lean on by default.
What a risk-based model actually requires instead of a score
A four-factor model only works if someone in the organization can answer each factor correctly for every new vulnerability, and that is a harder operational problem than it sounds. According to Security Boulevard's breakdown of BOD 26-04, the directive maps all sixteen possible combinations of its four binary variables to five separate remediation tiers, with the highest tier also requiring forensic triage to determine whether exploitation already happened before the patch went in. That is a meaningfully different skill set than reading a CVSS number off a scanner report.
Answering those four questions in practice means a team needs, at minimum:
- An accurate, current asset inventory that flags what is internet-facing and what sits behind segmentation, because exposure is one of the four variables and most organizations cannot answer that cleanly today.
- A live feed into the Known Exploited Vulnerabilities catalog and exploit-maturity signals like EPSS, rather than a wait-and-see posture toward NVD enrichment.
- A documented process for judging post-exploitation impact, meaning whether a flaw hands an attacker full control or something more limited, which requires actual technical analysis of the vulnerability rather than a lookup.
That combination of asset awareness, threat intelligence consumption, and vulnerability analysis is close to a direct description of what a SOC analyst is expected to do day to day, and it maps closely onto the domains covered in CompTIA's CySA+ certification, which centers on vulnerability management and threat detection as practiced skills rather than theory. If your current process still assumes a government database will hand you a severity score on schedule, that assumption needs replacing before the next audit, not after.
How should a security team respond right now
Start by auditing what your current patch cadence actually depends on. If prioritization decisions trace back to an NVD CVSS score as the primary input, map how many of your open vulnerabilities already carry a "Not Scheduled" label and have no NIST-assigned severity at all. That number is likely larger than most teams expect, and it only grows from here.
Next, build or adopt a layered signal approach instead of a single score. Teams that already combine the KEV catalog, exploit prediction data, and internal asset criticality into one view are far closer to compliant with CISA's model than teams still running CVSS-only triage. This is also where documentation earns its keep: auditors and insurers increasingly expect a written rationale for why a vulnerability was deferred, not just evidence that critical ones were patched. The curriculum overview in Forge University's certification resources walks through how vulnerability management, threat intelligence, and incident response fit together as one operational discipline rather than separate checklists, which is useful context if you are rebuilding a program from scratch.
Finally, treat this as a staffing gap, not just a process gap. A risk-based model with sixteen possible tier combinations is not something a junior analyst can run from memory, and it is not something a single annual training session fixes. If you want a study plan built around this kind of risk-based vulnerability triage, you can start training whenever you're ready, since the exam objectives behind CySA+ and the operational skills CISA is now demanding line up more closely than most job postings make explicit.
The part that will not show up in a press release
Neither CISA's directive nor NIST's enrichment cutback is framed as a staffing story, but that is what both amount to in practice. A fixed federal deadline and an automatic CVSS score both functioned as guardrails that let under-resourced teams default to simple rules. Remove both guardrails at once and the organizations left exposed are the ones that never built the analytical capability behind them, only the habit of following them.
That gap will surface first in audits, then in cyber insurance underwriting, and eventually in incident postmortems where the question becomes why a known-exploited vulnerability sat unpatched despite meeting none of the old urgency triggers. The agencies and vendors driving this shift are not going to reverse course because the transition is inconvenient. The organizations that adapt fastest will be the ones that already have people who can run a four-factor risk model without waiting for someone else to score it for them first.