It’s 6:40 on a Saturday evening, and a security alert lands in the inbox of a software company’s lead engineer. A flaw in a widely used library has just been added to a list of vulnerabilities that attackers are actively exploiting. Her company’s desktop app bundles that library. So might the mobile app, and possibly the firmware updater.
She doesn’t know which products contain it, which versions customers are running or who has the authority to decide whether this has to be reported. The answers are in a spreadsheet last updated in the spring, and the person who maintains it is on holiday.
Until this autumn, that would have been a stressful weekend. Since September 11, 2026, it’s also a legal deadline. Under the EU Cyber Resilience Act (CRA), a manufacturer that becomes aware of an actively exploited vulnerability in its product has 24 hours to send an early warning. That’s 24 hours on the clock, not 24 working hours, and the clock doesn’t care that it’s the weekend.
One security researcher, Joe Brinkley of Cobalt, told CSO Online that the 24-hour window “completely kills” manual triage. He has a point, and it isn’t mainly about the report. The hard part is knowing, within hours, whether you’re affected, which products are involved and who decides. That’s a process problem, and most of it can be automated.
In this post we’ll start with a quick check on whether the rules apply to you, then explain what they require and why manual triage struggles. We’ll set out a practical process for meeting the 24-hour clock, with an example timeline, a checklist and answers to common questions.
Does This Apply to You?
Start here, because the answer decides whether this post is for you.
The reporting duty applies to manufacturers of products with digital elements. The regulation defines that as a software or hardware product, plus its remote data processing solutions and any components placed on the market separately. It reaches manufacturers wherever they’re based if they place products on the EU market, and non-EU manufacturers are expected to appoint an authorised representative in the EU.
You’re likely in scope if you make:
- Software people download or install, such as desktop apps, mobile apps, plugins and SDKs
- Connected hardware or firmware
- Agents, CLI tools or components distributed to customers, even if your main platform is a hosted service
You’re likely out of scope if you run a purely web-based service that customers use through a browser, with nothing installed on their side. Those services are generally excluded from the CRA, though they may fall under other rules such as NIS2. Open-source software developed outside a commercial activity is also excluded, though organisations that systematically support open-source software meant for commercial use can have lighter obligations of their own.
The boundary between product and service can be blurry, so assess each product separately and take legal advice if you’re unsure. If you only run a website or a web shop, this probably isn’t your obligation, though it may be your software supplier’s.
What the Rules Require
Article 14 of the CRA, Regulation (EU) 2024/2847, sets out a three-stage reporting sequence for two kinds of event: actively exploited vulnerabilities and severe incidents.
Early warning, within 24 hours. This is due without undue delay and in any case within 24 hours of becoming aware. It’s a first alert with essential information such as the affected product and what you know so far, not a finished investigation.
Notification, within 72 hours. A fuller update covering the nature of the vulnerability or incident, an initial assessment and any corrective or mitigating measures taken or available.
Final report. For an actively exploited vulnerability, this is due within 14 days after a fix or mitigation becomes available. For a severe incident, it’s due within one month of the incident notification.
Reports go through a single reporting platform run by ENISA, the EU cybersecurity agency, and are made available to the national CSIRT acting as coordinator. Most of the CRA’s other requirements don’t apply until December 11, 2027, but the reporting duty already does, including for products placed on the market before then.
Two points are easy to miss. First, the trigger is a vulnerability that’s being actively exploited, not any newly found bug. Second, the 24-hour report isn’t expected to be complete. Law firms advising on this stress that teams need a way to make an early call on reporting while the facts are still developing.
Why Manual Triage Struggles
The CSO Online analysis makes a practical point about where the information lives. The facts you need to file a notification usually sit in five or six separate places: SIEM systems, threat feeds, known-exploited-vulnerability alerts, scanner findings, asset inventories and software bills of materials (SBOMs). None of them were built to talk to each other on a 24-hour timeline.
Add a few realities of ordinary software teams:
- Alerts don’t arrive in office hours. A Saturday-night alert that waits until Monday has used up most of the window.
- Knowledge sits in people’s heads. “Which of our products use that library?” shouldn’t depend on who happens to be online.
- Decisions need an owner. If nobody is named to decide that something is reportable, the hours pass while people look for permission.
- Volume grows. A process that copes with one alert a quarter may fail when there are several in a week.
Some of this is opinion from vendors who sell automation, so weigh it accordingly. Still, the underlying logic holds: a process that relies on someone noticing, searching and deciding, in order, will struggle to meet a short deadline.
A Process for Meeting the 24-Hour Clock
Build a queryable inventory first. You can’t report on a product you can’t identify. Keep an up-to-date list of every product and version you ship, with an SBOM for each. Open-source tools such as Syft and Trivy can generate these automatically in your build pipeline, so the inventory refreshes with every release rather than going stale.
Define “aware” and record the moment. Decide in writing what counts as becoming aware of an active exploitation, and log a timestamp whenever that point is reached. Advisers differ on edge cases, such as whether the clock starts at the first automated alert or when someone confirms it, so agree your position with legal counsel in advance and apply it consistently.
Watch the right sources automatically. Subscribe to feeds that flag exploited vulnerabilities, along with your own scanner output, support tickets and threat intelligence. Have them feed one place, so a human isn’t checking five dashboards on a Saturday.
Match vulnerabilities to products automatically. When a new exploited vulnerability appears, a script should check it against your SBOMs and answer within minutes: which products and versions contain it, and which customers may be affected. This is the single most valuable thing to automate.
Name the people and the backup. Appoint an owner for the reporting process, a deputy and an approver with authority to sign off an early warning. Because the clock runs through weekends, you need an on-call arrangement that covers them. Write down who does what across security, engineering and legal.
Pre-fill the early warning. Prepare a template with your company details, product identifiers and contact point, so the automated match can fill in most fields. A person should be reviewing a draft, not starting from a blank page.
Automate the clock and the nudges. Start a countdown the moment awareness is logged, and send escalating reminders to the owner and the approver. Include a deliberate buffer, so the target for submission is well inside 24 hours.
Keep humans for judgment. Automation should gather, match and draft. People should decide whether an event is actually exploited, whether it’s reportable and what the notification says. The aim is to give your experts the facts in an hour rather than a day.
Rehearse before you need it. Run a drill with a realistic exploited vulnerability, at an awkward hour if you can. Time how long each step takes and fix the slowest one. Then repeat for the 72-hour notification and the final report, which need their own templates and owners.
An Example 24-Hour Timeline
This is an illustration of how the hours could be spent, not a legal requirement.
- Hour 0: An exploited-vulnerability alert arrives. The system logs the timestamp and starts the countdown.
- Hours 0 to 1: Automation checks the vulnerability against every SBOM and lists the affected products and versions.
- Hours 1 to 4: The on-call engineer confirms the evidence of exploitation and checks the match.
- Hours 4 to 8: The reporting owner and approver decide whether the event is reportable. Legal reviews if needed.
- Hours 8 to 16: The pre-filled early warning is checked, completed and approved.
- By hour 20: The early warning is submitted through the single reporting platform, leaving a margin.
- Hour 24: The hard limit.
- Hours 24 to 72: Work continues on the fuller notification, including mitigation advice for users.
A 24-Hour Response Checklist
- Confirmed which of your products fall within the CRA, product by product
- Built an inventory of every product, version and SBOM, refreshed automatically on release
- Appointed a reporting owner, a deputy and an approver, with weekend and holiday cover
- Written down what counts as becoming “aware”, agreed with legal advisers
- Connected exploited-vulnerability feeds, scanner results and support channels to one intake point
- Automated the match between new vulnerabilities and your products
- Created pre-filled templates for the 24-hour, 72-hour and final reports
- Set up a countdown with escalating reminders and a submission buffer
- Registered for the reporting platform and checked your route, including an authorised representative if you’re based outside the EU
- Run at least one timed rehearsal and fixed what it exposed
Frequently Asked Questions
When did the CRA’s reporting duty start? September 11, 2026. Most other CRA obligations apply from December 11, 2027.
What has to be reported within 24 hours? An early warning about an actively exploited vulnerability or a severe incident in your product. It needs essential information, not a finished investigation.
Does a newly discovered bug trigger the clock? Not on its own. The urgent reporting duty is triggered by active exploitation, though you should still handle ordinary vulnerabilities through your normal disclosure and patching process.
Who do we report to? The national CSIRT designated as coordinator, and ENISA, through a single reporting platform.
Does this apply to SaaS companies? Pure browser-based services are generally outside the CRA. But downloadable components such as agents, SDKs and plugins are products, and some remote data processing solutions can count as part of a product, so check each case.
Can we do this without buying new tools? Largely, yes. Much of it is a named owner, a clear definition, an automated inventory and a tested runbook. Tools help with speed, but the decisions and the ownership matter more.
Is this legal advice? No. Take advice from a lawyer who knows the CRA, especially on scope and on when the clock starts.
Build for the Saturday Night Alert
It’s tempting to treat the 24-hour clock as a paperwork problem, a form to fill in when something goes wrong. But the form is the easy part. The real test is whether, at 6:40 on a Saturday, your team can quickly work out what’s affected, who decides and who presses send.
The teams that handle it calmly will be the ones that made the answer a system rather than a scramble: an inventory that updates itself, a match that runs in minutes, an owner who knows the job and a rehearsal that has already exposed the weak spots. The regulation may feel heavy, but a well-built process makes each alert smaller and easier to handle.
If you’d like help putting that in place, our automation team can connect your inventory, vulnerability feeds and reporting workflow, build the alerts and countdowns, and keep the monitoring running. You can see how we approach this kind of work across other brands in our case studies.
