CRA Reporting from 11 September 2026: What to Report, to Whom, and How Fast

Most Cyber Resilience Act compliance plans target December 2027, the date of the cybersecurity CE marking. That is a scheduling error.

The first binding obligation under Regulation (EU) 2024/2847 applies from 11 September 2026, and it covers every product within the scope of the regulation, including those placed on the market long before the text becomes fully applicable.

This particular obligation is not a paperwork exercise, it sets a 24-hour deadline, and unfortunately a process that has never been exercised will never meet that deadline.

The essentials in five points

• Two types of event must be reported: actively exploited vulnerabilities and severe incidents affecting product security.
• Three deadlines: 24 hours, 72 hours, then a final report no later than 14 days after a fix becomes available (1 month for severe incidents).
• One channel: ENISA's Single Reporting Platform, which should go live on 11 September 2026.
• Your installed base is in scope, not just future products, and the obligation even outlives the support period.
• Maximum penalty: 15 million euros or 2.5 % of worldwide turnover.

What must be reported

Actively exploited vulnerabilities. A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. In every case, the point is to verify that any published proof of concept genuinely applies to your product before drawing any conclusion.

Severe incidents having an impact on product security. An incident that affects, or is capable of affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of data or functions.

Open-source software stewards are also subject to a reporting duty where they are involved in the development of the products concerned.

The three deadlines

Stage	Deadline	Expected content
Early warning	24 h from becoming aware	Product, version, summary, date of awareness, Member States concerned
Notification	72 h from becoming aware	Initial assessment, corrective measures applied, actions users can take
Final report	14 days after a fix becomes available (vulnerability) or 1 month after the 72 h notification (incident)	Full description of severity and impact

Note: the clock starts when you become aware, not when the vulnerability is discovered or when a fix ships.

The guidance published by the Commission on 27 July 2026 pins that moment down. Faced with a suspicious event or a report from a customer, a researcher or a media organisation, the manufacturer must assess it immediately, and it is deemed to have become aware when, following that initial assessment, it has a reasonable degree of certainty that the vulnerability is being actively exploited or that the incident has compromised the security of its product.

The wording leaves room for judgement, but the Commission stresses how promptly that initial assessment must be carried out: dragging out the analysis to delay the start of the clock is not a workable strategy.

Your current products are in scope

The obligation does not depend on when the product was placed on the market, since it also covers every product within CRA scope placed on the market before 11 December 2027.

In practice, a product designed in 2019, sold in 2022, still supported and available in the Union falls in scope as of this week, even though it will never carry a cybersecurity CE marking.

Note: this was clarified by a corrigendum published in the Official Journal on 2 July 2025 (2025/90555), the original wording being ambiguous on the point.

The Commission also states that the reporting obligation continues to apply after the support period ends, unlike the vulnerability handling requirements in Annex I Part II, which do stop with support. A product you no longer maintain but which remains in service at your customers' sites therefore still falls under Article 14.

There is, however, no retroactivity on awareness. Active exploitation you already knew about before 11 September 2026 does not need to be reported retrospectively. Where awareness arises after that date, however, the obligation applies, including where the vulnerability was already known.

If the CRA scope of your product is unresolved, our scope finder tool gives a first answer in a few minutes.

Who receives the report

Reporting goes through ENISA's Single Reporting Platform, the Single Reporting Platform.

The recipient is the CSIRT designated as coordinator in the Member State of your main establishment, meaning the place where decisions on the cybersecurity of your products are predominantly taken.

Without an identifiable main establishment in the Union, the following cascade applies:

1. Member State hosting your largest headcount in the Union
2. Member State where your authorised representative acts for the highest number of products
3. Member State where your importer places the most products on the market
4. Member State where your distributor makes the most available
5. Member State with the highest number of users

One notification is enough for a given event, even with several subsidiaries in the Union or a parent company outside it. Internal coordination is of course your own responsibility.

