Since 29 April 2024 it has been unlawful in Great Britain for a manufacturer, importer or distributor to make most consumer connectable products available unless they meet three baseline security requirements and come with a statement of compliance. The legal basis is Part 1 of the Product Security and Telecommunications Infrastructure Act 2022 (the PSTI Act) and the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 (SI 2023/1007), amended twice in 2025. This guide explains who and what is covered, the password, vulnerability reporting and support period requirements, the statement of compliance, the routes to deemed compliance through ETSI EN 303 645 and foreign labels, and enforcement. It is for product security teams, compliance leads, importers and online marketplaces. For the underlying technical standard, see the ETSI EN 303 645 Consumer IoT Guide. Status checked on legislation.gov.uk and GOV.UK on 27 October 2026.
Key takeaways
- Three requirements, all mandatory: no universal default passwords, a published way to report security issues with response timescales, and a published minimum security update period (the "defined support period").
- Duties fall on the whole supply chain: manufacturers comply and issue the statement of compliance; importers and distributors must not make a product available without one, and must act on compliance failures.
- Deemed compliance routes exist: meeting named ETSI EN 303 645 provisions (or ISO/IEC 29147 clauses for reporting), or holding a current Japan JC-STAR STAR-1 or Singapore Cybersecurity Labelling Scheme label.
- Penalties are significant: up to the greater of £10 million or 4% of qualifying worldwide revenue per breach, plus up to £20,000 per day for continuing breaches, enforced by the Office for Product Safety and Standards (OPSS).
- Several categories are excepted: including products supplied in Northern Ireland, EV charge points, medical devices, smart meters, non-cellular desktops, laptops and tablets, and (since 25 February 2025) motor and agricultural vehicles in Great Britain.
Scope: who and what is covered
The regime applies to "relevant connectable products": products that are internet-connectable or network-connectable and are not excepted. Part 1 of the Act defines "UK consumer connectable product" (section 54) and the relevant persons (section 7): manufacturers, importers and distributors. A manufacturer established outside the UK can appoint a UK authorised representative to carry out certain duties, but GOV.UK guidance is clear that the manufacturer remains liable for failures.
Typical in-scope products include smart TVs and speakers, connected cameras and doorbells, smart home hubs, wearables, connected toys and baby monitors, and home routers. The test is the product and its intended consumer market, not the size of the company.
| Excepted product (Schedule 3 to SI 2023/1007) | In force from |
|---|---|
| Products made available to be supplied in Northern Ireland | 29 April 2024 |
| Charge points for electric vehicles | 29 April 2024 |
| Medical devices | 29 April 2024 |
| Smart meter products | 29 April 2024 |
| Desktop computers, laptop computers, and tablet computers that cannot connect to cellular networks | 29 April 2024 |
| Motor vehicles (in Great Britain) | 25 February 2025 (inserted by SI 2025/211) |
| Two- or three-wheel vehicles and quadricycles (in Great Britain) | 25 February 2025 (SI 2025/211) |
| Agricultural and forestry vehicles (in Great Britain) | 25 February 2025 (SI 2025/211) |
Products excepted here are often covered by their own sector rules (medical devices, smart meters, EV charge points, vehicles). Northern Ireland is excepted because EU product rules apply there; manufacturers selling into both markets should also track the EU Cyber Resilience Act. See the EU Cyber Resilience Act Guide and the Product Security Laws Map.
Key obligations
The three security requirements (Schedule 1)
| Requirement | What the law requires | Practical evidence |
|---|---|---|
| 1. Passwords | Where passwords are used (outside the factory default state), they must be unique per product or defined by the user. Unique passwords must not be based on incremental counters, publicly available information or unique product identifiers such as serial numbers (unless derived with encryption or keyed hashing accepted as good industry practice), and must not otherwise be easily guessable. Cryptographic keys, certain pairing PINs for non-IP protocols, and API keys are excluded. | Password generation design, per-device provisioning records, test results showing no shared defaults |
| 2. Reporting security issues | Publish at least one point of contact for reporting security issues and state when the reporter will receive an acknowledgement and status updates until resolution. The information must be accessible, clear and transparent, provided without prior request, in English, free of charge, and without requiring personal information. | Public vulnerability disclosure policy page, intake mailbox or form, internal SLA records |
| 3. Minimum security update periods | Publish the defined support period (an end date or length of time) so that someone without technical knowledge can understand it. Publish any extension as soon as practicable. Shortening a published period breaches the requirement. Where the manufacturer sells on its own website, the period must appear with equal prominence to the price information. | Product pages, packaging copy, internal update policy and support roadmap |
Statement of compliance
Section 9 of the Act requires manufacturers to ensure the product is accompanied by a statement of compliance. GOV.UK notes the Act calls it a "document" and does not require it to be physical. Schedule 4 to the Regulations sets the minimum content:
- Product type and batch.
- Name and address of each manufacturer and any authorised representative.
- A declaration that the statement was prepared by or on behalf of the manufacturer.
- A declaration that, in the manufacturer's opinion, the product complies with the Schedule 1 requirements or meets the Schedule 2 deemed compliance conditions.
- The defined support period as it was when the manufacturer first supplied the product.
- Signature, name and function of the signatory.
- Place and date of issue.
Where compliance relies on a standard, the statement must identify its number, version and date of issue. Manufacturers and importers must retain a copy (regulations 8 and 9).
Supply chain duties
- Manufacturers: comply with the requirements (s.8), issue the statement (s.9), investigate potential compliance failures (s.10), take action and notify where there is a failure (s.11) and keep records (s.12).
- Importers: must not supply products where the manufacturer has failed to comply, must ensure a statement of compliance accompanies the product, investigate and act on failures, and keep records (ss.14 to 20).
- Distributors: equivalent duties not to supply non-compliant products and to act on failures (ss.21 to 25).
Deemed compliance (Schedules 2 and 2A)
| Requirement | Condition A | Condition B | Condition C |
|---|---|---|---|
| Passwords | ETSI EN 303 645 provision 5.1-1 and, where relevant, 5.1-2 | Current Japan JC-STAR STAR-1 label | Current label at any level of the Singapore Cybersecurity Labelling Scheme |
| Reporting security issues | ETSI EN 303 645 provision 5.2-1, or ISO/IEC 29147 paragraphs 6.2.2, 6.2.5 and 6.5 | Current JC-STAR STAR-1 label | Current Singapore CLS label |
| Minimum security update period | ETSI EN 303 645 provision 5.3-13, with the Schedule 1 publication rules still applying | Current JC-STAR STAR-1 label | Current Singapore CLS label |
| Statement of compliance (Schedule 2A) | Current JC-STAR STAR-1 label | Current Singapore CLS label | None |
Schedule 2A and regulation 4A were inserted by SI 2025/1267 with effect from 4 December 2025. Labels must be current and unexpired at the relevant time.
Timeline and current status
| Date | Event | Source |
|---|---|---|
| December 2022 | PSTI Act 2022 receives Royal Assent | GOV.UK regime guidance |
| 14 September 2023 | SI 2023/1007 signed into law | GOV.UK regime guidance |
| 29 April 2024 | Product security regime takes effect | GOV.UK; legislation.gov.uk |
| 25 February 2025 | SI 2025/211 adds vehicle exceptions and a minor amendment to Schedule 1 paragraph 3 | legislation.gov.uk |
| 4 December 2025 | SI 2025/1267 inserts regulation 4A and Schedule 2A (deemed compliance for the statement of compliance via JC-STAR and Singapore labels) | legislation.gov.uk |
Status as at 27 October 2026: the regime is in force. legislation.gov.uk showed no known outstanding effects for SI 2023/1007 when checked. Regulation 10 provides for review, so the requirements may change: check legislation.gov.uk before relying on this summary.
Enforcement and penalties
OPSS, part of the Department for Business and Trade, enforces the regime under a memorandum of understanding with DSIT, using a risk-based and proportionate approach according to GOV.UK guidance.
| Power | Act section | Detail |
|---|---|---|
| Compliance, stop and recall notices | ss.28 to 30 | Require action, stop supply or recall products; appeals under s.33 |
| Failure to comply with a notice | s.32 | Criminal offence; on summary conviction a fine (England and Wales), up to level 5 on the standard scale (Scotland and Northern Ireland) |
| Monetary penalties | ss.36 to 38 | Per breach, up to the greater of £10 million or 4% of qualifying worldwide revenue for the most recent complete accounting period, plus a daily penalty not exceeding £20,000 while the breach continues |
| Forfeiture | ss.42 to 44 | Forfeiture of non-compliant products |
| Publicity | ss.45 and 46 | Inform the public about compliance failures and publish enforcement action |
| Director liability | s.52 | Offences by directors, partners and similar officers |
Section 37 requires a penalty to be appropriate and proportionate, taking into account the effects of the breach and any remedial action taken.
What it means for AI agents and non-human identities
The PSTI requirements are about device credentials and lifecycle, which is non-human identity territory:
- Device credentials are identities: the password rule ends shared factory defaults, but Schedule 1 explicitly excludes cryptographic keys and API keys. Those still need unique, protected provisioning. Treat per-device keys and certificates as the real identity layer. See the Device and IoT Identity Guide and the IoT Device Identity with TPM and DICE Guide.
- Cloud companions and app tokens: most connected products depend on a companion app and cloud back end that issue tokens and API keys. The law does not regulate those directly, but a leaked shared API key in firmware undermines the unique-password goal. Inventory and rotate them.
- Support period is a credential lifetime question: when security updates stop, certificates, keys and trust anchors on the device are no longer maintained. Align certificate validity and back-end token policies with the published defined support period.
- AI features and agents: products with on-device assistants or cloud AI agents are still relevant connectable products if they are network-connectable. Vulnerability reports about AI features (for example prompt injection reaching device controls) should flow through the same published reporting route and timescales.
Compliance steps
- Scope the portfolio: list every product sold in Great Britain, mark connectability, and check each against the Schedule 3 exceptions.
- Close password gaps: test each product (including pre-installed and required software) for shared or derivable passwords; move to per-device generation or forced user definition at set-up.
- Publish a reporting route: a vulnerability disclosure page with contact point, acknowledgement and update timescales, with no personal data required. Align it with ISO/IEC 29147. See the Vulnerability Disclosure Policy Template and the PSIRT Guide.
- Set and publish the defined support period: agree it with engineering and finance, publish it in plain language on packaging, product pages and next to the price on your own web store, and never shorten it.
- Decide the compliance route: direct assessment against Schedule 1, deemed compliance via ETSI EN 303 645 provisions, or a current JC-STAR STAR-1 or Singapore CLS label.
- Produce the statement of compliance: include all Schedule 4 items, distribute it with each product (digital is acceptable), and retain copies.
- Brief importers and distributors: provide statements and evidence; agree how compliance failures are reported and handled.
- Test and maintain: re-test on every firmware release and new batch, and have a rollback plan: if a release breaks compliance (for example reintroducing a default credential), stop shipment of that batch and issue a fix.
Choosing a route: a manufacturer already testing against ETSI EN 303 645 will usually find Condition A the cheapest evidence path, because the three mapped provisions are a small subset of that standard. A manufacturer that already sells into Japan or Singapore with a current label can rely on that label, but must track its expiry, because a lapsed label removes the deemed compliance. Small manufacturers with a few products often assess directly against Schedule 1 and keep a short evidence file per product. Large portfolios benefit from one documented route per product family, so that a firmware change triggers a known re-test.
Frequent mistakes seen in practice: a support period published only in a PDF manual rather than with the price, a reporting address that bounces or demands an account login, a statement of compliance that names the product family but not the batch, and companion app updates that silently reintroduce a shared default credential on older hardware.
Practitioner checklist
- Confirm which products are relevant connectable products and which are excepted under Schedule 3.
- Verify no product ships with a universal or derivable default password.
- Publish a security issue reporting contact with acknowledgement and update timescales.
- Publish the defined support period in plain English, including next to the price on your own website.
- Choose and document the compliance or deemed compliance route.
- Issue a statement of compliance with all Schedule 4 content and retain copies.
- Give importers and distributors the evidence they need and a route to report failures.
- Inventory device keys, certificates and companion app API keys and align them with the support period.
- Track SI amendments and OPSS guidance at least quarterly.
Standards and references
- legislation.gov.uk: Product Security and Telecommunications Infrastructure Act 2022
- legislation.gov.uk: The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023
- legislation.gov.uk: SI 2023/1007 Schedule 1, Security requirements for manufacturers
- legislation.gov.uk: SI 2023/1007 Schedule 2, Conditions for deemed compliance
- legislation.gov.uk: SI 2023/1007 Schedule 3, Excepted connectable products
- legislation.gov.uk: SI 2023/1007 Schedule 4, Minimum information for statements of compliance
- GOV.UK: The UK Product Security and Telecommunications Infrastructure (PSTI) product security regime
Related NHI Mgmt Group resources: ETSI EN 303 645 Consumer IoT Guide · EU Cyber Resilience Act Guide · Product Security Laws Map · IoT Security Guide · Device and IoT Identity Guide. This guide summarises the UK PSTI product security regime as at 27 October 2026 and is not legal advice.