12 September, 2026
If you’ve landed here searching “en 40000-1-4” or “pren 40000-1-4,” you’re looking at the technical heart of Cyber Resilience Act compliance. This page explains what the standard is, how it’s structured, and what to do about it now.
What is prEN 40000-1-4?
prEN 40000-1-4 is the draft European standard that translates the CRA’s essential cybersecurity requirements into a catalogue of concrete, testable security controls. It’s the second project (PT2) in the EN 40000 series, and for most manufacturers it will be the single most consulted document in that series, because it’s where the law’s requirements stop being legal text and start being engineering decisions.
The “pr” prefix means the standard is still in draft: it hasn’t been formally adopted yet, so the content below reflects the current draft direction, not a finished, citable standard. Treat it as the best available guidance today, and expect refinement before final publication.
How the standard is built
prEN 40000-1-4 doesn’t invent new obligations. It takes the CRA’s essential requirements and works them down to something a security team can actually implement, through three layers:
Essential requirements.
These map directly to CRA Annex I, Part I (a) through (m), the legal text every product with digital elements has to satisfy, and which you can read in full on our essential requirements explainer.
Security objectives.
Each essential requirement is broken into one or more objectives, statements of what a product needs to achieve, independent of how.
Control requirements.
Each objective is backed by specific, assessable controls, the technical criteria an auditor or a tool like SAMMY can actually check against.
That requirement-to-objective-to-control structure is the whole point of the standard: it’s what turns “ensure an appropriate level of cybersecurity” into something you can build a checklist from.
How it maps to the CRA’s essential requirements (a-m)
The Cyber Resilience Act requires that products with digital elements “be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.” That obligation breaks down into thirteen sub-requirements, (a) through (m):
| CRA Annex I requirement (verbatim, condensed) | prEN 40000-1-4 control focus |
| (a) “be made available on the market without known exploitable vulnerabilities” | Vulnerability assessment and remediation before release |
| (b) “be made available on the market with a secure by default configuration… including the possibility to reset the product to its original state” | Default credentials, disabled insecure protocols, secure baseline configuration |
| (c) “ensure that vulnerabilities can be addressed through security updates, including… automatic security updates… with a clear and easy-to-use opt-out mechanism” | Update mechanisms, patch delivery, update authenticity |
| (d) “ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access” | Authentication, authorisation, access logging |
| (e) “protect the confidentiality of stored, transmitted or otherwise processed data… such as by encrypting relevant data at rest or in transit by state of the art mechanisms” | Encryption at rest and in transit, key management |
| (f) “protect the integrity of stored, transmitted or otherwise processed data… against any manipulation or modification not authorised by the user, and report on corruptions” | Integrity checks, tamper detection |
| (g) “process only data… that are adequate, relevant and limited to what is necessary in relation to the intended purpose” (data minimisation) | Data collection scoping, minimisation controls |
| (h) “protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks” | Resilience, DoS protection, essential-function isolation |
| (i) “minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks” | Network and resource impact controls |
| (j) “be designed, developed and produced to limit attack surfaces, including external interfaces” | Attack surface reduction, unused feature disablement |
| (k) “be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques” | Sandboxing, privilege separation, mitigation mechanisms |
| (l) “provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user” | Logging, monitoring, audit trails |
| (m) “provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner” | Secure deletion, factory reset, data portability |
A worked example: requirement (b) in practice
Take a connected security camera.
Requirement (b) says the product must ship “with a secure by default configuration… including the possibility to reset the product to its original state.” In prEN 40000-1-4 terms, that single sentence turns into a working set of controls: no shared or hardcoded default password, a forced unique-credential setup on first use, insecure legacy protocols (like unauthenticated Telnet access) disabled out of the box rather than left on for convenience, and a genuine factory reset that returns the device to that same secure baseline rather than to whatever configuration a previous owner left behind.
That’s the pattern across all thirteen requirements: a short legal sentence in Annex I, and a specific, checkable set of engineering decisions in prEN 40000-1-4. Once you can see the pattern for one requirement, the rest of the mapping table above reads the same way.
Where the controls come from
Rather than building a new framework from nothing, prEN 40000-1-4 reuses and builds on standards that already have real-world adoption:
- EN 18031:2024, the radio equipment security standard, contributes controls for connected and wireless products.
- IEC 62443-4-2 contributes component-level requirements familiar to industrial and operational-technology vendors.
- ETSI EN 303 645 contributes consumer IoT security provisions.
If your product already has to satisfy one of these, you’re not starting from zero on CRA compliance, you’re extending work you’ve likely already done. You can use SAMMY to map between the different frameworks.
Timeline
prEN 40000-1-4 is still in drafting. Its sibling standards, EN 40000-1-2 and EN 40000-1-3, have already completed public enquiry and are listed as Under Approval on the official CEN standards portal, but as of this writing neither has a confirmed publication date on that record. prEN 40000-1-4 itself is further behind: public enquiry, the stage where the draft opens for formal comment, was expected to run into November 2026.
30 October 2027 is the target publication date, and it comes directly from CEN-CENELEC’s own working group, not just a figure repeated across the compliance blogosphere. Their CRA Standards Unlocked webinar slides on PT2 (the working name for this standard) show an indicative timeline running enquiry and formal vote through 2026 and into “PT2, 30 October 2027, Publication by ESOs.” That’s roughly a year between the end of public enquiry and publication, which lines up with the normal CEN process (resolving enquiry comments, formal vote, then administrative publication steps), so the gap isn’t unusual. The slide itself notes the whole timeline “is indicative and will be adapted as [CEN processes] higher priority items,” so treat 30 October 2027 as CEN’s own current best estimate, not a contractual guarantee, and expect it could shift.
Until any of these are formally published, manufacturers can work from the CRA framework in SAMMY that has a complete list of requirements based on the legal text and the preliminary horizontal standards. You can use SAMMY for free on SAMMY.codific.com. <<insert a video about using the CRA framework in SAMMY.
How to get ready now
You don’t need to wait for formal publication to start, and you don’t need to build your own tracking system from scratch to do it. SAMMY’s CRA framework is built around this exact requirement-to-control structure, so it’s a practical place to do this work rather than just a checklist you keep in a spreadsheet:
- Start with a scope assessment. Before you map anything, confirm your product is actually in scope, and how deeply. SAMMY’s free CRA Scope Assessment takes about 3 minutes and tells you where you stand before you invest time elsewhere.
- Map your product against the essential requirements inside SAMMY’s CRA framework, rather than a static copy of Annex I. The requirements are already law regardless of when the standard publishes, and working inside the framework means your mapping becomes evidence you can show, not just notes you took.
- Use the requirement-to-control table on this page as your starting checklist, then track your actual progress against it in SAMMY, so it evolves as the draft standard does instead of going stale in a document.
- Check what you already have against SAMMY’s other supported frameworks. If your product touches EN 18031, IEC 62443-4-2, or ETSI EN 303 645, SAMMY’s framework mappings show you what’s reusable before you build anything new.
Manage and demonstrate CRA compliance with SAMMY.
Review the requirements, track your evidence as you build toward them, and generate the documentation you’ll need to show conformity, all in one place.
Is prEN 40000-1-4 mandatory?
12 September, 2026
The standard itself isn’t mandatory, but the CRA essential requirements it maps to are law. Following a harmonised standard gives you a presumption of conformity, it’s the easiest path to compliance, not the only one.
What's the difference between prEN 40000-1-4 and the other EN 40000 standards?
12 September, 2026
EN 40000-1-2 sets general risk-based principles, EN 40000-1-3 covers vulnerability handling over a product’s life, and EN 40000-1-1 defines shared vocabulary. prEN 40000-1-4 is the one that turns requirements into testable controls, it’s the most operational of the four.
When will prEN 40000-1-4 be published?
12 September, 2026
There’s no confirmed date yet. A 2027 target is commonly cited, but the standard is still in drafting and CEN hasn’t locked in a publication date. This page will be updated as that changes.
Does my product need to comply with every control in the table?
12 September, 2026
Only the essential requirements that apply to your product’s risk profile and category. Not every product touches every requirement, for example, data minimisation controls matter more for data-processing products than for simple embedded devices.
What should I do while the standard is still a draft?
12 September, 2026
Work from the CRA’s Annex I text directly, treat the draft control mapping as your best current guidance, and use a tool like SAMMY to track evidence as your compliance work progresses, so you’re not starting from scratch once the standard is finalised.
Manage and demonstrate CRA compliance with SAMMY
The EU Cyber Resilience Act is here. SAMMY walks you through the requirements, tracks your evidence as you go, and produces the documentation you need to show conformity.
- Review CRA requirements
- Demonstrate compliance with evidence
- Generate legal documentation
