CRA and the Radio Equipment Directive (EN 18031): mapping synergies for radio equipment manufacturers

Two regulations, one approach: with conditions

Since 1 August 2025, any radio equipment whose intended use includes a connection to the internet or to a network must comply with the cybersecurity requirements of Article 3(3) of the Radio Equipment Directive (RED, 2014/53/EU), as defined by Commission Delegated Regulation (EU) 2022/30 and the harmonised standards EN 18031-1, EN 18031-2 and EN 18031-3. This obligation has been anticipated since 2022, but its entry into application marks a genuine transition: for the first time, a European product regulation imposes cybersecurity requirements on the design of radio equipment for consumer and professional markets.

Simultaneously, Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), entered into force on 10 December 2024, with a first operational deadline on 11 September 2026 (Article 14: vulnerability notification) and full conformity required by 11 December 2027.

The question now facing technical departments and compliance managers at radio equipment manufacturers is straightforward: to what extent can EN 18031 work already completed be leveraged for CRA? The honest answer is: substantially, but not completely. And the gaps are precisely where time is shortest: post-market vulnerability management.

What EN 18031 covers

The three EN 18031 standards cover distinct product scopes:

• EN 18031-1: internet-connected radio equipment, protection against harmful network traffic, protection of network and terminal resources;
• EN 18031-2: radio equipment capable of transmitting personal data, confidentiality and data protection;
• EN 18031-3: radio equipment intended for children or connected toys, authentication and protection adapted for a vulnerable population.

Technically, the EN 18031 requirements address three axes:

• Authentication and access control: prohibition of reusable default credentials, account and role management, protection against brute-force attacks;
• Confidentiality of communications and stored data: encryption of exchanges, protection of sensitive data at rest;
• Protection against harmful network traffic: filtering of malformed frames, resistance to denial-of-service attacks, minimisation of exposed network interfaces.

These requirements are evaluated using a risk profile approach (low, medium or high impact product), structurally compatible with the risk assessment methodology of prEN 40000-1-2. A manufacturer who has completed a rigorous EN 18031 evaluation therefore has a solid foundation: a documented product context, an identification of assets and interfaces, an assessment of relevant threats, and implemented and tested controls.

An important scope note: EN 18031 applies to radio equipment connected to the internet. Products communicating over a proprietary radio frequency (868 MHz, ISM band) without a direct internet connection may be outside the RED/EN 18031 scope, even if they fall under the CRA if their intended use includes a direct or indirect connection to another device. The CRA has a broader scope.

What the CRA adds beyond EN 18031

The fundamental difference between the two regulatory frameworks is not in the technical design requirements. That is where the overlaps are greatest. It is in the ongoing obligations after placing on the market. RED and its harmonised standards are design and testing obligations. The CRA is a lifecycle obligation.

Post-market vulnerability management (Annex I Part II)

Annex I Part II of the CRA requires manufacturers to establish and maintain a vulnerability handling process covering the entire support period of the product. This includes: monitoring known vulnerabilities in third-party components (SBOM / EUVD correlation), patch development, distribution of security updates, and notification of actively exploited vulnerabilities to ENISA within the timelines specified by Article 14 (24 hours for the early warning, 72 hours for the full notification, 14 days for the final report). EN 18031 contains no such requirement. Once a product is placed on the market, RED obligations cease.

Software Bill of Materials (Annex VII §3f)

The list of software components (including third-party dependencies, their version and supplier) must appear in the CRA technical documentation (Annex VII). This inventory is the basis for correlation with vulnerability databases (EUVD, NVD) that allows a manufacturer to determine, within hours, whether a published CVE affects a component present in the product. EN 18031 does not require a SBOM.

Published CVD policy (Annex I Part II, point 1)

The manufacturer must establish and apply a coordinated vulnerability disclosure policy, made public. This policy defines reporting channels, acknowledgement and response timelines, and the disclosure strategy. It must be accessible prior to placing on the market. EN 18031 has no equivalent.

Support period defined and communicated (Article 13(8))

The CRA requires that the support period (the duration during which the manufacturer commits to providing security updates) be defined, justified and communicated to the user before purchase. This information must appear in the user documentation (Annex II). RED contains no equivalent obligation.

Legacy products (Article 14 : retroactive application)

The Article 14 vulnerability notification obligation applies from 11 September 2026 to all products still present on the market, including those placed on the market before the regulation entered into force. EN 18031 obligations, by definition, only applied to products placed on the market from August 2025. The retroactive effect of Article 14 therefore reaches products for which no EN 18031 work was ever performed.

What EN 18031 actually delivers for CRA: a realistic inventory

A properly documented EN 18031 evaluation provides the following for CRA purposes:

• Product context and interface mapping: the product description, communication modes and operational environment documented for EN 18031 is directly reusable as the basis for the product context required by prEN 40000-1-2 (Clause 6.2).
• Asset and threat identification: the EN 18031 risk profile (low / medium / high impact) and the identification of sensitive data and critical functions constitute a valid starting point for the CRA risk assessment, even though the methodology must be formally aligned with prEN 40000-1-2.
• Annex I Part I controls: EN 18031 technical requirements likely cover 40–50% of the CRA essential requirements in Annex I Part I, in particular: secure default configuration (§1b), authentication (§1e), data confidentiality (§1f-g), protection of network interfaces. Controls implemented and tested for EN 18031 can be cited in the CRA technical documentation, provided the mapping is explicitly documented.
• Existing technical documentation: evaluation reports, test descriptions, architecture documentation: all reusable in the CRA technical file (Annex VII).

What is not covered and must be built specifically for CRA: the post-market vulnerability management process, the SBOM, the CVD policy, the definition and communication of the support period, ENISA registration, and the capability to issue a notification within the Article 14 timelines. These are organisational and operational workstreams, not product engineering workstreams, but they take time, and the September 2026 deadline is critical.

The conformity assessment module question

This is where the two frameworks diverge most sharply, with direct financial and calendar implications.

Under the RED Directive, a manufacturer who applies the harmonised standards EN 18031-1, 18031-2 and/or 18031-3 benefits from presumption of conformity with Article 3(3) RED, and can proceed with self-declaration (Module A, internal production control). A notified body is not required for these products.

Under the CRA, the assessment path depends on product classification:

• Standard products: Module 1 (equivalent to Module A): self-declaration available without conditions.
• Important Class I products (Annex III): Module 1 available only if an applicable CRA harmonised standard or common specification exists and is applied (Article 32(2)(a)). Without a harmonised standard: Module B+C or Module H, notified body mandatory.
• Important Class II products (Annex III): Module B+C or Module H, notified body always mandatory.

For manufacturers of connected domestic security products (alarm panels, connected locks, security cameras, access control systems), the relevant Annex III category is Category 17: smart home products with security functionalities, Class I.

The sectoral standard intended for this category is ETSI EN 304 632 (DEN/CYBER-EUS-0014, V0.2.1, February 2026), currently at mature draft stage, submitted for combined Public Enquiry and Vote (ETSI TC CYBER). This standard is not yet harmonised. It is not cited in the Official Journal of the EU. It is harmonisation (citation in the OJEU in response to standardisation request M/606) that opens the presumption of conformity and makes Module 1 available for Class I products.

Until EN 304 632 is harmonised, manufacturers of Class I products in Category 17 cannot rely on a CRA harmonised standard for conformity assessment. They must therefore, under the current normative landscape, plan for Module B+C: a notified body audit. Indicative costs: €15,000–50,000 depending on product complexity. Timeline: 6–12 months depending on notified body availability. The extent to which horizontal standards (prEN 40000-1-2, EN 40000-1-3) may serve as partial substitutes remains subject to ongoing interpretive debate.

The practical consequence is twofold. On one hand, EN 18031 work (which covers RED requirements via harmonised RED standards) does not automatically confer CRA presumption of conformity for the corresponding requirements. The two presumption systems are distinct. On the other hand, the risk window is real: if EN 304 632 is not harmonised before mid-2027, manufacturers of Class I Category 17 products will need to engage a notified body for December 2027, without having anticipated this cost if planning was based on a Module 1 scenario.

Practical sequencing for a manufacturer already engaged on EN 18031

If your organisation has already completed (or is in the process of completing) EN 18031 evaluation for RED compliance, the following sequence is recommended to extend this work to the CRA:

1. Finalise EN 18031 for RED compliance (if not yet done, as required since August 2025 for internet-connected products). This remains independent of the CRA and cannot be deferred.
2. Extend the risk analysis to the CRA Annex I scope: reuse the EN 18031 product context as input for the prEN 40000-1-2 process: formally document the mapping so the CRA technical file can invoke EN 18031 results.
3. Map the CRA Annex I requirements not covered by EN 18031: generate a correspondence matrix (EN 18031 vs. CRA Annex I), identify technical gaps to address.
4. Build the CRA-specific workstreams in priority order against the upcoming deadline: SBOM (Q3 2026 for products covered by Article 14), published CVD policy (before September 2026), operational internal vulnerability handling procedure (before September 2026), ENISA registration (before September 2026).
5. Monitor EN 304 632 harmonisation status: check NANDO and the OJEU regularly. If the standard is not harmonised by end of 2026, initiate early contact with the notified body that conducted your RED audits: it will likely be designated as a CRA notified body, and an existing relationship facilitates scheduling.
6. Plan the conformity assessment module as a dual scenario: budget and schedule for Module 1 if EN 304 632 is harmonised in time, and an alternative budget and schedule for Module B+C if it is not. Do not wait until 2027 to decide: the decision must be made at the latest by end of 2026 to allow time to select and engage a notified body.

The three organisational changes most manufacturers have not yet started

Among the CRA's post-market obligations, three organisational changes are systematically underestimated by manufacturers beginning their compliance process, particularly those who believe most of the work is done once EN 18031 conformity is achieved.

1. Recurring surveillance testing, not just project-linked testing. Manufacturers are accustomed to qualifying their products at the point of placing on the market and following modifications: they have procedures for this, teams, external laboratories. What the CRA introduces as a structural novelty is the requirement for recurring surveillance testing throughout the product's life, not only in project mode. This requires reorganising qualification teams and acquiring or outsourcing cybersecurity expertise (pentests, security reviews) on a recurring basis, not an ad-hoc one. For a manufacturer whose organisation is entirely project-driven around market launches, this is a change in operational model.

2. A formally designated PSIRT function. The capacity to notify an actively exploited vulnerability within 24 hours requires an operational PSIRT (Product Security Incident Response Team) function. In an SME, this function does not require a dedicated team: a single person can be sufficient depending on the organisation's size. But it must exist formally: designated by an operational note, with defined responsibilities: receiving reports, assessing severity, coordinating with R&D teams, and managing the notification procedure to ENISA and ANSSI when required. Given the 24-hour Article 14 deadline, an on-call arrangement must be defined for critical reports received outside business hours. This is the most immediately constraining organisational change for SMEs starting from scratch.

3. Securing the production chain. Handling a vulnerability is security-sensitive information: the need-to-know principle applies. In addition, the process of transmitting new firmware versions from R&D teams to the production chain must be secured and documented. Most manufacturers have production processes covered by ISO 9001, but without the necessary cybersecurity layer. The objective is to add this dimension (without necessarily going as far as ISO 27001), by documenting, auditing and securing this specific process from a cybersecurity standpoint. This is a requirement that few manufacturers have anticipated, and one that early CRA inspections will likely expose as a frequent weak link.

Conclusion

EN 18031 work does not need to be replicated for the CRA: it needs to be extended. Secure design, authentication controls, communication protection: all of this is reusable. But the EN 18031 compliance architecture stops at placing on the market. The CRA starts where it ends.

The priority workstream (and probably the one most disconnected from technical department practice) is post-market vulnerability management. Not a design requirement. An operational, continuous requirement, with legally binding timelines from 11 September 2026. For a manufacturer with products still on the market, that deadline is now less than six months away.