Patch what attackers use: BOD 22-01 and the agency work queue

The week

On November 3, 2021, the Cybersecurity and Infrastructure Security Agency, known as CISA, the federal government’s civilian cyber defense agency, issued Binding Operational Directive 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities. A binding operational directive is a compulsory instruction CISA can give to federal civilian agencies. It is not a law for everyone, but for those agencies it is not optional.

Two terms matter. A vulnerability is a flaw in software or hardware that an attacker can use to get in, steal data or cause damage. A window latch that does not quite catch is the physical equivalent. A vulnerability is exploited when someone actually climbs through that window in the real world, rather than in a lab or a research paper.

The directive created a public catalog of vulnerabilities that CISA had evidence were being actively exploited. It launched with a few hundred entries. To be listed, a flaw needed three things: a public tracking identifier, reliable evidence of exploitation in the wild, and clear remediation guidance, such as a vendor update.

Federal civilian executive branch agencies had to remediate, meaning fix or otherwise neutralize, the catalog entries on set timelines. They had two weeks for vulnerabilities assigned identifiers in 2021 or later, and six months for older ones, unless CISA set a different date. (Publicly known vulnerabilities each receive a tracking identifier that includes the year it was assigned, which is how the two clocks were told apart.)

The scope was wide. It covered software and hardware on federal information systems, whether run on agency premises or hosted by a third party, including cloud services. Where a contractor or cloud provider ran the system, the agency still had to find the affected assets and get them fixed. National security systems and certain defense and intelligence systems were excluded. CISA said it would not grant waivers or exceptions. Where a system could not be updated, the directive’s guidance was to remove it from the network, isolate it or segment it.

Agencies also had to review and update their vulnerability management procedures within 60 days and report on their status. The procedures had to cover who does what, how fixes are validated and how progress is tracked and reported. Status reports flowed through the Continuous Diagnostics and Mitigation federal dashboard, the government-wide program that collects asset and vulnerability data from agencies, or through the CyberScope reporting system for agencies not yet connected. CISA wanted more than fixes. It wanted evidence that each agency had a working process that would keep producing them.

CISA took on duties of its own. It would maintain the catalog, alert agencies when entries were added, and publish the thresholds it used to decide what qualified. It would also report each year on agencies’ progress to the Secretary of Homeland Security, the Director of the Office of Management and Budget and the National Cyber Director. The directive therefore created a feedback loop as well as a list.

BOD 22-01 built on an earlier directive, BOD 19-02 of April 2019. That one required agencies to fix critical and high-severity findings on their internet-facing systems, as found by CISA’s own scanning, within 15 and 30 days. The older directive ranked by severity on exposed systems. The new one ranked by evidence of exploitation, on every system.

The timing fitted a wider push. Executive Order 14028, signed in May 2021, had told agencies to modernize their defenses, and its 180-day deadlines for multifactor authentication and encryption fell days after the directive. A month earlier, the Office of Management and Budget had issued guidance on deploying endpoint detection and response tools across agencies.

The directive bound only federal civilian agencies. Even so, CISA encouraged state and local governments and private organizations to use the catalog to set their own priorities. Because the list was public and free, any bank, hospital or county government could read it and ask a simple question: are any of these on our systems?

On its face, this was a technical memo about patching. In effect, it changed how patch teams spent their week, gave them a new kind of standing in arguments with the rest of the organization, and exposed which agencies actually knew what technology they owned.

For years, the way organizations decided which security flaws to fix first ran on severity scores. A scanner, a piece of software that inspects an organization’s computers and reports known weaknesses, produces thousands of findings, each with a score, and the team works down from the top. It sounds sensible. The trouble is that a high score describes how bad a flaw could be, not whether anyone is using it. Most high-severity vulnerabilities are never exploited in the wild, while some that are exploited carry middling scores.

BOD 22-01 replaced that ranking with a smaller, evidence-based list and a clock. For agency IT operations, that was less a change in security theory than a change in how people spend their week. It reshaped the work queue and the conversation with system owners, and it left a good deal of work untouched.

