Organisations should use an over-the-air platform that can choose the right transport for the device rather than assuming SMS will work everywhere. Some devices can update over data connectivity, while others need identification through device-specific identifiers and delayed delivery when they reconnect. The key is to design for heterogeneous connectivity, offline periods, and lifecycle control, not one update path for every device.
When update transport must adapt to device connectivity
IoT fleets should be updated through an over-the-air platform that can route each update by the transport the device can actually use at the moment, not by a fixed assumption that SMS is always available. That means the update system needs to understand device state, reachable networks, and the device’s current transport options, then choose the viable path automatically.
For devices that have data connectivity, the update flow can be direct and immediate. For devices that are intermittently offline, the platform needs to queue the update and deliver it when the device reconnects. The practical goal is to keep update intent separate from delivery method so fleet operations do not break when the network path changes.
In practice, this is less about a single command channel and more about a delivery orchestration problem. A good system treats transport as a per-device decision, not a fleet-wide constant. That is what makes the approach resilient across constrained networks, roaming devices, and environments where message delivery is delayed or unreliable.
Why device-specific identity matters more than a single SMS path
When SMS cannot be trusted as the update trigger, the update workflow must identify the device in a way that remains stable across reconnects and transport changes. Device-specific identifiers let the platform match a queued update to the correct endpoint, even if the device was offline when the command was issued.
This is important because update mechanisms fail when identity, transport, and state are coupled too tightly. If the only delivery assumption is an SMS command, any SMS outage, number change, roaming issue, or message delay becomes an update failure. A device-specific delivery model reduces that fragility by letting the platform recover the target later instead of losing the instruction altogether.
The update logic should also preserve lifecycle control. The platform needs to know whether the device is eligible for the update, whether it has already received it, and whether the update should be retried or superseded. That keeps the system from duplicating commands or applying updates to the wrong device instance after reconnect.
Designing for offline periods, retries, and controlled rollout
IoT update orchestration works best when it assumes intermittent connectivity from the start. Devices may disconnect for long periods, return briefly, and disappear again. The update platform should therefore support deferred delivery, retry logic, and acknowledgement tracking so operators can tell whether an update was merely queued, actually delivered, or successfully applied.
This design also supports safer rollout decisions. If some devices are only reachable through data connectivity while others need delayed delivery, the operator can segment update waves by reachability and confidence. That prevents a single weak transport path from becoming the bottleneck for the entire fleet.
Transport selection should be governed by policy rather than manual operator guesswork. A platform that can choose among available channels, then fall back to a later delivery attempt when no reliable path exists, will usually outperform any scheme that hard-codes a preferred channel like SMS. For device trust and onboarding context, the Device and IoT Identity Guide is a useful companion because it frames device identifiers, certificates, and lifecycle trust as part of the same operational model.
Risk and Threat Considerations
SMS-based update commands create a brittle control point because delivery depends on a network path that may fail, delay, or be unavailable at exactly the wrong time. When update instructions cannot reliably reach the device, organisations face missed patches, inconsistent fleet state, and a wider window in which vulnerable devices remain exposed.
Failure mechanism: The platform assumes SMS delivery is sufficient, but the device is offline, roaming, unreachable, or no longer bound to that channel, so the update instruction never arrives or arrives too late.
Impact: Devices drift out of compliance, remediation is delayed, and attackers gain more time to exploit unpatched firmware or configuration flaws across the fleet.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Update delivery depends on stable device credentials and lifecycle control. |
| IA-9 — Service Identification and Authentication | IoT update systems often authenticate devices or services over variable transports. | |
| Recommendation — Manage device credentials so queued updates can be authenticated and retired safely. Authenticate devices and update services with mutual trust, not SMS alone. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Reliable over-the-air updates normally need protected delivery and integrity checks. |
| Recommendation — Protect update integrity with cryptographic verification before installation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Fleet update eligibility depends on controlling device accounts and lifecycle state. |
| Recommendation — Inventory and govern device accounts so update authority stays current. | ||
Practitioner Guidance
What to prioritise: Treat transport selection as an update-engine function, not an operator workaround. Your first check should be whether the platform can queue updates by device identifier and release them on reconnect without losing state.
What to verify: Confirm that the platform can prove delivery outcome for each device, including queued, delivered, and applied states. If you cannot distinguish those states, you do not have reliable fleet update control.
Common mistake: Using SMS as the primary update assumption because it is convenient for some devices. That shortcut often breaks at scale, especially when connectivity is uneven or devices move between networks.
Practitioner takeaway: The right design is not “how do we force every device to accept the same command path?” It is “how do we maintain update intent, device identity, and delivery certainty across heterogeneous connectivity?”
Related resources from NHI Mgmt Group
- How should organisations respond when IoT devices are built with weak default security and cannot be reliably distinguished from better secured devices?
- What happens when organisations keep using messaging features on devices that cannot receive a security update?
- How should organisations secure IoT communications when devices exchange sensitive data and control commands across home or enterprise networks?
- What happens when organisations cannot detect or identify all of their IoT devices?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
