MCU-Based vs FPGA-Based Hardware Root of Trust: Design Trade-offs for Embedded Security

Managing Director & Tech Advisor at Promwad GmbH

Petr Shamsheyeu

Security Engineer

As embedded systems take on long-lived, connected, and security-critical roles, hardware roots of trust (HRoT) have become foundational elements of device architecture. Designers commonly choose between secure microcontrollers (MCUs) and field-programmable gate arrays (FPGAs) to anchor trust, authenticate firmware, manage cryptographic keys, and protect against physical and logical attacks.

This article analyzes the practical engineering trade-offs between MCU-based and FPGA-based HRoT implementations, incorporating lifecycle regulations such as the EU Cyber Resilience Act (CRA), evolving post-quantum cryptography standards, and real-world side-channel and physical attack considerations.

Table of contents

1. Introduction

2. Definitions

3. MCU-Based RoT: Strengths and Constraints

4. FPGA-Based RoT: Capabilities and Engineering Cost

5. Hybrid Architectures

6. Regulatory and Lifecycle Factors

7. Selection Criteria for MCU, FPGA, and Hybrid RoT

7. Comparative Summary Table & Conclusion

References

1. Introduction

Embedded devices increasingly operate in environments where robust, hardware-anchored security is mandatory: industrial controllers, IoT gateways, telecom infrastructure, and automotive systems. Many of these platforms must remain secure and maintainable for 10–15 years, often under regulatory obligations requiring long-term updates and vulnerability mitigation.

A hardware root of trust provides:

immutable device identity;

cryptographic key protection;

verified boot and firmware authentication;

secure update mechanisms;

lifecycle state control.

Two primary implementation paths exist today:

MCU-based HRoT: security anchored in fixed-function silicon using vendor-provided secure boot ROM, hardware accelerators, and protected storage.

FPGA-based HRoT: security implemented in reconfigurable logic, with custom cryptographic engines, runtime monitors, and upgradeable functionality.

This article provides concise definitions, compares the engineering implications of each approach, and outlines selection criteria supported by regulatory and lifecycle requirements.

2. Definitions

MCU-Based Hardware Root of Trust

A root of trust implemented inside a secure microcontroller with:

immutable boot ROM;

fixed-function crypto accelerators (e.g., AES-128/256, SHA-256, ECC);

eFuse/OTP device identity;

optional secure enclave or TrustZone-M isolation.

Security capabilities depend on silicon vendor design and cannot be extended beyond available hardware blocks.

FPGA-Based Hardware Root of Trust

A root of trust implemented as custom logic inside FPGA fabric, typically including:

hardware modules for cryptographic functions;

secure boot of FPGA bitstream (encryption + authentication);

runtime monitors (voltage, clock, or logic anomaly detection);

Physical Unclonable Function (PUF) identity;

reconfigurable or upgradeable crypto cores (including emerging PQC algorithms).

Security capabilities depend on HDL implementation quality and bitstream protection.

3. MCU-Based RoT: Strengths and Constraints

3.1 Benefits

Low power and low cost
Secure MCUs operate with minimal silicon area, making them appropriate for battery-powered and cost-sensitive designs.

Predictable ecosystem
Toolchains, middleware, and security libraries (e.g., secure bootloader frameworks) are mature and vendor-supported.

Reduced engineering complexity
Firmware development avoids HDL design, timing closure, and side-channel-aware hardware engineering.

3.2 Limitations

Fixed hardware logic
MCU crypto accelerators and memory architectures are static. Updating cryptographic primitives or adding custom protections is not possible.

Limited compute and monitoring capabilities
MCUs cannot efficiently support high-throughput cryptography, advanced anomaly detection, or complex side-channel countermeasures.

Lifecycle constraints
Long-lifetime devices may outlast the relevance of silicon-fixed accelerators, especially given upcoming post-quantum standards [NIST, 2025].

3.3 Risk Considerations

Secure MCUs differ substantially: some offer only basic key storage, not a full HRoT.

Misconfigured TrustZone-M leaves gaps in the trust boundary.

Vendor silicon quality directly impacts security.

4. FPGA-Based RoT: Capabilities and Engineering Cost

4.1 Benefits

