FAQ: What Does the EU Cyber Resilience Act (CRA) Mean for Hardware and Firmware Supply Chain Security
The European Union’s Cyber Resilience Act (CRA), Regulation (EU), 2024/2847, “aims to safeguard consumers and businesses” from risks introduced through the digital supply chain. To satisfy this regulation, countless organizations will have to change how they operate. This will require implementing rigorous supply chain monitoring and management practices, and ultimately adopting new cybersecurity technologies to assure that digital products reaching consumers and enterprises aren’t already hacked before they even arrive. The regulation specifies two major issues that it aims to improve:
“Two major problems adding costs for users and society should be addressed: a low level of cybersecurity of products with digital elements, reflected by widespread vulnerabilities and the insufficient and inconsistent provision of security updates to address them, and an insufficient understanding and access to information by users, preventing them from choosing products with adequate cybersecurity properties or using them in a secure manner.”
The breadth of this Regulation is enormous, and hinges on the key phrase “products with digital elements and all integrated components.” EU law has used the term digital element since at least 2019. Directive (EU) 2019/771 defined “goods with digital elements” as:
“any tangible, movable items that incorporate or are interconnected with digital content or a digital service in such a way that the absence of that digital content or digital service would prevent the goods from performing their functions.”
The CRA extends the definition by adding the phrase “all integrated components.”
“The vulnerability handling obligations set out in this Regulation, which manufacturers have to comply with when placing a product with digital elements on the market and for the support period, apply to products with digital elements in their entirety, including to all integrated components.”
The inclusion of the term “all integrated components” makes it plain that not only software, but also firmware and hardware are subject to the obligations laid out in the EU CRA regulation.
This term includes not only user-facing operating systems, but also embedded and non-embedded software and digital infrastructure systems that make up the full technology ecosystem.
Historically, cyber regulations have downplayed or omitted discussion of firmware security. As firmware vulnerabilities and attacks have increased, this is changing. Another recent example in this trend is the shift from Revision 4 to Revision 5 of the global cybersecurity standard documented in NIST 800-53, which specifically changed the term “software” to the more inclusive “software, firmware, and hardware.”
Q: What are the vulnerability handling requirements in the CRA?
The CRA states:
“Where, in the exercise of due diligence, the manufacturer of the product with digital elements identifies a vulnerability in a component, including in a free and open-source component, it should inform the person or entity manufacturing or maintaining the component, address and remediate the vulnerability, and, where applicable, provide the person or entity with the applied security fix.”
That means that a manufacturer of a laptop, server, or AI chip, is responsible for vulnerability handling in the firmware and hardware of chips they have purchased from other manufacturers, who have likely used components from yet another layer of manufacturers. This places an enormous burden for cybersecurity on the furthest downstream providers. A cloud services provider who purchases servers and AI hardware from NVIDIA could be held responsible for discovering and handling vulnerabilities in any of the thousands of chips, components, and firmware binaries present in their gear, even if they do not have direct access to the source code of those components.
In the case of free and open source components, that may mean the manufacturer submits a pull request to the open source repository. But in the case of proprietary components, such as chips, network interface cards, or other hardware with built in firmware, the manufacturer of a laptop or server may not even have direct access to the source code to be able to provide a fix. They can notify their supplier, but the supply chain may contain several layers, making it difficult or impossible for a downstream manufacturer to drive security fixes in a timely fashion.
The CRA also acknowledges that cyberattackers often chain together multiple exploits to take non-obvious paths from initial intrusion to total domination inside a target. The law explicitly includes language requiring that digital elements that are only indirectly connected to networks must still be secured.
“As cyber threats can propagate through various products with digital elements before reaching a certain target, for example by chaining together multiple vulnerability exploits, manufacturers should also ensure the cybersecurity of products with digital elements that are only indirectly connected to other devices or networks.”
When new vulnerabilities are disclosed in firmware or hardware components of products such as firewalls or VPNs, a common response from vendors is to say that the vulnerabilities being disclosed are not exploitable as long as the device is deployed as instructed, with the vulnerable components not exposed to the internet.
This has proven repeatedly to be a hollow excuse, as seemingly unreachable vulnerabilities are regularly exploited by savvy attackers who have evaded first line defenses. As the CRA notes, even indirectly connected devices are often used by attackers to move laterally or establish persistence once they have gained initial entry into a target network.
While supply chain security requirements like the CRA are an important step to protecting end users and enterprises, they do not remove the necessity for those end users to verify by their own means that the digital products they use are secure.
Q: What are the digital supply chain due diligence requirements in the CRA?
The CRA includes many clauses requiring that digital elements and integrated components be documented and that security updates be made accessible in a timely manner. Several statements in the CRA seem deceptively simple or obvious, but will actually create major challenges for manufacturers and sellers of devices with digital elements. For example, the text of the CRA states:
“The appropriate level of due diligence depends on the nature and the level of cybersecurity risk associated with a given component, and should, for that purpose, take into account one or more of the following actions: verifying, as applicable, that the manufacturer of a component has demonstrated conformity with this Regulation, including by checking if the component already bears the CE marking; verifying that a component receives regular security updates, such as by checking its security updates history; verifying that a component is free from vulnerabilities registered in the European vulnerability database established pursuant to Article 12(2) of Directive (EU) 2022/2555 or other publicly accessible vulnerability databases; or carrying out additional security tests. The vulnerability handling obligations set out in this Regulation, which manufacturers have to comply with when placing a product with digital elements on the market and for the support period, apply to products with digital elements in their entirety, including to all integrated components.”
The ability of a manufacturer to assess the security, up-to-date status, and lack of vulnerabilities in third party components varies widely depending on the component and the supplier. This is likely to be one of the most challenging clauses for manufacturers to meet.
Q: What are some examples of “Important products with digital elements?”
The CRA text contains several annexes providing comprehensive but not exhaustive lists of the kinds of products and services that are considered important products with digital elements. Annex III, in particular, names several components specifically containing or related to the firmware of devices, including boot managers, physical or virtual network interfaces, ASICs and FPGAs, among dozens of other examples.
Q: What are the Software Bill of Materials (SBOM) Requirements In the CRA?
The EU Cyber Resilience Act (CRA) mandates that manufacturers of products with digital elements must create and maintain a Software Bill of Materials (SBOM) for each product. This SBOM must be in a machine-readable format and include information about all software components, including firmware, and their dependencies. The CRA also requires manufacturers to manage vulnerabilities, conduct risk assessments, and provide comprehensive technical documentation.
Given the historical challenges in obtaining, maintaining, and using SBOMs, the requirements in the CRA may force changes throughout the entire supply chain to ensure compliance with the new law.
SBOM requirements laid out in the CRA include:
- Comprehensive Component Inventory: The SBOM must list all software components, including firmware, used in the product, from the operating system down to the smallest modules.
- Detailed Metadata: The SBOM should include metadata for each component, such as version numbers, licensing information, and known vulnerabilities.
- Machine-Readable Format: The SBOM must be in a format that can be easily processed by computers, facilitating automated analysis and vulnerability management.
- Regular Updates:The SBOM must be updated whenever the product’s software is modified, including patches and new features.
- Accessibility: The SBOM must be provided to market surveillance authorities upon request and included in the technical documentation.
Q: When Will CRA Be Enforced?
The CRA entered into force on December 30, 2024. Full enforcement of the CRA, including SBOM provisions, begins 36 months after the entry into force (December 2027). Manufacturers must be ready to report exploited vulnerabilities to ENISA (The European Union Agency for Cybersecurity) by September 11, 2026.
The CRA also contains numerous clauses requiring “timely” notification, disclosure and remediation around vulnerabilities. Not all of these instances specify a precise timeframe that would be considered timely, though. The requirements leave some flexibility, with the expressed purpose of not creating undue burden on affected organizations.
Q: How Does Eclypsium Support The Most Challenging CRA Requirements?
A major challenge in making SBOMs accessible and usable has always been the inconsistency of coverage across different types of digital elements. This is especially true for hardware and firmware components, partly because of the supply chain complexity of these components. For example, the original creator of a firmware package may make it available to downstream manufacturers, who may modify the firmware, create their own management interfaces for it, and change it to their own versioning system.
For end buyers, including enterprises, this can make it difficult to know which firmware version you have in subcomponents of endpoints, servers, and network equipment. Lacking consistent versioning makes it hard to track whether newly disclosed vulnerabilities are present in the environment, and whether patches are available or applicable to your specific version.
Eclypsium makes getting SBOMs much easier by extracting and analyzing the actual firmware that is in your environment. Instead of relying on manufacturers or systems integrators to provide an accurate SBOM, Eclypsium customers can scan their environment and automatically get SBOMs, including software, hardware, and firmware, from the devices actually deployed in their enterprise.
Furthermore, Eclypsium extracts, decompiles, and analyzes firmware binaries from devices in the environment to discover vulnerabilities. Instead of relying on version-matching, which is not dependable for firmware vulnerability detection, Eclypsium customers get deep analysis of the firmware that is actually deployed in their environment, providing a much stronger baseline from which to remediate vulnerabilities, improve security posture, and hold upstream supply chain vendors accountable for the vulnerabilities in their products.
For a summary of which EU CRA requirements Eclypsium fulfills, download our EU CRA Coverage Brief, or request a live demo to see how Eclypsium works in your own environment.
For information on how Eclypsium supports coverage of NIST 800-53r5, NIST 800-161, NIST SP 1800-34, NIST SP 800-193 and other regulatory guidelines used internationally, please visit our Regulatory Compliance page.
