That discrepancy does not make the defensive guidance irrelevant. It does mean security leaders should separate CISA’s actionable instructions from its broad threat framing. The campaign packages several existing federal initiatives into a concise checklist aimed at water, wastewater, energy, transportation, health care, public safety, and other operators whose outages have immediate consequences.
For Windows and enterprise IT teams, the useful change is not a new patch or a new product requirement. It is a sharper operating model: know which internet-facing systems you own, stop treating unsupported perimeter appliances as normal technical debt, and make recovery an exercised capability rather than a document stored on a file share.
CISA’s three-part message rests on existing directives
CISA’s campaign groups its recommendations under three verbs: reduce vulnerabilities, replace end-of-support devices, and recover quickly after an incident. The agency points federal civilian agencies to Binding Operational Directive 26-04 for risk-based security-update prioritization and to Binding Operational Directive 26-02 for removing or replacing unsupported edge devices.
BOD 26-04, issued June 10, changes how federal civilian executive branch agencies are expected to decide what gets patched first. Rather than organizing remediation solely around a vulnerability’s severity score, CISA directs agencies to weigh exposure, inclusion in the Known Exploited Vulnerabilities catalog, exploitation automation, and the likely technical impact after compromise. It supersedes BOD 19-02 and BOD 22-01, according to CISA’s announcement.
The distinction matters for administrators because a high-severity flaw buried behind segmentation is not operationally equivalent to a remotely exploitable VPN, firewall, router, identity gateway, or web application exposed to the internet. CISA’s framework formalizes that common-sense priority for federal agencies: identify assets, understand exposure, and move first on vulnerabilities attackers can realistically use.
Private operators, state and local governments, and commercial enterprises are not directly bound by BOD 26-04. CISA presents the directive as a model other organizations can adopt, but that is encouragement, not a new mandate. The campaign’s language blurs that line slightly by putting federal directives beside advice for every organization; IT leaders should not confuse a federal compliance deadline with a general recommendation.
Still, the method is worth adopting. A Windows-focused environment should be able to answer, quickly and with evidence, whether an affected product exists in its estate; whether it is externally reachable; whether it is a domain controller, remote-access gateway, management server, hypervisor, backup platform, or operational-technology support system; and whether the organization has signs of prior compromise before applying a fix.
That last point is important. Patching closes a route in, but it does not evict an intruder who entered before the update. CISA’s BOD 26-04 implementation materials require federal agencies, in designated circumstances, to assess whether compromise occurred before remediation. Many private-sector patch programs still measure success as a percentage of closed tickets. For an exposed, actively exploited vulnerability, the more meaningful closure criterion is: patched, investigated, credentials reviewed, persistence checked, and monitoring increased.
Unsupported edge devices are the campaign’s clearest operational warning
CISA’s “replace” pillar focuses on end-of-support devices, particularly equipment at the network edge. That includes appliances and services such as VPN gateways, firewalls, routers, load balancers, remote-management platforms, and other externally reachable systems that connect internal Windows networks to outside users and services.
The companion CISA, FBI, and U.K. National Cyber Security Centre fact sheet issued in February is explicit: end-of-support edge devices are attractive entry points because vendors no longer investigate defects or deliver security patches. An unsupported appliance can provide attackers a foothold into otherwise modern and patched Windows environments. Replacing Windows 11 PCs while leaving a retired VPN concentrator exposed on the public internet is therefore not a meaningful reduction in organizational risk.
BOD 26-02 applies to federal civilian executive branch agencies, but its central expectation is broader than government: lifecycle management needs to be an ongoing security function. Organizations need an inventory that includes hardware model, firmware or software version, owner, internet exposure, support-end date, replacement plan, and business dependency. Most asset inventories have some of those fields. Too few have all of them accurate enough to guide a rapid decision during an active incident.
CISA also calls on software producers to publish lifecycle information in machine-readable forms such as OpenEOX. That is a useful long-term objective, but it does not solve the immediate inventory problem inside most organizations. Machine-readable lifecycle information only helps if procurement, CMDB, endpoint-management, network-discovery, and vulnerability-management records can associate an actual deployed asset with a product and version.
For IT administrators, the immediate work is less glamorous:
- Remove direct internet exposure from operational technology controllers, management interfaces, and appliances wherever the business process permits it.
- Identify unsupported edge devices before an attacker identifies them through internet scanning.
- Replace a device that has no credible vendor support path instead of trying to compensate indefinitely with compensating controls.
- Restrict remote administration through hardened gateways, strong identity controls, and phishing-resistant multifactor authentication rather than leaving device administration publicly reachable.
- Preserve configuration backups, licenses, and replacement documentation so an emergency migration is possible without rebuilding institutional knowledge during an outage.
The final point is often overlooked. “Replace” is not simply a purchasing action. A firewall, VPN appliance, domain service, or industrial workstation can remain in place after support ends because no one knows every integration, certificate, account, routing exception, or vendor-maintenance dependency attached to it. That uncertainty is itself a security finding. It should be documented and reduced before a crisis forces the replacement.
Recovery guidance is moving toward keeping vital operations alive
CISA’s recovery pillar centers on CI Fortify, an initiative intended to help critical-infrastructure operators maintain essential operations and restore systems after a serious cyber incident. In July, CISA, the FBI, Australia’s Cyber Security Centre, and other partners published CI Fortify guidance on isolating vital operational technology and enabling systems during a crisis.
The guidance emphasizes identifying critical assets and connections, creating separation points, planning graduated isolation actions, and testing those plans. The stated preference is physical isolation of vital systems where feasible, with temporary network isolation measures as a fallback for organizations that cannot achieve full separation.
This is more specific than the usual advice to “have backups.” Backups are necessary, but they do not keep a water-treatment process, hospital service, transport operation, or public-safety dispatch function running while a compromised identity system, remote-access service, or corporate network is being investigated. Recovery planning has to account for which systems must remain available, who can operate them with normal IT services unavailable, and what can be disconnected without causing the operational outage the attacker was seeking.
The recent focus is grounded in real pressure on operational technology. In July, CISA, the FBI, EPA, and other U.S. partners updated guidance on Iranian-affiliated actors targeting programmable logic controllers across U.S. critical infrastructure. CISA’s July 28 CI Fortify release also warned that state-sponsored actors increasingly target critical infrastructure for pre-positioning, meaning access may be obtained well before a disruptive event.
For Windows administrators supporting operational environments, the recovery plan should include more than file-level backups and bare-metal images. It should define offline or segregated identity recovery, tested restoration of Active Directory dependencies, authoritative copies of device configurations, break-glass procedures that do not rely on a compromised single sign-on service, and communications channels that still work when corporate email and collaboration tools do not.
A recovery point objective without a recovery procedure is only a target. Organizations should test whether they can restore a required Windows server, privileged access path, line-of-business application, network configuration, or operational engineering workstation within the stated time—and whether staff can do so using records that remain available during an incident.
The CVE claim needs a correction, not repetition
CISA’s page attributes a faster threat environment partly to artificial intelligence and says that, by August 2026, the number of vulnerabilities added to the CVE database had already exceeded the entire 2025 total. The CVE Program’s public metrics do not support that statement as written. They listed 15,176 CVE Records for 2026 and 48,244 for 2025 at the time of review.
NIST has independently reported rapid growth in CVE submissions, saying submissions in the first quarter of 2026 were nearly one-third higher than the same period a year earlier and that submissions rose 263 percent between 2020 and 2025. That supports the general argument that defenders face a growing volume of vulnerability information. It does not validate the campaign page’s specific claim that 2026 had already overtaken 2025 by August.
CISA may be using a different count, cutoff, or definition of “added to the CVE database,” but the page does not explain one. Until the agency provides that methodology, readers should treat the comparison as unsupported. Security planning does not need an inflated statistic to justify prioritization: NIST’s own account of record growth and CISA’s focus on exploited, exposed systems already make the operational case.
The larger risk is not that organizations fail to read every new CVE. It is that they cannot identify which vulnerabilities affect systems they own, whether those systems are reachable, and whether an attacker has already used them. CISA’s campaign is most valuable when it drives that discipline—inventory, exposure reduction, lifecycle replacement, and exercised recovery—rather than when it becomes another awareness-month checklist.