What embedded developers need to know about the CRA

Feature articles | August 4, 2025

By Nick Flaherty

Authentication & Encryption Software & Embedded tools

Embedded system developers are set to face major challenges over the next two years as the new Cyber Resilience Act (CRA) regulations are coming into effect.

The CRA means that over the next two years, developers will have to include monitoring of connected devices along with secure updates and, for the first time, a software bill of materials (SBoM). This will apply to a wide range of “products with a digital element”, or PDE, sold in the European Union from 2027.

“There’s a lot of activity going on finally. The legislation wasn’t finalised until last year so although drafts had been circulating for years before that,” said George Grey, UK-based vice president of software at Qualcomm and co-founder of Foundries.io in Cambridge.

“It is now getting serious as if you think about the average time to develop an IoT device, whether that robots, or medical equipment. These can take 18 months and now, given its July 2025 and products must be compliant by 2027, we have got to get started.”

What is the CRA?

The CRA, or Regulation (EU) 2024/2847, is the EU’s first horizontal law that legally mandates Secure-by-Design for every product with digital elements. It introduces objective-oriented and technology-neutral essential cybersecurity requirements that manufacturers must follow

The Act requires manufacturers to implement “essential requirements” for cybersecurity throughout their products’ lifecycle. The Act passed on 10th December 2024, and is being introduced in two phases. The first, or imports, requires compliance by 11th September 2026 for importers of equipment and the second by 11th December 2027 for all the requirements of the Act.

This is similar to the introduction of the EMC regulation back in 1992 after a compliance period and will have a similar reporting system.

The CRA’s mandatory security obligations are detailed in CRA Annex I (CRA Art. 6). This annex is split into two, where Part I defines the product security requirements that must be designed into the device from the start. Part II defines the vulnerability handling requirements a manufacturer must follow throughout the product’s support lifecycle.

Hardware

There are seven key aspects of Cyber Resilience Act (CRA) compliance: secure-by-default configuration, secure over-the-air firmware updates, data integrity protection, access control and device authentication, data confidentiality and secure storage, risk assessment and secure-by-design integration, and attack surface reduction.

One of the key ways to achieve this is via a secure root of trust such as ARM’s TrustZone or QuarkLink from Crypto Quantique.

Shahram Mossayebi CEO of Crypto Quantique Source: Crypto Quantique

“Ensuring CRA compliance can be a complicated process, often involving many processes, platforms and tools. QuarkLink addresses the majority of these challenges in an integrated, easy-to-use way that eliminates the need for engineers to be cryptographic experts but gives them the assurance that their products will meet the act’s requirements,” said Shahram Mossayebi CEO of London-based Crypto Quantique (right). The company supplies secure element IP to chip designers alongside silicon IP and an end-to-end security platform for embedded devices.

In devices, the QuarkLink software development kit (SDK) acts as an abstraction layer to implement native hardware-based security functions with chip vendors including Microchip, Renesas and STMicroelectronics. In the cloud, the platform centralises the implementation and management of secrets and certificates throughout the product lifecycle. This reduces risks related to cryptography such as insecure implementation, misconfiguration, leaked secrets, and expired certificates.

A recent independent analysis of QuarkLink from cybersecurity advisory firm Cetome looked at the different aspects of the platform for the CRA..

“The CRA is pushing all the vendors and software developers to do something, even if it is the smaller devices,” he says. “A lot of the time the hardware is bought from different vendors and that can be outside the EU but when it is assembled in the EU you have to write the embedded software and because of the CRA you need root of trust and write the software to take advantage of that security.”

Meanwhile US startup Thistle Technologies is developing a platform to manage the secure updates that will be needed.

Window Snyder, CEO and founder of Thistle Technologies Source Thistle Technologies

“All the work we have been doing in security over recent decades hasn’t really made its way into devices, so it’s increasingly important to add this,” said Window Snyder CEO and founder (left). She has worked on Apple’s iOS operating system and at open source browser developer Mozilla. The company has 10 staff spread across the Bay Area, Texas and Berlin, Germany,

“It’s the most of the sensitive part of the system so reliability is critical. Update has been a challenge for device makers, and there is no room for error on updates,” she said.

