CRA Reporting Obligation Since 11 September 2026: What Manufacturers Must Build Now
Key points · As of 3 October 2026
The reporting obligation applies. Most manufacturers lack the detection.
- Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents — early warning within 24 hours (Art. 14 Cyber Resilience Act).
- Including products in the field: the obligation covers all products with digital elements placed on the market before 11 December 2027 (Art. 69(3)).
- The real problem is technical: you can only report what you detect. Without a software bill of materials, continuous vulnerability matching and a reporting channel, you learn about an exploited flaw too late — or not at all.
- The remaining obligations follow on 11 December 2027. Building detection now already covers most of Annex I Part II.
What has applied since 11 September 2026
The Cyber Resilience Act (Regulation (EU) 2024/2847) takes effect in stages. Most requirements — secure product design, vulnerability handling, technical documentation, CE marking — apply from 11 December 2027. Article 14, the reporting obligation, has applied since 11 September 2026 (Art. 71(2)). That is the uncomfortable order of the CRA: the duty to report comes before the duty to search systematically.
Two kinds of events must be reported. First, actively exploited vulnerabilities — flaws for which there is reliable evidence that an attacker has exploited them in a system without permission (Art. 3(42)). Second, severe incidents affecting the security of the product: when the availability, authenticity, integrity or confidentiality of sensitive or important data or functions is or can be affected, or when malicious code has been or can be introduced into the product or the users’ systems (Art. 14(5)).
The deadlines for actively exploited vulnerabilities
within 24 hours
Early warning
From becoming aware of the actively exploited vulnerability — naming the Member States where the product has been made available (Art. 14(2)(a)).
within 72 hours
Vulnerability notification
Affected product, nature of the exploit and vulnerability, corrective measures taken and what users can do themselves (Art. 14(2)(b)).
no later than 14 days after the fix
Final report
Description incl. severity and impact, information on the malicious actor where available, details of the security update (Art. 14(2)(c)).
Severe incidents follow the same 24 and 72 hours, but their final report is due one month after the 72-hour notification, not after the fix (Art. 14(4)). The CSIRT may request an intermediate report in between.
Reports go simultaneously to the coordinating CSIRT and to ENISA, via the single reporting platform, which ENISA says has been operational since 11 September 2026. In Germany, the BSI names CERT-Bund as the coordinating CSIRT. You must also inform impacted users about the vulnerability and possible mitigations (Art. 14(8)) — if you don’t do so in time, the CSIRT may do it instead.
Who is affected — and who isn’t
Anyone placing a product with digital elements on the EU market: software or hardware with a direct or indirect data connection — connected machines and controllers, IoT devices, routers, desktop and mobile software, firmware, software components sold separately. This includes the manufacturer’s remote data processing solutions without which the product could not perform a function: the device cloud, the app backend (Art. 3(1) and (2)).
Medical devices, motor vehicles and aviation, among others, are excluded because their own regulations apply (Art. 2). Pure software-as-a-service is covered by NIS2, not the CRA, according to Recital 12. Operators are often subject to NIS2, manufacturers to the CRA — and anyone who is both has both reporting paths.
From December 2027, products in the default category can use self-assessment of conformity (Module A, Art. 32(1)). Important products of Class I and II (Annex III) — such as operating systems, routers, password managers, VPNs, firewalls or hypervisors — need stricter procedures. The reporting obligation is the same for all categories.
The real problem: you can only report what you detect
The 24-hour clock starts once you become aware. The legal question is when that is. The technical question matters more: how do you find out at all? Most mid-sized manufacturers have no good answer. A customer calls support, a researcher writes to the general info address, a reseller forwards an email — or the flaw first appears in a trade article.
The most common case will be a different one: a vulnerability in a widely used library is being exploited worldwide, and the question is whether your product contains it. If you don’t know your components, finding out takes days. With a current software bill of materials, it takes minutes.
That is why the reporting obligation and vulnerability handling belong together. What Annex I Part II mandates from December 2027 is the foundation you need for the reporting obligation today.
The eight vulnerability handling requirements
CRA Annex I Part II — binding from 11 December 2027, and already the basis for a working reporting chain today.
Know your components — SBOM
Identify and document vulnerabilities and components, with a software bill of materials (SBOM) in a commonly used, machine-readable format — covering at least the top-level dependencies.
Remediate without delay
Address vulnerabilities without delay; ship security updates separately from feature updates where technically feasible.
Test regularly
Effective and regular tests and reviews of the security of the product.
Disclose fixed vulnerabilities
Once an update is available, publish a description, affected products, impact, severity and remediation guidance.
CVD policy
Put in place and enforce a coordinated vulnerability disclosure policy.
Reporting address
Facilitate information sharing — including a contact address where third parties can report vulnerabilities.
Secure update distribution
Mechanisms that distribute updates securely — automatically where applicable.
Free, explained updates
Disseminate security updates without delay and free of charge, accompanied by advisory messages on what users should do.
On top of this come the manufacturer obligations in Article 13: due diligence when integrating third-party components including open source, reporting discovered flaws to the component’s maintainer, a support period of generally at least five years, and keeping every security update available for at least ten years or the rest of the support period.
What to build technically in the coming weeks
Eight steps, sorted by impact. The first three decide whether you notice an exploited flaw in time at all.
- 1
Inventory products and support periods
Which products with digital elements do you have on the market — including older versions? The reporting obligation covers everything placed on the market before 11 December 2027 (Art. 69(3)). Record the support period and the internal owner for each product.
- 2
Generate an SBOM per product — automatically
A hand-maintained list is out of date with the next release. Generate the SBOM in your build pipeline (e.g. CycloneDX or SPDX), version it with the release and archive it for every version you ship.
- 3
Match components against vulnerability data — continuously
An SBOM only helps if it is checked daily against new CVEs and exploitation reports. Watch for "known exploited" flags (such as CISA’s KEV catalog): that is where your 24-hour clock is most likely to start.
- 4
Publish a reporting address
A security.txt per RFC 9116 and a page with your disclosure policy. Anyone who finds a flaw in your product needs to know where to send it — otherwise you read about it in the press.
- 5
Rehearse the reporting path once
Who decides whether "actively exploited" applies? Who reports on the ENISA platform, with which account? ENISA advises creating the EU Login with MFA only when needed — still, settle in advance who will do it. A weekend is not an excuse for delay.
- 6
Be able to ship updates securely
Signed updates, a documented distribution path, a plan for devices without automatic updates. No update means no final report — the 14-day period runs from the availability of the fix.
- 7
Be able to inform users
Art. 14(8) requires informing impacted users about the vulnerability and mitigations. Do you have a customer list per product and version — or only reseller addresses?
- 8
Have the product tested before an attacker does
Annex I Part II no. 3 requires regular security testing anyway. A penetration test of firmware, app, API and backend finds the flaws that would otherwise end up on the ENISA platform.
You can see an example of step 4 on our own site: we publish a vulnerability disclosure policy and a security.txt — both take an afternoon and are the easiest step on the list.
Fines — and why they are not the biggest risk
Breaches of the essential requirements and of Articles 13 and 14 can be fined up to €15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64(2)). Micro and small enterprises are not fined for a missed 24-hour early warning — the obligation itself still applies to them.
The bigger day-to-day risk is a different one: your customers read the same deadlines. If you supply machines, devices or software to companies that are themselves subject to NIS2, you will be asked about your vulnerability process — in procurement, in supplier audits, in the next framework contract. A credible answer is now a sales argument.
Frequently asked questions about the CRA reporting obligation
Does the CRA reporting obligation apply to products we shipped years ago?
Yes. Article 69(3) of Regulation (EU) 2024/2847 states that the reporting obligations in Article 14 apply to all products with digital elements placed on the market before 11 December 2027 — including products already in the field. The other requirements only apply to such legacy products if they are substantially modified after that date.
What is an "actively exploited vulnerability"?
A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (Art. 3(42) CRA). A merely theoretical flaw, or a finding from a commissioned penetration test, does not trigger the reporting obligation.
Who receives the report?
The CSIRT designated as coordinator and ENISA, simultaneously — via the single reporting platform, which ENISA says has been operational since 11 September 2026. The competent CSIRT is the one in the Member State of your main establishment; for Germany, the BSI names CERT-Bund as the coordinating CSIRT.
Is our SaaS application covered by the CRA?
Pure software-as-a-service is generally covered by NIS2, not the CRA (Recital 12). It is different for remote data processing without which a product with digital elements could not perform one of its functions — such as an app’s backend or a connected device’s cloud (Art. 3(2)). The classification in your specific case belongs with your legal counsel.
What fines apply?
For breaches of the essential requirements and of Articles 13 and 14, up to €15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64(2)). Micro and small enterprises are not fined for missing the 24-hour early warning (Art. 64(10)) — the obligation itself still applies to them.
Do we already need an SBOM for the reporting obligation?
The SBOM requirement in Annex I Part II becomes binding on 11 December 2027. In practice you need it today: without a current bill of materials you cannot tell quickly enough whether an actively exploited flaw in a library affects your product — and so you cannot report within 24 hours.
If you want support
You can take the steps above yourself. If you’d like help, we handle the technical side — with a German security lead who signs off every report, and developers who help with the fixes.
CRA readiness check
Two days, €2,900, for one product: SBOM maturity, update mechanism, reporting paths, testing practice and open attack surface — with a prioritised action plan.
See our CRA servicesProduct penetration test
From €3,500: firmware, device, app, API and backend — the regular security testing Annex I Part II requires, with a re-test after remediation.
See penetration testingSecure SDLC review
Four days, €4,900: build pipeline, SBOM generation, dependencies and secrets — so the bill of materials is generated automatically and stays current.
See security auditWhat we deliberately don’t offer
We are not a law firm and not a notified body: the legal classification of your product and the conformity assessment belong with your legal counsel. We also don’t provide a 24/7 standby for your reporting deadlines. What we deliver is the technical foundation, so you know in time what you have to report. This article is a technical assessment, not legal advice.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — Official Journal of the EU, in particular Art. 3, 13, 14, 64, 69, 71 and Annex I
- ENISA: Single Reporting Platform (SRP) — Frequently Asked Questions
- BSI: Single Reporting Platform and reporting under the Cyber Resilience Act (German)
- CISA: Known Exploited Vulnerabilities Catalog
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)
Build the detection before you need the report
In a 30-minute intro call we look at one product and tell you which technical gaps lie between where you are today and a working reporting chain.
Rather see first what is reachable from outside? Request a free attack surface check
