Reporting obligations of manufacturers 製造商的通報義務

The three clocks that decide everything

Article 14 runs on three stopwatches, and all of them start the moment the manufacturer becomes aware. Not the moment you confirm, not the moment you finish forensic analysis — the moment a reasonably informed engineer could say "this looks like an actively exploited vulnerability in our product." The CRA defines "actively exploited" as a vulnerability where reliable evidence shows a malicious actor has used it without the system owner's permission. That is a lower bar than criminal-proof confirmation.

24 hours gets you an early warning — product name, a sentence of context, affected Member States if you know. 72 hours adds technical detail. 14 days delivers a final report, but the 14-day clock only starts when a corrective or mitigating measure is available, not at discovery. For severe incidents, the final report window extends to one month.

Why September 2026 bites before December 2027

The rest of the CRA — conformity assessment, CE marking, technical documentation — applies from 11 December 2027 and only to products placed on the market from that date. Article 14 is the exception. It applies from 11 September 2026 and it reaches back to every CRA-covered product already sitting in EU buyers' hands. A product shipped in 2023 is still covered in 2026 if it is still being made available on the EU market.

That single design choice transforms Article 14 from a "future compliance project" into a "now operational obligation." If your PSIRT, SBOM inventory, and ENISA SRP account do not exist by August 2026, you will miss the window on your first real incident.

→ Long read: what 11 September 2026 actually binds you to (and what it doesn't)

One submission, not twenty-seven — but pick the right CSIRT

Article 14(7) solves a problem many APAC exporters have feared: that shipping to 27 Member States might mean 27 parallel notifications. It does not. You submit once, the receiving CSIRT forwards to ENISA and to all other relevant national CSIRTs, and your legal team needs to identify one CSIRT, not twenty-seven.

The trickier question for non-EU manufacturers is which CSIRT. Most articles online describe it as "the authorised representative's Member State" and stop there. The actual rule is a strict four-step waterfall, and each step uses a highest-number tie-breaker:

1. The Member State where the authorised representative acting on behalf of the manufacturer for the highest number of products is established.
2. If no auth. rep, then the Member State of the importer placing on the market the highest number of products.
3. If no importer, then the Member State of the distributor making available the highest number of products.
4. If none of the above can be identified, then the Member State with the highest number of users.

Two consequences APAC exporters routinely miss. First: a Taiwan ODM that sells through five different EU importers without designating an authorised representative will land at step (b) — the importer with the highest unit volume — regardless of where the OEM brand sits. Second: distribution patterns shift. The CSIRT you reported to in Q3 may not be the right one in Q1 next year if your importer mix moves. The regulation lets you keep using the same CSIRT once you reach step (d), but not earlier in the waterfall — for steps (a) through (c) you have to re-evaluate when your distribution shifts. Build that re-evaluation into your incident response plan now, not on day one of an actual incident.

The small-company carve-out you should not rely on

Article 64(10)(a) gives microenterprises and small enterprises (under 50 employees, up to €10M turnover) a narrow reprieve: you cannot be fined specifically for missing the 24-hour early warning deadline. This is timing relief only. You still must report, still must meet the 72-hour and 14-day deadlines, and still face fines for those. And the moment you cross 50 employees or €10M, the relief evaporates. Treat it as a soft landing for scale-ups, not a strategy.

The OSS-steward sub-regime almost everyone missed

If you are an open-source software steward — a legal person systematically supporting the development of FOSS products that are eventually placed on the market — Article 24 carves you out of most of Article 14. Two exceptions only. Article 14(1) (the duty to notify actively exploited vulnerabilities) applies to stewards only to the extent they are involved in the development of the product. Article 14(3) and 14(8) (the duty to report severe incidents and to inform users) apply only when the severe incident affects the network and information systems the steward provides for the development. Everything else — the 24/72/14-day clocks of 14(2), the incident clocks of 14(4), the CSIRT cascade of 14(7), the delegated and implementing acts of 14(9) and 14(10) — does not apply to stewards.

And then, even more decisively, Article 64(10)(b) makes stewards completely fine-exempt for any infringement of the CRA. This is the strongest carve-out in the entire regulation. The legislative intent is to avoid chilling the foundations the rest of the digital economy depends on. The practical implication is that a steward like the Apache Software Foundation, the Linux Foundation, the OpenSSL Foundation, or the OpenJDK community has obligations to write a security policy and to cooperate with market surveillance authorities, but cannot be compelled by fines to operate the same incident-reporting machinery a commercial manufacturer does.

Why this matters for APAC: many Asian hardware vendors fund and contribute to upstream OSS projects. The vendor's commercial product is fully in scope; the upstream steward is mostly out of scope. Do not conflate the two regimes when designing your supply-chain due diligence under Article 13(5).