Introduction
As an increasing number of products offer connectivity and software integrations, cyberattacks continue to rise in prominence. According to the latest data (as of 2024), there are approximately 18 billion IoT devices worldwide, projected to increase to over 39 billion over the next ten years.
Manufacturers will face heightened risks of cyber attacks and noncompliance within the fast-growing digital landscape if they continue to rely on inconsistent update mechanisms and outdated security practices. The European Commission estimates the annual cost of cybercrime to the global economy at €5.5 trillion. High-profile attacks like the 2020 SolarWinds breach, one of the largest in history, and the WannaCry ransomware attack in 2017 highlight the growing prominence of breaches and the substantial need for updated security practices. These attacks affected tens of thousands of devices while causing immense risk to the security and integrity of users and operations worldwide. SolarWinds and WannaCry are only a fraction of cyberattacks occurring annually – a number that will only grow as connected devices increase their footprint across the digital ecosystem.
To address inadequate cybersecurity measures and the general population's lack of understanding of cyber risks, the European Parliament formally approved (March 2024) and adopted (October 2024) the Cyber Resilience Act (CRA) across Europe. This legislation is intended to ensure the security and integrity of hardware and software within products available in the European Union (EU) market for commercial activity, either free or paid.
The Cyber Resilience Act (CRA) takes a horizontal approach, introducing updated requirements for “products with digital elements (PDE).” The act defines PDEs as software or hardware associated with remote data processing solutions connected to a device or network that, if absent, would prevent the product from performing one of its specific functions. The use of a PDE must include a direct or indirect connection to a device or network. Notably, the CRA excludes products such as medical devices, military hardware, and motor vehicles, all of which must already comply with their respective industry-specific security regulations.
In full enforcement, the CRA ensures critical compliance through monetary penalties – €15 million or 2.5% of global turnover, whichever is greater. Additionally, breaking compliance could lead to the loss of the CE mark, a certification required for a product to be sold within Europe. Losing the CE certification effectively removes the product’s market approval.
The scope of the CRA and the severe consequences for noncompliance pose an immense challenge for all manufacturers in the supply chain of a connected product. Manufacturers must determine their responsibilities under CRA, understand the act's scope, and plan any necessary steps to achieve compliance.
Who must comply with the Cyber Resilience Act (CRA)?
Timeline: An overview of the Cyber Resilience Act
The Cyber Resilience Act legislation enters play as cybersecurity is emerging as a critical challenge for the European Union. With the number of connected devices growing exponentially alongside the onset of cyberattacks, the CRA aims to address cyber resilience within all devices containing digital elements.
The Cyber Resilience Act covers all products with digital elements (PDEs), with stricter requirements for Class I and II products, defined in Annex 3. The legislation aims to impose a horizontal cybersecurity strategy, that is, securing products (or components and subcomponents) throughout the supply chain instead of focusing on the particular final usage stage of the product. For example, instead of applying solely to an industrial automation robot (final usage stage), CRA applies to each programming device (including software) and software-only application used to create the final robot.
The Cyber Resilience Act (CRA) applies to physical PDEs as well as software-only products. Any software sold or made available within the European Union, whether as a standalone product or integrated into a broader product ecosystem, falls under the CRA's scope. The act's stringent cybersecurity requirements are fully imposed on software-only products, meaning developers must still ensure their products are secure by design throughout their lifecycle.
As such, the Cyber Resilience Act covers all new products with digital elements (PDEs) on the European Union market, from hardware-software combinations to software-only solutions. Manufacturers must understand whether the CRA applies to them as industries brace for the impact. (As previously mentioned, CRA only excludes the named industries with pre-existing regulations in effect.)
Additional CRA requirements for certain product categories
Article 7 of the CRA outlines stricter applications for PDEs with the core functionality of a product category classified as Class I and Class II within Annex III of the legislation. These specific products are considered critical if they perform essential cybersecurity functions, such as securing networks and preventing intrusions, or if they prevent significant risks that can disrupt other products or harm users, especially regarding network management and personal data processing.
CRA: Class I products
Class I products include software and hardware-software combinations essential for everyday cybersecurity and network management. These products are sold on consumer markets for end-user functions.
- Software-only products: These products focus on managing security, access, and network functions, such as password managers, standalone and embedded browsers, VPN software, antivirus software, operating systems, and security information and event management (SIEM) systems.
- Hardware-software products: These products integrate software with hardware to enhance security and functionality, such as identity management systems (including biometric readers), smart home security devices like smart door locks and security cameras, and routers/modems intended for internet connection.
For important products with digital elements that fall under Class I, if the manufacturer has not fully applied harmonized standards or if those standards do not exist, the product and its manufacturing processes must undergo either 1) an EU-type examination followed by internal production control or 2) a conformity assessment based on full quality assurance.
CRA: Class II products
Class II products include software and hardware-software combinations focusing on critical cybersecurity functions, such as securing and controlling virtualized environments and ensuring robust system protection. These products are sold in larger-scale enterprise markets.
- Software-only products: These products are essential for virtualized environments, such as hypervisors and container runtime systems.
- Hardware-software products: These products combine hardware and software to provide robust cybersecurity measures, such as firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers.
For Class II products, manufacturers must demonstrate conformity using procedures similar to those of Class I products, including an EU-type examination, full quality assurance, or, if available, a European cybersecurity certification scheme.
CRA requirements for software-only products
The CRA covers virtually any for-sale software products that connect to the internet or any network system, including:
1. Operating systems: Systems like Linux play a foundational role in managing hardware and must be built with security measures in place under the scope of CRA.
2. Antivirus and security tools: Antivirus software is crucial in protecting systems against malware and other security threats. These tools fall under strict CRA scrutiny as they are essential in maintaining digital ecosystems and fall under Class I and II classifications.
3. VPNs: VPN software is essential in encrypting internet connections and protecting user data. These software solutions fall under the full scope of the CRA.
4. Cloud-based and SaaS solutions: Even if the software is delivered via the cloud, it must meet the CRA’s extensive cybersecurity standards if it deals with remote data processing. Software as a Service (SaaS) platforms that fall under Class I and Class II and other cloud-based solutions must ensure the security of both the service and the underlying infrastructure remain compliant.
CRA requirements for free or open source software
Regarding open source software, if products with digital elements (PDEs) incorporate open source software and are classified under “commercial activity” within the European market, the regulations generally apply. For open source software, the specific circumstances of a product’s development and use (commercial) affect the application of the CRA on a case-by-case basis.
For example, open source software available for free online to explore and share is not a part of market activity. However, suppose that free software is either integrated into a product or supplied for distribution in commercial activities. In that case, this is classified as market activity and falls under the scope of the CRA. Once the open source distribution is run on commercial machines or generates money from its distribution, the software itself is subject to the full scope of the CRA. For example, all major Linux distributions are offered commercially through support or packaging and will, therefore, fall under the scope of the CRA.
Open source software components that are not monetized in any way but are intended for integration into products by other manufacturers are not considered market activity under the CRA. Generally, individuals contributing to an open source project and scenarios where donations are given for open source efforts will most likely be exempt from the CRA regulations. Furthermore, not-for-profit operations are not considered commercial activity. Even if a not-for-profit company creates PDEs that qualify as free, open source software, they are not regarded as a commercial activity if the organization is structured to reinvest earnings towards not-for-profit goals.
In summary, there are several cases where free or open source software (FOSS) falls under the CRA, including:
1. Commercial distribution: Selling or distributing FOSS as part of a commercial product or service.
2. Monetized integration: Integrating FOSS into a product with digital elements that the manufacturer sells or monetizes.
3. Paid support and services: Providing commercial support, maintenance, or customization services for FOSS.
4. Commercial licensing: Offering a dual-licensing model where the FOSS is available under a free license but also offered under a paid commercial license.
5. Commercial use by a business: When a company uses FOSS as a critical component in its commercial operations, such as incorporating FOSS into a for-profit sale software product.
Preparing for CRA compliance
The Cyber Resilience Act applies to a wide range of products with digital elements to address the growing number of connected devices and cyber threats. The CRA targets both software-only solutions and hardware-software combinations, imposing stricter requirements on critical products classified under Class I and II. While free and open source software (FOSS), by definition, falls outside the scope of CRA when used for non-commercial activity, it becomes subject to regulation if included with a commercial offering or integrated into commercial products or services. Class I products include essential cybersecurity tools like VPN software, operating systems, and smart home devices, while Class II products focus on critical cybersecurity functions such as hypervisors and firewalls. Manufacturers of these products must meet rigorous compliance standards, including EU-type examinations and conformity assessments, to ensure their products meet the CRA’s essential requirements.
As the CRA takes full effect, organizations at the highest risk of noncompliance have yet to prioritize security and lack processes and essential tools to ensure continued security and compliance.
Essential requirements of the Cyber Resilience Act
Annex 1 of the Cyber Resilience Act mandates in-depth cybersecurity requirements, ensuring PDEs are designed, developed, and produced to uphold a robust level of cybersecurity to mitigate possible risks throughout the product’s lifecycle.
While aligned to existing cybersecurity frameworks, the Cyber Resilience Act mandates addressing product cyber vulnerabilities. The US NIST Cybersecurity Framework (CSF) traditionally broke the process into five categories: identify, protect, detect, respond, and recover (later, adding govern in version 2.0). The CRA requires manufacturers to account for each step throughout their process and the PDEs' lifecycle.
First, organizations must maintain and track a comprehensive software bill of materials (SBOM) – akin to the identify category in the NIST framework. From there, PDEs must include a secure-by-default configuration (protect). The CRA introduces key provisions for identifying vulnerabilities (detect) and ensuring issues are remediated promptly through secure software updates (respond). All PDEs require the ability to reset to the original secure state (recover). Lastly, manufacturers must publicly disclose all vulnerabilities (govern) promptly, as public safety necessitates disclosure.
Maintain an accurate Software Bill of Materials (SBOM)
Annex I.2.1
By definition, many PDEs in the market integrate or communicate with other products and infrastructures in the supply chain. Similar to analog products maintaining a bill of materials (BOM) covering the hardware components and modules within the product, PDEs – products with digital elements – introduce software to the equation. Therefore, to comply with the CRA, organizations must maintain a comprehensive software bill of materials (SBOM), including creating a machine-readable format covering at least the top-level dependencies.
A software bill of materials (SBOM) is a formal, machine-readable record containing details on software components and how they fit into a PDE's supply chain. As software changes more frequently than hardware, the SBOM must also be continually updated and maintained. Software versions and patches are rolled out consistently; therefore, a compliant SBOM will be updated constantly to remain compliant. For example, each product update will introduce new software versions for some parts of the program, such as updating from version 2.2 to 2.3; in turn, the SBOM must also be updated to stay compliant.
If the SOBM is available to the user, the producer must also supply information on where consumers can access the document. When applicable, the SOBM is also instrumental in proving compliance with a market surveillance authority when checking alignment with essential requirements of the CRA.
Detecting hardware and software vulnerabilities
Annex I.1.2, Annex I.2.2, Annex I.2.3
Manufacturers of products with digital elements are required to identify and document vulnerabilities within their products. Regular security tests and reviews are required to maintain product integrity.
Public disclosure of vulnerabilities
Annex I.2.4, Annex I.2.6
Additionally, manufacturers must establish a policy for coordinated vulnerability disclosure enforcement, and measures should be in place to facilitate the reporting and sharing of information on potential vulnerabilities with a provided single point of contact. Upon releasing a security update, manufacturers should disclose detailed information about the vulnerabilities fixed, including their impacts and severity. However, if necessary, they may delay this disclosure to protect security until users can apply the update.
Then, companies must promptly address and remediate these vulnerabilities through security updates, ideally separate from functionality updates.
Remediating vulnerabilities through secure software updates
Annex I.1.3, Annex I.2.2, Annex I.2.7, Annex I.2.8
To ensure that products with digital elements remain secure, manufacturers must implement mechanisms for the timely and secure distribution of updates to address vulnerabilities. These updates must be available without delay and, where applicable, automatically installed to mitigate security issues.
Manufacturers must provide these updates free of charge, accompanied by clear advisory messages that include guidance on necessary actions. Additionally, security updates should be separated from functionality updates and delivered within an appropriate time frame.
For vulnerability remediation, deploying software updates over the air (OTA) presents the only practical solution to meet CRA requirements. OTA update infrastructure allows manufacturers to deliver security patches directly to devices while ensuring that updates are applied automatically or with user flexibility for postponement, maintaining high levels of security and user convenience.
Resetting the product to the original secure state
Annex I.1.3
All PDEs are required to be able to reset the product to its original state. Requiring a reset function ensures any products with digital elements are recoverable and not left in an inoperable state during a cyberattack or failure.
Traditionally, the industry refers to this functionality as a “factory reset” – resetting a device to its state when departing the factory. However, the traditional sense of resetting a device contradicts cybersecurity best practices and the intention of the Cyber Resilience Act.
The product software is still evolving from the time of manufacturing to the first device activation (when a device is in inventory). Security bugs, patches, and updates can occur and are deployed during this gap. As such, resetting a product to its original manufactured state does not necessitate security (as that state may have security issues that have since been addressed).
To reconcile the intention of CRA and resetting a device, manufacturers should be able to configure a device and restore it to its original secure state. Any fixed bugs, patches, or other security improvements should not be lost when ‘resetting’ the device. If remediations are lost on reset, the ‘factory reset’ state should also be configured to immediately update for any known vulnerabilities so that the device is in a secure state on reset.
Achieving cybersecurity throughout the product life cycle
The CRA implements these comprehensive requirements to ensure that products with digital elements (PDE) maintain a high cybersecurity standard throughout their lifecycle. Among the products covered by the Cyber Resilience Act, hardware-software comprising PDEs (also referred to as IoT, smart, or connected products) require the most effort to achieve satisfactory compliance. As manufacturers strive to meet these standards and maintain critical compliance, over-the-air (OTA) updates provide the infrastructure for delivering timely and secure updates and effective vulnerability management for IoT products.
Over-the-air (OTA) software updates: The linchpin to CRA compliance
Essential requirements for compliance are explicitly laid out within the Annex sections of the Cyber Resilience Act. Throughout these sections, over-the-air (OTA) software updates emerge as an essential function to achieve compliance.
Annex 1.2c states, “through automatic security updates that are installed within an appropriate timeframe, with a clear and easy-to-use opt-out mechanism.” Aside from the explicit requirement in the CRA for automated update mechanisms, it is infeasible to manually perform local security updates on IoT devices, especially when considering product scale and geographical location. Anything besides an OTA update infrastructure would consume more resources and time while creating inefficiencies that allow for security breaches at low product counts and become impossible at scale and growing complexity.
OTA software updates and IoT products
In the most basic sense, an over-the-air (OTA) update allows devices to receive and install updates remotely without physical or manual technical intervention. The process typically involves replacing the existing firmware or software with a new version via a connection, such as a cellular network. The update is received through the communication channel, replacing the current version.
How Over-the-air (OTA) Updates Ensure Security
Establishing an OTA update infrastructure allows manufacturers to manage and update their products quickly and at scale. Thus, to deploy security updates or patches, manufacturers must leverage an OTA update solution.
However, if the update fails, the system may also stop functioning. Or if an adversary breaches the process, the product may become unreliable (or worse, compromised). Even unintended scenarios, such as an employee making a mistake, can create insecure and potentially harmful outcomes, and a robust OTA update solution should consider such common cases.
As the Cyber Resilience Act prescribes, merely having a functional OTA update process is not enough; the OTA update infrastructure must “securely distribute updates.” The challenge of establishing a secure OTA update infrastructure lies in ensuring security across product lines, geographies, users, environments, and updates with increasing complexities.
Key security considerations for OTA updates and IoT devices
The affected digital landscape comprises billions of products with digital elements (PDEs) that require updates and continual maintenance under the CRA regulation. However, updating IoT, smart, and connected products presents unique requirements that differ from traditional cloud, IT, or operational technology (OT) offerings.
Establishing layered security
First, not only should the PDE have security built in, but the OTA update infrastructure must also have security built in to distribute updates securely. A CRA-compliant OTA update solution should encompass security best practices, including two-factor authentication, role-based access control (RBAC), and securing communication channels, such as mutual TLS (mTLS) and code signing verification or similar functions.
Security at the device level
Securing individual devices is essential in maintaining the integrity of an entire connected fleet. A CRA-compliant solution ensures all communications between devices and the OTA platform are encrypted and authenticated through mutual TLS. Code signing provides an additional layer of authenticity and integrity verification.
Importantly, device security is not a static state established at the point of manufacturing but must be ensured throughout the device lifecycle. There is often a gap between the time of software provisioning during manufacturing and the initial device activation and use—typically three to twelve months—during which new software updates are deployed. Establishing a secure first boot process where the device is updated automatically to the latest software version as its first action in the field ensures that devices in inventory remain secure when initially activated. Major botnets exploit known vulnerabilities within minutes, which highlights the importance of immediately, at first boot, carrying out an OTA update.
Similarly, managing and maintaining a secure original state for each device enables the ability for manufacturers to restore devices properly without introducing previously addressed vulnerabilities or bugs.
Security at the fleet level
Beyond individual device security, fleet-wide security practices are essential to maintaining CRA compliance in the diverse IoT landscape. To ensure security scales with device count and across the device lifecycle, functionalities like monitoring, configuration management, and remote troubleshooting are essential for rapid and compliant responses to any potential vulnerability.
In addition to ensuring a security update at first boot and secure original state processes across a fleet of devices, the management and synchronization between hardware and software versions must also be secured throughout the update process. Orchestration is a vital process in managing the security of an entire, often heterogeneous, fleet of connected devices. Secure orchestration tools enable maintained control over the deployment of updates across a fleet, ensuring consistent security and functionality.
As AI advances and its related products become available to the mass market, this process will only become more critical. AI, by nature, requires more frequent information input or updates to ensure the underlying models and algorithms continue to improve. Establishing a secure update process today ensures manufacturers are not only ready to achieve CRA compliance but also compete in an AI-driven market.
Security at the operations level
With the prominence and scale of connected devices, security extends beyond the device level. Securing the people and processes that manage these systems plays a pivotal role in secure device management. After all, if the wrong person gains high-level access to the OTA update infrastructure, all devices can be instantly compromised. Role-based access control (RBAC) ensures that only authorized people can perform critical operations regarding software changes. Limiting permissions with RBAC reduces the risk of insider threats and human error. Additionally, two-factor authentication (2FA) adds an extra layer of protection, preventing unauthorized access even if one set of credentials is compromised.
An additional component and CRA requirement is the software bill of materials (SBOM), which contains details on software components and how they fit into a PDE's supply chain. As each software update poses changes to the SBOM, each deployment and updated device needs to be tracked with the relevant SBOM updated. Utilizing audit capabilities to update the SBOM continuously ensures CRA compliance while maintaining a clear record of software dependencies and overall security status.
Finally, detailed documentation, reporting, and audit logs should be maintained to track actions taken and help troubleshoot or identify any issues that arise, including the required software bill of materials (SBOM).
Ensuring product robustness
The Cyber Resilience Act aims to ensure the security of products with digital elements. As seen in other sectors, security, and safety often go hand in hand. A failed device update could render the product inoperable, potentially creating negative or even severe consequences. For example, the recent Crowdstrike outage caused worldwide downtime across various operational sectors. In turn, the incident created massive disruptions in day-to-day operations and global supply chain communications. The outage resulted from an erroneous update applied en masse and could have been avoided using robust and secure OTA update features such as phased rollouts.
The OTA update infrastructure must consider robustness to ensure security and avoid downtime to manage the overall customer experience. The OTA update solution should include an integrity checksum functionality to avoid device corruption – an end-to-end verification process on both the device and the update to be applied. In the instance of update failure, automated rollback functionality ensures the device is left functional and not inoperable.
The update deployment of the OTA infrastructure should also be flexible and granular to manage risk further. For example, full image updates can ensure consistent software across a product fleet or line. Functionality, such as automatic update retry and phased rollouts (or canary deployments), minimize the risk of large-scale update or device failure. Empowering OTA infrastructure with these robust features improves the overall customer experience while combating downtime and possible openings for security vulnerabilities. Robust feature sets drastically reduce outages, product recalls, and software or firmware incompatibilities, ultimately improving brand image and customer usability.
For IoT, smart, and connected products specifically, manufacturers must also consider the inventory and sale processes to ensure robustness and security. For example, after a new PDE is manufactured, it might spend several weeks or months in transit, inventory, or on a shelf. Over that period, new vulnerabilities, bugs, or patches can also be discovered, meaning that when the product is first activated, its software will already be outdated and potentially insecure. The OTA infrastructure should also facilitate a first boot update and retry support to manage the realities of the product’s lifecycle. To ensure a secure update process, manufacturers should leverage an OTA infrastructure that ensures robustness throughout the update process and product lifecycle.
Contextualizing the IoT environment
Compared to large cloud and IT systems, IoT devices operate in diverse, heterogeneous environments, making common update solutions inadequate. Similarly, while also widely used, public cloud IoT services often fall short of addressing the specific security and functionality requirements of IoT, smart, and connected products. When strategizing to maintain compliant products with digital elements, manufacturers must understand the limitations of existing update tools and the importance of establishing a purpose-fit secure software update strategy for IoT products to maintain ecosystem integrity and performance.
Cloud and desktop IT update solutions
Common IT update tools for cloud, mobile, and desktop devices are not a suitable solution for IoT products as they are not designed to handle IoT systems' unique constraints and environments.
Under the scope of CRA, connected devices require continual software and firmware updates; managing and updating connected devices presents challenges in security and scalability, jeopardizing CRA compliance. With a large footprint of connected IoT devices, the attack landscape and vectors are more numerous, creating a heightened need for robust security often absent in desktop IT solutions. Attempting to deploy updates across a heterogeneous pool of devices is challenging as cloud and desktop IT solutions often roll out inconsistent updates to devices even in much more homogenous network environments. For example, the KB5028185 update for Windows 11 in 2023 led to reports of boot loops and network connection problems for some users despite working fine for others due to hardware variations where the update was applied. If desktop environments are already struggling with consistent updates from cloud and desktop IT solutions, the challenges only become more significant in the more complex IoT landscape. Given the complexity of IoT environments and the broad scope of the Cyber Resilience Act, more than a desktop IT solution is needed, and professional OTA will be essential to remain compliant and secure.
Second, cloud and IT desktop solutions often require stable connectivity. However, connectivity is not always present in the realm of IoT devices. For example, a maritime smart device existing at sea may have limited bandwidth to utilize or smart cameras in remote locations may be unable to access stable connections. In scenarios with unreliable connectivity, cloud and IT desktop solutions are inadequate.
A suitable OTA update solution for IoT products requires robust features that solutions built for IT do not provide nor are intended for, such as A/B partitions and delta update capabilities that ensure deployments reach the whole system while supporting the environmental limits of connectivity. Furthermore, a one-size-fits-all approach from a standard IT solution is often not compatible with the inherent heterogeneity of IoT devices, leading to more frequent update failures or system outages. Specialized IoT OTA update solutions provide more granular control over the update process, ensuring all devices receive the necessary updates without compromising security or performance.
How A/B and Delta Updates Ensure IoT Device Integrity
Public cloud IoT services
Many public cloud providers offer basic IoT services to connect devices and, in some cases, manage jobs to devices. These services are sometimes promoted as a solution for OTA updates as well. However, they should only be seen as building blocks for a small aspect of complete OTA updates or device management, like communication or obtaining a list of devices. The rest is left to the customer, especially the critical and challenging parts of device-side integration, security, and robustness.
While advantageous in some facets, public cloud IoT services fall short in several critical areas for an optimized IoT environment. First, today’s public cloud services often lack essential device-side software by usually only offering a simple SDK to communicate with the cloud – meaning it was not designed to manage the unique requirements of IoT devices end-to-end. The limited device-side software creates a substantial gap, resulting in an incomplete and fragmented approach. To create the device-side software, manufacturers must undertake additional development efforts to integrate and support OTA on the devices themselves. In doing so, manufacturers must also ensure the security and robustness required by CRA within their internal development, testing, quality assurance, and deployment processes. When a new product revision or line is to be launched, this entire cycle must be repeated, and so the approach is not future-proof.
Most cloud-based IoT solutions aren’t ready “out-of-the-box.” When preparing for CRA compliance, leveraging cloud IoT solutions requires additional development efforts to get started and operational and security risks to manage and maintain. The use of public cloud "building blocks," like communication channels, databases, and API gateways, further complicates leveraging cloud solutions for OTA – adding to the development burden with more configuration, integration, management, and maintenance requirements.
In the long term, cloud solutions create a dependency on specific cloud providers, resulting in a vendor lock-in scenario; vendor dependence is often costly and limiting as organizations, products, and the IoT ecosystem evolve, cloud offerings are sunset, and prices increase.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Managing growing complexity
As with most security measures, the requirements of the Cyber Resilience Act are relatively simpler in environments with lower complexity. Achieving compliance for a single product is less complex than a product line, and a product line is less complex than multiple product lines. As complexity expands, so does the difficulty in ensuring robust security and achieving compliance with security regulations like the CRA.
For IoT, smart, and connected products, complexity is inherently vast. There are often multiple products, product revisions, product lines, distribution channels, geographical locations, embedded consulting vendor relationships, and more to manage. Underneath the product, there are multiple hardware and software vendors to manage—and with each, compatibility and dependency considerations must be accounted for between hardware matched to software versions plus horizontal hardware-software version compatibility.
When examining complexity at a level higher than the product, time zones, connectivity, and regional and local regulations must be taken into account. An update with the CRA-required user acceptance, for example, will need to be deployed based on the time zones and potentially days (e.g., to avoid holidays) of the devices’ physical location.
This is not to mention the monitoring, configuring, and troubleshooting required to ascertain whether a product issue is a security vulnerability—perhaps a zero-day attack—or a device, user, or other type of issue.
The OTA update infrastructure needs to be built with complexity in mind to distribute secure updates to PDEs. The OTA update solution needs to manage complexity and do so in a manner so that manufacturers can issue security updates in a timely fashion, notify the public appropriately, and manage their products throughout the lifecycle, distribution, connectivity, and, in the worst-case scenario, a straight-on cyberattack.
While some alternative OTA update solutions from IT to bespoke homegrown systems can handle some of the previous considerations, very few can manage the complexity PDEs encounter or the functionality the Cyber Resilience Act requires to ensure true security. The solutions that encompass all of the security considerations and achieve compliance evolved over time – and with it, massive investments in time, money, human resources, risk of knowledge loss with staff and vendor changes, and lessons learned.
Bespoke, homegrown OTA alternatives
The Cyber Resilience Act (CRA) allows for both a commercial or homegrown OTA infrastructure. Building an OTA update mechanism in-house often seems like an attractive option, but it poses significant challenges and risks, especially in the context of complying with the Cyber Resilience Act (CRA).
For homegrown OTA systems, a central pitfall is the extensive time required to achieve CRA compliance. Homegrown solutions typically center around one problem to be addressed, such as a single type of OTA update on a specific hardware. The resulting system is built only to address the problem at hand and rarely encompasses unforeseen requirements like regulatory compliance. As a result, most homegrown solutions lack the necessary documentation on security protocols and OTA processes required for audits and demonstrating CRA compliance. Without sufficient documentation, it is nearly impossible to prove that your homegrown OTA tool meets the required security levels or has the essential feature set mandated by the CRA. In most cases, homegrown systems evolve over time with partial know-how from staff that move to new projects and even leave the company. Retroactively creating the required documentation to ensure CRA compliance is exceptionally challenging and, indeed, a significant security risk in general.
Homegrown OTA solutions often lack the advanced feature set necessary to comply with the CRA. For example, visibility into which products in the field possess a security vulnerability is typically missing in homegrown solutions, a critical function to ensure timely and secure updates. Other vital functions that homegrown OTA systems miss include user confirmation, scheduling of updates, and automatic creation of software bill of materials (SBOMs), all capabilities required to meet CRA standards.
Aside from CRA compliance, there are countless examples of homegrown OTA systems pushing out failed updates, which cause immense disruption, bricking entire fleets and leading to security concerns amid downtime. For instance, in 2023, Rivian experienced an infotainment system outage, where vehicle owners could not access their vehicle’s infotainment system and main display screens due to an incorrect build update deployed over the air. To get past the ‘bricked’ device, vehicle owners had to either wait for a new update, effectively losing access to vehicle displays or go in for a physical maintenance appointment. The Rivian infotainment outage, resulting from an erroneous OTA update, created significant downtime, possible data loss, and security concerns for owners across the globe. For Rivian, it meant negative news coverage and unhappy customers – in other words, major brand damage.
Furthermore, whether handled in-house or outsourced to a consulting firm, custom development projects like a homegrown OTA system notoriously encounter unforeseen issues that arise during development, creating additional risks and challenges to overcome. OTA capabilities are a critical infrastructure governing the entire product fleet. Without specialized expertise, there is a risk of subtle security compromises, potential product downtime, and severe penalties for CRA noncompliance.
Additionally, a homegrown OTA solution often limits the ability to future-proof device infrastructure. As new security gaps and needs emerge over the years, the continuous development, discovery, and patching of the OTA update system drains resources and creates a maintenance burden. The homegrown system’s drain on resources not only diverts attention from product differentiation in the marketplace but also increases the risk of being locked into a custom system struggling to be adequate rather than ensuring robust and secure OTA update delivery – as required by the Cyber Resilience Act.
Relying on or evolving a homegrown solution to achieve compliance with the Cyber Resilience Act requires significant additional investments, expertise, and management and is commonly fraught with unforeseen issues, risks, challenges, and ongoing maintenance. As a result, homegrown solutions risk the core business, significantly delaying time to market or missing launch dates. Regarding compliance, bespoke or homegrown solutions are not recommended as they typically lack the documentation, security, robustness, and advanced functionality to satisfy the secure update distribution requirements of the CRA.
Establishing a secure OTA update infrastructure
The most comprehensive requirement of the Cyber Resilience Act is the ability to enable secure software updates. Annex 1.2.7 of the CRA states explicitly that “manufacturers of PDEs must provide for mechanisms to securely distribute updates.” The ability to securely distribute patches is paramount in identifying a proper solution for managing OTA updates.
As such, OTA update infrastructure solutions are likely considered a Class I product under the Cyber Resilience Act, potentially falling under configuration management solutions. Therefore, they must also comply with CRA requirements in and of themselves. With a horizontal cybersecurity strategy underpinning CRA, the OTA update infrastructure should comply with CRA, whether commercially available or internally built and homegrown.
Compliance with the requirement to deliver a secure deployment demands planning and implementing preventive strategies so manufacturers ensure their devices remain resilient against evolving threats. Secure software updates are a critical defense mechanism that safeguards devices, data, and users. An essential requirement of the CRA, implementing a secure-by-design OTA strategy can ensure PDEs comply with regulations and maintain the highest security and reliability standards throughout their operational lifecycle.
Selecting the proper OTA solution is critical for compliance and long-term success in the wake of the CRA. Given the difficulty and nuance of the IoT environment and the heavy security regulations from the CRA, there are countless considerations when selecting the correct strategy for compliance. The CRA requires a secure system to deploy changes, audit patches to compile a Software Bill of Materials (SBOM), and provide timely documented updates to maintain security throughout the IoT lifecycle. The proper solution will integrate easily, bolstering compliance and minimizing resource drain to stay ahead of all requirements proactively.
The requirements of the CRA make it nearly impossible for organizations to build and maintain a compliant OTA update mechanism from scratch without significant risks, challenges, and delays. Furthermore, as OTA update solutions themselves are likely to be considered Class I products under the CRA, any homegrown solution itself would be under that same CRA scrutiny. If OTA infrastructure is considered Class I by the CRA, the manufacturer must take additional steps to apply harmonized standards and conduct a conformity assessment. These additional requirements pose an even deeper burden for compliance on top of the already extensive difficulty of developing homegrown OTA. Purpose-built OTA update solutions offer manufacturers a comprehensive and compliant infrastructure, meeting CRA regulatory standards, among others, while delivering additional advantages out of the box.
For CRA compliance, the OTA update infrastructure should offer and facilitate the following:
- Efficient over-the-air updates: Provide a complete end-to-end infrastructure for automatic security updates, ensuring timely and cost-efficient deployments across all devices. By automating these updates, the OTA update infrastructure aligns with the security and vulnerability management requirements, reducing the burden on the internal compliance team.
- Total control over the update process: Provides flexibility in managing software updates. Manufacturers can tailor the update experience, offering users options to approve or delay updates directly on their smart devices. Furthermore, server-side API integration and dynamic grouping capabilities allow for precise control over update preferences, ensuring that different products can be updated according to exact specifications.
- Secure update process: Incorporate industry-leading security measures such as role-based access control (RBAC), device authentication, and digital code signatures to ensure that devices are protected throughout the update process. Robust security features are not only well-documented but also heavily tested across millions of devices, making the OTA update infrastructure a reliable choice for secure software distribution.
- Total SBOM control and secure reset with full image updates: Versatile support for various update types, including full image updates, provides manufacturers with total control over the software bill of materials (SBOM). Regular full image updates ensure consistency and offer a secure reset option, fully aligning with CRA requirements (Annex 1.1.3) – cost-efficiently and maintaining a secure and consistent IoT environment.
- Identify vulnerable products in the field and target disclosure to owners: Software inventory capabilities allow manufacturers to quickly identify which products in the field are affected by newly discovered vulnerabilities. The level of precision facilitates thorough impact analysis and ensures that manufacturers can coordinate vulnerability disclosures effectively, meeting the CRA's requirements for transparency and security.
Considering the complexity of IoT device management, compounded with the intense requirements of the CRA, OTA updates are essential for manufacturers working with connected devices. Using a homegrown solution is a heavy lift that lacks future-proofing and is guaranteed to create larger problems in compliance and connectivity down the line. Furthermore, cloud IoT solutions generate expensive lock-ins and lack customization and purpose-built security needed out-of-the-box. A purpose-built OTA solution is an investment in the future security, efficiency, and success of a product in the wake of the extensive requirements of the Cyber Resilience Act.
CRA compliance for consulting and service providers
The stringent requirements of the Cyber Resilience Act demand a new level of embedded, IoT, and connected device expertise, documentation, and ongoing support to establish a compliant OTA update infrastructure. Few manufacturers, in-house software, third-party developers, service providers, and consulting companies possess all the internal knowledge to develop, manage, and maintain a compliant OTA update solution. As a result, consulting companies and service providers are realizing a new opportunity and trajectory regarding OTA update systems.
Rather than attempting to develop custom OTA update solutions that meet CRA standards, the most strategic and client-focused consultants and service providers are adopting a best-of-breed approach.
A shift in approach: Managing the complexity and depth of the CRA
Building an OTA solution that complies with the CRA is no longer just about deploying patches as needed; it's about ensuring that every aspect of the system, from design to deployment, meets the highest security standards. A compliant OTA update infrastructure requires a level of specialization that is difficult to achieve without the backing of a dedicated OTA solution.
As such, partnering with professional and proven OTA vendors brings the necessary technical expertise alongside the extensive documentation and support needed to satisfy CRA requirements. Professional solutions are built with compliance in mind, ensuring systems are secure, future-proof, and capable of handling the evolving cybersecurity landscape. By partnering with these vendors, consulting companies can better serve their clients, helping them avoid the pitfalls of homegrown solutions, such as inadequate documentation and security vulnerabilities.
Within the scope of the CRA, successful consultancies are not the primary developers of OTA systems; they act as strategic advisors who guide their clients toward the most secure and compliant solutions. The best decision for a consulting company is to align with a professional OTA vendor, ensuring that their clients meet CRA requirements while maintaining a robust and secure future-proof OTA infrastructure.
Get started: Comply with the Cyber Resilience Act
Considering the challenges and complexities involved in CRA compliance, selecting a market-leading OTA update solution with a proven track record in the field is the ideal solution for organizations seeking a secure, reliable, and comprehensive OTA platform. Choosing Mender as your OTA solution ensures compliance with the Cyber Resilience Act (CRA) while also offering a range of benefits that streamline operations and secure your devices.
Ensure regulatory compliance: With built-in features that address CRA requirements out-of-the-box, Mender upholds regulatory compliance while remaining prepared for future changes. A professional OTA provider handles this burden, Mender offers secure software updates that meet all CRA requirements, including enabling end users to control the update process, secure update mechanisms, comprehensive CVE (Common Vulnerabilities and Exposures) reports ready for public disclosure, and necessary documentation for audits. Mender lowers compliance risks and ensures ongoing alignment with the latest regulatory standards.
Accelerated time-to-market: Designed to be easy and efficient, significantly reduce the time spent on compliance work and development efforts, enabling manufacturers to hit critical timelines and stay ahead of competitors. Unlike homegrown solutions, which can delay market launch by 6 to 12 months, Mender is ready to deploy almost immediately.
Reduce operational costs: Developing and maintaining an in-house, compliant OTA solution is a heavy lift that creates countless operational burdens to simply enable OTA. Operational burdens drastically increase when attempting to add robust features such as delta updates, network support, and remote troubleshooting. Mender eliminates these expenses, offering a cost-effective solution that saves both time and money.
Manage complexity: Launching a new IoT product is already a complex process. Adding the burden of developing and maintaining an OTA system across product lines, software versions, hardware components, and heterogeneous suppliers increases the challenge. By choosing Mender, manufacturers can focus on solving core market problems while leaving the intricacies of OTA management to the experts.
By choosing Mender, manufacturers opt for a battle-tested, comprehensive, secure, and well-supported OTA solution that simplifies compliance with the CRA while enhancing control over software updates, security risks, and administrative burdens. A partnership with Mender provides more than an OTA software update tool—Mender provides a best-in-class strategic asset in maintaining the security and reliability of smart products, ready to deploy out-of-the-box to future-proof infrastructure and ensure growth throughout the heavy regulations of the CRA.
The role of over-the-air (OTA) updates in EU CRA compliance - A comprehensive guide
Mender: General Solution Overview
