Cyber Resilience Act Reporting Obligations

09/03/2026

    CRA Article 14 answers a practical question for manufacturers of products with digital elements: if you discover an issue is being actively exploited or a serious security incident occurs, who do you notify, how quickly, and what information must the report contain?

    In this article, we examine the different reporting tracks available to manufacturers when notifying CSIRT‑ENISA, depending on the nature and severity of the incident or vulnerability. For more in‑depth information on the CRA, readers can consult our EU Cyber Resilience Act Guide or visit our CRA Hub, where they will find detailed insights into the regulation and learn more about the services we provide to support manufacturers in preparing for CRA compliance.

     

    CRA Article 14: Manufacturer Reporting Obligations under the CRA

    Article 14 establishes the manufacturers’ reporting obligations, with two parallel reporting tracks that apply when manufacturers become aware of specific security events. 

     

    Track 1: Actively exploited vulnerabilities

    Actively exploited vulnerabilities refer to situations where a malicious actor is already taking advantage of a flaw in the product to cause harm. This track applies when there is confirmed, ongoing exploitation affecting users or other persons, such as an authentication bypass enabling unauthorized access or privilege escalation leading to data theft in a user‑facing component. When manufacturers detect such active misuse, they must quickly assess the nature and impact of the exploitation and initiate immediate corrective or mitigating measures to protect users and limit further damage.

    Vulnerability reporting timeline (Article 14(2))

     

    0h – Awareness
    You become aware of an actively exploited vulnerability.
    24h – Early warning notification (≤ 24 hours)
    • Send fast, even if incomplete
    • Include actively exploited status
    • Include (where applicable)
    • Member States where product is available
    72h – Vulnerability notification (≤ 72 hours)
    • More detail (unless already provided)
    • Include general product info (as available)
    • Include general nature of exploit + vulnerability
    • Include corrective/mitigating measures taken
    • Include measures users can take now
    • Include (where applicable) sensitivity of notified information
    14d – Final report (≤ 14 days after fix/mitigation is available)
    • Include vulnerability description
    • Include severity + impact
    • Include (where available) malicious actor information
    • Include security update / corrective measures details

     

    Track 2: Severe incidents impacting product security

    Severe incidents refer to cybersecurity events that affect, or could affect, the security of the product or the manufacturer’s development, production, or maintenance processes. These incidents may not involve active exploitation but are considered severe when they pose a significant cybersecurity risk for users or other persons. Examples include malicious code injected into updates, compromise of code‑signing keys or signing services, or breaches of the source‑code repository or build system that impact shipped artifacts.
    An incident is classified as severe when it meets either of the following conditions:

    • It harms the product’s ability to protect the availability, authenticity, integrity, or confidentiality of important or sensitive data or functions, or
    • It leads (or could lead) to the introduction or execution of malicious code in the product or in a user’s systems.

     

    Severe Incident Reporting Timeline (Article 14(4))

     

    0h – Awareness
    The manufacturer becomes aware of a severe incident.
    ≤ 24 hours – Early warning
    Submit an early warning including:
    • Whether unlawful or malicious acts are suspected
    • An initial assessment
    • Member States where the product is available (if applicable)
    • Mitigation or corrective measures already taken
    ≤ 72 hours – Incident notification
    Submit an incident notification including (where available):
    • Nature of the incident
    • Severity and impact
    • Detailed description
    • Likely threat type or root cause
    • Measures users can take
    • Sensitivity of the notified information (if applicable)
    ≤ 1 month – Final report
    Submit a final report including:
    • Applied and ongoing mitigation measures
    • Consolidated information from the completed investigation

     

    How and where to report: Single Reporting Platform

    For both tracks, manufacturers report via the Single Reporting Platform. The notification becomes simultaneously accessible to the national coordinator CSIRT and to ENISA.

    Deadlines, applicability and legacy products

    Reporting obligations under Article 14 apply from 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents for all products with digital elements that fall within the scope of the CRA, including products placed on the market before 11 December 2027 (see Article 69(3)).

    Notification to Impacted Users

    After becoming aware of an actively exploited vulnerability or a severe incident, manufacturers must inform impacted users.

    Reporting vulnerabilities in third‑party components

    Where a product contains an actively exploited vulnerability originating from an integrated component, the product manufacturer must notify it. The component manufacturer must also notify it if the component has been placed on the market.

    Delegated acts and CSIRT coordination

    A delegated act supplements the CRA by defining terms and conditions under which the first (coordinator) CSIRT receiving a notification may delay sharing it with other Member States’ CSIRTs. See the official text here: Delegated act.

    Practical guidance for manufacturers

    • Getting started: build awareness and roles through CRA Training and read the CRA Essential Guide.
    • Process in place: use a gap analysis with the CRA Readiness Assessment.
    • High maturity: prepare for assurance schemes such or Cyber Resilience Mark or EUCC Certification.
    • End‑to‑end support: follow the maturity pathway on our CRA Compliance Services page.

    FAQ about CRA Reporting

    1) What must manufacturers report under CRA Article 14?
    Actively exploited vulnerabilities and severe security incidents, submitted via the Single Reporting Platform.

    2) How fast do manufacturers need to report?
    The clock starts when the manufacturer becomes aware of the vulnerability or incident. Follow the specific timelines defined by the platform and guidance once available.

    3) Do legacy products need to be reported?
    Yes, if they fall within the CRA’s scope, including products placed on the market before 11 December 2027.

    4) What if the vulnerability comes from a third‑party component?
    Both the product manufacturer and the component manufacturer (if the component is placed on the market) have notification duties.

    5) Do manufacturers need to notify users as well as authorities?
    Yes. Impacted users must be informed after the manufacturer becomes aware of the issue.

    Additional information reading

    Applus+ uses first-party and third-party cookies for analytical purposes and to show you personalized advertising based on a profile drawn up based on your browsing habits (eg. visited websites). You can accept all cookies by pressing the "Accept" button or configure or reject their use. Consult our Cookies Policy for more information.

    Cookie settings panel