PSTI in Practice: Product Security Duties for Connected-Device Makers Selling into the UK

The PSTI regime does not ask you to write a policy. It asks your firmware to stop shipping a shared default password, and it makes that a legal duty attached to the device itself.

Most of what is written about the Product Security and Telecommunications Infrastructure regime treats it as a documentation exercise: produce a statement of compliance, file it, move on. That reading gets the regime backwards. The three security requirements that came into force on 29 April 2024 are engineering requirements. They constrain how a device is provisioned at manufacture, what services it exposes, and how long you commit to patching it. The statement of compliance is the paperwork at the end. If the firmware still ships with a shared default credential, the statement is a false declaration, not a shield.

This is written for the people who own the product, not the people who file the forms: the CTO of a hardware business, the firmware lead, the head of product security deciding what to build into the next revision before it goes to the UK market.

The three requirements, read as engineering

The Security Requirements for Relevant Connectable Products Regulations 2023 set out three obligations in Schedule 1. Read as a lawyer, they are three clauses. Read as an engineer, they are three changes to how you build and support a product.

1. Passwords must be unique per device or user-defined. A password that is common to a product model, or that a user can reset back to a shared factory value, is out. So is a password derived from an incremental counter or from information anyone can obtain — a MAC address, a serial number printed on the box. In practice this means a per-unit secret injected at manufacture, or a forced first-boot credential set by the user before the device becomes usable.
2. You must publish a way to report vulnerabilities. At least one point of contact, publicly accessible, plus a stated timeframe for acknowledging a report and for giving status updates. This is a live process that has to be staffed, not a mailbox nobody reads.
3. You must publish a defined support period. The minimum length of time, in clear language a non-technical buyer understands, for which the product will receive security updates. There is no floor on the number itself — but you must state it, and you must state it before sale, and it commits you.

The password requirement is where most legacy product lines fail, because a shared default is the cheapest thing to manufacture and the hardest thing to retrofit. The support-period requirement is where most firms fail on honesty: you cannot publish a five-year window and then run a two-person firmware team that cannot sustain it.

The duty attaches to the device, and to more than the manufacturer

The requirements bind the manufacturer, but the regime also puts duties on importers and distributors. An importer must not place a non-compliant product on the UK market and must ensure it is accompanied by a statement of compliance. A distributor must not supply a product it has reason to believe is non-compliant. If you are a device maker outside the UK selling through a UK importer, the importer is now contractually motivated to interrogate your firmware, because their own liability rides on your build.

The statement of compliance is defined by Schedule 4. It must identify the product and manufacturer, declare which route to compliance you took, and state the defined support period that was correct when the product was first supplied. Manufacturers and importers must keep a copy for the longer of ten years or the support period. It is a signed declaration, retained and inspectable — which is exactly why treating it as the deliverable, rather than the evidence of engineering work, is a mistake. A device maker that is simultaneously a regulated entity under other regimes will recognise the pattern from the overlap between NIS2 and the Cyber Resilience Act: the same product carries duties under several instruments at once, and the cheapest path is to build once against the strictest.

Provisioning a unique credential, and the statement that follows from it

The first requirement is the one that touches the production line. You need a per-unit secret that is generated with real entropy, tied to the device identity, and recorded so that a lawful reset restores a device-specific credential rather than a shared one. The pattern below sketches manufacture-time provisioning and the statement-of-compliance record that references the same product batch. It is deliberately minimal; the point is the shape, not the tooling.

# PSTI provisioning: generate a unique per-device credential at manufacture,
# then emit the batch's statement-of-compliance record. British spelling in comments.

#!/usr/bin/env bash
set -euo pipefail

SERIAL="$1"                 # unique per unit, not the published credential
MODEL="acme-cam-v2"
SUPPORT_UNTIL="2031-04-30"  # defined support period, committed before sale

# 32 bytes of entropy -> per-device password. NOT derived from serial/MAC,
# NOT an incremental counter, NOT publicly available information.
DEVICE_PW="$(openssl rand -base64 24)"

# Store the hash on-device; the plaintext goes to secure fulfilment only
# (e.g. printed on a per-unit label inside the box), never a shared value.
PW_HASH="$(printf '%s' "$DEVICE_PW" | openssl passwd -6 -stdin)"
printf 'admin:%s\n' "$PW_HASH" > "/provision/${SERIAL}.shadow"

# Statement-of-compliance record (Schedule 4 fields), retained 10 years
# or the support period, whichever is longer.
cat > "/soc/${SERIAL}.yaml" <<YAML
product_model: ${MODEL}
batch_serial: ${SERIAL}
manufacturer: "Acme Devices Ltd, Cyprus"
compliance_route: "security_requirements"   # or deemed via ETSI EN 303 645
defined_support_period_ends: ${SUPPORT_UNTIL}
vuln_disclosure_contact: "https://acme.example/security"
declared_on: "$(date -u +%Y-%m-%d)"
YAML

Two things in that snippet do the real work. The credential is drawn from entropy, not from anything printed on the device, so it cannot be regenerated by an attacker who reads the label. And the support-period date is written once, at manufacture, into the record that will be inspected years later — which forces the commercial decision about how long you will patch to be made before the product ships, not after a researcher finds a hole.

The support period is a firmware budget, not a marketing line

The published support period is the requirement with the longest tail. It is a standing commitment to maintain a build pipeline, a signing process, and an over-the-air or manual update route for every model still inside its window. If you sell three models a year and promise five years each, you are committing to maintaining fifteen concurrent firmware lines at any given time. That is a resourcing decision the board should see, because a missed security update is no longer only a security failure — under the reformed product-liability rules, a missing update can itself be treated as a defect. PSTI and product liability now pull in the same direction: the update mechanism is part of the product.

There is a compliance route through recognised standards — you can meet the requirements directly or rely on the relevant provisions of ETSI EN 303 645 and ISO/IEC 29147 for vulnerability handling — and a set of excepted products, including certain medical devices, smart meters and some computers. Check whether your product is genuinely in scope before you build to the regime, and check it against the actual definitions rather than a vendor summary. If you are already engineering the device to expose user-access and data flows for other reasons, the disclosure and update plumbing sits naturally alongside that work; the same discipline that makes connected products expose data by design is what makes them updatable and reportable by design.

Enforcement sits with the Office for Product Safety and Standards, and the ceilings are not nominal: penalties reach the greater of £10 million or 4% of worldwide revenue, with up to £20,000 a day for a continuing contravention. But the number that should concentrate the mind is not the fine. It is the signed statement of compliance, retained for ten years, declaring that a device meets requirements its firmware does not. Sign that on the strength of paperwork alone, and you have not managed the risk — you have documented it.