EU Cyber Resilience Act Harmonised Standards Guide: EN 40000 Series, Vertical Product Standards and Presumption of Conformity

The Cyber Resilience Act tells manufacturers what security outcomes their products must achieve, but it is the harmonised standards being written under standardisation request M/606 that will tell them how to prove it. Those standards decide whether a product can rely on the cheaper self-assessment route, which evidence a market surveillance authority will expect, and how much engineering work sits behind each essential requirement in Annex I. As at November 2026 none of them had been cited in the Official Journal, while the main CRA obligations still apply from 11 December 2027. This guide explains how presumption of conformity works under Article 27, what the horizontal EN 40000 series and the vertical product standards cover, which parts are expected first, and how product security teams should plan around drafts that are still moving. It is written for product security leads, compliance owners and engineering managers at manufacturers of hardware and software sold in the EU.

Source note: legal provisions are from Regulation (EU) 2024/2847 on EUR-Lex; standards status is from the European Commission CRA standardisation page, CEN-CENELEC, DKE and secondary reporting as checked on 11 November 2026. Drafts and proposed dates are not law. Confirm against the official text before relying on it.

Key takeaways

• Presumption of conformity only starts at citation. A product that meets a harmonised standard is presumed to meet the Annex I requirements the standard covers, but only once the standard's reference is published in the Official Journal; a draft or a ratified EN alone does not give that presumption.
• M/606 asks for 41 standards in two families. Horizontal standards (EN 40000-1-x) cover principles, generic security requirements and vulnerability handling for every product; vertical standards cover specific Annex III and IV product categories such as browsers, password managers, firewalls and operating systems.
• Vulnerability handling is the part to watch first. prEN 40000-1-3 maps to Annex I Part II and is the horizontal part expected to be cited first, while the generic technical controls in EN 40000-1-4 are on a longer track into 2027.
• Class I products depend on the standards most. Under Article 32(2), important class I products can only use internal control if harmonised standards, common specifications or a suitable certification scheme exist and are applied in full; otherwise a notified body is required.
• Build to the drafts now, with a fallback. Teams that map their secure development and vulnerability processes to the EN 40000 drafts and IEC 62443 today, and keep a notified body option open, are not exposed if citations slip.

How presumption of conformity works under the CRA

Regulation (EU) 2024/2847 sets essential cybersecurity requirements in Annex I: Part I covers the properties of the product, and Part II covers the manufacturer's vulnerability handling processes. Article 27 then gives manufacturers three ways to obtain a legal presumption that they meet those requirements, without arguing every requirement from first principles.

Two practical consequences follow. First, partial application is allowed, but the presumption shrinks to the parts applied, and for a class I product partial application sends the uncovered requirements back to a notified body. Second, Member States can formally object to a common specification under Article 27(7), so even the fallback route carries some uncertainty. The EUCC scheme is the main certification route available today for ICT products. See the EU Cybersecurity Certification EUCC Guide.

The M/606 standardisation request and timeline

The Commission issued standardisation request M/606 to CEN, CENELEC and ETSI by Commission Implementing Decision C(2025) 618 of 3 February 2025. The three organisations accepted it on 3 April 2025 and committed to deliver at least a year before the CRA applies. The Commission's CRA standardisation page describes "a set of 41 standards", prioritising the important and critical categories in Annexes III and IV, plus supporting work on terminology, sector risk assessment methodology and a common threat catalogue.

The dates for standards are moving targets. Treat the revised delivery dates as proposals until the amending decision is published, and check the Commission page and the Official Journal before relying on any citation.

The horizontal EN 40000 series

The horizontal standards are developed in CEN-CLC/JTC 13 (working groups 9 and 6). They build on the EN 18031 series originally written for the Radio Equipment Directive delegated act, and extend that approach to the much wider CRA scope. See the EU Radio Equipment Directive Cybersecurity Guide.

What prEN 40000-1-3 asks for

Public summaries of the draft describe a process standard that turns Annex I Part II into auditable activities. The draft content reported so far includes:

• Disclosure policy: a published coordinated vulnerability disclosure policy with intake channels, acknowledgement and validation steps, coordination rules and reporter credit. See the ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide.
• Component inventory: a software bill of materials, and a hardware bill of materials where relevant, kept current for the support period. See the SBOM Guide.
• Continuous review: automated checks of the SBOM against newly published vulnerabilities, with documented review cycles and test results.
• Remediation and updates: risk-based prioritisation, interim mitigations, secure distribution of security updates and advisories to users.
• Reporting readiness: event triage, named roles and records explaining why an event did or did not meet a reporting threshold, which ties directly to the Article 14 duties already in force. See the EU Cyber Resilience Act Vulnerability and Incident Reporting Guide.

These descriptions come from secondary summaries of a draft; read the CEN-CENELEC draft itself through your national standards body before building audit criteria on any single clause.

Vertical product standards

Vertical standards cover the product categories listed as important (Annex III) or critical (Annex IV). They are meant to be used with the horizontal parts, adding the threats, security functions and test methods that matter for one product type. ETSI delivers most of them through a dedicated group in ETSI TC CYBER; CENELEC TC 65X delivers the operational technology variants as the EN 50770 series, built on IEC 62443; CEN/TC 224 and CLC/TC 47X also take part, covering identity devices, secure elements and semiconductors.

Item numbers and standard numbers follow the German national committee's project list dated October 2026; the smart meter gateway item (40) had no standard number assigned. Where both an ETSI and an EN 50770 standard exist for the same category, the split is broadly by market: the EN 50770 parts serve industrial and OT products already built to IEC 62443, with amendments to IEC 62443-4-1, 4-2 and 3-3 in preparation to support them. See the IEC 62443-4-1 and 4-2 Secure Product Development Guide.

