Many companies starting an electronic product project focus on what is visible immediately: product functionality, development cost, PCB assembly price, component availability, prototype lead time and the possibility of moving into serial production. That is natural. The product has to work, it has to be manufacturable and it has to fit the budget.

The problem begins when conformity assessment appears only at the end of the project. Sometimes it comes as a question: “Can you also handle CE?”. Sometimes it appears as an assumption: “If the modules have CE, the whole device should be compliant too”. Sometimes it becomes a schedule pressure: “The product is ready, we only need the document for sales”.

In electronics, this approach is risky. CE marking is not a marketing label or a quality certificate. It is the manufacturer’s declaration that the product meets the requirements of the applicable legislation. To sign such a declaration responsibly, the OEM manufacturer should know which requirements apply to the product, which standards were used, which tests were performed, which risks were assessed and how conformity will be maintained during serial production.

Note: this article is for informational purposes only and is not legal advice. The applicable requirements, standards and conformity assessment route should always be verified for the specific product, market and responsibility model.

This guide explains what an OEM manufacturer should understand before moving an electronic device into production. The point is not that every customer must become a legal or standards expert. The point is to ask the right questions at the beginning of the project and avoid a situation where conformity blocks the launch, shipment, sale or continued production of the device.

Who this guide is for

This article is for companies that develop, order or place electronic devices on the market under their own brand or business model.

Typical situations include:

• you have an idea for an electronic device and want to move from concept to prototype,
• you have a working prototype and are planning serial production,
• you have a design prepared by an external engineering office,
• you are transferring production from another supplier,
• you import or integrate an electronic device under your own brand,
• you sell a B2B, industrial, professional or consumer device,
• you do not have an internal compliance department, but you are formally responsible for the product.

In practice, this issue is not limited to small companies. Large organisations can also have fragmented responsibility: RD assumes one thing, procurement another, the supplier a third, and the sales team expects a finished product with CE marking. If nobody manages conformity from the beginning, the risk returns during testing, documentation review or market surveillance.

If you are moving from an idea or prototype to a product ready for production, it is worth aligning technical, manufacturing and conformity requirements at the same time. This process naturally connects with electronic product development and preparing the product for electronics manufacturing services.

CE is not a sticker at the end of the project

One of the most common misunderstandings is treating CE as the last step before sales. The product works, the enclosure is ready, the prototype passed functional tests, so now it is time to “do CE”. This way of thinking is understandable, but wrong.

CE marking means that the manufacturer declares the product’s conformity with the applicable requirements of European Union legislation. For electronics, this may involve several areas: electromagnetic compatibility, electrical safety, radio equipment, restrictions on hazardous substances, batteries, consumer product safety, environmental requirements or cybersecurity requirements for products with digital elements.

This means conformity assessment begins much earlier than in the laboratory. It begins with understanding the product:

• what it does,
• who will use it,
• where it will operate,
• how it is powered,
• whether it communicates wirelessly,
• whether it contains firmware or software,
• whether it has a battery,
• whether it is part of a larger machine or system,
• which market it will be sold in.

If these questions are not asked early, the project may move in a direction that is later difficult or expensive to defend. The issue may be a PCB layout vulnerable to EMC emissions, insufficient insulation distances, an unsuitable power supply, no space for a label, no firmware version control, missing component documentation or an enclosure that does not meet environmental requirements.

That is why CE should be treated as a design and evidence process, not as a formality after production.

In practice, the CE topic should appear when the product architecture, first technical assumptions and prototype plan are being created. We describe the broader path from concept to implementation in the guide: From idea to finished electronic device.

Who is the OEM manufacturer and who is responsible for the product

Electronic product projects often involve several parties: the customer, electronics designer, PCB supplier, EMS assembler, enclosure supplier, module manufacturer, test laboratory, component distributor and sometimes a final system integrator. This can create the false impression that conformity responsibility will somehow be distributed across all project participants.

