CRA September 2026 Deadline: Vulnerability Reporting Requirements Explained

On 11 September 2026, the first binding obligation under the EU Cyber Resilience Act (CRA) takes effect. From that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through a platform operated by ENISA. This is the only part of the CRA that becomes legally enforceable in 2026. The broader obligations, including conformity with the Annex I essential requirements, CE marking, and market surveillance, apply from 11 December 2027.

That distinction matters, because the work needed to report well in 2026 is wider than the legal text of the reporting obligation itself. This guide separates what the CRA strictly requires on 11 September 2026 from what you should put in place in practice to meet it, and explains the risk of treating the two as the same thing.

What is legally required on 11 September 2026

The CRA applies in stages. Article 14, which sets out the reporting obligations, applies from 11 September 2026. The provisions on notification of conformity assessment bodies (Articles 35 to 51) apply earlier, from 11 June 2026. Everything else applies from 11 December 2027.

What Article 14 legally requires from 11 September 2026 is narrow and specific:

• Notify any actively exploited vulnerability in your product with digital elements, on the staged timeline below.

• Notify any severe incident having an impact on the security of your product, on the same timeline.

• Inform impacted users, and where appropriate all users, of the vulnerability or incident and of any corrective or mitigating measures they can take (Article 14(8)).

• Submit these notifications through the ENISA Single Reporting Platform.

One point is widely missed. The reporting obligation reaches backward. Under Article 69(3), Article 14 applies to all products with digital elements within the scope of the CRA, including products placed on the market before 11 December 2027. So products you shipped years earlier are covered by the reporting duty once you become aware of a qualifying vulnerability or incident, even though they are otherwise exempt from the CRA until substantially modified.

Non-compliance with the Article 14 obligations can carry administrative fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher (Article 64(2)).

Note what is not on this list. The CRA does not legally require you to hold a product inventory, an SBOM, a monitoring process, or a coordinated vulnerability disclosure policy on 11 September 2026. Those become binding requirements only in December 2027. But in practice, you cannot meet the Article 14 obligation reliably without them. This post addresses that gap between what is legally required and what practical implementation demands, along with the risks involved, so you can prioritize the work that matters most before the deadline.

The practical milestones, and the risk of skipping them

To report the right event, for the right product, within 24 hours of becoming aware, you need three things that the reporting obligation itself does not spell out: you need to know which of your products are in scope and what's inside them and you need to be able to report the vulnerabilities. These are the two practical milestones for 2026.

The risk of skipping them is concrete. Without a scope inventory and component view of those products, you cannot tell which incoming vulnerability information concerns a product you are responsible for reporting and you cannot tell whether a vulnerability published about a third-party library or chipset is present in something you placed on the market.

Milestone 1: A CRA scope and compliance-tracking inventory

The first milestone is not an SBOM. It is an inventory that lets you classify which of your products fall within CRA scope, so you know which products the reporting obligation applies to. This is a compliance-tracking exercise.

Scope rests on three cumulative criteria from Article 2(1). A product is in scope where it is a product with digital elements, it is made available on the market, and its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. All three must hold.

Your inventory should record the inclusion and exclusion logic for each product:

• Inclusion. A product with digital elements is a software or hardware product and its remote data processing solutions (Article 3(1)). The connection criterion is broad: a direct physical connection includes USB, Ethernet, Wi-Fi, Bluetooth, or an industrial fieldbus link from a sensor to a controller, and a logical connection can be indirect, for example an offline utility that reaches a network only through its host operating system.

• Exclusion. Products with no capability to connect to other devices or networks fall outside scope, such as a coffee machine or electronic toy whose firmware has no connection capability. Products developed or modified exclusively for national security or defence, or specifically designed to process classified information, are excluded (Article 2(7)), as are products covered by certain other Union law, including medical devices, motor vehicle type-approval, certified civil aviation products, and marine equipment (Article 2(2) to 2(4)). Products you manufacture purely for your own use are not placed on the market and are out of scope unless placed on the market separately.

