UK IoT Security Legislation

Fingerprint Icon Written by Chris Powell

IoT Security Legislation

Autonomous devices make our lives more comfortable. Even security-focused geeks, such as myself, have robot vacuum cleaners and smart lawnmowers.

However, the push to make smart devices cheap and more affordable has to lead to a quality problem. And quality problems typically show up as security problems.

I like to say “bad security is indicative of bad quality”.

Smart Hoover & IoT Lawn Mower
- My IoT hoover and smart lawn mower

ETSI EN 303 645

To address these IoT security issues, the European Telecommunications Standards Institute (ETSI) developed ETSI EN 303 645, more colloquially known as “Cyber Security for Consumer Internet of Things: Baseline Requirements”. It's an open standard that sets out how to secure IoT devices.

The point of this article is to describe its thirteen principles in an easy to digest manner while highlighting potential sticking points. If I can leave you with a good high-level understanding of its elements, then I've done my job.

As a prerequisite, if you are unfamiliar with the proposed UK IoT security legislation. Please review the government press release located here.

The UK's proposed laws will not cover the entire standard, only the first three elements.

  • No universal default passwords.
  • Implement a means to manage reports of vulnerabilities.
  • Keep software updated.

They also only apply to consumer household devices, not industrial ones. But any IoT system that ends up in a UK home will have to comply with the regulations.

Associated Services

The IoT ecosystem never comprises just hardware devices. A combination of mobile applications, web interfaces and cloud backends, such as Azure or AWS, surround the technology.

Risk management strategies have to consider the whole environment. Any application that supports or manages an internet-connect system is an associated service.

Constrained Devices

Constrained devices are those that are limited in hardware resources or power utilisation. A good example is a smart heating system with a thermostat that acts as a centralised hub.

The thermostat's job is to communicate with remote controllers to regulate heating elements. In this scenario, the controllers are the “constrained devices” because they lack physical resources.

It's an important distinction because the controllers cannot perform rigorous security checks. The standard takes these limitations into account and fits nicely around this model.

Thirteen Principles

1 — No universal default passwords

A global default password is a universal password that is applied by default to every smart device model in a product line. It does not matter if it is or isn't possible to change; the standard mandates they must not be used.

Note, it does not include passwords that are sufficiently strong and unique to each device. However, it does not allow generation from known seed values such as a MAC address, serial numbers, or incremental passwords such as “password1”, “password2”, “password3” etc.

2 — Implement a means to manage reports of vulnerabilities

All software and hardware, including IoT devices, has vulnerabilities. Organisations must have policies around dealing with software bugs and security patching.

This element mandates that organisations must have a policy for managing vulnerability reporting by either fixing the problem themselves or passing it on to an appropriate authority. There must be a point of contact and acknowledgement of the report with routine status updates.

3 — Keep software updated

This element mandates that organisations must provide security updates and make it clear when the system turns end off life.

As part of this, it states that devices must have their make, model and version number visible. Otherwise, it must return this information upon interrogation.

4 — Securely store sensitive security parameters

The standard mandates that critical security parameters must be sufficiently protected.

It's worth noting that there is a difference between parameters with regards to security levels. For example, a device name may not be sensitive, whereas a software integrity key is.

Hardware protections such as Trusted Execution Environments (TEEs) or Universal Integrated Circuit Cards (UICCs) are ideal for these applications.

Not using hardcoded values within source code and utilising unique update keys is also required.

5 — Communicate securely

This element states that data stored on devices, as well as transmitted information, should use best practice cryptography where appropriate. However, this is not always possible, as is the case with constrained devices.

It's mandatory to protect critical interfaces and restrictions must exist to prevent unauthenticated changes. The term best practice allows for future modifications to the device without violating the standard.

6 — Minimise exposed attack surface

The principle of least privilege is required. That is, interfaces and hardware should not permit more access than needed during regular operations. However, it is not a static definition, as most devices configure themselves differently depending on their current state.

If a system is uninitialised, as is the case when first purchased, then it's permissible to place it in a more open configuration temporarily. But, only during initial setup.

7 — Ensure software integrity

Ensuring software integrity, preventing rollback attacks and detecting tampering is essential to good device security. This element states that there should be a mechanism to prevent unauthorised software updates.

If changes or system alterations are detected, then the device should alert the user and may isolate itself from the network.

8 — Ensure that personal data is secure

Ensuring that personal information is protected sounds similar to provision 5 — communicate securely. The difference is that this element focuses on personal data only.

That is because personal data isn't just transmitted locally. It is also used and stored by associated services — for example, mobile applications, web interfaces and cloud backends.

Personal data must use appropriate cryptographic protections, and its precise use must be clear to consumers.

9 — Make systems resilient to outages

Systems inevitably break. Whether it's the WiFi disconnecting or a cloud service becoming unresponsive, devices must be resistant to outages.

If a smart device losses connectivity with its backend service, for example, an internet-connected door lock. It must not fail in such a way as to compromise its base functionality.

The standard mandates that systems must be resilient to outages and be able to recover in an automated fashion.

10 — Examine System telemetry data

If the device collects data such as access logs and system monitoring information during operation, then it should be analysed for security anomalies.

The manufacturer, operator or developer is permitted to perform this analysis via a remote service.

11 — Make it easy for users to delete user data

The device must allow users to delete their data without compromising the system functionality. The instructions should be clear, easily accessible and a confirmation provided upon deletion.

No user data should exist in the event they transfer ownership to another individual.

12 — Make installation and maintenance of devices easy

Most smart device consumers are not security experts. Therefore IoT systems should configure, and maintain themselves securely with minimal interaction from the user.

To this end, a manual process is allowed provided it minimises the amount of human intervention. It should also be possible to interrogate the device to verify the setup.

13 — Validate input data

Weak validation of data is the primary cause of memory-based vulnerabilities such as remote code execution, information disclosures and denial of service attacks. This element states protocol parsers, API code and network interfaces should validate data correctly.

However, there are always edges cases that anyone can miss. It's why using automated analysis tools such as static analysers, and instrumented fuzzers is so essential.


There's more to the standard than what I've described here, and the level of protection depends on the specific use case. However, having official guidelines to work from is an initial step in the right direction.

If you operate, manufacturer or develop home-based IoT devices that touch the UK market, then you will be affected by the upcoming legislation. However, ignoring these changes and applying fixes later will inevitably be more costly.

Remember that ETSI EN 303 645 is a European standard so expect to see similar schemes and regulations across the continent. Finland is a noteworthy example as they have already established an IoT security certification program.

Make sure to apply fixes, assure your devices and verify that you don't get caught out.