In practice, it must be clear who places the product on the market as the manufacturer. If a company sells the device under its own brand, defines its intended use, decides on the construction and takes responsibility for making the product available to customers, it is typically the manufacturer in both the business and formal sense.

A design partner or EMS can help significantly. It can design electronics with EMC in mind, prepare production documentation, control BOM versions, provide traceability, support testing, cooperate with the laboratory and maintain process stability. However, this does not automatically mean it assumes the manufacturer’s responsibility for the Declaration of Conformity of the final product.

This distinction is critical. The EMS usually manufactures according to agreed documentation and process. The OEM is responsible for ensuring that the product as a whole is compliant, properly described, marked, documented and kept in conformity after changes.

OEM, EMS, importer and distributor: simplified responsibility map

The safest approach is to define the responsibility model at the start of the project. Who defines the requirements? Who selects the standards? Who maintains technical documentation? Who orders testing? Who signs the Declaration of Conformity? Who approves production changes? Without these answers, the project may work technically, but remain organisationally unready for the market.

Where to start with conformity assessment for an electronic device

The first step is not choosing a laboratory. The first step is describing the product and its use context. Only then can you reasonably identify which requirements may apply.

Minimum information worth collecting:

• product name and function,
• end user description,
• target market and country of sale,
• operating environment: home, industrial, vehicle, machine, field use, outdoor, humidity, temperature,
• power supply: mains, external power supply, battery, PoE, industrial installation,
• communication interfaces: wired, radio, Bluetooth, Wi-Fi, LTE, LoRa, NFC,
• presence of firmware, application, cloud connectivity or updates,
• mechanical elements and enclosure,
• product variants and configuration options,
• expected production volume,
• planned product lifecycle and change management.

This description is practical, not academic. If the product contains a radio module, conformity will be different than for a simple wired controller. If the product is mains powered, the safety requirements are different than for a low-voltage device supplied by an external adapter. If the product has firmware and network communication, you need to consider not only function, but also updates, configuration and potential cybersecurity requirements.

The earlier this information reaches the design and manufacturing partner, the easier it is to plan product architecture, prototypes, pre-compliance testing, documentation and implementation schedule.

Organising input data like this is part of a good NPI process. At Inventronics, we describe this as a sequence of steps from project qualification through prototype, validation, documentation, pilot run and serial production. See: Product development process.

How to identify which requirements may apply

Not every electronic device is subject to the same requirements. That is why one of the first tasks for the OEM manufacturer is to identify the legislation and conformity areas relevant to the specific product.

The table below does not replace legal analysis, but it shows the typical way of thinking.

In practice, several areas are often analysed in parallel. For example, a small IoT device powered by a battery and communicating via Bluetooth may require consideration of RED, EMC, RoHS, batteries, user instructions, marking and cybersecurity. If the same device is used in an industrial environment, customer expectations around robustness, traceability, quality and version control also become important.

The worst scenario is discovering the applicable requirements after the PCB and enclosure are already finished. At that point, the change may mean redesign, another prototype series, repeated testing and a delayed production launch.

For products with firmware, network communication or updates, cybersecurity requirements should also be considered from the start. We cover this topic separately in the article: Cyber Resilience Act readiness for electronics manufacturers.

Harmonised standards: why they matter and why they should be considered early

Legislation defines general requirements, but it often does not tell the engineer exactly how to design a specific circuit, enclosure, power supply, interface or test procedure. In practice, harmonised standards play a major role because they help demonstrate conformity with the requirements.

For the OEM manufacturer, three points are important.

First, a standard is not only a document for the laboratory. The choice of standards influences the design. It may determine requirements for EMC immunity, emissions, insulation distances, temperature limits, testing approach, marking or user instructions.

Second, standards should be considered before the design is frozen. If the engineering team designs electronics without awareness of the target tests, the risk increases that the product will work functionally but fail testing or require expensive changes.

Third, the list of standards is part of the product’s conformity story. The manufacturer should be able to explain why specific standards were selected, what testing scope was performed and what evidence exists in the technical documentation.