Remote data processing solutions (RDPS) need explicit evaluation, because they extend the product beyond what you ship. RDPS is data processing at a distance where the software is developed by you or under your responsibility, and whose absence would stop the product performing one of its functions (Article 3(2)). A cloud backend that lets a smart device be controlled remotely is in scope as RDPS. A website or a standalone SaaS offering that does not support a product's functionality, or that is developed outside your responsibility, is not. Where RDPS is in scope, it is part of the product you must report for.

Classification of a product as important or critical, based on its core functionality under Annex III and Annex IV and detailed in Commission Implementing Regulation (EU) 2025/2392, is not needed to meet the 2026 reporting deadline. It drives the conformity assessment route that applies from December 2027, where the classification determines whether you can self-assess or must involve a notified body. It is worth capturing in the same inventory now so the record serves both deadlines, but it is not a 2026 reporting prerequisite.

This inventory does not require new infrastructure. It can be embedded into an existing asset or product inventory if you have one, built in a dedicated compliance tool, or maintained in a structured spreadsheet. What matters is that it answers one question reliably: for which products and product versions are we the manufacturer with a reporting duty?

Milestone 2: Reporting vulnerabilities and severe incidents under the CRA

From 11 September 2026 you must report actively exploited vulnerabilities and severe incidents under Article 14, on deadlines that begin to run within hours of confirming a vulnerability or incident. Meeting the obligation depends on two things: knowing which events are notifiable and which are not; and having a clear path from the moment you become aware to a submitted report. This milestone works through each of them.

What you must report under the CRA

Two types of event are notifiable under Article 14.

Actively exploited vulnerabilities. Article 3(42) defines this as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. The trigger is evidence of malicious exploitation, not the existence of the flaw.

Severe incidents. 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, or where it has led or could lead to the introduction or execution of malicious code in the product or in a user's systems (Article 14(5)).

Some events are not subject to mandatory reporting. A zero-day found by ethical hackers or by a testing laboratory, with no evidence of prior malicious exploitation, is not an actively exploited vulnerability and is not mandatorily notifiable. The same applies to bug bounty findings. Where an integrated component contains a vulnerability that cannot be exploited in your product, it is not actively exploited in your product and is not mandatorily notifiable. In these cases you may notify voluntarily under Article 15, and you must report the vulnerability to the entity that maintains the component under Article 13(6). Where an actively exploited vulnerability originates in a component and is exploitable in your product, you must notify it, and the component manufacturer, if it placed the component on the market, notifies separately.

CRA reporting timeline: 24 hours, 72 hours, 14 days

Article 14 sets a three-stage cascade for both vulnerabilities and severe incidents:

• Early warning: without undue delay and within 24 hours of becoming aware.

• Notification: without undue delay and within 72 hours of becoming aware, with general information, an initial assessment, and any corrective or mitigating measures.

• Final report: for vulnerabilities, no later than 14 days after a corrective or mitigating measure is available; for severe incidents, within one month after the notification.

Under Article 64(10), administrative fines do not apply to microenterprises and small enterprises for missing the 24-hour early warning deadline. The obligation to report still stands.

Where you report: The ENISA single reporting platform

Reporting is done through the Single Reporting Platform, a single electronic system established and operated by ENISA, scheduled to be operational by 11 September 2026, with a testing period expected beforehand. Its purpose is to let manufacturers report once rather than notifying multiple national authorities separately.

A notification routes simultaneously to the CSIRT designated as coordinator and to ENISA. Your coordinator CSIRT is determined by your establishment under Article 14(7): if you are established in the EU, it is the coordinator in the Member State of your main establishment, meaning where decisions on the cybersecurity of your products are predominantly taken; if you are not established in the EU, it is the coordinator in the Member State where your authorised representative is established. The coordinator then disseminates the report to other relevant CSIRTs and market surveillance authorities. We cover how the platform handles routing, dissemination, and sensitive reports in detail in our guide to the ENISA Single Reporting Platform.

From detection to a reported notification

The clock in Article 14 starts when you become aware of a qualifying event, so it helps to be clear about how awareness happens and what has to follow it. The CRA does not prescribe how you must detect vulnerabilities or incidents, and it does not require you to run any particular monitoring activity to comply. The obligation is to act once you are aware. In practice, awareness can arrive through several channels:

