Introduction
For UK-bound connected consumer products, the Product Security and Telecommunications Infrastructure regime makes product security a sourcing input rather than an after-launch software task. A buyer should determine whether the exact product is in scope, identify the statutory manufacturer and other roles, address the three baseline security requirements, define the security-update period and vulnerability-reporting route, and make sure a compliant Statement of Compliance accompanies the product.
This UK PSTI importer checklist for connected products provides an operational framework. It does not assign your legal role or confirm conformity. A private-label brand owner can be the statutory manufacturer even when a separate Chinese factory physically makes the product, so the real supply-chain and trademark arrangement must be reviewed.
Confirm Whether the Finished Product Is in Scope
The GOV.UK consumer connectable product security guidance explains the UK regime, which came into effect on 29 April 2024. It applies to relevant connectable products made available to UK consumers, subject to exclusions and detailed definitions.
Begin with functions, not marketing names. Record whether the product can connect to the internet or a network, directly or indirectly; its radio and wired interfaces; companion app or cloud dependency; user accounts; local administration; supplied gateway or hub; intended consumer use; and markets. Include the exact hardware and firmware version.
Some product categories or configurations are excluded or governed differently. Do not infer scope merely because a device has Bluetooth or because another supplier calls it “smart.” Have a competent reviewer compare the finished configuration with the official definitions and exclusions.
A smart pet feeder camera, air quality monitor kit or smart pet doorbell can illustrate connected-product sourcing questions, but each linked page is an enquiry route, not a claim of PSTI scope or compliance.
Manufacturer Is a Statutory Role, Not Factory Shorthand
Under the PSTI framework, “manufacturer” is not simply the physical plant assembling the device. Official guidance includes a person who has a product designed or manufactured and markets it under that person’s own name or trademark, and a person who markets another person’s product under its own name or trademark. A private-label buyer may therefore occupy the statutory manufacturer role depending on the actual arrangement.
Map at least four participants: brand owner, design or firmware owner, physical factory, UK importer and distributor. Record who controls the name or trademark, who sets security requirements, who can change firmware, who publishes update information, who receives vulnerability reports and who holds the technical records.
The PSTI Act 2022 establishes duties across the regime. Manufacturer, importer and distributor duties differ, and none should be allocated from a generic purchase-order label. Ask qualified UK counsel or a competent adviser to review the contracts and actual placing-on-market route.
Address the Three Baseline Security Requirements
The Security Requirements for Relevant Connectable Products Regulations 2023 set the baseline requirements. The sourcing brief should address passwords, vulnerability reporting and security-update information for the exact model.
1. Do Not Rely on Universal or Easily Guessable Default Passwords
Document account creation, device setup, reset behavior, service credentials, local interfaces and any password supplied with the product. The factory should explain how credentials are generated or assigned and whether any shared engineering credential remains in production firmware.
Test the production-representative setup flow. A visual check of the package cannot verify credential architecture. Security engineers should define tests and review firmware or system behavior where appropriate. Remove development accounts and record the production configuration.
2. Publish a Vulnerability-Reporting Route
Identify the person responsible for receiving reports, the contact mechanism, the information needed from a reporter and expected acknowledgement or status communication. Make the route accessible without forcing researchers to use a consumer returns form.
The factory can supply technical contacts and triage information, but the statutory manufacturer needs a durable public process. If the app, cloud service or firmware is supplied by a third party, contracts should state who investigates and who communicates. Test the route before launch.
3. State the Minimum Security-Update Period
The minimum period for security updates must be published in a clear, accessible way and stated as required. Decide the period before the purchase order because it affects component availability, firmware ownership, cloud maintenance and commercial support.
Do not use “lifetime updates” unless the responsible business has defined and can support that promise. Record the start and end point, product variants covered, publication location, update delivery method and dependencies. A factory promise to “support when needed” is not a controlled period.
Build a Supplier Security Information Request
Ask for a model-specific architecture summary: chipset and module, network interfaces, firmware owner and version, mobile app and cloud provider, account and authentication flow, update mechanism, encryption or key-management description at an appropriate level, open-source component process, reset and end-of-support behavior, development access removal, vulnerability contact and known support dependencies.
This request is not a demand for passwords, private keys or other sensitive secrets. Store security records with limited access. Ask for enough information so the responsible specialists can evaluate the product and maintain it, while keeping operational credentials protected.
Create an issue register with severity, affected model and version, owner, target action and release decision. The factory, software provider and brand owner need one controlled version of the release status.
The Statement of Compliance Must Accompany the Product
For an in-scope product, the official guidance says the manufacturer, importer and distributor must ultimately ensure that a Statement of Compliance accompanies the product and meets statutory requirements. Do not treat the document as a factory certificate or assume only the importer needs to care.
The Regulations specify required contents and retention periods. Have the responsible reviewer approve the statement for the exact product and business roles. Align product type, batch or serial references, manufacturer details, applicable security requirements, support-period information, signatory and date as required.
Decide how the statement will accompany the product—for example in the package or through another permitted mechanism reviewed for the actual arrangement—and how it will remain accessible. The artwork and document process should prevent an old statement being packed with a new firmware or brand-owner revision.
A Pre-PO PSTI Sourcing Checklist
- Describe the exact connected product, interfaces, app, cloud and intended consumer use.
- Confirm scope and exclusions with a competent reviewer.
- Map statutory manufacturer, importer and distributor roles from the real arrangement.
- Lock the password, vulnerability-reporting and security-update requirements.
- Obtain model-specific hardware, firmware and support information.
- Define security evaluation, remediation and release ownership.
- Approve the Statement of Compliance and how it accompanies the product.
- Align packaging, instructions, listing and support pages.
- Require written notice for hardware, firmware, app, cloud or ownership changes.
- Verify the released production configuration before shipment.
Place unresolved items on a no-ship or no-launch list according to their risk and the responsible reviewer’s decision. Do not hide them in informal chat messages.
Mid-Article CTA
Send Your Connected-Product Requirements. Browse KudBo products and email info@kudbo.com with your UK sales plan, product functions, connectivity, firmware ownership, quantity, packaging and support requirements. KudBo can coordinate samples, factory data, artwork and release records for your security and legal reviewers.
Sampling and Security Evaluation
Use a production-representative sample with final hardware, firmware, app version and backend environment. Label it with model, revision and date. A prototype running a developer build can support early evaluation, but it should not be the only evidence for the released product.
Prepare installation steps, account creation, network setup, password behavior, update process, reset, loss of service and decommissioning for review. If a product depends on a third-party cloud, state what the evaluator can and cannot test. Keep findings linked to a corrected firmware build and retest record.
Factory functional testing can confirm that a sampled device powers on, connects under the agreed setup and reports the intended firmware. It cannot prove that the architecture meets every security requirement. Independent security testing, technical assessment and legal review have different purposes; the evidence pack should identify each.
Control Firmware and Service Changes
A casing change is visible. A firmware library, server endpoint or credential change may not be. Require advance notification for chipset, radio module, memory, firmware, mobile app, cloud service, update mechanism, security library, certificate handling, manufacturing test mode, brand ownership and support-contact changes.
The change request should describe the old and new version, reason, security impact, affected inventory, migration plan, evidence required and rollback or support implications. Use signed or otherwise controlled release artifacts and preserve version identifiers that customer service can retrieve.
Do not assume a successful sample approval covers future reorders. Reconfirm the production firmware and service dependencies before every PO, especially after a long gap or component shortage.
Packaging, Manuals and Online Listings
Customer-facing material must match the supported product. Explain setup, account security, reset, update availability and support routes clearly enough for the intended user. Avoid absolute claims such as “unhackable,” “100% secure” or “updates forever.”
Keep the published vulnerability route and update period consistent across the website, manual, statement and support portal. If a QR code or URL is used, verify the destination before artwork release and again at shipment inspection. Plan continuity so the destination remains controlled after a packaging reprint.
For online listings, check model identity, connectivity claims, compatible systems, included items and support statements. A listing created from an engineering prototype can overpromise features that were removed before mass production.
Production and Shipment Inspection
At first-piece review, verify model identification, hardware revision, production firmware, accessories, manual, package, Statement of Compliance and support reference. Use a controlled method to read firmware version; a sticker alone may not be enough.
At shipment inspection, sample cartons across the lot and check visible identity, included materials, package revision and defined functional setup. Record devices tested, firmware shown, network environment and limitations. Do not ask inspectors to perform ad hoc penetration testing or declare PSTI compliance.
If the statement is missing, the firmware differs or the support link fails, segregate the affected stock and escalate. Corrective work needs a recheck before loading. Preserve photos without exposing credentials or personal data.
Post-Launch Readiness Begins Before Shipment
Decide who monitors the vulnerability contact, triages reports, coordinates technical fixes, signs release decisions and informs users. Maintain a secure asset register linking sold models to firmware, components, update period and support status. Ensure the brand can reach the factory or software provider after the final commercial payment.
Plan what happens when the published support period ends. Customer communication, cloud continuity, feature limitations and safe decommissioning can all affect trust. The UK National Cyber Security Centre’s device security principles provide useful broader design guidance, while the statutory requirements remain the legal baseline.
Frequently Asked Questions
Which consumer connectable products are in scope?
Scope depends on the statutory definitions, consumer use, connection capability and exclusions. Review the exact finished configuration against official guidance.
Can a private-label brand owner be the statutory manufacturer?
Yes. A person that has a product designed or manufactured and markets it under its own name or trademark can fall within the manufacturer definition. Confirm the actual arrangement.
What three baseline requirements should the sourcing brief cover?
It should address passwords, a vulnerability-reporting mechanism and publication of the minimum security-update period.
Who must ensure the Statement of Compliance accompanies the product?
Official guidance says the manufacturer, importer and distributor must ultimately ensure it accompanies the in-scope product and meets the statutory requirements.
Can the Chinese factory sign one generic statement for every brand?
Do not assume so. The statement must match the exact product and statutory roles; a private-label brand owner may itself be the manufacturer under PSTI.
Can shipment inspection prove cybersecurity compliance?
No. It can check released identity, firmware, documents and limited functions. Security and legal conclusions require appropriate specialist evaluation.
Put Security Deliverables Into Commercial Agreements
The purchase order and development agreement should identify firmware and app deliverables, release approval, access to version information, vulnerability coordination, update responsibilities, support-period inputs, component-change notification and records supplied at handover. Legal counsel should draft or review the binding terms; procurement should make sure the operational owners can actually perform them.
Avoid a clause that simply says “supplier complies with PSTI” while leaving firmware ownership and post-sale support undefined. Ask who pays for investigation and remediation, how quickly technical contacts respond, what happens if a cloud provider closes, and how the brand obtains a final firmware build if the factory relationship ends.
Define permitted security testing and confidentiality. Researchers and laboratories may need access to technical information, while production passwords, signing keys and customer data must remain protected. A clear escalation path prevents urgent reports from being sent to a dormant sales inbox.
Review a Supplier Exit Scenario
Before placing the order, simulate the loss of the current factory, app developer or cloud vendor. Can the statutory manufacturer identify deployed versions, publish support information, receive reports and provide updates through the stated period? If not, the dependency belongs in the launch decision.
Record code, key, build, server and account ownership at an appropriate level. Escrow or transition provisions may be considered with specialist advice. The buyer should not demand sensitive secrets it cannot secure, but it needs enough contractual continuity to deliver its published commitments.
This exercise also improves normal reorders. It reveals single-person contacts, undocumented build steps and third-party services that could change without notice. Resolve practical gaps before customer inventory depends on them.
At each reorder, obtain a signed or otherwise controlled release summary naming the production hardware, firmware, app, cloud endpoint, vulnerability contact and published update period. Compare it with the prior lot and list every difference, including library or service changes that do not alter the product’s appearance. The statutory manufacturer and other responsible parties can then decide which security assessment, Statement of Compliance or customer-information items need revision before the new lot is made available.
Related KudBo Resources
Browse the KudBo product catalog, explore the buyer guide library, read more Compliance & Documentation sourcing guides, or send your product requirements for a focused sourcing discussion.
Conclusion
PSTI readiness depends on accountable ownership. Classify the finished product, map the statutory roles, lock security and support decisions, issue a correct Statement of Compliance and preserve the released configuration through production and post-launch support. The physical factory is one contributor, not automatically the statutory manufacturer.
Final CTA
Request a Connected-Product Sourcing Review. Explore KudBo products, use the contact section, read the EU GPSR importer checklist and FCC wireless-product guide, then email info@kudbo.com with your model, functions, firmware, market, quantity, packaging and support requirements.