Cybersecurity Resilience Act vs PSTI Act: key differences, compliance, and penalties

The European Union’s Cyber Resilience Act, CRA, marks a turning point in how digital products are built, maintained, and brought to market. It places cybersecurity at the core of product design from the first line of code to the final update.

While the UK’s Product Security and Telecommunications Infrastructure, PSTI, Act serves a similar purpose domestically, the CRA sets a broader and more stringent framework for anyone offering digital products across the EU. 

Understanding the difference between the two acts, and knowing when they apply, is vital for companies operating internationally, especially those in sectors that rely on digital products or connected services. 

CRA vs PSTI Act: A side-by-side comparison 

Aspect	UK PSTI Act	EU CRA
Jurisdiction and reach	Applies only within the UK. Targets non-UK manufacturers selling IoT or smart devices into the UK.	Applies across all 27 EU member states. Covers EU and non-EU manufacturers offering products with digital elements in the EU.
Products in scope	Consumer “connectable” products: IoT or smart devices connecting to the internet or a home network.	All products with digital elements: hardware or software that can connect to a device or network. Includes both consumer and industrial systems.
Key security requirements	Three core obligations: no default passwords, a means to report vulnerabilities, and transparency on update periods.	Full lifecycle security: secure-by-design and by-default principles, risk assessment, vulnerability management, mandatory disclosure, and timely patching.
Compliance process	Self-declaration through a Statement of Compliance. No third-party testing required.	Conformity assessments vary by risk. Critical products may require independent certification before EU market entry.
Enforcement authority	UK Office for Product Safety and Standards (OPSS).	National Market Surveillance Authorities in each EU member state.
Penalties	Up to £10 million or 4% of global turnover (whichever is higher) and daily fines up to £20,000.	Up to £10 million or 4% of global turnover (whichever is higher) and daily fines up to £20,000. Up to €15 million or 2.5% of global turnover for serious violations; lower tiers at €10M/2% and €5M/1%.
Timeline	Effective April 2024 (transition period completed).	Entered into force December 2024. Mandatory compliance by December 2027.

When must UK companies comply with the Cyber Resilience Act? 

Although the UK is no longer part of the EU, the Cyber Resilience Act applies to UK companies that sell, distribute, or provide products with digital elements to EU customers. 

If your organisation develops or sells software, connected devices, or digital systems that are placed on the EU market, directly or via distributors, you fall under the CRA’s scope. 

In other words, if you go with your services outside the UK, and those services or products are available in EU countries, you must comply with the Cyber Resilience Act. 

The CRA officially took effect in December 2024, with a three-year transition period. By December 2027, all affected businesses must demonstrate compliance, while vulnerability reporting requirements will already apply by late 2026. 

For UK firms, this means planning: 

• Identify all digital products offered in EU markets. 

• Integrate security-by-design practices across the development lifecycle. 

• Document cybersecurity measures and incident-response plans. 

• Prepare for conformity assessments, especially if your products fall into critical categories. 

Failing to act early could mean being blocked from selling in the EU market or facing significant penalties once enforcement begins. 

When does the Cyber Resilience Act not apply?

There are a few cases where the CRA doesn’t apply: 

• No EU market access: If your products or software are not made available in the EU, CRA obligations do not apply. 

• Already regulated sectors: Medical devices, automotive systems, and civil aviation products are exempt since they are governed by dedicated cybersecurity rules under existing EU frameworks. 

• Non-commercial open-source software: Open-source projects developed or distributed outside commercial activity are excluded. However, once integrated into a commercial product, the CRA applies. 
• Pure service models: Cloud or SaaS products with no physical or digital “product” placed on the market may fall under other laws (e.g. the NIS2 Directive) rather than the CRA.  

Penalties for non-compliance 

Both the UK and EU frameworks introduce strict penalties for failing to comply. 

Under the PSTI Act: 

• Fines up to £10 million or 4% of global annual revenue, whichever is higher. 

• Daily penalties up to £20,000 for ongoing non-compliance. 

• Potential recall or stop notices for products already on the market. 

