Note: This article was originally published on LinkedIn.
Executive Summary
The EU Cyber Resilience Act (CRA) turns product security into a continuous, legally enforced obligation: manufacturers of “products with digital elements” (PDEs) must monitor for vulnerabilities, disclose them responsibly, and ship security updates throughout the product’s support period. For operators, that means more security updates, more often, from more vendors—a shift from the predictability of Microsoft’s monthly Patch Tuesday to a continuous patching cadence across both IT and OT. At the same time, NIS2 (cross‑sector cybersecurity) and DORA (financial sector resilience) require risk‑based decisions and operational continuity as those changes are rolled out. The practical upshot: organizations need a risk‑aware, automated, auditable patching program that can keep pace without breaking systems—or budgets.
Why CRA Means “More Patches, More Often”—Including in OT
The CRA is a horizontal EU regulation covering most software and connected hardware placed on the EU market. It requires security‑by‑design, vulnerability handling throughout the lifecycle, and timely security updates during the declared support period. CRA entered into force December 2024; vulnerability reporting obligations for actively exploited vulnerabilities begin September 11, 2026, and full application (e.g., CE‑marking, conformity assessments) starts December 11, 2027. That framework pushes vendors to release fixes as soon as they are ready rather than holding them for monthly or quarterly bundles—so operators should plan for weekly (or even daily) updates instead of once‑a‑month bursts.
The CRA also elevates expectations for embedded/IoT/OT. Manufacturers must maintain an SBOM (software bill of materials), ensure devices are updateable, and—for many classes—provide security updates for years (commonly cited as at least five years or the expected lifetime). As OT estates accumulate intelligent gateways, PLCs, industrial firewalls, and smart sensors, these obligations translate into a steady stream of firmware and software updates landing in operational environments, not just on desktops and servers.
CRA’s vulnerability‑handling duties are explicit: maintain processes to detect, report, and fix vulnerabilities; publish coordinated vulnerability disclosure; and notify authorities of actively exploited vulnerabilities within strict timelines (widely summarized as a 24‑hour early notification followed by further reports). This formalizes a continuous remediation rhythm for manufacturers—and, by extension, for their customers.
Bottom line: CRA doesn’t merely allow more frequent patches; it requires and incentivizes them. If your estate includes CRA‑covered PDEs in IT or OT, expect more updates from more vendors over longer product lifecycles—and build operations for that reality.
Patch Tuesday vs. CRA: What Changes
There is already a shift with a lot of vendors from once per month to weekly updates. Sometimes even faster than once per week, looking at some of the browser vendors. The expectation is that this will change with the CRA.
Sources: Microsoft’s monthly update policy; EC CRA overview; independent summary of CRA vulnerability handling.
Where NIS2 and DORA Fit: Risk‑Based Decisions and Resilience
NIS2 expands cybersecurity obligations across many sectors, requiring risk management, supply‑chain assurance, and board‑level accountability. DORA (mandatory for financial entities and designated ICT providers since January 2025) prescribes ICT risk management and resilience testing to ensure institutions withstand disruptions—including those that might be introduced by change. Both frameworks expect proportional, risk‑based choices, not calendar‑based patching. In other words, CRA increases the supply of patches; NIS2 and DORA shape how you choose, test, deploy, and prove those changes were proportionate and safe.
The Operational Overload You Should Expect (and How to Plan for It)
- Change management explosion: Monthly bundles become dozens of weekly micro‑changes across vendors. Without automation and clear risk lanes, CABs bog down and engineers spend more time shuffling tickets than reducing exposure.
- Continuous testing across heterogeneous estates: Frequent updates require automated regression testing for OS images, drivers, middleware—and in OT, firmware and protocol stacks. Resilience mandates mean you must prove changes don’t harm availability.
- Supply‑chain & SBOM operations: CRA mainstreams component transparency. You’ll ingest SBOMs, map component CVEs to assets, and trigger remediation only where exposure exists—demanding CMDB enrichment and tighter integration between vulnerability intel and asset data.
- Evidence‑first compliance: Auditors expect proof that you evaluated risk, applied mitigations, tested, deployed, and measured outcomes—so automate evidence capture as part of the workflow.
- Capacity & skills: More frequent releases increase load and the need for platform SRE skills across IT and OT.
Expanded Risk‑Based Prioritization: CVSS Isn’t Enough
CVSS provides a technical severity score, but lacks business context (asset criticality, data sensitivity) and real‑world threat signals (exploit availability, active abuse). Prioritizing by CVSS alone risks fixing lower‑impact items while leaving weaponized, actively exploited issues on critical systems. CRA’s cadence—and NIS2/DORA’s expectations—make a multi‑factor model essential.
- Threat‑led signals: Incorporate exploit availability (PoC vs. weaponized) and active exploitation. CISA’s Known Exploited Vulnerabilities (KEV) catalog is an authoritative list of CVEs confirmed exploited in the wild; treat KEV membership as a binary priority boost and wire it directly into your risk engine.
- Asset criticality: Map vulnerabilities to business services and asset tiers in your CMDB. Internet‑exposed systems and crown‑jewel workloads score higher than isolated lab assets, aligning with NIS2/DORA’s impact‑driven risk expectations.
A Practical, Multi‑Dimensional Scoring Model
Composite Risk Score = CVSS + Asset Weight + Exploit Factors → route to SLA lanes:
- Emergency (≤24–72h)
- Expedited (≤7–14 days)
- Routine (next maintenance window)
- Mitigate & Defer (with compensations + enhanced monitoring) Why this matters: It operationalizes the “proportional, risk‑based” principle in NIS2/DORA while absorbing CRA’s continuous feed.
Worked example.
Active exploitation: Yes (KEV) (5) Total = 7.5 + 3 + 4 + 3 + 5 = 22.5 → Emergency lane (patch/mitigate immediately). A CVSS 9.8 on a lab‑only asset with no exploit and no active abuse can remain Routine until the next safe window.
Vulnerability: CVSS 7.5
Asset: Core payment system (High = 3)
Exploit: Weaponized RCE (4 + 3)
What If There’s No Patch Yet? Mitigate, Monitor, Document
CRA, NIS2, and DORA all recognize there are moments when immediate patching isn’t possible—especially in OT or when the vendor hasn’t issued a fix. Your obligation is to reduce exposure decisively and evidence your decisions:
A. Apply compensating controls
- Network segmentation & isolation (tighten ACLs, harden conduits/zones in OT).
- Access hardening (MFA, least privilege, remove legacy remote access, rotate credentials).
- Protocol filtering / WAF/IPS virtual patching (block/inspect the vulnerable service).
- Application allow‑listing to prevent unauthorized binaries/scripts.
B. Increase monitoring
- Turn on deep logging; forward to SIEM/SOC.
- Deploy detection rules (Sigma/YARA) for exploit TTPs and IoCs.
- Track KEV and vendor bulletins daily for escalation or new mitigations.
C. Document residual risk and revisit on a schedule
Record the risk score, compensations, and monitoring in the change ticket, and set a review date/SLA to apply the patch when available.
Automation & Orchestration: The Only Sustainable Answer
With update volumes rising and risk‑based triage required, manual workflows won’t keep up. You need an automated pipeline covering:
- Intelligence & intake: Aggregate vendor advisories, KEV, and EU sources (including ENISA).
- Risk engine: Compute scores and auto-assign SLA lanes with pre-populated change tickets.
- Test automation: CI/CD-style regression suites for IT and vendor-approved test benches for OT.
- Deployment orchestration: Ring-based rollouts, canaries, and automatic rollback on anomalous telemetry.
- Evidence & observability: Auto-attach test logs, timestamps, and audit-ready reports on demand.
Special Focus: What Changes in OT
OT constraints—safety, deterministic timing, vendor certifications, and process coupling—make frequent patching challenging. Operators must implement updates safely by aligning asset segmentation, applying mitigation-first protocols, and keeping rollback media ready.
Conclusion: Embrace Continuous, Risk‑Aware Operations
Treat Patch Tuesday as a predictable foundation and CRA as the continuous layer above it. Build a risk engine that goes beyond CVSS, orchestrate end‑to‑end, and instrument everything so evidence is a by‑product. Do this, and you’ll lower real risk faster than attackers can raise it.