Run both scope tests for dual-market products. UK PSTI targets consumer connectable products and three specified security areas; the EU Cyber Resilience Act covers a wider set of connected hardware and software and adds lifecycle, conformity, CE-marking, and reporting duties.
One security program can support both regimes, but each market needs its own legal conclusion, product documents, dates, and regulator-facing record.
Start with the sales territory and complete product boundary. For the UK, apply the Product Security and Telecommunications Infrastructure (PSTI) Act 2022 to test whether each item is a relevant connectable product made available to consumers and whether an exception applies. For the EU, test each hardware or software item, including qualifying , against Regulation (EU) 2024/2847 and its exclusions. If both apply, share engineering evidence but keep the legal approvals separate.
Side-by-side decision guide
UK PSTI vs EU Cyber Resilience Act
Use the rows to route the product, evidence, and approvals. Do not collapse the two legal tests into one result.
Assess the relevant connectable product, including the hardware and software that make it internet-connectable or network-connectable, against the UK definitions and exceptions.
The Act and Regulations except specified products, including certain regulated products and, after the 2025 amendment, specified vehicle categories. The exact exception conditions must be checked.
Article 2 excludes or limits specified medical, in vitro diagnostic, automotive, aviation, marine, defence, national-security, and other products. Free and open-source software supplied outside a commercial activity is outside the main scope, with separate steward rules.
Manufacturers, importers, distributors, authorised representatives, open-source software stewards, and other specified actors have role-specific duties.
A compliant product is accompanied by a UK statement of compliance, subject to any valid deemed-compliance route; the file also needs actor and retention records.
Schedule 1 specifies password conditions, a published security-reporting route and response-time information, and publication of the minimum security-update period with an end date.
Annex I sets risk-based product cybersecurity and vulnerability-handling requirements. Article 13 requires a reasoned support period, normally at least five years unless expected use is shorter.
Use one engineering plan, but map each control and support decision to the exact UK and EU text and keep the different publication and lifecycle evidence.
PSTI requires publication of a route for reporting security issues. A compliance failure also triggers actor-specific investigation, reasonable steps, notification, and record duties; it does not use the CRA Article 14 reporting sequence.
From 11 September 2026, Article 14 requires staged reporting of actively exploited vulnerabilities and severe incidents affecting product security, with related user information and final-report duties where applicable.
Use shared detection and triage, then route the event through separate UK compliance-failure and CRA Article 14 decisions with their own clocks and submission evidence.
EU market-surveillance authorities can require corrective action, restrict or prohibit products, order withdrawal or recall, and impose national penalties within the CRA framework.
Keep market-specific supply, technical, reporting, corrective-action, notice, and regulator-communication records; one authority's outcome does not bind the other.
Assess the relevant connectable product, including the hardware and software that make it internet-connectable or network-connectable, against the UK definitions and exceptions.
The Act and Regulations except specified products, including certain regulated products and, after the 2025 amendment, specified vehicle categories. The exact exception conditions must be checked.
Article 2 excludes or limits specified medical, in vitro diagnostic, automotive, aviation, marine, defence, national-security, and other products. Free and open-source software supplied outside a commercial activity is outside the main scope, with separate steward rules.
Manufacturers, importers, distributors, authorised representatives, open-source software stewards, and other specified actors have role-specific duties.
A compliant product is accompanied by a UK statement of compliance, subject to any valid deemed-compliance route; the file also needs actor and retention records.
Schedule 1 specifies password conditions, a published security-reporting route and response-time information, and publication of the minimum security-update period with an end date.
Annex I sets risk-based product cybersecurity and vulnerability-handling requirements. Article 13 requires a reasoned support period, normally at least five years unless expected use is shorter.
Use one engineering plan, but map each control and support decision to the exact UK and EU text and keep the different publication and lifecycle evidence.
Comparison row 6
Reports and corrective action
UK PSTI
PSTI requires publication of a route for reporting security issues. A compliance failure also triggers actor-specific investigation, reasonable steps, notification, and record duties; it does not use the CRA Article 14 reporting sequence.
From 11 September 2026, Article 14 requires staged reporting of actively exploited vulnerabilities and severe incidents affecting product security, with related user information and final-report duties where applicable.
Use shared detection and triage, then route the event through separate UK compliance-failure and CRA Article 14 decisions with their own clocks and submission evidence.
Comparison row 7
Enforcement and penalties
UK PSTI
OPSS can investigate, serve compliance, stop, and recall notices, impose monetary penalties, seek forfeiture, publish failures, and pursue specified offences.
EU market-surveillance authorities can require corrective action, restrict or prohibit products, order withdrawal or recall, and impose national penalties within the CRA framework.
Keep market-specific supply, technical, reporting, corrective-action, notice, and regulator-communication records; one authority's outcome does not bind the other.
Comparison row 8
Dates
UK PSTI
PSTI Part 1 and the 2023 Regulations have applied since 29 April 2024.
Use the PSTI workstream when a manufacturer, importer, or distributor makes a relevant connectable product available to UK consumers. The regime has applied since 29 April 2024. Confirm the password requirement, published security-issue reporting route, published minimum security-update period, statement of compliance, and actor-specific supply checks.
Use the EU Cyber Resilience Act workstream for a product with digital elements made available on the EU market when its intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The CRA can cover standalone software, embedded software, hardware, and a remote data-processing solution on which a product depends for a function. Check Article 2 exclusions before classifying the product.
Run both workstreams when the same product is supplied in both markets. A connected home camera is a representative dual-market example. Standalone commercial software may be a CRA product even when it is not a UK consumer connectable product. The product may have a shared bill of materials, threat model, vulnerability process, update mechanism, test suite, and support plan, but it still needs jurisdiction-specific scope findings and outputs.
Record exclusions narrowly. PSTI Schedule 3 and the CRA Article 2 exclusions use different sector, product, and legal conditions. Free and open-source software supplied outside a commercial activity is outside the CRA's main product obligations, while open-source software stewards have separate duties. Neither framework creates a general exemption merely because another cybersecurity standard or sectoral rule applies.
The CRA requires the manufacturer to perform and document a cybersecurity risk assessment, design and produce the product in accordance with Annex I, handle vulnerabilities throughout the support period, prepare technical documentation, complete the applicable conformity assessment, issue an EU declaration of conformity, and affix CE marking. Importers and distributors have verification, identification, cooperation, and corrective-action duties.
Product classification affects the conformity route. The CRA distinguishes default products, important products in classes I and II, and critical products. Classification depends on Annexes III and IV and any delegated acts, not on a general impression that a product is high risk. Most products can use the internal-control route, while important and critical categories may need a harmonised-standard route, EU-type examination, full quality assurance, or another route specified by Article 32.
The CRA support period normally must be at least five years unless the product is expected to be used for less than five years. The manufacturer must base it on expected use, product and market characteristics, user expectations, component support, and other Article 13 factors. PSTI instead requires the manufacturer to publish the minimum period for which security updates will be provided, expressed with an end date. One operational period can serve both only when its reasoning and publication satisfy both rules.
Article 14 reporting starts before the general product obligations. From 11 September 2026, manufacturers must use the CRA process for actively exploited vulnerabilities and severe incidents affecting product security. Most other CRA provisions apply from 11 December 2027; Chapter IV on notification of conformity-assessment bodies has applied since 11 June 2026.
Does the CRA replace PSTI for products sold in the UK?
No. The CRA is an EU regulation and PSTI is UK law. A product sold in both markets may need both. EU conformity, an EU declaration, or CE marking does not remove UK PSTI scope, security, statement, and supply-chain duties.
Are products already on the EU market exempt from the CRA?
Not as a blanket rule. Article 69 contains transitional provisions for products placed on the market before 11 December 2027, but the CRA can apply when a product is substantially modified after that date. Article 14 reporting also applies from 11 September 2026 to products within its terms. Record market-placement and modification facts rather than relying only on a model launch date.
Does the CRA always require a notified body?
No. The conformity route depends on product classification, applicable harmonised standards or certification, and Article 32. Many products can use internal control. Important class II products and critical products face stricter routes, and some class I cases require a third-party route when the conditions for internal control are not met.
Assign one product owner to maintain the boundary across device, software, cloud dependency, interfaces, versions, and markets.
Record the Annex III or IV classification decision and the chosen Article 32 conformity-assessment route.
Build a CRA technical file around the Annex I risk assessment, design evidence, tests, vulnerability handling, update delivery, user information, and support-period reasoning.
Prepare CRA incident triage and reporting before 11 September 2026, including clocks, submission ownership, and user-notification decisions.
Keep the UK statement of compliance separate from the EU declaration of conformity and CE-marking file.
Reassess after a new intended use, connectivity path, remote-service dependency, software component, product class, legal entity, support-period decision, market route, or .