CISA will discontinue its weekly Vulnerability Bulletin on September 28, 2026, ending a familiar digest that many security teams used as a predictable list of newly recorded CVEs. In a September 16 notice, the agency said the move is part of a broader shift away from severity-led vulnerability management and toward a risk-based model tied to real exposure, active exploitation, and business impact.
That matters because the bulletin was never just another newsletter. For many defenders—especially teams without deep automation—it was a weekly discovery layer: CVE ID, affected product, publication date, severity, CVSS score, description, and patch information when available, all in one place. When that disappears, visibility does not disappear with it, but the work of assembling it moves back onto the organization.
The question most readers are really asking is straightforward: if CISA stops publishing the weekly list, what should replace it—and how do you keep “risk-based” from becoming shorthand for “we’ll get to it later”?
What ends on September 28 — and what does not
The first point is to separate the sunset from the surrounding vulnerability ecosystem. CISA is ending the weekly CVSS-oriented summary, not the underlying records or the broader alerting machinery around them. The CVE program continues. CISA’s Known Exploited Vulnerabilities Catalog continues. CISA Cybersecurity Alerts and Advisories continue. Vendor security notices continue.
What changes is the operating model. Instead of one government-produced weekly digest that treated newly published CVEs as the main unit of attention, CISA is pushing subscribers toward several inputs that need local context before they become a remediation queue.
For federal civilian executive agencies, that is more than a messaging change. CISA says the shift aligns with Binding Operational Directive 26-04, issued June 10, 2026. The directive tells agencies to prioritize remediation using four factors: asset exposure, KEV status, exploit automation, and post-exploitation technical impact. It also requires agencies to identify publicly exposed assets, maintain scanning access, attest quarterly to exposed IPs and domains, and, in designated cases, check whether an attacker compromised an asset before patching it.
Private companies are not automatically bound by that directive. But the logic behind it is hard to ignore. CVSS can describe the severity of a vulnerability. It cannot, by itself, tell you whether your organization actually runs the affected software, whether that system is internet-facing, whether exploit activity is established, or whether compensating controls already reduce the practical risk.
Why some teams will miss the bulletin
CISA’s argument for the change is sensible on its face. A flat stream of vulnerabilities can overwhelm analysts, and a medium-severity flaw on an exposed identity system may deserve faster action than a critical issue on an isolated, unused asset. KEV status and exposure often answer the operational question more directly than severity alone.
But the bulletin solved a real problem: it was simple. Teams with thin staffing could watch one predictable feed and make a first pass without building an ingestion pipeline across multiple sources. Replacing that with KEV, CISA advisories, CVE records, vendor notices, and internal asset data is a better model in theory, but it can demand more integration work, more tuning, and sometimes tooling that smaller organizations do not have.
That is why the practical replacement should not be “subscribe to everything” and hope for the best. It should be a repeatable workflow.
A workable replacement playbook
Start with the one input the weekly bulletin could never provide: an authoritative inventory of what you actually expose. At minimum, security teams need a maintained view of internet-facing assets, key internal systems, owners, business criticality, and whether they can scan those systems consistently. Without that, a richer set of feeds can still produce a poorer outcome, because the organization cannot tell which notices apply to which real assets.
Next, keep four external streams in view: the KEV Catalog, CISA advisories, CVE records, and the security advisories published by the vendors you actually run. There is no single-feed substitute for the old bulletin because the right inputs depend on your technology stack and staffing. The goal is not to mirror the bulletin’s old format. It is to make sure new vulnerability information reliably lands in a queue that can be matched against your environment.
Then triage each applicable issue through questions that mirror BOD 26-04. Is the affected asset publicly exposed? Is the vulnerability listed in KEV? Is there evidence of exploit automation or other signs that exploitation is becoming easier to scale? If the flaw is exploited, what is the likely post-exploitation impact on this system? Those questions are more useful than a score alone because they force a team to connect the vulnerability to the asset and the likely attacker path.
That still does not mean lower-severity work can be ignored. Risk-based prioritization only holds up if deferrals are explicit, time-bound, and reviewable. A team should document why an item is not first in line, what compensating controls exist, when it will be revisited, and what change in exposure would move it up. Otherwise, “risk-based” becomes a backlog management slogan rather than a control discipline.
The next step is patch governance, not just patch scheduling. For each item accepted into remediation, set a test window, assign ownership, and define how the organization will verify that the patch or mitigation actually landed where intended. If a patch cannot be applied quickly, record the compensating controls in place and who approved the exception.
CISA’s directive adds another operational point that many private-sector teams should consider even though they are not required to follow it: in some cases, patching is not the end of the job. If a vulnerability affects an exposed asset and the circumstances suggest likely intrusion, the team may need to check whether the system was already compromised before or after remediation. Closing the hole is different from determining whether someone already came through it.
For buyers and operators, the real lesson is that September 28 is not a disappearance of vulnerability information. It is the end of a convenient packaging layer. Teams that depended on that layer should use the next few days to replace a weekly reading habit with a pipeline: subscribe to the surviving feeds, map them to exposed assets, record exploit evidence and compensating controls, verify remediation, and keep a human review path for business-critical exceptions.
The organizations that handle this change well will not be the ones that chase every new CVE equally. They will be the ones that can explain, for every important vulnerability, whether they are exposed, how they know, what they did about it, and what they chose to defer—on purpose, with dates attached.
By
By
By
By
By
By