“The update is where we started as when security fails it is often here. There are so many ways to mess this up. The problem isn’t the vulnerability, the problem is the ability to fix the device in the field, that is the solutions to the vulnerability,” she said. This is going to be even more important with edge devices deploying AI models.

“Getting to a software security supply chain starts with a secure boot, but then everything comes down to key distribution, deploying keys and the hardware root of trust for configurations,” she said. “Developing secure boot can be 12 to 18 months development for a two or three person team so helping developers with that is a huge step forward. For a lot of the capabilities we don’t care what the OS is, we are operating right after the boot loader.”

The company is working particularly with system on module makers to support their boards, and partnering with other companies for the SBoM capability and for post quantum encryption.

SBoM requirements

There are key implications for the software development process and company processes as a result of the Act and the requirement for an SBoM. As almost all development teams are using some form of open source software, the requirement to track all the different libraries for vulnerabilities is key. AI tools could well be a way forward.

“The first big implication is the paperwork compliance,” said Grey at Foundries.io. “This is like compliance with any other security standard, that requires you have a good process, that’s one side and I would expect the consultancy companies to help people get started.”

“Clearly you need things in place like a software bill of materials (SBoM) and for a product based on Android or Linux you need that SBoM or from the supplier. But most of the products are modified, with specific drivers for the devices you are using so you need the process in place and the paperwork in place. There are also requirements in the Act that if you become aware of a vulnerability in certain circumstances you must report that in a very short time so there are reporting requirements as well,”

“The second implication is the actual change from a technical point of view to comply with the requirements of the Act in updating devices. That very much depends on the use case,” he said. “Alexa is one thing, but a piece of medical equipment or a robot in continuous use 24/7 is a different issue.”

“It’s the combination of the process side and the technology side that will require any product and their supply chain to comply with the requirements of the Act.”

“Most of the tools exist today to do this as a developer with Yocto Linux, there are tools to create an SBoM but the challenge is that if you put that through an open source or commercial tool to get the vulnerabilities you get a lot of false positives, for example with a library it may be a feature rather than a vulnerability.

“So the issue is identifying which of the vulnerabilities map to the code, and that is a manual process that is difficult to automate but I think we will start to see AI tools – this is a big data problem that AI is well suited to solve. It’s that part of compliance that will be tricky as that is not a solved problem.”

Proprietary software

Typically in the database or the software supplier there will be a patch or release update to protect against the vulnerabilities. ”If you are creating your own software and you know the provenance, its more complex,” said Grey. “You then have your own applications as proprietary code or using AI, where there are no tools to create that SBoM and in that case you are relying on third party testing.”

There are ways of reducing the risks through traditional penetration testing and security experts, using more safe coding practices, such as moving to Rust as a memory safe language.

George Grey, VP software at Qualcomm Source: Qualcomm

“The challenge there is you have to have a process that if a vulnerability is found, what the Act says you have to address it, and you have to show that you have to address it and report it if necessary,” said Grey.

“What Foundries do is we provide an SBoM with every build and this is signed in a way that the software you run is the software you wrote, with secure updates,” he said.

“There are tools to follow best practice to update and there are tools to analyse source code and even binaries from third partis but there is no magic bullet. You might be able to do it for a particular use case and a particular set of software but with the range of IoT devices, the range of software and the way it is built there are huge variations. There are thousands of companies building tens of thousands of products, and that’s even before the application software, so this does has to be done on a case by case basis.”

“This is going to affect the SMEs and smaller companies and what Qualcomm and other software suppliers can do its step up to provide the high level tooling for analysis of the software we are delivering,” he said. “We are providing software developed in open source, and therefore what you are seeing is tools for extracting these SBoMs.”

For example Foundries can run a scanning tool on a software container such as Docker or Kubernetes that are becoming more popular in embedded designs to identify vulnerabilities.

“But then you have to have the processes to ensure when someone does find a vulnerability you can react quickly.”

“A root of trust can help and there is a lot of software that uses these, but you can never assume that your hardware is perfect, there will be attacks on hardware and the SoC vendors are working on trying to reduce the risk of that

