It’s a nice spring Saturday in 2023 and what am I doing? I am sat inside listening to classical music and writing this instead of being outside enjoying the sunshine! But it is important…

The government announcement today: ‘Starting gun fired on preparations for new product security regime‘ published the draft secondary legislation details (pdf) to accompany the Product Security and Telecommunications Act. More specifically: ‘The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations, subject to parliamentary approval.’ The regime details are further explained here. In terms of IoT security, we have been waiting for this for a long time. I can tell you that I was discussing with government colleagues what we really mean by ‘password’ and what should be in and out for this part of the work in January 2020 just before the pandemic, which now seems like a lifetime ago.

For some background to this please read the following blog which also has a bunch of links to the previous history. You can also follow this twitter thread I’ve been running on the legislative progress. The relevant government department is now DSIT (the Department for Science, Innovation and Technology) and the work is based on the Code of Practice for Consumer IoT Security which evolved into the international standard ETSI EN 303 645.

So what is this new stuff? Well the primary legislation for the Product Security and Telecommunications Infrastructure Act (2022) was passed in December 2022 and that provides the overall framework. We’re looking specifically at Part 1 of the Act which deals with Product Security. The secondary legislation contains the specific text of the technical requirements that the government is seeking to regulate. The reason for this approach is pretty straightforward. The use of secondary legislation allows for adaption to accommodate the way that technology rapidly develops, without having to return to parliament for a completely new process of new legislation. This makes obvious sense and means that the legislation is both robust from a longevity perspective – i.e. there’ll always be a need to govern product security, but flexible to adapt to changing circumstances e.g. the market entirely gets rid of passwords for some new technology, or that the bar of security should be raised by adding new requirements.

What do the draft regulations say?

At a high level, here’s what’s in the draft (and I’m paraphrasing here):

• There are three requirements – no default passwords, to have and act on a vulnerability disclosure policy and to be transparent about the minimum time consumers will get software updates.
• The requirements will come into force on the 29th of April 2024 – so one year from the announcement and that’s all of three them, they are not staggered in any way.
• If there are multiple manufacturers involved in a connected product, they all have to meet the requirements.

What are the technical requirements?

Schedule 1 outlines the security requirements for manufacturers. I’ve covered off the details of the requirements before, but to drill down a little bit into what the draft regulations say on the technical side:

On passwords:

The scope is pre-installed software on a device and hardware – but not when it’s in a factory default state. To be clear on this – it would be permissable to have a default password for pre-initialising a device, but only to put it into a state where unique password could be chosen. It’s not my ideal scenario if I’m honest but it is practical – if you’re in a position where you deploy a lot of devices, especially to consumers, there are a lot of situations where devices need to be reset including when the device is first turned on. I dream of the day that we don’t have to use passwords at all, but it is still a long way off and we can only play the cards we’re dealt. If you’re a manufacturer reading this, think very carefully about what you can do to avoid using passwords and what you’re doing in that factory initialisation state.

On the password detail:

• They’ve got to be unique or defined by the user of the product.
• They cannot be easily guessable, be based on incremental counters etc. (i.e. all the tricks that vendors use that they think are clever – XOR anyone?)
• Passwords don’t include cryptographic keys, pairing data, API keys etc. (think about Bluetooth, Zigbee and so on – all important, but not the target of this particular requirement).

On how to report security issues (vulnerability disclosure):

The scope is the hardware and pre-installed software of the product as well as software that is installed (e.g. apps) that are needed for the IoT product to work properly.

• There needs to be a point of contact for people to report security issues in a clear and accessible way (and it outlines what they expect in that sense).
• The manufacturer has to acknowledge the report and then give status reports until the issue is resolved.

I hope this is a further wake-up call – my company has been producing research and data on this topic for the past 5 years for the IoT Security Foundation. This year’s report showed that only 27% of IoT manufacturers had vulnerability disclosure in place. Let’s see how it progresses this year.

On information on minimum security update periods:

The scope is as before – with software developed in connection with the purpose (so think of, say a smartphone app to control the IoT device).

