How the Cyber Resilience Act applies to IoT and embedded devices
The CRA classifies connected products by risk, not by industry label. Here is how IoT and embedded devices actually get classified, and why fielded units are the hard part.
Most explanations of the Cyber Resilience Act are written at the regulatory level, in force since, reporting from, essential requirements from. Useful, but they skip the part embedded and IoT teams actually need: how does a specific connected device get classified, and why does everyone say fielded devices are the hard part.
TL;DR: The CRA applies to any "product with digital elements" with a data connection to a device or network, which covers the overwhelming majority of IoT and embedded hardware regardless of industry. Classification into default, important, or critical risk tiers determines whether self-assessment or third-party assessment is required. The genuinely hard part is not the classification, it is delivering security updates to devices you have already shipped.
Does the Cyber Resilience Act apply to IoT devices?
Yes, essentially by construction. The CRA's scope, set out in Regulation (EU) 2024/2847, is defined around "products with digital elements", any hardware or software product whose intended or foreseeable use includes a direct or indirect logical or physical data connection to a device or network. A smart thermostat, an industrial sensor gateway, a wearable, a fleet-tracking module, and a consumer camera all satisfy that definition. The regulation does not carve out IoT as a special category needing separate rules, it is simply one of the largest populations of products the general rule already covers. For the full requirement set, see our Cyber Resilience Act framework page.
Does a device need internet access specifically to be in scope?
No. The connectivity test is broader than "has its own internet connection." Bluetooth, Zigbee, LoRa, a wired serial link into a local gateway, or any other logical or physical connection to another device or network counts. A sensor that only talks to a local gateway over a proprietary radio link, with the gateway being the only internet-connected component, is still a product with digital elements in its own right. Teams sometimes assume an "air-gapped" or gateway-mediated device escapes scope; it usually does not.
How does classification actually work for IoT and embedded products?
The CRA sorts products into three risk tiers: default, important, and critical, based on the cybersecurity risk posed if the product is compromised, not on the industry it is sold into. Most consumer IoT, smart home devices, wearables, and similar products without a dedicated security function sit in the default class, which allows self-assessment against the essential requirements. Products that perform security functions themselves, or that operate in higher-risk contexts such as industrial control systems and certain network infrastructure, are more likely to land in important or critical, which require third-party conformity assessment through a notified body. Our conformity assessment guide covers how that boundary is drawn in more detail.
Why do fielded devices get singled out as the hard part?
Because the CRA's requirements are trivial to build into a device that does not exist yet, and genuinely difficult to retrofit onto one that is already in a customer's hands. A new design can include an over-the-air update mechanism, structured logging for vulnerability monitoring, and SBOM generation from the first commit. A device shipped three years ago, possibly with no update path at all, constrained flash, or a bill of materials nobody has kept current, needs all of that engineered in after the fact, against hardware constraints that cannot be changed. The operational question, "can we patch what we have already shipped, and can we do it inside 24 hours of learning about active exploitation," is where most embedded teams' actual CRA risk lives, not in the paperwork.
What does this mean for legacy embedded product lines specifically?
If your company has multiple hardware generations in the field, some old enough that the original engineering team has moved on, the first practical step is an inventory: what hardware revisions exist, what firmware version is each one running, and what components does each firmware build depend on. Without that baseline, you cannot know which fielded units are affected by a new CVE, let alone patch them inside a 24-hour window. Our ESP32 CRA ship list is a concrete, artifact-level walkthrough of exactly this problem for one common embedded platform, and generalises to most microcontroller-based product lines.
Do connectivity protocols like Modbus or MQTT change the classification?
Not directly, the classification looks at the product's function and risk profile, not its specific communication protocol. But protocol choice does affect how you demonstrate compliance in practice, since your SBOM, vulnerability monitoring, and update mechanism all need to account for the actual data path a device uses, whether that is MQTT over Wi-Fi or Modbus over a wired industrial bus.
What is the single most useful thing an embedded team can do first?
Generate an SBOM for every actively shipping product line and wire it to vulnerability monitoring before worrying about which formal assessment track applies. Classification determines your assessment path, but an SBOM and monitoring pipeline are needed regardless of which track you land in, and they are usually the longest lead-time item. Our hands-on SBOM walkthrough and CVE-to-patch pipeline are the concrete starting points.
Where Scadable fits
Scadable was built for exactly this problem, mapping every fielded device and firmware version to the components it runs, flagging what is actively exploited, and getting the fix backported and deployed to devices that are already in the field, not just new units coming off the line. If you have multiple generations of embedded hardware and no single source of truth for what is running where, book a walkthrough.
Last reviewed: July 1, 2026.
Frequently asked questions
Does the Cyber Resilience Act apply to IoT devices? Yes. Any IoT or embedded device that qualifies as a "product with digital elements", meaning it has a digital component and a direct or indirect logical or physical data connection to a device or network, falls under the CRA regardless of the specific industry it is sold into.
How are IoT devices classified under the CRA? Products are classified as default, important, or critical based on the risk posed if the product is compromised. Most consumer IoT sits in the default class, which allows self-assessment. Products with security functions, or used in sensitive contexts like industrial control, are more likely to be classed important or critical, which require third-party assessment.
Why are fielded IoT devices harder to comply with than new designs? A new design can build in secure-by-design practices, SBOM generation, and an update mechanism from day one. A fielded device already shipped, potentially without an update mechanism, needs those capabilities retrofitted or a plan for how a fix reaches it at all, which is an operational problem, not just a design one.
Does a device need internet connectivity to be in scope? No. The definition covers direct or indirect connection to another device or network, which includes Bluetooth, Zigbee, LoRa, wired serial links to a gateway, and other non-internet connectivity, not only devices with their own internet-facing interface.
What is the single hardest CRA requirement for embedded teams specifically? Delivering security updates to already-fielded devices within the support period, including devices with constrained memory, no over-the-air update mechanism, or long field lifetimes that outlast the original engineering team's institutional knowledge of the product.