What has applied since 11 September 2026
The Cyber Resilience Act – CRA for short – is not just a topic for 2027. Although many of the comprehensive product requirements will only become fully applicable later, the reporting obligations for actively exploited vulnerabilities and severe security incidents have already applied since 11 September 2026.
The European Commission sets out clear deadlines: an early warning must generally be submitted within 24 hours of becoming aware, and a more detailed notification within 72 hours. For actively exploited vulnerabilities, a final report is then due no later than 14 days after a corrective or mitigating measure is available; for severe incidents, the final report follows within one month of the 72-hour notification.
Who is affected by the Cyber Resilience Act?
The focus is on manufacturers of products with digital elements who make such products available on the EU market. This can concern classic hardware, but also software and connected products. What matters is not company size alone, but role, product and how the product is made available on the market.
For many mid-sized companies, the first questions are therefore: do we develop or distribute our own software? Do we integrate software into machines or devices? Do we place products on the market under our own name? Which external components and open-source parts do they contain? Clarifying these roles is a prerequisite for any further CRA planning.
Open-source software stewards have their own timeline; according to the EU guidance, their corresponding reporting obligations apply from 11 December 2027. Where legal questions are unclear, the specific classification of a company or product should be agreed with appropriate legal advisers.
24 hours, 72 hours, final report: the deadlines at a glance
Early warning within 24 hours
As soon as an actively exploited vulnerability or a severe incident becomes known, the clock starts. The early warning is meant to inform quickly and does not yet need to contain every technical detail.
More complete notification within 72 hours
Within 72 hours, additional information is expected – for example on the affected product, the nature of the vulnerability or incident and any corrective or mitigating measures already taken.
Final report
For actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For severe security incidents, a period of one month after the 72-hour notification applies.
The official rules and deadlines are summarised on the European Commission's page on CRA reporting obligations.
Reporting via the ENISA Single Reporting Platform
A central Single Reporting Platform (SRP) has been set up for notifications. It is operated by ENISA and is intended to prevent manufacturers from having to report the same case separately to numerous authorities. The platform has been in operation for mandatory CRA notifications since 11 September 2026.
It is important for companies not to organise access only while an incident is under way. Responsible persons, EU Login accounts, roles, deputies and internal approvals should be defined and tested in advance. ENISA provides information on using the platform on its Single Reporting Platform page.
What the CRA changes in everyday IT
Above all, the short deadlines change the internal pace. A security advisory must not sit in a personal mailbox for days. A ticket must not move back and forth between development, IT and management without it being clear whether a reporting obligation has been checked.
- Monitoring: Vulnerabilities and incidents must be detected reliably.
- Product inventory: The company must know which versions, components and dependencies may be affected.
- Assessment: Technical teams need criteria for when a vulnerability must be considered actively exploited or an incident severe.
- Escalation: Security, development, management and, where applicable, legal/compliance need defined channels.
- Customer communication: Corrective measures and updates must quickly be put into an understandable form.
The internal processes that should be in place now
1. Assign responsibility
One person or function should manage the CRA reporting process. This includes a deputy, so that holidays or illness do not put a deadline at risk.
2. Define the initial technical assessment
Which information does the security or development team need in the first two hours? Product version, affected component, known exploitation, reachable systems and possible impact should be easy to gather quickly.
3. Test the 24-hour process
A tabletop exercise with a fictitious incident quickly shows whether contacts, responsibilities and approvals work realistically.
4. Document evidence and decisions
Not only the notification itself, but also points in time, technical findings, risk assessment and measures taken should be documented in a traceable way.
The software supply chain and dependencies are becoming more important
Modern products rarely consist solely of in-house code. Libraries, firmware, open-source components, cloud services and supplier modules can all be part of a product. If a critical vulnerability in a component becomes known, a manufacturer must be able to answer quickly which of its own products and versions are affected.
That is why software bills of materials, version inventories, supplier contacts and automated vulnerability information are gaining importance. A good overview of the supply chain significantly shortens the time between "new CVE published" and "we know whether we are affected".
Common mistakes when preparing for the CRA
- "This only affects large manufacturers": Classification depends on role and product, not just on the number of employees.
- Writing only a legal policy: Without technical detection and operational processes, the document is of little help in an emergency.
- No complete product inventory: Without knowing components and versions, companies can only assess whether they are affected slowly.
- Not testing reporting access: Accounts, roles and deputies should be checked before an incident occurs.
- Not involving suppliers: Suppliers must be able to provide security information quickly and in a structured way.
CRA quick check for companies
- Has it been clarified whether, and for which products, your company is considered a manufacturer?
- Is there an up-to-date register of products, versions and components?
- Is it defined who assesses a possible reporting obligation from a technical and organisational perspective?
- Can a reliable initial notification be organised within 24 hours?
- Are ENISA SRP access, deputies and approval channels prepared?
- Is there a process for security advisories, updates and customer information?
- Has the procedure already been tested with a realistic scenario?
Conclusion: CRA compliance starts with working IT and security processes
Since 11 September 2026, the Cyber Resilience Act has become a practical reality for the manufacturers concerned. The reporting deadlines show that vulnerability management, incident response, product inventory and documentation need to work together more closely.
büKOM Systemhaus GmbH supports companies with IT security, vulnerability management, monitoring, technical reporting and escalation processes and organisational preparation. This does not replace legal classification – but it creates the technical basis for requirements to be implemented at all when it matters.