Secure IoT product design: from hardware to field deployment

Securing an IoT product stacks four chains of trust: hardware Secure Boot (SB) with ECDSA-P256 or Ed25519 Root of Trust (RoT), signed firmware with anti-downgrade rollback (MCUboot), Transport Layer Security (TLS) 1.3 / AES-256, and hardware key storage in a Key Management Unit (KMU) or Hardware Security Module (HSM). At AESTECHNO (Montpellier), we apply this from MCU selection to meet the Cyber Resilience Act (CRA), EU 2024/2847, and ETSI EN 303 645.

Contents

• Secure boot and chain of trust
• Firmware signing and secure update (OTA)
• Encrypted communications
• Secure storage
• Physical security
• Regulatory framework: what's mandatory
• Secure elements: ATECC608B vs SE050 vs OPTIGA Trust M, how to choose
• IoT security checklist for CTOs and CISOs
• Real cases from the lab
• Standards, tools and IoT security frameworks
• Our approach at AESTECHNO
• Bottom line

Secure boot and chain of trust

Secure boot is a hardware mechanism that guarantees only authenticated, signed firmware can run on a microcontroller or processor. It is the first link in the hardware chain of trust, blocking any unauthorised code modification at startup. Without secure boot, an attacker with physical access can replace the firmware with a malicious version, and the product will run it without complaint.

The principle: at boot, the processor's boot ROM verifies the firmware's cryptographic signature before executing it. If the signature is invalid, the device refuses to start. This verification relies on a public key permanently fused into the hardware, the hardware root of trust. Every later protection, from signed OTA updates to encrypted key storage, depends on this first verification step.

Available technologies:

• MCUboot: open-source bootloader for Zephyr and Apache Mynewt. Supports Ed25519 and ECDSA-P256, with dual-slot (A/B) management
• TF-M (Trusted Firmware-M): PSA reference implementation for Cortex-M, providing an isolated Secure Processing Environment
• ARM TrustZone: hardware separation between "secure" and "non-secure" worlds on Cortex-M33/M55

KMU, Key Management Unit: modern MCUs like the nRF5340/nRF9160 (Nordic Semiconductor) and STM32H5/STM32U5 (STMicroelectronics) integrate a KMU, a hardware module dedicated to storing and managing cryptographic keys. The KMU stores keys in protected registers, inaccessible to the application firmware in normal operation. Keys never leave the hardware, they are used directly by the MCU's cryptographic accelerator.

Hardware root of trust vs software-only: a pure software approach stores keys in flash, accessible to anyone with an SWD debugger. The hardware Root of Trust (RoT) anchors trust in silicon, far harder to compromise. The difference between a software lock and a physical safe. This principle is echoed, as noted by NIST in SP 800-193 on Platform Firmware Resiliency (PFR): protection, detection and recovery must be rooted in hardware immutable to the main firmware.

Certificate chain: in production deployments, each device holds a unique certificate signed by the manufacturer, itself attached to a root certificate authority (CA). The full chain, device → manufacturer → cloud, enables mutual authentication at every level.

Firmware signing and secure update (OTA)

Firmware signing and secure Over-the-Air (OTA) updates are the software supply chain of any IoT product deployed in production. They guarantee that only authentic, untampered firmware of an approved version can be installed on a device, whether in the factory or remotely, across a fleet of thousands.

A secure update chain combines the elements detailed in this section: a signature algorithm (ECDSA-P256 or Ed25519) verified by the bootloader, a SHA-256 hash that proves image integrity, and a dual-slot MCUboot layout that rolls back automatically when a new image fails. An anti-rollback counter completes the scheme by refusing older signed versions that carry known vulnerabilities. Weak integration of any one of these pieces undoes the others.

Signature algorithms and orders of magnitude:

• ECDSA-P256: 64-byte public key, 64-byte signature. Verification on Cortex-M4 with accelerator: typically under 10 ms. NIST FIPS 186-4 standard.
• Ed25519: 32-byte key, 64-byte signature. Verification even faster (~3 ms on Cortex-M4 with a dedicated accelerator), and resistant to side-channel attacks on the implementation.
• SHA-256: 256-bit hash (32 bytes), computed in under 1 ms on a 256 KB firmware image with a hardware accelerator clocked at 64 MHz. SHA-256 remains the baseline for signature integrity on IoT firmware, according to NIST FIPS 180-4.