Those three effects are the core of what follows, in that order. They come after a short explanation of why patching is hard in the first place. After them come what the free catalog meant for banks, hospitals and counties outside the directive’s reach. The piece closes with the habits that separated agencies that coped from those that did not, and the measures a leader can use.

The argument is that the directive’s most important effect was organizational. The list was useful. The deadline, and the authority it lent patch teams, changed more.

Why patching is harder than it sounds

Every piece of software, from the operating system on a laptop to the program that runs a network firewall, contains mistakes. Some of those mistakes let an outsider do things they should not: read files, run their own commands or take control of the machine. When such a flaw becomes publicly known, the company that makes the software usually releases a patch, a small update that corrects the mistake. Installing it is called patching.

If that were the whole story, patching would be easy. In a large organization it is not, for three reasons.

First, there is the volume. A government agency or a mid-sized bank may run tens of thousands of devices and thousands of different software products. Scanners routinely report tens of thousands of open findings. No team can fix them all at once, so every team is, whether it admits it or not, choosing what to leave for later.

Second, there is disruption. Patching usually means restarting a system, and sometimes an update breaks something else. A claims system, a payroll application or a hospital scheduling tool may need to be taken offline during a planned maintenance window. The people who rely on that system are rarely enthusiastic.

Third, there is knowing what you have. An asset inventory is the organization’s list of its own technology: which devices exist, what software and version each runs, where it is and who is responsible for it. Without it, a warning that a particular product is dangerous is hard to act on, because nobody can say quickly where that product is running.

Who owns which part

Patching also crosses organizational lines. The security team usually runs the scanner and decides what is urgent. Infrastructure and desktop teams install the fixes. Application owners test whether a fix breaks their system. Program offices or business units decide whether a system can go offline. Contracting officers hold the levers over vendor-run systems.

Each group has its own priorities and its own manager, and none owns the outcome end to end. A finding can wait for weeks between teams without anyone deciding to leave it open. Much of what BOD 22-01 did was assign that end-to-end ownership, through the procedures it required and the deadline it attached.

How severity scores work, and where they mislead

Most findings arrive with a score from the Common Vulnerability Scoring System, a 0 to 10 scale maintained by the incident response community FIRST. The score describes technical properties: whether the flaw can be reached over a network, whether the attacker needs to sign in first, and how much damage success would do. A flaw that lets anyone on the internet take over a server scores near 10.

Those properties matter, but they describe potential. They say nothing about whether working attack code exists, whether criminal groups have adopted it, or whether the vulnerable product is common in a particular estate. A team that fixes every score above 9 first may spend weeks on flaws nobody exploits, while a flaw rated 7 is being used against its peers.

Where patches cannot simply be installed

Some systems resist patching for structural reasons. Network appliances such as VPN gateways and firewalls often need a full firmware upgrade and a reboot that interrupts every remote user. Systems run by a vendor under contract may only be patched by that vendor, on its schedule. Older applications may depend on a version of an operating system or database that the update changes, so the patch must be tested against the application first.

Vulnerability management is the discipline that ties these together: find the flaws, decide which ones matter, get them fixed, and prove they were fixed. The deciding step is where the old approach struggled. BOD 22-01 swapped the question from “how bad could this be” to “is someone actually doing this right now.”

The work queue

Before the directive, a typical agency patch team faced a backlog it could never clear and a ranking that did not separate urgent from merely serious. Afterward, a defined subset of findings carried a federal deadline. That gave the team a short list it could actually finish, and a reason to finish it that did not depend on internal argument. Completion rates became meaningful again, because the denominator was a few hundred catalog entries rather than tens of thousands of findings.

The change of denominator matters more than it sounds. A team reporting that it has closed 40 percent of tens of thousands of findings is telling leadership almost nothing about risk. A team reporting how many catalog entries remain open, and for how long, is telling leadership something real.

From a monthly cycle to a feed

The catalog was also continuous. CISA added entries as it confirmed exploitation, each with its own due date, sometimes several in a week. That turned vulnerability management from a monthly cycle into something closer to an operational feed. Teams needed to see each addition, match it to their assets and assign an owner within a day or two.

