We increasingly rely on internet connected devices in our day-to-day lives, with consumer devices that include door bell cameras, thermostats, children’s toys and home assistants. However the cyber security of these devices doesn’t always live up to the trust we place in them to reliability perform their function and protect our personal data. It’s often too easy for attackers to abuse our devices to spy on us, deny us of service, mine cryptocurrency and launch distributed denial of service attacks. To remedy this, in 2020 ETSI released the first international standard for consumer IoT devices, known as ETSI EN 303 645 with the aim to “prevent large-scale, prevalent attacks against smart devices that cybersecurity experts see every day, by establishing a security baseline for connected consumer products and provides a basis for future IoT certification schemes“. In this blog post we’ll take a closer look at the standard and the requirements it places on IoT device manufacturers.
Passwords
The most straight forward form of cyber attack is by making entry ‘through the front door’, an attack which is very trivial when manufacturers ship devices with published default usernames and passwords. Attackers can easily determine the credentials and can be confident that most consumers wont have bothered to change them. It’s no surprise then that this standard mandates some common sense provisions in this area. The standard requires that where passwords are used they are unique to each individual device or are defined by the user (Provision 5.1-1). It also requires that those passwords are not easy to guess for example they are not deduced by the mac address, serial number or similar (Provision 5.1-2).
The standard also requires that users can change the authentication value used (e.g. re-register their fingerprint, or change their pin) (Provision 5.1-4) and that where possible some protection from brute-force attacks is provided (e.g. an automatic lock out or delay after failed authentication attempts) (Provision 5.1-5).
Vulnerability Management
When security researches discover new security vulnerabilities they typical follow a coordinated vulnerability disclosure (CVD) process – this allows them to publicly disclose and write about their work, but only after reporting it to the manufacturer and giving them some time to mitigate and deploy a fix. However, for this approach to work manufacturers must publish a disclosure policy and provide contact details – this is a mandatory requirement of the standard (Provision 5.2-1).
As vulnerabilities are being discovered all the time, it becomes necessary for manufacturers to monitor for vulnerabilities that may exist in their devices. The standard recommends (Provision 5.2-3) that manufacturers monitor as well as rectify security vulnerabilities within their products. Given that most products are constructed from hundreds of third-party or open-source packages it can be challenging to identify known vulnerabilities. Fortunately, open source tooling such as cve-check in Yocto or commercial services such as our own Galapagos service can be used to obtain a Software Bill of Materials (SBOM), identify known vulnerabilities and provide patches.
Naturally, with security vulnerabilities, time is of the essence and so the standard recommends that any disclosed vulnerabilities are resolved in a timely manner (Provision 5.2-2). And requires that any security updates are timely (Provision 5.3-8).
Software Updates
In order for manufacturers to patch security vulnerabilities there must be a means to update the software on their devices – the standard recommends that all device software should be securely updateable (Provision 5.3-1, 5.3-2). It also recommends that software updates are verified for authenticity and integrity (Provision 5.3-9) – and for the case where software updates are made over the network then this becomes mandatory (Provision 5.3-10). It also states that manufacturers keep their products up to date for a defined product support period (Provision 5.3-13).
The standard does recognise that isn’t always possible or practical to update device software and where this is the case then they recommend that manufacturers ensure that the product is replaceable instead (Provision 5.3-15) and thus should provide a period of hardware replacement support (Provision 5.3-14).
The standard requires that updates are simple to apply (Provision 5.3-3) though prefers that software updates are applied automatically (Provision 5.3-4, 5.3-5). The standard also recommends that whilst updates should be automatic, they should be configurable to allow the user to retain control of when their device is updated (Provision 5.3-6). When security updates are available, the standard requires that the user is informed of details of the vulnerability (Provision 5.3-11) and are notified regarding any loss of service that may occur during the update (Provision 5.3-12).
There are widely used solutions for providing secure software update solutions – free and open-source solutions such as SWUpdate as well as commercial solutions such as Memfault and Mender.io.
Finally the standard also requires that the model of the device is clearly recognisable, which may be via a label, user interface (Provision 5.3-16) or API. If a user knows the model of device they have, they can easily research for any support periods and for details of known issues or recalls.
Cryptography
The use of cryptography is essential when securing IoT devices, however weaknesses can be introduced through the poor selection of cryptography, insufficient implementation and inadequate key generation or handling. Therefore the standard mandates the use of “best practice cryptography” for the use of user authentication (Provision 5.1-3), to facilitate secure software update (Provision 5.3-7), to communicate securely (Provision 5.5-1) and to provide confidentiality when transmitting personal data (Provision 5.8-1, Provision 5.8-2). The standard also recommends that cryptography implementations (and security related functionality in general) are “reviewed or evaluated” (Provision 5.5-2). In reality, this is really just a strong suggestion to not reinvent the wheel and instead use third-party/open-source known-good implementations, as unless you’re a cryptographer it’s really difficult to implement security from scratch and get it right. Naturally, the standard also recommends that it it should be possible to update the cryptography used (Provision 5.5-3).
IoT devices usually contain what the standard refers to as “sensitive security parameters” which is really cryptographic material (e.g. credentials, keys, certificates, etc) used for providing the security of the device or services it interacts with. The standard requires that these are stored securely, which on modern hardware usually means making use of hardware-backed secure storage features. These features make it very difficult to access such parameters on a compromised device, even with physical access to the device. As an example, this page gives an overview of some of the security features of an NXP i.MX SOC.
The standard requires that any critical security parameters used for integrity and authenticity checks of software updates and to protect communication are unique per device (Provision 5.4-4). Clearly, if there is a compromise on one device then with per-device keys only that single device will be effected rather than the whole fleet.
The standard also recommends that critical security parameters are encrypted in transit (Provision 5.5-6) and requires that confidentiality is protected for critical security parameters that are communicated via remotely accessible network interfaces (Provision 5.5-7).
Similarly where hard-coded unique device identities are used for security purposes then those are required to be implemented via tamper persistent means (Provision 5.4-2).
The standard also requires that credentials (and other parameters) are not hard-coded in source, for example API keys, usernames and passwords (Provision 5.4-3).
Finally, the standard requires the manufacturer shall follow secure key management processes (Provision 5.5-8).
Finally, the standard also recommends that functionality made available via a network is only available after authentication (Provision 5.5-4), though this is required for functionality that can make security-relevant changes (Provision 5.5-5).
Security Hardening
Any software installed on an embedded device may contain vulnerabilities that could be exploited by attackers, therefore security can be improved by removing unused software and thus reducing the ‘attack surface’. The same is true for disabling unused hardware and debugging features.
The standard requires that all unused network interfaces and network services are disabled (Provision 5.6-1), along with physically accessible debug interfaces (Provision 5.6-4). It also requires that the device minimises disclosure of security-relevant information – for example not exposing versions of software used or configuration information (Provision 5.6-2).
The standard also recommends that unused features of the hardware (Provision 5.6-3) are disabled. It also recommends that unnecessary software is removed or disabled (Provision 5.6-5) and dead code is minimised (Provision 5.6-6).
The standard also recommends running software with the least necessary privileges (Provision 5.6-7) and that, where available hardware-level memory access controls are enabled (Provision 5.6-8).
Finally the standard recommends the use of a secure software development process (Provision 5.6-9).
Secure Boot
In order for devices to perform their intended role, it’s crucial that the software hasn’t been modified by an attacker. The standard recommends the use of secure boot to provide this attestation (Provision 5.7-1). By using secure boot device makers can have the confidence that the only software that can be run on the device is software that has been digitally signed by them.
The standard also recommends that when an unauthorised change is detected then the user should be alerted and use of the wider network should be limited (Provision 5.7-2). It also discusses the benefits and risk of having an ability to recover from such unauthorised change.
Resilience to Outages
The standard recognises that IoT devices play an increasingly critical role in our lives, therefore any loss of network or power shouldn’t unduly impact the availability of the service provided. The standard therefore recommends that resilience should therefore be built into IoT devices (Provision 5.9-1).
The standard also recommends that where power is restored, the device should “recover cleanly” and continue operating normally (e.g. it’s storage doesn’t get corrupt). It also states that the device should remain operational locally when network isn’t available (Provision 5.9-2).
Finally, the standard also recommends that steps are taken to use network resources in an orderly way, for example when deploying updates to update them in batches to prevent, or when recovering from a power outage leaving a randomised delay before reconnecting to the network. These steps mitigate against distributed denial of service attacks and improve the overall availability of the service provided.
Installation and Maintenance
An overly complex device that is difficult to configure and requires a knowledgeable end-user is more likely to be misconfigured than a device which is initialised with safe and secure default settings. As such the standard recommends that installation and maintenance of an IoT device should require minimal decisions by the user and follow security best practice on usability (Provision 5.12-1).
Furthermore the standard recommends that the manufacturer should also provide users with guidance on how to securely set up their device (Provision 5.12-2) and provide guidance on how to check their device is securely set up (Provision 5.12-3).
Validate Input
A large number of software vulnerabilities originate due to insufficient user input validation. Thus sanitising potentially malicious user originated inputs is essential to protect against a wide base of vulnerability categories. This is especially true in an era of automated tools such as fuzzers. Therefore the standard requires that all externally originated data is validated before use (Provision 5.13-1).
Data Protection
The standard requires that consumers are made aware of what personal data is processed and how it is being used (Provision 6-1) as well as ensuring that where consent is obtained, it’s obtained in a “valid way” (Provision 6-2) which can be withdrawn at any time (Provision 6-3).
The standard recommends that where telemetry data is collected then processing of personal data is kept to a minimum necessary (Provision 6-4) and requires that users are informed on what telemetry data is collected and how it is used (Provision 6-5). The standard recommends that any telemetry data is leveraged to examine for security anomalies (Provision 5.10-1).
The standard requires that the user has a means to erase their data from the device in a simple manner (Provision 5.11-1). It’s also recommends that a means is provided for removing personal data from any associated services in a simple manner via the device (Provision 5.11-2) and that clear instruction are provided for doing so (Provision 5.11-3). The user should also be given clear confirmation that their personal data has been removed (Provision 5.11-4).
Finally, the standard requires that all external sensing capabilities of the device (e.g. a microphone or camera) is documented in an accessible way that is clear and transparent for the user (Provision 5.8-3).
The EN 303 645 standard provides an excellent baseline level of security for consumer IoT devices, it’s recommendations are reasonably straightforward to achieve and are applicable across a broad range of devices. Furthermore, this standard has been adapted into subsequent vertical standards – for example ETSI TS 103 848 for home gateways in 2022, ETSI TS 103 815 for smart locks in 2024 and ETSI TS 103 927 for smart voice controlled devices in 2024.
The EN 303 645 standard is also underpinning government efforts around the world to legislate for improved cyber security. For example in April 2024 in the UK, the Product Security and Telecommunications Infrastructure Act (PSTI) came into force and requires manufacturers of UK smart devices to meet minimal security requirements – those requirements are based on the EN 303 645 standard. With regards to the EU Cyber Resilience Act, there are some categories of device where EN 303 645 may be used.
The EN 303 645 standard is freely available online with an implementation guide and assessment specification also available. It’s helpful to read the “Terms” section as some words and phrases used have specific meanings. It should be noted that not all recommendations of the standard are mandatory, though the standard does require that justifications should be recorded for each recommendation that is not fulfilled or applicable (Provision 4-1).
The EN 303 645 standard provides sensible recommendations that are easy to achieve. One side effect of manufacturers following the standard will hopefully mean we’ll see less stories like this in the news.
We’d love for you to reach out to us if you need assistance in implementing ETSI EN 303 645 or similar standards. We have plenty of experience with vulnerability management, long term software maintenance, software update, secure boot, security hardening and leveraging hardware security features.