Deep dive on EU CRA for STM32 MPU

Applicable for

STM32MP13x lines, STM32MP15x lines, STM32MP21x lines, STM32MP23x lines, STM32MP25x lines

---

1. Prerequisites

This article contains information about the European Union Cyber Resilience Act (CRA) for STM32 MPU.

Information about the STM32 microcontroller (MCU) CRA is available in the article Deep_dive_on_CRA( This page is hosted in the STM32 MCU wiki. Selecting the link opens a new tab. Be aware that visiting this page leaves the STM32 MPU wiki).

2. Introduction Q&A for CRA

ST encourages readers to access the following European Union (EU) Cyber Resilience Act (CRA) documents:

• EU Cyber Resilience Act law
• CRA Implementation Act for "Important" and "Critical" products: technical description of the categories
• Implementation frequently asked questions (FAQ) : preliminary set of technical questions

3. Disclaimer

This article, which is associated with ST deliverables, attempts to interpret the current status of the CRA regulation and its impacts, and to help customers and developers prepare for future compliance requirements. This article does not provide a legal interpretation of the regulations. Some of these interpretations might vary, and changes might occur over time.

Industry standards bodies and consortia are actively working to clarify applicability and conformance.

All information and links are subject to change.

4. CRA scope

CRA defines products to which CRA does not apply, for example, medical devices under Regulation (EU) 2017/745.

The CRA implementation frequently asked questions (FAQ) clarify the interplay with other EU legislation, including civil aviation, marine, product liability, machinery, general product safety, RED, the European Health Data Space, the General Data Protection Regulation (GDPR), and the Data Act.

4.1. Device Classification

The objective of this classification is to define the Cyber Resilience Act (CRA) conformance process.

The essential cybersecurity requirements are the same for all product classes.

At the initial stage, you must highlight the core functions of the device.
Then search, in CRA ANNEX III , the most appropriate product category and the related class to which the product belongs.
If the product is listed, the product belongs to the Important, or Critical classes. If not listed then the product belongs to the Default class. Refer to CRA ANNEX IV " of the CRA for critical products.

The technical description of each product category available in Annex III and Annex IV of the CRA, are given the CRA CRA Implementation Act .

This classification defines the conformity assessment procedure that applies to the product.

4.2. STM32MPU classes

CRA ANNEX III explicitly defines two classes for microprocessors as follows:

• Class I: microprocessors with security-related functionalities
• Class II: tamper-resistant microprocessors

Note: If the MPU does not include security-related functions, it belongs to the Default class.

CRA Implementation Act introduces a minimum physical robustness requirement following:

• Class II products: with AVA_VAN.2 or AVA_VAN.3
• Critical products, with at least AVA_VAN.4

Notes:

1. AVA_VAN is a common criteria assurance component for vulnerability assessment. The numbers 2, 3, and 4 indicate the assurance level.
2. AVA_VAN.3 means that an accredited laboratory evaluated the physical robustness against moderate cybersecurity attacks.

STM32 microprocessor units (MPUs) feature security functions. As a result, they are classified as Class I or Class II, depending on their security features. STM32MP13 and STM32MP2x are SESIP Level 3 certified with AVA_VAN.3 certification:

• SESIP Level 3 STM32MP13 Security Target
• SESIP Level 3 STM32MP25 Security Target

STM32MP15 is not SESIP certified. Class I does not require AVA_VAN physical robustness.

ST will deliver a declaration of conformity for its STM32 microprocessor units (MPUs) based on either self-assessment for Class I or third-party assessment for Class II.

Note: As standardization work is ongoing, this statement may change.

4.3. Software Bill of Material

Providing a software bill of materials (SBOM) in response to an explicit European Commission request is a mandatory requirement of the Cyber Resilience Act (CRA). The rational of this request is to make possible investigation or surveillance.

Because SBOMs can disclose sensitive information, it is recommended to control their publication. As general rule, SBOM publication policy should be aligned with package publication policy.

Several SBOM formats exist. The most commonly used formats are CycloneDX and SPDX. SBOM format converters and SBOM viewers are available, they can be free or commercial.

It is recommended to consider SBOM confidentiality before using an online viewer or converter.

An SBOM provides transparency about software composition, including component names, licenses, and releases.

SBOM formats can support vulnerabilities information:

• CycloneDX case: Security Use Case: Vulnerability Exploitability | CycloneDX
• SPDX case: SPDX Capturing Software Vulnerability Data in SPDX 3.0 – SPDX

Vulnerability scanners are mainly using SBOM as input to identify components then to search for public vulnerabilities into databases.

Open source communities already deploy SBOMs. For example, the Yocto Project provides documentation for creating a software bill of materials.

ST SBOMs (CycloneDX) do not provide vulnerability information. ST SBOM is updated for each package's release.

For Yocto-based OpenSTLinux embedded software and other flavors, ST publishes SBOMs for STM32MPU software components.

For Bare metal - RTOS embedded software, ST publishes STM32MPU SBOMs in the same way as STM32MCU SBOMs. ST decided to provide SBOMs for its X-CUBE or X-LINUX deliveries that are distributed according to the software security level. When ST distributes them publicly, they are available in the ST GitHub repository.

