The CRA in five points
- The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847 on the cybersecurity of products with digital elements throughout their lifecycle.
- The reporting obligations in Article 14 have applied since 11 September 2026.
- The manufacturer reports when it becomes aware of an actively exploited vulnerability contained in its product or a severe incident affecting its security.
- An early warning is due within 24 hours and an expanded notification within 72 hours, both from awareness and without undue delay. A final report follows.
- General application starts on 11 December 2027. Reporting is already mandatory; preparing for the rest requires work now.
Content reviewed in September 2026 · .
It is five o'clock on a Friday afternoon. A customer sends logs showing how an attacker used a flaw in your appliance to execute code. Product engineering starts investigating. Security asks which versions are affected. The person who usually speaks to management has already left.
Since 11 September 2026, if the product falls within the CRA and the manufacturer becomes aware of an actively exploited vulnerability, there is also a reporting obligation with specific deadlines. The weekend does not turn these into business days.
The CRA is not yet fully applicable, but since September 2026 it has stopped being solely a regulation to prepare for in the future.
Our cybersecurity calendar for the final stretch of 2026 placed this milestone alongside other regulations. Here we focus on a more specific decision: what a manufacturer must be able to do today when a product security problem emerges.
What is the Cyber Resilience Act?
The Cyber Resilience Act is an EU regulation establishing cybersecurity requirements for products with digital elements made available on the EU market. It covers hardware and software, including components placed on the market separately, where their intended purpose or reasonably foreseeable use involves a direct or indirect logical or physical connection to a device or network.
It addresses design, development and vulnerability handling during the support period. It assigns obligations to manufacturers and other supply chain actors. Certain associated remote data processing solutions can also be covered. Exclusions and sector-specific rules exist: assess the actual product rather than relying on the label “technology business”.
The starting points are Articles 2 and 3 of the Regulation and the European Commission's overview.
What changed on 11 September 2026?
Article 14, covering manufacturers' reporting obligations, became applicable. This earlier deadline does not bring all design, documentation, support and conformity assessment obligations into application at once.
Entry into force
The CRA enters EU law.
Assessment bodies
Chapter IV, Articles 35 to 51, applies.
Reporting
Article 14 is already applicable to manufacturers.
General application
The main product obligations become applicable.
Dates checked against Article 71 and the Commission's Communication C(2026) 5252.
Article 69(3) extends Article 14 reporting to in-scope products placed on the market before 11 December 2027. Selling the product earlier does not exempt it from these notifications.
This does not require retrospective reporting of active exploitation the manufacturer already knew about before 11 September 2026, according to ENISA's FAQs. Distinguish when the product was placed on the market, when the event happened and when the manufacturer became aware.
What must be reported?
Actively exploited
There is reliable evidence that a malicious actor has exploited a vulnerability in a system without its owner's permission. Article 14 concerns a vulnerability contained in the manufacturer's product.
A high severity score or a published proof of concept does not, by itself, establish active exploitation.
Illustrative example: logs and analysis confirm that an attacker is using an authentication flaw in an appliance sold by the company.
Severe and affecting product security
The incident harms or can harm the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or it has led or can lead to malicious code being introduced or executed in the product or a user's systems.
Illustrative example: a compromised update system enables malicious code to be distributed to product users.
These are distinct situations that can overlap. A problem with corporate email does not automatically trigger CRA product reporting. Assess the criteria in Articles 3(42) and 14(5). The examples help explain the decision but do not replace an assessment of the specific case.
The deadlines: 24 hours, 72 hours and afterwards
Information is completed in stages. The early warning is not expected to contain the entire root cause analysis. Nor can it be delayed until the investigation is complete.
Flag the event
Identify the situation and, where applicable, the Member States where the product is known to have been made available. For severe incidents, include whether unlawful or malicious acts are suspected.
Provide what is known
For vulnerabilities: the product and the nature of the exploit and flaw. For incidents: their nature and an initial assessment. In both cases, measures taken, actions users can take and information sensitivity, as applicable.
Complete the analysis
Vulnerability: no later than 14 days after a corrective or mitigating measure becomes available.
Severe incident: within one month of submitting the 72-hour notification.
The vulnerability final report covers its description, severity and impact, available information about the malicious actor and details of measures. The incident report includes its description, severity and impact, the threat or likely root cause, and applied and ongoing mitigation. The CSIRT may request intermediate reports. Article 14(2), (4) and (6).
Both the 24-hour and 72-hour windows start from awareness of the reportable event. They are not 24 hours plus another 72. These are maximum periods, and the requirement to act without undue delay applies. Record when and on what evidence that awareness is reached.
The Commission's published guidance, section 9.1, explains that an initial assessment may be necessary to establish whether a report is required. This does not authorise prolonged triage or waiting for internal approval once the event is known.
Where do you report? ENISA's Single Reporting Platform
The Single Reporting Platform (SRP) is developed, operated and maintained by ENISA, the European Union Agency for Cybersecurity. It has been operational since 11 September 2026. It provides a single channel for reporting to the Computer Security Incident Response Team (CSIRT) designated as coordinator and to ENISA, subject to the Regulation's exceptions on dissemination. Commission confirmation.
Access is through the official SRP portal. ENISA documents the use of EU Login and the Assigned Representative role. Define users, cover for absences and responsibility for maintaining access. Select the coordinating CSIRT according to Article 14(7).
Read the registration and user manuals beforehand. An Assigned Representative in the platform should not automatically be equated with an authorised representative under Article 18.
Waiting for an incident to discover how to access the platform adds an avoidable dependency to a process that already has little room for delay.
One operational detail from ENISA's FAQs, updated on 12 September: the platform's initial 72-hour counter is calculated as 48 hours after the early warning is submitted. ENISA warns that this can show an earlier deadline. Keep your own calculation from awareness; the counter does not change the legal deadline.
The real challenge: being able to report within 24 hours
Could you identify the affected versions within 24 hours? You need more than a sales catalogue. Products, versions, components, technical owners and relevant customers or markets need to be connected.
You also need a vulnerability management process that receives reports from customers, researchers, suppliers and internal monitoring. Someone must assess their reliability, distinguish a flaw from active exploitation and preserve the evidence.
Meeting a 24-hour deadline does not mean writing faster. It means deciding beforehand what to detect, who assesses it, who escalates it, who decides and who reports.
- DetectReceive the report and record its time and source.
- ValidateCheck evidence and the connection to the product.
- ClassifyAssess active exploitation or a severe incident.
- EscalateBring together product, security, legal and management.
- DecideRecord the reasoning and activate the owner.
- NotifySubmit the available information and retain confirmation.
- Investigate / remediateEstablish scope, versions and measures in more detail.
- Update the notificationComplete the information and prepare the final report.
Parallel work: investigation, containment and mitigation begin in the first hours. The sequence shows reporting coordination, not a reason to wait before fixing the problem.
In a small business, one person may hold several roles. What matters is having an owner and a backup for each decision. An approval chain that only works Monday to Friday needs reviewing before the first alert.
Third-party components matter too. Supplier assessment helps establish the contacts, notifications and evidence you will need when a dependency flaw reaches your product.
Practical case: an enterprise appliance manufacturer
An authentication flaw in a distributed version
A European manufacturer sells a file management appliance to businesses in several Member States. It receives a report at 17:00 on Friday. By 18:00, it has reliable evidence of malicious exploitation of a vulnerability contained in its product. In this example, the latter time marks awareness of the reportable event.
- First hours
- The team performs triage, preserves logs and samples, identifies the product owner and checks versions. Security coordinates investigation and containment. The time of awareness is recorded.
- Without undue delay; no later than Saturday at 18:00
- The manufacturer submits an early warning through its assigned user. It provides the required information available and relevant Member States. It does not wait for a patch or for the team to return on Monday.
- Without undue delay; no later than Monday at 18:00
- The notification is expanded with the identified product and versions, the nature of the flaw and exploitation, measures taken and actions users can take. Remaining uncertainties are recorded.
- Afterwards
- Remediation and verification continue. The manufacturer informs affected users and, where appropriate, all users without undue delay, including measures they can take, under Article 14(8). This communication may be needed long before the final report.
If a mitigation becomes available at noon on Sunday, the maximum deadline for the vulnerability final report expires 14 days after that moment. Publishing a patch later does not restart it. The team retains submission records and reviews gaps in detection, inventory or escalation.
Who is affected by the CRA?
Start with the product, its commercial supply and the company's role. This table helps frame the assessment; it does not automatically declare every business in scope.
| Organisation | Review the CRA? | Why |
|---|---|---|
| B2B software manufacturer | Yes | Software supplied on the EU market may be a product with digital elements. Check connectivity, purpose and exclusions. |
| Connected hardware manufacturer | Yes | Assess the device, its software and associated remote functions. |
| IoT manufacturer | Yes | Internet of things devices may be covered, subject to applicable exclusions. |
| Digital component integrator | Yes | It may be the final product's manufacturer. The brand under which it is supplied and modifications matter. |
| SaaS business | It depends | Software as a service is not automatically included. Distinguish cloud services from a product and its remote data processing. |
| Importer or distributor | Yes, according to its role | It has its own obligations under the general timetable. It does not automatically take over manufacturer reporting; assess whether it becomes a manufacturer. |
| Business only using third-party software | Review procurement and dependencies | Use alone does not make it a manufacturer under Article 14. Other obligations and supplier information needs may apply. |
SaaS and cloud: look at the architecture
A remote data processing solution meets this definition where the software is designed and developed by or on behalf of the manufacturer and its absence would prevent the product from performing one of its functions. A remote service enabling device control may qualify. Charging a subscription or using cloud servers is not enough.
Identify who is responsible for the remote software, which product function it supports and the boundary of that dependency. Recitals 11 and 12 and Article 3(2), alongside the Commission's guidance, help assess this. Also review substantial modifications and cases where another actor becomes the manufacturer.
What if I use open-source components?
Using open source does not automatically exclude the final product. The CRA gives specific treatment to free and open-source software developed or supplied outside a commercial activity. That treatment does not simply transfer to a commercial product incorporating it.
An open-source software steward has a specific role providing sustained support for the development and viability of certain projects. It is not synonymous with every contributor or with a manufacturer integrating a library.
Stewards' reporting obligations under Article 24(3) apply from 11 December 2027. A manufacturer using open source cannot wait until then to meet Article 14. Sources: Articles 2(3), 3(14) and 24 and the European Commission.
What about SMEs?
Being a small or medium-sized enterprise does not provide a general exemption. The Regulation includes support and proportionality measures, such as CSIRT reporting assistance and simplified technical documentation for microenterprises and small enterprises under the specified conditions.
Article 64(10)(a) also provides a specific exclusion from the administrative fines regulated there for microenterprise or small-enterprise manufacturers missing the early warning deadline. It does not remove the reporting obligation or create a blanket exemption for all SMEs. Articles 17(6), 33 and 64.
On 27 July 2026, the Commission published guidance with 67 practical examples, use cases, flowcharts and graphs, paying particular attention to microenterprises and SMEs. It helps with scope, modifications and support. Official publication.
Its status needs precision: Communication C(2026) 5252 approves the draft's content and provides for formal adoption once all language versions are available. This article uses that published material as non-binding guidance; the Regulation remains the legal reference.
What should a business do now?
This checklist proposes operational preparation. It does not turn every practice into a formal obligation already applicable, or require the conformity assessment route to have been resolved first. Tick items as you read; selections are neither saved nor sent.
If inventories or owners are missing, a maturity and gap assessment can establish the starting point. A Cybersecurity Master Plan turns gaps into priorities, resources and follow-up.
What changes in December 2027?
From 11 December 2027, product cybersecurity requirements and vulnerability handling processes apply generally, alongside risk assessment, technical documentation, conformity assessment, the EU declaration and CE marking as applicable.
Manufacturers will need to integrate these requirements into development and support. The assessment route depends on the product and its category; not everything requires third-party certification. For earlier products, Article 69(2)'s transition rule is tied to substantial modifications after that date, with the reporting exception explained above.
Today's work should feed that preparation: a reusable inventory, documented decisions and evidence the team can maintain. Reporting now; comprehensive preparation underway. Articles 13, 32, 69 and Annex I.
How do the CRA and NIS2 relate?
The CRA focuses on the security of products with digital elements. NIS2, Directive (EU) 2022/2555, addresses risk management and resilience for certain entities. A manufacturer may need to assess both.
Neither replaces the other, and a CRA submission does not demonstrate compliance with every other reporting duty. Coordinate event assessment and check the recipients, criteria and deadlines of each regime. For context, see ACBSEC's NIS2 guide and the Commission's official NIS2 page.
Frequently asked questions about the CRA
What is the CRA?
The Cyber Resilience Act is Regulation (EU) 2024/2847 on the cybersecurity of products with digital elements made available on the EU market.
When does the Cyber Resilience Act apply?
It entered into force on 10 December 2024. Chapter IV applies from 11 June 2026 and Article 14 from 11 September 2026. General application starts on 11 December 2027.
What changed on 11 September 2026?
Manufacturers’ reporting obligations under Article 14 became applicable. This did not bring forward all product obligations scheduled for 2027.
What must be reported within 24 hours?
An early warning about an actively exploited vulnerability contained in the product or a severe incident affecting its security, without undue delay and no later than 24 hours after awareness.
What must be reported within 72 hours?
An expanded notification with available information and relevant measures, unless already provided. The 72 hours run from awareness of the event, not from the early warning.
Where are CRA incidents reported?
Manufacturers submit mandatory notifications through ENISA’s Single Reporting Platform, operational since 11 September 2026, selecting the appropriate coordinating CSIRT.
Does the CRA affect SMEs?
Yes, if their products and role fall within scope. Support and specific provisions exist for smaller businesses, but being an SME does not provide a general exemption.
Does the CRA cover software?
Yes. It can cover separately supplied software and components. Assess connectivity, purpose, commercial activity and applicable exclusions.
Does it cover SaaS?
Not automatically. Distinguish the cloud service from the product with digital elements and assess whether a remote data processing solution meets the CRA definition.
Does it cover open source?
It depends on the activity and role. Incorporating open source does not exclude a commercial product. Open-source software stewards have specific reporting obligations from 11 December 2027.
What happens on 11 December 2027?
The CRA becomes generally applicable, with product, vulnerability handling, documentation and conformity assessment requirements as appropriate, subject to transitional provisions.
How do the CRA and NIS2 relate?
The CRA focuses on product security; NIS2 on risk management and resilience for certain entities. They can coexist and their obligations must be assessed separately.
What to check today
The CRA's first operational milestone has arrived. A manufacturer needs to prepare for December 2027 and check whether it can recognise a reportable event today, assemble the available information and get it to the people who must act.
A useful exercise for this week: choose a product, assume active exploitation and walk through the process with the people who would respond. Any gaps you find now have a concrete priority.
Official sources
European Commission · Cyber Resilience Act
European Commission · reporting obligations
ENISA · Single Reporting Platform and manuals
ENISA · platform FAQs, 12 September 2026
Commission · guidance publication, 27 July 2026
Communication C(2026) 5252 · draft status
Annex · published guidance, section 9.1 on reporting
Content reviewed on 15 September 2026. Illustrative examples and operational recommendations must be adapted to the product and the company’s role.