Artifact GuideEU

Cyber Resilience Act comparison CRA vs UK PSTI Act

Use this page to separate grounded EU CRA duties from UK PSTI points that need their own UK legal-source check.

The CRA side is based on EU and ETSI sources; exact UK PSTI scope, dates, penalties, and legal wording should be verified against UK sources before use.

Author
Sorena AI
Published
Mar 4, 2026
Updated
May 25, 2026
Sections
4

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 4, 2026
Updated May 25, 2026
Overview

The Cyber Resilience Act is an EU horizontal product-cybersecurity regulation for products with digital elements. UK PSTI product-security work often overlaps operationally for connected consumer devices, but this page does not treat PSTI as interchangeable with the CRA. The available sources support CRA duties and ETSI consumer IoT baseline controls; they do not include primary UK PSTI legal sources, so UK-specific legal conclusions should be confirmed separately.

Side-by-side comparison

CRA vs UK PSTI Act: conservative comparison

Use this matrix to plan dual-market product-security work without overstating UK PSTI legal facts that are not grounded by the available CRA source set.

Review all sources
First framework
EU Cyber Resilience Act

The CRA column is grounded in Regulation (EU) 2024/2847 and Commission CRA material.

Second framework
UK PSTI Act

The UK PSTI column is conservative. It identifies likely comparison topics and blocks exact UK legal conclusions until primary UK PSTI sources are reviewed.

Comparison row 1

Scope boundary

EU Cyber Resilience Act

CRA applies to products with digital elements made available on the Union market, including software, hardware, and covered remote data-processing solutions necessary for product functions, subject to CRA exclusions and special rules.

UK PSTI Act

Treat UK PSTI scope as a separate UK-law question. The available sources support consumer IoT baseline context through ETSI EN 303 645, but they do not establish the legal PSTI scope.

Operational implication

A connected product can need both workstreams, but do not use a CRA in-scope decision as proof of UK PSTI coverage or a UK consumer IoT baseline as proof of CRA coverage.

Comparison row 2

Covered actors

EU Cyber Resilience Act

CRA requires manufacturers to address Annex I product security properties and vulnerability-handling requirements, including secure development, vulnerability remediation, security updates, component documentation, and user information.

UK PSTI Act

For UK PSTI planning, compare only high-confidence product-security themes until UK sources are reviewed: password design, vulnerability reporting, software-update support, and consumer-facing security information.

Operational implication

One engineering control can support both programs, but the CRA obligation map should cite Annex I and the UK PSTI obligation map should wait for UK primary-source confirmation.

Comparison row 3

Trigger

EU Cyber Resilience Act

CRA evidence should include the cybersecurity risk assessment, Annex I mapping, vulnerability-handling process, SBOM or component records where applicable, support-period rationale, test reports, technical documentation, EU declaration of conformity, and CE marking records.

UK PSTI Act

UK PSTI evidence should be held as a separate workstream. Exact statement content, responsible actor checks, product information records, and enforcement evidence are blocked until UK PSTI sources are reviewed.

Operational implication

Reuse control evidence only after labeling which facts prove CRA compliance and which facts still need UK PSTI source support.

Comparison row 4

Core obligations

EU Cyber Resilience Act

CRA Chapter IV applies from 11 June 2026, Article 14 reporting applies from 11 September 2026, and the Regulation applies in full from 11 December 2027.

UK PSTI Act

UK PSTI timing is not grounded by the available CRA source set. Do not publish or rely on UK PSTI start dates, transition dates, response windows, or enforcement dates from this page.

Operational implication

Use CRA dates for EU planning only. Add a separate UK PSTI calendar after primary UK sources confirm the relevant dates and clocks.

Comparison row 5

Evidence record

EU Cyber Resilience Act

CRA conformity work can lead to EU declaration of conformity and CE marking for covered products with digital elements that satisfy the applicable requirements.

UK PSTI Act

UK PSTI should not be described as CE marking or CRA-style conformity assessment without UK-source support. Keep any UK product statement or labeling conclusion separate.

Operational implication

A CE mark or CRA declaration should not be presented as evidence that UK PSTI legal obligations have been met.

Comparison row 6

Timing and deadlines

EU Cyber Resilience Act

CRA enforcement can involve market-surveillance authorities, corrective action, restriction or withdrawal of products, and administrative fines under the CRA enforcement framework.

UK PSTI Act

