How to Make Embedded Systems and IoT Products CRA-Compliant: A Practical Roadmap

The hack at Odido in March 2026 once again highlights the importance of cybersecurity for businesses. In addition to the material damage, which is estimated to run into the millions, the reputational damage to Odido is incalculable.

This could happen to your company too, warn Bram Blaauwendraad and Gaurav Raina of the cybersecurity consulting company Veritas. FHI spoke with both security experts about what companies can do now to get their cybersecurity in order and to become compliant with the Cyber Resilience Act (CRA) in time.

The CRA aims to enhance the cybersecurity of digital products and services within the European Union. Bram and Gaurav will deliver a keynote on this new law during the D&E event on April 14 in Den Bosch. They will focus on its practical application in the business world, drawing on their experience with RED 3.3, the European directive governing the security of radio equipment.

Ecosystems

As a Senior Security Consultant & Service Lead, Gaurav is well-versed in RED 3.3. and uses that knowledge to address the uncertainties surrounding the CRA. “You can think of RED 3.3 as a narrower precursor to the CRA,” Gaurav explains. “While RED focuses mainly on radio equipment, the CRA covers entire ecosystems: devices, software, backend systems, and their interactions. How do you ensure devices communicate securely with each other , even in critical environments? And how do you test devices, apps, and backends responsibly?”

Act Now

“The full CRA obligations for placing new products on the EU market apply from 11 December 2027but the advice is to start preparing now. Not just because it’s ‘nice’ to be compliant, but also to prevent business damage like what recently happened at Odido,” the security specialist continues.  He gives another example: “In 2021, an unauthenticated reset flaw in Western Digital’s My Book Live led to mass remote wipes of internet‑exposed devices – a lesson in defining support periods, securing default configurations, and executing post‑market vulnerability handling, all of which the CRA now makes mandatory (with reporting from 11 Sep 2026).” The examples underline the social relevance of the CRA. “Companies are willing to act but often lack clear guidance. And that’s exactly what Bram and I want to provide during our presentation at the D&E event.”

Understanding CRA Standards

A major challenge for industry and Bureau Veritas is the fact that the technical standards have not yet been formally harmonized. Gaurav: “The CRA works with two types of standards: horizontal and vertical. Horizontal standards are broadly applicable and focus on general principles of cybersecurity. Vertical standards are specific to certain sectors or industries and take into account the unique characteristics and risks associated with them, such as additional rules for healthcare or industrial control systems. The standards are still under development, but the CRA’s legal text has already been finalized. That text forms the basis for our advice.”

The uncertainty surrounding the harmonization of the standards is frustrating, but according to Gaurav, the biggest challenge lies in the supply chain. “CRA assigns manufacturer responsibilities but requires end‑to‑end assurance across the supply chain. Practically, that means you can’t be compliant if your suppliers aren’t. So as a business owner, you must not only consider your own company but also the compliance of your suppliers. On top of that, it’s not always clear where the responsibilities lie.”

Secure By Design

Gaurav’s colleague Bram, who works as a Senior Security Consultant, joins the conversation. “Engineers need clear advice: how do we tackle this? We address this by developing practical documentation for our clients. For example, one CRA requirement is that every product must be ‘secure by design’ at its core. Secure by design means integrating security from the start, for example by performing threat modeling, enforcing secure coding practices, and validating designs through testing. We’ve written a plan that explains, step by step, how to create such a secure design and what a company needs to take into account.”

Bram continues: “It’s important that engineers can easily work with the guidelines and that they’re part of the normal workflow. Think of tips and checks that automatically appear in IDEs, pipelines, and templates. Organizations that handle this well become CRA-compliant much faster than those that rely solely on policy.”

Practical Examples

The CRA permeates the entire development process, according to Gaurav and Bram. That’s why it’s crucial to conduct a risk analysis in advance and document everything for the CRA. Bram gives an example: “Suppose a company delivers complete solutions consisting of multiple components. The risk then lies primarily in the connection between the components. Another common example in practice is a customer wanting to deviate from the standard architecture (engineering to order). In such a case, I consider three aspects: what exactly is changing, what is the risk involved, and who is responsible for it. For the CRA, it is especially important that the process is clear and traceable.”

Collaboration

“Compliance requires collaboration and commitment from all levels of the organization: from the engineer soldering components onto a circuit board to the CEO,” Bram concludes. “It is often necessary to draft new policies or agree on different procedures. That is why it is important that everyone is on the same page. Organizations that integrate security into their development processes now will not only meet CRA requirements faster, they will also reduce risk and build more resilient products,” Bram concludes.

Interested in learning more? Join the D&E event on April 14 in Den Bosch.