The platform then takes care of disseminating the information to the relevant European bodies (CSIRTs, market surveillance authorities, and so on). ENISA will publish its public URL on its dedicated page before go-live.

Three access constraints to anticipate

• Authentication runs through EU Login, with multi-factor authentication required. Accounts can and should be created in advance.
• One primary representative, up to twenty secondary ones. The primary representative registers the entity and invites the others, and CSIRT validation does not block a first submission.
• No API at launch. Final submission is manual, through the interface, although automation remains possible upstream in your own tooling.

If the platform is unavailable, ENISA states that manufacturers should wait for it to be restored before submitting, with direct CSIRT contact remaining possible where the situation demands it.

The prerequisites for meeting the 24-hour deadline

To arrive on time, you have to arrive early.

Knowing what is inside the product. An actively exploited vulnerability in a third-party component is reportable by the manufacturer of the finished product, and without a software bill of materials kept current for every shipped release, matching an exploitation reported in the wild against a catalogue product takes days. Our article on efficient management of CVEs with Yocto describes a production-grade chain.

Knowing whether the component is actually reachable. The Commission is explicit on this: where the third-party vulnerability cannot be exploited in your product, because the vulnerable code is not reachable for instance, or where it simply has not been exploited in it, it does not fall under mandatory reporting. Your vulnerability handling duties and the duty to report upstream to the component maintainer remain in full, and voluntary reporting stays open, but a documented reachability analysis saves you unnecessary filings while providing the justification you will need if a decision not to report is ever challenged.

Knowing who decides. A named person must be reachable outside office hours and authorised to qualify an event as reportable and to submit it.

Having rehearsed. A first report filed under pressure, on an interface never used before, with an account created in a hurry, will not fit in 24 hours.

Informing users is a separate duty

Awareness also triggers Article 14(8), which requires you to inform impacted users and, where appropriate, all users. Where information is not provided in good time, the CSIRT that received the notification may step in and inform users directly.

Informing is not disclosing. The Commission states that this duty implies neither publication nor indiscriminate dissemination, and that detailed communication may be restricted to the users concerned. The case is expressly made for products deployed in sensitive or essential environments, where publishing technical detail would raise the risk. Broader disclosure has its place once the vulnerability is fixed, Annex I Part II requiring in any case that information on fixed vulnerabilities be published once the update is available.

The operational constraint is the ability to reach impacted users by name, which assumes you know who deploys your products. That is rarely the case where sales go through distributors or integrators.

The penalty tier

Failing the reporting obligation falls in the regulation's upper tier: up to 15 million euros or 2.5 % of worldwide annual turnover, whichever is higher.

Two derogations apply:

• Microenterprises and small enterprises are not exposed to fines for missing the 24-hour deadline alone, but the duty to report still stands, as do the subsequent stages.
• Open-source software stewards are exempt from administrative fines, their reporting duty remaining applicable.

To do this week

1. Determine whether your products fall within CRA scope.
2. Identify your main establishment and the corresponding coordinating CSIRT.
3. Create EU Login accounts, with MFA enabled, for everyone authorised to file.
4. Appoint a primary representative and backups, with a real on-call rota.
5. Verify that the software bill of materials for every supported product is current.
6. Write a one-page qualification procedure answering a single question: is this event reportable, yes or no.

---

TrustnGo supports manufacturers in setting up the vulnerability handling processes required by the CRA, from SBOM generation to the reporting procedure. See our Cyber Resilience Act services or get in touch.

Sources

• Regulation (EU) 2024/2847, Articles 14, 16, 24, 64 and 69
• Corrigendum 2025/90555 of 2 July 2025, OJ L
• ENISA, Single Reporting Platform, Frequently Asked Questions, updated 4 September 2026
• European Commission, FAQs on the CRA Implementation, Section 5
• European Commission, Communication C(2026) 5252 and its annex, guidance on the application of the CRA, 27 July 2026, points 210 to 220