Every Directive Is a Floor Too Many Teams Read It as a Ceiling

What CISA’s new risk-based patching directive gets right, and why meeting it, or admiring it from the sidelines, was never the whole job.

Co-authored with Jeremy McKain, Staff Risk Expert at Walmart Global Tech.

On June 10, 2026, CISA published Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk”. It replaces flat, CVSS-driven patch deadlines with four risk factors and dynamic remediation timelines, and for the first time, federal agencies are no longer required to score vulnerabilities by severity alone to decide what gets patched first.

It also doesn’t apply to you if you run security for a company that isn’t a federal civilian agency.

We keep seeing two reactions to that fact. One assumes a federal directive somehow binds a commercial security program. The other, more common, assumes that because it doesn’t bind you, it has nothing to teach you. That second one is the expensive mistake, and it’s the one this piece is actually about.

Mario Lunato made a version of this argument earlier this year in FedRAMP 20x Doesn’t Kill the Compliance Burden. It Reassigned It: compliance regimes don’t actually reduce work, they relocate it, usually from one team to another. The same logic applies a level up. A directive or a control catalog was never the finish line. It’s the floor, and deciding how far above it you need to stand is not a decision you get to outsource to a regulator.

What BOD 26-04 Changes

BOD 26-04 supersedes two older directives, BOD 19-02 and the KEV-defining BOD 22-01, and replaces the old “patch every High and Critical in N days” model with something closer to SSVC-style decision making, the decision-tree approach Carnegie Mellon’s CERT/CC has pushed as an alternative to a single CVSS number: a score built from four yes-or-no questions. Is the asset publicly exposed, is the vulnerability in CISA’s Known Exploited Vulnerabilities catalog, can exploitation be automated start to finish, and does successful exploitation hand an attacker partial or total control?

Stack those four and you land in one of four remediation windows: three days, fourteen days, sixty days, or fix it at the next scheduled system upgrade. Hit all four (a publicly exposed device, a live KEV listing, automatable exploitation, full control) and the clock is brutal: three calendar days, and the agency also has to check whether the box was already compromised before it patched, since a patch closes the door without checking whether someone already walked through it.

Notice what’s missing from that list: CVSS. By revoking BOD 19-02, CISA formally dropped the requirement to score vulnerabilities by severity alone. That’s a real shift, not a cosmetic one. CVSS was never built to tell you how likely something is to get exploited in your specific environment, only how bad it looks in a vacuum.

The Floor Reaches Further Than Its Legal Text

CISA’s binding operational directives get their authority from 44 U.S.C. § 3553, and that authority stops at the edge of the federal civilian executive branch. It doesn’t reach national security systems, and it doesn’t reach a bank, a hospital network, or a generic commercial SaaS platform. CISA knows this, which is why its own language encourages state, local, and private-sector critical infrastructure owners to adopt the practice voluntarily, the same way the KEV catalog itself quietly became a reference point that auditors and cyber insurers now use by default.

That word, encourages, is doing a lot of work. But the pressure travels through channels that don’t need a statute. FedRAMP responded within a week: cloud service providers now have to meet new Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules by December 7, 2026, specifically to align with this directive.

Underneath the legal question sits a more practical one. A three-day remediation window for the worst-case combination is aggressive by any standard, and CISA didn’t pick that number to make a point. It’s a response to how much faster exploitation has gotten. A lot of private-sector programs are still running SLAs, thirty days, sixty days, ninety days, that were reasonable when exploitation took weeks to operationalize. Those numbers were a scheduling convenience more than a real risk decision, and the gap between the SLA you’ve always used and how fast attackers actually move now doesn’t close just because your company isn’t a federal agency.

Why the Floor Is Built Coarse, on Purpose

CISA’s four factors have to work identically for a cabinet department and a three-person federal office nobody’s heard of. That’s a feature for a regulator writing one policy across a hundred-plus agencies of wildly different maturity. It’s a limitation for you, for at least three reasons.

The floor doesn’t know your business. Publicly exposed and total control are the right universal signals, but they say nothing about whether the asset in question processes customer payment data or is a marketing microsite nobody would miss for a week. Exposure and impact aren’t the same question, and only you can answer the second one.

The floor’s core data source has real gaps. BOD 26-04 leans heavily on the KEV catalog to answer the exploitation question, and KEV, by the account of the people who track it hardest, misses a lot. VulnCheck’s own 2026 research on network edge devices, the most targeted category in its 2025 data, found that fewer than a quarter of the vulnerabilities they’d confirmed as actively exploited had actually made it onto CISA’s KEV list. Even the good, risk-based model is running on a partial feed.

The floor is drowning in volume it never priced in. FIRST, the global association of incident response and security teams that also maintains CVSS and Exploit Prediction Scoring System (EPSS), tracks CVE volume trends across the industry as part of that work, and it has revised its projections upward more than once this year, with the growth being driven largely by AI-assisted vulnerability discovery outpacing the tooling built to triage it. NIST’s own vulnerability database has been candid about what that did to it: after falling behind on enrichment for two years straight, it moved most of its backlog to a “Not Scheduled” status rather than clear it. That’s the enrichment layer a lot of vulnerability tooling has quietly depended on for years, and it just told everyone it can’t keep up.

None of this is a knock on CISA. They built the most generalizable model they reasonably could with the mandate they have. It’s a reminder that a floor engineered for universal, minimum applicability was never going to be sharp enough to double as someone’s actual program.