Customizable hardware trust anchor
Designers can create dedicated hardware engines for authentication, key derivation, secure updates, and state machines tailored to the system threat model.

Side-channel and physical-attack resistance
FPGA logic supports fine-grained countermeasures such as masking, power balancing, asynchronous logic, or clock jitter insertion — options not available on fixed MCU silicon.

Runtime cryptographic acceleration
Unlike MCUs, FPGAs can accelerate cryptography continuously during device operation. This benefits encrypted data pipelines, authentication-heavy protocols, and proprietary or emerging algorithms.

Lifecycle and post-quantum adaptability
Reconfigurable FPGA logic can accommodate PQC cores as standards evolve, aligning with long-term support requirements.

4.2 Limitations

Potentially higher power consumption
Mid-range and high-density FPGAs consume more power than MCUs.

Higher engineering complexity
Developing a secure FPGA-based HRoT requires HDL expertise, timing closure proficiency, and side-channel-aware design practices.

Verification overhead
Security validation must include functional verification, timing analysis, bitstream authentication, and leakage evaluation.

4.3 Risk Considerations

Bitstream protection is essential; security depends on key provisioning and proper AES-GCM or CMAC authentication.

Partial reconfiguration introduces additional attack surface.

Unhardened crypto implementations may leak through side channels.

5. Hybrid Architectures

Hybrid designs combine:

MCU as the immutable trust anchor responsible for secure boot, device identity, and lifecycle states;

FPGA as an extension for high-throughput cryptography, upgradeable PQC modules, runtime monitors, or protocol offload.

This architecture allows designers to meet regulatory lifetime requirements while keeping BOM and power under control.

6. Regulatory and Lifecycle Factors

Long-lifecycle IoT, industrial, and telecom devices increasingly fall under regulations such as the EU Cyber Resilience Act (CRA), requiring manufacturers to:

provide security updates for multiple years;

maintain vulnerability management processes;

ensure secure update mechanisms.

This shifts the design trade-off:

MCU-only HRoT may be insufficient if fixed crypto blocks become outdated.

FPGA or hybrid HRoT enables long-term updates of cryptographic modules and runtime defenses.

Lifecycle compliance thus becomes a central engineering criterion, not just a business consideration.

7. Selection Criteria for MCU, FPGA, and Hybrid RoT

7.1 Device Class & Expected Lifetime

Short-lived, battery-powered endpoints → MCU.

Industrial controllers, gateways, telecom equipment → FPGA or hybrid, due to CRA-driven long-term support obligations.

7.2 Threat Model

Standard secure boot and firmware integrity → MCU.

Physical access, side-channel risk, custom algorithms → FPGA.

Mixed threat environments → Hybrid.

7.3 Upgradeability

Static security requirements → MCU.

Need for PQC enablement or programmable crypto → FPGA or hybrid.

7.4 Power and Cost

Strict BOM and energy constraints → MCU.

Moderate power budget with need for extended security → FPGA or hybrid.

7.5 Engineering Skills

Firmware-only teams → MCU.

Teams with HDL and hardware security expertise → FPGA.

Multidisciplinary teams → Hybrid.

8. Comparative Summary Table & Conclusion

Criterion	MCU-Based RoT	FPGA-Based RoT	Hybrid RoT
Power Consumption	Low	Medium–High (varies by family)	Medium
Cost	Low	Medium–High	Medium
Flexibility	Low	Very High	High
Crypto Performance	Fixed accelerators	Custom & high-throughput	Mixed
PQC Support	Limited (software only)	Hardware-upgradeable	High
Side-Channel Resistance	Vendor-defined	Custom countermeasures	Mixed
CRA Lifecycle Compliance	Limited	Excellent	High
Engineering Complexity	Low	High	Medium–High

Selecting between MCU-based, FPGA-based, and hybrid HRoT implementations requires evaluating lifecycle requirements, regulatory obligations, threat exposure, engineering capabilities, and long-term cryptographic agility.

While MCUs remain optimal for low-cost and low-power endpoints, FPGAs provide a path toward custom hardware security, runtime acceleration, and PQC readiness. Hybrid architectures bridge the gap for systems needing both a stable, certified trust anchor and high-performance, upgradeable security logic.