UK PSTI Compliance for Connected Product Makers

Most compliance searches in the UK are still about CE marking and GPSR. Hardly anyone types "PSTI compliance" into Google yet, but that is starting to shift. The law banning weak default passwords on smart devices sold in the UK has been enforceable since 29 April 2024, and nearly two years on, a January 2026 industry survey found that 59.47% of IoT manufacturers still have no published way for a security researcher to report a bug. If your product connects to Wi-Fi, Bluetooth, or a SIM, this rulebook already applies to you, whether you have heard of it or not.

What is PSTI compliance, exactly?

PSTI stands for the Product Security and Telecommunications Infrastructure Act 2022. It got Royal Assent in December 2022, but the part that actually bites for product makers, known as the Product Security regime, only came into force on 29 April 2024. That regime is made up of the Act itself plus a companion statutory instrument, the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023.

Being "PSTI compliant" means meeting three specific security duties for any relevant connectable product you make, import, or sell in the UK. It is a narrower job than a full technical file for CE or UKCA marking, but it is a legal duty in its own right, and the Office for Product Safety and Standards (OPSS) can fine you up to £10 million or 4% of global turnover, whichever is greater, for getting it wrong. When the rules took effect, Viscount Camrose, then the UK's Minister for Cyber, put it plainly: "From today, consumers will have greater peace of mind that their smart devices are protected from cyber criminals, as we introduce world first laws that will make sure their personal privacy, data and finances are safe." For a fuller breakdown of the legal text and its scope, see our UK PSTI regulation page and the PSTI glossary entry.

Does PSTI apply to my product?

The Act covers "relevant connectable products": anything that can connect to the internet directly, or that can connect to another internet-connectable product over a network. That is a wide net. Smart TVs, connected baby monitors, smart speakers, video doorbells, fitness trackers, smart plugs, and routers are all squarely inside scope. So is most consumer electronics with a Wi-Fi chip bolted on almost as an afterthought.

There are a few carve-outs worth knowing. Electric vehicle charge points, medical devices, smart meters, and plain desktop or laptop computers sit outside the regime because they are already governed by other rules. Everything else that connects, from a smart kettle to a connected garage door opener, needs to be checked against the three requirements below. If you are unsure where your own product lands, our compliance check tool is a fast way to see what applies before you commit engineering time to a fix.

The three requirements you must meet

PSTI compliance boils down to three duties, and all three trace back to a global standard called ETSI EN 303 645, which UK regulators used as the technical basis for the law.

• No default or easily guessable passwords. Every unit must ship with a unique password, or force the user to set one on first use, rather than shipping with "admin/admin" or something similarly weak.
• A published vulnerability disclosure policy. You need a clear, publicly accessible point of contact so a security researcher who finds a flaw in your product knows how to report it, and roughly what response to expect.
• A stated minimum security update period. You must tell customers, before or at the point of sale, how long the product will keep receiving security updates, or explicitly say if it won't receive any.

None of these are exotic asks. Most of the cost sits in policy and documentation rather than in redesigning hardware. But they are legal duties with a paper trail, which is exactly the kind of thing that trips up small teams who assume "we'll sort security later." Our Declaration of Conformity generator can help you pull the supporting statement together once you have the substance in place.

Worth knowing: the duty sits with whoever is named as the manufacturer, importer, or distributor on the product, not just the factory that built it. If you are a UK brand having a product built overseas and sold under your own name, you are the one OPSS will come to first, regardless of where the firmware was actually written.

How PSTI compares with the EU Cyber Resilience Act

If you sell into both the UK and the EU, it is easy to conflate PSTI with the EU's Cyber Resilience Act (CRA). They cover similar territory, connected product security, but they are not the same law, and treating them as interchangeable is a common and costly mistake.

The table below shows how the two regimes line up on the points that matter most to a small hardware team.

PSTI is narrower but already live and already being checked. The CRA is broader and phases in over the next 18 months, with its first hard deadline, mandatory reporting of actively exploited vulnerabilities, landing on 11 September 2026. If you are building a product roadmap around both, our CRA reporting deadline guide walks through what that September date actually requires. The practical takeaway: PSTI is your immediate UK obligation, and CRA readiness is the project you should already be starting.

What happens if a smart pet feeder gets this wrong?

Say you are a two-person startup selling a Wi-Fi-connected pet feeder through Amazon UK, roughly 3,000 units a year. The app requires a password on setup, so you assume you are covered. But nobody has published a security contact, and the packaging says nothing about how long the feeder will get firmware updates.

On paper, that is two of the three PSTI duties unmet. If OPSS runs a spot check, or a customer complaint flags it, you could be asked to produce a statement of compliance you don't have. Fixing it after the fact means a hurried policy page, a firmware update statement retrofitted onto packaging that has already been printed, and possibly a stop notice while it's sorted. Fixing it before launch is an afternoon's work: a security.txt-style contact page and one paragraph of update commitment on the listing. The difference is entirely about sequencing, not effort.

How do you actually prove compliance?

Evidence is what OPSS will ask for if it comes knocking, and evidence is also what protects you if a retailer or marketplace asks for proof before listing your product. In practice that means keeping three things on file: your password approach documented in your design records, a live URL where the vulnerability disclosure policy sits, and a written statement of the update period that matches what is printed on the box or shown at the point of sale.

If you already produce a Declaration of Conformity for CE or UKCA purposes, PSTI evidence sits alongside it rather than replacing it. Anyone importing hardware from overseas factories should also flag PSTI early in supplier conversations, since a factory that has never heard of ETSI EN 303 645 will need clear written specs, not a verbal request.

Keep those records for as long as the product is on sale, plus a reasonable tail afterwards, in case a query lands months after your last unit shipped. It is also worth revisiting the update period statement every time you plan a hardware refresh, since a new model with a longer support commitment can quietly make an older statement look stale even if nothing about the old product has changed.

None of this needs a security team. It needs someone to own three specific documents and keep them current as products change. Start with the PSTI regulation page to confirm your product is in scope, then use our compliance check to map what else your product needs before it goes on sale.