How do organisations implement the UK PSTI Act?

What the PSTI Act requires organisations to do first

The practical starting point is to treat the UK psti act as a product-security baseline, not a documentation exercise. Organisations need to confirm that connected products sold into the UK are designed to avoid common consumer IoT weaknesses, then prove that those requirements are met before launch and remain supported after sale. That usually means aligning engineering, legal, supplier, and customer-support teams around one evidence set.

For most organisations, the first implementation gap is not technology, it is ownership. If product security, procurement, and support teams each hold different assumptions about what is required, compliance becomes inconsistent across product lines and suppliers. A useful operational model is to map every connected product to a responsible owner, a security requirements checklist, and a support commitment that can be shown to a regulator or customer.

How to build PSTI compliance into product and supplier workflows

Implementation works best when the baseline controls are embedded into design, procurement, release, and support processes. The direct answer already points to the core obligations: remove default passwords, publish a vulnerability disclosure contact, state update support periods clearly, and retain evidence that products and suppliers meet those obligations for the UK market.

That evidence should be collected as part of normal product governance, not reconstructed after launch. Organisations usually need product-level declarations, supplier attestations, release approvals, and support-life records that show the security baseline was checked before the product entered the UK market and will continue to be checked during its supported life.

• Build the PSTI requirements into product approval gates so a release cannot proceed without security sign-off.
• Make supplier onboarding prove the same baseline requirements, especially where firmware, remote services, or embedded components are outsourced.
• Keep a single support-period record per product family so customer-facing claims, engineering reality, and legal commitments stay aligned.

For consumer IoT, the useful lens is device trust and lifecycle control, which is why NHIMG’s Device and IoT Identity Guide is relevant when teams need a practical model for onboarding, default-password bans, certificates, and device trust. Where teams need a broader view of the regulatory landscape, the Global Cybersecurity Regulatory Map helps place the PSTI Act alongside other market-specific obligations.

What good PSTI evidence looks like in practice

Good implementation is measurable. A compliant organisation can point to the exact products in scope, the specific baseline controls applied, the date those controls were approved, and the support period promised to customers. It can also show where vulnerability reporting is published and who internally owns intake, triage, and remediation.

The common mistake is to treat this as a one-time launch checklist. PSTI obligations are lifecycle obligations, so evidence must survive product changes, supplier changes, firmware updates, and end-of-support decisions. If a product is still sold or still supported, the organisation should be able to explain how it remains covered by the baseline and who checks that promise is still true.

For teams that want to compare UK obligations with other jurisdictions, the NCSC UK Advice and Guidance is a useful anchor for UK-facing security expectations, and the ISO/IEC 27002:2022 Information Security Controls provides a broader control-implementation reference for governance, supplier management, and secure configuration.

Practitioner Guidance

What to verify: Check that every connected product sold into the UK has a named owner, a current support period, a published vulnerability disclosure route, and a documented position on default credentials before it is offered for sale.

What to prioritise: Start with the products that have the broadest market exposure, the longest support tail, or the least mature supplier chain, because those are the places where missing evidence usually creates the biggest compliance gap.

Decision rule: If the product cannot be traced to a clear support commitment and a maintained security baseline, treat it as not ready for UK release, even if the engineering team believes the technical fix is straightforward.

Practitioner takeaway: PSTI implementation succeeds when compliance is built into product governance and supplier control, not added as a final check after the product is already in market.

Related resources from NHI Mgmt Group

• Guide: IoT Security Guide
• How do organisations implement the UK Online Safety Act?
• How do organisations implement UK Telecoms Security Act?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?