Insecure firmware update mechanisms remain the second most common class of critical IoT weakness behind weak default credentials, per OWASP IoT Top 10. We see the same pattern in every audit: correct cryptography on paper, broken integration in the factory pipeline. Our test procedure for any new OTA stack is simple: simulate a power-loss mid-flash on the secondary slot, measured using a programmable PSU, and confirm the bootloader falls back cleanly.

MCUboot dual-slot (A/B) architecture: firmware is stored in two slots. The active slot runs the current version. The update is downloaded into the secondary slot, verified (signature + integrity), then activated on the next reboot. If anything fails, boot crash, watchdog timeout, the bootloader automatically reverts to the previous version (rollback). No human intervention required.

Firmware image encryption: beyond signing (which guarantees authenticity), encrypting the firmware image prevents reverse engineering. A competitor or attacker who intercepts an OTA file cannot analyse the code. MCUboot supports AES encryption with ECIES key exchange.

Anti-rollback: a monotonic counter written in hardware (or in a protected flash region) prevents installing an older firmware version. Without this protection, an attacker could force the install of a known-vulnerable version to exploit it.

Secure OTA, the full chain:

1. Encrypted transport: TLS 1.3 between device and update server
2. Signed payload: the firmware image is signed with the manufacturer's private key
3. Verification before execution: the bootloader checks the signature before switching to the new slot
4. Automatic rollback: on failure, revert to the previous version

Encrypted communications

Encrypted communications are the in-transit protection that shields data moving between the IoT device, the gateway and the cloud. Any unencrypted exchange, MQTT telemetry, CoAP commands, BLE streams, can be intercepted, modified or replayed by an attacker on the network. Encryption in transit is now the absolute minimum for any professional connected product.

TLS 1.3 for MQTT and HTTPS: TLS 1.3 is the current standard for securing TCP communications. Compared with TLS 1.2, it removes obsolete cipher suites, cuts the handshake to a single round-trip (1-RTT), and enforces forward secrecy. For IoT products talking MQTT to a cloud broker (AWS IoT Core, Azure IoT Hub, Mosquitto), TLS 1.3 is the default choice. We deploy it systematically on our connected designs.

DTLS for CoAP and UDP: for UDP-based protocols, CoAP in particular, DTLS (Datagram TLS) provides equivalent security. DTLS 1.3 brings the same improvements as TLS 1.3 to the UDP world, important for low-power devices using LwM2M or CoAP.

BLE, pairing modes: Bluetooth Low Energy security depends heavily on the chosen pairing mode:

• Just Works: no authentication, vulnerable to MITM attacks. Acceptable only for non-sensitive data
• Passkey Entry: PIN-code authentication, MITM protection
• OOB (Out-of-Band): key exchange via NFC or QR code, the most secure
• LE Secure Connections (BLE 4.2+): uses ECDH for key exchange, replaces legacy pairing

Certificate pinning vs CA trust: certificate pinning anchors trust in a specific certificate rather than a CA chain. Stricter, but it complicates certificate rotation. The choice depends on product lifetime and your PKI infrastructure.

Mutual TLS (mTLS): in classic TLS, only the server authenticates. With mTLS, the device also presents its certificate, the server verifies that the device is genuinely legitimate. Essential to prevent a counterfeit device from connecting to your cloud infrastructure.

Secure storage

Secure storage is the at-rest protection that covers cryptographic keys, certificates, authentication tokens, calibration data, and possibly user data. A key stored in plaintext in an MCU flash can be recovered in minutes by an attacker with a standard debugger. Protecting data at rest is inseparable from overall product security.

Encrypted flash: some MCUs offer transparent flash encryption (XIP, eXecute In Place, with hardware decryption). The STM32H5, for example, provides OTFDEC (On-The-Fly Decryption). Code is stored encrypted and decrypted on the fly by hardware during execution, with no performance impact.

Key storage options range from key registers integrated in the MCU to dedicated secure elements on I²C and TPMs on Linux-class gateways. The right level depends on the certification targeted and on the product architecture.

Key storage, hardware hierarchy:

• KMU (nRF5340, nRF9160): dedicated hardware registers, keys accessible only to the cryptographic engine
• UICR (User Information Configuration Registers): protected memory region, but less isolated than the KMU
• Secure elements (ATECC608B, Infineon OPTIGA): dedicated cryptographic components on I²C, with internal key generation, signing, and Common Criteria-certified storage
• Trusted Platform Module (TPM) on Linux-class gateways (fTPM via firmware or dTPM on SPI), paired with a Physical Unclonable Function (PUF) for device-unique identity derivation without explicit key injection

