The Cyber Resilience Act tells manufacturers what their products must achieve. The EN 40000 family is meant to tell them how. Four horizontal parts, drafted in CEN/CLC/JTC 13 WG 9 under standardisation request M/606, set the common baseline. Vertical standards then turn that baseline into requirements for specific product types such as routers, operating systems or network functions.
I work on this family from the inside, as Rapporteur for prEN 40000-1-3 (Vulnerability handling) and prEN 40000-1-4 (Generic security requirements). This article explains how the parts fit together, where each one stands, and what that means for manufacturers preparing for 11 December 2027.
I have touched on several of these points before: in an interview with ITS, the Swedish ICT standardisation body (June 2026), and in the APPtake instant paper on AI-assisted coding and the CRA I co-wrote with Enrico Frumento (July 2026). This piece pulls those threads together.
The family at a glance
Each horizontal part answers a different piece of the CRA; vertical standards pick from Part 1-4 and add what their product category needs.
The four horizontal parts
EN 40000-1-1 – Vocabulary. The shared dictionary. Every other part refers to it normatively, so terms such as product, component or RDPS mean the same thing everywhere in the family. It received 100% approval and is close to publication, as WG 9 Convenor Ben Kokx announced.
EN 40000-1-2 – Principles for cyber resilience. The process backbone: cybersecurity risk management and the lifecycle activities a manufacturer runs from design to end of support. It was built on CRA Annex I, Part I (1), the overarching requirement that products ensure an appropriate level of cybersecurity based on the risks. It also supports the manufacturer’s obligation under Article 13 to carry out and document a cybersecurity risk assessment, and that risk assessment drives everything else. Like Part 1-1, it received 100% approval and is close to publication: these two are the first parts of the family to cross the line.
FprEN 40000-1-3 – Vulnerability handling. Its goal is to keep the product secure throughout its support period. Where Part 1-4 secures the product when it is placed on the market, Part 1-3 keeps it secure afterwards, through the processes behind CRA Annex I, Part II: identifying components, receiving and triaging reports, remediating, disclosing and distributing updates. As I said in the ITS interview, it is the horizontal part designed to carry presumption of conformity on its own, and the one every other CRA standard will refer to for vulnerability handling. It went through Public Enquiry from December 2025 to March 2026, roughly 2,200 comments were resolved, and in August 2026 it was submitted for the pre-Formal Vote assessment (details here).
The Commission’s assessment produced a further 36 comments, which WG 9 addressed. In its follow-up, DG CNECT had no further comments, and WG 9 has now prepared and agreed the draft for Formal Vote. If no objections to registering it for Formal Vote reach the JTC 13 secretariat by 23 October 2026, the JTC 13 Chair and secretariat will confirm consensus to send it to Formal Vote. The Formal Vote runs for at least 35 days, so publication is expected between the end of 2026 and February 2027 at the latest, depending on how fast the remaining steps move.
prEN 40000-1-4 – Generic security requirements. A catalogue of 65 technical controls in 18 families, each with rationale, guidance and a pass/fail assessment method, mapped to the thirteen product requirements of Annex I, Part I, (2)(a) to (2)(m). It builds on the EN 18031 series written for the Radio Equipment Directive, extended to everything the CRA covers.
Vertical standards. Product-category standards, prepared in CEN-CENELEC and ETSI, that select controls from Part 1-4, tighten them where needed and add category-specific requirements. They are the main route to presumption of conformity for the important and critical products listed in Annexes III and IV.
How the parts work together
The parts are designed to be used together, along the life of a product:
- Speak the same language with Part 1-1.
- Assess the risk with Part 1-2. What is the product for, where will it be used, what can go wrong?
- Select and verify controls with Part 1-4. The risk assessment decides which controls apply; each selected control comes with its own test method and evidence.
- Handle vulnerabilities with Part 1-3, for the whole support period: know your components, receive reports, fix, disclose, update.
The common thread is the risk assessment. In the ITS interview, I listed skipping it as one of the most common mistakes I see, together with underestimating the CRA’s scope and hoping for another postponement. It also explains a principle that runs through the whole family:
- a default-category product is not automatically a low-risk product. The same component can sit in a consumer gadget or in an energy or telecom network. The horizontal baseline is shared; the depth of the controls follows the risk.
- The second thread is proportionality. The CRA does not demand perfection. It demands that you reduce vulnerabilities and handle them in a structured, documented way, with a realistic roadmap that improves over time.
As the APPtake paper puts it, a policy does not stop a vulnerability, but without one there is no framework to act systematically.
A new pressure on the family: AI-generated code
In the APPtake instant paper, Enrico Frumento and I looked at what “vibe coding” does to CRA compliance. The standards were not written with AI-generated code in mind, but they answer it well:
- Responsibility does not transfer. The manufacturer is liable for every defect, including those an AI tool introduced. An LLM is a tool, not a legal entity.
- Component visibility becomes harder. AI tools pull in dependencies nobody chose consciously. That is exactly where Part 1-3’s component identification and Part 1-4’s [GEC-1] (no insufficiently mitigated known exploitable vulnerabilities) and [GEC-13] (no unneeded software components) bite.
- Exploitation is faster. The window between discovery and exploitation has collapsed from years to roughly a day. Manual, reactive processes cannot keep up, so the controls for automatic updates, monitoring and resilience in Part 1-4 become structural, not optional.
The answer is not to stop using AI, but to move from ungoverned vibe coding to AI-assisted engineering, with humans in control of architecture, verification and security.
Where each part stands
| Part | Where it stands |
|---|---|
FprEN 40000-1-1 Vocabulary | Approved, 100% |
FprEN 40000-1-2 Principles | Approved, 100% |
FprEN 40000-1-3 Vulnerability handling | Formal Vote draft agreed by WG 9; goes to Formal Vote if no JTC 13 objections by 23 October 2026 |
prEN 40000-1-4 Generic security requirements | Draft submitted to the European Commission for assessment, July 2026, ahead of CEN Enquiry |
Parts 1-1 and 1-2 both received 100% approval, as announced by WG 9 Convenor Ben Kokx, in line with the October 2026 target I gave in the ITS interview. The other dates are the targets from that interview. Standardisation timelines move; the CRA’s do not. Reporting obligations have applied since 11 September 2026, and the full regulation applies from 11 December 2027.
Why does it take this long? European standards are adopted by consensus, not majority vote. The Commission pushes for strong, verifiable requirements; national bodies, where manufacturers are well represented, push for proportionate ones. Every objection has to be addressed, and the text has to hold up against the wording of the law. As I put it to ITS: the sharpest version doesn’t always win, but the most durable one does.
What to do now
Waiting for the final standards is the riskiest strategy available. The drafts are public enough, and stable enough in their structure, to work with today:
- Classify your products. Default, important (Class I or II) or critical decides whether you can self-assess, and whether harmonised standards are optional or your ticket to self-assessment.
- Run the risk assessment first. Use the Part 1-2 principles. Everything downstream depends on it.
- Gap-analyse against the Part 1-4 catalogue. If you already comply with EN 18031 for the RED, you are not starting from zero.
- Put vulnerability handling in place now. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents, and the reporting clock starts when you become aware of them. The reporting obligation does not require Part 1-3, but having its processes in place makes that awareness faster and far more predictable.
- Get involved. SMEs hold practical knowledge that makes standards workable. You do not need to be an expert in everything to contribute through your national body.
Further reading
- CRA standards play different roles – interview with Angelo D’Amato, ITS, 18 June 2026
- AI-Assisted Coding and the Cyber Resilience Act, APPtake instant paper by Angelo D’Amato and Enrico Frumento, July 2026
- prEN 40000-1-3 reaches the pre-Formal Vote HAS assessment, Vulnir, 3 August 2026
- Announcement of the approval of EN 40000-1-1 and EN 40000-1-2, Ben Kokx, Convenor of CEN/CLC/JTC 13 WG 9, LinkedIn
Help needed for your compliance journey?
At Vulnir, we help manufacturers turn the EN 40000 family into day-to-day practice: product classification, risk assessments that justify control selection, gap analyses against prEN 40000-1-3 and prEN 40000-1-4, and training for product and test teams. If you want to know where you stand, get in touch.
Get In Touch