prEN 40000-1-3 Reaches the Pre-Formal Vote HAS Assessment

Over 2,000 comments, and a genuinely collaborative process

The draft went through formal review by CEN/CENELEC’s HAS Consultants and National Members, and internal WG9 review, with 2,202 individual comments in total, each requiring a documented response: accept, partially accept, reject with reasoning, or note for a future version. About two-thirds of the feedback led directly to changes in the text.

That volume of scrutiny is exactly what you want in a standard that’s going to underpin legal presumption of conformity. It’s slower, but it’s how you catch the gaps that matter before they become gaps in someone’s production compliance program.

A few of the changes that came directly out of that process:

A simpler risk model. The early draft included a whole separate “Applicability” phase dedicated to something called “Requirement Enhancements”, an extra layer of risk-tiered obligations manufacturers had to work out whether they needed. Following the review process, the enhancement mechanism was removed entirely. Instead of creating multiple requirement tiers, the standard now adopts a single, coherent set of vulnerability handling requirements that manufacturers apply proportionately using their own cybersecurity risk assessment under the CRA. The result is a document that is simpler to implement, easier to audit, and more closely aligned with the regulatory framework.

A new annex mapping every requirement to the risk it addresses. A process standard like this one should make its own logic visible: why does this requirement exist, and what happens if you skip it? The finalized standard now includes an informative annex doing exactly that: every vulnerability handling activity mapped to the risk it mitigates, so manufacturers can reason about proportionality using their own risk assessment rather than guessing.

Real support for multi-party disclosure. Modern software products increasingly depend on open-source software, commercial components and complex supply chains. Reflecting this reality, the standard now provides stronger support for multi-party coordinated vulnerability disclosure, incorporating concepts from ISO/IEC TR 5895 throughout the vulnerability handling lifecycle. This better reflects the collaborative nature of vulnerability handling under the CRA, where manufacturers frequently interact with suppliers, researchers, maintainers and downstream stakeholders.

A consistent distinction between third-party and non third-party components. This is probably the most substantive technical shift between the first draft and the final version, and it runs through the whole document rather than sitting in one clause. The early draft applied uniform rules regardless of where a component came from. The finalized standard consistently separates what a manufacturer controls from what they don’t, and applies full rigor to the former, a lighter reference-based path to the latter. It shows up in three places:

• Component identification. The old SBOM rule was flat: identify at least the top-level dependencies, full stop. Now, non third-party components, the code the manufacturer actually writes and controls, must be completely identified and documented, with the conformity assessment explicitly requiring evidence of that completeness. Third-party components only need to be identified at least at the directly-integrated level, reflecting the practical reality that manufacturers often can’t obtain full transitive-dependency data from every upstream supplier.
• Verification. A new requirement means that where a vulnerability sits in a third-party component, is fully mitigated by an available remediation, and that remediation has been applied, several otherwise-mandatory downstream steps become optional. In plain terms: if you’ve installed the upstream vendor’s patch, you don’t need to run your own full internal risk-assessment and remediation-decision paperwork on a vulnerability someone else has already fixed.
• Release advisories. For vulnerabilities in a manufacturer’s own components, the published advisory must be fully detailed, description, identifiers, dates, severity, impact, remediation guidance, contact information. For third-party component vulnerabilities, the manufacturer can instead reference the third party’s own published advisory or the updated version, rather than duplicating information they didn’t produce.

The same pragmatism shows up in hardware identification. The early draft required identifying every hardware component integrated in the product; the final version scopes this to components directly contained in the product, promotes component version from an optional extra to a mandatory recorded field, and adds a practical fallback: where the required information isn’t available or sufficient, the manufacturer documents whatever information does support vulnerability handling. That’s a requirement written by people who have actually tried to get complete component data out of a hardware supply chain.

Direct traceability to the CRA’s legal text. The standard’s Annex ZA, the table that ties each clause back to a specific essential requirement in Annex I of the CRA, is what actually allows this document to grant presumption of conformity once it’s cited in the Official Journal. Getting that correspondence table right, cleanly structured and complete, was one of the most detail-heavy parts of the review process, and it’s now fully in place.

A standard that stands on its own. Earlier drafts leaned on a companion standard (Part 1-2) as a normative dependency, which would have meant manufacturers needed both documents just to claim conformity with this one. That dependency has been removed; prEN 40000-1-3 is now self-contained, referencing other standards only informatively. This significantly improves usability for manufacturers implementing vulnerability handling processes.