UK PSTI enforcement notices, penalties, powers, thresholds, and limitation periods are not grounded here and should not be stated without UK primary sources.

Operational implication

Escalate EU risk using CRA market-surveillance and penalties provisions; open a separate UK legal review before describing UK enforcement exposure.

Comparison row 7

Enforcement

EU Cyber Resilience Act

Use CRA sources when the decision turns on EU scope, Annex I requirements, vulnerability handling, support period, Article 14 reporting, technical documentation, conformity assessment, EU declaration of conformity, CE marking, or CRA enforcement.

UK PSTI Act

Use UK PSTI sources, not this CRA-grounded page alone, when the decision turns on exact UK product scope, statutory security requirements, statements, dates, responsible actors, penalties, or enforcement powers.

Operational implication

The safest dual-market answer is usually: build shared product-security controls, then issue separate EU CRA and UK PSTI conclusions with separate citations.

Comparison row 8

Overlap and reuse

EU Cyber Resilience Act

CRA applies to products with digital elements made available on the Union market, including software, hardware, and covered remote data-processing solutions necessary for product functions, subject to CRA exclusions and special rules.

UK PSTI Act

Treat UK PSTI scope as a separate UK-law question. The available sources support consumer IoT baseline context through ETSI EN 303 645, but they do not establish the legal PSTI scope.

Operational implication

A connected product can need both workstreams, but do not use a CRA in-scope decision as proof of UK PSTI coverage or a UK consumer IoT baseline as proof of CRA coverage.

Comparison row 9

Practical decision rule

EU Cyber Resilience Act

CRA applies to products with digital elements made available on the Union market, including software, hardware, and covered remote data-processing solutions necessary for product functions, subject to CRA exclusions and special rules.

UK PSTI Act

Treat UK PSTI scope as a separate UK-law question. The available sources support consumer IoT baseline context through ETSI EN 303 645, but they do not establish the legal PSTI scope.

Operational implication

A connected product can need both workstreams, but do not use a CRA in-scope decision as proof of UK PSTI coverage or a UK consumer IoT baseline as proof of CRA coverage.

Practical decision rule

How to use this comparison

  • Use the CRA column as the grounded EU work plan for products with digital elements.
  • Use the UK PSTI column as a review checklist, not as final UK operational guidance or a source-complete PSTI summary.
  • Reuse engineering controls where they genuinely overlap: credentials, vulnerability disclosure, updates, secure configuration, dependency tracking, and support-period communication.
  • Block final UK PSTI conclusions until primary UK sources confirm scope, actors, statement requirements, dates, enforcement powers, and penalties.
Section 1

What is safe to compare from the available sources

The CRA source set supports concrete EU duties: scope for products with digital elements, manufacturer vulnerability handling, security updates, support-period transparency, technical documentation, EU declaration of conformity, CE marking, and Article 14 reporting.

The same source set also includes ETSI EN 303 645, which is useful for consumer IoT baseline controls such as avoiding universal default passwords, operating a vulnerability reporting route, and keeping software updated. Those controls are useful context for UK PSTI planning, but they are not a substitute for UK PSTI legal analysis.

  • Use CRA sources to decide EU scope, conformity, documentation, support, CE marking, and reporting work.
  • Use ETSI consumer IoT controls only as a technical baseline comparator, not as proof of UK PSTI compliance.
  • Do not reuse CRA dates, conformity files, CE marking conclusions, or Article 14 reporting assumptions for UK PSTI without separate UK source review.
  • Do not rely on this page for UK PSTI penalties, statutory deadlines, exact responsible actors, or statement-of-compliance wording.
Recommended next step

Separate CRA evidence from UK PSTI evidence

Research Copilot can help turn a connected-product security baseline into separate EU CRA and UK PSTI evidence packs, with UK legal conclusions held until primary UK sources are reviewed.

Section 2

CRA obligations that usually require separate work

The CRA is broader than a consumer IoT baseline. It covers products with digital elements made available on the Union market, including relevant software, hardware, and remote data-processing solutions where those solutions are necessary for the product to perform its functions.

A manufacturer should therefore build a CRA file around the product, not only around individual security features. The file should connect the cybersecurity risk assessment to Annex I requirements, vulnerability-handling processes, support-period rationale, technical documentation, conformity assessment route, EU declaration of conformity, and CE marking.

  • Scope: confirm whether the product is a product with digital elements and whether any exclusions or special rules apply.
  • Security properties: map the product against Annex I Part I requirements, including secure-by-default design, vulnerability reduction, protection of confidentiality, integrity, availability, and secure updates.
  • Vulnerability handling: maintain documented processes, component and vulnerability records, coordinated disclosure, secure update distribution, and remediation evidence.
  • Market access: prepare technical documentation, conformity assessment evidence, EU declaration of conformity, and CE marking where required.
