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.

RFQ, or request for quotation, is not just a short message saying: “please quote the production of this device”. In electronics, that kind of request usually leads to many follow-up questions, non-comparable offers or a price based on assumptions the customer cannot see.

An RFQ is meant to help obtain a reliable quotation. In practice, it is also the first test of a project. It shows whether the customer knows what they are looking for, whether the documentation is complete, and whether the scope covers only PCB assembly or also design, prototyping, NPI, firmware, testing, enclosure integration and production of the finished device.

This article explains how to prepare a quote request for electronics manufacturing or electronics design so that a partner can quickly assess the scope, risks and cost. The goal is not perfect documentation on day one. The goal is to separate facts from assumptions from the start.

Who this article is for

This material is for customers who want to ask about electronics design, prototyping, NPI, PCB assembly or electronic device manufacturing.

Typical situations include:

• you have an idea for a device and want to understand the cost of further work,
• you have a prototype and want to prepare it for production,
• you have PCB documentation and are looking for electronics assembly,
• you have a product after a previous supplier and want to organize production,
• you import a finished product and are considering your own production,
• you want to compare EMS offers but do not know what information is needed,
• you need a quote not only for a board, but for a complete device with final testing.

If the project is simple and the documentation is complete, an RFQ can quickly lead to a quotation. If the project is incomplete, the RFQ should first help identify what is missing.

What an RFQ means in electronics design and manufacturing

An RFQ is a request for quotation whose purpose is to obtain a price, lead time and scope of delivery. In electronics manufacturing, an RFQ may cover different things: electronics design, prototype build, PCB assembly, production preparation, testing, firmware programming, enclosure integration or serial production.

The problem is that these scopes are often mixed in one request. A customer asks for production but actually still needs design work. They ask for PCB assembly but expect a finished device. They ask for a unit price but do not have a final test, an up-to-date BOM or volume information.

A good RFQ should therefore answer three questions:

• what exactly needs to be quoted,
• what stage the project is at,
• which data is certain and which data is still an assumption.
• Without this, a partner may prepare an offer, but it will depend on interpretation. Two offers based on different interpretations are not comparable.

Why comparable offers matter more than the number of offers

Many customers send the same request to several suppliers and expect a simple price comparison. This only makes sense if every supplier quotes the same scope, the same volumes, the same tests and the same level of responsibility.

In practice, this is often not the case. One partner assumes they will buy components and take responsibility for BOM completion. Another assumes that the customer will supply the parts. A third includes functional testing, while a fourth includes only visual inspection. One includes tooling preparation, while another shows it later as an additional cost.

That is why a well-prepared RFQ should force comparability. The customer should specify whether they expect a quote with component sourcing, without component sourcing, with testing, without testing, with firmware programming, with packaging, with final assembly or only for PCB assembly. If an element should be optional, it is worth asking for it as a separate line item.

The best offer is not always the lowest price. The best offer clearly shows the scope, assumptions, risks and conditions for moving to the next stage. This helps the customer make a decision based on facts, not on a price that looks attractive only because part of the work is missing.

RFQ, RFI and RFP: what is the difference?

In practice, the customer does not always need an RFQ immediately. Sometimes an RFI or an RFP is a better first step.

RFI, or request for information, is used to check whether a potential partner has the right capabilities. It is useful when the customer is still looking for a supplier and wants to ask about services, experience, technologies, testing, NPI approach, quality, traceability or firmware support.

RFP, or request for proposal, is broader. It checks not only the price but also the proposed approach. It makes sense when the project requires technical cooperation, is not fully defined or the customer is looking for a partner for a larger process: from concept through prototype to production.

An RFQ works best when the scope is specific enough to prepare a quote. If the customer has only an idea and expects a serial production price, they are formally asking for an RFQ, but in reality they first need analysis or an RFP.

In practice, an EMS RFQ should combine purchasing language with technical language. A quote request for electronics manufacturing cannot be limited to price, because the partner must also assess component, testing, documentation, timing and supply chain risks.

The most common mistake: asking only for a unit price

The unit price is important, but in electronics, asking for it too early often leads to poor decisions. If it is not clear whether the product has a final test, what the BOM looks like, whether firmware must be programmed, what the enclosure looks like and what the production scale is, the price will only be an estimate.

The biggest problem appears when the customer compares offers without checking what they include. One offer may include component sourcing, assembly, programming and testing. Another may cover only SMT assembly. A third may not include tooling preparation, while a fourth may assume that the customer supplies all components.

As a result, the cheapest offer may not be the best one. It may simply be the least complete.

A good RFQ should make the scope clear: what is included in the price, what is excluded, what assumptions were made, what requires clarification and which costs are one-off.

First define what you are really looking for

Before sending an RFQ, it is worth naming the starting point. This shortens the discussion and reduces the risk of misunderstandings.

Typical scenarios:

If you do not know which scenario fits your situation, it is worth saying so directly. A good partner should help determine whether you need a production quote or an analysis stage first.

RFQ for electronics design

A request for electronics design should describe the problem, not only the expected solution. At the beginning, you do not need to have a schematic or PCB. You do need to describe what the device should do, where it will operate, who will use it and which constraints matter most.

For a design RFQ, it is worth providing:

• a description of the device functions,
• the operating environment,
• power supply requirements,
• communication requirements,
• size constraints,
• expectations for the enclosure,
• firmware requirements,
• expected volume,
• regulatory or industry requirements,
• target product cost, if known.

At this stage, the quote usually covers design work, prototyping and first validation. The serial production price can only be indicative, because there is no final BOM, test strategy or production documentation yet.

The transition from idea to product is described in the Inventronics product development process.

RFQ for a prototype

A prototype request should clearly separate two goals: checking functionality and preparing for production. A demonstration prototype may work, but it does not have to be ready for serial production.

For a prototype RFQ, it is worth providing:

• the current project stage,
• available files and documentation,
• number of prototypes,
• expected test scope,
• firmware programming method,
• enclosure or mechanical requirements,
• critical components,
• known technical issues,
• decisions that the prototype should confirm.

If the prototype is meant to be a step toward production, DFM, DFT, testing and documentation should be discussed from the start. Otherwise, it is possible to build a demonstration unit that later requires major changes before serial production.

RFQ for NPI and production preparation

NPI, or new product introduction, is often missing from quote requests. A customer asks about assembly, but the product does not yet have a stable BOM, a test procedure, quality criteria or a plan for the first production run.

An NPI RFQ should include:

• documentation review,
• BOM analysis,
• component availability assessment,
• DFM and DFT,
• test preparation,
• firmware programming procedure,
• pilot run plan,
• acceptance criteria,
• ECO/ECN change handling,
• a plan for moving to repeatable production.

This is especially important when a project is stuck between prototype and production or when the customer wants to transfer production from another supplier. In such situations, a sensible first step may be a diagnostic phase such as NPI Rescue.

RFQ for PCB assembly

A PCB assembly request is most concrete when the customer has a complete set of production data.

The minimum data set includes:

• Gerber files or full PCB production data,
• BOM with manufacturer part numbers,
• centroid or pick-and-place data,
• assembly drawing,
• information about variants,
• SMT and THT requirements,
• quality requirements,
• volumes and schedule,
• information on who buys the components,
• test scope after assembly.

If some data is missing, a quote may still be possible, but it should include assumptions. It is worth marking immediately what is current, what is preliminary and what is not available yet.

RFQ for a complete device

A complete device is more than an assembled board. An RFQ for a device should also include the enclosure, mechanical parts, harnesses, connectors, labels, firmware, configuration, final testing, packaging and logistics requirements.

In the industry, this scope is often called box build or final assembly. The customer does not have to use these terms, but should clearly state whether they expect only electronics or a device ready for shipment.

For this type of RFQ, it is worth providing:

• product structure,
• final assembly scope,
• list of mechanical parts,
• packaging requirements,
• labeling method,
• final test procedure,
• traceability requirements,
• acceptance criteria for the finished device,
• responsibility for sourcing non-PCB parts.
• This matters because integrating electronics with the enclosure often reveals issues that are not visible in PCB files alone.

How to describe volumes and timing

Volumes are one of the most important parts of an RFQ. Five prototypes, a pilot run, the first hundred units and repeatable production over several years are quoted differently.

In the request, it is worth separating:

• number of prototypes,
• planned first production run,
• expected monthly or quarterly production,
• annual production,
• possible volume increases,
• expected launch date,
• preferred delivery rhythm.

If you do not know exact volumes, provide scenarios. For example: 5-10 prototypes, first run of 50 units, annual production of 500-1000 units. This is better than no information, because the partner can assess whether the process should be prepared for manual small-batch startup or for larger repeatability from the beginning.

Timing should also be described realistically. If the project requires component sourcing, PCB fabrication, assembly, programming, testing and an enclosure, the delivery time depends on the slowest element. An overly aggressive deadline in an RFQ may lead to an offer with many assumptions or to important preparation steps being skipped.

A good partner should separate the time needed to prepare the process from the time needed for production itself. The first batch usually requires more engineering work than later batches.

One-off costs: NRE, tooling and test preparation

In an RFQ, it is worth asking not only about the unit price but also about one-off costs. In electronics, these can be significant, especially for new projects, prototypes, NPI and complete devices.

One-off costs may include:

• documentation analysis,
• process preparation,
• SMT stencil,
• test adapters,
• assembly fixtures,
• test program preparation,
• firmware programming procedure preparation,
• first batch validation,
• production documentation,
• design changes for DFM or DFT.

In the industry, such costs are often called NRE, or non-recurring engineering. For the customer, the key point is not the term itself, but understanding which costs appear once and which costs repeat in every batch.

When comparing offers, the customer should check whether one-off costs are shown separately. An offer with a low unit price but hidden preparation costs may turn out to be less attractive than a more expensive but transparent offer.

IP, confidentiality and ownership of documentation in an RFQ

An RFQ often requires sharing technical documentation. This may include schematics, PCB files, BOM, firmware, mechanical drawings, test data, a description of product behavior and information about problems in current production. This is sensitive data.

Before sending full documentation, it is worth agreeing confidentiality rules. In many cases, an NDA is needed, especially if the project contains proprietary technical solutions, firmware, end-customer data or information about costs and suppliers.

It is also worth checking who owns the documentation. This often becomes a problem in projects developed by several subcontractors or during production transfer from a previous supplier. The customer may have the product but not full rights to source files, tooling, test programs or firmware code.

That is why the RFQ should indicate which data the customer has, which data can be shared and which items need clarification. If the goal is long-term production, documentation rights and change handling are as important as the assembly price.

How to ask for quote variants

If a project has several possible paths, it is better to ask for variants instead of one combined price. This is especially useful when the customer does not yet know whether to start with a prototype, a pilot run, full NPI or immediate production.

Example variants:

• quote for documentation review only,
• quote for prototypes without serial production preparation,
• quote for prototypes with DFM/DFT analysis,
• quote for a pilot run with final testing,
• quote for production with component sourcing,
• quote for production with customer-supplied components,
• quote for a complete device with enclosure assembly and packaging.

This structure helps show where the cost is created, which decisions affect lead time and where the risk of wrong assumptions can be reduced. It also makes internal discussion easier, because management, purchasing and engineering teams can see what they are actually paying for.

What data to prepare for every RFQ

Regardless of the scenario, a good RFQ should include several groups of information.

• Product description and use case
  What the device does, where it operates, who uses it and what the consequences of failure are.
• Project stage
  Whether there is only an idea, a prototype, a PCB design, a first batch or production at another supplier.
• Expected service scope
  Design, prototype, PCB assembly, component sourcing, NPI, testing, firmware, enclosure, final assembly or serial production.
• Technical documentation
  Schematic, PCB, BOM, production files, drawings, mechanical models, assembly instructions, test description and firmware.
• Volumes and timing
  Number of prototypes, first batch, annual production, preferred schedule and expected flexibility.
• Quality and regulatory requirements
  Standards, certificates, operating environment, traceability, acceptance criteria and end-customer requirements.
• Main risks and concerns
  Component availability, cost, timing, quality, IP, testing, firmware, production transfer or problems with a previous supplier.

If the request concerns repeatable production, it is also worth adding information about the expected supply model: production on demand, safety stock, scheduled deliveries, component sourcing by the partner or customer-supplied components. This helps assess not only price, but also operational risk.

You do not need to have everything perfect. You do need to show what is known and what still needs clarification.

What to do if the documentation is incomplete

Incomplete documentation does not stop the discussion. It only stops the expectation that a reliable serial production offer can be prepared immediately.

If data is missing, the best approach is to say it directly in the RFQ. For example: “we have a working prototype but no formal test procedure”, “the BOM needs verification”, “firmware is developed by an external team”, “the enclosure is still being designed”, “we do not know whether documentation from the previous supplier is complete”.

This honesty shortens the process. The partner can then propose an analysis stage, documentation review or NPI instead of pretending that everything is ready for production.

Table: minimum data for different quote requests

This table does not replace a technical discussion, but it helps prepare the request so that the partner can identify risks faster.

Common mistakes in RFQ requests

The most common mistake is sending only the BOM and expecting the full price of a finished device. The BOM is important, but it does not describe testing, quality, final assembly, firmware or production risks.

Other common mistakes include:

• no volume information,
• no distinction between prototype and serial production,
• unclear component sourcing responsibility,
• no test information,
• no acceptance criteria,
• no product variant information,
• omitting firmware and programming,
• no enclosure and packaging data,
• expecting comparable offers for different scopes,
• hiding problems from current production.
• A good RFQ does not have to be long. It has to be specific. The less the partner has to guess, the better the chance of receiving a useful quote.

How Inventronics can help

Inventronics can help customers prepare a project for quotation even when the input data is not yet complete. The discussion may cover electronics design, prototype, NPI, BOM review, PCB assembly, firmware, testing, enclosure integration and serial production preparation.

If the customer has an idea or prototype, the first step may be organizing requirements and risks. If the customer has finished documentation, the next step may be manufacturability, testing and quotation review. If the customer wants to transfer production, it is worth starting with a data audit and a re-NPI plan.

The most important point is not to pretend that every project is ready for immediate production. Sometimes the best answer to an RFQ is not a unit price, but a proposal for the first stage: analysis, documentation review or a pilot run.

Frequently Asked Questions

If you are looking for shorter answers before sending a request, see also the Inventronics frequently asked questions.

Summary

A good RFQ for electronics design and manufacturing is not a purchasing formality. It is a tool that helps organize the scope, project stage, technical data, risks and quality expectations.

The better the request is prepared, the lower the risk that the customer receives offers that are not comparable or look attractive only because they are incomplete. In electronics, the most expensive items are often not those visible in the unit price, but those missing from the scope: testing, firmware, documentation, NPI, enclosure, quality and change handling.

If you are not sure whether your project is ready for quotation, it is worth starting with a technical discussion. Sometimes the shortest path to a good offer is to organize the input data first.

Talk to Inventronics about a quote request for electronics design and manufacturing. We can help define the scope, missing data, risks and the shortest path to a meaningful quotation.

The post How to Prepare an Electronics Quote Request appeared first on INVENTRONICS.

The question is no longer solely about finding the cheapest production location. Increasingly, the focus is on: where can we achieve predictable, secure production with good communication, document protection, rapid response to changes, and a real impact on quality?

This article explores the benefits of relocating electronics manufacturing to Poland, the risks that must be assessed before such a move, and why nearshoring should be approached as a structured technical and production project, rather than a simple supplier change.

This article is intended for:

This information is intended for clients who already have an electronic product, prototype, documentation, or an existing production line and are considering a change in their collaboration model.

Typical Applications:

• Production is carried out separate from the sales market.
• Deliveries are unpredictable or excessively long.
• Supplier communication can slow down the implementation of changes.
• The client has limited visibility into quality control, testing procedures, and batch history.
• The importance of protecting intellectual property, firmware, documentation, or test data is increasing.
• The product requires frequent design modifications or variations.
• Transportation costs, inventory levels, complaints, and delays are increasingly offsetting the lower unit price.
• Clients seek a manufacturing partner located closer to their R&D teams, target markets, or decision-making centers.

If you recognize these challenges, nearshoring may be a viable option. However, this does not necessarily mean that all production should be immediately relocated. It is first necessary to understand what is truly driving costs and risks.

What is nearshoring for electronics manufacturing?

Nearshoring involves relocating part or all of the production process closer to the market, the design team, or the end customer. For European companies, this may mean manufacturing electronics in Poland instead of in Asia, or moving away from a very distant offshore model.

In practice, nearshoring of electronics production involves more than just geographic proximity. It also entails a shift in project management, leading to shorter communication channels, simplified audits, faster response to changes, and greater control over documentation, testing, components, and quality.

For some clients, nearshoring represents a complete relocation of serial production. For others, a phased approach is more suitable: prototypes, pilot series, strategic products, or variants requiring frequent modifications can be produced in Poland, while larger, stable volumes may remain with the existing supplier. It is crucial that the decision is based on risk assessment and total cost analysis, rather than simply following a trend in location.

Why COVID Changed the Way We Think About Manufacturing.

The COVID-19 pandemic demonstrated that a global supply chain, which may have functioned effectively for years, can suddenly become a source of significant risk. Factory closures, transportation restrictions, component shortages, soaring freight costs, and uncertain delivery schedules particularly impacted projects optimized solely for low unit costs.

Many customers have realized that the real challenge isn’t just the electronics assembly itself, but the lack of flexibility. When a component is unavailable, a suitable substitute must be quickly approved. When a customer requirement changes, the documentation, firmware, testing, and production process must be updated. If a production run is delayed, it’s crucial to quickly identify the specific bottleneck.

With a supplier located far away, each of these actions can take significantly longer. Time zone differences, language barriers, a lack of direct contact with engineers, and limited process visibility mean that even minor changes can become complex undertakings.

COVID-19 has not halted globalization, but it has changed the way risk is assessed. Clients are now increasingly focused on supply chain resilience, alternative component sourcing, safety stock levels, the ability to conduct rapid audits, and the availability of a local partner with expertise in both manufacturing and design.

Geopolitical shifts in the United States and their impact on the electronics industry.

A second important factor is the evolving geopolitical landscape of the United States. In recent years, the United States has increasingly viewed semiconductors, digital technologies, data, and electronics as strategic areas. This translates into increased pressure on supply chain security, export restrictions, technology controls, a “friend-shoring” policy, and the rebuilding of select manufacturing capabilities closer to trusted markets.

For our European customers, this is not an abstract policy. If a product incorporates components subject to restrictions, utilizes specific communication technologies, targets a regulated industry, or is part of a larger industrial system, geopolitical factors can impact component availability, lead times, documentation requirements, and the ability to sell in certain markets.

This is compounded by the risks of tariffs, origin controls, sanctions, changes in trade relations, and pressure to diversify suppliers. Even if a specific project is not directly affected by any restrictions, the client should be aware of the extent to which their production depends on a single region, a single logistics route, or a single supplier.

Nearshoring to Poland does not eliminate all geopolitical risks, but it can reduce certain operational dependencies. Manufacturing closer to the market facilitates document control, communication with partners, faster implementation of changes, and the development of an alternative supply chain model.

Intellectual Property Protection: Documentation, firmware, testing, and proprietary knowledge.

In electronics, intellectual property encompasses more than just schematics and PCB designs. It also includes firmware, manufacturing files, bill of materials, test procedures, production data, programming settings, quality documentation, mechanical solutions, device configuration, and the knowledge behind the design choices made for a specific product.

The more dispersed the supply chain, the more difficult it becomes to control who has access to information, where it is stored, how it is updated, and whether all versions are consistent. This problem is particularly acute when a project has been developed by multiple teams, manufactured by an external supplier, and when testing and firmware programming are poorly documented.

Nearshoring can be beneficial by reducing the organizational and legal distance between the client and the partner. It simplifies the establishment of rules regarding access to documentation, intellectual property rights, file transfer methods, change management procedures, process auditability, and responsibility for production data.

It’s important to note that location alone does not guarantee IP security. Robust measures are required, including agreements, version control, a clear division of responsibilities, access procedures, and a partner who understands that client documentation is not merely an addition to production, but one of the most critical project assets.

In practice, it’s crucial to verify several key aspects: who possesses the current source files, who has the authority to use the tooling, where the firmware images are stored, who is familiar with the programming procedures, who approves component substitutions, and whether the previous supplier holds critical knowledge that has not been documented. If the answers to these questions are unclear, the production transfer should begin with regaining control over the documentation and intellectual property.

Which products are best suited for nearshoring?

Nearshoring is not equally cost-effective for all products. It is most advantageous in situations where flexibility, control, and rapid response are critical.

Suitable products include:

• For medium to short production runs,
• with frequent design changes,
• with numerous variations or configurations.
• requiring firmware programming or calibration.
• Available for the European market.
• with high quality requirements,
• requiring final testing or integration with the enclosure.
• Subject to intellectual property protection.
• dependent on rapid engineering support,
• In situations where returns are costly or logistically challenging.

A less suitable candidate for optimization might be a very simple, stable product with a high volume, low unit value, and minimal risk of design changes. In such cases, the lowest possible production cost may remain the critical factor. However, even in these situations, it’s worth considering diversification: locating a portion of the production closer to the market, while maintaining the existing production model for the remainder.

Importer as Manufacturer: When Nearshoring Represents a Business Model Shift.

A specific scenario involves clients who previously imported finished electronic products and now wish to transition to becoming manufacturers or owners of their own products. This decision may stem from a need for greater control over quality, profit margins, availability, service, branding, device functionality, or the protection of relationships with end customers.

In this scenario, nearshoring involves more than simply relocating existing production to Poland. It represents a shift in the business model: moving from the sale of finished products to the management of the customer’s own electronic product. The client transitions from being solely an importer to taking responsibility for specifications, documentation, compliance, testing, design changes, component availability, and the product lifecycle.

This approach provides greater independence but requires a structured technical process. Simply sending a device image to a partner and expecting a local copy is insufficient. A legal and secure pathway is needed: this includes defining functional specifications, electronic design or reviewing existing designs, component selection, documentation, prototyping, testing, certification, production preparation, and New Product Introduction (NPI).

That’s when an EMS (Electronics Manufacturing Services) or design-to-manufacturing partner becomes essential. Their role extends beyond PCB assembly to encompass assisting clients in transitioning from off-the-shelf components to a product they have real control over. This includes firmware development, production documentation, final testing, enclosure design, product variations, and change management procedures.

For importers, the benefits may include increased predictability and the opportunity to develop products under their own brand. However, a risk is underestimating the scope of responsibility. Transitioning to a manufacturing role requires consideration not only of the purchase price, but also of market compliance, batch quality, service, returns, component availability, and intellectual property protection.

Therefore, it’s advisable to begin with a feasibility analysis. The initial outcome should not be a direct offer for mass production, but rather a roadmap outlining what can be developed locally, what requires a new design, the legal and technical risks involved, the necessary testing procedures, and the timeline for safely proceeding to the first production run.

Decision Map: Is Nearshoring a Viable Option?

When is it advantageous to consider relocating production to Poland?

Consider nearshoring electronics production to Poland when unit cost is no longer the sole determining factor, and factors such as lead time, quality, communication, and control become more important.

Warning Signals:

• Lead times are difficult to predict.
• Every design change takes too long.
• Complaints are often analyzed slowly or without a clear identification of the root cause.
• The client does not have full visibility into testing and quality control processes.
• Production often requires frequent communication with the technical team.
• The product has multiple variants or is produced in short production runs.
• There is a risk associated with the protection of firmware, data, or documentation.
• Inventory costs, transportation expenses, and delivery delays are increasing.
• The project is intended for the European market and requires compliance with local regulations.

Poland is a particularly suitable location for products requiring design collaboration, New Product Introduction (NPI), testing, flexibility, and strong communication. While it may not always be the most cost-effective option for very large, stable production volumes, it can be a better choice when the cost of errors, delays, or loss of control outweighs the difference in assembly costs.

When nearshoring is not the solution.

Nearshoring is not a panacea. If a project suffers from poor documentation, an outdated Bill of Materials (BOM), a lack of testing procedures, unclear firmware versions, and undefined quality requirements, simply relocating production will not resolve the underlying issues.

In such cases, an initial project assessment phase is required. This involves determining which documentation is current, identifying approved components, understanding the final testing procedures, defining acceptance criteria, and identifying any issues encountered in previous production runs.

Nearshoring can be part of the solution, but only when combined with New Product Introduction (NPI), project audits, and production preparation. Without these elements, the client risks transferring not only the product but also all existing problems to the new supplier.

If a project is facing difficulties, it’s advisable to begin with a thorough diagnosis and a stabilization plan. This approach aligns well with the Rescue NPI 60 intervention strategy: Rescue NPI 60

Europe and Asia: More than just the price per unit.

Comparisons of manufacturing costs between Asia and Europe often begin with the unit price. While understandable, this is an incomplete picture. In electronics, the total cost of ownership (TCO) is crucial. This encompasses not only assembly costs, but also transportation, inventory, tied-up capital, shift management, returns, audits, communication, delays, quality risks, and the cost of lost sales.

A lower per-unit price can be advantageous for stable products, high volumes, and well-established processes. However, it may become less attractive when dealing with frequently changing products, requiring rapid response times, involving short production runs, demanding stringent quality requirements, or when the product is critical to the end customer.

In Europe, a key advantage often lies not in the lowest labor costs, but in a shorter decision-making cycle. It’s easier to meet with the team, conduct audits more quickly, efficiently discuss changes to the Bill of Materials (BOM), analyze complaints, or launch a pilot production run. For many projects, this flexibility offers greater value than the perceived cost savings in assembly.

How to calculate the actual cost of transferring production.

Before making a decision about nearshoring, it’s important to calculate several cost and risk factors.

The first category includes direct costs: assembly, components, testing, programming, packaging, logistics, and warehousing. The second category encompasses setup costs: documentation analysis, production data preparation, tooling, test adapters, initial production run, process validation, and any necessary corrections.

The third group, often the most significant yet difficult to quantify, represents hidden costs: delays, excess inventory, warranty claims, slow response to change requests, loss of version control, component issues, flawed testing assumptions, and client team time spent on supplier coordination.

Nearshoring becomes a viable option when the benefits of reduced lead times, improved quality, lower risk, and increased project control outweigh the difference in unit cost.

A proper Total Cost of Ownership (TCO) analysis should compare two scenarios: the current production model and a model involving the relocation of a portion or the entirety of the process to Poland. It’s important to consider not only the purchase cost but also the cost of time. If a client’s team regularly spends weeks resolving changes, addressing complaints, or dealing with component shortages, this represents a real operational cost, even if it’s not immediately apparent in the invoice price.

The greatest risks associated with transferring production.

Transferring electronics production requires careful preparation. The greatest risks typically do not stem from the assembly process itself, but from deficiencies in the input data.

Common Issues:

• incomplete production documentation,
• Variations in Bill of Materials (BOM) between the customer and the supplier.
• No approved component substitutes available.
• PCB files that do not match the actual product version.
• Tests described only in an informal manner.
• Firmware programmed by a single individual.
• No ECO/ECN change history available.
• unclear quality criteria,
• equipment belonging to the previous supplier,
• Data regarding complaints and common defects is unavailable.

Therefore, the transfer of production should begin with an audit of the documentation and process. Only then can production be responsibly costed and the first production run planned.

It’s important to remember the risk of “hidden processes.” Sometimes, a previous supplier produced correctly not because the documentation was complete, but because operators possessed undocumented workarounds, corrections, and product-specific knowledge. When production is transferred, these informal practices disappear. The new partner only sees the documentation, making the transfer a good opportunity to convert this undocumented knowledge into a controlled process.

What to avoid during production transfer.

The least effective approach is to send a package of files to several potential suppliers and wait for comparable quotes. If the documentation is incomplete, each quote will be based on different assumptions. One may not include testing, another may omit firmware programming, a third may assume different quality criteria, and a fourth may not factor in component risk.

A common mistake is rushing production without a pilot run. When a client immediately orders a large quantity, the new supplier lacks the opportunity to safely identify and address potential issues. Problems that should be revealed during a pilot phase often surface only during full-scale production.

The third mistake is treating intellectual property protection solely as a legal matter. While contracts are important, practical implementation is equally crucial: controlling access to files, version control, the method of firmware delivery, decisions regarding component substitutions, and who is authorized to modify production documentation.

The transfer process should be managed as a technical project, not as a routine procurement change.

What to prepare before discussing a technology transfer.

Before engaging with a potential new partner, it is advisable to gather a comprehensive set of information to assess the scope and associated risks.

Key features:

1. Product Description and Applications.
   What is the device’s purpose, what environment does it operate in, who is the end-user, and what are the consequences of failure?

2. Current technical documentation.
   Schematics, PCB files, Bill of Materials (BOM), product variants, mechanical specifications, firmware description, assembly and packaging instructions.

3. Production and quality data.
   Volumes, defect history, complaints, test results, acceptance criteria, traceability requirements, and information on previous issues.

4. Transfer Range
   Whether the scope includes the entire production run, a pilot series, a specific variant, PCB assembly, final testing, programming, integration with the enclosure, or the complete device.

5. Business Risks
   Deadlines, cost constraints, end-customer requirements, intellectual property risks, component dependencies, and the reasons why the current model is no longer effective.

If some data is incomplete, it doesn’t preclude a discussion. It simply indicates that the initial step should be to organize the documentation, rather than immediately providing a quote for a production run.

Here’s a step-by-step overview of the production transfer process:

A successful production transfer should be structured in phases. This ensures the client understands the verification process, potential risks, and the timeline for each decision point.

Typical workflow:

1. Preliminary Qualification.
   Product evaluation, volume assessment, review of available documentation, analysis of transfer reasons, and identification of key risks.

2. Document review.
   Verification of Bill of Materials (BOM), Printed Circuit Board (PCB) designs, firmware, test procedures, quality requirements, revision history, and data compliance.

3. Plan for New Product Introduction (NPI) or Re-NPI.
   Identifying areas for improvement prior to production launch: documentation, components, testing procedures, adapters, programming processes, or acceptance criteria.

4. Procurement and process preparation.
   Component availability verification, including substitutes, tooling, test station readiness, and production data validation.

5. Pilot production run.
   Production of a limited batch to validate documentation, assembly processes, testing procedures, cycle times, defect rates, and communication effectiveness.

6. Performance overview and stabilization.
   Problem analysis, documentation updates, change management decisions, and preparation for subsequent production runs.

7. Repeatable Manufacturing.
   Establish regular deliveries with version control, traceability, testing, and a defined change management process.

The biggest mistake is to treat technology transfer as a simple “file transfer.” In practice, a new partner must understand the product, the process, the testing procedures, the quality standards, and the rationale behind previous decisions.

Why NPI is Crucial for Nearshoring

New Product Introduction (NPI) is not only necessary for new projects. When transferring production, a re-NPI process is often required: a reassessment to ensure the product, documentation, and process are ready for stable production with a new partner.

This stage reveals discrepancies between documented specifications and actual production processes. Instances may include test variations from documented descriptions, component substitutions without corresponding BOM updates, or firmware programming procedures relying on undocumented operator knowledge.

Transferring production without proper NPI (New Product Introduction) processes carries significant risk. While a new supplier may be able to manufacture a product based on the provided documentation, that documentation may not accurately reflect the actual manufacturing process. Therefore, a reliable partner should inquire not only about the documentation itself, but also about the product’s history, quality issues, design decisions, and acceptance criteria.

How Inventronics Can Help.

Inventronics can assist clients with evaluating, preparing for, and launching production closer to the market. The scope of services depends on the project’s stage and may include document analysis, BOM review, testability assessment, New Product Introduction (NPI) preparation, pilot production, electronics assembly, firmware programming, final testing, and enclosure integration.

If a project is not yet well-defined, the initial step should be a thorough assessment: identifying what is complete, what is missing, potential risks, and whether the transfer can be executed without requiring design modifications. If the project is ready, the next steps involve process preparation and the production of the first batch.

For projects requiring rapid stabilization, the Rescue NPI 60 approach can be beneficial. This involves proactively identifying and mitigating risks, ensuring comprehensive documentation, and establishing a clear action plan before commencing full production. Rescue NPI 60

For more information about Inventronics’ comprehensive product development process, please see here: Inventronics product development process.

Frequently Asked Questions.

Summary:

Relocating electronics production to Poland is more than just a change of location. It’s a strategic decision to gain greater control over product development, documentation, quality, communication, intellectual property, and supply chain risk.

COVID-19 highlighted that overly long and inflexible supply chains can halt even well-designed products. Geopolitical shifts in the USA have demonstrated that electronics and semiconductors are strategically important areas. The increasing importance of intellectual property protection underscores that documentation, firmware, and production data are integral to a client’s competitive advantage.

Therefore, the decision to pursue nearshoring should not be based solely on the per-unit price, but rather on the total cost, risk assessment, and the partner’s ability to reliably manage the project. A well-planned transition can reduce communication overhead, increase predictability, and facilitate product development in subsequent versions.

Talk to Inventronics about nearshoring electronics production to Poland. We will assess your project stage, documentation, risks, NPI scope, and identify the safest path for transferring your production closer to the market.

The post Nearshoring Electronics Manufacturing to Poland appeared first on INVENTRONICS.

This is often the point at which many clients begin searching for an “electronics partner.” However, it quickly becomes apparent that the market uses a variety of terms: electronics design, PCB, prototyping, EMS, contract manufacturing, NPI, DFM, testing, final assembly, and box build. For a client simply looking to develop and manufacture a device, this terminology can be unnecessarily complex.

This article outlines the process from initial concept to finished electronic device, highlighting common risk areas, the information needed before engaging with a potential partner, and when it’s beneficial to seek out a team that integrates design and electronics manufacturing.

This article is intended for:

This material is intended for clients seeking a partner for a broader range of services beyond PCB assembly.

Typical Applications:

• You have an idea for a new device and need to assess its feasibility?
• You have a prototype, but you’re unsure if it can be manufactured repeatedly.
• You have an electronics project, but lack the necessary production documentation and testing procedures?
• Do you have a product currently manufactured manually or in small batches, and you’re looking to scale up to mass production?
• Are you experiencing issues with your current supplier and seeking to streamline your project?
• Do you want to consolidate your design and production processes with a single partner?
• We provide support for electronics design, enclosure development, testing, and production preparation.

If you recognize any of these scenarios, the cost of PCB assembly alone may be a limiting factor. First, it’s necessary to determine precisely what needs to be designed, verified, tested, and prepared for production.

What is your starting point, and what are the next steps?

Three common starting points:

Clients approach us with varying levels of project readiness. This is important because the initial stage of a project determines the scope of work, pricing structure, and technical risks involved.

You have an idea, but not a design?

This is the initial stage. The client knows the problem they want to solve, but they may not yet have a schematic, PCB layout, bill of materials, or prototype. Often, only a functional description, a housing sketch, client requirements, or a reference device exists.

In such cases, the initial step is not production, but rather a thorough analysis of needs, requirements, and feasibility. This involves defining the product’s intended application, target market, end-user, operating environment, power supply method, expected lifespan, service model, and production scale.

This information defines specific technical and regulatory requirements. The design approach differs significantly depending on the application, whether it’s a consumer device, an industrial telemetry module, a household appliance controller, or a product operating in harsh environmental conditions. It’s crucial to identify relevant standards, safety requirements, electromagnetic compatibility (EMC) regulations, radio communication protocols, or labeling requirements from the outset.

Without such analysis, a product may function technically but fail to meet market requirements, standards, or user expectations. This can lead to problems later in component costs, PCB modifications, enclosure design, testing, or production implementation.

The goal is to establish a clear direction: defining what we are designing, identifying constraints, and determining what needs to be validated through prototyping.

If a project is still in the conceptual phase, but the timeline or business risks are already critical, a preliminary qualification process is recommended. Inventronics conducts such assessments as part of product development and through the Rescue NPI 60 implementation support program. Rescue NPI 60

You have a prototype, but not a production-ready product.

A common scenario: the prototype functions, but it was built quickly, often manually or using readily available components at the time. While it serves a demonstration purpose, its suitability for mass production remains uncertain.

It’s easy to develop a false sense of security at this stage. While a working prototype demonstrates the feasibility of an idea, it doesn’t guarantee that the product can be manufactured repeatedly, tested, certified, and maintained.

At this stage, it is necessary to verify not only the device’s functionality but also its technological aspects: the PCB design’s resilience to production variations, enclosure compatibility, firmware programming methods, the availability of test points, the ability to detect critical errors before shipment, and compliance with relevant standards.

A prototype review should encompass four key areas: manufacturing, testing, compliance, and documentation. Only after such a comprehensive review can one determine whether process refinement is sufficient or if a design change is necessary.

Many elements often remain to be addressed before a solution is finalized, including production tooling, testers, adapters, programming procedures, quality control stations, assembly documentation, BOM variations, batch traceability, and acceptance criteria for the first production run.

The primary objective is to differentiate between functionalities proven in the prototype phase and those ready for repeatable production.

If a prototype is stuck between demonstration and implementation, a useful first step is an intervention assessment: a risk map, a 30/60/90 plan, and a decision on whether the project has a viable path to New Product Introduction (NPI), pilot production, or full-scale production. The following describes the scope of the Rescue NPI 60 service: Rescue NPI 60

You have a project, but need to streamline production.

The third scenario involves clients who possess documentation but experience difficulties with production, including high costs or reliance on numerous subcontractors. Challenges may arise from quality issues, component availability, inadequate testing, lengthy lead times, or a lack of comprehensive control over design changes.

Often, these issues stem from problems encountered in earlier stages. While a prototype may function correctly in a designer’s office, production launch can reveal technological, quality, or compliance challenges. This typically occurs when a design is developed without considering Design for Manufacturing (DFM), Design for Test (DFT), and Design for Assembly (DFA) principles.

In such projects, assembly times often exceed initial estimates, leading to increased labor costs, a higher incidence of defects, and difficulties in conducting testing. Furthermore, responsibility for quality becomes blurred between the design and production phases.

That’s why it’s worth considering a single-source design and manufacturing model. When the same entity assists with design, prepares the product for production, and then manufactures it, it’s easier to maintain consistency in technical decisions related to assembly, testing, costs, quality, and repeatability.

The process begins with a project and process audit. The partner should review the documentation, bill of materials, manufacturing files, test procedures, and historical issue logs. Only then can a decision be made regarding whether process improvements are sufficient or if design modifications are necessary.

This scenario is particularly important when transferring production or scaling up from small production runs to larger volumes.

If production has already begun but is experiencing delays, quality issues, supplier disputes, or compliance problems, this is a typical scenario for NPI intervention. In this mode, we first organize the input data, assess risks, review documentation, and develop a project stabilization plan. Rescue NPI 60

Why simply “manufacturing the PCB” is often insufficient.

In electronic devices, the PCB is a crucial component, but it rarely represents the entire product. A finished device typically includes firmware, power supply, sensors, communication modules, enclosure, wiring harnesses, connectors, labels, testing procedures, instructions, and quality requirements.

Therefore, the question “how much does it cost to produce a PCB?” often arises prematurely. More appropriate questions are:

• Is the project ready for production?
• Is the documentation complete?
• Can components be purchased directly?
• Does the product have scheduled testing?
• Is there a known method for detecting errors before shipment to the customer?
• Are the enclosure, mechanics, and electronics integrated and compatible?
• Can the same quality level be consistently maintained across subsequent production batches?

Companies that overlook these questions often save time initially, but frequently lose it later: in PCB revisions, component changes, final testing, warranty claims, or production ramp-up issues.

Below is a simplified, 7-step overview of our process. The detailed Inventronics process encompasses 16 stages: from system design and electronics development, through firmware, prototyping, certification, and production preparation, to mass production, logistics, and support. Inventronics product development process.

Phase 1: Defining product needs and requirements.

A successful product design doesn’t begin with a schematic. It starts with understanding the product’s intended function, the operating environment, and the value it will provide to the user.

At this stage, it is important to gather essential information:

• What functionalities should the device possess?
• who will be the end user,
• In what environment will the product operate?
• What are the dimensional, power, and cost limitations?
• Does the product require connectivity?
• Do you require a firmware update?
• Which standards, certifications, or customer requirements may be relevant?
• What is the anticipated production volume?

The more detailed the description of the problem and application, the easier it is for our design partners to select the optimal solution. Complete technical documentation is not always required. Initially, a clear description of the objective, operating conditions, and business expectations is sufficient.

Phase 2: Technical Concept and Device Architecture.

Once the requirements are finalized, we proceed to the technical design phase. This stage involves critical decisions that impact cost, lead time, risk, and subsequent production.

Typical decisions include:

• selection of key functional modules,
• selection of microcontrollers, communication modules, and sensors.
• Power supply method:
• Firmware specifications:
• method of updating and diagnostics,
• Preliminary selection of enclosure or mechanical requirements.
• testing strategy,
• Batch and product version traceability level.

This stage is crucial because architectural modifications are inexpensive as long as they remain theoretical. Once the PCB, enclosures, and prototypes are manufactured, each subsequent change becomes significantly more costly.

In practice, a good partner should be able to say not only “it’s possible,” but also “it’s possible, but it will increase testing costs,” “this component has a risk of availability,” “this enclosure will complicate assembly,” or “this interface requires additional validation.

Phase 3: Electronics design, PCB layout, and documentation.

Once a concept is approved, the actual electronics design phase begins. This includes schematic design, component selection, PCB layout, mechanical constraint analysis, and the preparation of documentation required for prototype fabrication.

At this stage, the following are produced, among other things:

• electrical schematic,
• Component list.
• PCB design,
• production files,
• Assembly requirements:
• Preliminary test documentation.
• Data required for component procurement.

From the outset, design should consider not only functionality but also manufacturability and testing. This includes incorporating space for test points, ensuring component availability, planning firmware programming procedures, enabling optical inspection, and accounting for assembly limitations.

When a design is created without considering manufacturing, problems often arise later: insufficient clearances, difficult access to test points, components that are unavailable for purchase, unclear Bill of Materials (BOM) variations, or a lack of clear assembly instructions.

Phase 4: Prototype and Initial Validation.

The prototype is not yet a product ready for sale. It is a tool for validating design assumptions.

In the prototype phase, we verify:

• Does the electronics meet the specified requirements?
• Does the firmware communicate correctly with the hardware?
• Is the power supply stable?
• Does the device fit within the enclosure?
• Are the primary functions testable?
• Are there any potential thermal, mechanical, or communication issues?
• Verify that the component costs align with the initial projections.

At this stage, revisions are natural. This is not a project failure, but rather a part of the process. It is important that all revisions are documented, and that decisions have clear ownership. Otherwise, it is easy to lose track of the reasons behind a particular change and its impact on the product.

A well-executed prototype should lead to clear decisions regarding what needs improvement, what can remain as is, what requires further testing, and what is ready to proceed to the next stage.

Phase 5: Preparation for Mass Production.

Transitioning from prototype to mass production is a distinct phase. In the industry, this is often referred to as NPI, or New Product Introduction. However, what matters most to the client is the outcome: ensuring the product can be repeatedly manufactured, tested, and delivered.

At this stage, it is necessary to organize:

• the final list of components,
• Product variants:
• assembly documentation,
• firmware programming procedures,
• testing procedures,
• Quality acceptance criteria.
• Packaging method:
• Batch traceability and serial number identification.
• post-production change management.

Here, the distinction between a prototype and a finalized product often becomes apparent. While a prototype may function, production demands repeatability. If each unit requires manual adjustments, additional interpretation, or engineering decisions, the process is not yet ready for scaling.

Step 6: Integration into the final device.

A populated PCB is often just one component of the final product. It typically requires integration with enclosures, wiring harnesses, connectors, mechanical components, software, labeling, final testing, and packaging.

In the industry, this process is often referred to as final assembly or box build. The client does not need to understand these terms. What is important is that someone takes responsibility for integrating the electronics with the rest of the device.

This stage may include:

• PCB assembly in enclosures.
• connection to harnesses and connectors,
• Assembly of mechanical components,
• programming or configuration of the device.
• Final testing.
• visual inspection,
• labeling,
• Packaging.
• Preparing for shipment.

If the client requires a complete device, rather than just a printed circuit board, this aspect must be planned in advance. Otherwise, the final assembly process becomes a series of improvisations.

Phase 7: Testing and Quality Control.

Testing is not an afterthought; it is an integral part of the product development process.

It is essential to define what will be tested, how frequently, using which tools, and according to what criteria. Testing procedures differ for prototype testing, initial production run testing, and final inspection before shipment.

The testing strategy may include:

• optical inspection of assembly processes,
• electrical testing,
• functional testing,
• firmware programming and verification.
• Communication test.
• Power supply test.
• configuration control,
• Final testing of the finished device.

The most crucial question is: what defects must be detected before shipment to the customer? The answer to this question determines the testing procedure.

Without testing, production may appear satisfactory on the surface. However, problems often manifest only at the customer’s end, where the cost of repair is significantly higher than the cost of identifying the error during the manufacturing process.

What do production and testing technologies entail?

In practice, the production of electronic devices may involve SMT assembly for surface-mount components, THT assembly for selected connectors or through-hole components, AOI inspection, ICT testing, FCT testing, and final device testing. Clients do not need to understand the details of each technology. It is important that the partner can select the appropriate scope of production and quality control based on the product’s risk profile, volume, industry requirements, and the potential consequences of failure.

How do the 7 steps outlined in the article map to the Inventronics process?

On the Inventronics website, the product development process is described in 16 stages. In this article, we consolidate these into 7 broader blocks, as clients typically do not require a complete operational overview at the outset. Instead, they need to understand the current status of their project and the next logical step.

Further stages, such as logistics, warehousing, distribution, and after-sales support, are particularly important when the device is to be produced in cycles or requires servicing.

You can find the complete list of stages here: Inventronics product development process.

What are the most common risks that prevent a project from moving to production?

Often, it’s not a single major issue that causes problems, but rather the accumulation of minor deficiencies.

Typical Risks:

• incomplete project documentation,
• List of components without suggested alternatives.
• Components that are difficult to obtain or pose a procurement risk.
• No test procedure available.
• No test points are available on the PCB.
• The enclosure is not compatible with the electronics.
• Firmware not yet prepared for production programming.
• Lack of version traceability.
• Changes implemented without a decision history.
• Unclear division of responsibility between project management, procurement, production, and quality control.

These issues can be minimized if a design and manufacturing partner is involved early in the process. The later the manufacturing team sees the design, the less opportunity there is to make improvements without incurring costly changes.

When is it beneficial to seek a single partner for project and production?

Not every project requires a single partner for the entire process. However, when a product is intended for mass production, a single design and manufacturing partner can minimize handoffs, misunderstandings, and gaps in responsibility.

This is particularly important when:

• The product is new and requires further technical refinement.
• The project will be developed iteratively.
• The electronics must be compatible with the enclosure and mechanical design.
• Final testing is required.
• The product features firmware or communication capabilities.
• Traceability of versions and batches is crucial.
• Repeat production is planned.
• The client seeks to minimize risk during the transition from prototype to mass production.

Having a single partner doesn’t automatically guarantee simplicity. However, it does mean that design, testing, and production can be planned as a unified process, rather than as separate stages passed between different companies.

What should be the outcome of the initial phase?

The initial technical discussion doesn’t always result in a complete offer for mass production. Often, it’s premature to do so. If the project details are not yet fully defined, a roadmap outlining the next steps is a more honest and valuable outcome for the first phase.

This map should answer the following questions:

• What is the current status of the product?
• Identify what is missing for prototyping or production.
• Which areas pose the greatest risk?
• What decisions need to be made before obtaining a quotation?
• What documents are required?
• What can be done in parallel?
• What is the most logical and efficient next step?

For our clients, this is crucial because it avoids seemingly attractive but inaccurate pricing. If the scope of work is unclear, the price will also be uncertain. In practice, it’s better to start with a brief analysis phase rather than later incurring costs for revisions resulting from incorrect assumptions.

The initial phase may result in a technical concept, a risk assessment, a prototype scope definition, a preliminary architecture, a list of required data, or a project readiness plan for production.

When is a project ready for a meaningful quotation?

Customers frequently require a quick understanding of the unit cost of a product. This is understandable, as pricing information is essential for business decisions. However, providing an accurate price estimate requires a clearly defined scope of work.

The project can be accurately priced when the following information is available:

• What is the function of the device?
• What are the technical and environmental requirements?
• Which components are critical?
• Do you have an existing PCB design, or does it need to be developed?
• Do you require firmware?
• Does the product include a housing and mechanical components?
• What should the final testing process look like?
• What is the planned quantity?
• Whether the client requires a prototype, a pilot production run, or full-scale production.

Without this data, the offer will be based on assumptions. While this may be sufficient for an initial assessment, it is not adequate for responsible production planning.

Therefore, a reliable partner should clearly differentiate between three levels of pricing: an initial estimate, a project design quotation, and a production quotation following documentation finalization.

Minimum Technical Package Required Before Production.

Before a product enters production, it should have a defined technical package. This isn’t about bureaucracy; it’s about ensuring consistent manufacturing processes and enabling the identification and analysis of any errors.

The minimum package typically includes:

• current schematic or project description,
• PCB files and production data.
• a list of components with variations and alternatives,
• Firmware version description.
• programming or configuration instructions,
• Final test description.
• Quality acceptance criteria.
• assembly documentation,
• Housing and packaging requirements.
• Traceability guidelines for batch and version identification.

What is the process for transitioning from the initial production run to repeatable, high-volume manufacturing?

The initial production run serves not only to deliver the first units but also to validate the manufacturing process.

In the initial series, it is important to verify:

• Is the documentation clear and understandable for production purposes?
• Are the components arriving as planned?
• Does the assembly process require improvisation?
• Does the test detect the most critical errors?
• What is the programming and configuration time required?
• What challenges arise during enclosure design?
• Are the packaging and labeling processes consistent and standardized?
• What are the actual operating times?

Following the initial production run, a concise review should be conducted to identify what is functioning correctly, areas for improvement, necessary clarifications in the documentation, and changes to be implemented before the next production batch.

This is a crucial step that should not be skipped. Proceeding directly to large-scale production without validating the process can result in more costly and difficult-to-resolve errors.

How Inventronics Can Help.

Inventronics can support clients throughout the entire product lifecycle, from initial design to production. Our services include electronic device design, documentation preparation, prototyping, testing, New Product Introduction (NPI), and electronic device manufacturing in production runs.

The discussion may cover the following topics:

• analysis of an idea or an existing prototype,
• Electronic design or design support.
• component selection and documentation preparation.
• PCB preparation for assembly.
• Project review for manufacturability and testing.
• Prototype development and testing.
• NPI preparation,
• electronics assembly,
• Firmware programming or version control, if included in the scope of services.
• Production and final testing.
• integration of electronics with enclosures or modules.
• quality and production documentation,
• Traceability of batches, versions, and test results.

The greatest value is realized when Inventronics can become involved in a project before the documentation is finalized. This allows for easier design of a product that is not only functional, but also manufacturable, testable, and maintainable.

What to prepare for your first meeting.

You don’t need a complete project design. However, it’s beneficial to provide information that allows for a quick assessment of the scope and potential risks.

Before the consultation, it’s beneficial to gather five groups of information, aligning with the initial project analysis process used by Inventronics.

1. Description of the concept and applications.
   Describe the product concept, its intended application, key features, and the problem it is designed to solve. It is important to specify the operating environment and highlight the most important features for the user.

2. Technical and regulatory requirements.
   Gather information regarding power supply, communication protocols, firmware, enclosure, dimensions, assembly, technical limitations, and required standards, certifications, or regulations. If the product is intended for a specific industry, it is advisable to identify relevant quality or regulatory requirements from the outset.

3. Market, target user, and production scale.
   Determine the intended end-user, the target market, and the anticipated production scale (prototypes, initial production run, or full-scale production). This information influences the selection of technical solutions, testing procedures, documentation requirements, and the overall production preparation process.

4. Input materials, prototypes, and reference samples.
   If you have sketches, photos, models, schematics, a bill of materials, an existing prototype, or examples of similar products, please provide them. These materials help us quickly understand your requirements and reduce the number of assumptions.

5. Budget, timeline, and key risks.
   Please provide an estimated budget, desired timeline, and any major concerns you may have, such as: cost, lead time, component availability, testing requirements, quality standards, certification needs, potential production transfer challenges, or issues with your current supplier.

What constitutes a successful sales conversation?

A successful sales conversation doesn’t begin with simply quoting a per-unit price. First, it’s crucial to determine whether the client requires design services, prototyping, production preparation, assembly, testing, or a more comprehensive support package from concept to series production.

In practice, the discussion should cover several key areas:

• What problem does this product solve?
• What is the current status of the documentation?
• what has already been tested,
• Which components are confirmed, and which are still under consideration?
• What is the planned production volume?
• What are the quality and delivery requirements?
• What the client chooses to entrust to the partner, and what remains within the client’s control.

This collaborative approach allows us to clearly define the project phases: analysis, design, prototyping, production preparation, initial production run, and ongoing production. This ensures that each decision has a specific objective, associated cost, and defined completion criteria.

How to identify a reliable partner.

A good partner doesn’t start with just the assembly price. They first inquire about the product, project stage, requirements, testing, and planned production scale.

Consider the following when evaluating a potential partner:

• We understand the difference between prototyping and mass production.
• Inquiries regarding testing procedures and quality criteria are welcome.
• It can identify risks within documentation.
• discusses component availability,
• We offer a structured New Product Introduction (NPI) process.
• It is compatible with various product versions.
• We understand the importance of firmware in manufacturing.
• It can integrate electronics with mechanics and final testing.
• It clearly defines the scope of services, outlining what is included and what is excluded.

If the conversation focuses solely on the unit price, without discussing testing, documentation, and risk assessment, it’s a warning sign. The unit price is important, but only after clearly defining the product specifications and quality control procedures.

Common customer mistakes at the project’s outset.

A common mistake is initiating discussions too late in the project lifecycle, after the design is “locked,” but before a production feasibility assessment has been conducted.

Other common errors include:

• Lack of a clear product application description.
• underestimating the importance of testing,
• Selecting components without verifying availability.
• Treating a prototype as a production-ready design.
• No firmware or update plan available.
• No decision has been made regarding responsibility for documentation.
• omitting enclosure and final assembly,
• No acceptance criteria were defined for the initial production run.

Frequently Asked Questions.

Summary:

The journey from initial concept to a finished electronic device involves more than just designing and assembling a circuit board. It’s a comprehensive process that integrates user requirements, electronics architecture, firmware, PCB design, component selection, enclosure design, testing, documentation, manufacturing, and quality control.

Integrating design and manufacturing considerations early in the process minimizes the risk of costly changes later on. A reliable partner will not only manufacture your device but also prepare it for repeatable production, testing, and future development.

If you have an idea, prototype, or product requiring preparation for mass production, begin with a technical consultation. Together, we can assess the project’s stage, identify potential risks, review documentation, and determine the most efficient path to a finished product.

Contact Inventronics to discuss the design and manufacturing of your electronic device. We will provide an initial process overview, covering everything from concept or prototype development, through design and testing, to series production.

The post From Idea to Electronic Device 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.