PSTI Act

Expanded Definition

The PSTI Act is a UK product security law that sets baseline expectations for consumer connected products placed on the market, especially internet-connected devices that are likely to be used by individuals rather than specialist operators. Its practical purpose is to reduce avoidable compromise by making insecure defaults less acceptable and by pushing manufacturers to disclose how long security updates will be provided.

Although it is often discussed alongside broader IoT security guidance, the Act is narrower and more operational: it targets product design choices that create widespread, preventable risk, such as weak or universal default passwords, poor vulnerability reporting channels, and unclear update commitments. For security teams, that makes it less a general cybersecurity framework and more a product compliance requirement that should be reflected in secure development, supplier assurance, and release governance. The baseline logic is consistent with control thinking found in NIST SP 800-53 Rev 5 Security and Privacy Controls, even though the legal obligations themselves are UK-specific.

Definitions vary across vendors when they try to package the PSTI Act as an IoT certification label, but no single standard governs this yet. The most common misapplication is treating it as a one-time legal checkbox, which occurs when organisations fail to operationalise secure defaults and update transparency across the full product lifecycle.

Examples and Use Cases

Implementing PSTI Act requirements rigorously often introduces product and documentation overhead, requiring organisations to weigh faster shipment against stronger assurance, clearer disclosures, and better vulnerability handling.

• A consumer smart camera ships with a unique password or mandatory first-time password change, rather than a factory default that can be guessed or reused at scale.
• A connected home hub includes a public vulnerability disclosure route so researchers and customers know how to report weaknesses responsibly.
• A device listing states the minimum security update period, helping buyers understand whether support ends in months or years.
• A manufacturer reviews supplier firmware practices to ensure embedded components do not reintroduce insecure defaults into the final product.
• A compliance team maps product documentation and release notes against UK market requirements and internal assurance gates, rather than leaving security claims to marketing copy.

These patterns overlap with broader product security expectations in NIST product security guidance and the operational discipline behind secure configuration and vulnerability handling. They are especially relevant where IoT devices feed into homes, workplaces, or critical service environments, because weak product governance can create downstream risk long after sale.

Why It Matters for Security Teams

The PSTI Act matters because consumer IoT insecurity is often created before deployment, then persists through manufacturing, distribution, and support. For security teams, the challenge is not only avoiding non-compliance but preventing insecure product choices from becoming permanent attack paths. Weak password handling, absent disclosure routes, and vague update promises all increase the likelihood that devices will be targeted once they are online and at scale.

That has direct implications for governance, procurement, and incident readiness. Security teams need visibility into which products are in scope, how suppliers implement baseline controls, and whether update commitments are technically and contractually enforceable. The Act also reinforces the value of evidence-based product assurance rather than trust-based claims. That thinking aligns with the device-security principles often reflected in UK NCSC device security guidance and with vulnerability disclosure practices described by IETF vulnerability disclosure work.

Organisations typically encounter the real impact only after a device fleet is exposed to mass exploitation or support obligations become impossible to meet, at which point the PSTI Act becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams prove DORA compliance for AI agents that act autonomously?
• How should organisations prove EU AI Act compliance across the AI lifecycle?
• How should security teams govern AI assistants that can act inside IAM systems?
• How should security teams govern MCP-enabled AI assistants that can act on tools and data?