Secure Firmware Update Architecture for Industrial Connected Products

An update mechanism is the one security control that lets you fix every other security problem after a product ships. For industrial equipment it’s also the riskiest code path you own: a bad update can stop a production line, and an attacker who controls your update channel controls your fleet.

This guide sets out a secure firmware update architecture for industrial connected products, from the signing key to the fleet report. It’s part of our embedded and firmware security hub. It’s written for firmware leads and engineering managers at US makers who sell into the EU, where the EU Cyber Resilience Act now ties update capability to a legal support period.

Why industrial updates are a different problem

The IETF’s firmware update architecture for IoT (RFC 9019) notes that updates matter most when devices have long lifetimes or sit in remote places where manual work is hard ^[5]. It also says devices must not fail when a power loss or network drop interrupts an update ^[5]. Industrial equipment has all of those conditions, plus a few of its own:

• Intermittent connectivity. Many machines sit behind plant firewalls, on cellular links, or offline for long stretches. Some only see an update when a technician plugs in a laptop or USB stick.
• Maintenance windows. Customers decide when a machine may restart. An update that installs on its own schedule can break a production plan.
• Safety interlocks. Updating control firmware while a machine is running can create a hazard. RFC 9019 recognizes that the final decision to install may need a person’s confirmation for safety reasons ^[5].
• Long fleets. The CRA’s recitals note that industrial products are often in use for much longer than five years ^[1]. Your signing keys, crypto choices and update servers may have to outlive several hardware generations.
• Mixed fleets. One installed base can hold several board revisions, bootloader versions and partition layouts at once.

The CRA itself recognizes the long-life point. Its recitals say products for industrial settings, such as industrial control systems, are often in use for much longer periods, and that products expected to be used for more than five years should get longer support periods ^[1].

What the Cyber Resilience Act asks of your update path

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its reporting obligations under Article 14 have applied since 11 September 2026, and its main obligations apply from 11 December 2027 ^[1][2][3]. The provisions below are paraphrased. Read the text itself ^[1] and see our Cyber Resilience Act support period guide for the planning side.

Support period (Article 13(8)). Manufacturers must handle vulnerabilities effectively for a support period they set, based on how long the product is expected to be in use. The period must be at least five years, unless the product is expected to be used for less time ^[1]. The Commission’s July 2026 guidance (non-binding) stresses that five years is a floor, not a default ^[4]. The information used to set the period goes into the technical documentation ^[1].

Update availability (Article 13(9)). Each security update released during the support period must stay available for at least 10 years after release, or for the rest of the support period if that’s longer ^[1]. That’s an artifact-retention requirement for your update infrastructure, not just a device feature.

End-of-support notice (Article 13(19)). The end date of the support period (at least month and year) must be clear at the time of purchase. Where technically feasible, the product should tell users when support has ended ^[1].

Annex I, Part I, point (2)(c). Products must allow vulnerabilities to be fixed through security updates. Where applicable, that includes automatic security updates installed within an appropriate timeframe and enabled by default, with a clear opt-out, user notification of available updates, and the option to postpone them temporarily ^[1].

Annex I, Part II. Vulnerability-handling duties include fixing vulnerabilities without delay through security updates, shipping security updates separately from feature updates where technically feasible (point 2), providing mechanisms to distribute updates securely and, where applicable for security updates, automatically (point 7), and disseminating security updates without delay, free of charge unless otherwise agreed for a tailor-made product with a business user, with advisory messages (point 8) ^[1].

Annex II. User instructions must cover how security-relevant updates can be installed and how the automatic-update default can be turned off ^[1].

For industrial products, the postponement and opt-out language in Annex I is what makes maintenance windows and operator approval workable. How far "appropriate timeframe" stretches for a plant that patches twice a year is a question for counsel, not this page.

Two related points from the Commission’s guidance:

• A security update that doesn’t change the product’s intended purpose or add new cybersecurity risk generally isn’t a "substantial modification" ^[4].
• An update can still be a substantial modification if it materially changes the product’s boundaries or dependencies, for example by adding new externally reachable interfaces. The guidance suggests checking whether an update adds threat vectors or attack scenarios ^[4]. Feature work and security fixes therefore deserve separate release tracks, which also matches Annex I Part II point 2 ^[1].

If your equipment is also machinery, the Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 ^[11]. Its Annex III section 1.1.9 requires machinery to identify the safety-relevant software installed on it and to collect evidence of legitimate or illegitimate changes to that software or its configuration ^[11]. A signed update path with an install log can contribute to that evidence.

The reference architecture: six stages

The architecture below follows the roles RFC 9019 describes (an author, a firmware server, a status tracker, and a firmware consumer on the device ^[5]). It adds the industrial controls above. Each stage lists what it must guarantee.

1. Signing (build and release)

• Sign a manifest, not just the image. The manifest binds the image digest to metadata the device checks: vendor and device-class identifiers (so a board never accepts firmware for another model), a monotonic sequence number (for anti-rollback), and, for delta updates, the digest of the required base image ^[6].
• Keep signing keys in protected storage such as an HSM. RFC 9124 recommends replacing update-signing keys from time to time, and making them delegates of a longer-lived trust anchor, because replacing a trust anchor in the field is hard and risky ^[6].
• Separate duties: build, approve and sign should not all sit with one person or one CI job. The Update Framework (TUF) is designed so that compromising one key, or fewer keys than a set threshold, doesn’t compromise clients ^[9].

Key hierarchy, rotation, revocation and CI integration are covered in our firmware signing and key management guide.

2. Distribution

• Treat the transport as untrusted. Device-side verification protects the device, and TLS protects the channel and the reports.
• Plan for staged rollouts (pilot group, then waves) and for offline paths: a signed package delivered by USB or a service laptop must pass exactly the same checks as one delivered over the network.
• Defend against freeze and rollback attacks at the repository level. TUF’s design goals include stopping an attacker from serving stale metadata without the client noticing, and from tricking clients into installing older software ^[9]. Uptane applies a similar approach to automotive fleets, where compromise of one server or operator should not give full control ^[10].
• Keep every released security update available for the period Article 13(9) requires ^[1].

3. Device verification

• Verify the manifest signature against a trust anchor the device can’t be talked out of. That anchor lives in the root of trust: see secure boot and hardware root of trust.
• Check, in order: signature, vendor/class IDs, sequence number against the stored minimum, image digest, and (for deltas) the base image digest ^[6].
• Handle the long-offline device. RFC 9124 describes a device that has been offline so long it accepts an old but valid update that still has a known vulnerability ^[6]. Manifest expiry can help, but RFC 9124 notes it needs a trusted clock. It also says the last firmware you ever ship for a product should not expire ^[6], which is worth planning for at end of support.

4. Install: A/B or delta

• A/B (dual-bank) install. Write the new image to the inactive slot, verify it, then switch the boot target. The running system is never overwritten, which covers the power-loss requirement in RFC 9019 ^[5]. The cost is flash: room for two images. Bootloaders such as MCUboot offer swap- and overwrite-based upgrade strategies with different flash layouts ^[16].
• Delta install. Sends only the differences, which helps on slow or metered links. The device must authenticate which base image the delta applies to ^[6], and you need a full-image fallback for devices that have drifted.
• Recovery partition. A minimal, rarely updated image that can fetch and install a full update if both main slots fail. RAUC, for example, documents an additional rescue slot for this case ^[17].
• Gate the install. Before switching, check the maintenance-window policy, operator approval if required, machine state (for example, stopped and in a safe state), and power/battery. These checks belong in the update agent, with the safety logic owned by your controls engineers. Have functional-safety engineers confirm the gating for each machine type.
• Multi-processor products. Many devices hold more than one MCU and may need several images and manifests for one update ^[5]. Decide whether components update together or separately, and how you prevent incompatible combinations.

5. Rollback

There are two kinds, and they pull in opposite directions:

• Functional rollback (wanted). If the new image fails a health check after boot (it doesn’t reach a "healthy" state within a set time or number of boots), the bootloader returns to the previous slot. The new image is only marked permanent after it confirms itself healthy.
• Security rollback (blocked). An attacker must not be able to install an older, vulnerable image. Enforce a minimum sequence number on the device ^[6], ideally stored in hardware-backed monotonic counters or fuses. Rollback protection at the boot stage is covered in our root-of-trust guide.

One way to reconcile them: raise the stored minimum only after the new image is confirmed healthy, and only for security releases. MCUboot, for example, makes test swaps permanent only after a self-test, and notes that its security counter needn’t increase with every release ^[16].

6. Reporting

• The device reports its state back: download, verified, installed, booted, healthy, rolled back, with reason codes. RFC 9019 calls this role the status tracker ^[5]. RFC 9124 requires status reports to travel over an authenticated, confidential channel so they can’t be spoofed ^[6].
• Devices that are offline queue reports and send them on reconnect, or a technician’s tool collects them.
• Fleet reports answer the questions you’ll be asked: which units still run a vulnerable version, which ones failed, which ones are past their support end date. That data supports vulnerability handling under Annex I Part II ^[1] and, if a vulnerability is actively exploited, the reporting work under Article 14 ^[1].

Secure firmware update challenges and solutions (quick table)

Build, buy or adopt

On embedded Linux, open-source update frameworks such as Mender, SWUpdate and RAUC each implement parts of this architecture. For example, RAUC describes signed update bundles and fail-safe A/B updates ^[13], SWUpdate documents verified and encrypted update images ^[14], and Mender documents operating-system and delta updates ^[15]. We list them for orientation only, not as recommendations. For microcontrollers, the IETF’s SUIT manifest format is still an Internet-Draft at the time of writing ^[7].

Whichever route you take, your team still owns the keys, the manifest policy, the install gating and the support-period commitment. Our OTA platform vs. custom update infrastructure comparison sets out the decision criteria.

For a broader resilience model, NIST SP 800-193 organizes platform firmware resiliency around protection, detection and recovery ^[8]. For industrial components, IEC 62443-4-2 sets technical security requirements for industrial automation and control system components ^[12]. See our standards hub for how those standards relate to the CRA.

Where to start

1. Inventory each product line’s current update path: signed or not, rollback or not, offline path or not.
2. Write down the support period you expect to commit to per product, and check it against signing-key lifetimes and SoC/BSP end-of-life dates.
3. Pick the install pattern (A/B, delta, recovery) per hardware platform.
4. Define the manifest fields and anti-rollback policy before choosing tooling.
5. Agree the install-gating rules with your controls and safety engineers.
6. Stand up fleet reporting before the first field update, not after.

Use our free Secure Update Readiness Assessment to turn this into a prioritized gap list. If you’re bringing in outside help, our guide to evaluating firmware development companies lists the security questions to ask.

Spotted an error? Report it to our corrections log. Read our editorial methodology.