You Have 24 Hours - EU Cyber Regulations and IoT Part 3

Finding a vuln in a device is quite the dopamine hit and it's still something I love. Now that I'm also working on the other side and receiving bug bounty reports and other disclosure, I get to see the challenges that hit a manufacturer when a bug report lands. One of the first things manufacturers need to do is get a baseline. Which devices are affected, what can users do about it, and who needs to hear about it first?

In [part 1](https://www.digitalandrew.io/eu-cyber-regulations-and-iot-part-1-whats-actually-coming/) of the blog series I laid out the timeline, and in [part 2](https://www.digitalandrew.io/eu-cyber-regulation-and-iot-part-2-red-already-happened/) we covered the Radio Equipment Directive (RED). From September 11 (today if you're reading this blog when it was posted) 2026, the Cyber Resilience Act (CRA) [reporting obligations start applying](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), and the first deadline is just 24 hours after you become aware of a reportable event. In this blog I'm going to cover what you have to report, how the deadlines work, and what you actually need in place to meet them.

Same disclaimer as before, I'm an engineer and a hacker, not a lawyer (IANAL as they say on reddit, I never get tired of writing that acronym), so none of this is legal advice. I work in internal product security at a device manufacturer these days, which is why one of the reasons interested in how you actually make this work when a report arrives, however, all of the opinions in this blog are my own entirely.

The CRA's main requirements apply from December 11 2027, but the [Commission's summary](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) makes clear that Article 14 reporting starts earlier and covers in-scope products already placed on the European Union (EU) market. For an Internet of Things (IoT) manufacturer, that means your existing devices need to be part of the reporting process too.

The [July Commission guidance, section 9.1](https://ec.europa.eu/newsroom/dae/redirection/document/131456), also says reporting continues after support ends. It doesn't require retroactive reports of active exploitation you already knew about before September 11, however, learning about exploitation after that date can trigger reporting even if the bug itself is old.
If your product inventory only covers the next release, You'll probably want to start looking at what you've already sold (including any of those models your dev team would rather forget).

The first of the two reporting triggers is an actively exploited vulnerability in your product, meaning there is reliable evidence of malicious exploitation without the system owner's permission. The [European Union Agency for Cybersecurity (ENISA) explains this in its reporting guidance](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions), so a researcher getting a shell on their own device, or a scanner finding an old library, doesn't by itself establish active exploitation (phew).

The second is a severe incident affecting product security. Under [Article 14(5)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng), this includes incidents that harm, or can harm, protection of sensitive or important data or functions, or that introduce, or can introduce, malicious code into the product or a user's systems. You need to assess this trigger separately, even if you haven't identified an exploited vulnerability.

The Commission's [guidance on awareness](https://ec.europa.eu/newsroom/dae/redirection/document/131456) calls for immediate assessment of suspicious events, with awareness given once there's reasonable certainty that a reportable event has occurred. An initial investigation is expected, but waiting for every detail of the root cause isn't the threshold.

My practical advice is to treat it like any DFIR process. Record when the information arrived, what you checked, and when you reached that conclusion, otherwise you're trying to reconstruct the start of a legal deadline from somebody's chat history.

The [reporting timetable](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) looks like this:

Both initial deadlines run from awareness, so the 72 hours includes the first 24, and [ENISA's frequently asked questions](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions) confirm that both submissions must be made without undue delay. If you become aware at 3pm on a Friday, I'd plan to have the warning submitted well before 3pm Saturday, which means somebody needs to be available over the weekend.

One way I like to think of this is an incident ticket that gets updated as the investigation progresses. The early warning gets the event on record, then you add the details as you establish them.

For the early warning, Article 14 asks for the EU countries where the product is available, where applicable, and for incidents, whether unlawful or malicious activity is suspected. By 72 hours, you provide the available details of the exploit or incident, measures taken, what users can do, and information sensitivity. The final report adds severity and impact, details of the corrective measures and any available attacker information for vulnerabilities, or likely cause and ongoing mitigations for incidents.

[ENISA's field guide](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2) maps the information to each reporting stage.

Here's the critical detail behind the 14 days: a mitigation can start that final-report deadline, so waiting for the next firmware release could already put you late if you've made a workaround available.

Reports go through the Single Reporting Platform (SRP), operated by ENISA, to the relevant Computer Security Incident Response Team (CSIRT) designated as coordinator and normally to ENISA simultaneously.

The [Commission's explanation of the reporting route](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) also covers the limited exceptions for delaying information sharing between authorities.

For manufacturers with a main EU establishment, that determines the coordinating CSIRT. Manufacturers outside the EU also have a reporting route, with [Article 14(7)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) setting an ordered test based on their representative, importer, distributor, then users. Work out which applies to you before an incident.

You also have to inform impacted users and, where appropriate, all users, including measures they can take when needed, as set out in [Article 14(8)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng). For a device manufacturer, I'd have the customer message drafted alongside the regulator's report so users can act on whatever mitigation is available.

Companies will probably need a security contact and a named person who can coordinate the response, with somebody covering their absence. Reports can arrive through researchers, customer support or suppliers, so those people need to know where to send them. A security email address that nobody checks is going to make the first 24 hours pretty difficult.

Then I'd make sure the team can connect a vulnerability to actual products and firmware versions. A Software Bill of Materials (SBOM) helps, but you also need to know which builds shipped, whether the affected code is reachable, and who can investigate it. This is preparation I'd recommend now; the broader CRA vulnerability handling requirements come with the December 2027 obligations.

For the reporting account, there's a useful detail in [ENISA's registration guidance updated September 10](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration): prepare a personal EU Login account with multi-factor authentication (MFA), but register on the SRP when you actually need to notify. ENISA advises against pre-emptive SRP registration, and says verification can run alongside reporting without preventing submission.

Finally, it's never a bad idea to run a practice incident using a real product and a made-up exploitation report, with the team finding the affected firmware, identifying the coordinator, and drafting the first warning. Keep the exercise internal, but use the actual people and information sources you'd rely on, including whoever can approve a mitigation and tell customers how to use it.
If that exercise gets stuck because the only person who knows the firmware is on vacation, you've found something useful to fix (preferably before they're actually on vacation).

I think the reporting deadline will make manufacturers look much harder at what happens after a device ships. For those of us who work on product security, being able to get a credible report to the right engineer quickly is something we can actually test and improve.
Next up I'll cover the December 2027 essential requirements, including secure defaults, software inventories and the commitment to keep shipping security updates.

Until next time...
Happy Hacking - DigitalAndrew