CISA BOD 26-04: A Step in the Right Direction — But Still Not an Attack-Path Model

The old model: severity without causality

For years, vulnerability management was dominated by severity scores. A vulnerability was prioritized because it was "critical" or "high." That sounds rational, but it hides a structural weakness: severity is not the same as attackability.

A vulnerability can be severe in theory but rarely exploited in practice. Another vulnerability can look moderate on paper but serve as the first domino in a rapid compromise chain.

This is the problem CISA is trying to solve. BOD 26-04 recognizes that defenders do not have infinite remediation capacity, and that patching must be guided by signals closer to real attacker behavior: exposure, active exploitation, automation, and impact. The break with the old model is explicit: by revoking BOD 19-02, the federal civilian executive branch no longer requires CVSS for vulnerability prioritization at all. The era of mandated severity-score triage is formally over.

In TLCTC language, CISA is moving from a vulnerability list toward a threat-informed prioritization model.

But it has not yet reached a cause-side attack-path model.

What CISA gets right

The strongest part of BOD 26-04 is the inclusion of exploit automation.

That matters because automation is not merely a technical convenience. It changes attack velocity. If exploitation can be automated, the time between vulnerability disclosure, weaponization, scanning, exploitation, and compromise collapses. CISA itself motivates the directive with the observation that AI tooling is shortening the window between patch release and exploitation.

TLCTC already has a formal home for this: the Δt annotation on the sequence operator, and the four velocity classes built on it. In TLCTC notation:

or:

A transition measured in minutes is velocity class VC-3 (Operational); seconds is VC-4 (Real-Time). The framework's structural claim is blunt: at VC-3 or faster, purely human response is structurally insufficient. Only automated containment or architectural controls operate at that speed. CISA's compressed remediation timelines are an implicit acknowledgment of exactly this — "if attackers can automate this, the patch clock must shrink" is a velocity-class argument, even if the directive never names it as one.

The directive also improves prioritization by taking public exposure into account. An internet-reachable vulnerable system is not the same risk as the same vulnerability buried behind several layers of access control. CISA's new model therefore moves closer to attack-surface-aware remediation.

So the direction is right:

CVSS-only thinking
→ KEV-based thinking
→ exposure + automation + impact thinking

But the missing next step is:

exposure + automation + impact
→ TLCTC attack-path constellations

The forensic concession

There is a second remarkable element in BOD 26-04 that has received less attention than the patch timelines: the directive requires agencies to assess whether a vulnerable system was already compromised before the patch was applied. CISA's reasoning is plainly stated — applying a patch does not evict a threat actor who is already inside.

Read carefully, this is a concession to the attack-path view of the world.

Patching closes the enabling step. It says nothing about whether the path has already progressed beyond it. In TLCTC notation, the forensic question the directive mandates is precisely this:

The server-side flaw was exploited. Did Foreign Executable Content execute? And if it did, what unresolved steps — credential use, function abuse, lateral exploitation — have already occurred? The … operator exists in TLCTC v2.1 for exactly this situation: evidence indicates that something happened, but the steps are not yet classified. Every … is an open analytical task.

So CISA now mandates the forensic question. What it does not provide is a grammar for recording the answer. An agency that completes its compromise assessment has no standard, cause-side vocabulary in which to state "the path reached #4 but not #1." That vocabulary is what TLCTC supplies.

The missing layer: attack-path constellations

The main limitation is that BOD 26-04 still treats the vulnerability mostly as a single remediation object.

But attackers do not exploit "a vulnerability" in isolation. They exploit one weakness because it opens the next step.

That next step is the difference between a vulnerability that is merely bad and a vulnerability that becomes strategically urgent.

For example:

This means: a server-side implementation flaw enables execution of Foreign Executable Content.

That is not just "remote code execution" as a label. In TLCTC, it is a two-step causal sequence:

1. #2 Exploiting Server — the attacker triggers a server-side implementation flaw.
2. #7 Malware — Foreign Executable Content executes through the target environment's designed execution capability.

TLCTC requires this separation: if Foreign Executable Content executes, a #7 step must be recorded in addition to the enabling step.

That distinction matters for patch prioritization. A server flaw that only leaks limited data is not the same as a server flaw that reliably leads to FEC execution.

Both may be #2.

But only one creates:

That constellation deserves a different urgency class.

Why #2 → #2 also matters

Another missing pattern is:

At first glance, that looks redundant. It is not.

In TLCTC, the same cluster may appear multiple times in one path when separate vulnerabilities, systems, or contexts are exploited. The white paper explicitly allows the same cluster to appear repeatedly in a path — across multiple systems or repeated attack steps.

