The UK's Product Security and Telecommunications Infrastructure Act 2022 (PSTI) Part 1 came into force on 29 April 2024, making the United Kingdom the first jurisdiction to impose binding minimum security requirements on consumer connectable products at the point of sale. A year of enforcement by the Office for Product Safety and Standards (OPSS), working under DSIT (the Department for Science, Innovation and Technology), has produced enough public evidence to draw conclusions. This review is written for engineers and product security leads who ship to the UK market and for TPRM teams whose vendors do.
The headline: the PSTI's three baseline requirements — no universal default passwords, a published vulnerability disclosure policy, and minimum security update periods — have caught more large vendors than small ones, have exposed weak points in firmware supply chains, and have generated enforcement letters that give everyone else a template for what to avoid.
What does the PSTI Act actually require?
PSTI Part 1 and the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 (SI 2023/1007) impose three primary obligations on manufacturers, importers, and distributors of consumer-connectable products supplied in the UK. First, passwords must be unique per device or user-defined, or the device must require the user to set a password at first use; universal default credentials are prohibited. Second, the manufacturer must publish a vulnerability disclosure policy that includes a point of contact for reporting issues and expected timelines for acknowledgement and response. Third, the manufacturer must publish the minimum length of time the device will receive security updates.
Each obligation is accompanied by a Statement of Compliance requirement: the manufacturer must provide a document declaring compliance and retain it for at least 10 years. Schedule 3 of the regulations lists limited exclusions, including charge points for electric vehicles covered by separate regulations and certain medical devices regulated under the Medicines and Medical Devices Act 2021.
Civil penalties under PSTI Section 36 can reach £10 million or 4% of worldwide revenue, whichever is greater, plus £20,000 per day for ongoing contraventions. That bracket sits deliberately in the same shape as GDPR, signalling the enforcement ambition.
How has enforcement played out in year one?
The OPSS has published enforcement guidance and, throughout 2024 and 2025, a growing body of decisions under the regulations. Publicly documented patterns include products listed for sale on UK marketplaces with firmware that still shipped with universal default credentials (typically admin/admin or root with a known static password), products with no linkable vulnerability disclosure contact on the manufacturer's UK-facing site, and Statements of Compliance that pointed to EU RED Article 3.3 compliance without mapping specifically to PSTI obligations.
The January 2025 Which? investigation into UK-sold smart doorbells — widely reported in the British press — surfaced specific brands with hard-coded credentials in firmware and with Statements of Compliance that did not match the physical products. DSIT's follow-up correspondence, later published in Parliamentary Questions, confirmed that the OPSS had opened several investigations under the regulations.
The pattern of enforcement is instructive. The OPSS has so far preferred compliance notices over immediate penalties, giving manufacturers a defined period to remediate. Where remediation has failed — primarily because a firmware update was not feasible within the notice period — the OPSS has moved toward withdrawal notices, effectively banning the product from UK supply.
What have vendors struggled with most?
Three failure modes dominate the public record. The first is supply chain opacity: a brand that sold the product did not know what its ODM or chipset vendor had baked into firmware. The Realtek-based camera SoCs and MediaTek reference designs have been named in multiple OPSS communications as underlying sources of default credential issues, echoing the 2023 Akamai advisory on widespread IoT credential reuse.
The second is disclosure policy formalism. Many vendors published a generic "security@" mailbox but did not meet the PSTI's expectation that the disclosure policy include response timelines. ETSI EN 303 645, the standard the PSTI regulations effectively import, sets clearer expectations: acknowledge receipt within a reasonable time, and keep the reporter informed of triage status. Vendors whose mailboxes auto-replied with "we will respond within 90 days" ran into PSTI section 9 compliance questions.
The third is the support-window statement. "For the lifetime of the device" is not a compliant statement under PSTI: the regulation requires a defined minimum period. OPSS guidance published in July 2024 clarified that vagueness is non-compliance. Vendors have had to publish concrete minimum periods — typically 3 to 5 years for smart home devices and longer for alarm systems — and their marketing has had to catch up.
How does PSTI interact with the EU Cyber Resilience Act?
The EU Cyber Resilience Act (Regulation (EU) 2024/2847), published in the Official Journal on 20 November 2024, imposes a broader set of requirements on "products with digital elements" and covers most commercial software in addition to IoT. The CRA's main obligations begin applying 36 months after entry into force, with early obligations (vulnerability reporting to ENISA) activating 21 months in.
PSTI and CRA are complementary rather than redundant. PSTI is narrower — consumer IoT, three baseline obligations, fast enforcement. CRA is wider and deeper — all products with digital elements, essential requirements including vulnerability handling across the product lifecycle, conformity assessment procedures. A manufacturer selling into both UK and EU markets cannot comply with PSTI and ignore CRA; the CRA's conformity assessment regime will eventually subsume PSTI's Statement of Compliance for products within its scope.
What does this mean for software supply chain risk?
The PSTI has produced an unusual public-interest dataset: a cross-section of UK-sold connectable products and their actual security posture. The pattern — ODM-sourced firmware, unknown chipset-level defaults, generic disclosure policies — echoes every supply chain incident the security community has tracked for a decade, from Mirai to the 2021 Verkada camera breach to the 2023 disclosures by Bitdefender on Wyze and Eufy cameras.
For enterprise buyers, PSTI enforcement is a leading indicator. A vendor that cannot meet PSTI's three requirements for its consumer line almost certainly has weaker supply chain hygiene in the enterprise portions of its business. Procurement teams should treat public PSTI notices as evidence for their own TPRM tiering.
How does PSTI apply to industrial IoT and commercial products?
PSTI Part 1 is scoped to consumer connectable products, defined in Schedule 1 of SI 2023/1007. Industrial IoT, commercial networking gear, and enterprise connectable products fall outside that scope. However, products that ship in both consumer and commercial variants often share firmware, and OPSS decisions on the consumer variant can affect supply chain decisions on the commercial one.
Forthcoming UK regulation expected in 2026 — telegraphed in the DSIT policy consultation on "Software Security and Resilience" that closed May 2024 — will extend similar obligations to a broader scope of software products, aligning the UK more closely with the EU CRA timeline.
How Safeguard.sh Helps
Safeguard.sh gives IoT and software vendors the operational backbone PSTI enforcement assumes. Eagle detection inspects firmware images, device SBOMs, and ODM-supplied artifacts for default credentials, unpatched CVEs, and support-window drift, flagging the exact conditions that have triggered OPSS compliance notices. The analysis runs continuously against a device's firmware lineage, which matters because ODM updates rarely reach brand owners unless it is automated.
The zero-day pipeline monitors vendor PSIRT feeds, the CISA ICS advisories, and exploit broker activity for IoT-relevant components — Realtek SDK, MediaTek reference, hostapd, common RTOS stacks — and alerts product teams before a public disclosure becomes a PSTI compliance event. SBOM lineage follows a chipset or library through every product in the portfolio, so a single upstream fix can be propagated consistently.
For TPRM, Safeguard.sh monitors ODM and chipset vendors as first-class suppliers, tracking their disclosure policies, support windows, and firmware release cadence — the same dimensions OPSS inspects. Lino compliance mapping translates PSTI Section 9 obligations, ETSI EN 303 645 provisions, and the anticipated CRA essential requirements into concrete engineering controls and evidence. Griffin AI remediation proposes firmware change sets, disclosure policy updates, and Statement of Compliance revisions that satisfy OPSS expectations without guesswork.