The two clocks shaped the work differently. The six-month window for older flaws let agencies plan a cleanup of long-standing problems, many of them on aging systems. The two-week window for newer ones demanded a standing process, because there was no time to convene a project for each entry. Agencies that treated both as one queue tended to let the urgent new items wait behind the old.

Agencies with accurate asset data could do that in hours. Agencies without it learned that the directive was really a test of inventory. Take a catalog entry for a particular VPN appliance, the box that lets remote staff connect securely to the internal network. Or one for a content management system, the software behind many public websites. Either is useless if nobody knows where those products run.

What the 60-day procedure review asked for

The requirement to update procedures within 60 days sounded administrative. It forced agencies to write down decisions many had left implicit. The procedures had to say how catalog entries would be remediated and who was responsible for each step. They also had to cover what happened when a fix could not be applied, how remediation would be validated, and how status would be tracked and reported.

A useful procedure answered concrete questions. Who watches the catalog, and how quickly after an addition must affected assets be identified. Who can grant a short delay, and who must approve a risk acceptance. What evidence closes a ticket. How a missed internal deadline is escalated, and to whom. Agencies that wrote these answers down found that most disputes during the year had already been settled on paper.

The practical changes

The practical changes were mundane and effective. Teams subscribed to the catalog’s machine-readable feed, a version of the list published in a format that software can read automatically, and pulled it into their scanners and ticketing systems. They tagged assets with product and version so a new entry produced a list of affected systems automatically. They set internal deadlines a few days ahead of CISA’s, leaving room for testing failures. And they started measuring time to remediate catalog entries, which is a more honest metric than total findings closed.

Suppose that on a Tuesday morning CISA adds a flaw in a widely used remote-access product. At an agency with good tagging, the ticketing system opens a ticket for each of the eleven affected devices before lunch. Each goes to the network team, with a due date set a few days ahead of CISA’s. At an agency without it, someone sends an email asking whether anyone uses that product, and the answer trickles in over a week, some of it wrong. Both agencies receive the same warning, but only the first knows within hours which devices it applies to.

Matching is harder than it looks

Matching a catalog entry to an estate is less mechanical than the feed suggests. Catalog entries name a vendor, a product and a vulnerability identifier. Asset tools record software under their own names, which do not always match. A scanner may detect a vulnerable library inside an application without the inventory knowing the application uses it. And some products, especially appliances, are invisible to agent-based tools because nothing can be installed on them.

Teams that did well kept a small mapping table that translated catalog product names to their own software records, and reviewed it when a match failed. They also ran authenticated scans, which sign in to each system and read its installed versions, rather than relying only on network scans that guess from the outside.

Where third parties hold the keys

The directive’s inclusion of third-party hosted systems turned contract management into patch management. An agency using a cloud service or a contractor-run system still had to know whether that system contained a catalog entry and when it would be fixed. For services authorized through FedRAMP, the federal cloud security program, providers already reported vulnerabilities to agencies under their authorization. For other services, agencies had to ask, and the answer depended on what the contract required the provider to disclose.

The conversation with system owners

The hardest part of patching is rarely the patch. It is scheduling downtime, testing compatibility and persuading a program office, the business side that owns and depends on a system, that the risk justifies the disruption. A severity score invites debate. A federal directive with a deadline, tied to evidence that attackers are using the flaw, mostly ends it. Patch teams gained a clear basis for asking mission owners to accept maintenance windows, and chief information officers gained a reason to back them.

Executives will recognize the dynamic. When the security team says a flaw is “critical,” the operations leader hears a technical opinion that competes with a real deadline of their own. When the security team says “attackers are using this, and we are required to fix it by the 17th,” the conversation shifts from whether to when.

Systems that could not be fixed on time

The directive also surfaced systems that could not be fixed on schedule. These included end-of-life platforms, meaning software the vendor no longer updates; vendor-managed appliances where the agency had no administrative access; and products whose vendors had not shipped a fix. Each needed a documented decision: isolate the system, apply a workaround, accept the risk at an appropriate level, or accelerate replacement.

