Notifications
Clear all
Topic starter
08/07/2026 6:54 pm
TL;DR: CISA Binding Operational Directive 26-04 replaces raw CVSS-led patch ordering with risk-based remediation that weighs exposure, known exploitation, exploit automation, and technical impact, with the highest-risk flaws due in as little as three days according to Senserva. The shift makes patch prioritisation an operational decision about attackability and business context, not a severity score alone.
NHIMG editorial — based on content published by Senserva: CISA BOD 26-04 and risk-based patch prioritisation
Questions worth separating out
Q: How should security teams prioritise patches when CVSS no longer drives the schedule?
A: Start with exploitability, exposure, and business impact.
Q: Why does exposure matter more than raw severity in patch governance?
A: Exposure determines whether an attacker can reach the flaw quickly, which often matters more than the theoretical severity label.
Q: What do teams get wrong when they treat all critical patches the same?
A: They assume every critical item has the same urgency and the same attacker value.
Practitioner guidance
- Rebuild patch queues around exploitability Rank remediation by exposure, KEV status, exploit automation potential, and technical impact instead of using CVSS as the primary scheduling input.
- Map vulnerable assets to identity and access criticality Flag internet-facing admin planes, directory services, secrets stores, and device-management systems as priority remediation targets because compromise there expands access fast.
- Tie vulnerability data to live configuration state Use authoritative asset and configuration sources so teams can confirm whether a vulnerable system is reachable, exposed, and actually in scope before deciding deadline order.
What's in the full article
Senserva's full article covers the operational detail this post intentionally leaves for the source:
- How Senserva maps Microsoft patches to the CVEs they fix and flags which ones are in CISA KEV.
- The specific risk-ranking logic it uses across CVSS, exploit activity, exposure, and impact.
- Implementation detail on deterministic reporting across Microsoft 365, Intune, Defender, and Entra ID.
- The Trustworthy AI workflow that drafts and validates fixes against tenant state before action.
👉 Read Senserva's analysis of CISA BOD 26-04 and risk-based patch priority →
BOD 26-04 and risk-based patching: what changes for teams?
Explore further
08/07/2026 7:16 pm
Risk-based patching is now an identity governance problem as much as a vulnerability problem. Once remediation timing is driven by what is reachable and exploitable, the question becomes who or what has standing access to those systems and whether that access increases blast radius. That is a governance issue across human admin rights, service accounts, and platform identities, because patch delay compounds privilege exposure. The practitioner conclusion is that patch priority and access priority now have to be managed together.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable when a high-risk vulnerability is left unpatched past the new window?
A: Accountability sits with the owners of the asset, the vulnerability management process, and the operational team that controls maintenance windows and exception handling. In regulated environments, the question is not only who patched it, but who could prove exposure, triage priority, and closure verification under the policy in force.
👉 Read our full editorial: CISA BOD 26-04 redefines patch priority around real risk
