UK PSTI Product Security PSTI vs ETSI EN 303 645

PSTI: define the exact products, services, processing, claims, entities, assets, or activities that bring this side into scope; record out-of-scope facts separately.

ETSI EN 303 645: test its own scope boundary, exclusions, and covered activity; do not copy the PSTI conclusion without a separate source-linked finding.

Write two scope findings first: where PSTI applies, where ETSI EN 303 645 applies, and which facts are outside one side even if evidence can be reused.

PSTI: identify whether the duty sits with the manufacturer, importer, distributor, or authorised representative, and record which supply-chain role can change the product, statement of compliance, vulnerability-disclosure channel, password control, or support-period information.

ETSI EN 303 645: assign the comparator duty to its own accountable actor and note when counterparties, subsidiaries, importers, providers, or customers differ.

Name each role separately because one entity can hold different obligations in different workflows.

PSTI: state the fact that starts the obligation, such as market placement, processing, designation, incident, reporting period, transfer, data request, supplier change, or public claim.

ETSI EN 303 645 is a voluntary consumer IoT baseline standard, so use it as a control and evidence comparator rather than treating it as a legal trigger with statutory thresholds or supervisory notices.

Start with the trigger so teams do not apply the wrong regime to the wrong facts.

The UK PSTI Act mandates three baseline security requirements for all connectable products: no universal default passwords, a published vulnerability disclosure policy, and a declared minimum security update period - each enforced by OPSS under the PSTI regime.

ETSI EN 303 645 defines 13 provisions covering no universal default passwords, a vulnerability disclosure policy, software update mechanisms, secure storage of sensitive parameters, minimized attack surface, security communications, minimized exposed attack surface, software integrity, personal data protection, resilience, telemetry examination, deletion of user data, and easy device installation.

Translate obligations into tickets, notices, records, controls, or contract terms.

PSTI: keep the evidence that proves this side of the decision, including cited text, registers, policies, test records, contracts, notices, reports, approvals, or audit artifacts.

ETSI EN 303 645: keep comparator evidence in a distinct record set and link only the artifacts that genuinely satisfy both source-linked requirements.

Keep source links, factual analysis, owner approval, and implementation evidence together.

PSTI: capture the application date, commencement date, transition period, reporting clock, review cadence, remediation window, or certification renewal that controls this side.

ETSI EN 303 645: track the comparator schedule separately so a later deadline, recurring audit, or incident timer is not hidden by the other workstream.

Use current source dates; do not reuse old project plans after amendments or guidance updates.

PSTI: identify the competent authority, regulator, assessor, customer audit, certification body, contractual remedy, penalty, or supervisory process tied to this side.

ETSI EN 303 645: identify the comparator enforcement or assurance route and record where supervision, penalties, market access, certification, or contract leverage differs.

Escalate when enforcement routes differ because a regulator, market-surveillance authority, certification body, customer, or contract counterparty may require different proof.

PSTI: reuse controls only where the source-linked duty, evidence standard, owner, and timing align with the comparator; otherwise keep a bridge note.

ETSI EN 303 645 can reuse evidence from the other side only when the same fact pattern, system boundary, control, owner, and source-linked requirement are genuinely aligned.

Document overlap explicitly instead of merging both tests into one vague compliance label.

PSTI: treat this as the controlling workstream when its scope trigger, deadline, regulator, or required artifact is the immediate blocker.

ETSI EN 303 645: run a parallel or follow-on workstream when this side adds separate actors, evidence, timing, penalties, customer assurances, or implementation constraints.

Choose one practical next step: proceed under PSTI, proceed under ETSI EN 303 645, run both in parallel, or document why neither side controls the present fact pattern.