Because CISA said it would not grant waivers, the risk acceptance was the agency’s own. That pushed the decision upward. A system owner who wanted to keep a vulnerable system running had to persuade the chief information officer, and sometimes the agency head, to sign for it. Few wanted to sign for a flaw that attackers were known to be using.

That pushed some long-deferred modernization choices onto the calendar. A system everyone had agreed to replace “eventually” suddenly had a dated problem attached to it. It also exposed contracts that gave vendors control of patch timing without any obligation to meet a federal deadline. New contracts began to include remediation windows for exploited vulnerabilities. For a general counsel or procurement chief, the important outcome was that security obligations moved from good intentions into contract terms.

How a risk acceptance should read

A risk acceptance is only as good as its contents. A sound one names the vulnerability and the system, explains why it cannot be fixed on time, and lists the compensating controls, such as isolation from the internet or tighter monitoring. It names the person accepting the risk, who should hold authority over the mission the system supports. And it carries an expiry date, after which the decision must be made again.

Acceptances without expiry dates tend to become permanent. A short quarterly review of open acceptances, by the chief information officer or chief information security officer, keeps them honest and shows which systems keep reappearing.

Maintenance windows as a standing agreement

Negotiating each outage separately does not scale to a feed that adds entries weekly. The agencies that adapted agreed standing maintenance windows with each program office in advance: a regular slot, a notice period and an emergency path for catalog entries due within days. Program offices gave up some control over timing. In return, they got predictability, and fewer surprise outages announced at short notice.

The trade-off is sharper for systems that run around the clock. Benefits processing, law enforcement systems and public-facing services may have no idle hour. For those, redundancy is the precondition for patching: a second instance that carries the load while the first is updated. Where that redundancy does not exist, the directive exposed an architecture problem as much as a patching one.

Reporting that has to hold up

Agency inspectors general, who audit information security programs each year under the Federal Information Security Modernization Act, gained a concrete thing to test. They could ask for the updated procedure, a sample of catalog entries, and the tickets showing when each was matched, assigned and fixed. They could compare rescan results with reported status. And they could read the risk acceptances for anything left open.

Reporting created its own discipline. Agencies had to show status against the catalog, so the data had to hold up. A patch marked as deployed on a system later found unpatched is worse than an honest exception. Teams that verified remediation by rescanning, rather than trusting the deployment tool’s status, produced reports that survived scrutiny and spent less time reconciling numbers by hand. The trade-off was capacity: rescanning and exception handling took staff time that had to come from somewhere.

The work the directive left untouched

The directive did not shrink the overall backlog, and it did not remove the need to manage it. A catalog of known exploited vulnerabilities is backward-looking by design. A flaw is added after exploitation is observed, so attackers using new or obscure vulnerabilities will not appear on it in time. It works as a most-wanted list rather than a forecast.

The entry criteria add their own gaps. A flaw needs a public identifier and clear remediation guidance before it can be listed. Exploited flaws without a vendor fix, and misconfigurations that are not software flaws at all, fall outside the catalog however much attackers use them. Weak passwords, exposed management interfaces and overly broad access are among the most common routes in, and none of them has a catalog entry.

Agencies still needed exposure management for internet-facing systems, which means keeping track of everything the outside world can reach and minimizing it. They still needed hardening, the practice of switching off features and accounts that are not needed so there is less to attack. And they still needed detection, the monitoring that spots an intruder who got in through a door patching could not close. Some teams found that the catalog crowded out this less visible work, because deadline-driven tasks always win the week.

Patched is not the same as clean

Fixing a flaw closes the door. It does not remove anyone who came through it first. For flaws exploited widely before a patch was available, an agency that patched on time could still have been compromised in the weeks before. A complete response to a catalog entry on an exposed system included checking for signs of earlier intrusion. The directive’s timelines measured the patch, not the hunt, and teams under deadline pressure often stopped at the patch.

It also did not add people. The same administrators handled the new deadlines alongside existing work. Agencies already struggling to recruit and keep systems staff found that a fast clock on a short list was easier to meet than a slow clock on everything, but it was still more work.

