For many hardware projects, certification appears at the very end of the development process.

The product is designed. The prototype works. Firmware is stable. The enclosure is ready. Manufacturing is being planned.

And then comes the question: “Is the product ready for certification?”

This is often when engineering teams discover that compliance is not simply a final testing procedure. It can influence the hardware architecture, PCB layout, RF design, power supply, enclosure, firmware, cybersecurity, component selection, and documentation.

For connected products, certification should therefore not be treated as the last step.

It should be one of the design inputs from day one.

The cost of “we’ll certify it later”

A common approach to hardware development looks simple:

• Design the product.
• Build a prototype.
• Make it work.
• Send it to a laboratory.
• Fix whatever fails.

The problem is that step five can become very expensive.

Imagine an IoT device failing EMC testing because of unwanted emissions. The solution may require changes to the PCB layout, grounding, power supply, filtering, clock configuration, antenna placement, shielding, or even the enclosure.

If the PCB design is already frozen and production tooling has been ordered, a relatively small compliance issue can turn into a complete hardware redesign – resulting in new prototypes, additional testing, higher costs, and delays.

The same applies to wireless performance. A device can work perfectly on a development board and behave differently once the final antenna, PCB, power supply, and enclosure are introduced.

Certification problems are often architecture problems discovered too late.

Compliance starts with product definition

The first certification question should not be: “Which laboratory should we use?”

It should be: “What are we building, how will it be used, where will it work, who is it for, and on which market do we want to sell it?”

The answers affect the entire engineering process.

An IoT device using Bluetooth may have different requirements from an industrial product using proprietary sub-GHz communication. A connected device processing personal data introduces additional security and privacy considerations. Products designed for medical, industrial, automotive, or safety-critical environments will require additional standards, documentation, and verification. The target market matters too. That is why compliance should be considered during the requirements and architecture phase, before the first production-oriented PCB is designed.

Certification influences architecture

Compliance requirements translate directly into engineering decisions.

Consider a typical connected hardware architecture:

Sensors → MCU → Wireless SoC → Power Management → Antenna → Cloud

Every layer can influence the final compliance result.

Hardware

• Component selection affects emissions, immunity, power integrity, thermal performance, safety and reliability.
• PCB layout influences high-frequency behavior, noise, grounding, and signal integrity.
• The power supply can become a source of unwanted emissions or introduce other system-level risks.
• The antenna, RF matching network, and enclosure directly affect wireless performance.
• Mechanical construction and materials can influence both safety and electromagnetic performance.

Firmware

• Firmware can influence radio behavior, clock configuration, communication patterns, power consumption, diagnostics, and overall system performance.
• It should also support efficient testing and diagnostics. If critical RF or system parameters are difficult to configure, troubleshooting a failed test can take considerably longer.

Cybersecurity

For modern IoT products, compliance increasingly goes beyond EMC and radio performance.

For certain categories of radio equipment in the EU, cybersecurity requirements under the Radio Equipment Directive have applied since August 1, 2025. They address areas including network protection, personal data and privacy, and protection against fraud.

This changes the engineering question from:

“Can we add security before launch?”

to:

“Was security considered when the product architecture was designed?”

For connected products, that distinction is critical.

Safety is not an afterthought

One of the most important lessons in hardware development is that safety requirements need to be defined together with the product’s intended use. It is not enough to ask whether the electronics work correctly.

The engineering team also needs to understand:

• What happens if a component fails?
• What happens if communication is interrupted?
• What happens if the device receives unexpected input?
• What happens during a power failure?
• What happens if the user operates the product incorrectly?
• What risks exist in the environment where the product will operate?
• Which safety standards apply to the intended market and application?

These questions can influence the architecture before the first prototype is built.

A product developed without this analysis may reach a late stage where EMC results are acceptable, but additional safety requirements reveal that the architecture, documentation, or verification approach needs to change.

That is precisely why the market and intended use of the product must be part of the initial engineering definition.

A Real-World Example: Medical Lighting Control Unit

The principle becomes clearer when we look at a real engineering project.

For a leading medical equipment manufacturer, we developed a specialized electronic control unit for surgical lighting. The device had to provide specific functionality while fitting into the client’s existing enclosure design and meeting demanding medical requirements.

The project required more than designing a PCB that simply worked.

Compliance Shaped the Engineering Process

We developed a custom PCB for a battery-powered control unit, engineered around the mechanical constraints of the existing enclosure.

Our team also supported the preparation of technical documentation and provided engineering consultancy throughout the testing process. The goal was to ensure that the hardware design was aligned with the requirements for final medical certification.

This is an important distinction.

Compliance was not treated as something that would be checked only after the hardware was complete. It was considered throughout the engineering process, from hardware design through testing and documentation.

Testability Was Designed Into the Product

The project also included the development of a dedicated production tester and a custom Product Update/Service Tool. These tools supported quality control, maintenance, and future product updates. This meant that testability and serviceability were not left until after development. They were considered as part of the overall product design.

Compliance Beyond the First Certification

The engineering work also continued beyond the initial certification process.