Under the Cyber Resilience Act: 

• Up to €15 million or 2.5% of global turnover for serious breaches. 

• €10 million or 2% for lesser violations. 

• €5 million or 1% for false or misleading information provided to authorities. 

• National regulators can order market withdrawal or product recalls for non-compliant products. 

Beyond financial penalties, non-compliance risks reputational harm, customer loss, and exclusion from one of the world’s largest digital markets. 

What does practical compliance look like? 

Treat CRA readiness as a product discipline rather than a paperwork exercise.  

Start by defining security requirements from the outset and recording the threats you are designing against. Maintain a software bill of materials, SBOM, for each release so you can trace third-party code and respond quickly when a component becomes vulnerable. Ensure your update process uses signed packages, prevents rollback to known-weak versions and supports staged rollouts with telemetry so you can monitor health and reverse safely if needed. 

Make your vulnerability disclosure policy public and run a coordinated process internally to triage, fix and communicate issues. Provide clear information to users about security features, support periods and update behaviour. Keep a concise technical file for each product that brings all this evidence together: requirements and threat model, SBOMs, test outcomes, update policy, disclosure records and incident logs. It will save time—and cost—when you face a conformity review. 

Suppliers are part of your product.  

Contracts should set expectations for patch timelines by severity, notification windows, proof of conformity and cooperation during incidents. Align your CI/CD pipelines to generate and store the artefacts you will need: SBOMs, signatures, test results and release notes. Measure progress with a handful of leading indicators such as time to patch critical issues, SBOM coverage across products and releases, the share of suppliers under CRA-aligned clauses, and the proportion of releases that pass security gates. 

Who carries the obligation? 

The manufacturer bears primary responsibility under the Cyber Resilience Act. If the manufacturer is outside the EU, an EU-based authorised representative and importers share duties to ensure compliance and keep documentation available. Distributors must check that conformity markings and user information, including the declared security support period — are present. Contracts should allocate these tasks clearly, including who maintains the technical file and who submits regulatory reports. 

Product classes and assessment paths 

Most mainstream software and many connected products will follow an internal assessment route as long as you can show secure-by-design practices, a durable update mechanism and clear user information.  

Products with higher potential impact, because they control sensitive processes, are widely deployed or create a significant attack surface, may need independent evaluation. The triggers are predictable: safety implications, systemic dependency, a serious vulnerability history or links to critical infrastructure. Plan for the strictest product in your portfolio and your entire programme will benefit. 

Post-market monitoring

CRA compliance continues post-release. 

Track vulnerabilities and incidents affecting your product, assess severity, and publish updates within the declared support window. Keep an auditable log of findings, triage decisions, advisories and the dates you informed users and authorities. Tie this cadence to your regular release train rather than treating it as an ad-hoc task.  

Reporting vulnerabilities under the CRA

The CRA introduces time-bound reporting of actively exploited or severe vulnerabilities and significant incidents.  

The manufacturer, or the authorised representative in Europe, will need to notify the designated authority through the EU portal within short windows. This is separate from your public disclosure to customers and from community reporting through your VDP. Assign roles, prepare templates and rehearse the process so you can act in days, not weeks. 

What your users should see

ach product should include a concise security notice that states the security support period, explains how updates are delivered and verified, points to the vulnerability reporting route, and notes any necessary secure configuration by the user. Host this online and reference it in packaging, app store listings and admin consoles.  

Software and service edge cases 

Mobile and desktop apps distributed to EU users are typically treated as products with digital elements, so they fall within scope. Embedded SDKs inherit scope when they ship as part of a product. Community open-source remains exempt until it enters a commercial build; at that point, you must track it in the SBOM and maintain updates. If you reach EU users through a marketplace or an EU-based reseller, that counts as placement on the EU market. 

Industries that should prioritise CRA readiness

Retail 

Retail runs on connected tech: POS terminals, handhelds, kiosks, in-store Wi-Fi, smart shelving, beacons and a stack of mobile and web apps. These are “products with digital elements” or depend on them, which brings CRA obligations into the procurement and operations flow. 

Where gaps typically appear 

• Unmanaged device fleets in stores: weak default configs, inconsistent patching, ad-hoc hardening. 
  Supplier sprawl: multiple POS, app and payments vendors with uneven security maturity. 

• Fragile update paths: patch rollouts without rollback plans, limited inventory of software components. 

What to prioritise this quarter 

• Asset & software bill of materials (SBOM) baseline for store tech and customer apps. 

• Secure update mechanism for POS, kiosks and mobile apps, with signed updates and staged rollouts. 

• Vulnerability disclosure policy (VDP) and intake workflow; publish the security support period for customer apps and connected devices. 

• Contract addenda for CRA with key vendors: disclosure timelines, patch SLAs, evidence of conformity assessments. 

Patch MTTR for store devices; % of assets with SBOM coverage; % of vendors under CRA-aligned clauses; % of apps with in-app update integrity checks.

KPIs that matter 

If you need help with compliance and making sure you’re well prepared for CRA, make sure you see our retail offer.

With our support, you get extensive security assessments and that evaluate your readiness not only for CRA, but also for cybersecurity attacks and breaches.

Consumer goods 

Manufacturers of wearables, toys, home appliances, entertainment devices and accessories ship the very products the CRA targets. Expectations include secure-by-design, secure defaults, vulnerability handling and supported updates across expected product lifetime. If you also sell into the UK, PSTI duties apply in parallel. 

Where gaps typically appear 

• Default or equivalent credentials in firmware and companion apps. 

• No declared security support period or unclear end-of-life posture. 

• OTA update channels without integrity checks or version pinning. 

• Third-party code (SDKs, OSS) with unknown provenance and no SBOM traceability. 

What to prioritise this quarter 

• Threat modelling and security requirements at product definition; block releases that lack a VDP, SBOM and signed update pipeline. 

• Hardening baselines: remove default passwords, lock debug interfaces, enforce least privilege, encrypt data in transit and at rest. 

• Secure OTA: signed packages, anti-rollback, fail-safe recovery, telemetry for update status. 

• Support & EOL policy: publish security support timelines per model and language-localise customer communications. 

KPIs that matter 

% of models with signed OTA; % of components with SBOM and licence clearance; vulnerability MTTR by severity; % of releases passing threat-model gate. 

Hospitality

Hotels and venues rely on guest-facing apps, property-management systems, smart locks and room controls, CCTV, building automation and payments. Many are networked and remotely manageable, increasing exposure. 

Where gaps typically appear 

• IoT in guest areas (locks, thermostats, TVs) running vendor defaults or old firmware. 

• Third-party integrations between booking engines, PMS, keyless entry and payment processors without end-to-end security testing. 

• Limited incident telemetry from room devices, making detection and response slow. 

What to prioritise this quarter 

• Zoning and zero-trust for guest-facing devices: isolate networks, restrict east-west traffic, rotate credentials at scale. 

• Vendor conformance profiling: require CRA-aligned evidence for smart-room and PMS suppliers; include patch SLA and coordinated disclosure in contracts. 

• Golden image & fleet playbooks for room devices with scheduled updates, health checks and rapid rollback. 

• Breach-ready comms: predefined notices for guests about security updates and incident handling. 

KPIs that matter 

% of smart-room devices on current baseline; time to patch critical vulnerabilities; % of suppliers with validated conformity evidence; incident means time to detect across guest networks. 

Travel 

Airlines, airports and travel platforms operate high-volume, high-availability systems: booking and loyalty apps, kiosks, baggage and sensor networks, crew devices and partner APIs. Many components are “products with digital elements” placed on EU markets. 

Where gaps typically appear 

• API and partner connectivity with uneven authentication and rate-limiting. 

• Kiosk and self-service fleets with mixed firmware levels and weak physical protections. 

• Legacy modules in customer apps and loyalty platforms without SBOM visibility. 

What to prioritise this quarter 

• API security baselines: strong auth, signed requests, schema validation, behavioural throttling and automated discovery. 

• Kiosk hardening & updates: signed boot, device attestation, port lockdown, tamper logging and staged patching windows. 

