What Happened
A mid-sized software vendor selling IoT devices in the EU market discovered an actively exploited vulnerability in their product line. Their security team followed their standard process: initial alert at 9 AM Monday, triage meeting scheduled for Wednesday, preliminary assessment Thursday afternoon. By Friday morning, they'd confirmed exploitation and begun drafting their disclosure.
Under the EU Cyber Resilience Act (CRA), they were already four days late.
The CRA mandates reporting within 24 hours for any actively exploited vulnerabilities or severe incidents. This vendor's manual triage workflow, adequate under previous regimes, now represents a compliance failure that could result in market access restrictions across the EU. The CRA applies to internet-connected hardware and software products, even if you're headquartered outside the EU, making this a global operational challenge.
Timeline
Hour 0 (Monday 09:00): Automated scanner flags unusual traffic pattern suggesting exploitation of a CVE in the vendor's firmware.
Hour 4: Alert reaches security team inbox. Engineer notes it for review but doesn't escalate; standard triage is scheduled for Wednesday.
Hour 24 (Tuesday 09:00): CRA reporting deadline passes. No report filed.
Hour 48 (Wednesday 11:00): Weekly triage meeting convenes. Team reviews 47 alerts from the past week. The exploited vulnerability is item 23 on the agenda.
Hour 52: Team agrees the alert looks serious, assigns to senior engineer for deeper analysis.
Hour 76 (Thursday 14:00): Analysis confirms active exploitation. Team begins drafting incident report.
Hour 100 (Friday 10:00): Report submitted to EU authorities, 76 hours late.
Which Controls Failed or Were Missing
Automated Detection Without Automated Response: The vendor had scanning tools that identified the exploitation pattern, but no automated pipeline to flag actively exploited vulnerabilities for immediate escalation. The alert entered a queue alongside routine findings.
No Real-Time Severity Classification: The team lacked tools to automatically distinguish between theoretical vulnerabilities and active exploitation. Every alert received the same treatment: wait for the weekly meeting.
Manual Triage Bottleneck: The 24-hour reporting clock "completely kills manual triage" procedures. This vendor's Wednesday meeting cadence, reasonable for traditional vulnerability management, became a structural compliance failure under the CRA.
Missing Operational Visibility: The security team had no real-time dashboard showing time-to-triage metrics or alerts approaching regulatory deadlines. They managed by inbox and calendar, not by SLA.
Inadequate Incident Classification Playbook: The team had no documented criteria for "actively exploited" versus "exploitable." This definitional ambiguity added hours to the assessment phase.
What the Relevant Standard Requires
The CRA's 24-hour requirement doesn't exist in isolation. Map this failure against existing frameworks your compliance team already tracks:
ISO/IEC 27001:2022, Control 5.24 (Information Security Incident Management Planning and Preparation): Requires documented procedures for detecting, reporting, and responding to security incidents. The vendor had procedures, but they weren't calibrated to CRA timelines.
NIST CSF v2.0, Detect (DE) and Respond (RS) functions: Specifically DE.CM-8 (vulnerability scans performed) and RS.AN-5 (processes established to receive, analyze, and respond to vulnerabilities). The vendor satisfied detection but failed the response timing requirement.
NIST 800-53 Rev 5, SI-5 (Security Alerts, Advisories, and Directives): Requires organizations to receive security alerts and take action in accordance with established time frames. The CRA now defines that time frame as 24 hours for active exploitation.
The CRA doesn't replace these frameworks; it adds a hard deadline that forces you to operationalize them differently.
Lessons and Action Items for Your Team
1. Automate Severity Scoring with Exploitation Context
Your CVSS scores don't tell you if something's being exploited right now. Integrate threat intelligence feeds (CISA KEV, vendor advisories, OSINT sources) directly into your vulnerability management platform. When a CVE moves from theoretical to actively exploited, your system should auto-escalate it outside normal triage queues.
Action: Audit your current scanner integrations. Can they consume real-time exploitation data? If not, you're managing blind.
2. Build a 24-Hour Response Pipeline
Map your current vulnerability-to-disclosure workflow. Where are the manual handoffs? A typical flow might be: scanner → alert → triage meeting → analysis → management review → legal review → disclosure. Each step adds hours.
Action: Document every handoff point and its typical duration. Identify which steps can run in parallel and which require human judgment. Your goal isn't to remove humans; it's to remove waiting.
3. Define "Actively Exploited" Before You Need To
The CRA doesn't provide a checklist. Is one exploit attempt enough? Do you need confirmed data exfiltration? Your team needs written criteria that a junior engineer can apply at 2 AM without calling a meeting.
Action: Draft a decision tree: "If [condition], then [escalation path]." Include examples from past incidents. Test it against your last six months of alerts.
4. Implement Real-Time SLA Dashboards
You can't meet a 24-hour deadline you're not measuring. Your security team needs a live view of: alerts received, time since detection, time remaining until CRA deadline, current owner, status.
Action: If your current tools don't support this, you're looking at either a platform upgrade or a custom integration. Budget accordingly.
5. Learn from GDPR's Implementation Challenges
The General Data Protection Regulation introduced a 72-hour breach notification requirement. Early GDPR compliance revealed that organizations struggled most with definitional boundaries ("Is this a breach?") and cross-functional coordination (security, legal, PR). The CRA will surface similar challenges, but faster.
Action: Review your GDPR breach notification procedures. What took 72 hours? Now compress that to 24. Where does it break?
6. Test Your Process Under Time Pressure
Run a tabletop exercise: it's Monday morning, your scanner flags active exploitation, the clock starts. Can your team file a compliant report by Tuesday morning? Include off-hours scenarios; vulnerabilities don't wait for business hours.
Action: Schedule quarterly drills. Measure your actual response time. If you're consistently over 24 hours in a drill, you'll fail under real pressure.
The CRA isn't asking you to find vulnerabilities faster. It's demanding you decide and disclose faster. That's a process problem, not a scanning problem. Fix the process now, before the regulation's enforcement provisions take effect.
