UK Product Security and Telecommunications Infrastructure Act: Software Implications

The UK's Product Security and Telecommunications Infrastructure Act 2022 (PSTI Act) came into force on April 29, 2024, making the UK one of the first countries to impose mandatory cybersecurity requirements on consumer connectable products. While the headlines focused on banning default passwords, the Act has deeper implications for software supply chain security.

If you manufacture, import, or distribute connected products in the UK—or if your software runs on such products—the PSTI Act is now your compliance reality.

What the PSTI Act Requires

The Act establishes three core security requirements for consumer connectable products:

1. No Universal Default Passwords

Products must not use universal default passwords. Each device must either have a unique password or require the user to set a password before use. Passwords must not be resettable to a universal factory default.

This sounds basic—and it is. The fact that legislation was needed to eliminate default passwords tells you something about the state of IoT security. But the enforcement mechanism gives it teeth: products that don't comply cannot be legally sold in the UK.

2. Vulnerability Disclosure Policy

Manufacturers must provide a public point of contact for reporting security vulnerabilities. They must also provide information about the timelines within which reports will be acknowledged and status updates provided.

For software supply chain security, this is significant. If your software contains third-party components with vulnerabilities, you need a process for receiving, triaging, and communicating about those vulnerabilities. This includes vulnerabilities discovered in your dependencies, not just your own code.

3. Transparency on Security Updates

Manufacturers must publish, at the point of sale, the minimum period during which the product will receive security updates. This information must be accessible and understandable by consumers.

This requirement has a ripple effect through the software supply chain. If a manufacturer commits to providing security updates for five years, they need confidence that their software supply chain will support that commitment. That means:

• Dependencies must be maintained for the product's supported lifetime
• Vulnerability monitoring must be continuous, not periodic
• The ability to update or replace components must be maintained

Beyond the Three Requirements

While the mandatory requirements are focused on the three areas above, the PSTI Act and associated guidance signal broader expectations:

Secure development practices. The UK government's Code of Practice for Consumer IoT Security (which informed the PSTI Act) includes 13 guidelines, of which the three above were selected for mandatory compliance. The remaining ten—including monitoring system telemetry, validating input data, and ensuring software integrity—represent the direction of travel.

ETSI EN 303 645. The PSTI Act aligns with this European standard for consumer IoT security. ETSI EN 303 645 includes provisions for:

• Keeping software updated
• Securely storing credentials and security-sensitive data
• Minimizing exposed attack surfaces
• Ensuring software integrity
• Protecting personal data

Organizations that align with ETSI EN 303 645 will be well-positioned for PSTI compliance and for likely future expansions of the mandatory requirements.

Enforcement

The Office for Product Safety and Standards (OPSS) enforces the PSTI Act. Enforcement powers include:

• Compliance notices — requiring manufacturers to take specific actions
• Stop notices — prohibiting the sale of non-compliant products
• Recall notices — requiring recall of products already on the market
• Fines — up to 10 million pounds or 4% of worldwide revenue, whichever is greater

These penalties are modeled on GDPR enforcement levels, signaling that the UK government takes product security seriously.

Software Supply Chain Implications

The PSTI Act creates several supply chain pressures:

Component lifecycle management. If you're committing to provide security updates for a defined period, you need to know what components are in your product, whether they're still maintained, and what the plan is if a component reaches end-of-life before your product does.

Vulnerability monitoring. Continuous monitoring of all software components—including transitive dependencies—is necessary to fulfill the security update commitment. You can't patch what you don't know about.

SBOM maintenance. While the PSTI Act doesn't explicitly mandate SBOMs, maintaining one is the only practical way to manage the transparency and update requirements. You need to know what's in your product to know what needs updating.

Supplier agreements. Manufacturers need agreements with their software suppliers that support their PSTI obligations. This includes notification of vulnerabilities, availability of patches, and end-of-life timelines.

Open-source risk. Connected products frequently rely on open-source components. The PSTI Act's security update commitment means manufacturers need to assess whether open-source components will continue to receive security updates for the product's supported lifetime.

Who Is Affected

The Act applies to three categories of economic actors:

• Manufacturers — including companies that design and build products, as well as companies that rebrand products
• Importers — companies that bring products into the UK market
• Distributors — retailers and other entities in the distribution chain

Each has specific obligations under the Act. Manufacturers bear the primary compliance burden, but importers and distributors must verify compliance before placing products on the market.

For software vendors, even if you're not directly subject to the PSTI Act, your customers who manufacture connected products will flow requirements down to you. Expect increasing requests for:

• Vulnerability disclosure processes and timelines
• Security update commitments and timelines
• Component inventories and SBOMs
• Evidence of secure development practices

Practical Steps

For organizations affected by the PSTI Act:

1. Audit your connected products. Identify which products fall within the PSTI Act's scope and assess current compliance against the three mandatory requirements.

2. Establish vulnerability disclosure. If you don't have a public vulnerability reporting process, create one now. Include clear timelines for acknowledgment and response.

3. Define security update periods. Determine and publish the minimum period for which you'll provide security updates. Ensure your supply chain can support this commitment.

4. Build your SBOM practice. Generate and maintain SBOMs for all connected products. This is the foundation for meeting your transparency and update obligations.

5. Review supplier agreements. Ensure your software suppliers provide vulnerability notifications, security updates, and end-of-life timelines that align with your PSTI obligations.

How Safeguard.sh Helps

Safeguard.sh gives connected product manufacturers the software supply chain visibility the PSTI Act demands. The platform tracks every component in your product, monitors for vulnerabilities across the full dependency tree, and alerts you when action is needed—supporting the security update commitments you publish at point of sale. With automated SBOM generation and lifecycle tracking, Safeguard.sh helps manufacturers fulfill their PSTI obligations while managing the underlying complexity of modern software supply chains.