Back

CRA compliance guide

| OTA, Security
Download now

Table of contents

Download now

Part 1: An Overview of EU Cyber Resilience Act (CRA) Compliance

An intro to the EU CRA

To address the growing concern over insufficient cybersecurity measures and the general public's lack of cyber awareness, the European Parliament officially enacted the CRA. This groundbreaking legislation introduces stringent requirements to bolster hardware and software security within products available in the European Union (EU). By targeting “products with digital elements” (PDEs) — a broad category comprising both software and hardware linked to connected devices — the CRA seeks to ensure that these commercial products meet robust cybersecurity standards. Non-compliance with the CRA could result in severe penalties, including fines of up to €15 million or 2.5% of global turnover and the potential loss of the CE mark, mandatory for selling products within the EU market.

“The comprehensive list of requirements in the CRA must be integrated into every step of a product’s lifecycle to maintain compliance – a heavy lift for manufacturers worldwide. Consequently, the substantial effort to comply requires over-the-air (OTA) infrastructure, tracking, documentation, and auditing.”

For manufacturers, achieving compliance with the CRA is a legal obligation and a significant challenge that requires careful navigation. The CRA takes a fully horizontal approach to securing PDEs, including requirements to:

  1. Available reset functionality: All PDEs must be manufactured in a secure-by-default state. If a vulnerability occurs, manufacturers must include functionality to rollback the device to its previously secure state.

  2. Compile a software Bill of Materials (SBOM): Manufacturers must maintain and update a comprehensive, machine-readable SBOM. The documentation must detail all software components and how they fit into the PDEs supply chain.

  3. Detect hardware and software vulnerabilities: The CRA requires regular security tests and audits to discover and remediate any security vulnerabilities throughout the device’s lifecycle.

  4. Publicly disclose vulnerabilities: Manufacturers must uphold a policy to publicly disclose vulnerabilities if and when identified through ongoing security tests. Information must be released to the public through a simple point of contact, similar to ongoing common vulnerabilities and exposures (CVE) reports.

  5.  Provide secure software updates: Throughout the lifecycle of PDEs, manufacturers must provide secure software updates to remediate identified vulnerabilities. Updates must be available free of charge on an opt-in basis.

The CRA aims to achieve the common goal of enforcing cybersecurity practices across all PDEs on the market within the EU. To reach this goal, the legislation pushes requirements across a widely defined range of products while emphasizing security and transparency throughout the PDE’s entire lifecycle. These requirements are all-encompassing and create specific challenges for manufacturers based on product type, OEM size, and overall market offering.

Essential requirements

The essential requirements of the EU CRA address cybersecurity at every level of a PDE, summarized by the following categories: 

Secure by design: The CRA mandates that products be built with security at their core rather than as an afterthought. Manufacturers must incorporate security measures from the earliest stages of design, such as:

  • Ensuring robust encryption for data, both stored and in transit
  • Implementing secure boot processes verifying the integrity of software before
    execution
  • Designing products to minimize attack surfaces and resist tampering

Vulnerability management: Manufacturers are required to maintain a proactive vulnerability management program to address security weaknesses throughout the product lifecycle, including:

  • Performing regular vulnerability assessments and penetration testing
  • Deploying security-related patches and software updates to mitigate discovered threats in a timely manner
  • Continuously monitoring products in the field to identify new vulnerabilities


Lifecycle management: The CRA includes efforts to continually monitor and secure the PDE throughout its lifecycle, not just at the point of manufacturing or product delivery, such as:

  • Securely distributing software and firmware updates and upgraded
  • Ensuring product robustness to be resilient against attacks and limit the impact on other devices if successfully attacked
  • Maintaining a comprehensive, machine-readable Software bill of materials (SBOM) 


The CRA takes its scope a step further by differentiating between different classes of PDEs based on their inherent risk.

  • Class I products: These PDEs are considered to be lower-risk products used in consumer settings or non-critical industrial operations. The full scope still applies, but the risk of non-compliance is generally lower.
  • Class II products: Products under this classification are typically higher risk, like firewalls and container runtime systems, requiring full quality assurance and intense auditing.

