STM32 Hardware Selection for CRA-Scoped Connected Products
Use this page to assess whether an STMicroelectronics STM32 part can support the secure-by-design controls, evidence, and lifecycle commitments needed for a connected product.
The EU Cyber-Resilience Act (CRA) raises the bar for connected products. For microcontroller-based designs, that means choosing hardware that can support a trustworthy boot chain, strong cryptography, secure storage for keys, and a maintainable update path over the product's support lifetime.
STMicroelectronics' STM32 portfolio provides security features that can support those goals. But no STM32 part, SDK, or reference design makes a product compliant by itself. The manufacturer still owns the product-level risk assessment, secure integration, vulnerability handling process, support commitments, and technical documentation required by the CRA.
ST's newer CRA pages are useful because they show how the company now packages its security story for product teams, not just firmware engineers. Use them as supplier inputs, not as a substitute for your own engineering and compliance work. See ST's CRA resource hub and related announcement st-announcement.
1. What STM32 can and cannot help you with
STM32 can help with
- Provide a hardware root of trust for secure boot and key protection.
- Provide hardware accelerators for AES, hashing, public-key cryptography, and random-number generation on many families.
- Provide device identity primitives, such as the STM32 unique device identifier and, on some series, stronger isolation and tamper features.
- Provide reference implementations such as STM32Trust and SBSFU to shorten secure boot and secure update work.
- Provide supplier documentation and assurance material that may support your technical file and supplier due diligence.
- Provide part-level features that may support emerging boot-manager expectations in ETSI EN 304 623, such as immutable trust anchors, anti-rollback support, secure debug controls, and recovery mechanisms.
STM32 cannot do for you
- Perform your CRA risk assessment or threat model.
- Prove that your final product is free of known exploitable vulnerabilities.
- Operate your vulnerability disclosure, triage, and patch process.
- Guarantee that your cloud backend, mobile app, radio configuration, or manufacturing flow is secure.
- Replace your obligation to assemble a defensible technical file and Declaration of Conformity.
For the product-level obligations, start with the CRA Overview, Types of Embedded Device, Threat Modeling, Secure Boot, Key Provisioning & Storage, SBOM & VEX Workflows, and Secure-by-Design Evidence Pack.
2. STM32 family cheat sheet
The STM32 family is large. For CRA-relevant controls, the series with the strongest isolation, key-management, and secure boot building blocks are the most interesting.
- STM32U5 / STM32L5: Cortex-M33 devices with TrustZone and a richer security feature set. These are strong starting points for new low-power, security-focused products.
- STM32H5 / STM32H7: Higher-performance parts suited to more demanding gateways, rich HMIs, and complex industrial designs. The H5 is the more security-forward of the two because it also uses Cortex-M33 and TrustZone.
- STM32WL: Long-range wireless parts designed for sub-GHz applications, useful where radio integration and secure device identity matter.
- STM32G4 / STM32G0: Cost-sensitive mainstream parts with a more modest security baseline. These can still fit lower-risk products, but they leave more of the security architecture to the integrator.
Table 1 - STM32 series vs. security and fit
| Series | CPU Core | Key hardware security features | Stand-out capability | Typical fit |
|---|---|---|---|---|
| STM32U5 | Cortex-M33 @ 160 MHz | TrustZone, HUK, AES, PKA, OTFDEC, tamper, secure boot, RDP, unique ID | Broadest security feature set in the low-power range | High-security, power-constrained IoT endpoints |
| STM32L5 | Cortex-M33 @ 110 MHz | TrustZone, AES, PKA, OTFDEC, tamper, secure boot, RDP, unique ID | Earlier entry point for TrustZone-based STM32 designs | Secure low-power general-purpose products |
| STM32H5 | Cortex-M33 | TrustZone, secure boot, crypto acceleration, isolation features | Higher performance with a more modern security architecture | Industrial controllers, gateways, rich embedded applications |
| STM32H7 | Cortex-M7 @ up to 550 MHz | Crypto/hash on some parts, secure boot support, unique ID, optional on-the-fly decryption | Highest MCU performance in the family | Rich HMI, industrial gateways, complex processing |
| STM32WL | Cortex-M4 + M0+ | AES, PKA, true RNG, sector protection, secure key management, unique ID | Integrated sub-GHz radio | Long-range wireless sensors and field devices |
| STM32G4 / G0 | Cortex-M4 / Cortex-M0+ | AES or baseline crypto on some parts, true RNG on some parts, unique ID, MPU | Lower BOM cost | Cost-sensitive industrial and control designs |
3. Quick-pick decision matrix
| If your product needs... | Choose | Why |
|---|---|---|
| State-of-the-art security and ultra-low power | STM32U5 | Best low-power choice when you want isolation, crypto acceleration, and a richer security baseline. |
| A lower-power TrustZone design without the premium U5 profile | STM32L5 | A practical way to adopt hardware isolation in secure embedded designs. |
| Higher performance plus stronger security architecture | STM32H5 | Better fit than older high-performance lines when security is a primary requirement. |
| Maximum compute for gateway, HMI, or edge processing | STM32H7 | Strong performance, but check exact part-level security features carefully. |
| Integrated sub-GHz connectivity | STM32WL | Helps simplify long-range wireless designs where secure identity and radio integration matter. |
| Lower-cost baseline security | STM32G4 / G0 | Suitable for simpler or lower-risk designs, provided your architecture closes the remaining gaps. |
4. Mapping STM32 capabilities to CRA-relevant controls
| CRA expectation | STM32 capabilities that can help | What you still own as the manufacturer | Handbook guide |
|---|---|---|---|
| Secure boot and authenticated firmware | SBSFU, secure boot building blocks, immutable boot ROM, RDP, key storage features on selected families | Boot-chain design, signing-key governance, secure manufacturing, fail-secure recovery | Secure Boot |
| Cryptographic resilience | AES, PKA, RNG, OTFDEC, TrustZone, and other hardware features on selected parts | Algorithm choice, protocol design, key lifecycle, crypto agility, cloud-to-device trust model | Key Provisioning & Storage and Cryptography under CRA |
| Secure updates and patching | STM32Cube ecosystem, secure update examples, signed-firmware reference flows | OTA backend, rollback strategy, release signing process, patch SLAs, field support over the declared support period | OTA Updates & Patching and Patch Cadence |
| Unique device identity | Factory-programmed UID and, on some devices, stronger isolation and key-derivation options | Certificate issuance, manufacturing provisioning, enrollment, rotation, revocation, device inventory | Unique Device Identity |
| Technical documentation and evidence | ST datasheets, application notes, security collateral, STM32Trust assurance materials | Risk assessment, architecture rationale, test evidence, supplier records, Declaration of Conformity, technical file | Secure-by-Design Evidence Pack |
5. Evidence to Retain
For STM32-based designs, useful evidence includes:
- exact part number, revision, package, and lifecycle status;
- security feature mapping for the selected part;
- boot-chain design and secure boot configuration;
- key-storage and provisioning design;
- debug-lockdown configuration and manufacturing records;
- update, rollback, and recovery test evidence;
- STM32Cube, SBSFU, STM32Trust, datasheet, and application-note references used;
- supplier security policy, advisory, and lifecycle records;
- records showing production configuration matches the intended security design.
6. Supplier due-diligence checklist for STM32-based designs
When you evaluate STM32 for a CRA-scoped product, collect evidence from ST the same way you would from any strategic component supplier.
- Exact part identification: Which precise STM32 family and part number are you using, and which security features exist on that exact variant?
- Security lifecycle: Does ST publish a clear security policy, vulnerability channel, and security advisories for the relevant product line? st-cra-page
- Reference design maturity: Are you depending on SBSFU, STM32Cube examples, or other collateral? If so, who owns maintenance and validation in your final product?
- Boot-manager evidence: Can the selected part support immutable trust anchors, anti-rollback counters, authenticated recovery, and secure debug lockdown consistent with the direction of ETSI EN 304 623?
- Assurance claims: Are there certifications or assurance schemes attached to this line, and what exactly do they cover: silicon, reference software, or the full system? st-trust-assurance
- Documentation for the technical file: Which ST artifacts can you cite: datasheets, application notes, security manuals, lifecycle statements, or public policies?
- Support horizon: Does the component lifecycle align with your declared support period under the CRA?
- Radio obligations: If you are using wireless STM32 devices, what extra evidence is needed for RED as well as the CRA?
7. Recommended STM32-based reading path
If you are using ST hardware in a CRA-scoped product, this is a sensible sequence:
- Use Types of Embedded Device to confirm the architecture and product boundary.
- Read the CRA Overview to map the legal obligations.
- Use Threat Modeling to identify the product-level risks your MCU must support.
- Design your trust architecture using Unique Device Identity and Secure Boot.
- Plan the operational path with OTA Updates & Patching and Vulnerability Disclosure.
- Capture supplier artifacts and your own evidence in an Secure-by-Design Evidence Pack.
8. Takeaways
- For new security-focused STM32 designs, STM32U5, STM32L5, and often STM32H5 deserve the closest look.
- STM32Trust and SBSFU can accelerate engineering work, but they do not replace product-level CRA responsibilities.
- Treat ST's CRA pages as useful supplier inputs for due diligence and technical documentation, not as proof of compliance on their own.
- Check the exact part's boot, rollback, recovery, and debug-lockdown capabilities against emerging boot-manager standards such as EN 304 623.
- The right MCU choice is only one layer in the CRA story; your threat model, update process, vulnerability handling, and technical file still do the heavy lifting.