Security Update Prioritization by Risk: Applying CISA's 3-Day Rule to Your Egyptian Company's Servers and Websites
Short answer: Since 10 June 2026, the US agency CISA no longer asks for every vulnerability to be patched at the same speed. Directive BOD 26-04 sets the deadline from four questions: Is the asset exposed to the internet? Is the flaw being exploited in the wild? Can exploitation be automated? Does it give the attacker total control? The answer is 3, 14 or 60 days, or the next system upgrade. In our own reading of the KEV catalog, 113 of the 139 vulnerabilities added since the directive got a 3-day deadline, and 101 of those deadlines span a Friday or Saturday, which is the Egyptian weekend.
Security update prioritization by risk means deciding which vulnerability gets closed today and which can wait for routine maintenance, based on where the asset sits and how attackers actually behave, not on the severity score alone. This article explains the new approach announced by the US Cybersecurity and Infrastructure Security Agency (CISA), presents numbers we extracted ourselves from its public catalog, and turns them into a practical plan for a company, clinic or factory in Egypt that runs a website, a server, a firewall and an accounting system.
What is security update prioritization by risk?
The idea is simple: no company has enough people to patch every flaw the moment it appears, so you need a clear rule for what gets patched within hours and what can wait. On 10 June 2026 CISA published the binding directive BOD 26-04: Prioritizing Security Updates Based on Risk, which supersedes BOD 19-02 and BOD 22-01. It binds US federal civilian agencies only, but it is the clearest free framework currently published, and any Egyptian company can borrow its logic.
The directive justifies the change by noting that attackers exploit unpatched vulnerabilities and that their use of AI may narrow the time between a patch release and exploitation. In its blog post Patch Smarter, Not Harder, CISA cites Verizon's 2026 Data Breach Investigations Report: organizations fully remediated only 26% of KEV vulnerabilities in 2025, down from 38% the year before, and the median time to full resolution rose to 43 days.
The four questions that set the patch deadline in BOD 26-04
The directive counts deadlines in calendar days, so Fridays and Saturdays count, and bases them on four variables:
- Is the asset publicly exposed? That is, can an unauthenticated person reach it over the internet, like your website, hosting panel or VPN gateway.
- Is the flaw in the KEV catalog? This is the Known Exploited Vulnerabilities catalog, to which CISA adds flaws with reliable evidence of exploitation.
- Can the adversary automate exploitation? That is, run every step by machine against thousands of targets.
- What is the technical impact? Partial or total control of the asset, including reliably revealing login credentials.
The table below condenses the directive's sixteen-row timeline table:
| Situation | Maximum deadline |
|---|---|
| Exposed + in KEV + total control (automatable or not) | 3 days with forensic triage |
| Internal + in KEV + automatable + total control | 3 days with forensic triage |
| Exposed + in KEV + automatable + partial control | 3 days |
| Exposed + not in KEV + automatable + total control | 3 days |
| Other KEV cases, or exposed and not in KEV (automatable with partial control, or not automatable with total control) | 14 days |
| Exposed + not in KEV + not automatable + partial control, or internal, automatable and not in KEV | 60 days |
| Internal + not in KEV + not automatable | Next system upgrade |
CISA says an initial analysis at one large civilian agency found only 1% of vulnerability instances in the three-day category, while over 60% were deferred to the next system upgrade. In other words, the approach does not demand more effort; it puts the effort where it matters.
What we found in the KEV catalog since the directive
We downloaded the official catalog CSV on the morning of 25 October 2026. It listed 1,756 vulnerabilities, the latest added on 23 October 2026. We then computed the gap between the date added and the due date for each entry. The results:
| Metric | 1 January to 9 June 2026 | 10 June to 23 October 2026 |
|---|---|---|
| Vulnerabilities added | 133 | 139 |
| With a 3-day deadline | 31 | 113 |
| Forensic triage required | Field did not exist | 91 |
| Known use in ransomware campaigns | Not counted | 8 |
- In October 2026 alone (to 23 October), 26 vulnerabilities were added: 23 with a 3-day deadline and 19 requiring forensic triage.
- Of the 113 three-day entries, the deadline window of 101 includes a Friday or Saturday.
- The most frequent vendors since 10 June: Microsoft with 13, Cisco with 10 and Fortinet with 6, plus three in MikroTik RouterOS and three in WordPress core.
- Seven old vulnerabilities (numbered 2020 or earlier) were added this year on evidence of exploitation, including CVE-2015-5477 in BIND and CVE-2015-3306 in ProFTPD.
The takeaway: the short deadline is now the rule, not the exception, and servers that have not been updated in years are still real targets.
Why this matters to an Egyptian company the directive does not bind
Because attackers do not distinguish between a server in Washington and one in Cairo. Fortinet firewalls, MikroTik routers, WordPress sites and Windows servers are very common in Egyptian companies and clinics, and they are exactly the products that keep appearing in the catalog. Three local factors make the approach more urgent:
- The Friday-Saturday weekend: a flaw added on Thursday can be exploited before the IT team is back on Sunday morning.
- Forgotten devices: a branch router, a camera panel or an old clinic system left open to the internet for convenient remote access.
- Unclear responsibility: many contracts never say who patches the server: the hosting company, the developer or the in-house employee.
We have covered specific cases before in our articles on PHP2Shell and PHP 8.2 end of life and Windows Server 2016 end of support; here we give the general rule that governs every case still to come.
The Smart One Group framework: a 3-14-60 matrix for your company in five steps
This is a practical framework we built at Smart One Group to simplify CISA's approach for small and medium businesses. It is not an official text.
Step 1: Inventory everything exposed to the internet
List every IP address, domain and control panel: the website, email, hosting panel, VPN gateway, firewall, and any clinic or ERP system reachable from outside the office. Whatever is missing from the list will never be patched.
Step 2: Classify each asset as exposed or internal
If the software is public-facing by nature, treat it as exposed until proven otherwise. Sometimes the fastest action is not patching but closing a port or restricting access to VPN, which moves the asset from exposed to internal and automatically extends the deadline.
Step 3: Subscribe to KEV alerts and match them to your list
CISA offers email alerts for each new addition and publishes the catalog in CSV and JSON. One team member matching vendor and product names against the inventory every day is enough.
Step 4: Apply deadlines in calendar days
Use three tiers: 3 days for exploited, exposed, total-control flaws; 14 days for other exploited flaws; and 60 days or routine maintenance for the rest. Decide in advance who works on Friday and Saturday when needed.
Step 5: Document every deferral
An acceptable deferral is a written one: which flaw, why it was deferred, when it will be fixed and who approved it. That log is what you will need in any audit or incident.
What to do within 72 hours when forensic triage is required
The implementation guidance that accompanies the directive proposes six steps for vulnerabilities that require forensic triage. Its timings are recommendations, not obligations:
- Scoping within the first two hours, with an out-of-band communication channel that does not rely on possibly compromised systems.
- Preserve and collect evidence within 2 to 24 hours, starting with volatile data in memory before changing anything.
- Critical patching and stabilization within 2 to 24 hours, after evidence collection, because patching may destroy artifacts.
- Contain and control within 6 to 24 hours, without alerting the threat actor.
- Triage analysis within 24 to 48 hours: unauthorized access, lateral movement, persistence or data exfiltration.
- Escalation decision within 48 to 72 hours, with a written report stating whether full incident response is needed.
The key lesson for Egyptian companies: do not just install the update and close the ticket. A flaw exploited before it was patched can leave a backdoor that survives the update.
How to write these deadlines into your support and hosting contract
If your server sits with a hosting provider or is run by an outside company, ask for explicit clauses in your technical support contract:
- A maximum deadline in calendar days for each tier, including holidays.
- Who patches the operating system, and who patches the application and plugins.
- A commitment to notify you of every exploited flaw affecting your assets, even before it is patched.
- A compromise check after critical flaws, not just a patch.
- A monthly report of what was patched, what was deferred and why.
If you are choosing a security services provider, also see our guide to the NTRA register of cybersecurity service providers.
Frequently asked questions
Is BOD 26-04 binding on companies in Egypt?
No. The directive binds US federal civilian agencies only, but CISA encourages all organizations to adopt risk-based vulnerability management, and its logic applies to any Egyptian company.
What is the KEV catalog?
The KEV catalog is a free public list published by CISA of vulnerabilities with reliable evidence of active exploitation. Each entry includes the CVE ID, product, date added and due date, and it now carries a field showing whether forensic triage is required.
Why not just rank by CVSS score?
Because a CVSS score measures theoretical severity, while CISA's approach adds two practical questions: is the asset actually exposed, and are attackers exploiting the flaw right now. A medium flaw being exploited on an exposed device is more dangerous than a critical flaw on an isolated one.
What does forensic triage mean here?
It is a quick check that the asset was not compromised before it was patched: collecting logs and memory, hunting for indicators of compromise and unfamiliar accounts or tasks, then a written report that decides whether to escalate.
Is turning on automatic updates enough?
Automatic updates help for operating systems and plugins, but they often do not cover firewalls, network devices and custom systems, and they do not answer whether the flaw was exploited before the update.
What is the first step to take this week?
Inventory your internet-exposed assets and match them against the KEV catalog. That step alone often reveals forgotten devices or control panels that are open for no reason.
Next step
If you want your servers, website and firewall reviewed against the 3-14-60 matrix, and clear deadlines written into your support contract, the Smart One Group team would be glad to help. Get in touch to arrange a review session.