As components became unavailable, we managed component phase-outs and implemented validated hardware modifications to maintain production without unnecessary disruption.

The project therefore illustrates a broader principle:

Compliance is not a test performed at the end of development. It is an engineering consideration that can influence architecture, hardware design, testing, documentation, production, and lifecycle management.

This is where design for testability becomes particularly important.

Design for testability

A strong compliance-oriented design process is not only about making the product work. It is also about making the product easy to validate.

Useful design features may include:

• accessible test points,
• diagnostic interfaces,
• production test modes,
• configurable communication parameters,
• firmware logging,
• automated hardware tests,
• controlled RF configurations,
• clear hardware revision identification.

These features may be invisible to the end user, but they can significantly reduce engineering and manufacturing effort.

The principle is simple:

Testability should be designed into the product, not added at the end.

Prototype ≠ production product

Development teams often use evaluation boards, temporary antennas, external power supplies, prototype enclosures, and development firmware. That is perfectly normal during early R&D. The problem comes when test results from such a setup are treated as representative of the final product.

For example:

Development setup

MCU + RF evaluation module + external antenna + laboratory power supply

may behave very differently from:

Production setup

MCU + integrated RF design + PCB antenna + switching regulator + final enclosure.

The closer the test configuration is to the final production design, the more useful and reliable the results become. This is particularly important for compliance.

A prototype can demonstrate that the concept works. It cannot automatically demonstrate that the final product will satisfy all applicable requirements.

A better R&D workflow

A certification-oriented development process can be structured around five stages:

01 – Regulatory and technical analysis

Define target markets, intended use, applicable regulations and standards, product classification, radio technologies, safety requirements, cybersecurity expectations, documentation requirements, verification and testing needs.

The result should be a technical compliance strategy, not simply a list of regulations.

02 – Architecture

Translate compliance requirements into engineering decisions covering: wireless modules, antennas, power architecture, processors, interfaces, firmware, security, safety mechanisms, enclosure design, diagnostic and testing capabilities.

At this stage, compliance becomes part of the product architecture. 

03 – Early risk reduction

Use engineering prototypes to investigate areas most likely to cause problems: RF performance, EMC, power integrity, thermal behavior, communication reliability, safety-related functions, and critical firmware functions.

The goal is not to certify the product early. The goal is to remove expensive unknowns early.

04 – Pre-compliance testing

Before formal certification, perform targeted tests to identify potential issues while the design can still be changed relatively easily.

Finding an EMC problem while the PCB is still being developed is very different from finding it after production tooling has been ordered.

The same principle applies to safety.

Identifying an architectural safety issue during the design stage gives the engineering team options. Discovering it after the product has been finalized may require substantial redesign, additional documentation, repeated verification, and new testing.

05 – Formal certification

Formal testing should confirm an already mature engineering design rather than dictate major design changes.

That is the difference between treating certification as a development input and treating it as a final exam.

Compliance is a lifecycle issue

Certification does not necessarily end the engineering responsibility.

Hardware products evolve. Components become obsolete. Firmware changes. Suppliers change. PCB revisions are introduced. Products enter new markets.

A seemingly minor change can potentially affect the compliance status of the product.

A mature R&D process should therefore consider questions such as:

• Can the wireless module be replaced without redesigning the entire system?
• What happens if a firmware update changes radio behavior?
• Which hardware changes require additional validation?
• Can a component substitution affect safety or compliance? 
• Can the device support secure updates throughout its lifecycle?
• What documentation needs to be maintained after certification? 
• How will product changes be assessed before release? 

Compliance is therefore not only about obtaining a certificate. 

It is about developing a product that can remain compliant as it evolves.

Compliance as an engineering advantage

Designing for compliance from the beginning is not only about avoiding regulatory problems. It can lead to a better engineered product. A development process that considers EMC, RF performance, cybersecurity, safety, testability, and lifecycle management from the start tends to produce products that are easier to validate, manufacture, maintain, and scale. It also gives engineering teams greater control over risk. 

Instead of discovering fundamental problems at the end of development, teams can identify and address them while design decisions are still flexible.

The goal should not be to design a product that barely passes certification testing.

The goal is to create an architecture where compliance becomes a natural result of good engineering.

The real question

For an experienced R&D team, certification should not be a final yes-or-no question.

The more important questions are:

“Did we define the product correctly?”

“Did we understand how and where it would be used?”

“Did we identify the applicable safety and compliance requirements early enough?”

And finally:

“Did we make the right engineering decisions before the design became difficult and expensive to change?”

If the answer is yes, certification becomes a controlled part of the product lifecycle.

If the answer is no, certification may expose architectural problems at the most expensive possible moment.

At IN R&D, we treat compliance as part of the engineering process – starting with analysis and architecture and continuing through hardware, firmware, safety, validation, certification, and deployment. 

Our approach follows the complete product lifecycle: from understanding the requirements and designing the architecture to development, compliance, scale-up, and long-term support. 

Because the best time to think about certification is not when the prototype is finished. 

It is when the product is still an idea.