A good design and manufacturing partner does not replace a compliance specialist or laboratory, but it should ask questions that influence the design: does the product have radio communication, what are the environmental limits, where is the power supply, how long are the cables, is the enclosure metal, are filters needed, are test points included and how will component changes be handled?

That is why the discussion about standards should not be separated from electronics design. Decisions about power supply, PCB layout, circuit separation, filtering, enclosure and testability are best made with a team that understands both development and later production. This scope is part of our electronic product development work.

Risk assessment as the foundation of documentation

Conformity assessment is not only about collecting test reports. The manufacturer should understand and document the risks associated with the product. In electronics, those risks may be technical, usability-related, environmental, quality-related and organisational.

Example risk areas:

• electric shock,
• overheating or fire,
• electromagnetic disturbances emitted by the product,
• product susceptibility to external disturbances,
• firmware malfunction,
• loss of communication,
• incorrect battery charging,
• incorrect assembly or component substitution,
• reasonably foreseeable misuse,
• missing instructions, warnings or markings,
• product version change without reassessing conformity impact.

In a mature process, risk assessment is not a separate document created after the fact. It should influence design decisions: component selection, circuit separation, PCB layout, enclosure, protections, production testers, quality control procedures and change approval.

Testing: what to plan before serial production

Final testing is important, but it should not be the first moment when the product meets conformity requirements. In electronic product projects, it is often worth performing earlier pre-compliance tests or at least reviewing the design for EMC, safety and manufacturability.

Tests that may be relevant for an electronic device include:

• EMC emissions,
• EMC immunity,
• electrical safety,
• radio testing for wireless devices,
• RoHS/material verification,
• temperature and load testing,
• environmental testing depending on the application,
• functional and production tests,
• firmware version and configuration control.

The greatest value comes from linking the test plan to project stages. A first prototype is tested differently than an engineering build, a pilot production run or a product ready for the Declaration of Conformity. If the schedule does not allow time for corrections after testing, the risk of delay is high.

From a production perspective, laboratory tests should not be disconnected from production tests. A product that passed testing as a prototype must later be manufactured repeatably, controlled and traced by production batch. This is one reason why conformity assessment should be connected with preparation for electronics manufacturing services.

CE technical documentation: what should be in the product technical file

Technical documentation is evidence that the manufacturer performed conformity assessment in an organised way. It is not a single certificate or one test report. It is a set of information that makes it possible to understand what the product is, which requirements apply, how it was designed, how it was tested and how it is manufactured.

Typical technical documentation for an electronic device may include:

• product description and intended use,
• product variants,
• electrical schematics,
• PCB layout and production files,
• BOM and information about critical components,
• firmware/software description and versions,
• risk assessment,
• list of applicable legislation,
• list of applied standards,
• test reports,
• user instructions,
• label and marking,
• material declarations and RoHS documentation,
• production control procedures,
• production test results,
• ECO/ECN change history,
• EU Declaration of Conformity.

In practice, technical documentation is strongest when it is created together with the project. If it has to be reconstructed years later or after a supplier change, decisions, reports, file versions, justifications and approval records are often missing.

If you are preparing an RFQ for a design partner or EMS, part of this information should be collected already at that stage. It helps assess scope, risks, missing data and a realistic implementation path. See the guide: How to prepare an RFQ for electronics design and manufacturing.

Serial production and maintaining conformity

Conformity assessment does not end on the day the Declaration of Conformity is signed. An electronic product lives: components, suppliers, firmware, PCB batches, substitute availability, customer requirements and sometimes standards themselves change.

For the OEM manufacturer, the following are especially important:

• BOM version control,
• approval of substitute components,
• assessment of the impact of changes on EMC, safety, radio and product function,
• firmware version control,
• batch traceability,
• retention of production test results,
• ECO/ECN procedure,
• decision rules for when a change requires retesting or laboratory consultation.