Aside from the class of product a manufacturer produces, the size of the OEM will create specific external challenges while attempting to comply with the CRA. While enterprises are generally more equipped than small and medium-sized businesses, both encounter roadblocks that must be overcome in the wake of the CRA.

  • Large enterprises: While larger companies often have dedicated security teams and budgets to address regulatory concerns, the complexity and scope of the CRA will still pose a significant challenge. Managing hundreds or even thousands of connected devices while ensuring updates are delivered securely and on time and maintaining an accurate SBOM will become overwhelming without the proper infrastructure or support in place.
  • Small and medium-sized OEMs: The CRA presents a challenge for smaller companies for different reasons. Limited resources and expertise make maintaining ongoing security measures and updating systems harder. Without a dedicated team, there is a greater risk of falling behind and spending resources on compliance that would be better used to get a product to market. 

While compliance is complex, non-compliance is out of the question for manufacturers that wish to continue to market their products in the European Union.

Part 2: The Scope of EU CRA Compliance

Understanding the scope of the CRA is the next critical step. It’s vital to grasp how PDEs fall under the CRA, the specific categories of software and hardware impacted, and key sectors that remain excluded from these regulations.

Understanding the scope of CRA compliance

The CRA focuses on ensuring that PDEs meet stringent cybersecurity standards throughout their lifecycle. PDEs encompass a wide range of hardware and software devices that connect to the internet or other networks and can be updated remotely. These products are required to maintain security, integrity, and transparency, ensuring that vulnerabilities are addressed and products are continuously monitored for risks.

PDEs under CRA

PDEs include any product that contains software or relies on digital infrastructure, such as smart devices, IoT systems, embedded software, and equipment with cloud connectivity. The CRA mandates that manufacturers implement processes to secure these products throughout the entire lifecycle, for example, during development, distribution, and post-market. The requirements are deeper than simply securing the software itself; manufacturers must go further and guarantee they distribute updates safely, address vulnerabilities promptly, and provide transparency across the entire product lifecycle.

Impacted categories of PDEs

The CRA impacts a broad spectrum of software and hardware-software combinations, including:

  • Embedded systems: Industrial controllers, sensors, and appliances that rely on integrated software.
  • IoT devices: Smart home gadgets, connected devices, and other internet-enabled equipment usually used throughout daily life.
  • Software platforms: Cloud-based services and applications that offer digital services to multiple users or businesses for remote data processing, including infrastructure, databases, and many software-as-a-service SaaS offerings.
  • Firmware: Any underlying software that helps manage hardware resources and software ecosystems. The CRA applies from the firmware level all the way up to the full operating system (OS) architecture. 

The CRA’s broad scope means that nearly every connected product must be compliant, and manufacturers need to ensure their devices are equipped to handle secure updates and protect users from potential cyber threats.

Key sectors excluded from the CRA

While the CRA takes a horizontal approach to cover all PDEs under market activity, specific sectors remain excluded from these regulations due to their unique nature or pre-existing regulatory oversight. These include:

  • Medical devices: These are regulated by specialized health and medical authorities, such as the European Medical Device Regulation (MDR).
  • Military hardware: Defense-related equipment is regulated separately, with security standards tailored to military and national security concerns.
  • Motor vehicles: Sector-specific regulations addressing safety and cybersecurity concerns govern automotive hardware and software. With the increased prominence of software-defined vehicles (SDVs),  regulations outside the CRA cover the automotive sector.
Apart from these exceptions, all other commercial PDEs are regulated, and non-compliance will be heavily penalized.

Part 3: Challenges in complying with the EU 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 PDEs throughout their lifecycle. These requirements, although essential, present significant challenges for manufacturers of all sizes.

Ensuring a secure-by-default product

The CRA sets the expectation that all 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 SBOM

The 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 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 rollouts 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. 

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

Learn More

Part 4: Proactive strategies to overcome 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. For instance, a robust OTA update infrastructure not only securely deploys software updates but can also automatically update the SBOM, support timely vulnerability remediation, and maintain a secure-by-default configuration. Without integration across these processes, manufacturers risk disjointed efforts that could compromise both compliance and security. Establishing security processes from the ground up can be daunting, especially for organizations without existing frameworks.

Navigating the complex requirements of the Cyber Resilience Act (CRA) calls for proactive strategies that account for all compliance elements holistically. Manufacturers need to design an effective infrastructure that seamlessly integrates secure software updates, SBOM management, vulnerability identification, and secure-by-default configurations. This infrastructure must be robust and agile enough to handle the evolving landscape of product security and the increasing scale of device fleets. While designing such an infrastructure is easier said than done, it is essential for sustaining long-term compliance and ensuring product security.

