UK Product Security and Telecommunications Infrastructure Act (PSTI)

Per UK PSTI Act + Regulations 2023: Prohibition of Universal Default Passwords + unique per device or user-set passwords for connectable products.

• PSTI evidence for UKPSTIACT-1

• defaults + VDP + support period partial

Per PSTI: distributor + importer + retailer due diligence + enforcement including civil penalties + product recall.

• PSTI evidence for UKPSTIACT-4

• defaults + VDP + support period partial

Importers must check that products bear or are accompanied by a statement of compliance, that the manufacturer has met security requirements, and must keep records and act on non-compliance.

• Importer compliance check procedure
• SoC archive
• Non-compliance investigations
• Records retained for required period

• Importer relies on manufacturer assurances without verification
• No archive of SoCs
• No process to halt supply on non-compliance

Distributors (including online marketplaces in scope) must verify that products have the required SoC and that manufacturers and importers appear to have complied, and must take corrective action if not.

• Distributor compliance checklist
• Sample audit records
• Removal records for non-compliant products
• Communications to manufacturers

• No SKU level verification
• Marketplaces relying solely on seller self-attestation
• No takedown when non-compliance found

Manufacturers established outside the United Kingdom should ensure a UK responsible person or compliant supply chain entity can act in their place for PSTI obligations.

• Authorised representative appointment
• Contractual responsibilities
• Contact details on SoC and packaging
• OPSS notification of representative

• No UK responsible person
• Importer treated as manufacturer without contract
• Inconsistent contact details across products

Online marketplaces that fulfil a distributor role under PSTI must ensure listings for in-scope products are supported by a valid SoC and that non-compliant listings are removed.

• Marketplace policy
• Seller onboarding checks
• Automated scanning of listings
• Takedown logs

• No verification of seller SoC
• No automated detection of non-compliance
• Slow takedown of flagged listings

Manufacturers should obtain security assurance from suppliers of chipsets, modules and third party firmware components used in connectable products.

• Supplier security questionnaires
• SBOMs for shipped firmware
• Component vulnerability monitoring
• Contractual security clauses

• No SBOM for product firmware
• No vulnerability monitoring on third party modules
• Contracts silent on PSTI obligations

Manufacturers established outside the UK that supply relevant products to UK consumers may appoint an authorised representative, who must be empowered to act and maintain documentation on the manufacturer's behalf.

• Written mandate between manufacturer and representative
• Representative contact details on file
• Document access arrangement
• Renewal schedule for the mandate

• Mandate verbal only
• Representative cannot produce statements of compliance
• No backup arrangement if representative ceases

Online marketplaces facilitating the sale of relevant products to UK consumers must take reasonable steps to ensure listings comply with security requirements and respond to enforcement requests.

• Seller onboarding checks
• Automated listing screening rules
• Takedown procedure and SLA
• Reporting channel for enforcement notices

• No proactive screening of new listings
• Takedown takes weeks
• Repeat sellers not blocked after multiple violations

Manufacturers, importers and distributors must notify OPSS when they become aware that a relevant connectable product they have made available has failed to comply with a security requirement, and take action to address the failure.

• Notification procedure
• OPSS notifications register
• Root cause analysis
• Customer communications

• No definition of when awareness is triggered
• Late notification
• No customer notification where appropriate

Manufacturers, importers and distributors should be prepared for OPSS enforcement, including information notices, compliance notices, stop notices, recall notices and civil monetary penalties up to GBP 10 million or 4 percent of global turnover.

• Regulatory liaison plan
• Internal escalation matrix
• Response templates for OPSS notices
• Penalty risk modelling

• No regulatory point of contact
• No internal process to handle notices
• No financial provisioning for penalties

Relevant persons must cooperate with the enforcement authority during investigations, including providing requested information, samples, and access to premises where products are held.

• Investigation response playbook
• Designated single point of contact for OPSS
• Legal hold notice template
• Records location index

• No SPOC named for regulator contact
• Records dispersed across systems with no index
• Slow response to information notices

Where the enforcement authority issues a compliance notice, the relevant person must take the steps specified within the period stated to remedy the non-compliance.

• Remediation project plan
• Customer notification letters
• Post-remediation conformity evidence
• Regulator response file

• Customers not notified of corrected products
• No verification of effectiveness
• Remediation deadline missed without extension request

Where a stop notice or recall notice is issued, the relevant person must cease the relevant activity and execute any recall as specified, maintaining records of actions taken.

• Product recall procedure
• Inventory hold logs
• Customer recall communications
• Returns reconciliation report

• Slow channel notification
• No tracking of returned units versus units sold
• Recall communications buried in marketing emails

Organisations should review PSTI compliance regularly across the product portfolio, incorporating findings from incidents, audits and regulator engagement.

• Annual compliance review
• Audit findings tracker
• Lessons learned register
• Board reporting

• Compliance assumed not measured
• No tracker for audit findings
• Reviews not reported to board

Manufacturers should publicly notify customers and registered users when a security flaw materially affects compliance with the requirements, with clear instructions on what action to take.

• Security advisory template
• Communications channel inventory
• Plain language review record
• Acknowledgement and response statistics

• Advisory hidden in technical bulletin format
• Email channel only with no in-product notice
• No follow-up if user has not actioned the advisory

Organisations should account for the financial penalties available under the PSTI regime (up to GBP 10 million or 4 percent of worldwide revenue) in their compliance governance and risk reporting.

• Risk register entry quantifying PSTI penalty exposure
• Board paper covering the regime
• Insurance review noting regulatory fines exclusions
• Compliance committee minutes

• No board awareness of the regime
• Risk register lacks quantified exposure
• Compliance treated only as operational

