ETSI EN 303 645 provision 5.7-2 says that if an unauthorised change to software is detected, the device should alert the user or administrator and should not connect to wider networks than those needed to perform the alerting. The standard also points to a local known good version for recovery.
The three decisions
A check that can fail needs a defined failure. There are three choices to make before you ship.
- Boot or not. Does the device refuse to run the failed image, fall back, or run in a limited mode?
- Who is told. The user, an administrator, a management service, or all of them?
- How does it recover. From a stored image, from a download, or only with service?
Limit the network
The ETSI wording is careful. The device should not connect to wider networks than necessary for alerting. A compromised image with full network access can attack other systems, join a botnet or exfiltrate data. A device that is restricted to a notification path can still report the problem.
Recovery without a recall
The standard says the ability to recover remotely from unauthorised changes can rely on a known good state, such as a locally stored known good version. This avoids denial of service and costly recalls or maintenance visits, while managing the risk of an attacker taking over the device by subverting the update path.
That tension is the design problem. The recovery path is also an attack surface. It needs the same signature checks and rollback protection as normal updates.
Handling bad updates
Provision 5.3-9 covers failed updates. It says a device should act on an invalid, potentially malicious update, and that beyond rejecting it, the device can report the incident or inform the user. Its example suggests the device should not leak information about the failure to whoever initiated the update, though it can log the event and deliver a notification to a trusted peer over a secure channel.
What good looks like
- A clear indicator on the device or in the app when verification fails.
- A support article that tells people what the alert means and what to do.
- A logged event that reaches the fleet management side, with enough detail to investigate.
- A tested recovery path, run at least once per release in your lab.
- No silent fall through to unsigned code.
Test the failure
Flip a bit in a signed image on a test unit and watch what the device does. If the answer is surprising, you found the real behaviour before a customer did.
Quick check
Should the device keep using the network after detecting tampering?
ETSI says it should not connect to wider networks than those necessary to alert the user or administrator.
Can a device recover without a service visit?
ETSI says recovery can rely on a known good state such as a locally stored good version, which can avoid costly visits.
Where Safeguard fits
Safeguard covers the software supply chain side of this work: SBOM and dependency scanning, policies and gates, and compliance and evidence automation. It does not replace hardware security features. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