Proactive strategies for CRA compliance

The stringent and overarching requirements of the CRA demand a proactive approach to compliance, emphasizing security as a continuous journey rather than a one-time checklist. For manufacturers aiming to remain competitive in light of the legislation, adopting proactive strategies ensures compliance while further enhancing long-term resilience and trustworthiness of product offerings in the market. The following strategies are critical for long-term success while proactively preparing for compliance with the CRA:  

  • Establish comprehensive security processes: An essential aspect of CRA compliance is the establishment of thorough security processes that span the entire product lifecycle. This includes compiling and tracking a comprehensive Software Bill of Materials (SBOM) to maintain transparency, ensuring timely deployment of security updates, and adhering to strict protocols for vulnerability disclosure and remediation. By maintaining a proactive stance on these elements, manufacturers can safeguard products to align with CRA mandates and remain ahead of any possible audits. Expanding this further, investments in automated tools that facilitate continuous monitoring of software vulnerabilities and streamline patch management ensure compliance from a technical standpoint. Additionally, fostering a culture of cybersecurity awareness across both technical and non-technical teams ensures that every stakeholder understands their role in operational security and cyber resilience. This approach will bolster defense while minimizing the risks associated with non-compliance.
  • Integrate systems and processes for compliance: A siloed approach to compliance is inefficient and risky under the CRA’s complex legislation. Ensuring that all systems and processes are seamlessly integrated and secure is an essential aspect to maintain compliance with the CRA. This includes connecting tools for vulnerability management, timely update deployment, and compliance tracking to ensure a holistic view of the security landscape. By connecting these tools, organizations can mitigate operational risks and improve their ability to respond to emerging threats in a timely manner, satisfying an essential requirement of the CRA.

    Furthermore, integration reduces the administrative burden of compliance by automating repetitive tasks, reducing the risk of human error in cumbersome compliance documentation. Automations also ensure that security data is accessible and secure, to enhance efficiency while positioning the entire organization to remain adaptable and compliant. 

  • Adopt a secure-by-default approach: The heart of the CRA is its emphasis on the importance of prioritizing security from the outset. Adopting a secure-by-default approach means automatically configuring products to meet high-security standards upon deployment and ensuring these configurations remain intact throughout the product lifecycle. This approach requires a robust foundation, including the implementation of a secure over-the-air (OTA) update mechanism to address vulnerabilities as they arise. Furthermore, security features like a secure first-boot process and rollbacks ensure product security follows the device lifecycle, while it sits in stock, and throughout the onset of any vulnerabilities. Proper proactive implementation of a secure-by-default approach must also extend beyond technical implementation and be embedded within the organizational mindset. Manufacturers should conduct regular security audits, simulate threat scenarios, and enforce rigorous testing protocols before and after product launch. Adopting a secure-by-default approach aligns with one of the CRA’s most important regulations while further building trust with customers, partners, and regulators to strengthen product security and overall public image while securing compliance. 

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

Learn More

Leveraging a professional OTA for CRA compliance

Leveraging a professional OTA solution can significantly reduce the complexities and burdens associated with compliance, ensuring that security, scalability, and reliability are maintained throughout the entire product lifecycle. These solutions are designed to address the stringent requirements of modern regulations, such as data protection, software integrity, and cybersecurity resilience, without overwhelming internal teams or requiring extensive resources.

By adopting an OTA solution that integrates seamlessly with existing infrastructure, manufacturers can achieve multiple objectives simultaneously. It enables the efficient deployment of critical updates and patches, ensuring devices remain secure against emerging threats and vulnerabilities. This reduces the risk of non-compliance penalties and reputational damage while maintaining customer trust. Furthermore, such solutions allow manufacturers to optimize workflows, automate routine processes, and allocate resources more effectively, empowering teams to focus on driving innovation and enhancing the user experience instead of navigating the intricacies of regulatory compliance.

Ultimately, a robust OTA solution serves as a strategic enabler, helping manufacturers stay competitive in a rapidly evolving market by balancing the dual priorities of operational efficiency and adherence to regulatory standards.

Tags: OTA, Security

Download the PDF

To unsubscribe and for information on our commitment to protecting your privacy, please review our Legal page.