Second-order effects on staff

A feed that can add urgent work any week changes the rhythm of an operations team. Emergency changes multiply, and with them evening and weekend work. Teams that absorbed each addition as an emergency wore out. Teams that built the routine described above, with standing windows and automatic matching, turned most additions into ordinary tickets and kept emergencies for the few entries that warranted them.

There is a quality cost too. Rushed patches skip testing, and an update that breaks a production system can cause a longer outage than the risk it addressed. Staged deployment, in which a fix goes first to a small pilot group and then to everything else, keeps speed and safety in balance. It needs a few days, which is another reason internal deadlines belong ahead of external ones.

Investments the directive justified

The agencies that coped best used the directive to justify two investments: accurate asset inventory and automated patch deployment for standard platforms. Automation here simply means letting software push routine updates to ordinary laptops and servers on a schedule, without a person handling each machine. Those investments freed skilled staff for the awkward cases, such as legacy systems and appliances, where judgment is required.

The strongest objection

The strongest objection to the catalog approach is that it rewards compliance with a list. An agency could meet every deadline and still be breached through a flaw that was not yet listed, or through a misconfiguration. Critics also noted that the list reflected what CISA and its partners could confirm, which skews toward widely used products and toward incidents that come to light.

Both points are fair, and the list was never meant to be a whole program. The argument for it rests on a narrower claim. Among the flaws an organization knows about, the ones attackers already use deserve to go first. Few security teams would dispute that ordering, and before the directive many could not act on it, because they had no shared, authoritative way to know which flaws those were.

A free list for banks, hospitals and counties

Outside the federal civilian government, the catalog was public and free. State and local agencies, health systems and banks could use it as a prioritization input without adopting federal deadlines. For organizations without a threat intelligence function, a team that tracks what attackers are doing, it answered the question of which vulnerabilities matter now. For those with one, it served as a cross-check that was easy to explain to auditors and boards.

How the catalog fits each sector

For a bank or credit union, the catalog fitted into an existing expectation. Bank examiners have long reviewed patch management under the FFIEC’s information technology guidance, and a documented rule for handling catalog entries makes that review easier. Much of a community institution’s exposure sits with its core processor and other service providers, so the useful step is often a contract clause or a due diligence question rather than an internal patch.

A broker-dealer’s patching constraint is the trading day. Systems that support order handling are patched outside market hours, which makes a two-week internal deadline realistic for most entries and tight for some.

For a health system, the hard cases are clinical. Medical devices often run embedded or older operating systems that only the manufacturer can update, and changes may need the manufacturer’s validation before use on patients. A catalog entry affecting such a device usually leads to network isolation and a manufacturer conversation, rather than a patch. The electronic health record and its supporting servers need planned downtime, coordinated with clinical leaders and backed by downtime procedures.

For a county or city, the constraint is people. A small IT team may support police, courts, utilities and the public website at once, with public safety systems run by vendors. The catalog gives such a team a short list it can defend to elected officials and department heads. It also gives them a basis for asking vendors, in writing, when each entry will be fixed.

Help that came with the list

Smaller public bodies did not have to build everything themselves. CISA offered free vulnerability scanning of internet-facing systems to state, local, tribal and territorial governments and to critical infrastructure organizations, with regular reports on what it found. For a county with no scanner of its own, that service and the catalog together gave a basic view of its most urgent exposure at no cost.

The limits were the same as for federal agencies, only sharper. External scanning sees only what faces the internet. Internal systems, and the many vendor-run systems in local government, still needed an inventory and a contract that required disclosure. The free tools answered which flaws mattered; they could not answer where those flaws were inside the network.

Why it matters to senior leaders

Four things make it relevant to senior leaders.