• A customer or partner reports unusual activity or a compromise. This is often the first signal, and it may arrive by any route, including a support ticket or a general email address.

• A security researcher or cybersecurity firm publishes threat intelligence. Public reporting on a zero-day used in targeted attacks can name your product before you have any internal signal.

• A government cybersecurity agency or a CSIRT notifies you, having detected exploitation through its own monitoring.

• An ethical hacker reports a vulnerability already being exploited in the wild. This differs from a good-faith disclosure of an unexploited flaw, which is not mandatorily notifiable.

• Your own monitoring, telemetry, honeypots, or dark web monitoring surface evidence that a vulnerability is being used.

Becoming aware is only the start. You then confirm whether the event actually triggers a reporting duty by checking the available information against the legal criteria: is there reliable evidence of active exploitation under Article 3(42), or does an incident meet the severity criteria in Article 14(5)? If it does, the staged deadlines apply from the point of awareness, so the assessment cannot sit in a queue. If it does not, you may still report voluntarily under Article 15. Either way, the decision and its basis should be written down, because a market surveillance authority can later ask you to demonstrate how you handled the information.

What to prioritize before the deadline

Implementing every good practice by 11 September 2026 is not realistic for most manufacturers, and the CRA does not ask for it. The honest approach is to separate what the law requires from what good practice recommends, and to sequence the work accordingly.

Priority one is a working path from information to a reporting decision, built on the tools and processes you already have:

• Make sure all available vulnerability and incident information is actually processed. Whether you do this manually or with automation, the point is that signals from your existing channels reach someone who can act on them, rather than going unseen.

• Define a process to assess each signal against the CRA notification criteria. A repeatable and well defined triage process that asks whether there is evidence of active exploitation or a severe incident is enough to start, and it is what turns raw information into a defensible decision.

• Document the reporting decision, including the cases where you decide not to report. A record of why an event did or did not meet the criteria is your evidence if the decision is later questioned.

• Establish the reporting process itself. Know who submits to the Single Reporting Platform, who can act inside the 24-hour and 72-hour windows, and how you will inform affected users under Article 14(8).

Priority two is closing the gap to best practice and to the full Annex I, Part II vulnerability handling requirements, using the draft standard prEN 40000-1-3 as the reference. The standard structures this work into two phases: a receipt phase, where you monitor internal and external sources, including the EU Vulnerability Database, and cross-reference incoming information against your inventory and SBOM, and a verification phase, where you assess whether a vulnerability is exploitable in your product and how severe it is. These capabilities make detection and assessment systematic rather than reactive, but they are the build-out that follows once the priority-one path is in place, not a precondition for the 2026 deadline.

The risk of non-compliance in deferring them is easy to underestimate. The reporting duty is triggered by an actively exploited vulnerability that is exploitable in your product, and the early warning is due within 24 hours of becoming aware. Two things have to happen fast inside that window: you have to learn that a vulnerability is being exploited, and you have to confirm that it actually affects one of your products.

A manual process is fragile on the first count. Without systematic monitoring, the first signal may arrive late or not at all, through an email that sits unread or a public advisory nobody on the team happens to see. A reportable event can pass unnoticed even though the obligation already applies, and the failure is not visible until it is too late.

The verification step is where the strain shows on the second count. Confirming whether a disclosed vulnerability is exploitable in one of your products has to be a repeatable assessment, not a fresh investigation each time across scattered documentation and tribal knowledge while the clock runs. Without an accurate SBOM to trace a disclosed component into the products that contain it, this step is slow and error-prone. As the volume of disclosures grows, a process that depends on the right person seeing the right report and tracing it by hand does not scale, and the gap between being compliant on paper and being able to respond reliably widens with every new advisory.

Treating 2026 as the on-ramp

The reporting obligation is one slice of the CRA, but the inventory, component visibility, and monitoring you build to meet it are the same foundations the full Annex I requirements rely on from December 2027. Building them once, properly, for the 2026 deadline avoids rebuilding them later.

At Tributech, we work with manufacturers navigating CRA compliance, and we are happy to discuss where these requirements apply to your products. Want to talk deadlines? Book a meeting with a CRA expert.