How should security teams secure over-the-air updates for connected devices?

Why This Matters for Security Teams

OTA updates are one of the highest-leverage control points in connected-device security because they can repair known flaws quickly or become the fastest path to fleet-wide compromise if trust is weak. Transport encryption alone is not enough. The device must verify who signed the update, whether the payload has been tampered with, and whether the update is meant for that exact hardware and firmware lineage.

This is why guidance from the EU Cyber Resilience Act matters: secure update handling is a product-security obligation, not an optional hardening step. For teams managing connected devices at scale, the OTA channel must be treated like a privileged software supply chain, with provenance, integrity, and rollback safety all enforced before install. NHIMG research on the DeepSeek breach reinforces the broader pattern: once trust material is exposed or update paths are abused, attackers can move quickly across a large surface area.

In practice, many security teams discover OTA weaknesses only after a signed package is accepted by the wrong device, rather than through intentional validation of the update trust model.

How It Works in Practice

A defensible OTA program layers several checks. First, the update package should be signed by a trusted release key, and the device should verify the signature locally before any installation begins. Second, delivery should use encrypted transport, but that transport should be considered a baseline rather than the trust decision. Third, devices should verify the sender or update service using certificates or equivalent workload identity so that the channel can be authenticated end to end.

Good implementation also includes device-class targeting, version pinning, and anti-rollback controls. A bootloader or update agent should reject images that are older than the currently installed trusted version unless a narrowly controlled recovery path exists. Integrity checks should cover both the image and the metadata, including model, region, and hardware revision, because a valid package for one device class can still be dangerous on another.

• Use signed manifests and signed payloads, not transport encryption alone.
• Bind updates to device model, hardware family, and expected firmware branch.
• Require certificate-based verification of the update source or signing service.
• Log every attempted install, reject, and rollback event for fleet monitoring.
• Test failed update recovery, because secure failure is part of secure delivery.

Where teams need implementation patterns, the OTA supply chain should be mapped to firmware signing, secure boot, and update authority separation, with guidance from the State of Non-Human Identity Security showing why credential governance and visibility matter even outside classic IT systems. Standards work from the EU Cyber Resilience Act and device lifecycle controls should be aligned early, not retrofitted after deployment.

These controls tend to break down when low-cost devices lack secure storage for keys and the vendor cannot support per-device trust anchors because the fleet was designed without hardware root-of-trust assumptions.

Common Variations and Edge Cases

Tighter update assurance often increases operational overhead, requiring organisations to balance fleet-wide safety against release speed and device cost. That tradeoff is especially real for battery-powered, intermittently connected, or field-serviced devices where update windows are short and recovery options are limited.

Current guidance suggests using different trust models by device class. High-risk devices should use hardware-backed key storage, per-device certificates, and staged rollout with canary validation. Lower-risk devices may rely on shared signing trust, but only if revocation and rollback controls are strong enough to contain a compromised release key. There is no universal standard for this yet, so security teams should document the rationale for each trust tier.

Edge cases include offline updates delivered through service technicians, regional firmware variants, and emergency patches that bypass normal rollout schedules. Those scenarios need strict chain-of-custody controls and a short-lived exception process. For organisations already aligning product security to sector obligations, the EU Cyber Resilience Act is a useful reference point for baseline expectations, but the operational design still has to fit the device’s memory, power, and connectivity constraints.

In the hardest environments, OTA security fails not because the signature check is missing, but because recovery, rollback, and trust revocation were never engineered for disconnected devices.

Related resources from NHI Mgmt Group

• When should security teams prioritise cipher suite updates over other TLS work?
• How should teams secure non-human identities across cloud and SaaS?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams combine SAST and DAST in a secure development programme?