Europe’s new cybersecurity standard for products with digital elements
The prEN 40000 series is the first horizontal European standard designed to support compliance with the Cyber Resilience Act (CRA). It covers everything from vocabulary and principles to vulnerability handling, generic security requirements, and threat modelling. Here is what manufacturers, importers, and distributors need to know.
Why EN 40000 matters now
The Cyber Resilience Act (Regulation (EU) 2024/2847) establishes mandatory cybersecurity requirements for virtually all products with digital elements sold in the European Union. From connected consumer devices to industrial software, the CRA demands that manufacturers build security in from the start and maintain it throughout a product’s lifecycle.
But regulation alone does not tell you how to comply. That is where harmonised standards come in.
The prEN 40000 series is being developed by CEN/CLC/JTC 13 “Cybersecurity and Data Protection” under Commission standardisation request C(2025)618 (known as M/606). Once these standards are cited in the Official Journal of the EU, compliance with them provides a presumption of conformity with the CRA’s essential cybersecurity requirements. In practical terms, following EN 40000 is the most straightforward path to demonstrating CRA compliance.
All five parts are currently in draft, submitted for CEN Enquiry. Parts 1-4 and 1-5 are at an earlier draft stage than the first three. The standards are expected to be finalised and cited before the CRA’s full application date of 11 December 2027, though manufacturers should not wait for final publication to start preparing.
The EN 40000 family at a glance
The series comprises five documents, each addressing a different aspect of product cybersecurity.
EN 40000-1-1 (Vocabulary) provides the common terminology and definitions used across the series. Draft, CEN Enquiry stage.
EN 40000-1-2 (Principles for cyber resilience) establishes the core cybersecurity principles, risk management methodology, and lifecycle activities. Draft, CEN Enquiry stage.
EN 40000-1-3 (Vulnerability handling) defines requirements for managing vulnerabilities throughout the product lifecycle. Draft, CEN Enquiry stage.
EN 40000-1-4 (Generic security requirements) catalogues specific security requirements mapping to CRA Annex I. Draft, CEN Enquiry stage, earlier than the first three parts.
TR 40000-1-5 (Threats and security objectives) maps threats to security objectives for risk assessment purposes. This is a Technical Report rather than a normative standard. Draft, TR Vote stage.
The documents are designed to work together. Part 1-1 provides the shared language. Part 1-2 establishes the overarching principles and framework. Part 1-3 addresses the specific obligation of vulnerability handling. Part 1-4 provides the detailed technical requirements. And TR 1-5 offers the analytical foundation for risk assessment by mapping threats to security objectives.
Importantly, EN 40000 is a horizontal standard. It applies across all product categories. Sector-specific (vertical) standards for particular industries can build on top of EN 40000, adding domain-specific requirements where needed. EN 40000 sets the baseline that every manufacturer must meet, regardless of sector.
EN 40000-1-1, the shared vocabulary
It may seem unusual to dedicate an entire standard to definitions, but anyone who has worked across multiple cybersecurity frameworks knows how much confusion arises from inconsistent terminology. “Risk”, “vulnerability”, “threat”, and “asset” can mean different things depending on which standard you are reading.
EN 40000-1-1 establishes the authoritative definitions for the entire series. Key terms include:
- Acceptable risk means risk that is accepted in a given context based on current values
- Asset refers to anything that has value to a person or organisation
- Authenticity is the property that an entity is what it claims to be
- Confidentiality, integrity, availability form the classic CIA triad, precisely defined
- Likelihood describes the chance of something happening
- Remediation covers action taken to fix a vulnerability
- Residual risk is the risk remaining after treatment
- Security objective is a statement describing what a security measure aims to achieve
- Software package refers to a distributable unit of software
These definitions align with established ISO/IEC terminology where possible, but are tailored to the CRA context. When preparing documentation for CRA conformity, using the exact terminology from EN 40000-1-1 ensures consistency and reduces the risk of misinterpretation during conformity assessment.
EN 40000-1-2, the core framework for cyber resilience
Part 1-2 is the heart of the EN 40000 series. It defines the cybersecurity principles, risk management methodology, and lifecycle activities that manufacturers must follow. If you only read one part of EN 40000, make it this one.
The four cybersecurity principles
EN 40000-1-2 establishes four foundational principles that underpin everything else.
1. Risk-based approach to cybersecurity. Security measures must be proportionate to the risks. Not every product needs the same level of protection. A connected pacemaker and a smart light bulb face different threat landscapes, and their security requirements should reflect that.
2. Security by design. Cybersecurity must be considered from the earliest stages of product development, not bolted on as an afterthought. This means integrating security into requirements gathering, architecture, design, implementation, and testing.
3. Secure by default. Products should be secure out of the box, without requiring the user to configure security settings. Default passwords, unnecessary open ports, and overly permissive access controls are exactly what this principle aims to eliminate.
4. Transparency. Manufacturers must be transparent about their products’ security properties, known limitations, and the measures taken to address risks. This includes providing clear security documentation to users.
Risk management framework
The standard defines a structured approach to risk management for product cybersecurity:
- Product context establishment to understand the product’s intended environment, users, and interfaces
- Risk acceptance criteria to define what level of risk is acceptable for the product
- Risk assessment as a four-step process covering asset identification, threat identification, risk estimation (likelihood and impact), and risk evaluation (comparing against acceptance criteria)
- Risk treatment through selecting appropriate responses such as avoidance, mitigation, acceptance, or transfer
- Risk communication to ensure relevant parties are informed about risks and treatment decisions
- Risk monitoring and review for ongoing reassessment as the threat landscape evolves
This framework will be familiar to anyone who has worked with ISO 27005 or IEC 62443-3-2, but it is specifically tailored for product manufacturers rather than organisations managing information systems.
Ten cybersecurity lifecycle activities
Perhaps the most practically significant part of EN 40000-1-2 is its definition of ten cybersecurity activities spanning the entire product lifecycle:
- Product cybersecurity planning to establish what cybersecurity work needs to happen and when
- Product cybersecurity requirements to define specific security requirements based on the risk assessment
- Cybersecurity architecture and design to translate requirements into a secure product architecture
- Secure implementation covering secure code, secure hardware configuration, and secure coding practices
- Cybersecurity verification and validation to test that security requirements are actually met
- Secure production and distribution ensuring the product is not compromised during manufacturing or delivery
- Cybersecurity issue management for handling security issues discovered after release
- Product monitoring to actively watch for new vulnerabilities and threats
- Planning for secure decommissioning ensuring products can be safely retired, including data deletion
- Third-party component cybersecurity management for managing the security of components sourced from other suppliers
That last activity is particularly important. Modern products incorporate dozens or hundreds of third-party components, each with its own security posture. EN 40000-1-2 introduces the concept of a Cybersecurity Supplier Agreement (CSSA), a framework for managing cybersecurity requirements in the supply chain. Annex B provides an informative example of what such an agreement should contain.
The standard also includes Annex C, which maps each requirement back to the specific essential cybersecurity requirements in CRA Annex I. This mapping is invaluable for compliance teams building their conformity documentation.
EN 40000-1-3, the vulnerability handling backbone
If EN 40000-1-2 defines what to build, EN 40000-1-3 defines what to do when things go wrong. And things will go wrong. Vulnerabilities emerge over time in every product, regardless of how well it was designed. The CRA makes vulnerability handling a mandatory obligation, not optional best practice. EN 40000-1-3 provides the framework for meeting that obligation.
The six-phase vulnerability lifecycle
The standard structures vulnerability handling into six distinct phases.
1. Preparation. Before you can handle vulnerabilities effectively, you need the right foundations in place. This includes a documented vulnerability handling policy, a coordinated vulnerability disclosure (CVD) policy so security researchers know how to report issues, operational security for your vulnerability handling processes, secure communication channels, product identification mechanisms, a Software Bill of Materials (SBOM) identifying all software components, hardware component identification where relevant, plans for regular security testing, and mechanisms for distributing security updates.
The SBOM requirement deserves special attention. The CRA mandates that manufacturers maintain an SBOM for every product with digital elements. EN 40000-1-3 specifies what that SBOM must contain and how it should be maintained. This is one of the most operationally demanding requirements for many manufacturers, particularly those who have not previously tracked their software supply chain in detail.
2. Receipt. This phase covers how you learn about vulnerabilities: maintaining the capability to receive reports from external researchers, users, and other sources; actively monitoring internal and external sources (CVE databases, security advisories, threat intelligence feeds); identifying which products and components might be affected; engaging coordinators such as national CSIRTs when appropriate; and conducting regular security testing to find vulnerabilities proactively.
3. Verification. Once a potential vulnerability is identified, it must be assessed through initial assessment to confirm whether the issue is genuine, vulnerability risk assessment to determine severity and exploitability, and prioritisation based on the risk assessment results.
4. Remediation. Confirmed vulnerabilities need to be fixed. This involves a remediation decision (patch, workaround, configuration change, or accept and document), remediation development, and remediation testing to verify the fix works without introducing new issues.
5. Release. Fixes need to reach users through established distribution channels, accompanied by advisories that inform users about the vulnerability and the available fix, including severity, affected versions, and remediation steps.
6. Post-release. After a fix is released, the work continues. This means monitoring adoption of the fix, watching for related vulnerabilities or exploitation attempts, and updating the risk assessment based on real-world information.
Beyond existing standards
EN 40000-1-3 builds on established vulnerability handling standards (EN ISO/IEC 30111 and EN ISO/IEC 29147) but goes significantly further. Key additions include mandatory SBOM requirements, regular testing and review for proactive vulnerability discovery, CVD obligations beyond just a contact email, risk-based rigour where higher criticality products undergo more frequent testing, and requirement enhancements for products where a security failure could have particularly severe consequences.
The CRA itself distinguishes between default, important, and critical product categories, and EN 40000-1-3 aligns its expectations accordingly.
EN 40000-1-4, the technical security requirements catalogue
Note: this part is at an earlier draft stage and subject to change.
While EN 40000-1-2 defines principles and processes, EN 40000-1-4 provides the specific technical security requirements that products must meet. It is structured as a catalogue of requirements that maps directly to the essential requirements in CRA Annex I, Part I(2).
The standard covers thirteen requirement areas:
- Vulnerability assessment for assessing and testing products against known vulnerabilities
- Secure configuration requiring products to support secure configuration and ship with secure defaults
- Security updates covering mechanisms for delivering and applying updates
- Access control including authentication, authorisation, and access management
- Confidentiality protection through encryption and data protection at rest and in transit
- Integrity protection with mechanisms to detect and prevent unauthorised modification
- Data minimisation ensuring products only process data necessary for their function
- Availability with resilience against denial-of-service and resource exhaustion
- External impact protection preventing products from negatively affecting the security of other systems
- Attack surface minimisation to reduce potential entry points for attackers
- Incident impact reduction to limit damage when a security incident occurs
- Logging and monitoring for recording and monitoring security-relevant events
- Data deletion ensuring users can securely remove their data from the product
Each area contains specific, testable requirements. Under access control, for example, the standard specifies requirements for authentication mechanisms, password policies, session management, and privilege separation. Under security updates, it addresses update integrity verification, rollback capabilities, and user notification.
The standard also defines security objectives that map to these requirements, providing the link between what you must do and why. This mapping is particularly useful when building conformity documentation, as it allows manufacturers to demonstrate that each CRA requirement is addressed by specific product features.
TR 40000-1-5, the analytical foundation for threat modelling
Note: this is a Technical Report (TR), not a normative standard, and is at an early draft stage.
TR 40000-1-5 takes a different approach from the other parts. Rather than defining requirements, it provides an analytical tool: a structured mapping of cybersecurity threats to security objectives for products with digital elements.
The document serves three purposes. First, it provides input for risk assessment. Manufacturers conducting the risk assessment required by EN 40000-1-2 can use it as a starting point for identifying relevant threats. Second, it provides a foundation for vertical standards. Industry-specific standards bodies can use the threat and objective mapping as a baseline. Third, it bridges to CRA requirements. The threats and objectives are derived from analysis of the essential requirements in CRA Annex I, making the document a useful reference for understanding the regulatory intent behind each requirement.
It is important to note that TR 40000-1-5 explicitly states it does not provide a complete list of all CRA-relevant threats. Manufacturers must still conduct their own product-specific risk assessment. The document provides a starting framework, not a finished analysis.
Who needs to pay attention
The EN 40000 series affects a broad range of stakeholders.
Manufacturers of products with digital elements are the primary audience. Whether you make connected consumer devices, industrial software, IoT gateways, or enterprise applications, EN 40000 provides the framework for demonstrating CRA compliance. This includes both hardware manufacturers and pure software companies.
Importers and distributors have due diligence obligations under the CRA. They must verify that products they place on the EU market meet the essential requirements. Understanding EN 40000 helps importers assess whether a manufacturer’s conformity claims are credible.
Open-source stewards, meaning organisations that systematically manage open-source projects intended for commercial use, have specific provisions under the CRA. EN 40000’s vulnerability handling requirements are particularly relevant here.
Conformity assessment bodies will use EN 40000 as the benchmark for evaluating product compliance, particularly for the “important” and “critical” product categories that require third-party assessment.
Sector-specific standard developers building vertical standards for automotive, medical devices, industrial automation, and other domains will use EN 40000 as their horizontal baseline.
The CRA timeline and what to do now
The CRA timeline is tight, and several deadlines are approaching.
- November 2024 saw the CRA published in the Official Journal
- December 2024 marked the CRA’s entry into force
- 11 September 2026 is when vulnerability reporting obligations begin
- 11 December 2027 is the full CRA application date
The September 2026 reporting obligation deserves particular attention. From that date, manufacturers must report actively exploited vulnerabilities to the relevant CSIRT within 24 hours. This requires having vulnerability monitoring and reporting processes in place well before the full CRA applies.
Practical steps to take now
Start with EN 40000-1-2. Understand the principles and lifecycle activities. Map your current development processes against the ten cybersecurity activities and identify gaps.
Establish vulnerability handling per EN 40000-1-3. This is operationally demanding and takes time to implement properly. Start building your SBOM capability, CVD process, and security update distribution mechanisms now.
Assess against EN 40000-1-4 requirements. Even in draft form, the generic security requirements indicate what the final standard will expect. Use them as a gap analysis checklist for your products.
Use TR 40000-1-5 for risk assessment. If you have not conducted a structured threat analysis for your products, the threat and objective mapping provides a solid starting point.
Prepare your conformity documentation. Start building the evidence trail that links your security measures to specific CRA requirements via the EN 40000 mapping.
Monitor standard development. The drafts will evolve before final publication. Track changes and adjust your approach accordingly.
Do not wait for the standards to be finalised. The CRA requirements are already defined in the regulation itself. EN 40000 provides the method for meeting those requirements, but the obligations are already law.
How EN 40000 relates to other standards
EN 40000 does not exist in isolation. Several established standards overlap with or complement the series.
IEC 62443 for industrial automation cybersecurity is the most widely adopted industrial cybersecurity framework. EN 40000 is horizontal and applies to all products with digital elements. IEC 62443 is vertical, focused on industrial automation and control systems. For industrial products, both may apply. IEC 62443-4-1 (secure development lifecycle) and IEC 62443-4-2 (component security requirements) align well with EN 40000’s lifecycle activities and security requirements respectively.
ISO 27001/27002 for information security management focuses on organisational security rather than product security. However, many risk management concepts overlap, and organisations already certified to ISO 27001 will find EN 40000’s risk management framework familiar.
ETSI EN 303 645 for consumer IoT security was an earlier European standard for IoT device security. EN 40000 is broader in scope, covering all products with digital elements, not just consumer IoT.
EN ISO/IEC 30111 and 29147 for vulnerability handling and disclosure are the foundation standards that EN 40000-1-3 builds upon. EN 40000-1-3 elevates many of their recommendations to mandatory requirements and adds CRA-specific obligations like SBOM and regular testing.
Preparing for the EN 40000 era
The prEN 40000 series represents a fundamental shift in how cybersecurity is regulated in the European market. For the first time, there is a comprehensive horizontal standard that manufacturers can follow to demonstrate compliance with the EU’s cybersecurity requirements for products.
The key takeaways:
- EN 40000 provides the most direct path to CRA compliance through presumption of conformity, once the standards are cited in the Official Journal
- The five parts work together to form a complete framework spanning vocabulary, principles, vulnerability handling, security requirements, and threat analysis
- The standards are still in draft but the direction is clear, and the underlying CRA requirements are already law
- Start now because vulnerability reporting obligations begin September 2026, full CRA compliance is required by December 2027, and implementing these practices takes time
- This is not optional since the CRA applies to virtually all products with digital elements sold in the EU
Manufacturers who align with EN 40000 now, even while the standards are being finalised, will be best positioned when the CRA deadlines arrive. Those who wait for final publication risk finding themselves non-compliant with no time to catch up.
The standards may still evolve in their details, but the fundamental principles (security by design, secure by default, risk-based approach, transparency, and mandatory vulnerability handling) are settled. Building on those principles today is the smartest investment a manufacturer can make.