5. Simplified proposed guidelines

5.1. What should I do?

1. Determine whether my product is covered by the Cyber Resilience Act (CRA).
2. Determine the applicable CRA conformity assessment procedure.
3. Identify the associated obligations.

5.2. Is my product concerned by CRA? 

The Cyber Resilience Act (CRA) is mandatory for products sold on the EU market that feature digital elements.

Exceptions:

• Products already regulated by regulations recognized by the CRA, such as medical, automotive, and aviation products.
• Spare parts: Products already present in the EU can be repaired. A functional update is in the scope of the CRA.
• Products that feature neither a logical nor a physical interface.

5.3. What is the associated CRA conformance assessment procedure?

The Cyber Resilience Act (CRA) essential requirements are the same for all products, but the conformance assessment procedure differs according to the four defined classes:

• Default Class: Conformance through self-assessment
• Important Product Class I: Conformance either through self-assessment if harmonized standard exists OR through 3rd party assessment
• Important Product Class II: Conformance through 3rd party assessment
• Critical Product: Conformance through 3rd party - European cybersecurity certification scheme EUCC

5.4. What are my obligations?

5.4.1. Risk assessment

CRA mandates risk assessment

• For Default and Class I, the CRA does not mandate any method.
• For Class II and the Critical class, the method shall be aligned with the targeted vertical standard.

ST does not promote any tool or method in this area. Many tools and methods exist, from simple to complex.

Note: CRA defines multiple standards:

• Horizontal (cross sectors): Vulnerability handling, secure development lifecycle, generic technical security requirements, security updates & support
• Vertical (per sector/product): adds domain-specific security on top of the horizontal baseline. For example: Industrial, Rail, Energy, Class I MCU/MPU, Class II MCU/MPU, Smart Cards...

5.4.2. Vulnerabilities reporting

CRA defines different communication actions depending on the type of vulnerabilities.

CRA reporting obligation scope (Article 14) applies to "actively exploited vulnerabilities" and "severe incidents". The application date is the 11th of September, 2026.

Some information related to CRA SRP is available there: ENISA

Other vulnerabilities, whether from internal findings or an external source, are not required to be reported to the EU single reporting platform. It can be reported to SRP as voluntary initiative. The CRA does not mandate the means of communication with users.

Communication could go to public databases, such as the national vulnerability database (NVD) and the European union vulnerability database (EUVD).

Another way could be to publish in a private location, such as the product security incident response team (PSIRT).

Another way could be on a case-by-case basis, such as Product Change Process (ie. JDEC Product Change Information/Notification).

Communication could also combine these options, for example, on a case-by-case basis during the embargo period and then to a private location.

ST communicates vulnerabilities through the product security incident response team (PSIRT ).

5.4.3. Vulnerabilities scanning

The Cyber Resilience Act (CRA) requires that products, placed on the EU market, do not contain known exploited vulnerabilities (KEVs).

One solution is to scan software against public vulnerability databases to identify vulnerabilities and check for KEVs.

KEVs information access depends on reference vulnerability database:

• EUVD database is providing both CVE and KEV informations
• NVD database is providing access only to CVE then user is to search corresponding KEV into Cybersecurity and Infrastructure Security Agency (CISA) KEV catalog

These scanning tools can use software bills of materials (SBOMs) of consumed software or the software itself as input.

Tools example:

• Vulnscout from Savoir-faire LINUX
• SBOM-CVE from Bootlin

Vulnerability assessment can be simplified by vulnerability exploitation exchange (VEX) information, when available from sources.

Open source communities already support vulnerability handling. Yocto is one example:

• Checking for Vulnerabilities — Yocto Project documentation
• Reporting Vulnerabilities — The Yocto Project - tip documentation

5.4.4. Vulnerabilities monitoring

The Cyber Resilience Act (CRA) requires manufacturers to provide cybersecurity support for at least five years.

During this period, the manufacturer must:

• monitor vulnerabilities. The CRA does not define the monitoring frequency.
  
• apply the vulnerability scanning described above. New vulnerabilities can be discovered after the last scan.

An automatic tool is strongly recommended. The tool can be as simple as a script or as complex as a commercial tool.

The most time-consuming steps are triage and assessment. Artificial intelligence (AI) can assist these steps, but a human must make the final decision.

5.4.5. Vulnerability fix

Depending on the assessment outcomes, a fix can be developed and published.

For an "actively exploited vulnerability" or a "severe incident", the CRA mandates to deliver final report, to the Single Reporting Platform, within 14 days after the fix of an "actively exploited vulnerability", or within one month after the fix of a severe incident.

5.4.6. Security updates

The Cyber Resilience Act (CRA) requires security updates to be available for at least 10 years (retention time).

5.5. Conformance documentation

5.5.1. Declaration of conformity and CE marking