• Money. Security and IT budgets are finite. Spending scarce staff time on flaws nobody is exploiting, while a known-exploited flaw sits open, is a poor use of money. A short, evidence-based list concentrates effort where it reduces the most risk.
• Risk. Many serious breaches begin with an attacker using a flaw that was publicly known, with a fix available, on a system that had not been patched. Fixing actively exploited flaws quickly closes the routes attackers are already using.
• Accountability. Suppose a breach happens through a flaw that was on a public list of actively exploited vulnerabilities. It will be hard to explain to a regulator, an insurer, a court or customers why it stayed open. The list changes what a reasonable organization can be expected to know.
• Measurement. Boards often see vulnerability counts that rise and fall without meaning. Time to fix known-exploited flaws is a number a non-specialist can follow from quarter to quarter.

Take a hypothetical regional bank with a small security team. It does not need to follow federal deadlines, but it can still adopt the habit. Every week, it compares the public catalog to its systems and fixes matches on a firm internal timetable. It reports to its risk committee how many matches were found and how quickly they were closed. That one change gives the board a clearer view of cyber risk than a page of raw scanner statistics.

Setting internal deadlines without a directive

A private organization adopting the catalog has to choose its own clocks. A common approach is to vary them by exposure. A catalog entry on an internet-facing system gets days; one on an internal server gets a few weeks; one on an isolated system gets a planned date. That approach anticipated, in a modest way, the risk-based model federal policy later adopted.

The clocks should be written into policy and approved by the risk committee or its equivalent. An examiner, auditor or insurer will ask what the organization’s target is, and whether it meets it. A target the organization sets and misses is better evidence of a working program than no target at all.

The same caution applies outside government. A private organization that adopts the catalog should treat it as a floor. Its own exposure, its own products and its own threat picture still decide much of what comes next.

The habits that made the directive work

The organizations that handled the directive well did unglamorous things:

• A current asset inventory, with product and version recorded, so a new warning turns into a named list of systems in hours, not days.
• An automatic link between the catalog feed, the scanner and the ticketing system, so nobody has to notice an update by reading a website.
• Internal deadlines set ahead of external ones, so a failed test does not mean a missed obligation.
• Standing maintenance windows agreed in advance with each system owner, with an emergency path for urgent entries.
• Remediation checked by rescanning, with honest, documented exceptions where a fix is not possible.
• A named owner and a dated plan for every system that cannot be patched: isolate, work around, formally accept, or replace.
• Contracts that oblige vendors managing systems on the organization’s behalf to apply fixes for exploited flaws within a set window.

The failures were just as predictable:

• Treating the list as the whole program. Because the catalog only includes flaws already being exploited, an organization that patches nothing else is always a step behind.
• Trusting the dashboard. A deployment tool that reports success is not proof the system is fixed. Rescanning is.
• Stopping at the patch. On exposed systems, a flaw exploited before the fix may already have let someone in.
• Letting the urgent crowd out the important. Inventory clean-up, hardening and monitoring rarely have deadlines, so they slip. Leaders need to protect time for them.
• Forgetting the vendor-managed corner. Appliances and hosted systems that the organization does not administer itself are often where the oldest, most exposed software lives.
• Measuring activity instead of outcome. “Findings closed” rewards closing easy items. “Time to remediate exploited flaws” rewards closing the right ones.

The habits share a feature. Each turns an occasional heroic effort into a routine that runs without anyone remembering to start it. That matters because the catalog never stops growing, and the staff who handle it change.

Measuring how fast exploited flaws are found and fixed

These take no technical knowledge to ask, and the answers reveal a great deal.

• When a new actively exploited vulnerability is announced, how long does it take us to know whether we are affected, and how do we find out?
• How complete is our asset inventory? What share of our systems have their software and version recorded?
• How many known-exploited vulnerabilities are open on our systems today, and what is the oldest one?
• Which systems can we not patch at all, and who has formally accepted that risk?
• How do we confirm that a patch actually worked, rather than relying on a tool’s report?

Once those answers are in, three further checks follow. The first is whether the median time to fix known-exploited flaws is getting shorter or longer. The second is whether contracts with vendors who manage systems on the organization’s behalf require them to fix exploited flaws within a set time. The third is which work, such as inventory clean-up, hardening and monitoring, deadline-driven patching is squeezing out, and whether anyone has agreed to that.

