1. What is Cyber Resilience Act?
The Cyber Resilience Act[1] (CRA) is a European cyber security law aiming at increasing security of connected digital elements. A summary of the law has been made available to the public, and is detailed here.
2. Impacted products
CRA applies to all products with a connected digital element, enhancing security through mandatory products and process requirements during the development lifecycle. Products are categorized according to their security related impact. Products under existing and mandatory application security regulations are excluded. This is the case, for example, of medical devices, who must comply with (EU) 2017/745, or in vitro diagnostic medical devices, who must comply with (EU) 2017/746. According to security impact, categories are defined, and a tentative list of products or applications is provided within Annex III of the law. If products are not listed within Annex III, they are considered to belong to the default class.
· Default class: All products not listed as security important nor critical
· Class I: Important products with security related functionalities
· Class II: Important products with security-related functionalities and tamper resistance requirements
· Critical class: Critical products
3. Timeline
The CRA's timeline includes vulnerability and incident reporting starting in December 2026, with full compliance required by December 2027. Products must be compliant if produced within Europe or imported to Europe after the application date. This means that products developed before the law are concerned.
4. Impact of non-compliance
Non-compliance can lead to severe penalties, including:
· Possible recall or withdrawal of products for non-compliance with cybersecurity requirements.
· Up to 15 M€ or 2.5% worldwide turnover for non-compliance with cybersecurity key requirements.
· Up to 5 M€ or 1% worldwide turnover for incorrect, incomplete or misleading information to the authorities.
5. Achieving compliance
To achieve compliance, products must implement the key security requirements listed by the law in Annex I:
• Risk assessment: a deep risk analysis, to be done starting from the product definition, to analyze potential risks and propose mitigations, updated during the device lifecycle.
• Secure by design (Secure SW life cycle): start implementing products with security in mind, instead of just adding security as an on-demand feature.
• No known exploitable vulnerabilities: be able to track impacting vulnerabilities and mitigate them to a low-level and acceptable risk, within all the supply chain, including software and hardware.
• Regular security updates: the capability to mitigate the severity of vulnerabilities by providing patches and/or updates is expected in most cases.
• Resistance to denial-of-service (DoS) attack: the capability to keep services running even during DOS disruptions, by limiting the effects of disturbances.
• Minimize negative impact on the availability of services provided by others
• Device protection (authentication, confidentiality, integrity): ensure that devices are genuine and avoid firmware exploits and malware injections.
• Software Bill Of Material (SBOM): provide an exhaustive list of software components used to build the products. The list shall include information such ownership, license, version, and copyrights.
• Vulnerabilities handling, monitoring, disclosure: vulnerabilities along the complete supply chain, including hardware and software, including open-source components, to be mitigated. Regular scans must be done to ensure that the product is safe over the product lifetime. In case of new vulnerabilities, the impact shall be assessed and mitigated. A robust security mitigation model is vital for identifying assets, threats, and common vulnerabilities, and for defining a protection strategy based on countermeasures. Severe incidents must be reported to ENISA[2] and CSIRT[3] with an early warning due in 24 hours, and a notification in 72 hours.
Finally, conformity assessment procedures may vary according to product security class. Starting from self-assessment for default product class to a full European cybersecurity certification based on EUCC. Vertical and horizontal harmonized standards are being defined to allow product self-assessments (called Module A assessment) and conformity assessments, based on full quality assurance for a group of products at organization level (call Module H assessment). Products belonging to the default class can claim compliance without the need for a harmonized standard.
6. CE marking
Products will bear the CE marking (EUR-Lex - 52022XC0629(04) - EN - EUR-Lex). Reference to article 29 & 30 of REGULATION (EU) 2024/2847.
7. Support period
CRA also mandates a security support period of at least 5 years, as well as the availability of security updates during 10 years after the support period. It also mandates information to final users, so that they can apply their security policies.
8. How ST can help for CRA compliance
The Cyber Resilience Act within Annex I lists all the essential requirements.
We propose here an answer to “how is ST helping for CRA”, by describing our secure activities and processes using this exhaustive list. For further detailed information on the availability of security solutions and security assurance by product, visit the STM32Trust webpage related product. Additional wiki pages with a dedicated chapter on CRA will be provided in the near future.
(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.
Security is part of ST DNA. Indeed, since many years ST is leading in security markets such as banking, digital identity, brand protection, eSIM, TPM. The know-how, skills, methodologies, infrastructures and processes have been extended to general purpose microcontrollers and microprocessors. Most of our certifications (such as ISO-21434) are shown on our corporate webpage. Other product related certifications, such as Common Criteria, EMVCo, GSMA, GSMA-SAS, ISO-27001, are also available, but limited to certain sites and product families.
(2) On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall:
(a) be made available on the market without known exploitable vulnerabilities;
ST has started a program of transparency regarding vulnerabilities since many years, with flaw reporting procedures that follow security standards:
· ISO/IEC 29147: Vulnerability Disclosure
· ISO/IEC 30111: Vulnerability Handling Processes
These are mandatory to pass security certifications like the one applied to many of our products, such as Arm® PSA, ISO21434 or Global Platform SESIP with a process audited and certified.
The list of product vulnerabilities is available on ST Product Security Incident Response (PSIRT) page, as well as our product page within the security documentation. We also invite users to scan the various public or private CVE & CVSS databases, and for Europe the European vulnerability database listing EUVD, relevant for CRA.
(b) be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state;
STM32 products are mostly delivered in user configurable forms and open for development, with lifecycle mechanisms to protect the parts once provisioned with firmware and secrets. All products include reset to factory mode, allowing full regression and reprogramming. OTPs are available on every product and cannot be erased.
(c) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;
STM32 products are hardware components, they cannot be updated in the field. In case of hardware vulnerabilities several mitigations may be proposed starting from software updates up to hardware fix. On the application side, secure update is one of our focused security functions. Depending upon the product, ST offers a variety of secure update solutions. These are described in our STM32Trust webpage or in our Secure boot and Secure firmware update wiki page.
(d) ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access;
Most of the STM32 devices have mechanisms to lock the Silicon device lifecycle, known as Readout Protections or Product State. They set limits, or prevent JTAG access. We advise developers to protect the integrity and authenticity of their code using Secure Boot mechanisms (see Secure boot and Secure firmware update). In some products with TrustZone® architecture (like those of the STM32H5 and STM32U3 series), solutions for attestation are available, including, in some cases, sets of attestation keys allowing seamless provision of initial certificates. Reporting unauthorized access is usually managed by the application itself, through hardware tamper mechanisms. This can be used to trigger logging of potential security breaches and prevent physical intrusions. We do also qualify partners to provide remote credential management and provisioning of attestation keys and certificates.
(e) protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state-of-the-art mechanisms, and by using other technical means;
To protect the confidentiality of data transiting over a communication link, cryptography is necessary. STM32 devices embed, in some cases, hardware cryptographic accelerators, random generators and keystore. These can be complemented by cryptographic libraries from ST or ST partners. Refer to Cryptography wiki page for more information. To protect confidentiality of data, cryptography can be used as well as Silicon device lifecycle and isolation.
(f) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions;
For this item, and in addition to solutions explained in (e), ST proposes several solutions of Secure storage.
(g) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);
Data minimization is mostly application context dependent. In no case ST products process personal information, unless specifically requested by the user.
(h) protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks;
Our physical disruption detection mechanisms, such as tampers, are fully configurable by the user and cannot block a system by default. This allows the developers to apply their own security policies, and ensure systems cannot be blocked during physical intrusion.
(i) minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;
This item relies on the ability to ensure devices are genuine and not subject to unwanted alterations. Use Secure boot and Secure firmware update to ensure the device is genuine, Silicon device lifecycle to avoid modifications, isolation of key secrets, attestation to prove the identity of the device and avoid cloning, Cryptography as a generic set of tools necessary for all steps. On some device several solutions are available to allow developers access to full security solutions such as Secure Manager or TF-M. Attestation keys and certificates are also essential, as described in (d).
(j) be designed, developed and produced to limit attack surfaces, including external interfaces;
The limitation of attack surfaces must be done on the application side by reducing the entry points to the device, using Silicon device lifecycle, Secure boot and Secure firmware update, isolation (in particular for the keys and device secrets, limiting via isolation the unnecessary access rights to the mandatory functions), and furthermore secure manufacturing allowing also to protect the device during its production,
(k) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;
This chapter talks about the reduction of the consequences of a security breach. Using best technics for isolation and using tamper detection mechanisms is essential. Limiting access only to security modules is a way to protect tampered devices. Tamper mechanisms of the STM32 allow to automatically erase sensitive information, blocking the device and preventing its misuse. This is of course under developer’s control.
The strong security assurance program from ST is again a way to ensure the device as well as its security functions were designed according to state-of-the-art technics, using standard methodologies assessed by external security notified bodies. STM32Trust provide a view on the certification targets of each product, however it is the responsibility of the developer to verify the validity and the scope of the certification directly on the SESIP and PSA websites.
(l) provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;
Developers may use all the security solutions provided by ST, however the final result remains an application-related concern.
(m) provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.
The Silicon device lifecycle allows a full erase of the device and a regression, erasing all memories except OTPs. When not possible, for devices in the field, device decommissioning is necessary. Device credentials, such as certificates and keys must be revoked by the application and at best logged into the application systems to prevent re-use of the device identities. Usage of “whitelist” / “blacklist” of devices is indeed recommended.
When using our partner solution for remote provisioning and remote credential administrations (see (d)) revoking mechanisms are in place and are at the heart of their solutions to allow sustain this requirement.
9. Risk assessment
ST does not provide direct risk assessment services, but provides various security solutions to mitigate the risks and security issues highlighted during the product risk assessment
- A scale of secure products associated with the level of security risk to cover
- Security functions covered by hardware, software or services and partner offers, and described within our STM32Trust webpage. STM32Trustprovides a framework to help developers to select the right solutions in hardware and software, as well as an ecosystem of security tools and qualified ST partners.
- A global security assurance program to provide transparency on the covered or claimed product functions, and to the targeted level. This allows developers to select the right device from the product definition stage. Refer to SESIP[4] and PSA[5] websites for official information.
- The vulnerability handling process has been in place for several years with public security advisories published and available on the PSIRT[6] page and on product pages.
- Secure software development is in place with:
- Security policies and levels set according to risk
- SBOM are available on most STM32Cube packages
- Automated vulnerability scans are under process
10. Where can I find further information on CRA by ST?↑
For further information, you can also watch the webinars part I and part II on the subject and download our detailed presentations and Q&A.
11. Conclusion↑
Achieving compliance with RED and CRA regulations goes through a strategic approach to risk assessment and the integration of robust security features. Leveraging solutions from providers like ST helps businesses meet regulatory requirements while protecting against security threats, ensuring product integrity and market trust. Adopting advanced security measures, conducting regular risk assessments, and maintaining effective communication about security incidents are essential for safeguarding digital assets. Staying informed about evolving regulations and collaborating with industry standards and legal entities will help businesses maintain security and compliance, crucial for long-term success.
12. References↑
- For further information, you can also watch the webinars part I and part II on the subject and download our detailed presentations and Q&A.
- STM32Trustsecurity framework
- STM32 Security wiki
- STM32H5 Secure manager - STM32TRUSTEE-SM | Product - STMicroelectronics
- STM32 classic-cryptographic library
- PQC compliant library allow users to start developing future proof cryptographic solutions.
- Product Security Response Team - PSIRT
- CRA Question and Answers (not yet available)
- REGULATION (EU) 2024/2847
- Cyber Resilience Act | Shaping Europe’s digital future
- Cyber Resilience Act Requirements Standards Mapping
- Visit ENISA web portal to get latest news and updates