The compliance clock is ticking: How IoT manufacturers can prepare for the Cyber Resilience Act

For several years, cybersecurity experts have warned that many Internet of Things, smart-home and other embedded devices can be easily hacked, hijacked or turned into spying devices. Such gadgets, ranging from fitness bands to internet-connected TVs to baby monitors, should be subject to stricter regulations, the experts said.

Those regulations are finally here. The United States, the United Kingdom, Singapore and several other countries are busy putting into place security frameworks for IoT devices, some of them voluntary, others tame.

But the big boy on the block is the European Union's very strict and very mandatory Cyber Resilience Act (CRA), which is already technically in force and goes into full effect by the end of 2027. It may completely change how embedded devices are made, sold and maintained.

Complying with the CRA is going to be a heavy lift for many manufacturers. Due to the long development and design time for most new devices, they'd better start implementing the CRA requirements now.

There's no "grandfather" clause for a device whose development process began before the CRA went into effect. If it hits the market on or after Dec. 11, 2027, it has to comply with the CRA.

These manufacturers will need to completely reshape the way they design and develop software and firmware for their devices. They will need to draw up a software bill of materials (SBOM) for each device, subject to revision each time the firmware is updated over the consumer lifespan of the device. And they will need to report and quickly fix any discovered vulnerabilities for years after a device hits the market.

"Your products need to be secure by design from the beginning," says Matt Wyckhouse, CEO of IoT-device security provider Finite State, which is helping its clients conform with the CRA. "They have to be secure by default, so you have good default configurations, and then you have to manage vulnerabilities and transparency throughout the life cycle."

Here's what the CRA mandates, and how makers of all covered products — which includes laptops, smartphones and commercial operating systems — can comply.

Why the CRA and other regulations have come about

It's no secret that many IoT, smart-home and embedded devices have weak cybersecurity. Kids' tracking bracelets can be hacked to show location data to strangers; smart light bulbs give up Wi-Fi passwords; home routers are dragooned into malicious botnets; and home security cameras are remotely hijacked by pranksters. 

The manufacturers of these internet-connected devices often don't follow the cybersecurity best practices that have long been observed by makers of personal computers, smartphones and operating systems.

And until recently, they've not needed to. Consumers have preferred low cost and ease of use over the inconvenience of stronger security. Just think how many people never changed the default administrative passwords on their home routers or Wi-Fi security cameras.

"Even just seven years ago, there was very little pressure on manufacturers of IoT devices," says Wyckhouse. "The manufacturers historically have just been focused on getting lots of features at very low cost into the market, and so there wasn't a lot of investment in this space."

So governments are getting involved. Singapore in 2021 launched a voluntary IoT certification program. The UK followed up in 2024 with its mandatory Product Security and Telecommunications Infrastructure (PSTI) regime, and the EU issued the most recent update of its Radio Equipment Directive (RED), also mandatory.

The PSTI requires makers of all internet-connected consumer products to say for how long security updates will be provided, and to provide contact info to report vulnerabilities and defects. The new RED was what made Apple iPhones switch to USB-C ports, but some other aspects have not been finalized.

Not to be left behind, the U.S. has been putting together the voluntary Cyber Trust Mark (or USCTM) program. It covers IoT "smart" devices such as Roombas, connected cameras, fitness bands, and baby monitors, but not smartphones, computers or (for now) wireless routers.

Modeled on the Energy Star consumer-information program launched in the '90s, the Cyber Trust Mark sticker will indicate that a device has met cybersecurity requirements laid out by the National Institute of Standards and Technologies (NIST) and verified by UL (formerly Underwriters Laboratories) and other independent testing labs.

The specifics of the USCTM are still being formulated, so we don't yet know when the program will go into effect. Most recently, the FCC gave UL a 60-day extension to file its recommendations.

The hard sell to device makers is that the CTM badge will make their devices more competitive in a crowded market, reduce the risk of data breaches, and help them comply with other national regulations, especially the EU's CRA.

What the CRA requires

While the above regulations are either voluntary, fuzzily defined or relatively toothless, the CRA is anything but.

Its requirements are well defined, and while manufacturer self-assessments are permitted in most cases, documentation must be provided. Manufacturers who violate the CRA are subject to fines of up to 15 million euros or 2.5% of global sales, whichever is greater. Products that violate the CRA may be recalled or banned, and vulnerabilities must be reported to EU authorities within 24 hours of discovery.

"If you don't have a program to monitor [vulnerabilities], you're not going to be compliant with that part of the rule," says Wyckhouse. "That's actually when you're going to get the most heat from the regulators, when there's an actual problem that's been discovered in your product."

The CRA is so strict that it may end up setting IoT and embedded-device security standards for the entire world, much as the EU's General Data Protection Regulation (GDPR) has shaped privacy standards worldwide, or how California's vehicle emissions standards have been adopted by more than a dozen other American states.

A Finite State eBook providing guidance to IoT manufacturers predicts that "CRA-compliant hardware and software will become the norm, naturally elevating cybersecurity standards even in less regulated markets."

Wyckhouse is skeptical about whether American consumers will use the Cyber Trust Mark when shopping for smart-home devices. But he thinks the CRA will make the Cyber Trust Mark more effective due to the significant overlap between the two standards.

"The good news for device manufacturers is the requirements are very similar," he adds. "You're going to have so much overlap that if you're ready for one, you're probably ready for the other."

Unlike the USCTM, the CRA does cover computers, smartphones, laptops, routers and other networking devices, commercially sold applications and operating systems, and internet-connected industrial or manufacturing machines — anything that can be considered a "product with a digital element." Makers of these products and services already mostly follow the CRA's requirements.

