EU issues CRA guidance (Part 1 – Draft Standards)
Official guidance and standards are beginning to appear in relation to the CRA. In some of the emerging information, ambiguities are clarified. In others, important changes in emphasis are detectable, meaning that interpretation of the CRA will shift a little.
As well as standards under development, many of which will be published later this year (see below), the EU has published an FAQ and also detailed draft guidance on CRA compliance. Plus there’s another weighty guidance document from ENISA called “Security by Design and Default Playbook”. I intend to assess the significance and usefulness of these publications. As ever, for me it’s all about distilling the practical implications for embedded, OT and IoT development.
In this note, I plan to start by looking a little more closely at the picture of emerging standards.
Harmonized Standards
The idea of a “harmonized standard” is that by adhering to it, you could benefit from a “presumption of conformity” to the corresponding regulation. Unfortunately, for the CRA, the simplicity of this approach is complicated by the development of multiple standards. At the same time, it’s been made clear that for the self-certification route permitted for “default” products, the “presumption of conformity” approach is not mandatory.
Three main “horizontal” standards are in development with publication dates announced (a fourth standard defines the language). Additionally a slew of product-category-specific vertical standards are also in the works.
The three horizontal standards address lines 1-15 of the EU’s request to Standards Organizations, which in turn are based on the CRA’s Annex I Part I, and can be summarized as below. Even though in some cases draft versions of the standards have been published, and may be found online, it is important to not get lost in the detail of these documents as a lot can change between draft and public standard.
- EN 40000-1-2 (Horizontal Standard: Cybersecurity Principles – CRA Annex I Part I(1)) Designing, developing and producing products with digital elements in such a way that they ensure an appropriate level of cybersecurity based on the risks (Publication date: 30/8/26). It was originally thought that this “process” standard would be tightly focused on the CRA’s principle of “Secure by Design” and prescribe a Secure SDLC along the lines of IEC 62443-4-1, ISO/SAE 21434, or NIST SSDF. However, while high level secure development principles are included, there is no detailed prescription, and this standard will focus equally on the cybersecurity risk assessment driven approach and other elements of the secure lifecycle. This is good news for manufacturers.
- EN 40000-1-4 (Essential Generic Security Requirements for PDEs – CRA Annex I PartI(2) (b)to(m)) Essential cybersecurity requirements relating to the properties of products with digital elements as set out in Part I of Annex I (Publication officially 31/10/27, but probably much earlier in 2027). A “product” standard. Part 1 of Annex 1 lists product requirements, which are in some ways the most difficult to standardize as they can rely on the attributes of specific hardware. Therefore it’s unfortunate that this standard will be published behind its siblings. In practice, other harmonized standards such as EN 18031:2024 may be substituted with some gap analysis and mitigation.
- EN 40000-1-3 (Vulnerability Handling – CRA Annex I Part I(2)(a)) Vulnerability handling for products with digital elements (Publication 30/8/26). Another “process” standard which will helpfully codify one of the most tricky topics, required for compliance in all PDEs. Some level of presumption of conformity in relation to this special topic is anticipated.
As mentioned, a Harmonized Standard is one which, once formally adopted by the EU may potentially be used as the basis of a “presumption of conformity” when claiming compliance with a particular regulation. Horizontal standards often come with a disclaimer saying that there can be no such presumption, or only a partial presumption based on that standard alone . Usually, a vertical standard is required as the basis for the presumption of conformity approach. In any case, a product-specific risk-driven approach will be needed to navigate compliance.
What about Vertical Standards?
The CRA defines Critical, Important(I) and Important(II) products, with the rest falling into the “default” category. The initial vertical standards aligned to the EU’s request are focused on the critical and important product verticals and so don’t help the rest of us in the broad industrial OT/IoT market, known as the “default” category. Vertical Standards are required to permit the manufacturers of those product categories a presumption of compliance. For default-category devices where compliance with a harmonized standard is not strictly required, CEN / CENELEC is engaged in a rework of part of the IEC 62443 standard for Industrial Automation Control Systems (IACS) as a way to fill this gap.
EN IEC 62443-4-2:2019/A11:2026, to be published in October 2026 is a major EU rework of the original IEC 62443 standard especially to render it suitable for a presumption of conformity for CRA in the default class. This standard will therefore potentially be a go-to for CRA compliance because it’s a “vertical” product specific standard. Of course, it’s not really product-specific at all as there is no such thing as a “default device”, just lots of devices that don’t fit the “important” and “critical” categories. This means there will be a potentially awkward intersection with the horizontal standard EN 40000-1-4, but the earlier publication date of the 62443/A11 standard means that in practice that is likely find use for establishing CRA compliance. This is slightly confusing, but it’s worth restating that unlike the Critical and Important products, adoption of a harmonized standard is voluntary.
The How, What and Why of Compliance
Standards can provide detailed guidance to conformity… the “How?” of compliance. But in the case of CRA these standards will not provide the “What?” or the “Why?” – not for default products anyway. The cybersecurity risk assessment is the key – it will inform you as to which cybersecurity requirements apply to your PDE and make sure you understand and can demonstrate Why that is, and What controls are required. If you’re designing a new product this will enable you to make key decisions sooner rather than later. Later in 2026 when standards are published, as long as your products have the fundamental attributes required to be secure, according to your risk assessment, then the technical documentation to claim conformity can be generated under the guidance of those standards.
In coming articles I plan to cover the “Risk Assessment Driven Approach”, and also the other EU guidance which has been recently published, which is helpful in this task.
Next Post: Commission Guidance of July ’26
