Firmware security from the bootloader up: what the Cyber Resilience Act means for connected industrial machines

For many years, security in the embedded systems world occupied a borderline position: something to address, perhaps, once the product was finished, or when a customer explicitly requested it. Industrial machines communicated over closed networks, microcontrollers were unreachable from the outside, and the attack surface was small enough that the problem could be managed with common sense and a few sensible precautions.

That context has changed substantially. Machines are now connected. Embedded products communicate with cloud infrastructure. Update cycles have become continuous. And with connectivity has come exposure.

The European Cyber Resilience Act was created in response to precisely this shift. It is not a document that concerns only consumer software manufacturers: it directly affects those who design and develop products with connected digital components, including industrial machines. And it requires security to be treated not as an additional layer bolted on at the end, but as an intrinsic property of the product, addressed from the very first stages of its conception.

What the Cyber Resilience Act requires for connected embedded products

The Cyber Resilience Act, adopted at European level, establishes essential cybersecurity requirements for products with digital elements placed on the EU market. Its scope covers hardware and software products that can connect, directly or indirectly, to networks or other devices.

Among the requirements the regulation introduces are the need to design products that are secure by default, to guarantee the availability of security updates over a defined period, to manage and communicate vulnerabilities in a structured way, and to document the security decisions made during development.

The application timelines are phased, and the finer normative details are still evolving at the implementation level. For this reason, before making decisions based on specific provisions of the regulation, it is always advisable to consult a legal adviser who specialises in regulatory compliance.

That said, the direction is clear. And for those developing firmware for industrial machines, some of the technical implications are already definable with reasonable precision.

Secure boot: a foundation that cannot be added afterwards

Secure boot is the mechanism that guarantees the authenticity and integrity of firmware before it is executed. In practice, each phase of the boot process cryptographically verifies the next, starting from a root of trust anchored in hardware: only code signed with the correct key is executed, and everything else is blocked.

In the context of CRA obligations and industrial firmware security, secure boot is not an optional addition. It is a prerequisite. And this is precisely its most important characteristic from a design perspective: it cannot be inserted retrospectively in any effective way, because it requires specific choices at the level of microcontroller selection, memory structure, and bootloader organisation.

A system designed without this architecture can be physically compromised through the injection of unauthorised firmware, which could alter the behaviour of the machine in ways that are difficult to detect. With secure boot active, even physical access to the board is not sufficient to modify the running code without the appropriate private key.

Implementation requires attention across several levels: management of the cryptographic key lifecycle, protection of public key storage, irreversible disabling of debug interfaces in production, and a build process structure that guarantees the signing chain. None of these aspects is trivial, but all of them are manageable when they are considered from the architecture phase.

Signed OTA updates: architecture and resilience

The ability to update firmware remotely is now expected as standard in connected machines. Over-the-Air updates make it possible to distribute security fixes, functional improvements, and regulatory adaptations without any physical intervention in the field. But an insecure OTA system is an attack surface, not a feature.

A robust OTA architecture requires that every firmware image distributed is cryptographically signed by the manufacturer. The device verifies the signature before accepting any update: if verification fails, the image is rejected and the previous firmware continues to run. This process concerns not only the signing of the file as a whole, but ideally also the verification of image integrity during the write to memory.

Alongside verification, a reliable OTA system implements a rollback mechanism: if the new firmware fails its boot checks or produces critical errors in the early stages of execution, the device automatically reverts to the last known good version. In an industrial context, where operational continuity is critical, this recovery capability is not a comfort feature but a requirement.

Developing firmware for industrial machines that incorporates these capabilities requires early planning of the flash memory structure, partition management, and the communication protocol with the update distribution server.

Hardware root-of-trust: why the silicon matters

Software security is only as effective as the hardware foundations it rests upon, and those foundations must be ones that cannot be circumvented. The concept of hardware root-of-trust refers to precisely this: a physical element of the system whose integrity is guaranteed by construction, and on which the entire trust chain of the device depends.

In practice, this translates into the use of microcontrollers or processors that incorporate dedicated security features: protected memory areas, hardware cryptographic engines, hardware random number generators, and secure boot mechanisms integrated into the silicon itself. Some architectures, such as those based on ARM's TrustZone, allow the creation of separate execution environments - a Trusted Execution Environment - in which sensitive code is isolated from the rest of the application firmware.

Alternatively, or in addition, discrete Secure Elements can store cryptographic keys and certificates in such a way that they are never directly accessible to the main processor, significantly reducing the exposed surface in the event of application firmware compromise.

The choice between these solutions depends on the specific requirements of the product, cost constraints, and acceptable complexity. But the decision must be made during component selection, not during integration.

Security-by-design: security as an architectural attribute

All of these elements - secure boot, signed OTA updates, hardware root-of-trust - share one defining characteristic: they work when they are planned from the outset. There are no shortcuts that allow robust security to be retrofitted effectively onto an architecture that never considered it.

The principle of security-by-design is not a slogan. It is the practical translation of a question that must be asked at the specification stage of a project: what are the realistic threats to this product, in this operational context, with this level of connectivity?

Answering that question requires building a threat model. Not necessarily a formal and complex document, but a structured analysis of who might have an interest in attacking the system, through which vector, and with what potential impact. From that analysis emerge the architectural decisions: which interfaces to disable, which data to protect, which operations require authentication, and which events must be logged.

In firmware development for microcontrollers used in connected industrial machines, this analysis shapes the structure of the code, memory management, communication protocol design, and validation testing. It is an investment in the design phase that reduces risk in a structural way, not merely a cosmetic exercise.

Practical implications for UK industrial machine builders

For industrial machine manufacturers who develop or commission their own electronic controls, the Cyber Resilience Act raises several concrete questions that are worth addressing before the deadlines draw closer.

Do the products you place on the market connect to external networks, supervisory systems, cloud platforms, or mobile devices? If so, they are likely within the scope of the regulation. Can the firmware that governs them be updated securely? Is there a procedure in place for managing vulnerabilities discovered after the product has been placed on the market? Is the electronics and firmware supply chain documented?

These are not questions to answer in isolation. Regulatory compliance requires the involvement of specialist legal advisers, and the precise technical specifications depend on the product, the hardware architecture, and the target market. But the technical component of these answers - that is, how to build a secure firmware system - is something where working with experienced development partners can make a substantial difference.

Electronics design and manufacturing services, when they include genuine firmware expertise, go well beyond writing code that functions correctly. They consider the entire product architecture, including its attack surfaces and its update requirements over time.

The right time to address this is now

The Cyber Resilience Act deadlines are approaching, but the real reason to address firmware security now is not regulatory. It is technical.

A secure architecture designed from the outset costs significantly less, in terms of time and resources, than retrofitting security onto a product that has already been developed. And in a market where the connectivity of industrial machines is set to increase rather than diminish, firmware security is a component of product value, not simply a compliance cost.

If you are developing a new electronic control for industrial machines, or evolving an existing product towards connectivity, the moment to address these questions is during the architecture phase, before hardware choices are locked in.

You can find further details on our approach to firmware development and electronics design. If you would like to discuss your project in concrete terms, we are available through our contact page.