As the Cyber Resilience Act (CRA) deadline quickly approaches, manufacturers selling connected products in the European Union face growing uncertainty and potential sales disruptions, while navigating evolving compliance requirements. What are the requirements of the CRA? Who do they apply to? What is the timeline, and how can you achieve compliance in time?
In this 1-hour pre-recorded webinar, experts from NXP and Digi International share how businesses can cut through the complexity and create a clear, actionable path to CRA compliance without halting progress in EU. Learn more in our CRA white paper.
Connect with Digi
Want to learn more about how Digi can help you? Here are some next steps:
Follow-up Webinar Q&A:
Moderator: Andrew Delaney Program Director at Finelight Media
Presenters:
- Carlos Serratos, IoT certification expert at NXP Semiconductor
- Ron Singh, Senior Director, OEM Solutions at Digi International.
What would the CRA level of criticality be for products that are sub-components of critical products, but are in principle product-agnostic? Where would such IP fall under any of the product categories of CRA?
Carlos: One of the things that the CRA does is to address the proportionality to the risk. If you have an application, because I get this question a lot from customers, when they ask me, "Do I need to use a secure element in all my products?" or, "Do I need to have tamper resistance in every product?" My answer is, "It depends." Because that's what the CRA says. The CRA says that, depending on the use case, you need to implement the mitigations which are proportional to the risk.
Okay, so, that's one part of the answer. Now, you may have a product in the critical category, but that doesn't imply that you need to use critical components. Your component, it's in the category according to the CRA, and then there is a very clear guidance from the Commission. They say, if you have a component, okay, you have a component, you go to the Annex 3 and Annex 4, and you look into the Class I, you look into the Class II, and Critical products. If you are not listed in any of those categories, then you're in the default category. So that means, if you have, for example, an operating system that is in Class I, if you have an operating system which is Class I, and this operating system goes into a product that's Critical category, still, operating systems are Class I. It doesn't mean that because it's in a Critical product, needs to move into Critical category. Okay? They are independent. And the other way around. You may have a secure element that is Critical category, and you put in a product that is in the Class I. The Class I product doesn't change, because now you have a critical component inside this Class I. Just look at them as independent elements, independent products.
How do we obtain more information? Will the slide deck be available?
Ron: We can absolutely make it available as a PDF to everybody that's attended. Certainly, people could contact me directly at ronald.singh@digi.com. Or you can find me on LinkedIn.
We will also offer the recorded webinar in the Resources section on Digi.com. And if you would like to chat with Digi Sales, reach out to us at www.digi.com/contactus. And of course we have our extensive white paper on the CRA, including everything developers need to know as they navigate the compliance journey.
Is there any official guidance that formally defines 'a substantial change,' as far as the CRA is concerned?
Ron: And therein lies a little bit of the challenge. You know, if you think about, for example, the deadline that the European Union have set themselves for the product categorization is December of this year. So, that's still work in progress.
So, there's a huge challenge for OEMs today, if they are being asked, as of now, September 2025, to have in place a mechanism for reporting vulnerabilities, and notifications, and the fallout from that, and what the patches and fixes and delivery might look like, when they don't actually know how the definitions might apply to their product. So, yeah. There's a lot of work in order on that, and I do have a lot of sympathy for a lot of OEMs who really read the guidance, and it's very exhaustive, trying to figure out how exactly it applies to them. It's still quite fluid.
Digi can help. We have a full Wireless Design Services team that supports organizations in certification and go-to-market needs with engineering help at any level needed, when integrating Digi embedded solutions into their designs.