Most of the CRA conversation right now is aimed at 11 December 2027. That's the wrong date to plan around first. Article 14 reporting starts on 11 September 2026, and it covers products already on the EU market — on a clock measured in hours, not quarters.
Most of the CRA compliance conversation right now is aimed at 11 December 2027 — the date the main conformity requirements kick in. That's the wrong date to be planning around first. Article 14 reporting starts on 11 September 2026, and it applies to products already sitting on the EU market, not just new ones. Whether a product qualifies has nothing to do with where it was designed or built. It comes down to one question: is it being made available in the EU. For a Tier 1 or OEM based outside Europe, that's the entire compliance question in one sentence.
The obligation itself is narrow. What has to be reported is an actively exploited vulnerability or a severe incident, not a routine bug and not a patch released on the normal cadence. The trigger is evidence that someone is actually exploiting it, not the mere existence of the defect. Once that trigger fires, the clock is unforgiving: an early warning inside 24 hours of becoming aware, a fuller notification at 72 hours, and a final report within 14 days of a corrective measure shipping (a month, for a severe incident rather than a vulnerability). Everything routes once through the Single Reporting Platform, to the CSIRT covering the manufacturer's main EU establishment, copied to ENISA.
The part that gets missed: if the vulnerability sits in a component you integrated rather than code you wrote, both you and the component's manufacturer carry separate notification duties. On an automotive Tier 1's bill of materials, a dozen or more third-party stacks in a single ECU is not unusual, and that alone turns a single CVE into a coordination problem before it's a paperwork problem.
Filing the report is not where programs fall over. What actually breaks is everything upstream of the filing: whether a security-relevant event in a shipped ECU gets detected in the first place, whether it's triaged and escalated internally inside that 24-hour window, and whether anyone in the building can answer "which of our shipped products contain this component" without a multi-day audit. That last one is an SBOM problem before it is anything else — the same ground ISO/IEC 18974 and ISO/SAE 21434 already require you to have covered.
We went through exactly this exercise ourselves. The open source security assurance process we self-certified against ISO/IEC 18974 (see the OpenChain Project's CRA compliance framework) is functionally the same discipline the CRA now requires: know what's in your product, track known vulnerabilities against it, and have a documented path from detection to response. The CSMS work we do with clients under UN R155 covers most of the rest — incident classification, escalation ownership, and the reporting muscle memory.
If you're assessing where you stand: map every product you place on the EU market and your role for each one (manufacturer, importer, or distributor — the obligations differ). Confirm you can trace a component-level advisory to the specific shipped products that contain it. Name an owner for the 24-hour clock, in writing, not "whoever's on call." And register for the Single Reporting Platform before you need it, not during an incident. We run this as a scoped readiness engagement for clients who want a second set of eyes on it — get in touch if that would help.
This note summarises publicly available regulatory information and is not legal advice. Primary sources: Regulation (EU) 2024/2847, and the European Commission's CRA implementation guidance (Communication C(2026) 5252), published 27 July 2026.