Establish scope before choosing a support commitment

As checked on 23 October 2026, the UK's consumer connectable product security regime has applied since 29 April 2024. Official guidance identifies requirements concerning passwords, security-issue reporting and security-update support information, alongside different duties for manufacturers, importers and distributors. Exclusions exist: a Bluetooth connection or an internet feature alone is not a sufficient product-specific legal assessment. Official UK guidance

Outsourcing manufacture does not necessarily leave all responsibility with the factory. The guidance's manufacturer description includes marketing another person's manufactured product under one's own name or trademark. A Hong Kong brand using Shenzhen engineering and a contract manufacturer should have the relevant business roles assessed before allocating documentation and support budgets.

This article addresses information handover. It is not a determination of market access, warranty liability or an individual product's legal position. Addressing support-period information does not establish compliance with the entire regime.

Make the period understandable without a technical background

Schedule 1, paragraph 3 addresses support-period information for relevant hardware and software capable of receiving security updates. Publication must be accessible in English without a prior request, payment or provision of personal information. A published period cannot subsequently be shortened; an extended period must be published as soon as practicable. Current Schedule 1

The government's regime explanation calls for the minimum length of support and an end date. Phrases such as long-term support or ongoing OTA do not provide a usable timetable. Nor should a team simply copy an unrelated repair or subscription date. This guide does not prescribe a legally sufficient number of years for a particular model or impose one period on every smart product. Government explanation

Keep three commitments separate

The following is an editorial working table, not a regulator's prescribed form.

Commitment Question to resolve Evidence to retain
Repair and warranty Which faults, parts and services are covered? Applicable terms, service workflow and accountable owner
Cloud or application service Which accounts, interfaces and subscriptions does use depend on? Service description, supplier arrangements and customer communications
Security updates Which model and related software are supported until which date? Published policy, version mapping, maintenance owner and supplier evidence

Separating these records helps prevent a sales promise from exceeding the team's operational capacity. It does not imply that the arrangements are unrelated. For a cloud-dependent product, downloadable firmware alone may not preserve every function a customer expects.

Ask suppliers for maintenance evidence

The UK National Cyber Security Centre's device principles address third-party components' security-support lifetimes and secure verification of updates. These are technical principles, not a substitute for a product-specific assessment of the legislation. NCSC update principles

A useful supplier discussion asks who takes responsibility when a module reaches the end of support, which repository and signing process a fix needs, and who determines whether an older batch is affected. The actual technical owner should answer these questions. A marketing team should not turn a supplier's claim that OTA is supported into a consumer-facing support period without further evidence.

The SBOM and open-source handover guide can help organize software information. An inventory does not itself obtain patches, modification rights or continuing maintenance from third parties.

Connect the sales page, product batch and statement

Schedule 4 requires the statement of compliance to identify matters including the product type and batch, manufacturer information and the support period that was correct when the manufacturer first supplied the product. Official guidance also explains that the statement must accompany the product; a digital format does not remove the relevant businesses' responsibilities. Schedule 4

An internal mapping can connect the model, hardware revision, sales territory, support-policy version, statement version and approver. When a module or software foundation changes, do not automatically reuse the previous batch's entire information pack. Assess its effect on the commitment and documents, then have the responsible business decide what needs changing.

The output is traceability, not a new self-created UK certification mark.

Coordinate the Hong Kong and Shenzhen work

One possible division of work is for the market-facing team to own English communications, engineering to verify versions and maintainability, supply-chain staff to obtain third-party support evidence, and the relevant UK-market business to seek professional advice on obligations. This is an editorial suggestion, not a claim about any exhibitor's existing process.

For a discussion with Jimhang Capital, a non-confidential page can outline the product, intended market, update dependencies, proposed commitments and unresolved technical or professional questions. That makes a cross-border conversation more concrete without treating exhibition interest as proof of readiness to supply a product legally.

Start with one support-period review

Bring existing warranty wording, application and cloud-service descriptions, component support information and the English sales page. Resolve which product each promise concerns, who supplies the evidence and which documents need coordinated versions before sales.

Sources were checked on 23 October 2026. Obtain appropriate professional advice for product scope, law and contract questions. Use the existing Jimhang Capital contact information or justin@jimscapital.cn for a discussion; do not include private source code or customer records in an initial introduction.