Section 3

Where engineering work can overlap

A single product-security program can support both CRA readiness and UK connected-product security work if it is designed around real controls rather than labels. Password design, vulnerability intake, software-update delivery, secure configuration, and support-period transparency are examples of work that can often be reused operationally.

The reuse limit is legal output. CRA has EU product-law artifacts such as technical documentation, conformity assessment, EU declaration of conformity, CE marking, and Article 14 reporting. UK PSTI work may need different statements, notices, actor checks, and enforcement records that are not supported by the available sources.

  • Share the engineering control: unique or user-defined credentials, secure update delivery, vulnerability intake, and product-support tracking.
  • Separate the legal artifact: CRA technical file and conformity records are not a UK PSTI compliance statement.
  • Separate the reporting clock: CRA Article 14 reporting applies from 11 September 2026 and follows the CRA reporting model.
  • Separate market labels: CE marking is a CRA/EU market-access signal, not a UK PSTI substitute.
Section 4

Practical dual-market approach

Start with one product-security baseline, then create separate EU and UK evidence layers. This prevents engineering teams from building duplicate controls while keeping legal conclusions traceable to the correct regime.

For the EU layer, ground each decision in the CRA: scope, product risk, support period, vulnerability handling, technical file, declaration, CE marking, and reporting. For the UK layer, record the likely overlap points but block final conclusions until primary UK PSTI sources have been reviewed.

  • Create one security-control register for credentials, updates, vulnerability disclosure, secure configuration, dependency tracking, and support commitments.
  • Create a CRA evidence index that references Annex I mappings, support-period rationale, SBOM or dependency evidence, test results, technical documentation, and conformity documents.
  • Hold UK PSTI conclusions in BLOCKED status until UK legal sources are added, and run a documented UK evidence check with named fields: UK scope source reference, UK responsible actor, product information duty, statement requirements, statutory deadlines, and enforcement references.
  • Approve a release only after the EU CRA evidence and UK PSTI evidence have each been checked against their own sources.
Primary sources

References and citations

Related guides

Explore more topics