Credentials must be stored securely within services and on devices, ruling out hardcoded keys in firmware images, according to ETSI EN 303 645 provision 5.4. Every deployed device should carry a unique, non-cloneable identity rooted in hardware, as noted by Bsi in its IoT baseline recommendations.

Absolute rule: never store keys in source code, nor in plaintext flash. This is the most common flaw we see in security audits. A grep -r "private_key" on the repo should return nothing.

Production provisioning: each device must receive unique keys and certificates during factory programming. Provisioning injects a private-key/certificate pair specific to each unit, enabling individual identification and limiting the impact of a compromise to a single device. Our electronic design firm in Montpellier integrates this step into our production processes.

Physical security

Physical security is the defence against direct hardware attacks: firmware extraction via debug ports, flash readout via probe, electrical signal analysis. A field-deployed IoT product is physically accessible, unlike a server in a datacentre. Locking down debug interfaces and enabling hardware protections is mandatory before any production rollout.

Debug ports, SWD/JTAG: in development, the SWD (Serial Wire Debug) and JTAG ports let you program, debug and read MCU memory. In production, these ports must be locked. An open SWD port in production is a wide-open door: flash readback, key extraction, modified-firmware injection. Locking must therefore be a step of the production process itself, verified at end-of-line, rather than a manual setting left to each engineer.

Readback protection:

• nRF APPROTECT: protection against debug-port access, configurable via UICR. On nRF5340, APPROTECT is enabled by default, you must explicitly disable it during development
• STM32 RDP (Read-out Protection): three levels, Level 0 (no protection), Level 1 (flash readback via debug forbidden, reversible by full erase), Level 2 (irreversible, debug permanently disabled)

Side-channel attacks: power analysis attacks (DPA, Differential Power Analysis) or timing attacks measure power-consumption or execution-time variations to extract cryptographic keys. Hardware accelerators in modern MCUs include countermeasures (masking, blinding), but pure software implementations remain vulnerable.

Tamper detection: for high-security applications (payment, medical, defence), enclosure-opening or physical-tampering detection mechanisms can trigger automatic key wipe. Secure elements like the ATECC608B integrate hardware tamper detectors.

Regulatory framework: what's mandatory

The European regulatory framework for connected-product cybersecurity is tightening significantly between 2025 and 2027. Several texts converge to impose security-by-design requirements, update maintenance, and vulnerability management across the product lifetime. Ignoring these regulations exposes vendors to fines, market-removal orders, and legal liability after an incident.

Four texts matter most for a connected product sold in Europe: the Cyber Resilience Act, the NIS2 Directive, RED Article 3.3 (d)(e)(f) for radio equipment, and the ETSI EN 303 645 standard for consumer IoT, with IEC 62443 for industrial products. Their requirements overlap: security by design, updates over the product lifetime, vulnerability handling and secure communications. The list below summarises what each text requires and who it applies to.

• Cyber Resilience Act (CRA), EU 2024/2847, European regulation whose vulnerability-reporting obligations apply since 11 September 2026, with full application on 11 December 2027. Covers all digital products (hardware and software) sold in the EU. Requires: security by design, vulnerability management, security updates throughout product lifetime, SBOM (Software Bill of Materials) in CycloneDX 1.5 or SPDX 2.3, Coordinated Vulnerability Disclosure (CVD), and reporting of actively exploited Common Vulnerability and Exposures (CVE) to ENISA within 24h. The CRA covers an estimated 90% of connected products placed on the EU market, as noted by European Commission impact assessments
• NIS2 Directive, extends cybersecurity obligations to the supply chains of essential and important sectors. If your customers are in energy, transport, healthcare or industry, they will demand security guarantees
• RED Article 3.3 (d)(e)(f), the Radio Equipment Directive adds cybersecurity requirements for any wireless-communicating device: network protection, personal-data protection, fraud protection. Applies to all CE-certified products with a radio component
• ETSI EN 303 645, reference standard for consumer IoT security. 13 baseline provisions: no default passwords, vulnerability management, secure communications, data minimisation, etc.
• IEC 62443-4-1 and IEC 62443-4-2, cybersecurity standard for industrial automation and control systems published by IEC. Defines security levels (SL1 to SL4) and requirements per component, system and organisation. Often paired with ISO/IEC 27001 for the Information Security Management System layer
• NIST SP 800-63 (digital identity guidelines) and NIST SP 800-193 Platform Firmware Resiliency (PFR), referenced by procurement teams in North America and increasingly by European integrators
• FIPS 140-3 for cryptographic module validation, required for US federal deployments and useful as a proxy for hardware crypto quality elsewhere