A #2 → #2 constellation might mean:

• internet-facing gateway exploit → internal application server exploit
• web application flaw → backend service flaw
• edge appliance vulnerability → management interface vulnerability

This is not "one vulnerability." It is a chainability condition.

CISA's current factors can say: publicly exposed + automatable + exploited + high impact.

But TLCTC can say:

That is more precise. Each ||...|| operator marks the step at which the responsibility sphere — and therefore the control regime — changes: first from the outside world into the exposed zone, then from the exposed zone into the internal estate, with an illustrative confidentiality outcome on the internal step. The notation shows how one exposed weakness becomes a path into deeper systems, and exactly where a defender's zone boundaries either held or failed.

Why "technical impact" is not enough

CISA's technical impact dimension is useful, especially when exploitation gives partial or total control over an asset. But "control" is still a result, not a full causal path.

From the TLCTC Bow-Tie perspective, this is critical. Threats live on the cause side. Outcomes such as data breach, outage, ransomware impact, or business disruption must be recorded separately as Data Risk Events or Business Risk Events — not treated as threat categories.

So a vulnerability record should not stop at:

technical impact: total control

It should ask:

• How is control achieved?
• What cluster step produces it?
• What next cluster step does it enable?
• What DRE is likely after that?

For example:

means: server-side flaw exploited, FEC executed, loss of confidentiality on the execution step.

Whereas:

could mean: server-side flaw exploited, no FEC execution, data integrity affected.

Those are not the same remediation problem.

The TLCTC extension CISA actually needs

CISA does not need to replace KEV, CVE, CVSS, EPSS, or SSVC. Those instruments remain useful.

What is missing is a causal field that records the attack-path role of the vulnerability.

A TLCTC-compatible vulnerability record could add:

{
  "cve": "CVE-XXXX-YYYY",
  "initial_cluster": "#2",
  "role": "attack-path-enabler",
  "likely_constellations": [
    "#2 → #7",
    "#2 → #2",
    "#2 → #4"
  ],
  "automation": "high",
  "expected_delta_t": "minutes",
  "velocity_class": "VC-3",
  "public_exposure": true,
  "dre_potential": ["C", "I", "Ac", "Av"],
  "compromise_assessment_required": true
}

This would convert vulnerability prioritization into attack-path prioritization. The velocity_class field ties the automation factor to a defensive mode; the compromise_assessment_required field operationalizes the directive's own forensic mandate in cause-side terms.

The key field is not just: Can exploitation be automated?

The key field is: What does automated exploitation enable next?

That is the TLCTC contribution.

The practical prioritization difference

Today, two vulnerabilities may both receive urgent treatment because they are exposed, exploited, automatable, and high impact.

But TLCTC would distinguish their causal role.

This is not merely "more severe." It is structurally different.

The defender does not only need a patch. The defender needs to know where to break the path:

• Prevent #2
• Detect #7
• Invalidate #4
• Constrain #1
• Prepare for [DRE: C] and [DRE: Ac]

That is why TLCTC matters. It separates the cause-side path from the data-risk and business-risk consequences, making control placement more precise.

Why this matters for regulation

Regulation often mandates controls without naming threats clearly. CISA's new directive is better because it moves closer to attacker behavior. But it still does not provide a stable threat taxonomy.

It says, in effect: Patch faster when exploitation is more likely, more automated, more exposed, and more damaging.

TLCTC adds:

• Name the causal step.
• Name the next causal step.
• Record the attack path.
• Attach DREs separately, to the steps that produce them.
• Map controls to the correct side of the Bow-Tie.

That is the missing regulatory layer.

Without it, agencies still risk prioritizing vulnerabilities as isolated objects rather than as nodes in attack sequences — and conducting the directive's newly mandated compromise assessments without a shared grammar to record what those assessments find.

The conclusion: right direction, incomplete grammar

BOD 26-04 is a small but important step in the right direction.

It recognizes that vulnerability severity alone is insufficient — and formally retires mandatory CVSS triage. It recognizes that exploit automation matters. It recognizes that exposure matters. It recognizes that post-exploitation control matters. It even recognizes, in its compromise-assessment requirement, that the patch is not the end of the story.

But it still lacks the grammar to describe why one vulnerability is more dangerous in a real attack sequence than another.

That grammar is provided by TLCTC.

CISA has moved toward: risk-based vulnerability remediation.

The next step is: cause-based attack-path remediation.

In TLCTC notation, CVE prioritization must evolve from:

to:

That is the difference between knowing that a vulnerability is dangerous and knowing what kind of attack it enables.

CISA has taken a useful step.

TLCTC provides the missing path.