Exempt from CRA requirements are connected vehicles, medical devices, civil aviation and marine systems, cloud services and assets, and software provided as a service (SaaS), each of which is already governed by various EU laws.

Also left out are free and open-source software, which was removed from CRA coverage after an outcry from developers during the legislation's review period, and devices and products made expressly for military or national-security purposes.

Here's some of what the CRA mandates for each product:

"You can think of [an SBOM] as the ingredients list for software, similar to a nutrition label," explains Wyckhouse.

That's already a lot to handle for a manufacturer, such as Apple, that develops most of its own software. But makers of IoT and embedded devices use tons of open-source and third-party code in their own products — code that itself is constantly changing as maintainers and developers revise it.

This creates an enormous software supply and dependency chain which is at great risk of being exploited or corrupted by attackers. Creating and maintaining an SBOM under those circumstances is like trying to wrestle a school of carnivorous eels underwater.

"You have one component that's depending on another component that's depending on another component," says Wyckhouse. "Having full visibility into all of those, those dependency relationships, and then compiling that into a list that you can generate, maintain and share, is actually a daunting effort if you've never done it before."

To nail down this problem, the CRA also requires that device and product makers:

"The CRA sets the bar about as high as you can," says Wyckhouse. "They've raised it so high that even the smallest device manufacturers have to have these really robust product security programs in place that are modeled after the absolute best companies in the industry who've been doing it for a decade or longer."

How the CRA categorizes products

The silver lining in all this is that the CRA, unlike the U.S. Cyber Trust Mark, does not require independent lab tests, audits or assessments for most products. Instead, an estimated 90% of products can undergo a self-assessment carried out by the device maker. The EU just needs to see ample documentation of those assessments.

The CRA puts devices and products into four categories:

1. Default

Low-risk products such as printers, most smart-home devices, Bluetooth speakers, basic computer applications, hard drives, video games, etc. If the product doesn't provide security for other devices or entities, it falls into the default category.

Manufacturers can self-assess these products by providing descriptions of function, risk assessments, and documentations of measures implemented to mitigate risk.

2. Important, Class I

Devices or products that do provide security, or whose compromise would be detrimental to security and privacy.

These include operating systems, PCs, most smartphones, gaming consoles, password managers, ID management systems, VPNs, routers, modems, web browsers, antivirus software, smart door locks, smart security cameras or alarm systems, smart baby monitors, smart toys with location tracking or interactive features, kid-tracking watches, smartwatches with health monitoring, and smart/voice assistants.

Self-assessment by manufacturers is allowed if one of three EU-approved compliance frameworks can be applied. If not, then a third-party assessment is needed.

3. Important, Class II

Devices or products that provide a higher level of security, such as firewalls, "tamper-resistant" CPUs/GPUs/microcontrollers, hypervisors/container managers, and intrusion-detection or intrusion-prevention (IDS/IPS) systems. For these, a third-party assessment is required.

4. Critical

Security-providing products or devices whose compromise could be catastrophic to organizations or individuals, such as smart cards, smart-card readers, smart meter gateways, and hardware security modules. These will have to undergo strict certification assessments carried out by EU-approved parties.

How to comply with the CRA

CRA compliance will be easy for Apple, Google or Microsoft, each of which already implements many of the required practices and can afford to quickly put the rest into place. But it won't be simple for most makers of consumer or industrial IoT and embedded devices.

"The CRA is a pretty fundamental shift," says Wyckhouse. "A lot of our customers, a lot of companies in the market are trying to do this for the first time."

Another thing to keep in mind, he adds, is that compliance with the CRA is not a one-and-done deal. Unlike some product certifications that apply only at product launch, the CRA needs you to continuously maintain, update, assess and patch your product's firmware for many years afterwards.

"Not only do you have to have secure by design, secure by default, no exploitable vulnerabilities when you take it to market," Wyckhouse says, "but you're then obligated to support it throughout the entire life cycle of the device."

Finite State foresees several potential compliance issues and has recommendations for tackling each.

Lack of money, staff or resources to handle CRA requirements. Finite State recommends using automated software-composition analysis (SCA) tools and vulnerability management platforms, plus project-management frameworks to keep track of it all.

"We can very rapidly bring [our customers] up to par, so we can support initial scanning of their code bases with our binary SCA tools and binary SAST [static application security testing] tools," says Wyckhouse.

To compile SBOMs, he adds, "we pull in all the dependencies, we pull in all the vulnerabilities, we let them see that, so that's a big part of what's required to comply with the CRA."

Protecting intellectual property while complying with SBOM and vulnerability-disclosure requirements. Some cybersecurity experts also warn that reporting vulnerabilities will lead to attacks before patches can be applied. Finite State recommends having lawyers draw up protective clauses in contracts with customers and suppliers.

Meeting 24-hour incident-reporting deadlines. Finite State recommends using automated detection and reporting tools.

Verifying the security and compliance of third-party components. Finite State recommends creating a vendor-compliance program.

Making sure your devices are still easy to use. Finite State recommends conducting usability testing alongside security audits, incorporating security into the beginning of the design and development process, and communicating with customers during the design and development process.

The rollout of the CRA will create a harsh new world for makers of low-cost embedded devices. Wyckhouse sees some hope in the fact that "white label" device makers often use firmware developed by large chipmakers, who will institute their own compliance programs.

Still, he fears that the CRA may put some IoT manufacturers out of business unless they can adapt to the new regulations. 

"The companies with the biggest challenge are the companies that have never had to invest in security, who only cared about getting low-cost products to market, and they're going to have a choice to make," explains Wyckhouse. "They're going to either have to invest in security or they're going to start losing a lot of their revenue very quickly."