Challenges in complying with the EU Cyber Resilience Act (CRA)

Adopting the main CRA requirements — maintaining secure updates, identifying vulnerabilities, compiling a Software Bill of Materials (SBOM), and ensuring secure-by-default configurations — bolsters the security of products with digital elements (PDEs) throughout their lifecycle. These requirements, although essential, present significant challenges for manufacturers of all sizes.

Ensuring a secure-by-default product

The Cyber Resilience Act (CRA) sets the expectation that all products with digital elements (PDEs) be “secure-by-default” to protect against emerging cybersecurity threats. Manufacturers, therefore, must integrate security at every stage of product development and deployment, taking key steps including:

1. Secure product development: Firstly, manufacturers must establish or augment security processes for product development and the organization to be in alignment. For organizations that have not previously implemented formal security measures, complying with CRA means designing security processes from scratch. Manufacturers that have pre-existing security standards will have an easier time adapting to the regulation, but overall, each requirement presents its own specific challenges on top of the baseline intent.

2. Provide a secure-by-default state: The CRA mandates that all PDEs must be configured in a "secure-by-default" state, meaning that a product's default settings should ensure security and require minimal user intervention to maintain it. Importantly, any fixed bugs, patches, or other security improvements should not be lost when resetting the device to default settings. If remediations are lost in the default settings, the manufacturer should reconfigure the device to immediately update for any known vulnerabilities. The secure configuration must be managed and maintained across devices, environments, and time.

Embedding device security

Enabling secure and immediate updates, protected by mutual TLS and verified by code signing, helps manufacturers maintain a secure-by-default configuration across all devices and throughout the product’s lifecycle. With configuration and software updates at the core of maintaining a secure-by-default state, the OTA update infrastructure is a critical component to achieving compliance. In embedding a secure and robust OTA infrastructure, security can also be embedded throughout the product development lifecycle, from design and testing to manufacturing and in-field usage.

Maintaining an up-to-date software bill of materials (SBOM)

The software bill of materials (SBOM) is essential for providing transparency in software and hardware dependencies and traceability throughout the supply chain. However, creating and managing an SBOM for products involving multiple third-party components can be a major challenge for manufacturers of all sizes. Unlike updating a hardware bill of materials, software evolves rapidly and requires consistent auditing and documentation to keep an up-to-date SBOM.

Challenges in managing an SBOM

1. Creating a comprehensive SBOM: Many manufacturers struggle with compiling a complete, up-to-date inventory of their product’s components, especially regarding third-party software dependencies. For complex systems such as large-scale IoT products, creating an SBOM is a difficult task without established processes or tools. Compiling an SBOM is only more difficult as the size of the fleet increases. Establishing an SBOM, fit for complex systems, and scalable with product growth presents a challenge that, in turn, requires substantial initial effort, tracking, and expertise.

2. Keeping the SBOM current: Once manufacturers establish a comprehensive SBOM, new challenges arise without the proper infrastructure in place to keep the document up-to-date. Many manufacturers lack automated processes or systems that refresh the SBOM with each new software deployment. Relying on manual SBOM updates risks outdated documentation which falls short of the compliance requirements as each new patch is deployed to the fleet.

Simplifying SBOM management

SBOM creation and management go hand-in-hand with OTA software updates. Each new software update deployed also updates the respective SBOM record. As such, tackling SBOM challenges alongside OTA update infrastructure decisions simplifies the process of maintaining and documenting software components. An effective OTA update solution will introduce auditing and tracking capabilities, ultimately helping manufacturers comply with CRA requirements by ensuring full traceability and that the SBOM is automatically refreshed with each deployment.

Vulnerability identification and disclosure

The Cyber Resilience Act (CRA) emphasizes the importance of comprehensive monitoring and proactive management of vulnerabilities across an entire product lifecycle, including not only proprietary code but also all third-party components and interactions. The emphasis on continual monitoring and prompt disclosure presents a few key challenges for manufacturers striving to achieve compliance.

Challenges in managing vulnerabilities

1. Comprehensive monitoring: While identifying vulnerabilities in proprietary code can be relatively straightforward, the true challenge lies in the broader scope of the product, or PDE. Manufacturers must conduct penetration testing on their proprietary code, continuously monitor all third-party software, and assess how the integration of the total product’s components could create new vulnerabilities. This level of oversight is essential for identifying new vulnerabilities but is often complex and resource-intensive.

