Notifications
Clear all
Topic starter
18/08/2026 2:32 pm
TL;DR: CISA BOD 26-04 replaces CVSS-only patch queues with a four-variable risk model that combines asset exposure, KEV status, exploit automation, and technical impact, according to ArmorCode’s analysis. The shift matters because it makes remediation a continuous control problem, not a periodic ticketing exercise, and raises the bar for evidence, automation, and defensible prioritisation.
NHIMG editorial — based on content published by ArmorCode: CISA BOD 26-04 Is an Architecture Mandate, Not a Patching Directive
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, making over-privileged systems 4.5x more likely to experience an incident.
Questions worth separating out
Q: What breaks when vulnerability management is based only on CVSS scores?
A: CVSS-only prioritisation breaks when several lower-scoring flaws can be combined into a complete exploit path.
Q: When should organisations replace severity-based patching with risk-based remediation?
A: They should do it when remediation windows, audit pressure, or attack speed no longer match the cadence of manual triage.
Q: What do security teams get wrong about asset exposure in vulnerability management?
A: They often treat exposure as a static property or a CMDB field, when it is really a continuously changing control condition.
Practitioner guidance
- Build a live exposure data plane Continuously resolve whether vulnerable assets are actually internet-reachable using network, cloud, and identity-aware telemetry instead of relying on static CMDB records.
- Tie vulnerability findings to business ownership Map each finding to an asset owner, service owner, and business function so remediation deadlines can be enforced without manual reconciliation.
- Automate tier recomputation Recalculate remediation priority when KEV status, exploit automation, technical impact, or exposure changes so the queue reflects current risk.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- How the ArmorCode Context Risk Graph correlates 375+ scanners, KEV feeds, and asset context into one remediation view.
- How Anya Agents route forensic triage, ownership resolution, and executive reporting across the remediation workflow.
- How the SSVC-aligned tiering logic maps the four BOD 26-04 variables to specific SLA windows.
- How the control plane supports evidence trails for auditors, inspectors general, and board reporting.
👉 Read ArmorCode's analysis of CISA BOD 26-04 and risk-based remediation →
CISA BOD 26-04 and the governance gap in vulnerability prioritisation?
Explore further
18/08/2026 3:19 pm
Severity-based remediation is now a governance failure mode, not a process preference. BOD 26-04 codifies what many mature teams already learned: a vulnerability’s score does not describe its operational danger unless exposure and exploitability are part of the decision. That is the same structural lesson identity teams face when standing privilege, stale ownership, or unmanaged secrets are treated as background hygiene. The practical conclusion is that remediation policy must be driven by live context, not static scores.
A question worth separating out:
Q: Who is accountable when remediation decisions cannot be explained to auditors?
A: The security and governance function is accountable, because prioritisation is now a control decision, not just an operations task. Teams need evidence for why a vulnerability was assigned a tier, what changed it, and who approved any exception. Without that traceability, remediation policy cannot stand up to regulator, board, or auditor scrutiny.
👉 Read our full editorial: CISA BOD 26-04 turns vulnerability management into risk architecture
