On 27 July 2026, CISA added two vulnerabilities to the Known Exploited Vulnerabilities catalogue on evidence of active exploitation:
- CVE-2025-68686 — Fortinet FortiOS, exposure of sensitive information to an unauthorised actor.
- CVE-2026-16812 — Arista VeloCloud Orchestrator On-Prem, OS command injection.
Two additions in a single alert is unremarkable. The timing is not. 11 days later, on 7 August 2026, federal civilian agencies hit the first compliance milestone of Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk” — the directive that supersedes BOD 22-01 (KEV remediation) and BOD 19-02 (internet-accessible systems), and replaces the flat KEV deadline with a graduated, risk-scored model.
For federal agencies this is a mandate. For everyone else it is the clearest signal yet of what regulators, auditors, and insurers are going to treat as a defensible vulnerability-management programme — and the old answer, “we patch KEV entries within 15 days,” is about to stop being the benchmark.
What changed
Under BOD 22-01, every entry in the KEV catalogue carried a due date, and the due dates were essentially uniform: agencies had a fixed window, typically two to three weeks, regardless of whether the vulnerable asset was an internet-facing VPN concentrator or a lab workstation with no route to anything.
That model was simple to audit and structurally wrong. It over-invested in low-risk instances and under-invested in the small set of assets where exploitation was trivially automatable and immediately catastrophic.
BOD 26-04 evaluates each vulnerability per asset against four binary variables:
- Publicly exposed — is the affected asset reachable from the internet?
- Known exploitation — is the CVE in the KEV catalogue?
- Automatable — can an adversary automate the full exploitation chain, from reconnaissance through exploitation?
- Technical impact — does exploitation yield total control of the system, or only partial?
The combinations map onto a graduated schedule. The headline tiers:
| Risk profile | Remediation window |
|---|---|
| Publicly exposed + KEV + automatable + total control | 3 days, plus mandatory forensic triage |
| High-risk combinations short of all four | 14 days |
| Lower-risk combinations | 60 days |
| No public exposure and not automatable | Remediate on system upgrade cycle |
The full directive contains a detailed matrix mapping each combination of the four variables to a window. Two features of the design deserve attention.
The three-day tier comes with forensic triage. For the top tier, patching is not sufficient. Agencies must assess whether the affected systems have already been compromised. This is a significant conceptual shift: the directive treats “publicly exposed, actively exploited, automatable, total control” as a condition under which prior compromise is the reasonable presumption, and the burden is on the operator to check rather than to assume cleanliness.
Prioritisation must be explainable. Agencies are required to be able to demonstrate which inputs drove each timeline assignment. A number produced by a scanner’s proprietary risk score, without traceability to the four variables, does not satisfy the requirement.
The two milestone dates
7 August 2026 — agency policies and processes must support the directive’s approach to ongoing vulnerability remediation. This is a governance deliverable, not a technical one: the written policy, the defined process, the assigned roles, the evidence trail.
7 December 2026 — agencies must begin evaluating and remediating vulnerabilities according to the BOD 26-04 timelines in operation.
The four-month separation between the two is deliberate and instructive. CISA is acknowledging that the hard part is not the patching. It is having an asset inventory accurate enough to answer “is this asset publicly exposed?” for every instance of every vulnerable product — and having the tooling to attach automatability and technical-impact attributes to each CVE.
Agencies that treat 7 August as a documentation exercise will discover in November that the December date requires data they do not have.
Applying the model to the two new KEV entries
CVE-2025-68686 — Fortinet FortiOS information disclosure
FortiOS runs on FortiGate appliances that sit, by design, at the network perimeter. For most deployments:
- Publicly exposed: yes, almost by definition.
- KEV: yes, as of 27 July.
- Automatable: an unauthenticated information-disclosure flaw against a perimeter device is typically scriptable at internet scale. Assume yes pending vendor detail.
- Technical impact: this is where it turns. Information disclosure is ordinarily partial, not total control — which under the matrix moves the instance out of the three-day tier into the 14-day band.
The caveat that experienced responders will apply immediately: information disclosure on a VPN appliance frequently means credential or session-token disclosure, and disclosed credentials on a perimeter device become total control at the next authentication. The Fortinet product line has an established history of exactly this progression. A rigorous reading of the technical-impact variable, informed by what the disclosed information actually enables, may justify treating this as the higher tier regardless of the literal CWE classification.
That judgement — and the requirement to document it — is precisely the “explainability” obligation.
CVE-2026-16812 — Arista VeloCloud Orchestrator On-Prem command injection
VeloCloud Orchestrator is the management plane for an SD-WAN fabric. Compromising it does not compromise one device; it compromises the control point for the network.
- Publicly exposed: on-premises orchestrators are frequently reachable, because distributed edge devices must call home.
- KEV: yes.
- Automatable: OS command injection against a web management interface is a well-understood, scriptable class.
- Technical impact: total. Command execution on the orchestrator host is full control, and it cascades to the managed fabric.
This one lands squarely in the three-day, forensic-triage-required tier for any internet-reachable instance. Organisations running VeloCloud Orchestrator On-Prem should be treating this as a possible-compromise investigation, not a patch ticket. That means: reviewing orchestrator authentication logs for anomalous administrative sessions, checking for unexpected configuration changes pushed to edge devices, examining the host for persistence, and rotating orchestrator and device credentials after patching.
Management-plane compromise is the highest-leverage position an attacker can hold in a modern network, and the Microsoft July 2026 Patch Tuesday and ServiceNow pre-auth RCE events this month reflect the same targeting logic: attackers are going after the systems that administer other systems.
Why non-federal organisations should adopt this anyway
BOD 26-04 binds FCEB agencies. It will bind far more than that in practice, through four channels.
Contractual flow-down. Federal contractors will see agency-specific clauses referencing the directive’s timelines, particularly for systems processing federal data. FedRAMP has already issued guidance on how the directive interacts with authorised cloud services, and FedRAMP requirements propagate to every organisation selling into government.
Regulatory convergence. The four variables are not CISA inventions — they derive from the Stakeholder-Specific Vulnerability Categorization (SSVC) framework, which has been adopted in various forms across sector regulators. Expect the same vocabulary to surface in financial-services and healthcare examination guidance.
Insurance underwriting. Cyber insurers already ask about KEV remediation SLAs. A programme that can produce per-asset exposure and automatability attributes answers the underwriting question far better than a flat “15 days for critical.”
Litigation and enforcement. After an incident, the question is whether the organisation’s vulnerability management was reasonable. A federal directive that defines a graduated standard becomes the reference point for what reasonable means — including, notably, the presumption that top-tier vulnerabilities warrant a compromise assessment rather than a patch alone.
Practical adoption path
Adopting the model without federal reporting obligations is achievable in a quarter.
Establish the exposure attribute first. For every asset, a maintained, machine-readable answer to “is this reachable from the internet?” This is the single hardest input and the one most organisations lack. External attack-surface management tooling, reconciled against the CMDB, is the usual route. The reconciliation gap — assets visible externally that the CMDB does not know about — is itself a finding.
Attach automatability and technical impact to CVEs, not to assets. These are properties of the vulnerability. Most threat-intelligence feeds now carry SSVC decision points; where they do not, a documented internal judgement with a named approver satisfies the explainability requirement.
Define your tiers and put them in policy. Three days with compromise assessment, 14 days, 60 days, next upgrade cycle. Written, approved, with named owners and an exception process that requires compensating controls and an expiry date.
Build the compromise-assessment runbook before you need it. The three-day tier’s forensic triage requirement is the operationally novel part. Decide in advance what “assess for prior compromise” means for each major asset class: which logs, retained how long, examined by whom, with what escalation threshold. Discovering during a three-day window that your perimeter appliance retains seven days of logs is a poor time to learn it.
Measure and report the four variables, not just the patch count. The metric that matters is: how many assets currently sit in the top tier, and how long have they been there?
Conclusion
The two KEV additions on 27 July are ordinary. The rulebook they arrive under is not. BOD 26-04 abandons the premise that a vulnerability has a single deadline and replaces it with the premise that a vulnerability has a deadline on a given asset, determined by exposure, exploitability, automatability, and impact — and that the worst combination warrants an investigation into whether you are already compromised.
Federal agencies have until 7 August to have the policy and until 7 December to be operating it. Everyone else has no deadline and every incentive, because the moment this model is the federal standard, it becomes the yardstick against which every other organisation’s vulnerability programme is measured after something goes wrong.
The immediate action, independent of all of the above: if you run Arista VeloCloud Orchestrator On-Prem and it is reachable from the internet, patch it and assume it may already have been reached.
This article is provided for informational purposes only and does not constitute legal advice.