For a final device placed on the EU market, the device manufacturer, under its sole responsibility, prepares and signs the EU Declaration of Conformity, serving as an official declaration that the product satisfies all relevant EU rules and standards. Component suppliers may provide supporting declarations for the components they place on the market.

CRA example of declaration of conformity (source: CRA Annex V) :

• Mandatory information:
  • Name and type and any additional information enabling the unique identification of the product with digital elements,
  • Name and address of the manufacturer or its authorized representative,
  • A statement that the EU declaration of conformity is issued under the sole responsibility of the provider,
  • Object of the declaration (identification of the product with digital elements allowing traceability, which may include a photograph, where appropriate),
  • A statement that the object of the declaration described above is in conformity with the relevant Union harmonization legislation,
  • References to any relevant harmonized standards used or any other common specification or cybersecurity certification in relation to which conformity is declared.
  • When applicable, the name and number of the notified body, a description of the conformity assessment procedure performed and identification of the certificate issued
• Additional information:
  • Signed for and on behalf of
  • (place and date of issue)
  • (name, function) (signature)

Declaration of conformity shall be published with the product and included into Technical documentation. It is not said if it shall be included into user documentation or if it shall be transmitted to user as standalone document

5.5.2. Technical documentation (CRA Annex VII)

Document shall be available in case of commission request, shall not be published. This document must contain at least the following:

• General product description,
• Description of the design, development, and production of the product with digital elements, and of the vulnerability handling processes,
• Assessment of the cybersecurity risks,
• Relevant information that was considered to determine the support period,
• List of the harmonized standards applied in full or in part,
• Reports of the tests carried out to verify conformity and the vulnerability handling processes,
• Copy of the EU declaration of conformity,
• Software bill of materials (SBOM), further to a reasoned request from a market surveillance authority.

6. Some use cases

6.1. Existing design

Context: the product already exists and is already sold, or planned for sale, on the EU market, the product must be then updated to conform to the Cyber Resilience Act (CRA).

Risk assessment is the first and most important step. The outcomes are mitigations, including security functions that are already implemented or new security functions that must be implemented. And, these new security functions affect the existing design, at minimum, in the memory footprint.
A possible solution is to use the security features of the microprocessor unit (MPU) in STM32 to reduce both development effort and memory footprint.
Another solution is to change the target STM32 microprocessor unit (MPU).

Most STM32 MPUs are certified to SESIP Level 3.

The direct benefits for the device are:

• Reduced development effort
• Reduced CRA conformance effort through the SESIP-to-CRA mapping of security functions

Another important potential impact for microprocessor unit (MPU)-based products is the use of open-source software. Manufacturers must identify and fix the software that they develop or use. Assessment of known vulnerabilities is an important effort for MPUs because of the use of open-source software and the large size of the software. Tools are key to minimizing effort.

ST does not promote any tool. The OpenSSF CVE benchmark could be a starting point for MPU users

6.2. New design

Context: new product intended for sale in the European Union (EU).

Consider the Cyber Resilience Act (CRA) from day one.
Define an optimized bill of materials (BOM), including the STM32 microprocessor unit (MPU) selection, and a strategy that minimizes effort.
Most STM32 MPUs are certified to SESIP Level 3.

Direct benefits for the device include:

• development effort
• Reduced CRA conformance effort because of the SESIP-to-CRA mapping of security functions

ST distributions include a software bill of materials (SBOM) file which provides easier dependency identification thanks to composition transparency.

7. Additional references

• Cyber Resilience Act
• ENISA
• CSIRT
• SESIP
• PSA
• PSIRT

• 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.

• STM32Trust security framework

• STM32 Security wiki

• Product Security Response Team - PSIRT
• OPENSSF “Understanding the European Union (EU) Cyber Resilience Act (CRA) (LFEL1001)” April 2025
• REGULATION (EU) 2024/2847
• Cyber Resilience Act | Shaping Europe’s digital future
• Cyber Resilience Act Requirements Standards Mapping
• ENISA Vulnerability Database: Vulnerability Database
• Visit ENISA web portal to get latest news and updates

Cyber Resilience Act

Microprocessor unit

Microcontroller unit (MCUs have internal flash memory and are intended to operate with a minimum amount of external support ICs. They commonly are a self-contained, system-on-chip (SoC) designs.)

The Linux Foundation® and Yocto Project® are registered trademarks of the Linux Foundation. Linux® is a registered trademark of Linux Torvalds

Common vulnerabilities and exposures

known exploited vulnerabilities, term used in the scope of CRA

Cybersecurity and Infrastructure Security Agency

Artificial intelligence

Cyber Resilience Act

Microprocessor unit

Microcontroller unit (MCUs have internal flash memory and are intended to operate with a minimum amount of external support ICs. They commonly are a self-contained, system-on-chip (SoC) designs.)

The Linux Foundation® and Yocto Project® are registered trademarks of the Linux Foundation. Linux® is a registered trademark of Linux Torvalds

Common vulnerabilities and exposures

known exploited vulnerabilities, term used in the scope of CRA

Cybersecurity and Infrastructure Security Agency

Artificial intelligence

Linux^® is a registered trademark of Linus Torvalds.