Under the Cyber Resilience Act, manufacturers face a strict new obligation: if you become aware of a severe security incident or an actively exploited vulnerability in your products, you must notify your designated national Computer Security Incident Response Team (CSIRT) and the EU Agency for Cybersecurity (ENISA) within 24 hours.
This initial "early warning" is a cornerstone of the CRA. It’s designed to kickstart a rapid, coordinated response to cyber threats as they emerge across the European Union. For example, if your company discovers that a flaw in your smart security cameras is being used by attackers to view live feeds, the CRA mandates you alert authorities within a day, not after you've developed a fix.
Why CRA CSIRT Reporting Is Now Mission Critical
The EU's Cyber Resilience Act (CRA) isn't just another set of guidelines; it fundamentally rewires the cybersecurity obligations for any organisation selling products with digital elements in the EU market. It marks a major shift away from voluntary best efforts and toward a legally binding framework.
Prompt, transparent communication is no longer just good practice—it's the law. The CRA’s CSIRT reporting requirements are the operational heart of this new regulation, turning a technical task into a critical business function.
Think of it as a coordinated emergency response network for digital products. When a serious vulnerability is discovered and exploited, it triggers a mandatory chain of notifications that pulls everyone—the manufacturer, national authorities, and ENISA—into alignment. For instance, if a German manufacturer of industrial controllers finds an exploited vulnerability, their report to Germany's BSI (the national CSIRT) is quickly shared with other EU countries via ENISA, protecting critical infrastructure across the continent.
Under the CRA, silence is no longer an option. Failing to report a known exploited vulnerability is a direct violation that can result in significant penalties and market exclusion. This makes CSIRT reporting a mission-critical function for maintaining EU market access.
The Key Players in CRA Reporting
To stay compliant, you first need to understand who you're reporting to. Your process will primarily involve two key bodies:
- National CSIRTs: Each EU member state designates a CSIRT to act as the primary contact point for manufacturers within its jurisdiction. When you discover a reportable incident, this is your first port of call. For a company headquartered in Spain, this role is handled by INCIBE. For a business in Ireland, it's the NCSC-IE.
- ENISA (The EU Agency for Cybersecurity): ENISA acts as the central coordinator for the entire system. Once you’ve notified your national CSIRT, that information is channelled to ENISA, which then ensures all other relevant member states are alerted. This hub-and-spoke model saves you from the nightmare of reporting to 27 different countries individually.
Grasping why these obligations are so critical comes down to understanding the principles of regulatory compliance risk management. The CRA effectively elevates product vulnerabilities from purely technical issues to major business risks with serious legal and financial consequences.
Core Reporting Triggers and Initial Deadlines
The CRA sets out clear triggers that activate your duty to report. The table below gives a high-level summary of the primary events that mandate a report and the extremely tight initial notification window.
CRA Reporting Triggers and Initial Deadlines
This table summarises the primary events that mandate a report to a CSIRT under the Cyber Resilience Act and the first notification window.
| Reportable Event | Initial Notification Deadline | Primary Recipient | Example |
|---|---|---|---|
| An actively exploited vulnerability. | Within 24 hours | National CSIRT/ENISA | Your team finds malware in the wild that uses a flaw in your VPN software. |
| A severe incident impacting product security. | Within 24 hours | National CSIRT/ENISA | A DDoS attack on your update servers prevents users from patching a known flaw. |
| A vulnerability found in a third-party component. | Without undue delay | The component's maker | You discover a flaw in an open-source library used in your product; you must inform the library's maintainers promptly. |
As you can see, the timelines demand well-rehearsed internal processes. There’s simply no time to figure it out once an incident happens. You can read more about the current state of play regarding these regulations.
Who Reports and What Triggers a Report
The Cyber Resilience Act casts a wide net, fundamentally changing how security responsibilities are managed. For any technology company, the first two questions are always the most urgent: ‘Does this apply to my products?’ and ‘Which specific events force us to act immediately?’ Nailing down the answers is the foundation for building a compliant reporting process.
The answer to that first question is refreshingly direct. The reporting obligation falls squarely on the manufacturer of any ‘product with digital elements’ placed on the European Union market. This is a deliberately broad definition, designed to cover today's massive ecosystem of connected technology.
That means everything from consumer gadgets like smart speakers and connected thermostats to complex industrial control systems and enterprise software suites. If you create a product with software or firmware that can connect to a network and you sell it in the EU, the CRA’s reporting duties apply to you. For example, a French company that manufactures smart lighting systems sold across Europe is considered a manufacturer and must comply.
Identifying Your Reporting Triggers
Not every bug or glitch demands a 24-hour alert to European authorities. The CRA makes a crucial distinction between minor issues and significant threats that require a coordinated response. Your primary triggers for a CSIRT report are:
- An actively exploited vulnerability: This is a security flaw in your product that attackers are already aware of and are actively using to compromise systems.
- A severe incident: This refers to a security event that has a significant impact on your product or its users, even if the root cause isn't a specific vulnerability in your code. A practical example could be a misconfigured cloud storage bucket exposing sensitive user data from your connected product.
Think of it as the difference between a leaky tap and a burst water main. A minor UI bug is a leaky tap—you fix it in the next update. But a vulnerability letting attackers remotely seize control of thousands of smart locks? That's a burst water main demanding an immediate, all-hands-on-deck emergency response. This is precisely what triggers the CRA CSIRT reporting requirements.
According to the CRA, an ‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that an attacker has leveraged it to compromise a system or network. This official definition grounds your response in observable reality, not theoretical risk.
Practical Examples of Reporting Triggers
Learning to distinguish between a routine bug and a reportable incident is a critical skill your team must develop. Let’s walk through some practical examples to make the distinction crystal clear.
Scenario A: The Non-Trigger
A user reports that a specific menu in your photo-editing software occasionally freezes, requiring a restart.
- Analysis: This is a performance or usability bug. It doesn't compromise security in any meaningful way (confidentiality, integrity, or availability). This would be handled through your normal patching cycle, not a CSIRT report.
Scenario B: The Clear Trigger
Your security team discovers a flaw in your smart camera’s firmware that allows an unauthenticated attacker to access the live video feed. Online forums show proof-of-concept code and chatter from threat actors discussing how to use it.
- Analysis: This is a textbook example of an actively exploited vulnerability. It has a severe impact on user privacy and confidentiality. This mandates an immediate 24-hour notification to your CSIRT and ENISA.
Understanding this distinction is vital. As an ES-based IoT vendor, for example, you must grasp the CRA's CSIRT stats: from 2026, you will report exploited vulnerabilities and severe incidents affecting products with digital elements, such as firmware flaws causing impacts for over 1,000 users. This represents a historical shift; pre-CRA, vulnerability disclosure in Spain had an average seven-day lag, but this will now be under 72 hours, a change which ENISA simulations project could cut exploit rates by 45%. This is crucial, given that a 2025 INCIBE report noted 85% of ES attacks hit unpatched IoT devices. You can read more about the current state of play regarding these regulations to better prepare your teams.
Under the Cyber Resilience Act, time isn't just a factor—it's the single most critical element of compliance. The regulation introduces a fast-paced, multi-stage reporting lifecycle that forces organisations to act with incredible speed and precision the moment a serious issue comes to light.
This isn't your typical technical clean-up. Incident response under the CRA is a highly structured communication protocol with European authorities. You have to master three key reporting milestones: the 24-hour 'early warning', the 72-hour 'main notification', and the subsequent final reports. Getting this rhythm right is fundamental to meeting your CRA CSIRT reporting requirements.
The flow chart below maps out the basic process, from a manufacturer's discovery to the mandatory reporting action.
This simple diagram highlights a core principle of the CRA: awareness of a trigger event immediately starts the clock, and that clock leads directly to a mandatory report.
The 24-Hour Early Warning
The second you become aware of either an actively exploited vulnerability or a severe security incident, the clock starts ticking. You have just 24 hours to submit an "early warning" to both your designated national CSIRT and to ENISA.
This initial report isn't meant to be a full forensic analysis. Think of it as an emergency flare. Its primary job is to give authorities a high-level, immediate heads-up so they can start coordinating a potential EU-wide response, even before you have all the answers.
Let's say you manufacture smart thermostats. Your security team finds forum posts with proof-of-concept code that lets attackers remotely control home heating systems, and your own telemetry confirms it's being actively used in the wild. You must send an early warning within 24 hours of that discovery.
Your initial alert just needs the basics:
- Your company’s name and contact details.
- The affected product name and version (e.g., "SmartComfort Thermostat Model X, firmware v2.1").
- A brief, high-level description of the vulnerability or incident.
- Any immediate mitigation advice you can give to users.
The 72-Hour Main Notification
After sending the early warning, your team needs to dig deeper. Within 72 hours of that initial awareness, you have to follow up with a "main notification" that adds crucial technical context to your first report.
This is where you provide the substance. It requires a much more thorough assessment of the vulnerability's nature, severity, and potential impact.
Going back to our smart thermostat example, the 72-hour report would need to add some serious specifics:
- A technical description of the vulnerability, including its type (e.g., "unauthenticated remote code execution").
- The estimated severity, which often means including a CVSS (Common Vulnerability Scoring System) score. A flaw like this would almost certainly be rated 'Critical'.
- Details on the potential impact, like the ability for attackers to crank up heating to dangerous levels or shut it down completely in the dead of winter.
Final Reports and Resolution
The CRA reporting clock doesn't stop at 72 hours. The final stage is all about providing closure and detailing the long-term fix, though the deadlines here are conditional.
Imagine your team detects an actively exploited vulnerability in one of your connected IoT devices. Within 24 hours of becoming aware, you notify the designated CSIRT and ENISA. By the 72-hour mark, you submit the more detailed 'main' notification. Because the vulnerability was actively exploited, you must then follow up with a final report within 14 days of making a patch or mitigation available. For severe incidents, the final wrap-up is due one month after the 72-hour report.
A complete final report proves the threat has been properly handled. It should cover the root cause, the mitigation steps you took, and clear instructions for users to apply the patch. To get a better handle on the full timeline, check out our guide on important CRA deadlines between 2025 and 2027.
How to Report: Process and Data Requirements
Knowing you have to report an incident is one thing; understanding the exact process, formats, and deadlines is a completely different challenge. The Cyber Resilience Act doesn't just deal in high-level principles—it specifies the practical mechanics of how and what you need to communicate during a security event.
The whole system is designed for efficiency. Instead of a chaotic scramble to notify multiple national authorities, the CRA establishes a single point of contact for all incident and vulnerability reporting.
At the core of this system is ENISA's single reporting platform. This will be the one and only place you submit your notifications. You won’t have to waste time figuring out which national CSIRT needs what information. Your job is to get one clear, comprehensive report into the system, which then handles the coordination.
The Coordinated Reporting Mechanism
The CRA's process is built on a simple but powerful idea: report once, inform many. This completely removes the administrative nightmare of individually notifying every single EU member state that might be affected by an incident.
In practice, the reporting cascade works like this:
- You submit your full report through the ENISA single reporting platform. For example, your incident response lead logs into the secure portal and fills out the web-based form.
- The platform automatically directs your submission to the designated national CSIRT coordinator for your organisation.
- Your national CSIRT then reviews the report and disseminates it to other relevant national CSIRTs and EU bodies through the same platform.
This coordinated model ensures every necessary authority gets the alert without burying your team in bureaucracy during a crisis. It frees you up to focus on what really matters: investigating the incident and shipping a fix.
Required Data for Your Notifications
An effective report is all about providing the right information from the start. Vague or incomplete submissions just create more work, leading to follow-up questions and delays when time is critical. To be prepared, you need to know exactly which data fields are mandatory for both your 24-hour and 72-hour notifications.
Let's walk through a scenario. It's 2027, and your company's embedded software, shipped across the EU, has a severe incident affecting over 10,000 users in Spain and Portugal. The CRA mandates a very specific escalation path. You must notify your national CSIRT coordinator and ENISA via the single platform. Your 24-hour early warning alerts them to the breach, but it's the 72-hour main report that must detail the impact on confidentiality, integrity, or availability.
For a company based in Spain, the national CSIRT coordinator is INCIBE. They would handle the initial intake and use the ENISA platform to share the cross-border details with their counterparts in Portugal. This coordination is critical, especially since statistics show that 65% of IoT attacks often span multiple borders. Learn more about the EU's approach to product cybersecurity compliance.
Your main (72-hour) notification must be structured and packed with detail. The table below gives you a sample template you can use as a tangible starting point for building your internal reporting processes.
Sample CRA CSIRT Notification Template
This table shows an example structure for the main (72-hour) notification, outlining the key data fields manufacturers must provide.
| Data Field | Description | Example Entry |
|---|---|---|
| Product Identification | The specific product name, model, and software/firmware version affected. | SmartHome Hub G3, Firmware v4.2.1 |
| Vulnerability Details | Technical information about the flaw, including its CWE type and CVSS v3.1 score. | CWE-798: Use of Hard-coded Credentials, CVSS: 9.8 (Critical) |
| Incident Description | A clear summary of the incident, how it was discovered, and its current status. | A hard-coded admin password was discovered, allowing unauthenticated remote access. Actively exploited. |
| Affected Member States | List of EU countries where affected users or systems are known to be located. | Germany, France, Spain, Italy |
| Impact Assessment | The effect on confidentiality, integrity, and availability (CIA). | Compromises confidentiality (user data access) and integrity (system control). |
| Mitigation Measures | Any immediate steps taken or recommended to reduce risk for users. | Advised users to disconnect the device from the internet until a patch is deployed. |
Having this data ready to go is non-negotiable. Building a complete CRA compliance evidence pack in advance ensures your team can pull this information together quickly when the 72-hour clock is ticking.
Your Practical Compliance Checklist for 2027
Understanding the CRA's legal text is one thing; operational readiness is what actually guarantees compliance. When you're facing a 24-hour deadline, you don't have time to figure things out during a live incident. This checklist breaks down the theory into a practical implementation plan.
1. Establish Key Contacts and Teams
First, build the human infrastructure for reporting. You need to know who to call externally and who’s responsible internally long before a crisis hits.
- Identify Your Lead National CSIRT: Your main reporting contact is the designated CSIRT coordinator in the EU member state where your main establishment is located. If your company is headquartered in Spain, for example, this is INCIBE. Find your designated CSIRT now.
- Form a Dedicated Response Team: Create an internal incident response team with crystal-clear roles. For example, specify that the Head of Product Security is responsible for assessing severity, a technical writer drafts the report, and the CISO gives final approval before submission.
2. Develop and Pre-Approve Reporting Templates
That 24-hour clock starts ticking fast. You won't have time to write a report from scratch. Preparing templates in advance is one of the single most effective ways to guarantee both speed and accuracy.
Use the sample template from the previous section as a starting point. Create pre-filled documents for both the 24-hour "early warning" and the 72-hour "main notification". Populate them with your company details, product lines, and contact information. Get these templates approved by legal and management now, so they are ready when you need them.
A pre-approved template is more than a document; it's a pre-negotiated consensus. It eliminates internal debates over wording and content during a high-pressure event, allowing your team to focus solely on the technical facts of the incident.
This step alone can slash your response time, making those tight deadlines far more manageable. For organisations still mapping out their compliance journey, it's also helpful to explore the role of CRA harmonised standards in providing a clear framework for these processes.
3. Implement Monitoring and Automation Tools
You can't report a vulnerability you don't know about. Robust monitoring is the bedrock of compliance. This means putting tools and processes in place that give you continuous visibility into your products' security posture.
- Continuous Vulnerability Scanning: Use Software Composition Analysis (SCA) tools to constantly monitor your code and its dependencies for newly disclosed vulnerabilities.
- Automate Draft Reports: Configure your security tooling to automatically generate a draft incident report whenever a high-severity or actively exploited vulnerability pops up in a production environment. For instance, if your SCA tool flags a critical flaw in a library like OpenSSL that is known to be exploited, it can trigger a ticket in your system with a pre-populated report draft.
4. Run Realistic Simulation Drills
A plan on paper is not enough. You have to pressure-test it. Regular simulation drills are the only way to build the muscle memory your team needs to meet the CRA’s demanding timelines.
Run tabletop exercises that simulate a real-world discovery of an actively exploited vulnerability. Start the 24-hour clock and make your team execute the full reporting process. A practical drill could involve a scenario where a security researcher privately discloses a critical remote code execution flaw in your flagship product. The team must then race against the simulated clock to validate the finding, draft the early warning, get approval, and submit it.
5. Integrate CRA into Broader Security Policies
Finally, make sure your CRA reporting process doesn't exist in a silo. It must be woven into your organisation's bigger security and disclosure frameworks.
Your Coordinated Vulnerability Disclosure (CVD) policy should specify that any incoming report meeting the CRA criteria immediately triggers your internal CSIRT notification workflow. Likewise, your post-market surveillance activities need a clear protocol for escalating security findings to the incident response team. For specialised assistance in meeting all regulatory demands, explore dedicated Compliance Solutions.
Your CRA Reporting Questions, Answered
Once you move from the legal text of the Cyber Resilience Act to building real-world processes, practical questions always come up. The theory is one thing; day-to-day operational reality is another. Getting the details right in these grey areas is what separates a smooth compliance process from a scramble.
Here, we'll tackle some of the most common and pressing questions teams have about CRA reporting obligations.
What Happens If We Notify the CSIRT but a Patch Is Not Ready?
The CRA prioritises transparency and proactive communication. If you hit the reporting deadline but your patch isn’t ready, you must still submit the report on time. Your duty is to be upfront about the situation.
In your report, you need to give a clear status update. For example: "We have confirmed the vulnerability and its severity. A patch is currently in development and undergoing QA testing. We anticipate releasing firmware version 2.5.1 to address this issue within the next 7 days. In the meantime, we advise users to disable remote access features." This kind of honest communication is far better than silence.
Does Reporting to a CSIRT Make the Vulnerability Public Immediately?
No, it doesn't. The initial reports you send to your national CSIRT and ENISA are confidential. This isn't about naming and shaming; the immediate goal is to allow a coordinated, behind-the-scenes response among national authorities and to figure out the potential EU-wide impact.
The entire process is built to align with Coordinated Vulnerability Disclosure (CVD) principles. This means public disclosure is usually held back until a patch is developed and available, preventing attackers from getting a roadmap to an exploit before users can protect themselves.
How Does This Relate to Our Existing Bug Bounty Programme?
Think of your bug bounty programme as a critical input to your CRA compliance workflow. It's one of the best tools you have for finding serious vulnerabilities before attackers do.
When a researcher reports a vulnerability through your programme that fits the CRA criteria—for instance, it's being 'actively exploited' or is a 'severe incident'—that's when your 24-hour reporting clock starts ticking. You absolutely must have a bulletproof process to escalate these findings from your bug bounty platform to your incident response team, kicking off the formal CSIRT reporting workflow without any delay. A practical example would be a researcher submitting a video proof-of-concept showing how to bypass authentication on your smart doorbell. The moment your team validates that it works, the clock starts.
What Are Our Responsibilities As an Importer or Distributor?
While the manufacturer carries the primary reporting burden, importers and distributors are not off the hook. You are a crucial link in the safety chain and have your own distinct obligations. If you learn about a reportable incident involving a product you’re selling on the EU market, you are legally required to inform the manufacturer 'without undue delay.'
For example, if a large retail chain acting as an importer receives multiple customer complaints about their smart home hubs being hacked, they cannot ignore it. They must promptly notify the product's manufacturer so the CRA reporting process can be initiated. Turning a blind eye to this could leave you exposed to penalties and significant legal liability.
Regulus provides a unified platform to help you navigate the complexities of the Cyber Resilience Act. Our solution helps you assess applicability, classify products, and generate a tailored requirements matrix, including ready-to-use templates for documentation and a step-by-step roadmap to turn findings into an actionable compliance plan. Gain clarity, reduce costs, and confidently place compliant products on the European market with our software, which you can explore at https://goregulus.com.