CRA Applicability Test for Products With Digital Elements
Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning.
CRA Article 14 Reporting Obligations for Vulnerabilities and Incidents
Article 14 guide to CRA reports for actively exploited vulnerabilities and severe product-security incidents, including deadlines, CSIRT routing, users, and evidence.
CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales
CRA FAQ explaining Blue Guide market-access concepts for products with digital elements: placing on the market, making available, imports, CE marking, operator roles, online sales, stock, and testing exceptions.
CRA CE Marking FAQ | Conformity Assessment, EU Declaration, Evidence
Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence.
CRA Component Due Diligence FAQ | Third-Party Software, FOSS, SBOMs
Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records.
CRA Conformity Assessment and CE Marking
How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking.
CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products
Cyber Resilience Act FAQ on when manufacturers can use module A, when module B+C or module H is required, and how important and critical products affect the route.
CRA Cybersecurity Risk Assessment FAQ | Article 13, Annex I, Updates
CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence.
CRA deadlines and compliance calendar | EU Cyber Resilience Act
Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates.
CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking
FAQ on the Cyber Resilience Act EU Declaration of Conformity: Annex V contents, simplified Annex VI wording, CE marking link, technical documentation, retention, updates, and operator duties.
CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives
CRA FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls.
CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II
CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information.
CRA Essential Cybersecurity Requirements in Annex I
A grounded guide to the Cyber Resilience Act Annex I requirements for product security, vulnerability handling, secure-by-design controls, documentation, and evidence.
CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS
FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes.
CRA Harmonised Standards FAQ | Presumption of Conformity, Common Specifications
Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence.
CRA Important and Critical Products FAQ | Annex III, Annex IV, Conformity Assessment
FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences.
CRA Integrated Components and Dependencies FAQ | Third-Party Software and SBOM Evidence
Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility.
CRA Interplay With EU Product Laws FAQ | RED, Machinery, Data Act
Grounded CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates.
CRA Known Exploitable Vulnerabilities at Launch FAQ
FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence.
CRA Legacy Products FAQ | Pre-11 December 2027 Products
Cyber Resilience Act FAQ on products placed on the market before 11 December 2027, Article 14 reporting, substantial modification, distributor stock, spare parts, and records.
CRA Manufacturer Obligations FAQ | Article 13, Annex I, CE Marking
FAQ for Cyber Resilience Act manufacturers covering Article 13 duties, risk assessment, Annex I, vulnerability handling, support periods, documentation, conformity assessment, reporting, CE marking, and evidence controls.
CRA Market Surveillance and Enforcement FAQ | Authorities, Corrective Action, Safeguards
Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties.
CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies
CRA Module B+C FAQ explaining EU-type examination, conformity to type, notified-body evidence, production control, CE marking, declarations, and certificate changes.
CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking
CRA Module H FAQ explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records.
CRA Notified Bodies FAQ | Scope, Modules B+C and H, Certificates
Practical CRA FAQ on when notified bodies are needed, how CRA bodies are designated, what their notified scope means, and how Module B+C and Module H assessments work.
CRA Open-Source Software FAQ | FOSS Scope, Stewards, Manufacturers
Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations.
CRA Over-the-Air Updates FAQ
Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths.
CRA penalties and fines FAQ | Article 64 fine caps
FAQ on EU Cyber Resilience Act Article 64 penalties: maximum fine tiers, turnover caps, national enforcement, economic operators, reporting duties, and open-source steward carve-outs.
CRA Penalties and Fines: Article 64 Caps and Enforcement Context
Article 64 of the EU Cyber Resilience Act sets administrative fine ceilings for Annex I, manufacturer, reporting, economic-operator, notified-body, and information-request breaches.
CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope
CRA FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment.
CRA Products with Digital Elements Scope | EU Cyber Resilience Act
Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles.
CRA Products With Digital Elements Scope FAQ
EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator boundaries.
CRA Remote Data Processing Solutions FAQ | Product Scope, Cloud and Backend Boundaries
FAQ on how the EU Cyber Resilience Act treats remote data processing solutions, manufacturer-controlled backends, third-party cloud services, SaaS, risk assessment, documentation, and user information.
CRA Reporting Obligations FAQ | Article 14, CSIRTs, ENISA, User Notices
Cyber Resilience Act FAQ on Article 14 reporting for actively exploited vulnerabilities and severe incidents, including timing, CSIRT routing, ENISA access, user notices, and evidence.
CRA Requirements | Annex I, Manufacturer Duties and CE Evidence
Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence.
CRA SBOM and Vulnerability Management Template
Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields.
CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls
Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products.
CRA Security Updates vs Functionality Updates FAQ
Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review.
CRA Substantial Modification FAQ | Updates, Repairs, Manufacturer Duties
Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties.
CRA Support Period FAQ | Expected Product Lifetime, Security Updates, User Information
Practical CRA FAQ on how manufacturers determine support periods, disclose support end dates, keep security updates available, and document support-period evidence.
CRA Tailor-Made Products FAQ | Bespoke Products, Market Placement, Evidence
FAQ on when a bespoke product may be treated as tailor-made under the EU Cyber Resilience Act, what the carve-out changes, and what manufacturers still need to document.
CRA Technical Documentation FAQ | Annex VII Evidence and Technical File
CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access.
CRA Transition Period FAQ | Entry Into Force, Application Dates, Reporting, Legacy Products
CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions.
CRA Update Availability and Software Archives FAQ
FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits.
CRA User Information and Transparency FAQ | Annex II Instructions
Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information.
CRA vs RED Cybersecurity Delegated Act
Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment.
CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates
How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records.
CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting
Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices.
Cyber Resilience Act Module A FAQ | Internal Production Control
FAQ on when CRA Module A internal production control is available, when it is blocked, and what documentation, testing, standards, and evidence it still requires.
EU CRA Compliance Program for Manufacturers and Economic Operators
Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance.
EU Cyber Resilience Act Checklist for Product Security and CE Marking
A CRA checklist for products with digital elements: scope, Annex I security controls, vulnerability handling, Article 14 reporting, technical documentation, conformity assessment, CE marking, and support-period evidence.
EU Cyber Resilience Act Core Functionality FAQ | CRA Product Classification
CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification.
EU Cyber Resilience Act FAQ
Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance.
EU Cyber Resilience Act Repairs and Spare Parts FAQ
CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.
EU Cyber Resilience Act Technical Documentation and Audit File
Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention.