CRA, RED DA and EN 18031: A Practical Readiness Guide for Electronics Manufacturers

Connected electronics placed on the European Union market are entering a new cybersecurity compliance cycle. The Radio Equipment Directive Delegated Act (RED DA) already applies to specified radio equipment, while the Cyber Resilience Act (CRA) introduces broader requirements for products with digital elements and their manufacturers.

For an electronics manufacturer, readiness is not a last-minute certification exercise. It is the ability to show, with controlled evidence, that cybersecurity risks were addressed from product planning through design, production, delivery and post-market support.

This guide explains how the CRA, RED DA and EN 18031 fit together, what changes on 11 December 2027, and what OEM and EMS teams should implement now.

Last reviewed: 9 September 2026

The regulatory map

The CRA and RED DA are related, but they are not interchangeable.

• CRA means Regulation (EU) 2024/2847, the Cyber Resilience Act. It establishes horizontal cybersecurity requirements for hardware and software products with digital elements.
• RED means Directive 2014/53/EU on radio equipment.
• RED DA commonly refers to Commission Delegated Regulation (EU) 2022/30. It activated the cybersecurity-related essential requirements in RED Article 3(3)(d), (e) and (f) for specified categories of radio equipment.
• EN 18031-1, EN 18031-2 and EN 18031-3 are harmonised standards supporting those RED cybersecurity requirements. They are not CRA harmonised standards.

Key dates

The repeal does not erase the RED DA period. Market surveillance under RED can still examine radio equipment placed on the EU market between 1 August 2025 and 10 December 2027 against the cybersecurity requirements applicable at that time.

Products placed on the market before 11 December 2027 are generally subject to the main CRA product requirements only if they undergo a substantial modification from that date. CRA Article 14 reporting is different: it also applies to products in scope that were placed on the market before 11 December 2027.

Which products may be in scope?

CRA scope starts with the product and its connection

The CRA covers software or hardware products with digital elements, including separately marketed software or hardware components and certain remote data processing solutions. Its scope applies where the intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, and the product is made available on the EU market in the course of a commercial activity.

This can include:

• connected controllers, gateways and telemetry devices;
• networked industrial equipment and embedded systems;
• desktop, mobile and cloud-connected software products;
• separately marketed firmware, libraries and hardware components;
• a backend service designed by or under the responsibility of the manufacturer when the product cannot perform one of its functions without that service.

A radio interface is not required for CRA scope. Ethernet, USB, a service interface, fieldbus connectivity or an indirect connection through another system can be relevant. Conversely, the presence of a microcontroller alone does not settle the scope question. The complete product, intended purpose, reasonably foreseeable use, connection and commercial placing on the market must be assessed.

The CRA also contains exclusions and special rules for areas already governed by sectoral legislation. Medical devices under Regulations (EU) 2017/745 and 2017/746, certain motor-vehicle and aviation products, marine equipment, and products developed exclusively for national security or defence require a separate legal analysis rather than an assumption that the CRA applies in full.

RED DA scope is narrower and category-based

Until its repeal takes effect, RED DA applies only to radio equipment covered by the categories in Regulation (EU) 2022/30:

• RED Article 3(3)(d): network protection applies to internet-connected radio equipment;
• RED Article 3(3)(e): personal data and privacy applies to internet-connected radio equipment that processes relevant data, and to specified childcare, toy and wearable radio equipment that processes such data;
• RED Article 3(3)(f): fraud protection applies to internet-connected radio equipment that enables transfers of money, monetary value or virtual currency.

The exclusions in Regulation (EU) 2022/30 must also be checked. For example, radio equipment governed by the Medical Devices Regulation or the In Vitro Diagnostic Medical Devices Regulation is excluded from all three activated requirements. Other sectoral exclusions are limited to particular requirements.

Classify the CRA product after confirming scope

Most in-scope products follow the default CRA conformity route. A product is an important product with digital elements only if its core functionality falls within a category in CRA Annex III. Annex III divides important products into Class I and Class II. CRA Annex IV separately lists critical products with digital elements.

Do not classify a complete industrial device as important or critical merely because it contains a listed component. Article 7 states that integrating a listed product does not by itself transfer that classification to the containing product. The core functionality and the applicable legal definitions must be documented.

What CRA readiness means in practice

CRA readiness is a controlled product lifecycle, not a folder created before an audit.

1. A documented cybersecurity risk assessment

The manufacturer must assess cybersecurity risks and use the result throughout planning, design, development, production, delivery and maintenance. The assessment should identify at least:

• intended purpose and reasonably foreseeable use or misuse;
• operational environment and external interfaces;
• assets requiring protection, including credentials, personal data, configuration, firmware and service availability;
• threat scenarios and security assumptions;
• applicable and non-applicable CRA Annex I requirements, with justification;
• selected controls, residual risks and verification evidence.

The assessment is part of the technical documentation and must be updated when relevant information, vulnerabilities or product changes alter the risk picture.

2. Secure-by-design and secure-by-default controls

Depending on the risk assessment, CRA Annex I expects products to address controls such as:

• no known exploitable vulnerabilities when placed on the market;
• secure default configuration and a way to restore a secure original state;
• appropriate authentication and access control;
• confidentiality and integrity of stored, transmitted and processed data;
• data minimisation;
• protection of essential functions and limitation of attack surfaces;
• security logging or monitoring where appropriate;
• secure deletion of user data and settings;
• security updates, with automatic installation enabled by default where applicable and with a clear opt-out mechanism.

The phrase “where applicable” does not remove the need for evidence. If a requirement is considered non-applicable, the technical file should explain why in the context of the product’s risks and intended use.

3. Third-party component control and an SBOM

Manufacturers remain responsible for due diligence when integrating third-party components, including free and open-source software. A useful software bill of materials (SBOM) should be machine-readable, version-controlled and linked to the exact released product configuration.

An SBOM is an input to vulnerability management, not proof of compliance by itself. The operating process also needs to answer:

• Who monitors advisories and vulnerability sources?
• How is a component matched to affected product versions?
• Who assesses exploitability and product impact?
• How are fixes tested, approved and distributed?
• How is evidence retained for each release and support period?

When a manufacturer identifies a vulnerability in an integrated component, CRA Article 13(6) also requires reporting it to the component manufacturer or maintainer and, where appropriate, sharing a developed fix or relevant documentation.

4. Vulnerability handling throughout a declared support period

The support period must reflect expected use, reasonable user expectations, the nature of the product and other factors listed in the CRA. It is generally at least five years, unless the product is expected to be used for less than five years. Longer-lived industrial products may require a longer period.

The end date of the support period, including at least month and year, must be communicated clearly at the time of purchase. Security updates issued during the support period must remain available for at least ten years after issue or for the remainder of the support period, whichever is longer.

5. Incident and actively exploited vulnerability reporting

From 11 September 2026, manufacturers must report through the CRA single reporting platform:

• an actively exploited vulnerability: early warning within 24 hours, follow-up information within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure becomes available;
• a severe incident affecting product security: early warning within 24 hours, incident notification within 72 hours, and a final report within one month after the incident notification.

The clock starts when the manufacturer becomes aware, not when an internal investigation is complete. Contracts with developers, component suppliers, EMS providers and service operators therefore need escalation paths fast enough to protect the manufacturer’s reporting deadline.

RED DA and EN 18031

EN 18031 provides a structured method for assessing the RED cybersecurity requirements during the RED DA transition period:

Harmonised, but with restrictions

Commission Implementing Decision (EU) 2025/138 published the EN 18031 references with restrictions. Three practical points matter:

1. Sections labelled “rationale” and “guidance” do not confer a presumption of conformity. They help interpretation but are not normative specifications.
2. EN 18031-1, -2 and -3 do not confer a presumption of conformity if clauses 6.2.5.1 and 6.2.5.2 are applied in a way that allows the user not to set and use any password.
3. Additional restrictions apply to parental or guardian access control under EN 18031-2 and to the secure-update assessment criteria in clause 6.3.2.4 of EN 18031-3.

Using an EN 18031 checklist without reading the notices published in the Official Journal can therefore create a false compliance conclusion. The product file should identify the exact standard edition, applicable requirement, decision tree, implementation category, test result and any restriction affecting the claimed presumption of conformity.

EN 18031 is useful for CRA preparation, but it is not CRA proof

Many EN 18031 controls are useful engineering inputs for CRA readiness, including access control, authentication, secure updates, protection of assets and network resilience. However, the standards were harmonised for specific RED Article 3(3) requirements. They do not automatically cover the full CRA Annex I lifecycle, vulnerability handling, reporting, support-period, user-information and technical-documentation obligations.

A manufacturer can reuse EN 18031 evidence in a CRA file where it is relevant, but it should maintain a separate traceability matrix showing what the evidence proves and what CRA requirements still need additional controls or records.

Conformity assessment and CE marking

Under RED during the transition

The RED conformity route depends on whether harmonised standards covering all applicable essential requirements have been applied in full. Where relevant harmonised standards are not applied, are only partly applied, do not exist, or do not cover all applicable requirements, the RED requires an assessment route involving EU-type examination followed by conformity to type, or full quality assurance, instead of relying only on internal production control.

Because EN 18031 was published with restrictions, each product must be checked against the exact Official Journal notices. A restriction does not automatically force every product to use a notified body, but it may prevent reliance on presumption of conformity for the affected requirement or implementation choice.

Under the CRA from 11 December 2027

For products in the default category, CRA Article 32 permits internal control (Module A), EU-type examination followed by conformity to type (Modules B+C), full quality assurance (Module H), or an applicable European cybersecurity certification scheme.

The route is stricter for listed products:

• Class I important products can use internal control only when the applicable harmonised standards, common specifications or qualifying certification schemes are fully applied; otherwise Modules B+C or H are required.
• Class II important products require Modules B+C, Module H or an applicable qualifying cybersecurity certification scheme.
• Critical products follow the certification or conformity routes defined by CRA Articles 8 and 32.

The manufacturer must complete the applicable conformity assessment, prepare the technical documentation and EU declaration of conformity, and affix CE marking. A laboratory report or voluntary certificate does not transfer the manufacturer’s legal responsibility and is not a substitute for the prescribed conformity assessment.

OEM and EMS responsibilities

The CRA definition of manufacturer includes a legal or natural person that develops or manufactures a product, or has it designed, developed or manufactured, and markets it under its own name or trademark. Consequently, outsourcing design or production to an EMS partner does not normally transfer the manufacturer’s CRA responsibility from the brand owner.

This allocation should be explicit in the contract and operational interfaces. At minimum, define:

• ownership and delivery format of source code, build records, SBOM and test evidence;
• notification timing for vulnerabilities and incidents, preferably well inside the manufacturer’s 24-hour reporting window;
• authority to approve component substitutions, firmware changes and backend changes;
• secure development, signing-key and production-programming responsibilities;
• patch development, validation, deployment and customer-communication responsibilities;
• records and support to be retained after the commercial project ends.

An EMS provider or another third party can become a manufacturer for CRA purposes if it substantially modifies a product and makes the modified product available on the market. Change control must therefore assess not only technical impact, but also whether a change affects compliance, intended purpose or cybersecurity risk.

The evidence package

A practical evidence package should connect legal requirements to product decisions and reproducible records. It commonly includes:

• scope, exclusion and product-classification rationale;
• product description, architecture, data flows and external-interface inventory;
• intended purpose, reasonably foreseeable use and operational assumptions;
• cybersecurity risk assessment and requirements traceability matrix;
• secure-development plan, code-review records and release criteria;
• versioned SBOM for each supported release;
• third-party component due-diligence records and supplier evidence;
• threat modelling and security test plans, results and remediation records;
• configuration, secrets, signing-key and production-programming controls;
• secure-update design and update-validation evidence;
• vulnerability disclosure policy, monitoring sources and triage records;
• reporting procedure for actively exploited vulnerabilities and severe incidents;
• support-period rationale, end date and update-retention plan;
• user security instructions and secure-decommissioning guidance;
• change-control and substantial-modification assessments;
• conformity assessment records, EU declaration of conformity and CE-marking evidence.

The strongest structure is traceable in both directions: each applicable requirement points to a design control and objective evidence, while each test or document states which requirement and product version it supports.

A 30/60/90-day implementation plan

Days 1-30: establish scope and ownership

• Inventory products, variants, firmware, companion applications and essential remote services.
• Record CRA and RED DA scope decisions, including exclusions and assumptions.
• Identify the legal manufacturer and map OEM, EMS, software and cloud responsibilities.
• Classify in-scope CRA products against Annexes III and IV.
• Identify the applicable RED Article 3(3)(d), (e) and (f) requirements.
• Nominate owners for product security, vulnerability intake and regulatory reporting.
• Open a gap register with actions, owners, due dates and release impact.

Days 31-60: build the engineering baseline

• Complete product architecture, interface and data-flow descriptions.
• Perform or update threat modelling and the cybersecurity risk assessment.
• Generate a versioned SBOM from a reproducible build or controlled release baseline.
• Assess EN 18031 decision trees and Official Journal restrictions for radio products.
• Define secure defaults, authentication, update, logging and decommissioning controls.
• Add cybersecurity requirements to supplier and EMS agreements.
• Establish a coordinated vulnerability disclosure channel and internal escalation workflow.

Days 61-90: verify and exercise the process

• Execute risk-based security tests and close critical findings.
• Run an update and rollback exercise using production-like signing and delivery controls.
• Reconcile the released firmware, SBOM, production configuration and technical file.
• Exercise a 24-hour/72-hour regulatory reporting scenario without submitting a real notification.
• Confirm the support-period decision and publish required user information.
• Select the conformity assessment route and engage a notified body early where required.
• Hold a release-gate review and document accepted residual risks.

Product release checklist

Before releasing a connected electronic product, confirm that:

• the legal manufacturer and economic-operator roles are documented;
• CRA and RED DA scope decisions use the product’s actual functions and connections;
• CRA classification is based on core functionality, not merely on embedded components;
• applicable EN 18031 requirements and harmonisation restrictions were assessed;
• the risk assessment matches the released hardware, firmware, application and backend;
• no known exploitable vulnerability remains in the release baseline;
• secure defaults and credential provisioning have been verified;
• data in transit and at rest is protected according to risk;
• security updates are authenticated, tested and recoverable;
• the SBOM identifies the released component versions;
• production substitutions and programming are controlled and traceable;
• vulnerability intake, triage, escalation and regulatory reporting are operational;
• the support-period end date and secure-use instructions are available to users;
• the conformity assessment, technical file, declaration of conformity and CE marking are complete.

How Inventronics can support a manufacturer

As an electronics design and manufacturing partner, Inventronics can support the technical part of readiness by integrating cybersecurity requirements into product architecture, component selection, firmware development, verification, production configuration and traceability.

The most effective engagement starts before the design is frozen. It defines evidence ownership, security acceptance criteria and post-market responsibilities alongside cost, quality and delivery requirements. The legal manufacturer retains its regulatory accountability, while both parties work from one controlled product baseline.

Discuss CRA and RED DA readiness for your product with Inventronics. Start with product scope, architecture, the OEM/EMS responsibility split and the evidence already available.

FAQ

Official sources

• Regulation (EU) 2024/2847 – Cyber Resilience Act
• European Commission: Cyber Resilience Act
• Directive 2014/53/EU – Radio Equipment Directive
• Commission Delegated Regulation (EU) 2022/30 – RED cybersecurity requirements, consolidated version
• Commission Implementing Decision (EU) 2025/138 – EN 18031 references and restrictions
• Commission Delegated Regulation (EU) 2026/339 – repeal of Regulation (EU) 2022/30
• European Commission: Radio Equipment Directive

This article provides general technical and regulatory information. It is not legal advice. Product scope and conformity routes should be confirmed for the specific product, intended purpose, market role and release date.