The first deadline of the Cyber Resilience Act went live last week. The Cyber Resilience Act (CRA) is the new EU regulation that defines minimum cybersecurity requirements for all products with digital elements, including their building blocks (hardware and software). It applies to anyone placing products on the EU market, not just companies based there.
The full requirements won’t go into effect until the end of next year. All products with digital elements sold in the EU need to comply with the CRA security requirements by December 11, 2027. We wrote more about the CRA in our initial blog post about it.
I’ve been following this regulation’s development closely for the past three years. Now that the Single Reporting Platform (SRP) is live, I want to share my first impressions and clear up some myths about how you need to comply with the CRA, so you can be confident moving forward.
Using the new CRA Single Reporting Platform
As of September 11, companies are legally required to report any actively exploited vulnerabilities or severe incidents to EU authorities within 24 hours of becoming aware of them. You can do this via the new Single Reporting Platform (SRP).
The initial report (after 24 hours) is followed by a notification within 72 hours that includes threat and mitigation information. Organizations must submit a final report within 14 days of a fix becoming available for exploited vulnerabilities, or within one month of the 72-hour notification for severe incidents.
So far, the only required fields of the initial report are:
- Type (vuln or incident)
- Title
- Summary
- Manufacturer name
- Member states where the product is available
- Product name
- Version
Under product, they also optionally ask for the product type (classification), and of course, you can add multiple products. That’s it!
Voluntary reporting will launch in a later phase, which will allow anybody to disclose vulnerabilities without facing legal consequences. In the meantime, only use the platform for mandatory notifications.
You can check out these details and more in the CRA SRP manual.
Cyber Resilience Act myth-busting
At Aikido Security, we get a lot of questions related to the CRA and its incident reporting obligations. Below, I clarify some of the most common misconceptions I've been hearing.
Myth 1: We have to report every vulnerability we find to ENISA
You don't actually have to report every vulnerability you find in your product (great news!). The only vulnerabilities you have to report are those that are actively being exploited in your product with malicious intent, or a severe incident affecting your product’s security.
So if you find a vulnerability in your product, but you have no proof or indicator that it has been exploited, you don’t have to report it. However, if you become aware that one has been exploited by a malicious actor, you will have to report it. So I recommend prioritizing vulnerabilities based on their exploitability to avoid them from becoming reportable events in the future.
Myth 2: The final report is due 14 days after you discover the vulnerability
This isn’t true. The actual guidance here is that the final report (for exploited vulnerabilities) is only due 14 days after you deliver the remediation. A lot of people read that as 14 days from when they first found out, then panic about a deadline that isn’t real. This gives you more time, since two weeks isn’t realistic for some products!
Here’s the full timeline:
- Within 24 hours, send an early warning. (“Something happened”)
- After 72 hours, send a vulnerability notification. (“Here's what happened.”)
- 14 days after releasing a remediation for actively exploited vulnerabilities, send the final report. (“Here’s how we fixed it.”)
- 1 month after the 72 hours notification for severe incidents, send the final report. (“Here’s how we handled the incident.”)
Myth 3: We just tell ENISA about the vulnerability, and we're done
Unfortunately, this is just one step. Under the CRA, you do need to report directly to the Single Reporting Platform (SRP), which is accessible to both your local CSIRT and ENISA. However, you also have to inform the users affected by an incident of any corrective measures that they can deploy to mitigate the impact of that vulnerability. Depending on the incident, you may need to inform your whole user base.
Myth 4: We have to register with Single Reporting Platform now that it’s live
Nope, no need to do anything right now if you don't have anything to report. I was a bit unsure about this one at first, but the user manual cleared it up: ENISA actually recommends that companies hold off on pre-registering.
I was a bit worried that if you don't pre-register, you'd end up waiting for validation from the CSIRT when an emergency hits. Luckily, this isn't an issue. An Authorised Representative (AR) can go ahead and submit notifications even while the validation is still pending. The platform will accept up to 20 submissions from unvalidated users, allowing up to 20 people to register for a single company to file reports.
First impressions and looking forward
My first impressions of the CRA SRP are mostly positive. Getting my account verified as a real Aikido employee (the “Assigned Representative association”) took three business days for Belgium's CSIRT to verify. This verification ensures trolls can’t just claim your company before you do.
The platform had a few deployment issues on the 11th, but everything was online within a few hours. Once you are set up, you get an email notification as soon as your association gets authorized. It also supports passkey authentication, though I definitely recommend setting up a few backup devices so you don’t get locked out.
Looking forward, the upcoming (to be) harmonised standards are really what everyone needs to keep an eye on, since they define the actual technical rules for building compliant products. You will definitely want to dive into these drafts as early as possible. If you don’t, you risk designing products that fall short and lead to costly redesigns later on.
Keep a close eye out for EN 40000-1-1 (which lays out the terminology) and EN 40000-1-3 (which sets the rules for vulnerability handling and disclosure). Getting familiar with these standards early will give you a major head start on your competitors!
The future of the Cyber Resilience Act
This September deadline was only the first step. All products with digital elements sold in the EU will need to comply with the full CRA security requirements by December 11, 2027. From that day onward, non-compliant products simply cannot be placed on the EU market anymore, causing direct revenue loss for the ill-prepared companies.
For consumers, clear labeling will show you the support period and security specs before you buy a product. Products will also need to be secure by default right out of the box, backed by guaranteed free updates for at least five years.
A side effect is that the EU can now use all the vulnerability reports to build out the EUVD (European Vulnerability Database). This can fill a void left by NIST NVD, which is buried under a giant backlog and announced it would no longer score and enrich every CVE submission. Personally, I believe this is also related to the rising sentiment that the EU should become more technologically independent. With the data from the CRA, the EU has an opportunity to create a database of its own. As the submissions pick up, we will see if the EU is successful with these goals.
For now, we’ll keep an eye on how the systems develop and keep you up to date with developments.
How Aikido helps you keep up with your CRA requirements
While no tool can do your CRA reporting for you, we monitor CISA's Known Exploited Vulnerabilities (KEV) catalog. This means the ‘Exploit Status’ filter in your Aikido feed only pulls the vulnerabilities with a known exploit in the wild, and those are the ones most likely to cause an incident. This allows you to prioritize them and avoid reportable events. You can also open a vulnerability's severity score to see whether "actively exploited in the wild" is listed as a contributing factor. That's your early indicator to check if you’ve been intentionally targeted and reporting obligations apply.
Use CVE Exploitability Analysis to see how a CVE could actually be exploited in your codebase. It’s useful for prioritizing and, if you do end up filing, describing the technical nature of the exploit to regulators and users alike.
While the CRA may seem like more obligations to keep track of, it doesn’t have to become overwhelming. Read more on how Aikido can help you meet CRA requirements.
You can also schedule a call with us, and we can help you out.