2. Remediation without delay: Upon identification, the CRA mandates a vulnerability be remediated “without delay” through free security patches available to all users. These updates must be available immediately to protect the end user and keep the product up-to-date. Numerous channels have been and can be used to deploy security updates, from USB sticks and onsite visits to over-the-air (OTA) updates. The “without delay” requirement for security updates by nature excludes physical updates via USB sticks, manual, or onsite visits, as a viable way to comply. Notably, the sophistication of each manufacturer’s update infrastructure will vary greatly, and what was sufficient for an annual product update may not be adequate for regularly and quickly deploying security patches. The absence of a well-integrated over-the-air (OTA) update solution severely impacts the timeliness of security update deployment and can also result in increased vulnerabilities due to the time lag.

3. Public disclosure and user notification: Once a vulnerability is detected, manufacturers are obligated to disclose these findings publicly and communicate with all affected users. Thus, a robust process in place for both prompt remediation and communication with users about vulnerabilities and any necessary updates or fixes is required. Without an automated, reliable system for identifying and managing vulnerabilities, manufacturers will struggle to meet these disclosure and communication obligations. 

End-to-end vulnerability management

Penetration testing, auditing, leveraging an out-of-the-box vulnerability management solution, or a mix of tactics, vulnerability identification is just the start. Manufacturers must consider the full scope of vulnerability management to ensure CRA compliance: identification, quick remediation, and notification. Similar to SBOM management, an effective OTA update solution can significantly streamline vulnerability management, offering the capability of deploying security patches quickly and efficiently with proper communication channels and user interactions. A proper OTA update infrastructure could automatically update the SBOM record as well, taking the vulnerability management process full circle.

Maintaining secure software updates

One core requirement of the Cyber Resilience Act is to ensure secure software updates throughout the lifecycle of any product with digital elements (PDE). As products become increasingly digital, they require more software updates. Secure software updates are critical for protecting users from evolving threats and maintaining product security (vulnerability remediation or security patches). But, noted separately from vulnerability management, offering secure product development updates (product, version, or feature updates) is also required.

Challenges in secure update distribution

1. General security: A compliant mechanism “to securely distribute updates for products with digital elements” must encompass essential security features, such as encryption, cryptography, and secure transmission protocols. Operational security measures, like role-based access control (RBAC), multi-factor authentication (MFA), and audit logs, are necessary to secure the mechanism itself. In addition to security basics, automation capabilities can reduce the risk of human error, and granular update controls offer methods to reduce update risks, such as phased roll outs or canary deployments. 

2. Device security: Ensuring prompt and compliant device security goes a step further than simply distributing patches, it requires robust mechanisms that support resilience in the face of threats. Critical features like automatic retry and rollback continually push patches until they succeed while preventing failed updates from destabilizing fleets.  Phased rollouts are another deployment feature that bolsters device security by allowing controlled, gradual rollouts to verify the stability and success of updates before a full fleet deployment. The utilization of a first boot update process ensures robust security when the device initially connects after manufacturing; since many devices can sit in inventory for months, using a first boot update ensures early vulnerabilities are addressed, protecting the end consumer with the most recent software regardless of when their purchased device was manufactured.

3. Fleet security: By nature, many PDEs exist over large, geographically distributed fleets. Therefore, the update mechanism must be capable of securely distributing updates at scale, to meet the demands of thousands or even millions of devices. Depending on the PDE, the update mechanism must also address complexity, such as varying connectivity conditions and locations. Effective orchestration across device type and hardware-software version compatibility is essential to ensure each update is successful and does not negatively impact device performance.

Secure device lifecycle management

Where non-digital products were sold with little after-purchase OEM interaction, manufacturers are constantly interacting with products with digital elements (PDEs). In this environment, the software update infrastructure becomes the backbone of manufacturer-product communication. From SBOM and vulnerability management to ensuring a secure-by-default configuration, complying with each facet fundamentally encompasses and creates requirements for the OTA update infrastructure. A well-designed and planned OTA update infrastructure can greatly streamline compliance with all other requirements within the CRA.

Overcoming EU CRA compliance challenges

Meeting the multi-faceted requirements of the Cyber Resilience Act (CRA) is a demanding task for manufacturers. There are overlapping challenges in maintaining secure updates, compiling and updating a comprehensive SBOM, identifying vulnerabilities, remediating vulnerabilities, providing secure product updates, and ensuring a secure-by-default configuration. These elements do not exist in isolation. An effective security and compliance strategy requires a unified approach that considers their interplay.

Further reading

Check out the other articles in our CRA compliance series:

• An overview of EU Cyber Resilience Act (CRA) compliance [Part 1]
• The scope of EU Cyber Resilience Act (CRA) compliance [Part 2]

Learn more about complying with the Cyber Resilience Act and protect your digital products from cyber threats

Read the overview