ETSI EN 303 645 vs UK PSTI

ETSI EN 303 645 covers consumer IoT devices connected to network infrastructure and their interactions with associated services; devices primarily intended for manufacturing, healthcare, or other industrial applications are outside the ETSI scope described here.

Do not infer UK PSTI scope from the ETSI consumer IoT boundary. Confirm the PSTI product scope and any excluded products from a PSTI-specific source before reusing the ETSI scope memo.

An ETSI scope record is a useful starting artifact, but the crosswalk should keep a separate PSTI scope decision with its own source citation.

ETSI TS 103 701 separates the Supplier Organization, which can be the developer, manufacturer, vendor, or distributor of the DUT, from the Test Laboratory that carries out conformance assessment.

Do not reuse the ETSI Supplier Organization or Test Laboratory labels as UK PSTI duty-holder labels. Confirm any PSTI role allocation from PSTI-specific material.

The ETSI assessment contacts can help route evidence requests, but the UK accountability row should remain open until PSTI role duties are sourced.

ETSI work starts with a consumer IoT product boundary and the provisions claimed for that product. Conditional and feature-based provisions depend on the device, mechanisms, and capabilities described in the ICS and IXIT.

Do not infer the UK PSTI trigger from an ETSI ICS status. Confirm the PSTI trigger, product status, and supply context from PSTI-specific source material.

A release gate should show two trigger facts: the ETSI provision/assessment trigger and the separately sourced UK PSTI trigger.

ETSI EN 303 645 includes baseline consumer IoT provisions for passwords, vulnerability reporting, software updates, secure storage, secure communication, attack-surface minimization, software integrity, personal-data security, resilience, telemetry, user-data deletion, installation, maintenance, and input validation.

Do not say that the UK PSTI obligations are identical to the ETSI baseline unless a PSTI source supports the exact mapping. Treat each PSTI requirement as unmapped until sourced.

Build a requirement-by-requirement crosswalk. Some ETSI controls may be reusable technical evidence, but unsupported PSTI rows should stay marked as source gaps.

ETSI evidence should include product identification, an ICS, IXIT information, public vulnerability-disclosure and support-period information where relevant, conceptual and functional test records, external evidence references, and verdicts.

UK PSTI evidence should not be declared complete from ETSI records alone. Add a PSTI source, then mark which ETSI artifacts support the UK review and which questions need new records.

Keep one matrix with columns for source, claim, artifact, product version, owner, ETSI status, PSTI status, and open source gap.

ETSI EN 303 645 uses timing concepts such as acknowledgement and status-update timelines in the vulnerability disclosure policy, timely action on vulnerabilities, timely security updates, periodic checks for updates, and a published defined support period.

Do not import those ETSI timing concepts as UK PSTI deadlines. Confirm any PSTI commencement, statement, supply, update, reporting, or enforcement clocks from PSTI-specific sources.

Separate operational security timing from legal timing. ETSI can support update and vulnerability-management evidence, but the UK PSTI schedule needs its own source.

ETSI TS 103 701 describes a conformance assessment methodology with test groups, conceptual and functional tests, external evidence, and PASS/FAIL verdicts. It also states that the document is independent from an assurance scheme.

Do not present an ETSI PASS verdict or assessment pack as proof of UK PSTI enforcement compliance unless a PSTI source or scheme explicitly accepts that evidence for the specific claim.

Use ETSI assessment results as technical assurance evidence. Keep UK PSTI enforcement, regulator, penalty, and market-access conclusions out of scope until sourced.

Reusable ETSI artifacts are strongest when they are product-versioned and traceable: ICS status, IXIT fields, password-generation evidence, vulnerability policy, update mechanism, support-period publication, user-data deletion checks, telemetry review, and interface inventory.

Reuse those artifacts for UK PSTI only after confirming the PSTI requirement, product scope, and role match. If the source gap remains, label the artifact as technical background rather than PSTI evidence.

Reuse reduces duplicate work only when the source-linked claim is the same. Otherwise, keep a bridge note explaining what the ETSI evidence does and does not prove.

Use ETSI EN 303 645 as the controlling source when the question is whether a consumer IoT product has mapped, implemented, justified, or assessed ETSI baseline provisions.

Use a PSTI-specific source as the controlling source when the question is UK legal scope, duty holder, statement wording, supply trigger, enforcement, or penalty.

The crosswalk is ready for release only when every row is labelled ETSI evidence, PSTI evidence, shared evidence, or source gap.