Which route fits which product class

The standards matter most where Article 32 makes self-assessment conditional. The table summarises how the standards interact with each class; the full classification rules are in the EU CRA Product Classes Guide.

Small and large manufacturers

• Small manufacturers and microenterprises: buy the draft through the national standards body, apply it to one product line first and record gaps; the cost of a notified body for a class I product without a cited standard is the main budget risk.
• Large portfolios: run one horizontal programme (risk assessment, SBOM, vulnerability handling) across all products, then add vertical deltas per category; participate in national mirror committees so changes are seen before publication.
• Open source stewards: are not subject to conformity assessment but benefit from aligning their vulnerability handling with EN 40000-1-3 because integrating manufacturers will ask for it. See the EU CRA Obligations for Software Developers and Open Source Stewards Guide.

How to plan around standards that are still drafts

1. Classify every product. Record whether each product with digital elements is default, class I, class II or critical, and which M/606 item and vertical standard number apply.
2. Obtain the drafts. Acquire prEN 40000-1-2, -1-3 and the relevant vertical draft through your national standards body or enquiry process, and note the version and date of each.
3. Gap-assess processes first. Compare your secure development lifecycle and vulnerability handling against EN 40000-1-2 and prEN 40000-1-3; these change least by product and are needed for Article 14 reporting already.
4. Gap-assess the product. Map each Annex I Part I(2) requirement to the controls in the vertical draft (and to EN 40000-1-4 once available), with test evidence per requirement.
5. Pilot one product end to end. Build a complete technical file for one product against the drafts, including the risk assessment, SBOM and test reports, and have it reviewed internally as if by a market surveillance authority.
6. Set citation triggers. Watch the Official Journal and the Commission page; when a reference is cited, re-run the gap assessment against the cited version, because cited versions can differ from drafts and citations can carry restrictions.
7. Keep a rollback route. For class I products, keep a notified body quotation and module B+C plan ready, so a late or restricted citation does not block placing the product on the market after 11 December 2027.

Where identity fits

Identity products are directly in scope as an Annex III category: identity management systems and privileged access management software and hardware sit under M/606 item 16 (EN 40000-10), and password managers (EN 304 618) and PKI software (EN 304 624) have their own vertical standards. Beyond those categories, the Annex I requirements on protection from unauthorised access, authentication and secure default configuration apply to every connected product, which puts default credentials, device identities, update signing keys and service accounts used by management interfaces inside the evidence a manufacturer must produce. Treat signing keys for security updates as production secrets with a named owner and rotation plan. See the IoT Security Guide and the Product Security Laws Map.

Measuring readiness

• Classification coverage: percentage of products with a recorded class, M/606 item and target standard.
• Draft gap closure: open gaps against prEN 40000-1-3 and the relevant vertical draft, tracked per product, trending down each quarter.
• SBOM currency: share of shipped versions with a current SBOM checked against new vulnerability data in the last 7 days.
• Vulnerability handling time: median time from report receipt to acknowledgement and to fix release, per product line.
• Fallback readiness: share of class I products with a notified body plan in place while no standard is cited.

Framework mapping

Common failure patterns

• Treating ratification as citation: claiming presumption of conformity because an EN has been published, when its reference is not yet in the Official Journal.
• Waiting for the final text: starting work only after citation, leaving less than a year before 11 December 2027 to change development processes that take longer than that.
• Applying the vertical standard alone: testing product features against the vertical draft but ignoring the horizontal vulnerability handling and risk assessment processes it assumes.
• Self-assessing class I on a partial standard: applying only some clauses and still planning module A, when Article 32(2) sends uncovered requirements to a notified body.
• Losing track of versions: technical files that cite "EN 40000" without part number, version or date, so evidence cannot be re-checked when the cited version differs from the draft.

Practitioner checklist

• Record class, M/606 item and target standard numbers for every product with digital elements.
• Obtain the current drafts of EN 40000-1-2, prEN 40000-1-3 and the relevant vertical standard, with version and date.
• Gap-assess vulnerability handling against prEN 40000-1-3 first, since Article 14 reporting already applies.
• Keep an SBOM per shipped version and check it against new vulnerability data automatically.
• Map each Annex I Part I(2) requirement to a control and a test result per product.
• Hold a notified body fallback plan for every class I product until a standard is cited.
• Monitor the Official Journal and the Commission CRA standardisation page monthly and log changes.
• Protect update signing keys and device credentials as production secrets with named owners.

Standards and references

• EUR-Lex: Regulation (EU) 2024/2847, the Cyber Resilience Act
• European Commission: Cyber Resilience Act standardisation
• CEN-CENELEC: CRA standardisation request officially accepted by CEN, CENELEC and ETSI
• CEN-CENELEC: CRA Unlocked webinar part 2, standards for the CRA (slides)
• DKE: Standardisation projects for the CRA (project list, October 2026)
• EVS: prEN 40000-1-2 Principles for cyber resilience
• IBF Solutions: Current status of standardisation for the Cyber Resilience Act
• CyberResilienceAct.eu: CRA standardisation deadlines pushed back two months

This guide summarises the status of harmonised standards under the EU Cyber Resilience Act as checked on 11 November 2026 and is not legal advice. Related NHI Mgmt Group resources: EU Cyber Resilience Act Guide · EU CRA Product Classes Guide · EU Cyber Resilience Act Vulnerability and Incident Reporting Guide · IEC 62443 Guide · Product Security Laws Map