IoT security checklist for CTOs and CISOs

The IoT security checklist below is the minimum set of security measures that must be validated before any IoT product goes to production. It covers the full chain, from hardware to organisational process, and forms the minimum compliance baseline for the Cyber Resilience Act and NIS2. Each item maps to a concrete, measurable risk.

The eight measures span four layers: hardware (secure boot, debug locking, keys stored in a KMU or secure element), software (signed firmware, OTA with automatic rollback), network and provisioning (TLS 1.3, unique credentials per device), and organisation (a vulnerability disclosure process). For each measure, the table names the risk you accept when it is missing, which turns it into a practical go/no-go review before production.

Real cases from the lab

Real cases from the lab show where IoT security actually breaks: rarely in the cryptographic algorithms, far more often in integration and production practices. The three cases below are drawn from our audits and IoT projects, and they show how field security diverges from spec assumptions.

In the first case, secure boot was active but the debug port had been left open on the production version. In the second, correct ECDSA-P256 signing lacked an anti-rollback counter, so an older vulnerable firmware could be re-injected. In the third, a TLS private key had been committed to a Git repository. Each case ends with the countermeasure we now recommend, from end-of-line debug locking to pre-commit secret detection.

• Case 1, a recent client project: secure boot active, JTAG forgotten. On one audit, we found a production product shipping a fully functional secure boot, but the JTAG/SWD port had been left active on the production version. Counterintuitively, enabling secure boot without locking debug is illusory protection: an attacker reads flash directly, extracts keys and bypasses the chain of trust. We recommend locking APPROTECT (nRF) or RDP Level 1/2 (STM32) in the production process, verified at end-of-line.
• Case 2: firmware signature bypassed via rollback. A customer had implemented ECDSA-P256 signing correctly, but without an anti-rollback counter. An attacker could re-inject an older signed version vulnerable to a known CVE. We systematically recommend a hardware monotonic counter (KMU or protected UICR) coupled with signing, never one without the other.
• Case 3, field report from a recent client project: TLS keys in the Git repo. During a code review, a grep -r BEGIN in the repo surfaced the MQTT broker's TLS private key, accidentally committed. Contrary to the belief that IoT security is a firmware problem, most vulnerabilities we observe come from the hardware layer and provisioning practices, debug left open, keys in plain flash, secrets in Git. Unlike server-side crypto, the device side has no operator to notice a compromise. We enforce mandatory secret detection (git-secrets, trufflehog) as a pre-commit hook in our pipelines.

Standards, tools and IoT security frameworks

Connected-product security is a mesh of standards, hardware building blocks and software tools that work together rather than in isolation. Standards and frameworks such as ETSI EN 303 645, IEC 62443-4-1/4-2 and the Cyber Resilience Act define what must be achieved.

Hardware building blocks, from ARM TrustZone and integrated KMUs to secure elements and server-side HSMs, decide where keys live and how code is isolated. Validation tools (static analysis, SBOM generation, CVE tracking) prove that the result still holds release after release. A gap in any one of these three layers weakens the other two, which is why we treat them as a single chain. Here are the building blocks we work with daily, grouped by role:

• Standards and frameworks: ETSI EN 303 645 (consumer IoT, 13 provisions), IEC 62443-4-1 / 62443-4-2 (industrial processes and components), NIST IR 8259 (IoT baseline), NIST SP 800-82 (ICS), RED Article 3.3 (d)(e)(f) for CE radio certification, Cyber Resilience Act (CRA) 2026-2027
• Hardware building blocks: HSM (Hardware Security Module) on the server side for PKI, ARM TrustZone on Cortex-M33/M55 for secure/non-secure isolation, Microchip ATECC608B or Infineon OPTIGA Trust secure elements for certified key storage, integrated KMU on nRF5340/nRF9160 and STM32H5/U5
• Validation tools: static analysis (Coverity, Polyspace) for the firmware chain, SBOM in CycloneDX 1.5 or SPDX 2.3 format (required by the CRA), Common Vulnerability and Exposures (CVE) and Common Vulnerability Scoring System (CVSS) databases for vulnerability tracking. A signed SBOM attached to every release is now the minimum bar for supply-chain transparency, per OWASP guidance

