IN Brief:
- ArmorFlash combines protected storage, cryptographic functions, device identity, and anti-rollback mechanisms behind standard serial-memory interfaces.
- ArmorBoot authenticates firmware inside the memory device while supporting secure updates, device recovery, and rollback protection.
- CRA reporting obligations began on 11 September 2026, while the regulation becomes fully applicable in December 2027.
Macronix International is positioning its ArmorFlash and ArmorBoot secure memory families around the European Union’s Cyber Resilience Act, bringing storage protection, device authentication, secure boot, and firmware recovery into hardware connected through standard memory interfaces.
The regulatory timing makes those functions more immediate for electronics manufacturers. CRA reporting obligations for actively exploited vulnerabilities and severe security incidents took effect on 11 September 2026, while the regulation’s main product requirements become fully applicable on 11 December 2027. Manufacturers therefore have to prepare product architectures and lifecycle processes while already operating under the new reporting regime.
ArmorFlash is designed as a secure storage platform rather than conventional flash with security handled entirely by the host processor. Macronix supports SPI, QSPI, and OctaBus interfaces alongside configurable protected regions, hardware cryptographic engines, true random number generation, physical unclonable function support, and non-volatile monotonic counters.
Those counters provide a hardware mechanism for resisting rollback and replay attacks. A system can prevent an older authorised image from being reintroduced after a security update by retaining an authenticated version state in non-volatile memory. Hardware key handling and authenticated links between the host and memory add protection for code and data moving across an external bus.
ArmorBoot narrows the focus to firmware authentication, secure startup, and software maintenance. The MX76 family uses a standard serial interface but can verify stored firmware internally, allowing the host to establish whether the code is authentic before execution. Macronix also includes secure update functions, device recovery, and monotonic counters intended to block unauthorised rollback.
The distinction matters because embedded security is made up of several separate controls. Secure boot establishes whether trusted software is being loaded, protected storage limits access to keys and sensitive data, and update controls determine whether a deployed product can move safely to corrected firmware later in its life. A weakness in any one of those stages can undermine protections elsewhere in the system.
The CRA adds a regulatory layer to that engineering problem. Its requirements extend beyond the silicon itself to secure product development, vulnerability handling, support periods, corrective updates, and incident reporting. A secure memory device cannot make a finished product compliant on its own, but it can provide hardware mechanisms that support the wider security architecture manufacturers have to document and maintain.
Macronix identifies automotive electronics, industrial control, networking, medical systems, computing, and connected embedded products among the markets for ArmorFlash. Its MX78 automotive secure NOR family has also been developed under ISO/SAE 21434 cybersecurity processes, placing the memory architecture alongside sector-specific requirements already being applied in vehicle electronics.
Using standard memory interfaces is central to the approach. System designers can add authentication, protected storage, and rollback controls without replacing the processor solely to obtain those functions. That is particularly useful in established embedded platforms where a major processor change can trigger software redevelopment, PCB changes, and renewed qualification.
The hardware still has to be integrated correctly. Secure flash does little if keys are mishandled elsewhere, firmware signing is weak, update servers are compromised, or manufacturers stop maintaining vulnerable products before the end of their declared support periods. CRA compliance therefore remains a system and organisational obligation rather than a component certification exercise.
The shift is nevertheless pushing security further down the electronics stack. Functions previously implemented mainly in application software are increasingly being anchored in processors, secure elements, and memory devices that can retain identity and protection independently of the host code.
With CRA reporting already active and full application approaching in 2027, that hardware layer is becoming harder for connected-product developers to treat as optional. Macronix’s proposition is that familiar serial memory can carry more of the authentication, storage, and recovery burden while leaving manufacturers to build the processes and software needed around it.
