What is firmware security, and why is it crucial for defence equipment?
Every piece of defence equipment, from a section radio to an uncrewed aerial vehicle, runs on software buried deep inside its hardware. This is firmware: the code that powers a device, tells it what it is, and controls its behaviour before a user ever sees a screen. In defence electronics, secure embedded firmware is what prevents that code from being tampered with, copied, or exploited as a weakness by an adversary. Because firmware is often developed once and rarely touched again, many companies focus on application and network security, thus overlooking firmware, which, once compromised, gives attackers deep-level access that’s hard to detect or remove.
If you have followed our earlier posts on choosing radios, LoRa networking, MAVLink integration and EMI and EMC compliance, this post moves from the hardware itself to the instructions running beneath it, and why getting that layer wrong can undo everything else.
What does secure embedded firmware protect?
Firmware sits below the operating system and often below any software the end user will ever interact with. It defines what a processor does the instant power reaches it, how peripherals are initialised, and which functions are permitted before the device has proven its own identity. Compromise it, and every layer built on top inherits that compromise, no matter how well the application software or network encryption has been designed.
Commercial IoT security has largely learned to treat firmware as an asset worth protecting. Defence electronics face a sharper version of the same problem, because the adversary is frequently a well-resourced, patient actor rather than an opportunistic criminal. State-level threat actors have the time, funding and motivation to reverse engineer a device, extract its firmware, and search for a single unguarded code path. A tactical radio, a UAV flight controller or a sensor node that ships with weak firmware protection is not just at risk of counterfeiting or IP theft. It can become a route into a wider network, a source of false telemetry, or a device that does something other than what the operator believes it is doing.
|
🛠️ DESIGN CONSIDERATION Securing firmware at rest, when it sits in flash memory or on a programming tool, is a different problem from securing it in execution, once it’s running on live silicon in the field. A complete design addresses both: encrypted or authenticated storage, and runtime protections such as memory isolation, execution-only regions and tamper response. |
Establishing a hardware root of trust
A secure embedded firmware defence security strategy needs a starting point that cannot itself be forged. This is the hardware root of trust: typically a public key, hash or unique identifier fused into silicon at manufacture, or held inside a discrete secure element, that nothing running on the device can alter. Every later security check ultimately traces back to this anchor. Without it, an attacker who can rewrite flash memory can simply rewrite the thing that is supposed to be checking the flash memory.
In practice, the security strategy is implemented through mechanisms such as a microcontroller’s internal secure enclave, an ARM TrustZone partition, or a dedicated secure element or trusted platform module wired onto the board. The choice depends on the platform’s power budget, cost target and the classification of what it needs to protect, and it is a decision best made early, since retrofitting a root of trust onto an existing board revision is rarely straightforward.
|
🛠️ DESIGN CONSIDERATION A hardware root of trust cannot be patched once a platform is deployed. Key length, hash algorithm and elliptic curve choices should assume a longer service life and a more capable future adversary than the threat model at the point of design, not simply what is considered adequate today. |
Secure Boot and the Chain of Trust
Secure Boot is a security standard that prevents unauthorised code from running on a device during its startup sequence, i.e., it is the process by which a device checks its own firmware before running it. The first stage, usually held in an immutable boot ROM, verifies the signature of the next stage before handing over control. That stage then verifies the one after it, and so on, until the full application firmware is running. Each link only trusts the one before it because that one has already been mathematically verified against the root of trust, not because it looks correct or comes from a familiar source.
Some designs extend this into a measured boot, where each stage records a cryptographic measurement of what it loaded, allowing a remote system to later confirm exactly which firmware version and configuration booted, rather than simply trusting that a signature check happened somewhere in the past.
|
⚠️ CRITICAL ALERT A chain of trust is only as strong as its weakest link. If one boot stage hands control to the next without independently verifying its signature, an attacker who compromises that single stage bypasses every protection built into the stages around it. Partial secure boot implementations, where only the first or last stage is checked, are a common and serious finding in defence firmware audits. |
Firmware signing, key management and anti-rollback protection: The foundational triad for device security
Firmware signing is the mechanism that lets a device tell genuine code from acounterfeit or malicious code, and guarantees the authenticity and integrity of an update. However, the signing framework is only as secure as the private keys used to generate the signatures; therefore, a private key, held by the manufacturer or an authorised integrator, needs to sign each firmware image. The device holds the matching public key and refuses to run anything that was not signed correctly. The security of the entire system now rests on how well that private key is protected, which makes key management as important as the cryptography itself.
This typically means keeping signing keys inside a hardware security module rather than on a laptop or build server, defining who is authorised to trigger a signing operation, and having a documented plan for what happens if a key is suspected of compromise, including revocation and re-keying of fielded devices. Firmware images also need anti-rollback protection, usually a monotonic counter, so that a device cannot be tricked into reinstalling an old, legitimately signed firmware version that contains a since-patched vulnerability.
|
🛠️ DESIGN CONSIDERATION Plan key rotation and revocation before the first unit ships, not after. Programme managers should ask suppliers directly how a compromised signing key would be handled across an already fielded fleet, and expect a concrete answer rather than a reassurance. |
Supply chain integrity: Where firmware security breaks down
In defence electronics, supply chain integrity ensures the authenticity, security, and reliability of components from sourcing through to deployment.
A well-designed secure boot chain and disciplined key management can still be undone by what goes into the firmware image in the first place. Modern embedded firmware is rarely written entirely in-house. It typically includes a real-time operating system, communications stacks, cryptographic libraries and vendor-supplied binary blobs for radios, sensors or power management chips, some of which arrive with little visibility into how they were built or by whom.
A software bill of materials for firmware (i.e., listing every component, its version and its provenance) is becoming as important in defence procurement as a hardware bill of materials already is. It allows a known vulnerability in a third-party library to be traced quickly to every affected fielded platform, rather than triggering a manual audit of every codebase the organisation has ever shipped to.
|
⚠️ CRITICAL ALERT Unverified third party binary blobs, particularly closed-source radio or sensor drivers supplied without source code, are one of the most common routes for firmware compromise in defence electronics. Where a supplier cannot provide provenance or a security review for a binary component, that component should be treated as a residual risk to be documented and mitigated, not quietly accepted. |
Def Stan 05-139 and the UK’s Secure by Design requirements
UK defence procurement now expects firmware security to be demonstrated, not assumed. Def Stan 05-138 sets out the organisational cyber controls a supplier’s own business must meet, assessed against a Cyber Risk Profile of Level 0 to Level 3 under the MOD’s Cyber Security Model. Def Stan 05-139 sits alongside it and is more directly relevant to firmware itself, since it defines the cybersecurity and resilience requirements for the products, systems and services the MOD actually procures, rather than the supplier’s corporate environment.
Both standards sit under the MOD’s Secure by Design approach, introduced through Industry Security Notice 2023/09, which requires cybersecurity to be planned and evidenced from the earliest stage of a programme’s CADMID or CADMIT lifecycle, rather than tested for once and then left alone. For a firmware development programme, this means secure boot design, key management arrangements and supply chain evidence need to exist as documented artefacts an assessor can review, not just as engineering practices the team happens to follow.
|
⚠️ CRITICAL ALERT Bids that cannot evidence a documented firmware assurance process against Secure by Design expectations, or the relevant Cyber Risk Profile level under Def Stan 05-138 and 05-139, risk being marked down or excluded before technical evaluation even begins. This is now a procurement gate as much as an engineering one. |
Secure firmware and OTA updates: A dual attack surface
Firmware security and update security are two sides of the same problem, which we covered in detail in our earlier post on secure OTA for defence IoT. That post focused on protecting the update in transit and authenticating the update server. This post’s concern is what happens once a firmware image lands on the device itself: it must be verified against the same signing key and anti-rollback counter used at initial manufacture before it is ever flashed, and the device needs a safe fallback if that verification fails, rather than a bricked unit in the field.
Fielded defence platforms are frequently updated over constrained, intermittent links, whether that is a tactical radio network of the kind discussed in our post on choosing radios for defence deployments, or a long-range, low-bandwidth LoRa link. Staged rollout to a small number of units first, sometimes called a canary deployment, and the ability to hold a previously known good firmware image as a fallback, both reduce the operational risk of an update that turns out to be flawed, whether that flaw is a bug or a compromise.
|
🛠️ DESIGN CONSIDERATION Treat the firmware signing chain and the OTA delivery mechanism as one combined attack surface during design review, not two separate work packages reviewed by different teams. A secure update channel delivering an unsigned image, or a rigorous signing process feeding an unauthenticated update server, both fail in the same way. |
Secure embedded firmware defence mechanisms within real-world power and EMC constraints
Cryptographic operations are not free. Signature verification, hashing and secure boot checks all consume processor cycles and power, which has a significant impact on the tactical sensor platforms covered in our earlier post on tactical sensor power design, where every microamp is already accounted for. Firmware security decisions cannot be made in isolation from the power budget, and a design that adds a secure boot chain late in development, after the power architecture is fixed, often forces an uncomfortable compromise between security and battery life.
The same interdependency applies to the electromagnetic environment discussed in our EMI and EMC in defence electronics post. Voltage and clock glitching, where an attacker deliberately induces a fault to skip a security check, exploits the same physical sensitivity that EMC hardening is designed to manage. A platform with strong EMC design and brownout or clock monitoring built in is inherently more resistant to these fault injection attacks, which makes early coordination between the firmware security engineer and the hardware team designing power and EMC protection a genuine efficiency, not just good practice.
Final Thoughts: Choosing a Firmware Development Partner for UK Defence Programmes
Firmware security is rarely the weak point because a team does not understand cryptography. It is more often the weak point because it was designed in isolation from the radio selection, the protocol stack, the power architecture and the update mechanism around it, each handled by a different specialist or a different supplier. A UAV platform using MAVLink, discussed in our post on MAVLink integration in defence UAVs, needs its command and telemetry security considered alongside its firmware signing chain, not after it.
For engineering teams, ensuring secure embedded firmware defense is an argument for a development partner who can reason about the full stack, from RF and power through to firmware and update infrastructure, rather than treating security as a checklist applied at the end. For programme managers and procurement decision makers, the same point translates into fewer integration surprises, a single point of accountability for security evidence, and a stronger position when demonstrating Secure by Design compliance to the MOD.
|
Work with Ignitec for end-to-end defence electronics services We design secure embedded firmware for UK defence programmes as part of a full stack engineering capability, spanning RF and radio integration, protocol design, tactical power architecture, EMC hardened hardware and firmware security together, rather than as separate, disconnected disciplines. |
If your programme needs a hardware root of trust, a secure boot chain, disciplined key management or Secure by Design evidence for Def Stan 05-138 and 05-139, our engineering team can help from concept through to fielded deployment. Contact us to discuss your defence firmware requirements.