Security-driven CI/CD discipline. We enforce on our pipelines: automated secret detection on every push, mandatory binary signing with HSM-stored keys (never on a developer workstation), SBOM generation on every build, and auto-deploy gated on tests. No binary reaches production without passing the full chain, this is the only effective barrier against a supply-chain attacker targeting your software.

Our approach at AESTECHNO

Our AESTECHNO approach is to integrate IoT security at every stage of our design projects, from component selection to factory programming. Our approach is pragmatic: each security measure is sized against the product's real risk level, its operational context, and the applicable regulatory requirements.

In practice, this translates into five commitments detailed below: secure boot and KMU configured from the first prototype on nRF5340, nRF9160 and STM32; TLS 1.3 over MQTT with mutual authentication; signed, rollback-capable Linux BSPs; a secure RTOS choice on microcontrollers; and CE/RED preparation that includes the Article 3.3 cybersecurity requirements. Behind all five sits a CI/CD pipeline that is the only path to production, so no binary skips signing or testing.

• Secure boot and KMU: we integrate secure boot and the Key Management Unit in our embedded designs on nRF5340, nRF9160 and STM32. The chain of trust is configured from the first prototype
• TLS 1.3 over MQTT: we deploy TLS 1.3 over MQTT for our connected products, with mutual authentication (mTLS) and certificate pinning when context requires it
• Secure Linux BSP: our custom Linux BSPs (Yocto) include firmware signing, secure OTA updates with rollback, and locked-down debug interfaces
• Secure RTOS choice: on microcontrollers, we use Zephyr RTOS with MCUboot, TF-M and PSA Certified, or FreeRTOS with the AWS IoT libraries for cloud deployments
• Certification support: we prepare CE/RED compliance including the cybersecurity requirements of Article 3.3

CI/CD pipeline: the only path to production

At AESTECHNO, we have set up security-oriented CI/CD pipelines on multiple customer projects: secret detection, static analysis, code signing and auto-deploy gated on tests. Twin objectives: minimal regression and a hardened delivery chain. Our operating principle is unambiguous, the pipeline is the only path to production. Server backends and mobile apps (Play Store) only receive a new build after the full test suite passes; no manual intervention can bypass the signing chain or the automated review.

IoT data layer: top-tier HA cluster

We have designed and deployed a top-tier HA database cluster for large-scale sensor ingestion. End-to-end coverage, hardware, firmware and cloud/data on the same project, remains rare on the market. In our practice, what kills an IoT project isn't write latency: it's what happens when a node goes down at 3 a.m. with 50,000 sensors transmitting. Multi-node replication, automatic failover and immutable audit logs close the chain of trust started by secure boot.

Secure elements: ATECC608B vs SE050 vs OPTIGA Trust M, how to choose

The choice of secure element is the lever that drives achievable certification level and BOM cost for a connected product, and it is best settled at MCU selection rather than late in the design cycle.

Four references dominate in 2026: the Microchip ATECC608B, the NXP SE050, the Infineon OPTIGA Trust M and the ST STSAFE-A110. All four connect over I²C and support ECDSA on P-256, but they differ in curve and RSA coverage, AES key length and Common Criteria level, from EAL4+ to EAL6+. The right pick depends on the target standard (ETSI EN 303 645, IEC 62443-4-2 or ISO/SAE 21434), on the MCU ecosystem already on the board, and on whether an integrated KMU is already enough. The table compares interface, algorithms and certification:

Practical recommendations: the ATECC608B remains the most cost-effective option for a consumer IoT product under ETSI EN 303 645, capacity to store up to 16 keys, factory provisioning via Microchip Trust Platform. The NXP SE050 suits IEC 62443-4-2 (industrial) products and applications requiring RSA or curves beyond P-256 (payment, identity). The Infineon OPTIGA Trust M stands out for its mature provisioning toolkit for automotive (ISO/SAE 21434). The ST STSAFE-A110 integrates naturally into STM32 ecosystems and simplifies the BOM if you already use an STM32U5/H5.