This is an area where the EMS partner can provide significant value. A stable production process, traceability, change control and batch documentation help maintain conformity over time. Without this, a product may formally pass testing as a prototype, while serial production begins to drift away from the assessed version.

In serial production, conformity depends not only on the design, but also on process discipline: BOM control, firmware versions, testing, traceability and change approval. That is why OEM projects need an EMS partner that understands both electronics assembly and the consequences of changes for the final product. See: Electronics Manufacturing Services.

Typical OEM mistakes when launching electronics

The most common mistakes usually do not result from bad intent. They come from not realising that conformity is part of the product project.

Typical problems include:

• treating CE as a final task,
• not identifying applicable directives and regulations at the start,
• assuming that a CE-marked module makes the entire device compliant,
• no list of standards before freezing the design,
• no budget or time for testing,
• technical documentation not collected during the project,
• missing instructions, warnings or correct marking,
• no change control after the first production batch,
• substituting components without assessing conformity impact,
• signing a Declaration of Conformity without sufficient evidence.

Each of these mistakes can cost more than organising the process earlier. The cost is not only redesign. It may also be delayed sales, a blocked shipment, a customer dispute, loss of credibility or repeated testing.

If the project is already past the prototype stage and problems have appeared with testing, documentation, manufacturability or transfer to serial production, a structured technical diagnosis may be the right first step. This scenario is addressed by Rescue NPI 60.

How a design and manufacturing partner can help

A good design and manufacturing partner should not promise to “take care of CE” without understanding the product. It should help the OEM move through the project in a way that creates a real path to conformity and serial production.

Support may include:

• organising product requirements,
• identifying questions needed for conformity scoping,
• designing electronics with EMC, safety and manufacturing in mind,
• preparing prototypes for testing,
• supporting pre-compliance testing,
• cooperating with the laboratory,
• preparing production documentation,
• controlling BOM and substitutes,
• maintaining batch traceability,
• maintaining firmware and process versions,
• supporting data collection for the technical file.

The greatest value appears when the conformity discussion starts before construction decisions are frozen. At that point, architecture, components, enclosure, power supply, testers and process can still be selected in a way that reduces the risk of later rework.

It is also worth checking whether the partner has real capabilities in the areas relevant to the product: design, assembly, testing, traceability, quality and technical documentation work. Learn more about Inventronics on the pages: Certifications, About us and Electronics Manufacturing Services.

Checklist of questions for the OEM manufacturer

Before starting the project or moving from prototype to serial production, it is worth answering the following questions.

When to discuss CE with your EMS partner

As early as possible. Not because every project needs full testing immediately, but because conformity requirements influence technical decisions.

The discussion is most valuable:

• at the product concept stage,
• before selecting modules and architecture,
• before the first PCB layout,
• before freezing the enclosure,
• before the prototype series,
• before laboratory testing,
• before production transfer,
• before approving substitute components.

If the product is already finished, the discussion still makes sense, but its nature changes. Instead of designing with foresight, the team has to assess the risks of the existing construction and decide whether the documentation, testing and production process are sufficient for responsible implementation.

Summary

CE conformity assessment for an electronic device is not a single document or the last step before sales. It is a process that connects legal requirements, design decisions, testing, technical documentation, production and change control.

The OEM manufacturer does not need to know every standard and every test scenario alone. However, it must understand that, as the product owner, it should take care of the right questions, responsibilities, documentation and evidence. A design and manufacturing partner can help, but it does not replace a conscious process on the manufacturer’s side.

The greatest risk appears when conformity is addressed only at the end. The greatest savings appear when CE is treated as part of the project from the beginning: from concept, through prototype, to serial production and product maintenance on the market.

Talk to Inventronics about the technical path to production and the data needed for conformity assessment. We can help organise requirements, risks, production documentation and change processes before they become costly problems.

FAQ

The post CE Conformity Assessment for OEM Manufacturers appeared first on INVENTRONICS.

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.

The post CRA, RED DA and EN 18031: A Practical Readiness Guide for Electronics Manufacturers appeared first on INVENTRONICS.