Three numbers make a compact quarterly report: open catalog matches and the age of the oldest; median days from catalog addition to verified fix; and the count of formally accepted exceptions, with their owners. A board or audit committee can read them without a briefing, and the trend says more than any single quarter.

The directive itself applied to a narrow group of federal agencies. The discipline it encouraged did not: know what you own, fix first what attackers are using, prove the fix, and be honest about the exceptions.

With hindsight

The catalog’s first real test came within weeks. In December 2021, the Log4Shell flaw in the widely used Log4j logging library was added to the catalog and then became the subject of an emergency directive. Because Log4j was buried inside thousands of other products, many agencies and companies struggled to say where it ran. The episode made the directive’s inventory lesson concrete faster than any audit could have.

CISA followed with an inventory mandate of its own. BOD 23-01, issued in October 2022, required agencies to run automated asset discovery every seven days and vulnerability scans every 14 days across their networks. The asset inventory that BOD 22-01 had always depended on became a requirement in its own right.

The catalog grew steadily and became one of the most widely referenced public sources in vulnerability management. By October 2026 it listed more than 1,700 entries, each with a date added and a due date, and a field noting whether the flaw was known to be used in ransomware campaigns. What started as a federal compliance list turned into a shared reference point that security teams, vendors and auditors could all point to when deciding what came first.

It also gained a companion. Probability-based scoring, such as FIRST’s Exploit Prediction Scoring System, which estimates the likelihood that a flaw will be exploited, offered a complement for flaws not yet listed. The catalog tells you which windows burglars are already using, while a probability score offers an educated guess about which windows they are likely to try next. Used together, they give a team both a must-do list and a sensible way to rank the rest.

The limits visible in 2021 also held. Attackers increasingly targeted edge devices such as VPNs and firewalls, the equipment that guards the boundary between an organization’s network and the internet, sometimes exploiting flaws before any fix existed. In that situation a remediation deadline could not by itself prevent compromise, because there was nothing yet to install. Detection, isolation and the ability to switch a device off quickly mattered as much as patching speed.

The catalog’s dependence on public vulnerability identifiers also showed. Every entry needs a CVE identifier, the numbering system run for years by the nonprofit MITRE under a federal contract. In early 2024, the National Vulnerability Database at NIST fell behind on analyzing new CVEs, leaving many without the details scanners rely on. In April 2025, MITRE’s contract to run the CVE program came within a day of lapsing before CISA extended it. Neither episode stopped the catalog, but both showed how much of the system rests on a small number of public institutions.

CISA’s emergency directives showed how far that problem went. In January 2024, it ordered agencies to act on exploited flaws in Ivanti remote access products, and soon after told them to disconnect the affected devices for rebuilding. In September 2025, ED 25-03 directed agencies to find Cisco firewall appliances, collect forensic data from them and patch or disconnect them within days. CISA described an advanced actor exploiting previously unknown flaws and altering device memory to survive reboots and upgrades. Patching was necessary but not sufficient; the directive required a hunt for compromise as well.

In February 2026, BOD 26-02 told agencies to inventory edge devices that no longer receive vendor support and to remove them from their networks within 18 months. That directive addressed the gap the catalog could never fill: equipment that will never receive a patch at all.

On June 10, 2026, CISA revoked BOD 22-01 and replaced it with BOD 26-04, Prioritizing Security Updates Based on Risk. It also revoked BOD 19-02. The new directive keeps the catalog but sets remediation urgency from several factors. They include whether the asset is publicly exposed, whether the flaw is on the catalog, whether exploitation can be automated, and how much control it gives an attacker. It defers action on low-risk vulnerabilities. In effect, it moves from a single list to a blend of evidence and context. The same flaw is treated as more urgent on a system the whole internet can reach than on one tucked away inside.

The directive is gone, but its habit survives in its successor: prioritize by evidence of exploitation, keep inventory accurate, and measure time to fix rather than findings closed. In any sector, those three habits are worth asking about by name. They are cheap to describe, hard to fake, and they tell you more about an organization’s real exposure than the size of its security budget.