• The information on the support period must be published.
• It must be accessible, clear and transparent (and they explain what that means).
• When a product is advertised for sale – the manufacturer needs to list this information in the specs (I’m heavily paraphrasing here).
• The manufacturer can’t shorten the update lifespan after they’ve published it (naughty!!)
• If the update support period is extended, then the manufacturer needs to update that information and publish it.

After this, there is another Schedule (Schedule 2) which outlines the ‘Conditions for Deemed Compliance with Security Requirements’. This is very detailed but there are some important points within it which essentially boil down to the following:

• A manufacturer complies with the requirements by implementing the relevant ETSI EN 303 645 (IoT security) provisions or ISO/IEC 29147 (vulnerability disclosure) paragraphs which are listed.

Schedule 3 then lists things that are out of scope – ‘Excepted connectable products’. There are some elements related to Brexit / free movement of goods but I won’t go into those here, but concentrate on the product parts:

• Medical devices – these are covered by the Medical Devices Regulation 2002. However! If the bit that is regulated is only the software, then the hardware requirements of this IoT regulation apply.
• Smart meters – if they’ve been installed by a licensed gas / electricity installer (which is defined) and have been through an assurance scheme (e.g. from NCSC), they’re out of scope.
• Computers – desktop, laptops and tablets that aren’t connectable to the mobile network are out-of-scope. However if these types of products are designed for children under 14, then they are in scope.

There’s been a lot of debate over this in general over the years and I think I can summarise this by saying – we’re looking at IoT products. That is predominantly where the problem is and we’ve got to draw the lines in places. It’s sensible to keep already regulated domains out-of-scope but obviously there are some grey areas that you can easily think of (think wellness products vs medical products or whether you consider cars to be large IoT devices or not). I guess the key message is – some of this will evolve over time too. The beauty of secondary legislation is that it can shift too to react to how this fantastic technology embeds itself in our lives in the future.

The final Schedule explains what is needed for Statements of Compliance – i.e. to confirm that the product does indeed meet the requirements.

The draft regulations have been shared with the World Trade Organisation (WTO) under the country’s obligations under the Technical Barriers to Trade (TBTs) Agreement as well as the EU Commission. This is all really important because in no way does this legislation put blockers on trade around the world – it is designed to help consumers be protected from poorly secured products. With international standards being referenced within the regulations, it ensures that there is adoption of internationally agreed technical elements, reducing the risk of fragmentation and divergence between markets around the world.

To answer a couple of obvious questions that I’ve seen mentioned before in relation to PSTI:

Why are there not more technical requirements in the draft regulations?

On adding new requirements, here’s my view – the regulations refer to ETSI EN 303 645 and the Code of Practice. If you’re a manufacturer of IoT solutions, you should already be implementing those requirements anyway. The top three items that have been adopted into the draft regulations are the minimum and most impacting in terms of the issues we face. It doesn’t really matter if you’ve got great hardware security in place if you’ve got admin, admin default password access across the device or service, no way for security researchers to contact you if they’ve discovered a vulnerability in their product, or don’t ever bother updating the device.

The technical requirements were written ages ago, this is old stuff, what about [insert buzzword]?

This is not true – if you go through the Code of Practice and also the ETSI spec, they were specifically designed to primarily deliver outcomes – e.g. things we wanted to stop doing or things we wanted to see happen. A lot of it doesn’t specifically say how you have to get there. I’ve talked about this before, but in summary all of the requirements hold true whether this was 2016 or 2030 e.g.

• I do not want default passwords in my device, someone will get in because they can be discovered easily.
• Hardware security provides a foundation that enables a device to boot and operate more securely than without it.
• Being transparent about software updates gives me, the consumer more information about whether I want to buy a product.
• Having a public security contact at a company allows security researchers to report vulnerabilities, allowing problems to be solved in an efficient and timely manner, ultimately protecting the users of the products that company makes.

And so on… So don’t let anyone say that the requirements are out of date – whatever the technology (and I’ll go further than consumer to pretty much all IoT) – these requirements will continue to be directly applicable as long as we have electronics, software and malicious actors.

Next Steps

So what are the next steps? Well, the formal text on the government website states ‘Following their approval by Parliament, and the conclusion of the UK’s notification commitments under international treaties, the consumer connectable product security regime will enter into effect on 29 April 2024.’ Now the countdown is well and truly started.