PSTI Act

What the PSTI Act Covers

The PSTI Act is a product security law, so the core subject is not general cybersecurity policy but the security baseline that consumer connected products must meet before and after sale. It is aimed at reducing avoidable risk in everyday IoT devices by making insecure defaults, poor disclosure and weak support practices harder to ship.

That makes the Act important because many consumer products are deployed with little user expertise and long-lived connectivity. If the baseline is weak, the product can become an easy entry point for botnets, privacy loss, nuisance access or wider home-network compromise.

Baseline Security Requirements in Practice

The Act’s practical significance is that it turns a small set of security expectations into market-entry obligations. In practice, manufacturers and importers need to think about how passwords are handled, how vulnerabilities will be reported, and what information a buyer can rely on about updates and support.

Those requirements matter because connected products are often mass-produced and hard to remediate once deployed. A weak default credential model, no clear update period, or no defined vulnerability contact path creates risk at scale, not just for one device but for the installed base.

For a deeper explanation of how the UK regime is structured and what compliance evidence usually looks like, see the UK PSTI Act Guide and the UK PSTI Act Product Security Guide.

Why PSTI Matters for Consumer IoT Security

PSTI is significant because consumer IoT failures are often mundane but consequential: reused passwords, opaque update support, and no credible vulnerability disclosure process. Those gaps are exactly the kind that let attackers compromise devices at scale or keep exploiting products after they have been sold.

The law also pushes the market toward secure-by-design expectations rather than relying on post-sale consumer action. That is especially important for devices that are hard to patch, hard to monitor, or deployed in homes and small offices where security administration is minimal.

NHIMG’s Smart Home Security Guide and Device and IoT Identity Guide show how product security expectations connect to device onboarding, trust and lifecycle control.

How PSTI Connects to Related Product Security Regimes

The PSTI Act sits alongside a broader international move toward product security regulation, including rules and guidance that also emphasise secure defaults, updateability and vulnerability handling. For organisations selling into multiple markets, the issue is less about one statute and more about aligning product engineering, compliance evidence and support processes across jurisdictions.

That is why practitioners often map PSTI alongside related product-security baselines rather than treating it as an isolated legal checkbox. The main operational question becomes whether product controls, statements and support promises are consistent across development, procurement and post-sale service.

NHIMG’s Security by Design and by Default Guide and Product Security Laws Map are useful starting points when comparing PSTI with other product-security regimes.

Risk and Threat Considerations

Poor PSTI implementation leaves a predictable attack surface: default credentials, weak disclosure, and unclear support windows all make exploitation cheaper for attackers and remediation slower for defenders. The risk is not only initial compromise, but persistence after sale when vulnerable devices remain in use without a clear path to fix them.

Failure mechanism: If a vendor ships insecure defaults or vague update commitments, attackers can mass-target exposed devices, then retain access because users cannot easily harden, patch, or report issues in time.

Impact: The result can be device takeover, botnet enrolment, privacy exposure, and downstream compromise of the local network or any service that trusts the device.

Practitioner Guidance

Why practitioners should care: PSTI is a product-design and product-support obligation, not just a legal text. Security teams, product owners and compliance functions need a shared view of what the product promises to customers and what evidence supports that promise.

Governance implication: Treat the Act as a lifecycle requirement that reaches design, manufacturing, packaging, support and vulnerability handling. If a product cannot meet the baseline cleanly, the issue is usually architectural or operational, not just documentation.

Practitioner takeaway: The strongest PSTI programmes make secure defaults, update disclosure and vulnerability contact points part of the product’s normal operating model, not a late-stage compliance add-on.

Related resources from NHI Mgmt Group

• How does the UK PSTI Act work?
• How do organisations implement the UK PSTI Act?
• Why does UK PSTI Act matter for security teams?
• How should security teams prove DORA compliance for AI agents that act autonomously?