“It’s the big companies that absolutely need to pay attention as they are most likely to be scrutinised.”

Open source is an advantage, he says.

“It’s much better to have code that people can see as you have more eyes and more use cases and the way open source works by always moving forwards and addressing both new functions and any bugs that are found from a wide varieties of users,” he said. “Problems in proprietary black box products are just as severe and take longer to fix.”

Software Agents

One way to monitor equipment in the field is to use software agents. Memfault in the US for example has developed software agents that sit on microcontrollers and microprocessors to monitor activity. This can detect problems with an IoT node but also with an update and even cyber attacks, with an automated cloud-based infrastructure to handle millions of devices. This is a key capability for the CRA.

Vegard Wollan, CEO of Nordic Semiconductor (right) and François Baldassari, CEO of Memfault Source: Nordic Semiconductor

The company is being bought by wireless microcontroller designer Nordic Semiconductor, and the CRA capability is very interesting, says Vegard Wollan, CEO of Nordic. Memfault currently supplies chip makers TI, Nvidia and Mediatek that support Linux on microprocessor cores, while Nordic currently only has microcontroller cores.

“It goes without saying that in order to resolve and report issues in a timely manner, you must first identify them,” says Memfault. “While some degree of vulnerability testing and detection is possible in-house, it’s impossible to account for all the potential variables that happen in the field. Memfault is acutely aware of this problem; in fact, it’s the primary reason why we exist.”

“Ultimately, there is no replacement for real-world data. Maintaining visibility into device performance in the field is not only critical to identifying quality or performance faults, but also for identifying unaccounted for vulnerabilities that may arise due to user behaviour, environmental factors, or other variables.”

“Collecting robust usage, performance, and behaviour data from devices in the field will become even more critical—if not from the entire fleet, then at least from a substantial sample.”

Memfault has developed tools to help collect various types of data from devices, including crash data, logs, and metrics, that are key for CRA compliance. Collecting a range of data and being able to correlate a specific issue to a particular software version, hardware version, component, or other factors will be extremely beneficial in compliance with detection and reporting requirements.

This connects closely to the requirement to maintain an inventory of software and hardware components for deployed devices. If a vulnerability in identified via in-house testing or field data, it will be crucial to have a clear picture of the exposure of the devices and determine it is correlated with a specific component.

A complete device inventory holds information about the components of each individual device, all of which can be customized and automatically populated. It is also developing functionality that will store an SBoM for each individual software version, allowing developers and network operators to see the prevalence of each version and its components across the deployment at any time.

Added to this is the secure delivery of software updates to the deployed devices. Being able to patch security vulnerabilities will be a key requirement for compliance and chip makers must provide security updates for at least the duration of the device’s lifecycle. The exact method for doing this will vary depending on the use case, but having an efficient way to roll out updates will be critical.

The regulation may force device makers to update their devices on short notice and outside the usual update schedule. This means more updates, more regularly, which comes with additional risk. When shipping an update to patch a security vulnerability, there’s always a possibility of accidentally creating another issue. This means it is important to have a controlled shipping process as well as ongoing, comprehensive observability and monitoring of devices receiving updates.

Harmonised CRA standards

While harmonised standards are still under development, Germany’s Federal Office for Information Security (BSI) has published a detailed technical guideline that serves as a practical playbook for CRA compliance. The standard, BSI TR-03183, is available at Cyber Resilience Requirements for Manufacturers and Products.

There is also the “Security Evaluation Standard for IoT Platforms” (SESIP) methodology from GlobalPlatform will be able to demonstrate conformance with the CRA. SESIP provides a methodology for conducting security evaluations of software and hardware components across both products and supply chains and is recognized as a standard by CENELEC, the European Standardization Organization, as EN 17927. It also aligns with many other legislation and vertical certification schemes around the world, including the Cyber Trust Mark in the US.

“Industry support for SESIP is building at this critical juncture for IoT manufacturers operating in Europe,” said Gil Bernabeu, CTO of GlobalPlatform. “The CRA is vital to protecting consumers and businesses by embedding security features into the heart of the connected devices we use every day, providing a cybersecurity framework that spans the design, development, and maintenance of digital products.”

