How can secure firmware update design support connected product compliance?
A connected product is rarely finished when it leaves production.
New vulnerabilities can emerge after launch, third-party software components may need patching and security expectations can change during the product’s working life. Manufacturers therefore need a reliable way to update devices that may already be installed in homes, vehicles, machinery or remote equipment.
However, providing an update mechanism is not enough. If a device accepts an untrusted file, installs firmware intended for another product or becomes unusable when an update is interrupted, the update process can introduce as much risk as it removes.
Secure firmware update design creates a controlled route from an approved software release to a verified, recoverable installation on the device. It also gives manufacturers a practical way to respond to vulnerabilities and demonstrate that connected products can be supported throughout their intended lifecycle.
Why connected products need a supportable update path
Connected products remain exposed to change long after the hardware design has been completed.
A communication protocol may be found to contain a weakness. A third-party library may require a security patch. Changes to a cloud platform could affect compatibility, while new attack methods may expose risks that were not understood when the product was originally developed.
Without a supportable update path, addressing those problems may require physical access to every device. For products installed across customer sites, vehicles or remote assets, that can turn a firmware issue into a costly service programme or product recall.
The regulatory direction is also clear. The EU Cyber Resilience Act introduces cybersecurity requirements covering the planning, design, development and maintenance of hardware and software products with digital elements placed on the EU market.
The Act entered into force on 10 December 2024. Its main obligations apply from 11 December 2027, while vulnerability and incident reporting obligations apply from 11 September 2026.
From that date, manufacturers must submit an early warning about an actively exploited vulnerability or qualifying severe security incident within 24 hours of becoming aware of it. A fuller notification generally follows within 72 hours.
Reporting a vulnerability is only one part of the response. The manufacturer also needs to investigate it, develop an appropriate correction, test the change and make it available to affected products. If those products were not designed to receive secure updates, responding within a sensible timeframe becomes much harder.
Secure firmware update design does not automatically make a connected product compliant. Compliance depends on the complete product, its risk assessment, development process, documentation and ongoing vulnerability management. However, a secure and supportable update route provides much of the technical foundation needed to correct problems after release.
Signing, verification, rollback and version control
A secure update process needs to establish that the firmware is genuine, suitable for the device and unchanged since it was approved.
Digital signing is commonly used to create that trust. The manufacturer signs an approved firmware image using a protected private key. The device then uses a corresponding public key to check the signature before allowing the update to be installed.
This is different from encrypting the firmware. Encryption can prevent others from reading the file, while signing allows the device to verify where the file came from and whether it has been altered. Depending on the product and its risks, both may be appropriate.
The signing process is only as secure as its key management. Private signing keys should be protected from unauthorised access and separated from everyday development environments. The design should also consider how keys can be rotated or revoked if one is compromised.
In a UK government survey of consumer IoT manufacturers, 67% of the 33 manufacturers surveyed said they ensured the integrity of device software across all their products. Only 48% said sensitive security parameters were securely stored across every product.
These figures were self-reported and came from a relatively small sample. They also measure broader software integrity and security-parameter storage rather than signing-key management specifically. However, the difference illustrates why a secure update architecture needs to cover key handling and protected parameters, not simply the act of signing a firmware file.
Verification should extend beyond checking the signature. The update package may also need to identify:
- The intended product and hardware revision
- The firmware version and build
- Memory and storage requirements
- Dependencies or bootloader requirements
- A cryptographic hash for integrity checking
- Any required migration of configuration or stored data
These checks help prevent correctly signed firmware from being installed on the wrong device or hardware version.
The device also needs to remain recoverable if the installation fails. Power may be lost halfway through an update, communications may drop out or the new firmware may start but fail an operational health check.
Dual-bank flash, A/B firmware partitions or a separate recovery image can allow the product to retain a known-good version while the new release is installed and tested. If the update does not complete successfully, the bootloader can return the device to an operational state rather than leaving it unusable.
This rollback process needs to be controlled carefully. Allowing unrestricted installation of older firmware can create a downgrade attack, where an attacker deliberately returns the product to a version containing a known vulnerability. Version checks, security counters or minimum permitted firmware levels can prevent that while still allowing recovery to an approved known-good image.
The current ETSI EN 303 645 standard for consumer IoT devices reflects these principles. It recommends authenticity and integrity checks for software updates, identifies version checking as a way to prevent downgrade attacks and highlights watchdogs, dual-bank flash and recovery partitions as ways to recover from unsuccessful automatic updates.
Version control is equally important behind the device. Manufacturers need to know which firmware was released, what changed, which products received it and whether deployment succeeded. Build records, release approvals and update logs help connect an issue reported in the field with the relevant source code, third-party components and affected hardware.
Without that traceability, even a technically secure update mechanism can become difficult to manage at scale.
Designing firmware updates around product lifecycle obligations
Update support needs to be considered while the product architecture is still flexible.
A long-lived product may require additional flash memory for two firmware images, processing capacity for cryptographic verification and protected storage for security parameters. It may also need a bootloader that can be maintained separately from the main application and a communication route capable of transferring updates reliably.
Leaving these decisions until after the hardware has been finalised can create difficult compromises. The microcontroller may lack enough memory for rollback, the update package may be too large for the available connection or the product may have no protected place to store trusted keys.
The expected support period should influence these decisions. Under the Cyber Resilience Act, manufacturers must determine and communicate how long a product will be supported and handle vulnerabilities during that period.
The CRA sets a support period of at least five years unless the product is expected to be used for less than five years. For industrial controls, vehicle systems and other products expected to remain in service for much longer, five years should not simply be treated as the default limit. The support period needs to reflect the product’s expected working life and reasonable user expectations.
Clear update commitments have not always been universal. In the UK government research, only 27% of the 33 consumer IoT manufacturers surveyed said they provided minimum security-update periods across all their products.
When researchers separately examined public information from 70 manufacturers, only 9% appeared compliant and another 10% somewhat compliant. Combined, that meant only 19% showed at least some public evidence of meeting the requirement. For 49%, the researchers could not find enough information online to determine whether an update period had been published.
The study was relatively small and was conducted ahead of the UK Product Security and Telecommunications Infrastructure regulations coming into force. It concerned UK consumer IoT requirements rather than current readiness for the EU Cyber Resilience Act. Even so, it demonstrates the wider problem: update support cannot remain an internal assumption. It needs to become a defined, documented and externally understandable part of the product lifecycle.
That obligation reaches beyond the firmware stored on the device. Manufacturers may need to maintain signing infrastructure, update servers, source code, build environments, third-party component records and staff knowledge for years after the initial production run.
The lifecycle plan should therefore consider what happens if a cloud service changes, a cryptographic method becomes outdated, a software supplier ends support or the original development toolchain is no longer available. It should also establish who monitors vulnerabilities, approves corrective releases and communicates updates to customers.
Testing is another important part of that process. A security patch may close a vulnerability but still affect communication timing, battery life, stored settings or a safety-related function. Updates should be tested against representative hardware revisions and realistic operating conditions before wider deployment.
Staged rollouts can reduce risk by releasing firmware to a controlled group of devices first. Health reporting and update logs can then show whether installations are completing successfully before the release reaches the full product population.
Guidance from NIST describes firmware resilience through three connected principles: protecting firmware against unauthorised changes, detecting changes that do occur and recovering rapidly and securely. Those principles are useful whether a product is a consumer IoT device, industrial controller or connected vehicle subsystem.
At TAD Electronics, hardware and firmware can be considered together from the beginning of product development. That makes it possible to plan the memory, processing, communications and recovery features needed to support secure updates before the product reaches manufacture.
Secure firmware update design is ultimately about keeping control of the product after it enters the field. It gives manufacturers a safer way to fix vulnerabilities, protect installed devices and meet responsibilities that may continue for many years after launch.
Click here to get in touch or here to read more.
‘Engineering Design, Imagine what could exist’
Got a web design question or mobile application need? Our in-house design agency, Bluebrick Studios, has you covered. Check out their site to find out how they can help you achieve your mission.
Frequently asked questions
What is secure firmware update design?
Secure firmware update design is the process of creating a controlled way to deliver, verify, install and recover firmware updates on an embedded device. It typically includes digital signing, integrity checking, version control, compatibility checks and a recovery mechanism for failed installations.
Why do connected products need signed updates?
Signed updates allow a connected product to verify that firmware came from an authorised source and has not been altered. Without this check, an attacker may be able to install modified or malicious firmware through the product’s update mechanism.
How does firmware rollback protect embedded devices?
Firmware rollback allows a device to return to an approved known-good version when a new update fails to install or operate correctly. It is commonly supported through dual-bank flash, A/B partitions or a protected recovery image. Rollback controls should also prevent deliberate downgrades to firmware containing known vulnerabilities.