The firmware for Internet of Things (IoT) and other embedded devices has often been a bit of a mess, with open-source and third-party code haphazardly grabbed from hundreds of different sources. Many IoT device makers have also been less than diligent about finding firmware vulnerabilities or issuing patches to end users.
That's all about to change. Impending regulations such as the European Union's Cyber Resilience Act (CRA) and the U.S. Cyber Trust Mark are forcing IoT and embedded device makers to implement the same cybersecurity best practices and DevSecOps secure-development processes already followed by top software makers like Microsoft, Apple and Google.
More significantly, all makers of consumer products that use software and are sold in the EU will need to provide up-to-date software bills of material (SBOMs) on demand, will need to report newly discovered vulnerabilities within 24 hours and will need to issue user-installable updates as quickly as possible.
The complexities of most software and firmware supply chains, not to mention the software itself, already makes manual vulnerability management, software composition analysis (SCA), SBOM compilation, and incident response very difficult. The stringent reporting and documentation requirements about to be imposed by the CRA will make it impossible to comply entirely by hand.
IoT and embedded-device manufacturers have no choice but to use automated firmware testing, vulnerability management and SBOM compilation and updating. These processes need to be put into place now, as the CRA goes into full effect at the end of 2027 and will apply to upcoming devices currently in the design stage.
Artificial intelligence (AI) is already part of these processes and will play a larger role as its code-checking abilities improve and the speed of software and firmware development accelerates.
"AI absolutely helps, because there's such a huge workload that's now being placed on these product security teams, who are already overwhelmed," says Matt Wyckhouse, CEO of firmware-testing and consulting firm Finite State. "They now have all of these regulations to comply with, and they now have to support more products than they've ever had to support. And AI definitely is helping in that mix."
The problem with manual code checking
In theory, making firmware that's free of vulnerabilities shouldn't be hard. You write the software, you have a security expert check it over, you put it through testing and then you release it.
But that's largely an illusion. Most firmware reuses components from earlier projects developed by the same team. Those components may have changed since they were first used or may behave differently when placed into a different software or hardware environment.
Often, firmware also pulls components from outside the organization, such as from vendors or from public online repositories that contain vast amounts of open-source code. You can question a first-party vendor on the security of its code and ask the vendor to submit the code for review, but you can't do it when you're using an open-source library that's constantly being updated.
It gets really complex when your suppliers or vendors are themselves using open-source or third-party code that they're not inspecting for vulnerabilities or tracking for updates. For these reasons, code checkers who go over firmware manually will soon be overwhelmed, whether they're searching for vulnerabilities or just trying to get a full inventory of all the sources used.
"You have one component that's depending on another component that's depending on another component," explains 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."
This is going to be especially difficult for device makers who've never had to comply with this kind of regulation. They'll have a hard enough time passing "friendly" external audits or penetration tests; if a product fails an audit mandated by the CRA, the product may be banned and its manufacturer slapped with very heavy fines.
"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," says Wyckhouse. "A lot of companies in the market are trying to do this for the first time."
Skip straight to automation
If an embedded-device maker hasn't done any kind of code security review or vulnerability management before, it won't be worth the effort to try to implement manual processes. The manufacturer should go straight to processes that are as automated as possible — or risk losing access to the European market.
"The companies with the biggest challenge are the companies that have never had to invest in security," says Wyckhouse. "They're going to have a choice to make ... They're going to either have to invest in security or they're going to start losing a lot of their revenue very quickly."
The risks of non-compliance in the U.S. market are lower. The voluntary Cyber Trust Mark labeling program, set to roll out later this year, only advises customers that a device bearing the label has passed government cybersecurity standards akin to those mandated in Europe by the CRA.
"The requirements are very similar," says Wyckhouse. "You're going to have so much overlap that if you're ready for one, you're probably ready for the other."
Automated processes such as static and dynamic application security testing (SAST and DAST), especially when aided by AI, will be able to sort through your code much faster than any human code checker. An automated vulnerability-management platform can detect and even remediate hidden threats and flaws better and more quickly than a team of experts.
When it comes to containing and tackling the enormous mess of constantly changing software sources that need to be dynamically documented in firmware SBOMs, there's no contest between humans and machines.
"If you wanted to generate an SBOM in a way that's going to be compliant with the CRA and enable you to be ready for Cyber Trust Mark," Wyckhouse said in a recent video interview, "you have to generate it in a format that's going to be machine-readable in one of these [CRA-compliant] standard formats."
"But you also have to go through a process of generating that, inventorying all the software that is in the code that your developers are writing, and not only that your engineering team is building, but all of your suppliers and their engineering teams, all the software that's inside of their code, and all of their suppliers," he added. "It's virtually impossible to do that accurately without automated tools."
How to get your code checking up to par
Finite State recommends several steps that makers of embedded and IoT devices can take to modernize their code management to comply with the CRA.
Automate software composition analysis, especially at the binary level. "We've automated that whole decomposition process, where we extract it, we look at all the files, and then for every single file that has executable code in it, we actually disassemble, decompile and extract all of these features," says Wyckhouse. "It does require a lot of work to do binary analysis, a lot of computation, but we've been refining that over many, many years to make that work very well."
Automate SBOM compilation and updating. "It's not easy, because modern software, especially using open-source code, has very long dependency chains," says Wyckhouse. "That's why Finite State automates as much as possible. It also looks for known vulnerabilities and hard-coded credentials."
Automate code review during firmware development. "Advanced SBOM tools can integrate with CI/CD pipelines, providing real-time updates and alerts on newly discovered vulnerabilities," writes Finite State's Hannah Beazley in a company blog post. "AI-driven analytics can help prioritize risk mitigation efforts, focusing resources on high-impact threats."
Automate vulnerability management. "Automating vulnerability detection makes this process more manageable," writes Beazley. "Manufacturers can leverage tools like Finite State that scan source code and binaries to cover the full spectrum of software components."
Automate patch deployment. "Manufacturers should automate the patch deployment process, ensuring that both scheduled updates and emergency patches are rolled out seamlessly," writes Beazley.
Overall, device manufacturers need to remember that the CRA, and the Cyber Trust Mark to a lesser extent, creates a whole new regulatory environment that mandates constant testing, documentation, and support not just during the product-design and firmware-development processes, but for the lifetime of the product as well. This will not be possible without automation.
"Your products need to be secure by design from the beginning," says Wyckhouse. "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."