Manufacturers, importers and distributors must determine whether their products are relevant connectable products under Part 1 of the PSTI Act 2022 and associated regulations, effective from 29 April 2024.

• Product scoping memorandum
• Connectivity assessment per SKU
• Schedule of in-scope and out-of-scope products
• Legal opinion on exemptions

• Products misclassified as out of scope
• No reassessment after firmware change adds connectivity
• B2B carve-out applied without evidence

Manufacturers must accurately determine whether a product falls within the scope of the security requirements or qualifies as an excepted product under the regulations, with documented rationale.

• Per-SKU scope determination
• Legal opinion or written rationale for exceptions
• Product taxonomy mapping to PSTI categories
• Periodic re-review schedule

• Scope decided informally without documentation
• Excepted status not re-reviewed when product changes
• No legal sign-off on borderline cases

Manufacturers must not supply products with universal default passwords; passwords must be unique per product or set by the user during initialisation, and meet defined complexity criteria.

• Password provisioning design
• Manufacturing process records
• Cryptographic uniqueness evidence
• User initialisation flow screenshots

• Same default password across batches
• Password derived from MAC address or serial number in a guessable way
• No way to set password before network connection

Manufacturers must publish information allowing security researchers and others to report vulnerabilities, with a designated point of contact, expected response timelines and information about status updates.

• Public VDP page URL
• security.txt file
• Triage SLA records
• Researcher communication logs

• No public VDP
• No response within stated timeframe
• Researchers threatened with legal action

Manufacturers must publish the minimum length of time during which security updates will be made available for each product, and ensure it is accessible without requiring the user to give personal information.

• Published support periods per SKU
• Internal roadmap aligned to commitment
• Update build pipeline records
• Public website screenshot

• Support period not published
• Support period shorter than user expectations or sectoral norms
• Inconsistent dates across product page, packaging and EU equivalent

Although not separately mandated in the first three security requirements, manufacturers should deliver software updates over secure channels and verify integrity, in line with ETSI EN 303 645 expectations.

• Code signing key management
• TLS configuration for update servers
• OTA update logs
• Rollback prevention design

• Updates over HTTP
• Unsigned firmware images
• No rollback protection

Manufacturers should ensure credentials, cryptographic keys and other security parameters are stored securely on the device and not in plaintext.

• Secure element / TEE usage records
• Key storage design
• Firmware reverse engineering review
• Threat model

• Credentials in firmware images
• Keys hardcoded in source
• No protection against extraction via debug ports

Manufacturers should disable unused interfaces, services and accounts and ensure debug interfaces are not accessible in production.

• Hardening guidelines
• Port and service scan results on production builds
• Debug interface removal evidence
• Threat model for exposed services

• Telnet or UART accessible
• Default open ports on LAN
• Debug builds shipped to customers

Products should remain functioning and locally usable in the case of a loss of network and re-connect cleanly without exposing users to additional risk.

• Offline mode design
• Network loss test reports
• Reconnect security checks
• Customer documentation

• No offline functionality
• Insecure reconnect (no certificate validation)
• Excessive reconnect attempts amplifying outages

Where products process personal data, manufacturers must ensure that data is protected in transit and at rest and that users can delete personal data from the device.

• Data protection impact assessment
• Encryption in transit / at rest evidence
• Factory reset design
• Privacy notice

• Personal data not encrypted at rest
• Factory reset does not erase all data
• No DPIA

Where products receive software updates, the update mechanism must validate authenticity and integrity of updates before installation to prevent the device being compromised through the update channel.

• Code signing key management procedure
• Update verification routine in firmware
• Anti-rollback protection design
• Penetration test of update flow

• Updates downloaded over plain HTTP
• Signature checked but rollback to vulnerable firmware allowed
• Signing keys stored without HSM protection

When a relevant product undergoes a material change that could affect its security compliance, the manufacturer must re-assess and, where needed, re-issue the Statement of Compliance.

• Engineering change request form including security review
• Updated Statement of Compliance archive
• Customer notification of change
• Version-to-compliance mapping

• Firmware updates not triggering compliance review
• No version history tied to compliance statements
• Material changes treated as minor

Manufacturers must produce a statement of compliance for each in-scope product before supply, containing the prescribed information, and make it available to distributors and on request to OPSS.

• Statement of compliance per SKU
• Version control of SoC
• Translation records (if applicable)
• Distribution mechanism to importers and distributors

• Missing prescribed fields
• SoC not updated when firmware changes affect compliance
• SoC not shared with all distributors

Manufacturers, importers and distributors must keep records of statements of compliance and other prescribed information for at least 10 years (or such period as set by regulations).

• Document retention schedule
• Archive system
• Access procedure for OPSS requests
• Audit trail of changes

• No central archive
• Records purged early
• No procedure to retrieve historical SoCs

Manufacturers should provide clear and accessible user documentation including secure configuration steps, update behaviour and end of support implications.

• User manuals
• Quick start guides referencing security setup
• End of support notices
• Translations as required

• Security setup omitted from documentation
• End of support not communicated
• Documentation only in English where required otherwise

Relevant persons must keep records that evidence compliance with each applicable security requirement for the periods specified in the regulations, in a form accessible to enforcement.

• Records retention policy
• Compliance evidence repository
• Index mapping evidence to security requirements
• Access logs showing retrieval capability

• Records held only on individual laptops
• Retention period below regulatory minimum
• No mapping between artefact and requirement

Per PSTI: Defined Support Period (Minimum Security Update Period Declaration) + Statement of Compliance + Manufacturer Identification.

• PSTI evidence for UKPSTIACT-3

• defaults + VDP + support period partial

Per PSTI: Vulnerability Disclosure Policy Publication + handling + acknowledgement + statutory contact.

• PSTI evidence for UKPSTIACT-2

• defaults + VDP + support period partial