• Supply-chain assurance: SBOM mandates for all SDKs, coordinated disclosure terms, and pre-prod fuzzing for critical user flows. 

• Incident reporting runbook aligned to CRA obligations, with clear roles for product, security and legal teams. 

KPIs that matter 

% of critical APIs with contract tests and schema enforcement; kiosk compliance rate; % of third-party SDKs with SBOM and vulnerability watch; vulnerability MTTR in mobile apps. 

Example quick-start roadmaps 

Use these as inserts in your internal plans or as annexes to the article. 

Retail and hospitality 

Week 1–4: asset census + SBOM sweep; harden POS/kiosk gold images; publish VDP. 

Week 5–9: signed update channels; network zoning for guest/store IoT; vendor contract addenda. 

Week 10–14: incident drill; evidencing pack for two flagship locations; board-level KPI dashboard. 

Consumer goods  

Week 1–4: threat model + security requirements at product gate; remove default creds; OTA signing. 

Week 5–9: SBOM automation in CI; EOL and support policy; customer-facing security page per model. 

Week 10–14: coordinated disclosure playbook; conformity evidence folder; dry-run audit. 

Travel  

Week 1–4: API inventory and risk tiering; kiosk hardening baseline; mobile app SBOM. 

Week 5–9: contract tests and schema enforcement on critical APIs; signed-boot and attestation on kiosks. 

Week 10–14: incident reporting rehearsal; supplier assurance reviews; compile technical file. 

Running this as a programme 

Give CRA readiness clear ownership. Product leaders should be accountable for the technical file and user disclosures; security engineering for threat modelling, update integrity and SBOM automation; compliance for evidence and liaison; legal and procurement for supplier obligations; and incident teams for regulatory reporting. Report a small set of programme-level metrics to leadership so progress is visible, and trade-offs are explicit. 

Programme KPIs: 

• Patch MTTR by severity 

• SBOM coverage per product and release 

• % suppliers under CRA clauses with evidence provided 

• % releases passing security gates (threat model, SBOM, signed update, VDP present) 

• % devices within hardened baseline 

RACI snapshot: 

• Product owner: accountable for Technical File completeness and user disclosures 

• Security engineering: responsible for threat modelling, SBOM automation, update signing 

• Compliance lead: responsible for conformity evidence, assessment liaison 

• Legal/procurement: responsible for supplier clauses and enforcement 

• CERT/IR team: responsible for vulnerability/incident reporting and advisories 

Timeline to plan against 

Stand up your disclosure channel, supplier obligations and SBOM automation now, and compile a first complete technical file this quarter. Prepare for time-bound vulnerability reporting from late 2026. By December 2027, ensure every product placed on the EU market has demonstrable secure-by-design controls, an operational signed-update mechanism, a published support period and a complete technical file. 

Does the Cyber Resilience Act apply to SaaS?

expand_more

It can, if your service includes distributed software (desktop/mobile clients) or connected devices placed on the EU market. Purely hosted services without a “product” element may instead be covered by NIS2.

How long must we provide security updates?

expand_more

For the declared support period appropriate to the product; you must communicate it to users and keep an auditable record.

Do mobile apps count as “products with digital elements”?

expand_more

Yes, when placed on the EU market (e.g., via app stores). You’ll need secure-by-design controls, a VDP and timely patching.

We’re UK-only – do we need CRA?

expand_more

No. But once your product is placed on the EU market (directly or through partners), CRA applies alongside any PSTI duties.

How CRA fits with other laws?

expand_more

CRA governs the security of the product itself. If you operate essential or important services, your organisation may also be subject to NIS2, which focuses on operational resilience and incident reporting for the service. If personal data is involved, GDPR obligations around breach notification and privacy-by-design still apply. For UK sales, PSTI adds consumer-IoT-specific duties. The most efficient approach is to set your product baseline to CRA; it aligns well with PSTI and reduces duplication in NIS2/GDPR controls.

How long must we provide updates?

expand_more

For the support period you declare as appropriate for the product; communicate it up front and honour it.