CRA Article 14 reporting is already applicable. Manufacturers need an operational process for identifying qualifying events, determining when awareness occurs, escalating quickly enough to meet the 24-hour and 72-hour deadlines, submitting through the Single Reporting Platform, completing the applicable final report and informing affected users where required.
Article 14 Reporting Is Already Applicable
The CRA reporting timetable is different from the timetable for the Regulation's main product-security requirements. Article 14 has applied since 11 September 2026, even though most CRA provisions apply from 11 December 2027. ENISA's Single Reporting Platform became operational on 11 September 2026 to support the mandatory notifications. Manufacturers should therefore treat Article 14 as a current operational requirement rather than a future readiness task. A company that waits for the 2027 main application date before establishing reporting ownership, escalation routes and platform access could miss an obligation that already applies. Reporting readiness should now sit alongside existing vulnerability-management and incident-response processes.
- Article 14 applies from 11 September 2026.
- The CRA Single Reporting Platform became operational on the same date.
- The wider CRA framework generally applies from 11 December 2027.
- Article 14 should already be part of product-security operations.
Two Types of Events Trigger Mandatory Reporting
Article 14 establishes mandatory notification duties for two different event types. The first is an actively exploited vulnerability contained in a product with digital elements. The second is a severe incident having an impact on the security of a product with digital elements. These are legal trigger categories rather than general labels for every vulnerability or security event. A newly discovered weakness is not automatically reportable merely because it is technically serious, and an operational security event is not automatically a severe incident merely because it caused disruption. Product-security teams therefore need a triage step that tests the available facts against the CRA definitions and Article 14 criteria before assigning the regulatory reporting path.
- Actively exploited vulnerabilities can trigger Article 14 reporting.
- Severe incidents affecting product security can trigger Article 14 reporting.
- Not every vulnerability is an Article 14 report.
- Not every product-security event satisfies the severe-incident test.
The Reporting Clock Starts From Manufacturer Awareness
The CRA measures the 24-hour and 72-hour deadlines from the manufacturer becoming aware of the actively exploited vulnerability or severe incident. Internal awareness handling is therefore a compliance control in its own right. Information can arrive through security monitoring, customers, researchers, suppliers, threat intelligence, external advisories or incident-response investigations. The practical challenge is distinguishing a signal that is still being investigated from the point at which the manufacturer has enough reliable information to be aware of the qualifying event. Organisations should define who can make that determination, how evidence is preserved and how the awareness time is recorded. A lengthy approval hierarchy should not consume the regulatory reporting window.
- Record when potentially reportable information is received.
- Escalate credible information to the Article 14 decision owner.
- Document the evidence supporting the awareness determination.
- Calculate reporting deadlines as soon as awareness is established.
Article 14 Uses a 24-Hour, 72-Hour and Final-Report Sequence
For both actively exploited vulnerabilities and severe incidents, the reporting process begins with an early warning submitted without undue delay and in any event within 24 hours of awareness. A fuller notification follows without undue delay and in any event within 72 hours. The final-report deadline then differs according to the trigger. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after submission of the 72-hour incident notification. The staged structure means the manufacturer can report preliminary but accurate information first and continue the technical investigation afterwards.
- Early warning: within 24 hours of awareness.
- Fuller notification: within 72 hours of awareness.
- Vulnerability final report: no later than 14 days after a corrective or mitigating measure is available.
- Severe-incident final report: within one month after the 72-hour incident notification.
Notifications Go Through the CRA Single Reporting Platform
Article 16 establishes the Single Reporting Platform and Article 14 requires the mandatory manufacturer notifications to be submitted through it. The platform is developed, operated and maintained by ENISA and became operational when Article 14 began applying on 11 September 2026. Manufacturers report through the platform rather than separately submitting the same Article 14 notification to multiple authorities. The workflow also involves the relevant CSIRT designated as coordinator. Platform access, manufacturer registration, assigned representatives and CSIRT selection therefore need to be prepared before a security emergency occurs. A reporting process that exists only as a written policy is incomplete if nobody can actually access and operate the SRP when the 24-hour clock begins.
- Use the CRA Single Reporting Platform for mandatory Article 14 notifications.
- Prepare SRP access before an incident occurs.
- Identify the correct CSIRT designated as coordinator.
- Ensure assigned representatives can submit when required.
Reporting Does Not End With the Regulatory Submission
Article 14 also contains a user-facing duty. After becoming aware of an actively exploited vulnerability or a severe incident affecting product security, manufacturers need to inform impacted users and, where appropriate, all users. Where necessary, they must communicate risk-mitigation and corrective measures that users can deploy. Regulatory reporting and customer communication should therefore be coordinated rather than treated as completely separate workstreams. Product security, support, engineering, legal and communications teams need a shared view of the affected products and versions, the currently available mitigation and the status of any corrective update. Communications should help users reduce risk without unnecessarily disclosing information that could make exploitation easier.
- Identify impacted users.
- Prepare mitigation guidance where necessary.
- Coordinate regulatory and customer communications.
- Keep communications aligned with affected product versions and fixes.
Legacy Products Can Still Create Article 14 Duties
Article 14 is not limited to products first placed on the market after the CRA's main December 2027 application date. The transitional provisions expressly preserve Article 14 for in-scope products placed on the market before 11 December 2027. Current ENISA guidance also states that the manufacturer reporting obligations apply from 11 September 2026. Companies with long-lived software or hardware portfolios therefore need reporting visibility across older products as well as new releases. A legacy product might receive different treatment under other parts of the CRA transition, but that does not remove Article 14 when the product is within scope and the relevant reporting trigger is met.
- Keep relevant legacy products in the Article 14 reporting inventory.
- Do not treat Article 69 as an Article 14 exemption.
- Maintain ownership and version information for older supported products.
- Connect vulnerability intake to the full in-scope product portfolio.
Build the Workflow Before the Next Security Event
A practical Article 14 workflow starts with event intake and triage, continues through legal-trigger assessment and deadline tracking, and ends with final reporting, user communication and evidence retention. The organisation should identify who owns the regulatory determination, who can submit through the SRP, who confirms the relevant CSIRT, who approves user communication and who tracks corrective measures. The process also needs to support staged reporting because complete technical findings may not exist during the first 24 hours. Tabletop exercises are useful because a workflow that appears clear in documentation can fail when teams need to identify the affected product, evidence, Member States, mitigation status, SRP representative and reporting owner at the same time.
- Define intake and escalation ownership.
- Create a 24-hour decision and submission path.
- Prepare information for the 72-hour stage.
- Track corrective measures and final-report deadlines.
- Coordinate user notification and evidence retention.
- Test the workflow using realistic security scenarios.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.