What happened
Regulation (EU) 2024/2847 entered into force on December 10, 2024. Article 14 reporting obligations apply from September 11, 2026. Most other substantive CRA obligations apply from December 11, 2027. The earlier reporting date means manufacturers must operate compliant notification processes before the regulation’s broader product-security requirements become fully applicable.
Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents affecting product security. The reporting sequence requires an early warning within 24 hours, a fuller notification within 72 hours and a final report within 14 days after a corrective measure is available for an actively exploited vulnerability or within one month for a severe incident.
ENISA states that the Single Reporting Platform becomes the technical tool for mandatory CRA reporting from September 11, 2026. Ireland’s NCSC says no pre-registration is required and account creation occurs during the first submission. Ireland’s NCSC says an emergency email fallback applies only when ENISA officially declares the Single Reporting Platform offline. An email alert does not remove the requirement to make the formal platform submission after service is restored.
Reports are addressed to the relevant coordinating CSIRT and are made available to ENISA under the CRA process, subject to defined exceptional grounds for delaying wider dissemination. Attribution posture: This is a regulatory implementation development; no threat actor or incident responsibility is at issue.
Why this matters now
The reporting provisions begin before most other substantive CRA requirements. Organisations cannot defer incident-notification design until the broader December 2027 compliance programme. A product may trigger reporting through active exploitation or a severe security incident even while other lifecycle controls are still progressing towards their later application date.
The 24-hour early-warning clock requires a operating model that joins product security, incident response, legal, engineering, customer communications and the responsible manufacturer entity. A technically accurate investigation delivered after the deadline is not an adequate substitute for a timely initial notification followed by the fuller statutory stages.
The obligation follows products with digital elements made available in the EU, so exposure is not limited to EU-headquartered companies. Global hardware and software businesses need a mapped legal-entity and product portfolio, including responsibility for components, authorised representatives and relevant open-source stewardship arrangements.
The decision for security leaders
Make CRA reporting an operational incident process, not a policy document. Assign authority to issue an early warning with incomplete but defensible information, define the evidence threshold for active exploitation and severe incidents, and establish how later findings update the initial submission.
Build a decision-grade register connecting each EU-market product to its manufacturer entity, product-security owner, support period, responsible CSIRT and notification stakeholders. Resolve ambiguity now; a 24-hour clock leaves little time to determine which affiliate, distributor or authorised representative owns the filing.
Approve one integrated workflow for regulatory notification and user communications. The process should preserve timestamps, awareness decisions, corrective-measure availability and the rationale for scope determinations so legal and security leadership can later defend both the content and timeliness of the response.
Evidence of closure
- An approved RACI identifies the reporting officer, deputies and submission authority.
- The product register records CRA scope and responsible legal entity for every EU-market product.
- The incident workflow timestamps the 24-hour and 72-hour decision gates.
- Controlled copies are available to the designated reporting officer and deputies.
The Security.io assessment
Confidence is high on the commencement date and reporting stages because the regulation, European Commission, ENISA and national guidance align. Operational details may continue to evolve as the platform begins production use, so teams should retain named owners for monitoring ENISA and coordinating-CSIRT updates.
This is not a broad claim that every vulnerability discovered after the start date requires notification. The trigger is an actively exploited vulnerability or a severe incident having an impact on product security. Organisations need documented triage criteria that distinguish those events from ordinary backlog findings while preserving a rapid escalation path when exploitation status is uncertain.
The immediate risk is governance latency. Product security may identify the technical event, but the reporting clock can be lost while teams debate legal-entity responsibility, severity, customer scope or submission authority. A successful readiness programme therefore proves decision speed and traceability, not merely awareness of the statutory deadlines.
Questions for the morning meeting
- Which legal entities are manufacturers for each digital product placed on the EU market?
- Who can authorise a CRA early warning within 24 hours?
- Can product security distinguish active exploitation from ordinary vulnerability exposure?
- What is the approved fallback if the Single Reporting Platform is unavailable?