Secure OTA updates for connected devices: the identity problem

At a glance

What this is: This is a practitioner-oriented explanation of over-the-air updates and the security controls needed to deliver them safely to connected devices.

Why it matters: It matters because OTA update pipelines are now part of identity governance for devices, certificates, and provisioning flows across IoT, machine identity, and lifecycle management.

By the numbers:

• Business Intelligence predicts there will be more than 30 billion connected devices by 2020.
• Nearly 160 million vehicles around the world will have the capability to upgrade their systems with OTA updates by 2022.

👉 Read DigiCert's article on securing over-the-air updates for connected devices

Context

Over-the-air updates are wireless software or provisioning deliveries sent to connected devices so they can stay functional, current, and secure. In identity terms, the update path itself becomes part of the trust boundary, because the device must verify the sender, the payload, and the channel before accepting change.

The governance problem is not just patch delivery. It is proving that each device is the intended recipient, that the update has not been altered in transit, and that certificates or other device identities are managed through the full lifecycle. That makes OTA a machine identity and certificate hygiene issue, not only an engineering convenience.

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: Why do over-the-air updates create identity risk for IoT fleets?

A: OTA creates identity risk because the device must decide whether an incoming update is legitimate. If certificates, authentication, or signing are weak, the update path can be abused to push malicious code, disrupt operations, or expose sensitive data across the fleet.

Q: What breaks when certificate lifecycle management is missing for connected devices?

A: When certificate lifecycle management is missing, devices can continue trusting expired, stale, or compromised identities. That creates a durable trust problem in which outdated credentials may still approve updates long after the device should have been re-enrolled or revoked.

Q: Who is accountable when a malicious OTA update reaches production devices?

A: Accountability usually sits across product security, device engineering, and identity governance. Organisations should define who owns signing keys, who approves certificate issuance, who monitors revocation, and who can stop deployment when update trust is uncertain.

Technical breakdown

How OTA update trust is established

OTA systems depend on three linked checks: device identity, message integrity, and delivery channel security. The device needs a way to authenticate the update source, verify that the payload has not been modified, and ensure the update is intended for that specific endpoint. Digital certificates often provide that trust layer by signing updates and binding them to a device or user identity. Without those checks, a wireless update mechanism becomes a distribution path for tampered software rather than a controlled maintenance channel.

Practical implication: enforce signed updates and certificate-based recipient verification before any device accepts a payload.

Why insecure OTA channels create identity risk

OTA updates travel over wireless paths that can be intercepted, replayed, or abused if the security model is weak. The risk is not limited to software corruption. Malicious updates can introduce malware, disrupt availability, or expose personal or operational data. In connected fleets, the update channel is effectively an identity assertion mechanism, so any weakness in authentication or encryption undermines the entire device trust model. This is why insecure OTA is best understood as an identity and integrity failure, not only a transport problem.

Practical implication: treat the update channel as a protected identity path and require encryption plus authenticity checks end to end.

Certificate lifecycle management for connected devices

Connected devices need more than initial enrollment. Their certificates and provisioning information must be created, stored, rotated, and revoked across the device lifecycle. If that lifecycle is weak, devices can continue trusting obsolete identities or accept updates from stale infrastructure. The article’s core point is that manufacturing-time security matters, but post-deployment controls matter too. For IoT programmes, OTA security depends on whether the organisation can continuously govern device credentials at scale.

Practical implication: build certificate lifecycle controls into IoT operations, including provisioning, renewal, and revocation.

NHI Mgmt Group analysis

OTA update security is a machine identity problem before it is a patching problem. The update channel carries trust decisions, because each device must decide whether a sender, payload, and certificate chain are legitimate. When that decision layer is weak, the organisation is not just slow on updates. It has no reliable way to tell a valid maintenance action from an attacker-controlled one. Practitioners should therefore treat OTA as part of the identity plane for connected devices.

Certificate-backed recipient verification: is the named control gap this article exposes. The article shows that devices need certificates to authenticate the intended recipient and to confirm the source of the update. That requirement is easy to state and hard to operationalise at fleet scale, especially when devices are deployed for years. The implication is that device identity must be governed as a lifecycle, not as a one-time enrollment event.

Secure OTA is now a baseline expectation for any connected fleet. As device counts rise, the risk is not only more endpoints but more update paths, more certificate states, and more opportunities for drift. That makes OTA security a cross-functional identity governance issue spanning engineering, IAM, and operations. Practitioners should align device trust with certificate management and authenticated delivery controls.

Manufacturing-time security assumptions do not survive deployment without ongoing governance. The article makes clear that security should be built in at manufacturing, but it also acknowledges that controls are still needed after devices leave the line. That means the real control boundary is the full lifecycle of the device identity. Practitioners should verify that post-deployment certificate governance is as deliberate as initial provisioning.

Connected-device update integrity should be measured as a trust outcome, not a patching metric. A fleet can have high update volume and still be unsafe if unsigned, unauthenticated, or misrouted updates are possible. The governance question is whether every device can prove the source and integrity of what it installs. Practitioners should assess OTA programmes by trust enforcement, not only by deployment speed.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For a broader view of the underlying market pressure, see Ultimate Guide to NHIs , The NHI Market for how identity governance is expanding across machine and device ecosystems.

What this signals

Certificate-backed device trust is becoming a baseline requirement for connected fleets. As OTA expands across consumer devices, industrial systems, and vehicles, the governance burden shifts from isolated patch events to continuous proof of sender authenticity and recipient identity. Teams that still treat firmware delivery as an engineering-only process will miss the identity controls that now determine whether an update can be trusted.

1.5 out of 10 organisations are highly confident in securing NHIs, according to our research, and that confidence gap matters directly for OTA programmes. Devices depend on credentials, certificates, and provisioning states that can drift long after deployment. The practical signal is simple: if your team cannot inventory, rotate, and revoke device identities cleanly, OTA integrity will remain fragile.

Update governance is moving toward lifecycle control, not one-time deployment assurance. The next step for many programmes is to connect certificate management, device enrolment, and revocation into a single operational view. That is where OTA security becomes measurable, because the organisation can see whether trust still exists at the moment an update is accepted.

For practitioners

• Require signed updates for every device fleet Block OTA acceptance unless the payload is signed by an approved authority and the signature chain is validated on-device before installation.
• Bind update acceptance to device identity Use certificates or equivalent identity credentials so each device can verify that an update is meant for its specific class, model, or enrolment state.
• Separate transport security from update trust Encrypt the delivery path, but also validate authenticity and integrity at the application layer so a secure tunnel alone cannot approve a malicious payload.
• Operate certificate lifecycle controls continuously Track issuance, rotation, renewal, and revocation for device certificates so retired or compromised identities cannot keep receiving updates.

Key takeaways

• OTA updates are an identity and integrity problem because devices must verify both who sent the update and who should receive it.
• Wireless delivery alone does not make updates safe, since malware, downtime, and tampering remain possible without certificate-backed trust controls.
• Connected-device programmes need continuous certificate lifecycle governance if they want OTA to stay secure after devices leave the factory.

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 set of credentials or certificate material that lets a connected device prove who it is to a system or to an update source. For OTA security, device identity determines whether a device can authenticate update traffic and whether its trust state is still valid.
• Certificate Lifecycle Management: Certificate lifecycle management is the controlled issuance, renewal, rotation, and revocation of digital certificates across their usable life. For connected devices, it ensures that update trust does not outlive the device state, and that stale credentials cannot keep approving change.
• Signed Update: A signed update is a software or firmware package protected with a digital signature so the recipient can verify origin and integrity before installation. In connected-device environments, signed updates are a core safeguard against tampering, replay, and malicious payload injection.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by DigiCert: What are over-the-air updates? Read the original.