From 11 September 2026, manufacturers must report certain actively exploited vulnerabilities and severe security incidents affecting products with digital elements. The CRA vulnerability reporting requirements use a staged process: an early warning within 24 hours, a fuller notification within 72 hours, and a final report after remediation or incident analysis.
When the reporting obligations start
Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, applies from 11 September 2026. This date is earlier than the general application date of 11 December 2027 for most other CRA obligations.
The reporting rules are relevant to products with digital elements that fall within the regulation's scope. They also apply to in-scope products placed on the market before 11 December 2027. Manufacturers should therefore not limit preparation to new product launches planned for the full application date.
The obligation is triggered when the manufacturer becomes aware of a reportable event. The legal deadlines run from that point of awareness, not from the date on which an internal investigation is completed or management formally classifies the event. A practical process must be able to identify when reliable information reached the organisation and preserve that timestamp.
What manufacturers must report
Article 14 creates mandatory reporting for two event types.
Actively exploited vulnerabilities
A manufacturer must notify an actively exploited vulnerability contained in its product when it becomes aware of that vulnerability. The regulation defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner.
This is narrower than every newly published vulnerability and broader than vulnerabilities confirmed only in the manufacturer's own infrastructure. A vulnerability can become reportable because reliable evidence shows exploitation in a product deployment, a customer environment, or another relevant system.
The manufacturer still needs a documented assessment. Useful inputs may include incident-response findings, credible reports from customers or researchers, threat-intelligence evidence, coordinated vulnerability disclosure information, and confirmed exploitation data from suppliers or component maintainers.
Severe incidents affecting product security
A manufacturer must also report a severe incident having an impact on the security of a product with digital elements. Under Article 14, an incident is severe where it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. It is also severe where it has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user's network and information systems.
This definition requires product-specific analysis. A service interruption, authentication failure, data-integrity problem, or malicious-code event may be reportable depending on its actual or potential security impact. Teams should avoid relying only on a generic incident-severity score that was designed for internal IT operations rather than product security.
The three reporting stages
The same basic structure applies to both reportable vulnerabilities and severe incidents, but the final-report deadlines differ.
Early warning within 24 hours
The manufacturer must submit an early warning without undue delay and, in any event, within 24 hours after becoming aware of the event.
For an actively exploited vulnerability, the early warning should indicate, where applicable, the Member States in which the manufacturer knows the affected product has been made available.
For a severe incident, it must also include at least whether unlawful or malicious acts are suspected. The notification should similarly identify relevant Member States where applicable.
The 24-hour stage is not intended to contain a finished root-cause analysis. Its purpose is to communicate the event quickly with the information that is available. Internal procedures should therefore allow submission while technical investigation continues.
Notification within 72 hours
Unless the information was already provided, the manufacturer must submit a fuller notification without undue delay and within 72 hours of awareness.
For an actively exploited vulnerability, this notification includes general information about the affected product, the general nature of the vulnerability and exploit, corrective or mitigating measures already taken, measures users can take, and an indication of information sensitivity where applicable.
For a severe incident, the notification includes available information about the nature of the incident, an initial assessment, corrective or mitigating measures taken, measures users can take, and the manufacturer's sensitivity assessment where applicable.
The 72-hour notification depends on fast access to product and release data. A reporting team should be able to identify affected versions, supported deployments, component provenance, available mitigations, and product availability across Member States without reconstructing these facts manually during the incident.
Final report
For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. It must include a description of the vulnerability, its severity and impact, available information about the malicious actor, and details of the security update or other corrective measure.
For a severe incident, the final report is due within one month after the 72-hour incident notification. It must include a detailed description of the incident and its impact, the likely threat type or root cause, and applied and ongoing mitigation measures.
The CSIRT designated as coordinator may also request an intermediate report containing relevant status updates. The reporting process should therefore remain active between the initial notification and closure rather than treating each submission as an isolated task.
Where notifications are submitted
Notifications are submitted through the CRA Single Reporting Platform established under Article 16 and managed by ENISA. The platform is intended to act as a single entry point rather than requiring manufacturers to submit the same report separately to multiple national authorities.
The manufacturer uses the electronic endpoint of the CSIRT designated as coordinator for the Member State in which the manufacturer has its main establishment in the Union. The notification is also made accessible to ENISA in accordance with the regulation's dissemination rules.
ENISA states that the platform is scheduled to be operational by 11 September 2026. Its current FAQ also indicates that representatives will need an EU Login account and that the dedicated public platform address will be published before launch. Organisations can prepare account ownership and authorised representatives now, while treating current implementation details as subject to change until ENISA publishes the final operational service.
What evidence should be retained
Reporting is a legal submission, but it is also an engineering and governance process. Manufacturers should retain evidence that explains what was known, when it was known, how the event was assessed, and what actions followed.
A useful reporting record includes:
- the initial source of the vulnerability or incident information;
- the awareness timestamp and the reasoning used to establish it;
- affected product names, versions, components, and deployment models;
- evidence of active exploitation or severe product-security impact;
- product availability by Member State;
- decisions about reportability and the accountable decision-makers;
- copies of the 24-hour, 72-hour, intermediate, and final submissions;
- sensitivity markings and any request concerning delayed dissemination;
- corrective and mitigating measures, including user guidance;
- security-update artefacts, test results, approvals, and release timestamps;
- communications with customers, researchers, suppliers, CSIRTs, and ENISA;
- the final root-cause, impact, and remediation analysis.
The record should distinguish facts from assumptions. It should also preserve changes over time so that later reports can explain why the assessment evolved as new evidence became available.
A practical preparation checklist
Manufacturers preparing for September 2026 should establish a minimum operating capability before the first reportable event occurs.
- Assign ownership. Define who receives vulnerability information, who determines whether Article 14 applies, who approves submissions, and who can act outside normal business hours.
- Create a product contact map. Link each supported product family to engineering, security, legal, communications, and management owners.
- Record market availability. Maintain evidence of the Member States in which each affected product has been made available.
- Define the awareness trigger. Document how reports from employees, customers, researchers, suppliers, and monitoring systems enter the formal assessment process.
- Prepare staged templates. Separate the minimum 24-hour information from the additional 72-hour and final-report fields.
- Connect release data. Ensure the response team can retrieve affected versions, SBOMs, component provenance, support status, and mitigation information quickly.
- Prepare platform access. Establish EU Login accounts, authorised representatives, backup submitters, and secure credential handling.
- Preserve evidence automatically. Capture timestamps, decisions, submitted data, approvals, and corrective actions in a controlled record.
- Run a tabletop exercise. Test a scenario involving an exploited third-party component or a severe product incident and measure whether the 24-hour and 72-hour stages are achievable.
- Monitor official updates. ENISA and the European Commission may update platform instructions, FAQs, and guidance as implementation progresses.
Common failure modes
The most significant risk is not lack of legal awareness but an operating model that cannot produce reliable information quickly enough.
Typical weaknesses include treating the 24-hour deadline as the time allowed to complete an investigation, using an IT incident process that has no product-version data, failing to track where products are available, and leaving submission authority with one unavailable person. Other common gaps are uncertainty about the awareness timestamp, inconsistent evidence for active exploitation, and remediation records that are not linked to the submitted report.
A reporting process should also avoid premature certainty. The regulation permits staged reporting because facts develop during investigation. An early warning can state what is known at that time, while later submissions refine the scope, impact, and corrective measures.
Management decisions before September 2026
Technical preparation alone is insufficient. Management should approve the reporting authority model, escalation thresholds, out-of-hours coverage, external communication responsibilities, and the acceptable level of uncertainty at each stage.
For Austrian manufacturers, the designated coordinator will depend on where the manufacturer's main establishment is located in the Union. Organisations with multiple EU entities should confirm which legal entity acts as manufacturer for each product and which establishment determines the relevant reporting endpoint.
The immediate objective is operational readiness: the organisation can recognise a potentially reportable event, preserve the awareness time, assemble the required product facts, make an accountable decision, and submit accurate staged notifications within the legal deadlines. Legal interpretation for specific products or incidents may still require qualified advice, but the supporting evidence and workflow should already exist before an event occurs.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act — Reporting obligations — European Commission
- Commission guidance on the application of the Cyber Resilience Act — European Commission
- Cyber Resilience Act Single Reporting Platform — ENISA