The CRA’s Challenge for Embedded Developers

The CRA is now in session. Well, at least its reporting obligations are. As of September 11th, the EU Cyber Resilience Act requires manufacturers selling within Europe to meet specific vulnerability and incident-reporting requirements for products or components with digital elements.

One deadline has passed, but the biggest one is still to come: December 11th, 2027, when the CRA’s wider requirements take effect. This will include secure-by-design development, risk assessment, vulnerability handling, documentation, and conformity assessment. Until then, manufacturers and the suppliers they rely on have time to understand their new responsibilities and prepare for the next stage.

Time To Prove It

While the CRA focuses on compliance for device manufacturers, there’s an obvious knock-on effect for developers of upstream components or foundational software like Real-Time Operating Systems (RTOS). After all, when it comes to vulnerability management, software bills of materials (SBOMs) and ‘secure-by-design,’ one weak link in a third-party component can create problems for the entire device.

For developers in already security-regulated industries like automotive and aviation, this isn’t new. But the CRA brings formal cybersecurity expectations to a much broader range of connected products.

CRA brings formal cybersecurity expectations to a broad range of connected products, including consumer, industrial, and energy. Image used courtesy of Adobe Stock

For consumer electronics, industrial equipment, and energy infrastructure, to name a few, building secure systems is no longer enough. Manufacturers must prove they’ve considered security from the outset, and provide the evidence to back it up.

The Out-of-Context Problem

When developing component designs to be embedded into a product, this can be a significant challenge. They’re often building hardware or software elements ‘out-of-context,’ before knowing their final application or end-user environment. How can you assess the security risks of a component if you don't know where, or how, it will ultimately be used?

In many ways, you can’t. Security needs to work in context. A component might have no vulnerability of its own but still play a vital role in the security of the wider system. After all, this is how exploits work: a component can be perfectly secure on its own, but become a security risk when it interacts with something else in the system.

Security needs to work in the context of the wider embedded system. Image used courtesy of Adobe Stock

For example, an RTOS may not expose an internet-facing interface, but an application running alongside it could be compromised. The question then becomes whether the underlying software can isolate that application and prevent the breach from spreading across the wider system.

The answer isn't for component developers to predict every possible use case. Instead, it’s about giving downstream manufacturers enough visibility to assess the component in context: what it contains, how it is maintained, what vulnerabilities exist, and how quickly fixes can be delivered.

This is particularly important in embedded systems, which often rely on complex software supply chains, middleware, and open-source components. Transparency is key, but gathering the information needed to meet new CRA requirements, including an SBOM, will be another challenge for companies to overcome. Developers may have limited visibility into the security processes behind upstream components, while maintaining their own forks or managing fixes can be time-consuming. The result? A delicate tightrope between keeping software secure and compliant, and keeping development efficient and on schedule.

The Role of Component Providers

Naturally, component and platform providers have a key part to play here. Products with digital elements placed on the EU market will need to demonstrate compliance with the CRA, and the components within them can't be treated as a black box.

Component developers need to think beyond simply delivering secure code. Their software needs to give downstream developers the mechanisms, visibility and evidence they need to manage security in the context of the final product – without assuming what that product will look like.

This is where it's important to recognize that it's not just the vulnerability itself, but also its potential impact on the wider system if exploited. And this is where a flexible approach is required. Rather than just providing software components, they need to give developers secure-by-design foundations alongside the evidence needed to confidently integrate those components into the wider system. Crucially, however, these assured components should not come at the price of lock-in, engineering constraints, or poor flexibility.

Otherwise, this creates a trap for developers. While secure foundations can provide the assurance needed for compliance, if they come with rigid architectures or tightly controlled ecosystems, they constrain development freedom. Instead of forcing lock-in, component providers must equip developers with the tools and evidence frameworks needed to build secure products themselves.

Better yet, foundational software components like RTOS, middleware, and device drivers should include features that allow the secure integration of software from multiple suppliers. For example, an RTOS should include partitioning features so that it can restrict third-party components to only access the resources and services they require. Features like this need to be configurable by the device manufacturer, allowing them to tailor security to the specific software being integrated.

Ultimately, it’s about giving developers the tools and information they need to apply secure-by-design principles and build the necessary evidence around the device and its full context. The security foundations and evidence required to demonstrate compliance should be built into the development process, giving developers greater confidence without forcing them to sacrifice flexibility or velocity. As a result, device manufacturers can achieve both freedom of design and robust security, without compromising system integrity or reliability.