Choosing the Right Memory Architecture for Firmware Security

Despite the growing number of cyber incidents on connected IoT devices, firmware security has always been an afterthought. As attackers penetrate through the system stack, targeting the boot process and low-level hardware configurations, the choice of memory architecture has become a key decision in establishing a verifiable chain of trust.

Therefore, securing firmware requires each component to be cryptographically verified before execution. The path starts with an immutable bootloader that loads and verifies the main firmware. However, the memory technologies used at each step determine the firmware vulnerability to unauthorized modification.

Internal vs. External flash

The physical location of the non-volatile memory used to store firmware is one of the most critical factors in a device’s threat model. Firmware engineers need to choose between on-chip embedded flash (eFlash) and an external flash module connected via a serial interface such as SPI or QSPI.

Embedded flash is typically integrated directly onto the microcontroller or SoC die. This architecture provides the highest level of physical security, as there is no external bus that an attacker can manipulate. Even the access to the internal flash is controlled by dedicated registers and lock bits.

In addition, eFlash supports permanent read-out protection. By shorting a dedicated security fuse, the developer can disable JTAG or SWD debugging interfaces, preventing the hacker from modifying the firmware image. However, the technology faces significant scaling issues as SoCs move to smaller nodes.

An external flash, by contrast, is placed outside the host processor and communicates through a high-speed serial interface. This architectural choice makes it easy to scale storage capacity, but it also expands the system’s attack surface. Any data moving between the processor and external flash is inherently vulnerable to snooping, man-in-the-middle attacks, and physical tampering.

To address these risks, firmware engineers must implement robust hardware and software protections. Many external NOR flash devices come with a physical write-protect pin. When the pin is held at a specific voltage, the internal logic of the chip prevents any erase or write commands from being executed.

Figure 1: Winbond Electronics’ W77Q32JWSSIR TR secure serial NOR flash memory with sophisticated cryptographic encryption of the communication channel. (Image source: Winbond Electronics)

But simply locking the flash is insufficient if the data can be read. Attackers can still access the address and data bus during execution. This vulnerability led to the development of specialized, secure flash devices that include hardware-based Root-of-Trust mechanisms, encrypted communication channels, and monotonic counters to prevent rollback attacks.

Yet, if the wrong memory architecture is chosen, the device can be left with a fundamental weakness that no software patching can fully fix. For instance, a design that stores firmware on an external EEPROM with no encryption or authentication will always be vulnerable to hardware attackers. On the flip side, choosing a memory that is too restrictive could hamper functionality.

Therefore, it is essential for engineers to understand best practices and design tips to maximize firmware security through memory architecture.

Best practices for secure firmware storage design

Firmware engineers must follow these principles when designing a secure firmware storage path from power-on to runtime:

1. Hardware-based Root-of-Trust

Execution must always begin from an immutable memory region. For example, a boot ROM or a permanently secure flash sector should contain the code that verifies all other firmware. This will ensure that an attacker cannot bypass verification by tampering with the initial code.

2. Use cryptographic signatures

Implement a secure bootloader that runs only firmware images signed with a trusted private key. This defends against unauthorized code, even if an attacker can access the memory and modify bits. If confidentiality is a concern, encrypt the firmware in storage.

3. Leverage the hardware security features

If the system architecture uses external memory, engineers should choose devices that support hardware security, such as built-in password protection or simple encryption. While these may not be as strong as a full secure element, they add another layer of protection.

Figure 2: Macronix’s MX25L3233FM2I-08Q 32 Mb serial NOR flash memory with support for serial peripheral interface. (Image source: Macronix)

4. Isolate firmware and data

Organize memory regions so that the most sensitive code is separated. In MCUs, put critical routine instructions in secure memory sections. Even with firmware, if the hardware supports it, mark certain flash memory banks as execute-only or read-only.

5. Plan for security firmware updates

Ensure that the update process itself is authenticated (example, require signed update packages). If the design uses an external memory for staging updates, treat it with the same security as the primary firmware storage.

Conclusion

Choosing the right memory for firmware can either make or break the security of any embedded IoT device. An insecure memory choice, such as external storage with no protection, opens the door to attackers. In contrast, a well-chosen architecture that combines on-chip memory with secure external storage and cryptographic controls provides a strong foundation for defending against sophisticated attacks.

For firmware engineers, the key takeaways are keeping the Root-of-Trust in tamper-resistant memory, treating off-chip memory as untrusted and compensate accordingly, and using the full set of hardware security features provided by modern memory technologies. By aligning memory technology with the device’s security requirements, we can protect even the smallest IoT sensor against firmware-level attacks.