Secure OTA updates for connected devices: the identity problem

At a glance

What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Over-the-air update security for connected devices depends on identity, authentication, encryption, and signed delivery paths.

Why it matters: For IAM and device-security teams, it shows that OTA is not just a transport problem, because update trust, recipient verification, and tamper resistance all shape device governance.

Context

Over-the-air updates are wireless software or provisioning updates sent to connected devices after deployment. The governance problem is that the same convenience that makes OTA useful also creates a trust boundary: the device must know who sent the update, what it is allowed to accept, and whether the payload has been altered.

DigiCert's article frames this as an identity problem for connected devices, not only a connectivity problem. That matters because update integrity fails when manufacturers treat delivery as the main control and identity as an afterthought, especially as more device classes depend on remote patching and feature delivery.

Key questions

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

A: Security teams should require signed updates, encrypted delivery, and certificate-based recipient verification for every device class. OTA security fails when transport protection is treated as enough, because the device also has to confirm that the sender is trusted and the payload is intact before installation.

Q: What breaks when connected devices cannot verify update identity?

A: The device loses its ability to distinguish legitimate maintenance from tampered content. That failure can expose fleets to malware, downtime, safety disruption, and unauthorised changes because the receiver has no reliable basis to accept or reject the update.

Q: When should teams build OTA security into device design?

A: Before deployment, not after. OTA trust depends on identity provisioning, certificate lifecycle decisions, and secure delivery paths that are much harder to retrofit once devices are in the field and already dependent on remote updates.

Q: How do organisations know an OTA update path is trustworthy?

A: Look for three signals: the device validates the sender, the payload is signed, and the transfer is encrypted. If any of those are missing, the update path is relying on transport convenience rather than provable trust.

Technical breakdown

How OTA update identity is established

Secure OTA depends on the device being able to verify the sender, the payload, and the intended recipient before installation begins. Digital certificates are used to bind identity to the device and to the update channel, while authentication confirms that the update request came from a trusted source. In practice, this creates a chain of trust from manufacturer to device, with encryption protecting update traffic in transit and signatures protecting the update contents from tampering. Without that chain, the device is simply accepting remote code over a network path it cannot independently trust.

Practical implication: establish device identity and signed update verification as baseline OTA requirements before rollout.

Why unsigned or unauthenticated updates create exposure

An OTA channel becomes risky when the receiver cannot distinguish legitimate maintenance traffic from malicious content. If the update path is not authenticated and encrypted, attackers can exploit it to deliver malware, cause downtime, or push tampered payloads that alter device behaviour. For connected systems that affect home automation, industrial operations, or vehicles, the security issue is not only data theft but also operational and physical impact. The underlying failure is the same: the device accepts an update without enough assurance about source, integrity, and recipient eligibility.

Practical implication: treat unauthenticated update paths as a direct exposure to tampering, disruption, and unsafe device behaviour.

Why manufacturing-time trust decisions matter

The article stresses that security should be built in at manufacturing time rather than added late. That is because OTA security depends on device provisioning, certificate assignment, update infrastructure, and management processes working together from day one. If the trust model is bolted on after deployment, the fleet may already contain devices that cannot validate updates consistently, cannot be revoked cleanly, or cannot be managed at scale. OTA governance is therefore a lifecycle issue, not a patching issue alone: the trust model must exist before the first update is delivered.

Practical implication: include OTA identity, certificate issuance, and update governance in device design and manufacturing requirements.

Threat narrative

Attacker objective: The attacker aims to inject tampered content into the update path so a connected device installs malicious or unsafe code.

1. Entry occurs through the wireless update channel when a device accepts update traffic from an untrusted or poorly protected source.
2. Credential or trust abuse follows when the receiver cannot reliably authenticate the sender or validate the signed payload.
3. Impact can include malware installation, downtime, safety disruption, or exposure of information on connected devices.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
• Verkada camera breach 2021: Admin credentials on Verkada's exposed Jenkins support server let hackers into a support interface and customer cameras at 97 customers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OTA trust is a non-human identity problem before it is an update problem. Connected devices need a verifiable identity so the receiver can distinguish legitimate provisioning and software delivery from hostile traffic. That identity layer is what turns remote maintenance into governed access rather than blind acceptance. Practitioners should treat the update channel as an NHI control plane, not a convenience feature.

Signed delivery paths matter because device recipients cannot use human judgment to filter risk. A device either validates the source and accepts the package or it does not. That makes certificate-based trust, encryption, and source authentication central controls for fleet governance. For connected-device programmes, the real question is whether the receiver can prove the sender and the payload before any execution happens.

Manufacturing-time identity design is the difference between governable fleets and retrofit debt. Once devices are deployed, update trust becomes harder to correct because every fielded unit inherits the original provisioning model. If certificates, identity binding, and management paths were not designed in, the fleet carries permanent governance drag. The implication is that OTA trust should be treated as part of product architecture, not operational cleanup.

Secure OTA exposes an identity blast radius that most device programmes undercount. A single weak update path can affect many devices at once, which means the blast radius is not limited to one endpoint or one user. Update governance must therefore consider recipient verification, transport security, and tamper resistance together. Practitioners should assess OTA as fleet-wide identity assurance, not isolated patch delivery.

Device identity for OTA is an NHI lifecycle issue, not a one-time certificate event. Certificates authenticate a device or user today, but the governance challenge is maintaining that trust across issuance, use, replacement, and revocation. That lifecycle view is what separates a secure fleet from a brittle one. Practitioners should align OTA controls with certificate and device identity governance across the full deployment lifespan.

What this signals

Device identity for OTA must be governed as part of the product lifecycle, not as a post-deployment patch. When manufacturers delay trust design until after release, every device inherits the original gap and the fleet becomes harder to govern over time. That is why certificate issuance, revocation, and provisioning need to be planned as operational controls, not one-off setup tasks.

OTA channels widen the identity blast radius of a single control failure. One weak update path can affect many deployed devices at once, so the control objective is to reduce the number of places where trust can fail. Practitioners should assess whether the update path proves source, recipient, and integrity at every step.

For practitioners

• Define device identity before shipment Assign certificate-backed identity and update trust rules during manufacturing so each device can verify authorised update sources from first boot.
• Require signed payload validation Make signature checking mandatory at the device before installation, and reject any update that cannot prove origin and integrity.
• Encrypt update traffic end to end Protect OTA delivery in transit so attackers cannot alter, observe, or inject update content on the network path.
• Build revocation into fleet governance Maintain a process for replacing or revoking device certificates when a device, key, or update trust relationship is no longer valid.
• Test update paths across the full device lifecycle Validate provisioning, rollout, recovery, and failure handling on the same update path so security does not collapse after deployment.

Key takeaways

• OTA security fails when connected devices cannot verify who sent an update and whether the package was altered in transit.
• The article ties poor update governance to malware, downtime, safety issues, and exposure of information on connected devices.
• The control priority is manufacturing-time device identity, signed delivery, and encrypted transport across the full device lifecycle.

Key terms

• Over-the-Air Update: An over-the-air update is a wireless delivery of software, firmware, or provisioning data to a connected device. In security terms, it is also a trust decision, because the device must verify the sender, the payload integrity, and the intended recipient before accepting change.
• Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
• Signed Payload: An update package that includes a cryptographic signature proving where it came from and whether it changed in transit. For connected devices, signature verification is a core integrity control because the device cannot rely on human review to catch malicious or tampered update content.
• Update Trust: Update trust is the assurance that a firmware or software update is authentic, intended for the right device, and safe to apply. It depends on signing, validation, and inventory linkage so patching does not become a blind spot in the device lifecycle.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.