The EU Cyber Resilience Act (CRA) is the most widely applicable cybersecurity regulation to impact smart products in recent years. While awareness of the regulation continues to grow, many organizations are still trying to understand what compliance looks like in practice — and how to translate regulatory requirements into operational readiness.
During a recent panel discussion, CRA experts Mena Roumbakis, Product Engineer at STMicroelectronics, and Eystein Måløy Stenberg, CTO of Northern.tech, discussed what the regulation means in practice and what organizations should be doing now to prepare. Covering everything from hardware design to field software maintenance, the conversation explored some of the most common questions organizations are asking today.
Does CRA apply to our products? How do we handle vulnerability management? What does documentation need to look like? And what does it really take to maintain IoT products over time? The panelists discussed commonly asked questions like these, and more in the full webinar.
These are the key questions discussed during the session, along with insights from both experts.
Q: Many organizations assume CRA doesn't apply to them. Who does it actually apply to, and why should connected product teams pay attention?
Mena Roumbakis, STMicroelectronics: CRA is important for anybody who ships products into Europe to pay attention to. It's not just European companies. Even customers in the US, if you're shipping any sort of electronics into the EU, you need to be paying attention to the CRA.
The CRA has already started, and we’re in the midst of it now. Full implementation will be in 2027. Customers who ship products into Europe need to pay attention today. It's not something we need to look at in the future; rather, we need to focus on it today. As far as development goes, it's something organizations probably should have been looking at yesterday.
Eystein Stenberg, Northern.tech: The law talks about a product with digital elements. Basically, it is any hardware or software that is connected to a network and transmits data. All IoT products fit into this definition; by nature, they send and receive data. The product also doesn't need to be connected to the internet. The regulation simply requires that the product transmit or store data. It's a very broad definition, and it applies to all products sold to the EU.
Q: Considering how broad the regulation is, where are organizations facing the most challenges when it comes to actually meeting CRA requirements?
Mena Roumbakis, STMicroelectronics: From our perspective, starting early is one of the best things one can do. It's security by design from beginning to end. It needs to be implemented from a product development point of view.
There's an analogy I like to use: consider the challenge of releasing a product, and three years down the road, a known vulnerability comes out. How do you fix it?
Traditional automotive manufacturers issue factory updates. If there's a recall on your vehicle, you take it to an authorized mechanic who patches and updates it. Then, Tesla came around and pushed updates remotely. That is where the infrastructure and capabilities need to be.
Physical access to the device might be a challenge. It's important to note that it's not just internet-connected devices. Even if the device is on your own closed network, it still needs to be CRA compliant. The idea is that devices that talk to other devices act in a good manner.
Eystein Stenberg, Northern.tech: Many of our existing customers are already very aware of security requirements, they're complying with other standards and regulations, and part of the reason they use Mender is exactly vulnerability management. Those that already have a security process in place, it's not such a big lift to also comply with CRA. If you look at the fundamentals, CRA is really just basic security: have a security process in place, document how you're doing it, do vulnerability management, and have a way to update the products. In simple terms, it boils down to: identify, remediate, and disclose. It doesn't prescribe how you update, but over-the-air updates is an efficient way to do it.
The harder cases come down to product and fleet complexity — very heterogeneous environments, many operating systems, many different kinds of products. Those situations are harder to manage and need a more mature, more generic device management solution.
Q: If you're trying to prepare for CRA today, where should you start?
Mena Roumbakis, STMicroelectronics: Starting early is best, it's the full development lifecycle. Documentation is key. Documenting and tracking the software you're using through a machine-readable software bill of materials (SBOM)is a big piece of it. Starting early will accelerate your timeline and make implementation easier. If you have a completed product and have to shoehorn security in after the fact, it's likely either going to be more difficult or too late.
In addition to that: track your software, implement secure boot, have an update path. Those three pieces get you a long way toward CRA compliance. If a CVE becomes known, you have a path to update the device rather than go through more costly updates or, even worse, get fined.
Eystein Stenberg, Northern.tech: Focus on what's on the device. You can always improve vulnerability detection processes after the fact, but you cannot change the hardware of shipped devices. You cannot easily integrate an OTA update solution when you already have devices in the field. This is almost impossible in our decade of experience with OTA updates.
The two most important things to figure out are what the requirements are, and what processes you have in place already. Then you can see what gaps you need to fill. A key part of CRA is that you document these processes. If you get audited, you need to keep that documentation. What are you doing to detect vulnerabilities? How frequently are you doing it? How do you notify customers when there is a vulnerability? How do you provide the update? All of this needs to be documented.
One finding from Northern.tech's 2026 State of Industrial IoT Device Lifecycle Management Report worth noting: 3 out of 5 organizations expect their current device management infrastructure to be inadequate within three years. If you're there, it's also time to evaluate whether you need a broader or more capable device management or OTA solution, because it needs to work for more than three years in order to comply with CRA.
Q: What is the one piece of advice you would give every product or engineering lead related to CRA?
Mena Roumbakis, STMicroelectronics: Think about security on day one, not as an afterthought once the product is complete. It'll make it easier in terms of the time cycle to get to release, especially if you're starting a new development cycle. Start documenting along the way. You can't just complete the product, put it on the shelves, and not have to think about it again. What does product security look like through the usage? And once it's taken out of the field? You must make sure that the product is available and functioning as intended, securely, and for the full product lifecycle.
Eystein Stenberg, Northern.tech: Start with documentation. Make sure you have a process in place, and you can always adjust it later. It won't be perfect, but even if you have something and you get audited, at least you have something to show for it. If you do not have documentation nor processes and you get audited, you're in a completely different category.
And it's worth remembering, this also gives you new opportunities. When you have the ability to update, change, and improve products in the field, you get competitive advantages down the line, brand recognition, and less brand risk. Begin with the documentation, and just start somewhere.
Featured Panelists
Mena Roumbakis is a Technical Marketing Engineer at STMicroelectronics with a focus on MPU products and Security for the STM32 ecosystem in the Americas. With over 20 years of experience in embedded systems and connected device design, Mena is committed to helping engineers find the best design solutions across microcontrollers, DSPs, and processors.
Eystein Stenberg is the CTO of NorthernTech, a leader in device lifecycle management, and the creator of Mender, the market-leading solution for robust, secure, and customizable over-the-air (OTA) software updates. With over 15 years of experience in security and systems management, Stenberg has served on the frontlines of some of the largest production environments and possesses in-depth knowledge on solving real-world system security challenges. An expert in embedded system security and IoT device management, Stenberg routinely shares his insights at industry technology conferences and other sector-focused events like automotive.
Learn more about Cyber Resilience Act (CRA)
The CRA applies horizontally to all products with digital elements (PDEs) available for sale in the European Union and is the first of its kind to require mandatory compliance. Penalties for noncompliance reach €15 million or 2.5% of global annual turnover, whichever is greater, and carry the risk of losing the CE mark required to sell in Europe.
More resources:
