Why firmware update architecture mission-critical for secure OTA defence systems

The Defence IoT problem often left undiscussed

OTA stands for over-the-air: the method by which software or firmware on a connected device is updated remotely, without physical access to the hardware. In consumer technology, you see it every time your phone downloads a security patch in the background. In defence IoT, the same principle applies to a much wider and more consequential range of devices: battlefield sensors, unmanned vehicles, surveillance nodes, and communication equipment, many of which are deployed in remote or operationally active environments where manual updates are impractical or impossible. Designing secure OTA defence systems (i.e., authenticated, encrypted, tamper-resistant, and verifiable) is what separates a device with a manageable firmware lifecycle from one with a critical vulnerability waiting to be exploited.

There is a persistent assumption in defence IoT procurement that once a device passes its acceptance tests and is fielded, the firmware is largely a closed matter. Security assessments focus heavily on network architecture, physical access controls, and supply chain provenance. Far less attention is paid to a question that becomes critical the moment a vulnerability is discovered in production: how do you safely push a firmware update to a device that may be deployed in a remote, contested, or denied environment?

This is not a theoretical concern. The UK’s defence IoT estate has grown substantially across platforms, from LoRa-connected battlefield sensor networks and unmanned ground vehicles to the MAVLink-enabled UAV systems operating across increasingly autonomous mission profiles. Each of those endpoints carries firmware. Each of those firmware images will need to be updated. And each update pathway, if poorly designed, can serve as a potential vector for adversarial exploitation.

Secure OTA firmware update capability is not a feature that can be retrofitted cleanly. It depends on decisions made at the architectural level, including hardware choices, cryptographic infrastructure, and network topology, that are extremely costly to undo once a system reaches production. This post addresses the decisions, where they go wrong in defence contexts, and how to approach them correctly from the outset.

Why is Defence IoT OTA different from commercial IoT?

Consumer and commercial IoT OTA frameworks have matured considerably. Platforms like AWS IoT Jobs, Azure IoT Hub Device Update, and open-source solutions such as Mender and RAUC have established solid patterns for fleet firmware management. They handle differential updates, rollback, deployment rings, and telemetry. On the surface, they appear to be viable starting points for defence applications.

The problem is that they were designed for a different threat model.

Commercial OTA infrastructure assumes cloud reachability, relatively stable network conditions, and threat actors operating primarily at the application layer. Defence IoT operates under assumptions that are fundamentally different: intermittent or denied connectivity, adversaries with state-level capability and motivation, stringent classification boundaries, and a regulatory environment that demands auditability at every step of the firmware lifecycle.

The UK Ministry of Defence’s Cyber Resilience Strategy, aligned with JSP 440 and the NCSC’s guidance for high-assurance systems, sets expectations that commercial OTA platforms were not built to meet by default. This doesn’t mean that commercial components cannot be used; rather, it means that using them without significant architectural work on authentication, key management, and transport isolation is unlikely to pass a serious security review.

Related reading: The connectivity constraints discussed in our post on LoRa for Defence Sectors are directly relevant here. Low-bandwidth, intermittent radio links create real constraints on delta update sizes, integrity verification overhead, and retry logic that OTA system designers must account for.

The architecture of secure OTA: What needs to be done correctly

Secure OTA is best understood as a system property rather than a component feature. It spans five distinct design areas, and weaknesses in any one of them can compromise the whole.

1. Hardware Root of Trust

The foundation of any secure firmware update mechanism is a hardware root of trust. In practice, this means a microcontroller or secure element that stores immutable cryptographic keys and verifies signatures before allowing any firmware image to execute.

ARM TrustZone, supported on the Cortex-M33 and above, provides a common implementation path for defence-grade embedded systems. Trusted Execution Environments (TEEs) isolate secure boot code and key material from the main application processor, making it extremely difficult for a malicious image to compromise the verification process itself.

The key question at the hardware selection stage is whether the target device supports secure boot in a way that cannot be bypassed by an attacker with physical access and a JTAG probe. Many commercially available modules include secure boot as an option rather than a mandatory feature, and it is not uncommon for it to be disabled in early prototypes to speed up development. In defence programmes, this is a risk that routinely escapes early scrutiny and becomes a significant finding at security accreditation.

2. Cryptographic Firmware Signing

Every firmware image intended for a defence endpoint should be cryptographically signed before leaving the build environment. The signature must be verified by the device before the image is applied or executed.

The signing algorithm is important. RSA-2048 remains widely used, but ECDSA with P-256 or P-384 is generally preferred for constrained devices due to smaller key sizes and faster verification. In high-assurance contexts, EdDSA (Ed25519) is increasingly favoured.

What matters as much as the algorithm is key management. Signing keys must be held in hardware security modules (HSMs), not on developer workstations or CI/CD build servers. Key ceremony procedures, access controls, and rotation schedules need to be defined before the first production firmware build is signed, not after. In UK defence programmes, the compromise of a firmware signing key would constitute a significant security incident requiring re-evaluation of the entire deployed fleet.

3. Secure Transport and Distribution Architecture

Even a correctly signed firmware image can be compromised if the distribution channel allows an adversary to substitute or manipulate the package in transit. Transport Layer Security (TLS 1.3) is the baseline requirement for any OTA distribution over IP networks. Certificate pinning at the device level, ensuring the device only trusts a specific CA hierarchy controlled by the programme, is a further requirement in high-assurance deployments.

The distribution architecture also needs to account for air-gapped and partially connected environments. Many defence IoT deployments, particularly forward-deployed sensor networks of the kind described in our LoRa for Defence Sectors post, lack persistent IP connectivity. In these cases, OTA updates may be delivered via encrypted removable media, tactical data links, or local update servers operating within a classified enclave.

Each of these delivery pathways must apply the same cryptographic verification at the device level. The transport mechanism is irrelevant to whether the firmware image is genuine: the signing and verification chain must hold regardless of how the image physically arrives at the device.

4. Rollback Protection and Secure Bootloader Design

A secure OTA system must protect against downgrade attacks, where an adversary pushes a valid but older firmware image containing known vulnerabilities. Rollback protection is typically implemented via monotonic counters stored in non-volatile memory within the secure enclave. The device tracks the minimum acceptable firmware version and refuses to boot images below that threshold.

The bootloader architecture has direct implications for update reliability and security. Dual-bank flash configurations, where the active firmware and the incoming update occupy separate memory regions, allow the device to retain a known-good image during the update process and only commit to the new image after a successful integrity check and initial boot.

A/B partitioning schemes are well established in the Linux OTA ecosystem (via tools like SWUpdate and RAUC) but require more careful design on constrained bare-metal systems where flash capacity and RAM are limited. The balance between update reliability and flash overhead is a genuine engineering trade-off that needs to be resolved early in hardware bring-up.

5. Auditability and Update Telemetry

In defence systems, the ability to prove what firmware is running on which device at any point in time is not merely useful, but is typically a compliance requirement. OTA infrastructure must maintain tamper-evident logs of update events, including the firmware version applied, the time of application, the cryptographic verification result, and the identity of the authorising operator where human approval is required.

For classified systems, this telemetry must remain within the appropriate security boundary. Sending device telemetry to commercial cloud logging infrastructure is typically incompatible with the classification requirements of UK defence programmes. On-premises log aggregation within a secure enclave, with appropriate access controls and retention policies, is the standard approach.

Threat modelling for OTA: What defence designers frequently miss

Generic IoT security threat models focus on the obvious attack vectors: man-in-the-middle on the update channel, malicious firmware injection, and denial-of-service against the update service. Defence contexts introduce additional threat scenarios that commercial OTA frameworks do not address, such as:

Supply chain compromise at the build stage: An adversary with access to the build pipeline can inject malicious code into a legitimate firmware image before it is signed. This is not mitigated by strong transport security or device-side verification: if the image is compromised before signing, the signature is valid, and the device will accept it. Mitigations include reproducible builds, binary attestation, and separation of build and signing environments with rigorous access controls.

Adversarial probing of update traffic patterns: Even encrypted OTA traffic has metadata: timing, size, frequency. In tactical environments, observable update patterns can reveal information about system state, patch cycles, and capability changes. Traffic shaping and scheduled update windows can reduce this exposure.

Physical access exploitation: Devices in forward-deployed environments may be subject to physical capture. A secure OTA design must assume that an adversary will attempt to extract signing keys or firmware images from captured hardware. This reinforces the requirement for hardware-backed key storage and anti-tamper design, areas Ignitec routinely addresses in defence hardware development.

Related reading: The UAV platform considerations in our MAVLink Integration in Defense UAVs post are directly relevant here. UAVs face a heightened physical capture risk and are a high-value target for adversarial firmware analysis. OTA architecture for UAV payloads and flight control systems should assume physical compromise as a design scenario.

UK regulatory and procurement context for defence IoT

UK defence programmes operate within a framework that increasingly treats firmware security as a first-class concern rather than an afterthought. Several areas of regulatory guidance are directly relevant to secure OTA design.

DEF STAN 05-138 establishes cybersecurity requirements for defence suppliers and systems, including expectations around software integrity and update management. Systems procured under DEFCON 658 clauses are likely to face specific scrutiny around firmware update procedures during security assurance activities.

The NCSC’s Principles for Secure Connected Products provide a coherent framework for thinking about update security that aligns well with the engineering requirements described in this post. Key principles include ensuring that updates are cryptographically verified, that there is a defined process for responding to vulnerabilities, and that update mechanisms do not introduce new attack surfaces.

The Product Security and Telecommunications Infrastructure (PSTI) Act 2022, now in force for consumer IoT, has raised the baseline expectation across the UK technology sector for what responsible firmware update practice looks like. While defence systems are not directly subject to PSTI, procurement programmes are increasingly referencing its principles as a baseline expectation, particularly for dual-use products with both civil and military variants.

Common design failures that undermine IoT in military environments

In Ignitec’s experience working on defence-adjacent and defence-contracted hardware programmes, the following design failures recur with notable consistency.

Signing keys generated and stored in CI/CD environments: This is the single most common failure mode in firmware signing practice. Building pipelines that generate keys as part of automated processes and store them as environment variables or secrets in a cloud CI platform fundamentally undermines the security of the signing chain.

Secure boot enabled only in release builds: Development and test builds with secure boot disabled are sometimes shipped to evaluation customers or used in field trials. If those devices are never recalled and updated to a secure configuration, they remain in the estate as unprotected endpoints.

OTA update servers accessible from the open internet without mutual authentication: Server-side TLS alone is insufficient. Defence OTA update infrastructure should require client certificate authentication so that only authorised devices can initiate update connections.

No rollback protection in the initial prototype, deferred as a ‘v2 feature’: Once a firmware version has been deployed to a fielded system without rollback protection, adding it retrospectively requires a breaking update that all devices must accept. If any devices fail to receive that update, they remain permanently unprotected.

Update telemetry sent to commercial cloud services: Even where the firmware image itself is handled correctly, logging and telemetry infrastructure that routes data to commercial cloud platforms can create classification boundary issues that are difficult to resolve without significant re-architecture.

Final thoughts: The cost of deferring secure OTA investment

The argument for deferring secure OTA investment is almost always a short-term cost argument: it adds complexity, takes engineering time, and the system is ‘air-gapped anyway’. This reasoning consistently underestimates two factors.

The first is that air gaps in defence IoT are rarely as complete as assumed. Systems that cannot receive remote updates in the field still need update pathways for depot maintenance and mid-life upgrades. Those pathways carry risk if they are not designed with the same rigour as operational network connections.

The second is the cost profile of a discovered firmware vulnerability in a fielded system with no secure update capability. The options are either a physical recall of every device, a high-risk manual update procedure with poor auditability, or acceptance of a known vulnerability in an operational system. None of these is an acceptable outcome for a programme operating under UK defence security requirements.

Secure OTA, designed correctly from the start, is the mechanism that converts a potentially catastrophic vulnerability response into a manageable patch deployment. That is not a nice-to-have capability for a defence IoT system. It is a fundamental requirement.

If you are designing a defence IoT system and firmware lifecycle management is on your risk register, we can help you address it before it becomes a programme-level problem. Talk to Ignitec about secure defence IoT design.