27 September, 2026
If you’re searching “en 40000-1-2,” you’ve found the standard that almost every manufacturer covered by the Cyber Resilience Act will end up touching, whether or not a product-specific standard exists for what you make.
What is EN 40000-1-2?
EN 40000-1-2 is the first project (PT1) in the EN 40000 series, and it’s officially titled “Cybersecurity requirements for products with digital elements, Part 1-2: Principles, product risk management, and lifecycle activities.”
Its own scope statement puts it plainly: the standard establishes generic cybersecurity principles that apply at every stage of a product’s life, specifies how to assess and treat cybersecurity risk, and lays the groundwork that more specific, product-category standards (the “vertical” standards, now due 31 December 2026 after the Commission’s 2026 amendment pushed the original 30 October 2026 mandate deadline back two months) will build on.
It does not, on its own, tell you which specific technical controls to implement, that’s prEN 40000-1-4’s job. EN 40000-1-2 is about process and principle: how you think about risk, not which encryption algorithm you pick.
Why it’s the “catch-all” standard
Most manufacturers will eventually work with a product-specific (“vertical”) standard once one exists for their category. Until then, and even after, EN 40000-1-2 is what applies. It’s the CRA’s Article 13 obligations turned into a working process: every manufacturer has to assess cybersecurity risk and act on that assessment, regardless of what they’re building. EN 40000-1-2 is what makes that obligation concrete and consistent across the whole market, rather than every manufacturer inventing their own version of “risk-based.”
The risk-based approach explained
The CRA doesn’t ask every product to meet every possible security measure at maximum strength. It asks manufacturers to assess risk and respond proportionately. Under Article 13 of the regulation, that means:
- Assessing cybersecurity risk before and during design, development, and production, not as an afterthought before shipping.
- Documenting that assessment and keeping it updated for as long as the product is supported.
- Using the assessment to decide which of the essential requirements in Annex I apply, and how they’re implemented, then justifying in the technical documentation any requirement that doesn’t apply.
- Exercising due diligence over third-party and open-source components integrated into the product, so a component you didn’t build doesn’t undermine your compliance.
In practice, that’s an ongoing inventory, not a one-time exercise, which is exactly what SAMMY’s Product Risk and Compliance (PRC) capability is built for: bringing risk assessments, component inventory, and threat modeling into one place instead of scattered spreadsheets you have to remember to update.
One specific, concrete number worth knowing: manufacturers must maintain a “support period,” the window during which they’ll keep handling vulnerabilities and issuing updates, and the regulation sets a floor of at least five years, unless the product is genuinely expected to be in use for less time. EN 40000-1-2 is where the process for determining and documenting that support period gets standardised.
How it relates to -1-3 and -1-4
Think of the three as a stack, not a checklist you work through once:
- EN 40000-1-2 sets the principles and the risk-assessment process, this page.
- EN 40000-1-3 takes over for the ongoing part: vulnerability handling once the product is already on the market.
- prEN 40000-1-4 supplies the actual technical controls, the specific things you build, mapped to each essential requirement.
You don’t pick one, you need all three (plus a vertical standard, once one applies to your product category) to have a complete compliance picture.
Status
EN 40000-1-2 has completed public enquiry and reached Formal Vote (FprEN) on the official CEN standards portal, the closest to final of any EN 40000-1 document as of this writing, but CEN has not yet posted a confirmed publication date. Its sibling standards, EN 40000-1-3 and EN 40000-1-1, are also under approval; prEN 40000-1-4 is further behind, still in drafting. Separately, worth distinguishing: the Commission’s mandate to CEN, CENELEC and ETSI (M/606) sets its own delivery deadline for the drafters, currently 31 October 2026 for this group of standards after a 2026 amendment pushed the original 30 August 2026 date back two months, but a mandate delivery deadline is not the same as formal publication or citation in the Official Journal, which is what actually confers the presumption of conformity.
None of that changes your obligations today: the CRA’s Article 13 requirement to assess and document risk is already law, independent of when any harmonised standard is formally published or cited.
How to comply
You can start building a compliant risk-assessment process now, ahead of publication:
- Set up a documented, repeatable risk assessment process, covering intended purpose, foreseeable use, and operational environment, not a one-off exercise. A PRC tool like SAMMY can help keep this current rather than static.
- Decide your support period now, and be ready to justify it. Five years is the floor, not a default you can assume applies to everything you make.
- Audit your third-party and open-source dependencies. Due diligence over components you didn’t write yourself is an explicit obligation, not a nice-to-have.
- Keep the risk assessment updated, and keep it in your technical documentation, ready to produce, not written once and filed away.
Not sure if this applies to you?
Run the free CRA Scope Assessment in SAMMY, takes about 3 minutes, and tells you exactly where your product stands.
FAQ
Is EN 40000-1-2 mandatory?
The standard itself is voluntary, but the underlying obligation, assessing and documenting cybersecurity risk under Article 13 of the CRA, is already law. Following the harmonised standard once published will be the easiest way to demonstrate compliance.
What’s the difference between EN 40000-1-2 and EN 40000-1-4?
EN 40000-1-2 is about process, how you assess and manage risk across a product’s life. prEN 40000-1-4 is about technical controls, the specific security measures you implement. You need both.
How long do I need to support a product under the CRA?
At least five years, unless the product’s expected use is genuinely shorter. Manufacturers must document how they arrived at their support period.
When will EN 40000-1-2 be published?
There’s no confirmed date yet. It has passed public enquiry and reached Formal Vote (FprEN), the furthest along of any EN 40000-1 document, but CEN’s project record doesn’t show a locked-in publication date. This page will be updated as that changes.
What should I do while the standard is still in draft?
Build your risk assessment process against Article 13 directly, it’s already binding regardless of standard publication timing, and use a tool like SAMMY to document and track that process as you go.
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
Explore CRA compliance in SAMMY
