Hardware security design is the practice of anchoring a device’s trust chain in tamper-resistant silicon — making it physically impossible to extract cryptographic keys, forge firmware signatures, or bypass authentication mechanisms through software attacks alone. Unlike software security (which relies on code correctness), hardware security provides a root of trust that cannot be compromised by vulnerabilities in the application, OS, or network stack.
With the EU Cyber Resilience Act (EU 2024/2847) mandating secure boot, authenticated updates, and vulnerability management for all connected products by December 2027, hardware security is no longer optional — it’s a regulatory requirement.
The Hardware Security Stack
A properly secured embedded device implements security at every layer:
| Layer | Component | Function | Example |
|---|---|---|---|
| Root of Trust | Secure Element (SE) or TPM | Tamper-resistant key storage, cryptographic operations | Infineon OPTIGA Trust M (CC EAL6+), NXP SE050 |
| Secure Boot | First-stage bootloader in OTP/protected flash | Verifies firmware signature before execution | ARM TrustZone + Secure Boot ROM |
| Secure OS Partition | TrustZone Secure World or RISC-V PMP | Isolated execution of security-critical code | OP-TEE, TF-M (Trusted Firmware-M) |
| Cryptographic Engine | Hardware AES, SHA, ECC accelerator | Performant crypto without CPU overhead | STM32 CRYP/HASH, ESP32 AES-XTS |
| Secure Storage | Encrypted flash with key derived from SE | Protected firmware and configuration data | OTFDEC (on-the-fly decryption) |
| Secure Communication | TLS 1.3 with hardware-backed credentials | Authenticated, encrypted data in transit | ATECC608B + AWS IoT Core |
| Secure Update | Dual-bank A/B OTA with rollback protection | Authenticated firmware updates | MCUboot, SWUpdate |
Secure Elements: The Foundation of Hardware Trust
A Secure Element (SE) is a dedicated, tamper-resistant IC designed to store cryptographic keys and perform cryptographic operations in a physically protected environment:
| Secure Element | Certification | Key Storage | Crypto Algorithms | Interface | Price Range |
|---|---|---|---|---|---|
| Infineon OPTIGA Trust M | CC EAL6+ | ECC P256/P384, RSA 2048 | ECDSA, ECDH, SHA-256, TRNG | I²C | €0.80–1.50 |
| NXP SE050 | CC EAL6+ | ECC, RSA, AES, Ed25519 | ECDSA, ECDH, AES-128/256, SHA-256/384/512 | I²C | €1.00–2.00 |
| Microchip ATECC608B | FIPS 140-2 (pending) | ECC P256 | ECDSA, ECDH, SHA-256, AES-128, TRNG | I²C | €0.50–0.80 |
| STMicro STSAFE-A110 | CC EAL5+ | ECC P256/P384 | ECDSA, ECDH, SHA-256/384, TRNG | I²C | €0.60–1.00 |
Why hardware, not software? A cryptographic key stored in MCU flash can be extracted via JTAG/SWD debugging, side-channel attacks (power analysis, electromagnetic emanation), or flash readout. A Secure Element stores keys in a shielded, tamper-detecting environment with active countermeasures — the key literally cannot leave the chip.
PSA Certified: The Industry Security Framework
ARM’s PSA (Platform Security Architecture) Certified framework provides a standardized security certification for MCU-based devices:
| Level | What It Certifies | Lab Evaluation Required | Typical MCUs |
|---|---|---|---|
| PSA Certified Level 1 | Security questionnaire, threat model, basic security functions | Self-assessment | STM32L5, Nordic nRF5340 |
| PSA Certified Level 2 | Software attack resistance, secure boot, secure update | Independent lab (8–12 weeks) | STM32U5, NXP LPC55S69 |
| PSA Certified Level 3 | Hardware attack resistance (fault injection, SCA) | Advanced lab (12–16 weeks) | STM32H5 + SE, Renesas RZ/G |
PSA Certified Level 2 is becoming the minimum expectation for commercial IoT products. It aligns closely with the CRA’s technical requirements and provides a clear compliance argument.
The Secure Boot Chain
A properly implemented secure boot chain prevents any unauthorized code from executing on the device:
1. ROM Bootloader (immutable, burned into silicon)
├── Verifies signature of Second-Stage Bootloader
└── If invalid → HALT (device does not boot)
2. Second-Stage Bootloader (MCUboot / U-Boot)
├── Verifies signature of Application Firmware
├── Manages A/B firmware slots for OTA updates
└── If invalid → Rollback to last known-good image
3. Application Firmware
├── Runs in Non-Secure World (TrustZone)
├── Accesses crypto services via Secure World API
└── Cannot access Secure Element keys directlyCritical requirement: The first-stage bootloader must be immutable — stored in OTP (One-Time Programmable) memory or ROM. If an attacker can modify the bootloader, the entire security chain collapses.
Post-Quantum Cryptography: Preparing for the Quantum Threat
Current asymmetric cryptography (RSA, ECC, Diffie-Hellman) will be broken by sufficiently powerful quantum computers. NIST finalized the first post-quantum cryptographic standards in 2024:
| Algorithm | NIST Standard | Type | Key Size | Performance on Cortex-M4 |
|---|---|---|---|---|
| ML-KEM (CRYSTALS-Kyber) | FIPS 203 | Key Encapsulation | 1,568 bytes (KEM-768) | ~1 ms encapsulation |
| ML-DSA (CRYSTALS-Dilithium) | FIPS 204 | Digital Signature | 2,420 bytes (DSA-65) | ~3 ms sign, ~1 ms verify |
| SLH-DSA (SPHINCS+) | FIPS 205 | Digital Signature (stateless) | 7,856 bytes | ~50 ms sign |
Impact on embedded systems: Post-quantum key sizes and signature sizes are 10–100× larger than ECC equivalents. This affects flash storage (for certificate chains), RAM (for signature verification buffers), and bandwidth (for OTA update signatures). Hardware designers need to plan for these requirements now, even before PQC is mandated.
The recommended approach: hybrid certificates that include both ECC and PQC signatures, ensuring compatibility with current infrastructure while providing quantum resistance.
Common Security Architecture Mistakes
| Mistake | Why It’s Dangerous | Correct Approach |
|---|---|---|
| Shared device credentials | One compromised device exposes all devices | Per-device unique credentials provisioned during manufacturing |
| Symmetric-only key exchange | No forward secrecy, replay attacks possible | ECDHE or ML-KEM key exchange for each session |
| Debug port left enabled | JTAG/SWD allows full memory readout | Disable debug in production via option bytes + RDP Level 2 |
| Software-only key storage | Keys extractable via flash dump or glitching | Hardware SE with tamper detection and active shielding |
| No firmware rollback protection | Attacker can downgrade to vulnerable version | Monotonic counter in SE/OTP prevents downgrade |
Our Security Engineering Approach
At Inovasense, hardware security is an architecture decision made in the requirements phase — not a feature added before certification. We design security from the silicon up:
- Threat modeling — STRIDE analysis during system architecture to identify attack surfaces
- Security IC selection — Right SE/TPM for the application (cost, certification level, algorithm support)
- Secure boot implementation — Immutable bootloader + MCUboot for managed A/B updates
- Credential provisioning — Per-device key injection during production using automated HSM workflow
- OTA infrastructure — Signed, encrypted firmware delivery with delta updates and rollback protection
All security implementations follow PSA Certified guidelines and are designed for CRA compliance from day one. Contact us to discuss your security architecture.