How to Classify IoT Products Under the CRA

Margaret Ellis

Welcome back to Come Reflect Act by Tributech. I’m Margaret Ellis, joined as always by David Evans. Today we’re taking on what is arguably the first and most critical fork in the EU's Cyber Resilience Act compliance road: classifying your IoT product under the CRA. David, this is the bit where most manufacturers start scratching their heads, isn’t it?

David Evans

Yeah, absolutely, Margaret. It’s the step everyone kinda wants to skip over, but you really can’t build a compliance plan until you pin down if your device is Default, Important, or Critical. And, you know, the way the CRA lays it out—it’s anything but static. Things can move around, and honestly, a lot of people misclassify by assuming their product is "just another" IoT thing.

Margaret Ellis

Ah, yes. Let’s break that down a bit. At the simplest: The category Default, means general IT or IoT products without an essential cyber role—basically, devices not central to security or safety. That’s your self-assessment route. But the moment your product veers into identity management, privileged access—think browsers, password managers, VPN software, network management systems—you’re looking at crossing into Important Class 1, with mandatory third-party assessment. Right, David?

David Evans

Exactly. And Important Class II—well, that’s for things that operate even deeper, like hypervisors, intrusion prevention systems, or tamper-resistant microprocessors. These are technologies that act as, sort of, the backbone of trust for the ecosystem. Here, third-party assessment isn’t just nice to have, it's mandatory. And then if we talk about Critical—now we're looking at hardware with security boxes, smart meter gateways, smartcards, cryptoprocessing devices... That’s where you’ll need certification under the EU Cybersecurity Certification scheme, the EUCC, when that becomes available for the category.

Margaret Ellis

Now, all three categories must comply with the same 13 essential cybersecurity requirements the CRA sets in Annex 1. What changes is how you prove conformity. For Default, you can use Module A—self-assessment. Move to Important, and you’ll be engaging with third parties using Modules B plus C or Module H. Critical? That’s EUCC certification, at least once a scheme exists, but until then you fall back on those third-party routes.

David Evans

And that proof—how deep your technical evidence needs to be, how closely you’re audited—all escalates with risk. So, every manufacturer really needs to treat classification as a living process, not a one-off. Margaret, anything else before we move into how “core functionality” actually gets defined within these categories?

Margaret Ellis

That’s a perfect segue, David. Because this is where even sophisticated product teams slip up—the difference between ‘core functionality’ and supporting features. The heart of it is: what is the buyer expecting your product to deliver, day one and every day after? That’s what regulators focus on. If security is a primary selling point, it’s core. If you’re just including, say, encrypted comms as part of a temperature probe, that’s supporting. You won’t get kicked up a class for that alone.

David Evans

It’s a little counterintuitive! An IoT hub, for example, that just forwards data—still Default. But if it manages network configuration or handles access control, suddenly you’re in Important territory. Or think about cloud or control-plane services: if your hardware flat-out needs the backend service to function, you have to analyze that as part of the core, and the risk level can go up.

David Evans

A word of warning too—embedding something from Annex III, like a crypto library or secure OS, doesn’t bump your whole device up a category automatically. It only does if the core, advertised purpose is that security-critical role. So, always map what you intend and how users rely on it, and don’t let aggregation or supportive features fool you into over-classifying. It’s about risk context, not a checkbox exercise.

Margaret Ellis

And just to round this out, supporting features are really about context. If security is your core pitch, regulators treat it as such. If your product’s core is something else, like environmental monitoring, even a bunch of security “add-ons” might not change the base classification. So, do the mapping work up front—it pays dividends when it’s time to justify your CE marking and assessment route.

David Evans

Let's talk about why classification isn’t a “tick it and forget it” kind of deal. Every major product release, any pivot in how users can interact with your device, or even broadening your cloud dependencies—those are all triggers to pause and recheck your class. You’ve gotta treat this as a standing design control, not a “one-and-done” activity.

Margaret Ellis

Completely agree. I always tell people: the CRA treats classification as living documentation. You can start by defining that core function and the intended use or misuse; map those functions to Annex III and 4—does it fit any listed security or system-critical role? Keep close tabs on changes from the Commission—Annex III or 4 could evolve, so regular monitoring is essential. Then you can document your chosen route, whether it’s self-assessment or a third-party audit, and plan those partner relationships, like testing labs or notified bodies, early. That way, you won’t be caught flat-footed when the next release drops.

David Evans

I want to toss a question to our audience, maybe for those of you running product teams out there: How often do you think your organization should revisit the product classification—every release, once a quarter, only for major changes? And who actually owns that process? Is it compliance, is it product, or some shared responsibility?

Margaret Ellis

It’s such a good point to reflect on. The organizations that treat classification as a strategic asset, not just a compliance hurdle—well, they’re the ones who have predictable product launches and far fewer audit headaches. Plus, turning compliance into a competitive advantage means your customers trust your releases and partners know you won’t freeze up if the requirements shift unexpectedly.

David Evans

So, bottom line: keep your evidence and documentation up-to-date, make classification a core part of your product design, and treat every change as a potential opportunity to improve—not just a box to tick.

Margaret Ellis

That’s a perfect place to wrap. David, as always—a pleasure. Take care, David!

David Evans

Thanks, Margaret. Always great chatting. And thanks to our listeners—looking forward to the next one! Bye, everyone!