PSTI vs CRA comparisons should be written in operational language: which products are covered, which actor must act, what evidence proves compliance, and which deadline or enforcement route applies.
Use this guide to separate UK PSTI duties from CRA duties for connected products and products with digital elements, then turn the result into owners, records, and next actions. Validate against current legal and policy requirements before implementation.
Structured answer sets in this page tree.
Cited legal and guidance references.
This page is a side-by-side comparison of UK PSTI and the EU Cyber Resilience Act (CRA). It helps you decide which regime applies to a connected product, what each regime requires, and what evidence and timelines your team should prepare first.
Compare PSTI and CRA through scope, actors, triggers, duties, evidence, deadlines, enforcement, and operational decision rules.
PSTI is the UK regime for relevant connectable products. Use it to confirm whether the product falls into scope, which actor owes the duty, and which enforcement route or statement of compliance applies.
CRA is the EU regime for products with digital elements. Use it to test product scope, economic-operator duties, conformity assessment, reporting dates, and whether a notified body may be needed.
| Dimension | PSTI | CRA | Operational implication |
|---|---|---|---|
| Scope and covered activity | PSTI: define the relevant connectable product and record the UK scope finding separately from any EU assessment. | CRA: test whether the product with digital elements is in CRA scope, including exclusions and any substantial-modification issues. | Write two separate scope findings first: one for PSTI and one for CRA. Do not reuse a UK scope conclusion as the EU conclusion without checking the CRA text. |
| Who must act | PSTI: identify the manufacturer, importer, distributor, authorised representative, or UK responsible person that owns the connected-product duty. | CRA: assign the comparator duty to the relevant manufacturer, importer, distributor, authorised representative, notified body, or steward role that the CRA names. | Name each role separately. A supplier can be responsible under one regime and only a supporting party under the other. |
| Trigger or threshold | PSTI: state the fact that starts the obligation for the UK regime, such as market placement or the regulated role you hold. | CRA: state the CRA trigger separately, such as market placement, classification, reporting event, or conformity-assessment route. | Start with the trigger so teams do not apply the wrong regime to the wrong facts. |
| Core obligations | The UK PSTI Act requires manufacturers to eliminate universal default passwords, publish a public vulnerability disclosure policy with a contact address, and state the minimum period for which the product will receive security updates before placing it on the UK market. | The EU Cyber Resilience Act requires manufacturers to conduct a cybersecurity risk assessment, implement security-by-design requirements throughout the product lifecycle, provide security updates for the support period, notify ENISA of actively exploited vulnerabilities within 24 hours, and affix CE marking after conformity assessment. | Translate each obligation into the exact deliverable the team must produce, such as a password control, disclosure page, support-period statement, risk assessment, technical file, report, or CE-marked declaration. |
| Evidence and records | PSTI: keep the evidence that proves the UK decision, including cited text, registers, policies, test records, contracts, notices, reports, approvals, or audit artifacts. | CRA: keep comparator evidence in a distinct record set and link only the artifacts that genuinely satisfy the CRA requirements. | Keep source links, factual analysis, owner approval, and implementation evidence together so the UK and EU records do not get mixed into one vague file set. |
| Timing and cadence | PSTI: capture the application date, commencement date, transition period, reporting clock, review cadence, remediation window, or certification renewal that controls the UK side. | CRA: track the CRA schedule separately so the 11 June 2026, 11 September 2026, and 11 December 2027 dates are not hidden by the UK workstream. | Use current source dates; do not reuse an older project plan if the regime dates or guidance have moved. |
| Enforcement or assurance route | PSTI: identify the competent authority, regulator, assessor, customer audit, certification body, contractual remedy, penalty, or supervisory process tied to the UK side. | CRA: identify the enforcement or assurance route for the EU side and record where supervision, penalties, market access, certification, or contract leverage differs. | Escalate when the enforcement routes differ because the UK regulator, EU market-surveillance authority, certification body, customer, or contract counterparty may require different proof. |
| Overlap and reuse | PSTI: reuse controls only where the source-linked duty, evidence standard, owner, and timing align with the EU side; otherwise keep a bridge note. | CRA can reuse evidence from the UK 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. |
| Practical decision rule | PSTI: treat this as the controlling workstream when the product is a relevant connectable product and the immediate blocker is a UK security requirement, statement of compliance, or OPSS-facing issue. | CRA: run this workstream when the product has digital elements in EU scope and the immediate blocker is CRA classification, conformity assessment, reporting, or CE-marking readiness. | If only one regime applies, act on that regime first. If both apply, run both workstreams in parallel and keep the evidence files separate. |
PSTI: define the relevant connectable product and record the UK scope finding separately from any EU assessment.
CRA: test whether the product with digital elements is in CRA scope, including exclusions and any substantial-modification issues.
Write two separate scope findings first: one for PSTI and one for CRA. Do not reuse a UK scope conclusion as the EU conclusion without checking the CRA text.
PSTI: identify the manufacturer, importer, distributor, authorised representative, or UK responsible person that owns the connected-product duty.
CRA: assign the comparator duty to the relevant manufacturer, importer, distributor, authorised representative, notified body, or steward role that the CRA names.
Name each role separately. A supplier can be responsible under one regime and only a supporting party under the other.
PSTI: state the fact that starts the obligation for the UK regime, such as market placement or the regulated role you hold.
CRA: state the CRA trigger separately, such as market placement, classification, reporting event, or conformity-assessment route.
Start with the trigger so teams do not apply the wrong regime to the wrong facts.
The UK PSTI Act requires manufacturers to eliminate universal default passwords, publish a public vulnerability disclosure policy with a contact address, and state the minimum period for which the product will receive security updates before placing it on the UK market.
The EU Cyber Resilience Act requires manufacturers to conduct a cybersecurity risk assessment, implement security-by-design requirements throughout the product lifecycle, provide security updates for the support period, notify ENISA of actively exploited vulnerabilities within 24 hours, and affix CE marking after conformity assessment.
Translate each obligation into the exact deliverable the team must produce, such as a password control, disclosure page, support-period statement, risk assessment, technical file, report, or CE-marked declaration.
PSTI: keep the evidence that proves the UK decision, including cited text, registers, policies, test records, contracts, notices, reports, approvals, or audit artifacts.
CRA: keep comparator evidence in a distinct record set and link only the artifacts that genuinely satisfy the CRA requirements.
Keep source links, factual analysis, owner approval, and implementation evidence together so the UK and EU records do not get mixed into one vague file set.
PSTI: capture the application date, commencement date, transition period, reporting clock, review cadence, remediation window, or certification renewal that controls the UK side.
CRA: track the CRA schedule separately so the 11 June 2026, 11 September 2026, and 11 December 2027 dates are not hidden by the UK workstream.
Use current source dates; do not reuse an older project plan if the regime dates or guidance have moved.
PSTI: identify the competent authority, regulator, assessor, customer audit, certification body, contractual remedy, penalty, or supervisory process tied to the UK side.
CRA: identify the enforcement or assurance route for the EU side and record where supervision, penalties, market access, certification, or contract leverage differs.
Escalate when the enforcement routes differ because the UK regulator, EU 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 EU side; otherwise keep a bridge note.
CRA can reuse evidence from the UK 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 the product is a relevant connectable product and the immediate blocker is a UK security requirement, statement of compliance, or OPSS-facing issue.
CRA: run this workstream when the product has digital elements in EU scope and the immediate blocker is CRA classification, conformity assessment, reporting, or CE-marking readiness.
If only one regime applies, act on that regime first. If both apply, run both workstreams in parallel and keep the evidence files separate.
Start by deciding whether the product is a relevant connectable product under PSTI or a product with digital elements under the CRA, then map the responsible actor, obligation, evidence, and timing for each regime separately. The useful answer should name the exact trigger, affected product or process, required action, owner, evidence, and escalation point.
Keep the legal source, product-scope decision, manufacturer/importer/distributor role, statement of compliance, and technical evidence together so PSTI and CRA records can be reviewed without merging two different legal tests.
Ownership should sit with the team that controls product design, supply-chain placement, importer/distributor checks, or customer security information, with legal and product-security review.
Evidence should show relevant-connectable-product scope, default-password controls, vulnerability disclosure channel, minimum support period, statement of compliance, supply-chain role checks, and OPSS or market-surveillance response readiness.
Use this UK PSTI Product Security guide to turn PSTI vs CRA into owners, evidence requests, review checkpoints, and reusable operating records inside Sorena.
Turn PSTI vs CRA into scoped questions, evidence fields, and review tasks.
Use Research Copilot to answer follow-up questions with cited source material.
Review scope, evidence, owners, and the next compliance actions with Sorena.
"enforcement actions taken by OPSS in relation to consumer connectable product security regulations"
"horizontal cybersecurity requirements for products with digital elements"
"Products with digital elements that have been placed on the market before 11 December 2027"
"This document provides guidance on regulatory activities, enforcement, and related resources for the Product Security and Telecommunications Infrastructure"
"Product Security and Telecommunications Infrastructure Act 2022"
"security requirements for relevant connectable products"
"security requirements for relevant connectable products"
"The government has been working with the tech industry to better secure consumer connectable products for several years"
"security requirements for relevant connectable products"
"This is a UK government guidance page about the PSTI Product Security regime and compliance requirements"