Building Above the Floor

Two moves close this gap, and they work together rather than competing.

The first is concrete: add EPSS. Built and maintained under FIRST by researchers including Jay Jacobs at Empirical, it outputs a daily-refreshed probability that a given CVE will be exploited in the wild within thirty days, and it’s free and API-accessible. KEV tells you what’s being exploited right now. EPSS tells you what’s likely to be exploited next. Chris Hughes at Resilient Cyber has made this case well and repeatedly: the two signals catch different things, EPSS surfaces real exploitation based on threat telemetry and KEV catches CVEs that EPSS underweights, so the strongest programs run them as complements instead of picking one. Nothing stops you from writing “any CVE above a chosen EPSS threshold on an internet-facing asset gets treated as our highest tier” straight into internal policy, the same way BOD 26-04 already treats KEV membership. CISA couldn’t mandate a FIRST-maintained model across a hundred agencies. You can mandate it for yours.

The second is structural: run this as a program, not a one-time scoring exercise. The industry’s name for it is Continuous Threat Exposure Management (CTEM), a five-stage cycle Gartner introduced in 2022 that never really stops.

Scoping means defining your attack surface around what the business actually cares about protecting (revenue systems, regulated data, identity infrastructure) instead of starting from an IP range or a raw CVE feed. No directive can do this part for you.

Discovery goes wider than CVEs alone: misconfigurations, excess permissions, exposed credentials, shadow IT, the stuff a patch can’t fix because it was never a patchable bug to begin with.

Prioritization is where BOD 26-04’s logic and this approach overlap most, except you’re adding a signal the directive structurally can’t include: business impact, scored against your own environment, sitting alongside KEV and EPSS rather than instead of them.

Validation is the stage most programs skip. Knowing something is theoretically exploitable isn’t the same as knowing it’s exploitable against your actual compensating controls, and testing that closes a lot of manufactured urgency in both directions.

Mobilization is the last stage and the one most organizations struggle with most. A prioritized, validated finding that nobody owns doesn’t help anyone. BOD 26-04 requires agencies to be able to explain and defend their remediation decisions rather than quietly execute them. That same instinct, treating prioritization as a governance decision and not only a technical one, is what makes mobilization actually happen.

The Floor Keeps Getting Rewritten, Everywhere

None of this is unique to vulnerability management, either. BOD 26-04 is the loud example this month. The quiet, load-bearing one is the control catalog a lot of people treat as a finish line: NIST SP 800-53. NIST’s own documentation describes a control baseline as a starting point for tailoring, and it expects organizations to add controls, remove them with documented justification, or build overlays for their specific sector and threat conditions. The Low, Moderate, and High baselines aren’t achievement tiers. They’re floors NIST fully expects to be built on.

Watch how the strongest federal programs use it. DISA took 800-53 controls and hardened them into product-specific STIGs, specifying exactly how to lock down a given operating system down to file permissions and logging, and those guides are public and free to any organization, no DoD contract required. FedRAMP took the same catalog and layered cloud-specific continuous-monitoring obligations onto it that 800-53 never spelled out on its own. Neither treated the baseline as finished. Both tailored it up for the environment they actually had to defend.

Turning This Into a Program

The mistake isn’t failing to comply with a directive that was never written for you. The mistake is reading “not mandated” as “not relevant,” and reading a published minimum, whether it’s BOD 26-04 or 800-53, as a target instead of a floor to build past.

So read BOD 26-04 closely. Its four-factor logic is a better skeleton than most commercial vulnerability programs are running today, and it’s worth adopting as a baseline even though you’ll never be bound by it. Here’s what putting the two moves above into practice actually looks like in week one:

Add a fifth signal it structurally can’t include. Layer EPSS and a business-criticality score on top of asset exposure, KEV status, exploit automation, and technical impact. Hughes calls asset criticality and data sensitivity the actual difference-makers, and he’s right: let those signals carry real weight instead of acting as a tiebreaker.

Know your actual exposure, not just your network diagram. If you can’t say with confidence which of your assets are truly reachable from the internet, that’s the first gap to close before you argue about remediation timelines. BOD 26-04 itself acknowledges this is harder than it sounds once NAT rules, cloud gateways, and legacy routing get involved.

Separate mitigation, remediation, and exception. BOD 26-04 itself distinguishes patching from a compensating control from documented risk acceptance. A proper patch can take days once you factor in testing. A working exploit can go from proof-of-concept to real attack in hours. A compensating control can often go in within hours too. Use all three deliberately instead of treating “patched” as the only acceptable outcome.

Write the tailored version into something enforceable. Your EPSS threshold, your reachability rules, your asset-criticality tiers belong in version-controlled policy your pipeline checks, not a PDF nobody rereads after the kickoff meeting.

Validate before you trust a label, and name an owner for what’s left. Don’t take a severity tag at face value in either direction; test it against your actual environment. And if the prioritization work that follows doesn’t end with a name and a deadline attached, it wasn’t prioritization. It was a report.

BOD 26-04, NIST 800-53, STIGs, FedRAMP: different paperwork, same pattern. Each one is a floor built to work for everyone, which is exactly why none of them were built to work perfectly for you. The floor is where the regulator has to stop. It was never where you have to stop. Compliance can tell you what you’re required to fix. Only you can tell yourself what you can’t afford to lose.