STM32 for Cyber-Secure IoT: A Threat-Model and Capability Assessment

Introduction

Connected products are moving into a hardening regulatory frame. The forthcoming EU Cyber Resilience Act (CRA), adopted by the European Parliament in March 2024 and awaiting final adoption by the Council, will impose mandatory cybersecurity requirements across the lifecycle of products with digital elements. It is expected to enter into force later this year, with the bulk of its essential requirements applying after a transition period of roughly three years and earlier deadlines for vulnerability reporting; the agreed text provides for penalties of up to €15 million or 2.5% of worldwide annual turnover. Security is therefore becoming a conformity obligation, not a feature to be bolted on late.

For a large share of those products the candidate platform is an STM32 — a family that began as cost-driven general-purpose silicon and has since acquired security-specific hardware. The relevant engineering question is no longer "can an STM32 be secured at all," but "which family, with which countermeasures, is sufficient for a given threat model and assurance target — and at what point does an external chip or a different architecture become the more defensible choice."

A threat model for connected MCU devices

Security requirements are clearer when expressed as a threat model rather than a feature list. A typical connected node faces a recurring set of attacks, each mapping to a countermeasure class.

Two observations follow. First, DoS resistance is largely an architectural and protocol concern — bounded buffers, hardware watchdogs, and a network stack that fails closed — rather than something a crypto accelerator solves. Second, the harder threats (key extraction, side-channel, fault injection, physical tampering) are exactly where silicon quality, not software, sets the ceiling. This is the axis along which STM32 families differ most.

What secure firmware actually looks like

A secure IoT firmware is organized around a root of trust (RoT) — a small, immutable starting point whose integrity is assumed and from which all other trust is derived. From the RoT, execution proceeds through a chain of cryptographic checks:

• Immutable boot stage verifies the next stage's signature before transferring control. On STM32 this is implemented as an immutable Root of Trust (iRoT, locked in ROM or write-protected flash) that validates an updatable RoT (uRoT). The vendor reference flows are named STiRoT (ST-provided) and OEMiRoT/OEMuRoT (OEM-built).
• Isolation separates trusted services (key handling, crypto, secure storage) from application code. On Armv8-M parts this uses Arm TrustZone, which partitions the device into a secure and a non-secure world with hardware-enforced boundaries, so a compromised application cannot read keys held in the secure side.
• Secure storage keeps credentials encrypted at rest, ideally bound to a hardware-derived key so a copied flash image is useless on a different die.
• Secure firmware update accepts only signed (and often encrypted) images, with a monotonic anti-rollback counter to block downgrade to a vulnerable version.
• Attestation lets a server cryptographically confirm what firmware a device is running before granting access.

In practice this is rarely hand-rolled. The portable reference is Trusted Firmware-M (TF-M), the open implementation of Arm's Platform Security Architecture (PSA) for Armv8-M, which exposes the PSA Crypto, Secure Storage, and Attestation APIs from the secure world. A signature check at boot or update time then reduces to a few standardized calls:

/* Illustrative PSA Crypto API usage (TF-M secure service).
   Verifies a firmware image signature against a provisioned public key. */
psa_status_t verify_image(const uint8_t *img, size_t img_len,
                          const uint8_t *sig, size_t sig_len)
{
    uint8_t hash[32];
    size_t  hash_len;

    /* Hash the candidate image (SHA-256). */
    psa_hash_compute(PSA_ALG_SHA_256, img, img_len,
                     hash, sizeof(hash), &hash_len);

    /* key_id refers to a public key held in secure storage,
       never exposed to the non-secure application. */
    return psa_verify_hash(key_id,
                           PSA_ALG_ECDSA(PSA_ALG_SHA_256),
                           hash, hash_len,
                           sig, sig_len);   /* PSA_SUCCESS == authentic */
}

The key-handle indirection (key_id) is the point: the application asks the secure world to use a key without ever holding its value, which is what makes the isolation worthwhile.

STM32 security peripherals, by family

STM32 security capability is graduated, so a blanket "STM32 is/isn't secure" claim is meaningless. The hardware blocks that matter:

• TRNG — a true random number generator with a physical entropy source, needed for keys and nonces; weak randomness undermines everything above it.
• AES / SAES — a symmetric crypto accelerator; SAES is a side-channel-hardened variant resistant to differential power analysis.
• PKA — a public-key accelerator for RSA/ECC, with SCA hardening on recent parts.
• HASH — a hardware SHA engine.
• OTFDEC — on-the-fly decryption of code executed from external flash, so off-chip firmware is not stored in the clear.
• HUK / tamper detection — a hardware-unique key for binding secrets to one die, plus active tamper inputs that can erase secrets on intrusion.
• Readout protection (RDP) — restricts debug and flash readback.

The STM32F2 line illustrates why family selection cannot be reduced to the series name. All four members share a Cortex-M3 core with no TrustZone, an analog true random number generator, a CRC unit, and flash readout protection. The cryptographic/hash accelerator, however, is fitted only to the "5" and "7" variants: the STM32F215 and STM32F217 integrate hardware AES-128/192/256, Triple-DES, and a hash engine, whereas the STM32F205 and STM32F207 ship without any crypto coprocessor and must perform symmetric and hash operations in software. A design that assumes hardware AES across the whole F2 line will therefore behave very differently on an F205 than on an F215.

