On June 10th CISA released its Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk.The Directive is targeted at Federal Civilian Executive Branch agencies and replaces CVSS-score-based deadlines with KEV based tiered remediation timelines of 3, 14, or 60 days.
The criteria for the tiering is:
- Asset Exposure: Is the vulnerable asset publicly exposed?
- KEV Status: Is the vulnerability, as identified by a common vulnerabilities and exposures identifier (CVE ID), on CISA’s Known Exploited Vulnerabilities Catalog?
- Exploit Automation: Is an adversary able to automate all the steps necessary to exploit the vulnerability?
- Technical Impact: Does an adversary gain partial control or total control of the vulnerable asset after exploitation of the vulnerability?
We've known for some time now that the CVSS score is a poor way of prioritizing patching. There is no risk calculation, the base score is skewed towards the higher numbers, and the sheer number of them per month is impossible for most organizations to safely test and deploy.
The NVD shows 4160 vulnerabilities per month in 2025 and over 32,000 released this year already (1). The KEV list looks small in comparison, but there are currently over 1600 entries in the KEV list with an average of around 20 additions per month.
While this is a move in the right direction, it still doesn't answer the underlying problem of agencies being able to patch within the three-day cycle. A lot of agencies are just not staffed for it, and who wants to be responsible for bringing down production and causing a monetary loss if one of these goes wrong.
For years I've advocated for a risk-based patching approach, taking into consideration factors like:
- Is the exploit in the wild
- Is the exploit being actively used
- Is the asset exposed publicly or near a trust boundary
- The assets' criticality
- What does the attack path look like and does the system have a wide or deep attack path to other assets or administrative accounts/systems, critical systems, etc.
- How does the vulnerability’s risk compare to other risks such as configuration risks, open services, etc.
And in case you're not already scared, now we have the additional threat of AI models developing vulnerabilities even more rapidly and chaining vulnerabilities together.
So what can we do now?
Any organization’s strategy (whether under this directive or not) for managing vulnerabilities is going to depend largely on their specific requirements and landscape, but in general - and my opinion.
- Get comfortable auto-patching workstations, with regular reboots
- Auto-patch browsers
- Manage apps and browser extensions and reduce and consolidate
- Know your assets and your attack surface, especially public facing
- Know your configuration standards and harden systems
- Constantly re-prioritize your truly “Critical” issues to address if you are falling behind
- Keep authentication and access in the mix to reduce your attack surface
- Start from the publicly accessible assets and assets on the edge of any trust boundaries
- Ensure management knows the risks and tradeoffs and why it is important-quantify the risk if possible
