A fleet owner can borrow one idea from CISA's known exploited vulnerabilities catalog: set patch targets by evidence of active attack, not by severity score alone. Give exploited flaws a short, fixed clock, and let everything else follow your normal release cycle.
What the directive does
CISA's Binding Operational Directive 22-01 establishes a CISA-managed catalog of known exploited vulnerabilities that carry significant risk to the federal enterprise. It also sets requirements for federal agencies to remediate vulnerabilities in the catalog. According to the directive, CISA decides what goes in based on reliable evidence that the exploit is being actively used by a threat actor. The directive binds federal civilian agencies. It is not a rule for private fleets, so treat it as a model and not an obligation.
The directive also asks agencies to establish a process for ongoing remediation, assign roles, and define the actions needed to respond promptly. Those are good bones for a fleet policy.
Turning it into a fleet policy
| Signal | Example action | Clock you define |
|---|---|---|
| Listed as known exploited and present in a shipped release | Emergency rollout plan | Shortest |
| Critical score, not known exploited, reachable | Next scheduled release | Medium |
| High or medium, not reachable | Backlog with review date | Longest |
| Not affected, with justification | Record and close | None |
You pick the clocks. What matters is that they are written before the next incident and that someone owns them.
Steps
- Subscribe to the catalog feed and match it against your release SBOMs.
- Add a field to each finding: known exploited yes or no.
- Define the emergency path: who approves, how a build is cut, how a rollout runs, and the stop rules.
- Rehearse it once with a harmless change.
- Track time from listing to the first device updated, and to the last.
Fleet specific wrinkles
Fleets do not patch in a day. Devices are offline, behind carriers, or in places that are hard to reach. So define two targets: the time to ship a fix, and the time until a stated share of devices has taken it. A mitigation, such as turning off an exposed service by configuration, may close the risk faster than a firmware update.
Safeguard matches stored SBOMs against new advisories and supports policies and gates, which is where a known exploited flag can change what is allowed through. See gold.safeguard.sh/scan for the free scan.
Mistakes to avoid
Do not copy a federal timeline without asking whether your fleet can meet it. A target you routinely miss teaches the team to ignore targets. Do not treat the catalog as complete either: a flaw can be exploited before it is listed, and some flaws in your own code will never appear there. Use it as one signal next to your own exposure data. Finally, record exceptions with an owner and an end date, so an accepted delay does not become permanent by neglect.
Quick check
Does the catalog apply to my private IoT fleet?
The directive applies to federal agencies. A private fleet can adopt the idea voluntarily, and customers who are agencies may ask about it.
Is a known exploited flaw always more urgent than a critical one?
Evidence of active attack usually raises urgency, but check whether the component is present and reachable in your devices.
Sources
Last reviewed: 19 October 2026.