Two further caveats apply even to the crypto-equipped parts. The accelerator's hash algorithms are MD5 and SHA-1 — both now considered obsolete for integrity and signature purposes — and there is no hardware SHA-256, no authenticated-encryption mode (such as AES-GCM), and no public-key accelerator. The block is consequently useful as a bulk AES/3DES throughput aid, but it does not by itself provide the primitives a contemporary secure-boot or TLS design depends on; those still rest on software libraries, and the absence of TrustZone means there is no hardware isolation between application code and key material.

The broader takeaway holds: a Cortex-M0/M3/M4/M7 STM32 with no TrustZone can still run TLS and verify signed updates, but it offers no hardware isolation between application and secrets and weaker physical-attack resistance. The Armv8-M lines (L5, U5, H5, WBA) are the ones designed for the regulated-IoT case, and U5/H5 reach independent PSA/SESIP certification — the evidence a conformity assessment will actually want.

Realizing it in practice: tools, libraries, and external silicon

ST consolidates the relevant resources under the STM32Trust framework, which defines a set of security functions (secure boot, secure storage, isolation, crypto, abnormal-situation handling, lifecycle control, and so on) and the services that implement them. The concrete toolchain includes STM32CubeProgrammer with TrustedPackageCreator for encrypting and signing OEM binaries, the STM32HSM hardware module for transferring credentials to a contract manufacturer without exposing them, and the X-CUBE-SBSFU / STiRoT / Secure Manager packages for the boot-and-update chain.

For the cryptographic and protocol layer, the common building blocks are the PSA Crypto API via TF-M, the bootloader MCUboot (anti-rollback, image signing), ST's certified CMOX cryptographic library (X-CUBE-CRYPTOLIB), and the widely used mbedTLS or wolfSSL/wolfBoot stacks for TLS and secure boot.

Where the MCU's own silicon is insufficient — typically when certified, tamper-resistant key storage or strong anticloning is required — the practical answer is to offload trust to an external secure element (SE). ST's STSAFE-A110 is representative: a turnkey SE built on a Common Criteria EAL5+ certified secure microcontroller, providing ECC-based device authentication, secure storage of keys and credentials, and assistance with TLS session establishment, all over an I²C interface. The architectural reasoning is straightforward: the SE holds private keys that never leave the certified die, so even full compromise of the host STM32 does not yield the device identity. For platform-integrity use cases an STSAFE-TPM (TPM 2.0, FIPS 140-2) plays an analogous role on Linux-class designs.

Conclusion: a qualified yes

For the majority of connected products, an STM32 is a defensible and often well-suited foundation — provided the family is chosen to match the threat model rather than the unit price. A modern Armv8-M part (U5 or H5) with TrustZone isolation, a hardened crypto engine, a TRNG, and a certified secure-boot path covers the dominant IoT threats and carries the PSA/SESIP evidence that emerging conformity work will draw on. Pairing such an MCU with an STSAFE secure element raises physical-attack and key-extraction resistance to a level the MCU alone does not reach, at modest BOM cost.

The platform is not the right answer in two situations. First, a legacy Cortex-M0/M3/M4/M7 STM32 with no TrustZone and minimal crypto hardware should not be the basis of a new device with meaningful security obligations; software-only countermeasures leave the harder threats unaddressed, and the dated primitives on parts such as the STM32F215/F217 (MD5, SHA-1, Triple-DES) underline how far an older accelerator can sit from current requirements. Second, when the product needs a rich operating-system-level Trusted Execution Environment (Linux with OP-TEE, multiple isolated workloads), the design belongs on a Cortex-A class part — ST's own STM32MP series, or a comparable applications SoC — rather than a microcontroller.

Where STM32 is genuinely a poor fit, the credible alternatives are adjacent rather than exotic: NXP LPC55Sxx or i.MX RT (Cortex-M33 with integrated crypto, or EdgeLock secure elements), Nordic nRF5340 (TrustZone plus an integrated crypto cell, for BLE-centric nodes), Microchip SAM L11 with the Trust Platform / ATECC608 elements, Renesas RA with its Secure Crypto Engine, or — at the cost-driven end — ESP32-class parts with flash encryption and secure boot. The discriminating factors among these are not raw cryptographic capability, which has largely converged, but certification evidence, the maturity of the secure-boot tooling, and whether a tamper-resistant element is needed at all.

References

[1] STMicroelectronics, "STM32Trust security framework," product documentation. [Online]. Available: https://www.st.com/en/ecosystems/stm32trust.html

[2] STMicroelectronics, "STSAFE-A110 — Authentication, state-of-the-art security for peripherals and IoT devices," Datasheet. [Online]. Available: https://www.st.com/en/secure-mcus/stsafe-a110.html

[3] European Commission, "Proposal for a Regulation on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)," COM(2022) 454 final, Sep. 2022.

[4] Arm Ltd. and PSA Certified, "Platform Security Architecture / PSA Certified," program documentation. [Online]. Available: https://www.psacertified.org/

[5] Trusted Firmware project, "Trusted Firmware-M (TF-M) documentation." [Online]. Available: https://www.trustedfirmware.org/projects/tf-m/