PSTI compliance: which connected-product launch is carrying hidden security debt?

A connected device can pass its functional tests, reach a UK distributor and still be missing the security evidence needed to support its sale. Since 29 April 2024, the UK Product Security regime has imposed baseline requirements on relevant consumer connectable products and duties across manufacturers, importers and distributors. The commercial gap is rarely “cybersecurity” in the abstract. It is a specific product family whose default credentials, vulnerability-reporting route, security-update period or statement of compliance cannot survive a release review. That makes the first purchase concrete: test one SKU family and decide whether it is ready, conditionally ready or blocked. This reading explains how to identify the responsible economic actor, build a product-security evidence pack and create an ongoing support-period service. It also shows how acquisition can reach businesses with a live launch or distribution trigger without claiming that a checklist makes a device secure or guarantees regulatory acceptance.

The Product Security regime covers relevant internet-connectable and network-connectable products made available to UK consumers, subject to statutory exclusions and special cases. Scope depends on connectivity, intended use, customer and product configuration. A product name, tariff code or “professional” label alone cannot establish whether a particular model or bundle is in scope.

A boundary file should describe hardware, software, radio or network functions, intended customer, bundled components and route to market. Variants matter: a non-connected model and its app-enabled sibling may need different conclusions. Uncertainty remains visible until legal or technical ownership resolves it.

Manufacturers carry the core security-requirement and statement duties; importers and distributors must check required documentation and act where they know or ought to know that a product is non-compliant. The statutory role follows what the business actually does, including branding and supply-chain control, rather than the title printed in a commercial agreement.

One company can hold different roles across product lines. The release file therefore maps the brand owner, designer, factory, UK importer, marketplace seller and distributor for each family. Contracts allocate evidence and cooperation, but cannot erase duties created by the real supply chain.

The baseline requirements address passwords, vulnerability reporting and security updates. Products must not use universal or easily guessable default passwords; manufacturers must publish a route for security-problem reports; and they must publish the minimum period for which security updates will be provided. Each requirement needs product-specific evidence, not a policy statement detached from the shipped build.

Testing should follow activation, reset, recovery, refurbished-device and support states. The vulnerability route must reach a team able to acknowledge and act. The published support period must reconcile with engineering capacity, packaging, web copy and distributor data.

A paid PSTI sprint should define scope and economic roles, test the three baseline controls, reconcile the statement of compliance with the shipped model and issue a release decision with remediation owners. It should focus on one SKU family or launch wave, avoiding an open-ended security programme that buyers cannot price or approve quickly.

The partner begins with product samples, firmware and support information, not a generic questionnaire. It records missing evidence, tests high-consequence states and distinguishes a document correction from engineering work. Where specialist legal interpretation or penetration testing is required, that dependency is named before the product is presented as ready.

A statement of compliance identifies the product and manufacturer, confirms compliance with the applicable security requirements, records the relevant support period and includes prescribed signatory and date information. It must accompany the product as required and match the version being supplied. A reusable template is useful only when its underlying evidence remains accurate.

The statement index links model identifier, hardware revision, firmware baseline, evidence owner, approval date and distribution markets. A material change should trigger reassessment rather than silent reuse. This gives sales teams a precise answer when a retailer or importer requests assurance.

A vulnerability-reporting route should tell researchers where to report, acknowledge receipt and provide status information while the manufacturer triages, reproduces, prioritises and remedies the issue. A published mailbox with no owner or response process does not create useful handling. Sensitive details also need controlled disclosure throughout investigation and release.

The recurring service can maintain the queue, evidence response times, coordinate product and support teams, and confirm that public information remains available. Its value rises with the number of models and software branches because each unresolved report can expose multiple shipments and distributors.

The published minimum security-update period shapes both compliance evidence and the customer proposition. It must reflect how long the manufacturer can support the product, distribute fixes and maintain relevant components. Marketing a longer period without engineering capacity creates debt; publishing a short period can weaken retailer confidence and product differentiation.

The decision belongs across product, security, finance and sales. Bill-of-material dependencies, third-party components, signing infrastructure and update delivery all affect the promise. A portfolio review can expose products whose published commitment has no funded operating plan.

OPSS supervises the regime and can investigate product-security failures. In its 2024–25 delivery report, OPSS said it assessed 82 connected devices and found varying non-compliance in 75% of those within scope. That is a targeted official sample, not a market-wide failure rate, but it shows why model-level evidence deserves executive attention.

The strongest proposition avoids penalty theatre. It uses the official sample to open a practical conversation about the client’s own portfolio, then proves value through a release decision, remediation plan and maintained evidence rather than a broad claim about the whole sector.

The best prospects have a near-term UK launch, imported connected products, multiple firmware branches, retailer diligence, a private-label change or a known evidence gap. A manufacturer needs engineering depth; an importer may need supplier evidence and role clarity; a distributor may need scalable checks across a catalogue. Their buying questions and offers should differ.

Search captures rule and statement questions. Trade networks, product-development partners, retailers, events, telephone, email and target-account outreach reveal shipment and launch timing. The qualification call must establish the actual product, actor role, evidence access and decision owner before offering technical work.

The offer is ready when the partner can identify its economic-actor audience, assess one bounded product family, refer specialist testing or legal questions and maintain security-support evidence within capacity. GetFishNet’s free eligibility test checks the trigger, proof, delivery model and channel economics before recommending a campaign.

The commercial promise should remain narrow: create a product-level decision and a durable control system. It must never imply that compliance prevents every vulnerability, that a statement guarantees enforcement immunity or that an importer can outsource all responsibility to the overseas factory.

Authorities cited: UK Legislation; Office for Product Safety and Standards; Department for Science, Innovation and Technology. Dated references remain in the private source register.