Cyber Resilience Act: The Article 14 reporting obligations

1. Introduction

Regulation (EU) 2024/2847, the Cyber Resilience Act (the "CRA" or the "Regulation”), entered into force on 10 December 2024 and is one of the pillars of the EU cybersecurity framework. It sets harmonised cybersecurity requirements for products with digital elements throughout their lifecycle and imposes obligations on manufacturers, importers and distributors placing such products on the EU market. Public debate has largely focused on 11 December 2027, when the CRA becomes fully applicable. That focus however overlooks a more immediate and operationally demanding milestone.

From today, 11 September 2026, Article 14 of the CRA applies. In plain terms: if a manufacturer becomes aware that a vulnerability in one of its products is being actively exploited, or that a severe incident has hit the security of one of its products, it must tell ENISA and its coordinating CSIRT at the same time. Each of those two triggers starts the same three-step clock: a short early warning within 24 hours of becoming aware, a vulnerability or incident notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available (for actively exploited vulnerabilities) or one month after the 72-hour notification (for severe incidents).

The European Commission's guidance on the application of the Cyber Resilience Act (the "Guidance"), the content of which was approved on 27 July 2026, clarifies how the reporting regime is expected to operate in practice. For most manufacturers, Article 14 will be the first tangible CRA obligation to comply with, and September 2026 is the first real operational stress test of their cybersecurity governance and incident management capabilities.

2. The CRA implementation timeline

The CRA rolls out in phases. For manufacturers, the key dates are: entry into force on 10 December 2024; governance and conformity-assessment-body rules from 11 June 2026; the Article 14 reporting obligations from 11 September 2026; and the remaining obligations — the substantive cybersecurity requirements, conformity assessment and CE marking — from 11 December 2027.

The 2026 obligations focus on a manufacturer's ability to detect, assess and escalate cybersecurity events under very short deadlines, rather than on product design, conformity assessment or CE marking. As a result, governance structures, reporting channels and internal decision-making procedures must already be in place, and manufacturers whose CRA roadmap is built solely around December 2027 should reassess their planning — particularly if they operate complex digital ecosystems, large product portfolios or software heavily reliant on open-source or third-party components.

3. Why Article 14 matters

Article 14 sits within the CRA's vulnerability management and market surveillance framework and reflects the objective of ensuring that competent authorities receive timely information on cybersecurity risks affecting products with digital elements. Two features are worth highlighting.

First, the obligations have a broad reach. They apply to all products with digital elements within the scope of the CRA, including those placed on the market before 11 December 2027. Unlike the vulnerability-handling duties under Annex I, which run only for a product's support period, Article 14 reporting continues even after that support period has ended. Manufacturers cannot therefore treat existing product portfolios, or products they have stopped actively supporting, as being outside the reporting regime.

Second, the two reporting streams have different scopes. A severe incident must be reported whenever it happens and compromises the security of the manufacturer's product — there is no exploitation threshold. A vulnerability, by contrast, only has to be reported once it is being actively exploited in that product. If a third-party component has a vulnerability that cannot be exploited in the manufacturer's product, or simply has not been exploited yet, Article 14 reporting is not triggered. Voluntary reporting under Article 15 remains available, and the manufacturer's other vulnerability-handling duties continue to apply regardless. The Guidance also confirms that vulnerabilities the manufacturer already knew were being actively exploited before 11 September 2026 do not need to be reported retroactively.

In addition to notifying authorities, manufacturers must inform impacted users of the vulnerability or incident and, where appropriate, all users. The Guidance takes a risk-based approach here: disclosure should be proportionate, and detailed technical information may be limited to affected customers where wider publication could itself increase cybersecurity risk. Broader disclosure typically becomes appropriate once the vulnerability has been adequately addressed.

Because the reporting regime starts operating well before the CRA is fully applicable, manufacturers may have to comply with Article 14 while broader CRA implementation projects are still ongoing.

A point often missed: a substantial modification of a product counts as placing it on the market again. A modification is substantial if it changes the product's cybersecurity risk profile beyond what the original risk assessment covered, or if it changes the product's intended purpose. The Guidance frames the test around four practical questions: does the change introduce new threat vectors (new interfaces, channels or dependencies); does it enable new attack scenarios; does it change how likely a known attack scenario is to succeed; and does it change the impact if it does. A "no" across the board points away from a substantial modification. Security updates are generally not substantial modifications, precisely because their purpose is to reduce risk — even a technically significant patch stays outside the concept if it does not change the product's intended purpose or introduce new risk. But a security fix can still tip into a substantial modification if it changes the product's boundaries or dependencies in a way the risk assessment did not cover — for example, replacing a local encryption feature with a remote encryption service run by a third party, which is the Guidance's own illustration of the concept. Once a substantial modification occurs, Article 14 obligations attach to the modified product from that point. If the modification is made by a distributor, importer or integrator rather than the original manufacturer, that operator becomes the manufacturer for CRA purposes and inherits the reporting duty — though only for the modified part of the product, unless the modification undermines the security of the product as a whole, in which case the full product is treated as newly placed on the market.

4. The real challenge: determining when a reportable event exists

The Article 14 obligations look straightforward at first sight. In practice, the compliance challenge often lies not in submitting a notification but in determining whether a reportable event exists, and when.

The Guidance clarifies that the 24-hour clock does not start the moment an incident or vulnerability first arises. It starts once the manufacturer, after an initial assessment, has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has occurred and compromised its product's security. This mirrors the "becoming aware" concept already used under NIS2 and the GDPR's breach-notification rules, which should help manufacturers triage consistently across the different regimes.

This matters in practice because manufacturers rarely have complete and verified information at the outset. Initial signals may come from internal monitoring, external researchers, coordinated vulnerability disclosure programmes, customers, suppliers or open-source communities. The manufacturer must triage fragmented, evolving information and reach a defensible reportability decision within hours, not days. The Guidance therefore places significant weight on governance and escalation, and expects manufacturers to move promptly to the initial assessment, particularly where the vulnerability may pose a significant risk.

The CRA does not only regulate product security: it also sets expectations on organisational preparedness, coordination and decision-making. In many cases, the quality of a manufacturer's governance will matter as much as the sophistication of its technical controls.

5. Governance becomes a key compliance requirement

Public debate has largely focused on cybersecurity-by-design and technical product requirements. Article 14 reveals a broader regulatory expectation: manufacturers must have in place governance structures that support rapid, accurate and well-documented decision-making whenever a cybersecurity event occurs. The notification is only the last, visible step in a much longer organisational chain.

Given the above, manufacturers should verify that they have in place, at a minimum:

• clearly defined incident escalation procedures;
• internal criteria for assessing whether a vulnerability is actively exploited;
• mechanisms ensuring effective coordination between cybersecurity, legal and compliance functions;
• decision-making processes capable of operating within compressed regulatory timelines;
• procedures for documenting investigations and reporting decisions; and
• governance frameworks capable of demonstrating accountability and regulatory compliance.

For many organisations, building these processes is the most demanding aspect of the September 2026 deadline.

6. CRA, NIS2, DORA, the AI Act and the GDPR: avoiding regulatory silos

CRA compliance rarely happens in isolation. Many organisations are already running compliance programmes under the NIS2 Directive, the Digital Operational Resilience Act ("DORA") where applicable, the AI Act, and — whenever personal data is involved — the GDPR. These frameworks have different objectives, but they rely on the same building blocks: detecting an incident, escalating it internally, and reporting it to a regulator. If a product with digital elements incorporates AI, is used by a NIS2 or DORA entity, or processes personal data, the same event can trigger obligations under more than one framework at once, usually on different but overlapping clocks: 24 hours for the CRA early warning, 72 hours for a GDPR data breach notification, and the NIS2/DORA cycle running in parallel. The Guidance flags that further clarification on the CRA's interaction with the AI Act and DORA is expected, and it already aligns the CRA's "becoming aware" trigger with the one used under the GDPR.

Rather than running parallel compliance streams, organisations should extend their existing cybersecurity governance programmes to cover CRA-specific requirements. A single coordination function should oversee incident classification, notification and follow-up across all applicable frameworks — including deciding whether a cybersecurity event also qualifies as a personal data breach requiring notification to the data protection authority and, where applicable, to data subjects. Organisations that have already invested in NIS2, DORA or GDPR breach-response readiness are usually well placed to absorb Article 14, provided they map the CRA's triggers, thresholds and reporting channels onto their existing playbooks.

7. Practical steps

Manufacturers should focus on a small number of concrete workstreams rather than on paper-only documentation. Priority actions include:

• confirming which products fall within the CRA's scope and mapping their software components and third-party dependencies;
• reviewing incident response and vulnerability handling procedures and aligning them with the 24-hour / 72-hour / final report cycle, and with the parallel notification to ENISA and the CSIRT coordinator;
• identifying, for each product line, who has authority to decide that a reportable event exists and to sign off notifications to authorities and users; and
• clarifying roles across legal, compliance, cybersecurity, product and communications teams.

Particular attention should be paid to the digital supply chain: how vulnerabilities are identified, classified and investigated in cooperation with suppliers, open-source communities and other third parties, and whether contractual arrangements support timely information flows towards the manufacturer. Tabletop exercises covering severe incidents and actively exploited vulnerabilities remain the most effective way to test whether governance holds under pressure.

The objective is not paper compliance. It is a governance framework that can respond consistently to cybersecurity events under significant operational pressure, and that can be evidenced to authorities, customers and counterparties when needed.

8. Conclusion

The Cyber Resilience Act is often described as a December 2027 project. Today however marks an important milestone. From 11 September 2026, manufacturers face concrete obligations to report actively exploited vulnerabilities and severe incidents affecting products with digital elements — including for products already on the market and beyond the end of their support period. This is the first genuine compliance milestone under the CRA, and the moment when cybersecurity governance moves from policy to practice.

The obligations applying from today are operational: they test the manufacturer's ability to detect, assess and report cybersecurity events under short deadlines, not (yet) its ability to design or CE-mark a product. Organisations that use these first months to strengthen governance, incident assessment and escalation — rather than to produce documentation — will be materially better positioned both to comply with Article 14 and to approach the broader obligations becoming fully applicable from December 2027.