“However, this landmark legislation presents a range of compliance challenges for manufacturers of connected devices and the components used in these products,” said Bernabeu. “SESIP simplifies conformity with the new regulations by providing a unified framework for comprehensive security evaluation, reducing cost, risk, and time to market. We look forward to expanding the SESIP ecosystem to help multiple industry sectors meet the requirements of the new European regulations. It will also enable international manufacturers to reuse their security evaluation investments to demonstrate conformance to non-European regulations.”

The SESIP methodology is already mapped to other standards and regulations such as ETSI, (EN 303645 / TS 103732), ISO/IEC (62443-4-2), RED (EN 18031), UNECE WP.29 (ISO/SAE 21434) and NIST (NIST 8259 / NIST 8425). It is also being used by schemes such as PSA Certified. In addition to Europe, SESIP is being adopted around the world in key markets such as China, where an agreement was recently reached between GlobalPlatform and China’s National Financial Technology Certification Centre (NFTC).

Microcontroller certification

Renesas Electronics for example has already certified three ranges of microcontrollers for CRA using the PSA Certified global security framework. This has introduced an extension to its Level 1 certification that addresses the compliance requirements of the CRA.

The families, based on the ARM Cortex-M33 and M85 all use the ARM TrustZone security block and were evaluated by Applus+ Laboratories in Spain.

PSA Certified Level 1 also offers additional extensions to comply with the European RED radio equipment directive and the UK Product Security and Telecommunications Infrastructure (PSTI) regulation which both apply to connected and IoT products. This allows manufacturers with the Level 1 certification to meet global security standards for IoT connectivity.

“Reducing fragmentation in cybersecurity certification is key, and we welcome PSA Certified’s efforts to align with other private schemes as well as governmental requirements,” said Jose Ruiz, Cybersecurity BU Director at Applus+ Laboratories.

“With the continued adoption of edge AI devices across all markets and new government regulations coming into effect, security must be prioritized to ensure trusted AI deployment, protecting both businesses and consumers,” said David Maidment, senior director, market strategy at ARM. “Initiatives like PSA Certified are fundamental to driving robust device security and we congratulate Renesas on these new certifications which showcase security leadership in the age of AI.”

The certified 32bit RA4L1 MCU Group is based on the Cortex-M33 (CM33) core with low power features, advanced security engine and communication interfaces for Industrial Automation, Home Appliances, Smart Home, Consumer, Building/Home Automation and Medical/Healthcare applications which all fall under the CRA requirements.

The certified RA8E1 and RA8E2 MCU Groups, both based on the Cortex-M85 (CM85) architecture, are designed for a wide range of applications including industrial automation, home appliances, smart home systems, and medical devices. The RA8E1 MCU Group features ARM Helium technology for Vision and Voice AI applications, while the RA8E2 MCU Group incorporates a Graphics LCD for advanced Human-Machine Interface (HMI) solutions.

Renesas has also achieved PSA Certified Level 3 root of trust component certification for the RA8D1, RA8M1 and RA8T1 MCU Groups to demonstrate protection of the root of trust.

“Achieving PSA Certified Level 1 with the CRA compliance extension demonstrates our commitment to providing our customers with secure, future-proof solutions,” said Daryl Khoo, Vice President of the Embedded Processing Marketing Division at Renesas.

German distributor Rutronik has been working with certification body TÜV Süd, the cyber security consulting company 1ACUE, and Infineon Technologies on guidelines for implementing the CRA requirements,

“We see ourselves as bridge builders between technology suppliers, legislators, and OEMs,” says Bernd Hantsche, Vice President Technology Competence Centre at Rutronik. “The CRA presents many of our customers with major challenges, but it also presents them with the opportunity to make their processes future-proof and resilient. We actively support them in this.”

Looking ahead

Although the Act has only recently been signed, there has been a lot of development in the background on the process flows and standard requirements, and the development tools are emerging to support the implementation.

Developers now need to adopt the requirements of the Act within their design flows, which is a major task. Compliance by the end of 2027 will be tight for many smaller companies, but there are tools and support from a wide range of suppliers to help.