ATECC608B vs integrated KMU (nRF5340, STM32U5): an integrated KMU is enough for most ETSI EN 303 645 use cases. An external secure element becomes relevant when you target Common Criteria EAL5+ or higher, or when the product embeds multiple MCUs sharing the same cryptographic identity. Further reading: ENISA (European IoT cybersecurity guidance), NIST (SP 800-213 IoT series), and the OWASP IoT Top 10 for the attack patterns to test in pre-compliance security work.

Bottom line: IoT security that holds against the CRA

A reference-grade secure IoT product stacks concrete, measurable choices: secure boot via ROM+MCUboot with ECDSA-P256 signing (verification under 10 ms) or Ed25519 (under 3 ms), key storage in an integrated KMU or a Common Criteria EAL4+ certified secure element, TLS 1.3 + mTLS on MQTT/CoAP with mandatory forward secrecy, dual-slot OTA with automatic rollback and a hardware anti-downgrade counter, SWD port locked in production (APPROTECT on nRF, RDP Level 2 on STM32). At AESTECHNO, we apply this stack on Zephyr+MCUboot+TF-M on nRF5340/nRF9160 and STM32H5/U5, with a CI/CD pipeline generating a signed CycloneDX SBOM on every release, compliant with the Cyber Resilience Act (EU 2024/2847), ETSI EN 303 645, IEC 62443-4-2 and RED Article 3.3. The IoT product that holds up in audit isn't the one that bolted on measures at the end of the cycle, but the one whose architecture was decided at MCU selection.

Related articles

Go deeper on every dimension of IoT security with these companion resources:

• Industrial IoT cybersecurity: threats and solutions, Threat overview, Zero Trust architecture, and Zero-Knowledge Proofs for industrial IoT.
• CE/RED certification for IoT products, Certification process and RED Article 3.3 cybersecurity requirements for radio equipment.
• Zephyr, FreeRTOS, real-time Linux: which embedded OS to choose?, RTOS comparison with a focus on security features (MCUboot, TF-M, PSA).
• Embedded Linux distributions: systemd, Alpine, Yocto, Building secure Linux BSPs with Yocto for production products.
• Bluetooth 5.4 and PAwR: complete guide, BLE security: pairing modes, LE Secure Connections, and AES-128 encryption.
• From idea to certified product, Our design process with a security audit at every milestone (EVT, DVT, PVT).
• AESTECHNO electronic design services, Our design methodology, from schematic to series production.

FAQ: IoT security from design to deployment

What is secure boot, and why is it essential for an IoT product?
Secure boot is a hardware mechanism that verifies the firmware's cryptographic signature at startup. If the signature is invalid, the device refuses to run. Without secure boot, an attacker can replace the firmware with a malicious version. This protection is now required by the Cyber Resilience Act for all digital products sold in the EU.

How does a secure OTA update work?
A secure OTA update relies on four mechanisms: encrypted transport (TLS 1.3), firmware signed by the manufacturer, signature verification by the bootloader before execution, and automatic rollback on failure. MCUboot's dual-slot (A/B) architecture guarantees a device never ends up in a non-functional state after an update.

What's the difference between a KMU and a secure element?
The KMU (Key Management Unit) is integrated directly into the microcontroller, an internal module that protects keys without requiring an additional component. A secure element (ATECC608B, OPTIGA) is a dedicated external component, connected over I²C, with its own Common Criteria certification. The KMU is sufficient for most IoT applications. The secure element is recommended for very-high-security applications (payment, identity).

Does the Cyber Resilience Act apply to my product?
If your product contains a digital component (software, or hardware that communicates) and is sold in the European Union, the CRA applies. This includes connected objects, gateways, sensors with firmware, and embedded software. Obligations include security by design, providing security updates, an SBOM (Software Bill of Materials), and reporting vulnerabilities within 24h.

Should SWD/JTAG ports be locked in production?
Yes, systematically. An open SWD port in production lets anyone with a debugger read the entire flash, firmware, keys, certificates. On nRF, enable APPROTECT. On STM32, configure RDP Level 1 minimum (Level 2 for critical applications). This measure is one of the simplest and most effective in IoT security.

How do you manage per-device unique key provisioning in production?
Provisioning fits into the factory programming chain. Each device receives a unique private-key/certificate pair, generated either on the device itself (via the KMU or secure element) or on a secure provisioning server. Keys are injected via SWD before the debug port is locked. This process requires a PKI infrastructure and automated production scripts.