Understanding the reporting obligations under the Cyber Resilience Act

21 hours ago

5 min read

The European cybersecurity framework for digital products is evolving significantly, driven by the rollout of the Cyber Resilience Act (CRA). Under the CRA, cybersecurity rules apply to all products with digital elements (PDEs) made available on the European Union market, requiring manufacturers to take full responsibility for cybersecurity across the entire product lifecycle. PDEs include hardware and software products, alongside their associated remote data processing solutions.

Although the CRA's core requirements apply starting December 11, 2027, mandatory reporting obligations under Article 14 have already taken effect as of September 11, 2026, making it legally required for manufacturers of connected products to report severe security incidents and actively exploited vulnerabilities.

Core concepts: vulnerability and incidents

The Cyber Resilience Act (CRA) mandates that manufacturers adopt a secure development lifecycle, ensuring cybersecurity is integrated throughout the planning, design, production, and maintenance phases. As the CRA applies to a wide range of products, it introduces varying levels of criticality, dictating the necessary rigor for controls and conformity assessment methods. Despite these differences, core obligations apply to all, with vulnerability management being a primary requirement.

A vulnerability is a weakness in a product with digital elements that could be exploited by an attacker. The CRA centralizes vulnerability management, requiring continuous monitoring, assessment, and remediation. Given that many products rely on third-party components, vulnerabilities are common; the critical challenge lies in identifying and patching the most dangerous ones.

The CRA centralizes vulnerability management, requiring continuous monitoring, assessment, and remediation.

An unpatched or undiscovered vulnerability may be exploited, causing adverse impacts on the product and potentially leading to an incident. The CRA requires manufacturers to report such events when evidence of exploitation or significant harm emerges. Specifically, manufacturers must identify and report:

Actively exploited vulnerabilities: situations where there is reliable evidence that a malicious actor has exploited a flaw without the system owner's permission.
Severe incidents: events that negatively impact, or have the potential to impact, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive data or functions, or that lead, or could lead, to the introduction or execution of malicious code within the product or its users' network and information systems.

Mandatory reporting active since September 11, 2026

Since September 11, 2026, reporting is mandatory for both severe incidents and actively exploited vulnerabilities, and this reporting obligation is triggered as soon as the manufacturer becomes aware of them.

The CRA establishes a phased timeline for notifications:

Within 24 hours an early warning notification must be submitted.
Within 72 hours a detailed notification must follow, providing exploit details, an initial assessment, and initial mitigation measures.
A final report must be submitted within 14 days after a corrective measure becomes available (for vulnerabilities), or within one month (for severe incidents).

All notifications must be submitted through the Single Reporting Platform (SRP), managed and developed by ENISA, which automatically routes reports to both ENISA and the relevant Member State's designated coordinating CSIRT. The ENISA platform became operational on September 11, 2026.

Under Article 69(3) of the CRA, Article 14 reporting obligations apply to all products within the scope of the regulation, including those placed on the market prior to December 11, 2027. This means that for older or discontinued products, manufacturers remain obligated to report any security issues affecting deployed units, even though they are exempt from product-related requirements.

Practical steps for compliance

To be compliant with active obligations is intertwined with CRA process obligations regarding vulnerabilities, therefore the correct approach is to establish a unified organizational process. This framework must cover both prevention, to minimize the risk of vulnerabilities being exploited, and reaction, ensuring the organization can respond systematically when an exploit or incident occurs.

The approach can be structured as follows:

Provide internal training to ensure all stakeholders develop a deep understanding of key cybersecurity concepts: vulnerabilities, vulnerability management, exploitation, and incidents. Stakeholders must be able to recognize these occurrences in real-world scenarios.
Establish internal processes for vulnerability management, and evaluate the use of tools to assist in the identification, prioritization, and triage of vulnerabilities. Additionally, maintain a process for incident response, ensuring a rapid reaction.
Develop multi-directional communication protocols for external reporting. This must include dedicated channels for receiving reports from external researchers (inbound), and procedures for proactive communication with affected customers and the Single Reporting Platform (SRP) managed by ENISA (outbound) during an incident.
Define clear roles and responsibilities to establish accountability for continuous vulnerability monitoring, remediation planning, and the timely transmission of notifications to ENISA regarding incidents or exploitations.

How Security Pattern can help

In order to help device manufacturers with tackling CRA's vulnerability management and incident response obligations, we launched the service Reporting Package: Vulnerability & Incident Management.

Reporting Package: Vulnerability & Incident Management

Vulnerability Management Procedure (VMP): Standardized internal templates and workflows to identify, triage, and resolve vulnerabilities.
Coordinated Vulnerability Disclosure (CVD): Custom policy templates and reporting tools to support external security researchers and satisfy regulatory transparency.
Incident Management Procedure (IMP): Framework to classify, investigate, and report security incidents to the authorities.

In addition, our other consultancy services related to CRA are Catalogue Analysis, Product Analysis and Secure Development Lifecycle (SDLC).

Catalogue Analysis

If you manage a diverse portfolio, analyzing every product individually is neither cost-effective nor sustainable. Our Catalogue Analysis framework optimizes your approach across your entire product line:

Product Grouping: We categorize your device catalogue into "families" so that subsequent technical assessments can be performed on a single representative model.
CRA Classification: We identify which products fall into the scope of the CRA and determine their regulatory categories (Default, Important Class I, Important Class II, or Critical).
Actionable Roadmapping: We highlight high-risk functional features (such as secure update mechanisms, third-party component dependencies, and data exposure) to establish clear compliance priorities.

Product Analysis

For individual products, we conduct risk and compliance analyses. This can be one representative device of a family, or the most business-critical version.

We evaluate your device's architecture against horizontal standards (such as the EN 40000 series) and relevant vertical industry standards.

Risk Assessment: We map your device’s usage context, identify primary threats, construct attack paths, and define risk mitigation strategies.
Security Requirements Definition: We draft a clear, product-specific requirement checklist detailing the exact technical features needed to bridge any gaps.
Vulnerability Assessment: Utilizing the cloud platform ARIANNA, we analyze your Hardware and Software Bill of Materials (HBOM/SBOM) against public databases to identify and eliminate known vulnerabilities.

Secure Development Lifecycle (SDLC)

CRA compliance requires security to be baked directly into your organization’s development process. Leveraging our certified expertise in standards like IEC 62443-4-1, we help you establish a sustainable Secure Development Lifecycle (SDLC):

Process Integration: We seamlessly map security requirements onto your existing development phases: from initial design and threat modeling to coding, validation, and maintenance.
Pragmatic Implementation: Our "coached" approach balances organizational security with development speed, ensuring minimum impact on your current product schedules.
Documentation: We define the necessary documentation and controls, leaving your team with a repeatable, audit-ready secure engineering process.