How far EN 303 645, EN 18031 and IEC 62443-4-2 each carry you, and what is still missing — a gap analysis from the laboratory’s point of view
The CRA (Cyber Resilience Act, Regulation (EU) 2024/2847) becomes fully applicable on 11 December 2027. The ideal preparation route is to wait for the corresponding harmonised standards, build to them, and obtain presumption of conformity — but the real timetable does not allow that kind of waiting.
The harmonised standards family matched to the CRA is the prEN 40000 series (1-1 vocabulary, 1-2 principles for cyber resilience, 1-3 vulnerability handling, 1-4 generic security requirements). As things stand, not one part of that series has been formally published in the Official Journal of the European Union (OJEU), so none of them yet confers presumption of conformity. The furthest along, 1-1 and 1-2, have reached final draft and formal vote; 1-3 is finishing its vote; and 1-4, the part most directly connected to product technical requirements, is the slowest in development — publicly available standardisation work item information puts its delivery at around the end of 2027.
Even on an optimistic estimate, there is still a gap between “the standard is delivered” and “it is published in the Official Journal and confers presumption of conformity”. Add the two together and what is left before full application on 11 December 2027 is often a matter of weeks. Put another way: if you wait for EN 40000-1-4 to appear before starting work, there is almost no chance of getting design changes, re-testing and the technical documentation done in time. Even so, there is plenty you can move forward with now.
The first and most fundamental reason: the legal obligation comes from the CRA itself, not from a standard. What manufacturers have to meet are the essential cybersecurity requirements in Annex I; the role of a harmonised standard is only to offer a shortcut for demonstrating that you meet them — under CRA Article 27, conformity with a harmonised standard already published in the Official Journal gives rise to a presumption of conformity with the corresponding requirements. If the standard is not published, the obligation is not deferred, and nothing stops a manufacturer from building its technical documentation against the Annex I provisions today.
Second, according to the direction the standardisation bodies have signalled, 1-4 is being built out on the basis of the EN 18031:2024 series. That means preparation work starting from EN 18031 carries over to a considerable degree and will not be written off wholesale once the standard is finalised.
Third, the technical controls in the existing standards are conceptually very close to Annex I. Access control, authentication, encryption, secure updates, logging — for controls like these the existing product security standards already offer mature practice and testing experience that can be carried across directly.
Apart from the official mapping annexes published with the EN 18031 series, the gap assessments below — comparing EN 303 645 and IEC 62443-4-2 against the CRA — have no officially published clause-by-clause mapping behind them; they are the professional judgement of technical experts working from the public information available. Their value lies in helping you decide where to invest first, not in replacing a formal conformity assessment.
| Standard | Product types it applies to | Current status |
|---|---|---|
| EN 303 645 (ETSI) | Consumer IoT products: smart home devices, wearables, connected toys and the like | An effective baseline security standard for consumer IoT |
| EN 18031 series (-1 / -2 / -3) | Connected products falling within the scope of the Radio Equipment Directive (RED, Directive 2014/53/EU) | Cited as RED harmonised standards in January 2025, conferring presumption of conformity (subject to restrictions) |
| IEC 62443-4-2 | Products and components associated with industrial automation and control systems | An international standard, widely adopted in industrial control |
The choosing principle: pick one as a starting point according to your product’s primary application domain; you do not need to apply all three. Only where a product spans several domains (an industrial connected gateway, for example) do you need to combine the technical requirements of more than one standard.
Of the three, this is the one furthest from the CRA — not because of the quality of the standard, but because it was always positioned as a baseline, with less technical depth than EN 18031.
| CRA requirement area | Current position | What needs strengthening |
|---|---|---|
| Known vulnerability management | Mentioned only in principle; no product-level requirement | Establish pre-shipment vulnerability scanning and CVE matching |
| Data and communications integrity | Partial gap | Strengthen communications integrity verification |
| Logging and monitoring | No corresponding mechanism at all | Build logging from scratch: persistent storage, a minimum set of events, timestamps, and a user opt-out |
| Network behaviour control | No correspondence at all | Add protection and monitoring for anomalous network traffic |
| Attack surface documentation | Partial gap | Complete formal documentation of exposed interfaces and services |
| Part II vulnerability handling obligations | Only the concept of a disclosure policy in principle; no concrete process requirements | The largest gap, to be built from scratch: SBOM generation, a vulnerability reporting contact point, a regular testing schedule, a security advisory publication process |
Our advice: consumer product manufacturers currently working only to EN 303 645 should put resources first into logging mechanisms and the full vulnerability handling process (SBOM plus a coordinated disclosure policy). These are the two areas furthest from the CRA today — and the most time-consuming to build.
Of the three, this is conceptually closest to the CRA’s technical controls. According to the direction the standardisation bodies have signalled, the planned prEN 40000-1-4 is being built out precisely on the basis of the EN 18031:2024 series; at the same time, the RED cybersecurity delegated regulation (Delegated Regulation (EU) 2022/30) has been confirmed as repealed with effect from 11 December 2027, with the CRA taking over. If a product has already been through RED compliance under EN 18031, this is the base most worth extending first.
| CRA requirement area | Current position | What needs strengthening |
|---|---|---|
| Access control, authentication, encryption, secure updates, secure storage and communication | Well covered, with complete mechanisms already in place | Relatively light — mainly confirming mechanism versions and which sub-standards apply |
| A systematic risk assessment process | Implicit only in the applicability decisions for each mechanism; no independent, systematic risk assessment documentation framework | Establish formal risk assessment and risk treatment documentation: product context analysis, risk acceptance criteria, risk evaluation, risk communication and monitoring |
| Product lifecycle governance | More focused on the technical control points themselves | Build governance documentation covering the full lifecycle: planning, requirements, architectural design, implementation, verification, production and distribution, decommissioning |
| Part II vulnerability handling obligations (8 items) | Not covered at all; the RED framework requires neither an SBOM nor a vulnerability handling process | As with EN 303 645, the full vulnerability handling process and the SBOM have to be built from scratch |
| Restrictions on presumption of conformity | EN 18031 itself carries a number of restrictions under the RED, and the restricted parts cannot be fully self-declared | Revisit those restricted items on the transition to the CRA to see whether third-party Notified Body verification is still required |
Our advice: for RED product manufacturers moving across to the CRA, the technical control burden is the lightest, and existing EN 18031 testing and documentation experience carries over directly. The focus of investment should be the two genuinely new governance requirements: establishing a formal risk assessment framework, and building Part II vulnerability handling capability.
The technical controls for industrial settings are strong. The gaps are concentrated in two areas — vulnerability management and user communication — plus one area industrial manufacturers have had little contact with in the past: compliance documentation aimed at the end market.
| CRA requirement area | Current position | What needs strengthening |
|---|---|---|
| Access control, data integrity, communications security, logging | Good coverage; the technical controls map across fully | Relatively light |
| Known vulnerability management | No corresponding requirement; the standard does not cover the concept | Establish a pre-shipment known-vulnerability review (CVE matching, vulnerability scanning) |
| User notification and opt-out mechanisms | No corresponding requirement | Add user notification functionality and the associated documentation |
| Exploitation mitigation | No clear correspondence | Strengthen the design and documentation of mitigations such as defence in depth and privilege separation |
| Part II vulnerability handling obligations | Not covered by the standard itself (the closest process concepts belong to IEC 62443-4-1) | Work through CRA Part II item by item to fill in the SBOM, the CVD policy, the vulnerability reporting contact point and the rest |
| Consumer / market compliance documentation | Entirely absent; B2B settings generally have no equivalent of CE marking or an EU declaration of conformity | Build the EU declaration of conformity, the CE marking process, and the information the instructions for use must carry (such as the end of the support period) |
Our advice: as well as strengthening vulnerability management and user notification on the technical side, industrial product manufacturers should pay particular attention to market compliance documentation. Industrial control systems have historically focused on technical verification, and end-market compliance activity such as CE marking and the EU declaration of conformity is unfamiliar ground. This part should be built into the compliance schedule early, because it involves processes and people rather than a design change.
Whichever standard you start from, neither of the following can be carried over directly from an existing base; we suggest treating both as first priorities:
The second item needs a further word of explanation: the existing standards largely focus on the technical quality of the product as it leaves the factory, whereas the CRA extends the requirements past the point of sale — to whether you have the capacity to maintain the product on an ongoing basis. That is not something one document or one round of testing can settle; it means building a standing organisational capability, which is why it is also the item that should least be left until last.
What gets overlooked in discussions of “preparing early” is that the CRA’s obligations do not all fall at the end of 2027. The manufacturer reporting obligations in Article 14 have applied since 11 September 2026: actively exploited vulnerabilities require an early warning within 24 hours and a notification within 72 hours, with a final report once a fix is available. And this obligation applies to every product already on the market that falls within CRA scope — not only to products launched after 2027.
Answering “is our product affected by this vulnerability?” within 24 hours depends precisely on the SBOM and the component inventory — that is, on the Part II item that is the “largest shared gap”. In other words, the real deadline for this preparation is not December 2027; it is now.
Two further practical points are worth confirming at the same time. Registering on ENISA’s single reporting platform requires the manufacturer’s designated representative to obtain an EU Login account and enable multi-factor authentication first, so it is worth securing early. And the statutory reporting deadlines will not be relaxed because of platform problems, so confirm the contact point for your Member State’s CSIRT and have a manual fallback reporting process ready.
This article gives a general gap map. Applied to an individual case, it still comes down to which standard the product actually follows, which mechanisms the existing test reports cover, and how complete the risk assessment and technical documentation are today — those three things determine how long the gap list really is.
If you would like to confirm where your product currently sits in compliance terms, take stock of the gap list for the transition to the CRA, or need a professional second opinion on whether existing test reports and technical documentation can be carried over, do get in touch: consultants and laboratory engineers from SV Surveillance and Applus+ Laboratories can help assess your individual case.
You are also welcome to join the in-person seminar in Taipei on Friday 18 September, where you can put questions directly to a CRA expert from Spain and learn more about planning for 2027 compliance and estimating the time and cost of implementation. Registration: Register for the seminar
Q: Can I wait for EN 40000-1-4 and still be in time? The timing is very tight and the risk is high. On the public information available, prEN 40000-1-4 (generic security requirements) is behind 1-1, 1-2 and 1-3 in development, with delivery estimated around the end of 2027 — and delivery is not the same as publication in the Official Journal and presumption of conformity. Starting work only once the standard is settled usually leaves too little time to complete design changes, re-testing and the technical documentation. The pragmatic approach is to start now against the existing standards and the Annex I provisions.
Q: We have already done EN 18031 (RED) compliance — can that be used directly for the CRA? The technical controls carry over substantially. According to the direction the standardisation bodies have signalled, prEN 40000-1-4 builds on the EN 18031:2024 series, so mechanisms and testing experience for access control, authentication, secure updates and the like can all be reused. But two areas have to be built new: a systematic risk assessment documentation framework, and the eight Annex I Part II vulnerability handling obligations — the RED framework requires neither an SBOM nor a vulnerability handling process.
Q: Where are the gaps between EN 303 645 and the CRA? Mainly in two places: logging and monitoring (EN 303 645 has no corresponding requirement at all, so it has to be built from scratch) and the full Part II vulnerability handling process (only the concept of a disclosure policy in principle). Beyond those, known vulnerability management, communications integrity, network behaviour control and attack surface documentation all show gaps of varying size.
Q: For industrial products built to IEC 62443-4-2, what is most easily missed in the transition to the CRA? Compliance documentation aimed at the end market. Industrial B2B settings generally have no concept of CE marking, an EU declaration of conformity or the information the instructions for use must carry (such as the end of the support period) — and the CRA requires all of them. On the technical side, the clearest gaps are known vulnerability management and user notification / opt-out mechanisms.
Q: If I can only do one thing first, what should it be? Establish SBOM generation and a vulnerability reporting contact point. These two are the gaps common to all three existing standards, they are core Annex I Part II requirements, and they are what the Article 14 reporting obligations in force since 11 September 2026 depend on — and they will not be written off by however the EN 40000 series is finally drafted.
The legal provisions, standard statuses and dates cited in this article are based on the following documents:
By the Secure Vectors Surveillance Inc. (SV Surveillance) × Applus+ Laboratories consulting team
* This article is commentary on regulation and standards, not legal advice. Apart from the official mapping annexes published with the EN 18031 series, the gap assessments between EN 303 645, IEC 62443-4-2 and the CRA have no officially published clause-by-clause mapping behind them; they are the professional judgement and recommendations of technical consultants working from the public information available, and are not an officially guaranteed route to compliance. The prEN 40000 series remains at draft stage at the time of writing, and both its content and its timetable may change before formal publication. The final compliance determination in an individual case should be based on the text of the CRA and on the interpretations of the competent authorities.
