Obligations of manufacturers 製造商的義務

Article 13 is the load-bearing wall of the entire CRA. If you manufacture anything with a chip and a network connection that ends up on the EU market — whether it is a router, a toy, a CNC controller, or a Linux-based industrial gateway — this is the article that tells you what you must do. All 25 paragraphs orbit four duties: design it securely, assess the risk, handle vulnerabilities for the support period, and prove it on paper.

The paragraph that surprises people most is paragraph 5 — due diligence on third-party components. If you put a Realtek chip or an open-source cryptography library inside your product, you are on the hook for its vulnerabilities. Not the original author. You.

"Security is no longer a feature you can add late. Under Article 13(1), it has to be baked in from the design phase — or the product cannot bear CE marking."

The other trap is paragraph 8 — vulnerability handling for the support period. You declare how long you'll support the product. That clock is now a legal commitment, not a marketing sticker. Under-declare and you lose market access; over-declare and you carry a multi-year compliance burden.

How vulnerability handling actually decomposes — six phases, not one duty

Article 13 says manufacturers shall handle vulnerabilities. It does not tell you how. The how lives in prEN 40000-1-3, the harmonised standard CEN-CENELEC JTC 13 WG 9 is drafting against this article. The standard divides vulnerability handling into six sequential phases, each with its own requirement IDs and its own expected outputs. Reading these in order is the cleanest mental model I've found for what Article 13(8) is actually asking for.

1. [PRE] Preparation — write the policies and build the receipts

This is everything you do before the first vulnerability ever lands in your inbox. Ten requirements (PRE-1 to PRE-10) covering: an internal vulnerability handling policy [PRE-1-RQ-01]; a public coordinated vulnerability disclosure (CVD) policy [PRE-2-RQ-01]; operational security for sensitive vulnerability data [PRE-3]; secure communication channels [PRE-5]; product identification (SKU, version, build) [PRE-6]; and — the heaviest two — software bill of materials [PRE-7] and hardware bill of materials [PRE-8]. PRE is where most APAC manufacturers will spend their first six months of remediation work, because the SBOM/HBOM requirement is structural: you cannot add it after the fact, you have to build it into your CI/CD.

2. [RCP] Receipt — make sure reports actually reach you

Seven requirements covering how vulnerability reports come in. RCP-1 demands a documented capability to receive reports — in practice, a security.txt file at /.well-known/security.txt, an email alias, a CVD coordinator relationship. RCP-2 requires monitoring — you have to actively watch CVE feeds, vendor security advisories of your upstream components, NVD, and your own bug bounty pipeline. RCP-3 and RCP-4 require you to map a newly disclosed CVE in any of your software or hardware components back to the products that contain them; this is where the SBOM from PRE-7 becomes operational. RCP-6 and RCP-7 require regular tests and reviews on your own product, not just reactive intake.

3. [VRF] Verification — triage

Two requirements (VRF-1, VRF-2). VRF-1 is the assessment: is the report credible, reproducible, applicable to your product, and what is the severity? VRF-2 is the prioritisation: given the severity and exploitability, what's the queue position? The deliverable is "a tracked, verified vulnerability report including an assessment of the vulnerability and its severity" — which becomes the input to remediation and, if the bar is met, the input to your Article 14 SRP notification.

4. [RMD] Remediation — decide, build, test

Three requirements (RMD-1 to RMD-3). RMD-1 is the decision (patch, mitigate, accept, withdraw), RMD-2 is the actual fix development, RMD-3 is testing the fix for effectiveness and compatibility. Compatibility is the trap APAC OEMs underestimate: a fix that breaks customer integrations is a fix that gets rejected. The deliverable is a tested remediation, ready to ship.

5. [RLS] Release — ship the update, publish the advisory

Two requirements. RLS-1 covers the security update distribution itself — secure channel, integrity verification, automatic update for consumer products, installation instructions. RLS-2 covers the advisory: a publication that lists the vulnerability, identifier (CVE), affected product, impact, severity, and remediation steps. RLS-2-RQ-03-RE specifies a machine-readable format, and the standard explicitly references CSAF 2.0 (ISO/IEC 20153:2025). RLS-2-RC-01 expects the information to land in the EU Vulnerability Database (EUVD). If you've never published a CSAF document before, this is the requirement that will surprise your engineering organisation the most.

6. [PRA] Post-release — measure, learn, improve

One requirement (PRA-1) but a heavy one. After the patch is out, you monitor adoption (did users actually install it?), capture lessons learned, and feed those learnings back into PRE — better policies, sharper detection, faster triage next time. This is the loop that makes vulnerability handling a process, not a project.

Reading Article 13(8) without this six-phase decomposition makes the obligation feel like a single black box. Reading it through prEN 40000-1-3 makes it operational: each phase has named outputs, and a notified body or market surveillance authority can ask you for any of them by name. Build your evidence binder along these six phases and audit becomes recognition, not surprise.

→ Long read: which of these six phases must be done by September 2026, and which can wait for December 2027