A secure update design verifies the authenticity and integrity of every update, is simple for the user or automatic, checks for updates after setup and periodically, recovers if an update fails, and comes with a published support period. ETSI EN 303 645 section 5.3 sets these out for consumer IoT.
Authenticity and integrity
Provision 5.3-10 says that where updates arrive over a network, the device shall verify the authenticity and integrity of each update via a trust relationship. The notes list valid relationships: authenticated channels, a network that requires a critical security parameter to join, digital signature verification of the update, or confirmation by the user. The reason given is that an unauthorized party must not be able to install malicious code.
Provision 5.3-9 adds that the device should verify updates, and for constrained devices that cannot do the cryptography, a trusted device such as a hub may verify first.
Provision 5.4-4 goes further: security parameters used for update integrity checks must be unique per device and produced to reduce automated attacks across a class of devices.
Make it easy to apply
Provision 5.3-3 says an update shall be simple for the user to apply, and the commentary warns that a hard update means users defer it. Provision 5.3-4 says automatic mechanisms should be used. Provision 5.3-6 says that if the device supports automatic updates or notifications, they should be enabled in the initialized state.
Check for updates and handle failure
Provision 5.3-5 says the device should check after initialization and then periodically. An example given is a daily check at a randomized time.
The commentary on automatic updates warns that a failed update can leave a device unusable. It points to watchdogs and dual bank flash or recovery partitions that return the device to a known good version or the factory state.
Provision 5.3-11 says the manufacturer should tell the user, in a recognizable and apparent way, that a security update is required and what risks it mitigates. Provision 5.3-12 says the device should notify the user when an update will disrupt basic functioning.
Tell the user, be timely, be transparent
Provision 5.3-8 says security updates shall be timely, with critical fixes handled with appropriate priority. Provision 5.3-13 says the manufacturer shall publish the defined support period clearly. For constrained devices that cannot be updated, provisions 5.3-14 and 5.3-15 call for publishing the rationale and replacement plan, and for the product to be isolable and the hardware replaceable.
A review sheet
Score each row yes, no or not applicable, and keep evidence.
- Are updates signed, and is the signature checked on the device or a trusted hub?
- Are verification keys unique per device?
- Does the device check for updates after setup and on a schedule?
- Can a failed update be rolled back?
- Is the support period published?
- Do you know which third party components each release contains?
The last question matters because timeliness depends on finding affected components. Safeguard provides SBOM and dependency scanning, and a free scan is at gold.safeguard.sh/scan.
Quick check
Do all devices need automatic updates?
The standard says automatic mechanisms should be used, which is a recommendation. Whether it applies depends on the device and how you use the conditions in the standard.
Sources
Last reviewed: 19 October 2026.
