Cybersecurity Resilience Act מול PSTI Act: הבדלים עיקריים, עמידה בדרישות וקנסות

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 מול PSTI Act: השוואה זה לצד זה 

היבט	חוק PSTI הבריטי	EU CRA
סמכות שיפוט ותחום פריסה	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.
מוצרים בהיקף	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.
דרישות אבטחה עיקריות	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.
תהליך עמידה ברגולציה	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.
רשות אכיפה	UK Office for Product Safety and Standards (OPSS).	National Market Surveillance Authorities in each EU member state.
קנסות	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%.
ציר זמן	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. 

עבור חברות בבריטניה, המשמעות היא תכנון:

• 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: 

• אין גישה לשוק האיחוד האירופי: If your products or software are not made available in the EU, CRA obligations do not apply. 

• מגזרים שכבר מוסדרים: Medical devices, automotive systems, and civil aviation products are exempt since they are governed by dedicated cybersecurity rules under existing EU frameworks. 

• תוכנה בקוד פתוח לא מסחרית: Open-source projects developed or distributed outside commercial activity are excluded. However, once integrated into a commercial product, the CRA applies. 
• מודלים של שירות טהור: 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.  

עיצומים בגין אי-עמידה בדרישות 

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

במסגרת חוק PSTI: 

• קנסות של עד10 מיליון ליש"ט או 4% of global annual revenue, whichever is higher. 

• קנסות יומיים של עד£20,000 בגין אי-ציות מתמשך.

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

במסגרת חוק החוסן הקיברנטי: 

• עד15 מיליון אירו או 2.5% מהמחזור העולמי עבור הפרות חמורות.

• 10 מיליון אירו או 2% עבור הפרות קלות יותר.

• 5 מיליון אירו או 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. 

איך נראית עמידה ברגולציה באופן מעשי? 

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. 

ספקים הם חלק מהמוצר שלך.

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. 

מי נושא בחובה?

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. 

מחלקות מוצר ומסלולי הערכה

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. 

ניטור לאחר השוק

עמידה ב-CRA נמשכת גם לאחר השחרור. 

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.  

דיווח על פגיעויות במסגרת ה-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. 

מה המשתמשים שלכם צריכים לראות

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.  

מקרי קצה בתוכנה ובשירות

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 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. 

היכן מופיעים פערים בדרך כלל

• מכשירים לא מנוהלים בחנויות: weak default configs, inconsistent patching, ad-hoc hardening. 
  ריבוי ספקים: multiple POS, app and payments vendors with uneven security maturity. 

• מסלולי עדכון שבירים: patch rollouts without rollback plans, limited inventory of software components. 

על מה לתעדף ברבעון הזה

• Asset & software bill of materials (SBOM) baseline עבור טכנולוגיות חנויות ואפליקציות לקוחות.

• מנגנון עדכון מאובטח for POS, kiosks and mobile apps, with signed updates and staged rollouts. 

• מדיניות חשיפת פגיעויות (VDP) and intake workflow; publish the security support period for customer apps and connected devices. 

• נספחים לחוזה עבור 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.

מדדי ביצוע קריטיים שחשובים

If you need help with compliance and making sure you’re well prepared for CRA, make sure you see our קמעונאי הצעה.

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

מוצרי צריכה 

Manufacturers of wearables, toys, home appliances, entertainment devices and accessories ship בדיוק המוצרים ש-CRA מתמקדת בהם. 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. 

היכן מופיעים פערים בדרך כלל

• פרטי גישה ברירת מחדל או שקולים בקושחה ובאפליקציות נלוות.

• לא הוצהרה תקופת תמיכת אבטחה או עמדת סוף-מחזור-חיים לא ברורה.

• ערוצי עדכון OTA without integrity checks or version pinning. 

• קוד צד שלישי (SDKs, OSS) with unknown provenance and no SBOM traceability. 

על מה לתעדף ברבעון הזה

• מודל איומים ודרישות אבטחה at product definition; block releases that lack a VDP, SBOM and signed update pipeline. 

• קווי בסיס להקשחה: 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. 

• מדיניות תמיכה ו-EOL: publish security support timelines per model and language-localise customer communications. 

מדדי ביצוע קריטיים שחשובים

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

אירוח

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. 

היכן מופיעים פערים בדרך כלל

• IoT באזורי אורחים (locks, thermostats, TVs) running vendor defaults or old firmware. 

• אינטגרציות עם צדדים שלישיים between booking engines, PMS, keyless entry and payment processors without end-to-end security testing. 

• טלמטריה מוגבלת של אירועים from room devices, making detection and response slow. 

על מה לתעדף ברבעון הזה

• אזורים ואפס אמון for guest-facing devices: isolate networks, restrict east-west traffic, rotate credentials at scale. 

• פרופיל עמידה בדרישות ספקים: require CRA-aligned evidence for smart-room and PMS suppliers; include patch SLA and coordinated disclosure in contracts. 

• תמונת זהב ומדריכי צי for room devices with scheduled updates, health checks and rapid rollback. 

• תקשורת מוכנה לאירועי אבטחה: predefined notices for guests about security updates and incident handling. 

מדדי ביצוע קריטיים שחשובים

% 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. 

נסיעות 

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. 

היכן מופיעים פערים בדרך כלל

• קישוריות API ושותפים with uneven authentication and rate-limiting. 

• ציי קיוסקים ושירות עצמי with mixed firmware levels and weak physical protections. 

• מודולים מדור קודם in customer apps and loyalty platforms without SBOM visibility. 

על מה לתעדף ברבעון הזה

• קווי בסיס לאבטחת API: strong auth, signed requests, schema validation, behavioural throttling and automated discovery. 

• הקשחת קיוסק ועדכונים: signed boot, device attestation, port lockdown, tamper logging and staged patching windows. 

• הבטחת שרשרת אספקה: SBOM mandates for all SDKs, coordinated disclosure terms, and pre-prod fuzzing for critical user flows. 

• נוהל הפעלה לדיווח אירועים aligned to CRA obligations, with clear roles for product, security and legal teams. 

מדדי ביצוע קריטיים שחשובים

% 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. 

דוגמאות למפות דרכים להתחלה מהירה 

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

קמעונאות ואירוח

שבוע 1–4: asset census + SBOM sweep; harden POS/kiosk gold images; publish VDP. 

שבוע 5–9: signed update channels; network zoning for guest/store IoT; vendor contract addenda. 

שבוע 10–14: incident drill; evidencing pack for two flagship locations; board-level KPI dashboard. 

מוצרי צריכה

שבוע 1–4: threat model + security requirements at product gate; remove default creds; OTA signing. 

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

שבוע 10–14: coordinated disclosure playbook; conformity evidence folder; dry-run audit. 

נסיעות

שבוע 1–4: API inventory and risk tiering; kiosk hardening baseline; mobile app SBOM. 

שבוע 5–9: contract tests and schema enforcement on critical APIs; signed-boot and attestation on kiosks. 

שבוע 10–14: incident reporting rehearsal; supplier assurance reviews; compile technical file. 

ניהול זה כתוכנית 

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. 

מדדי תוכנית: 

• תיקון MTTR לפי חומרה

• כיסוי SBOM לפי מוצר וגרסה

• % ספקים תחת סעיפי CRA עם ראיות מסופקות

• % מהדורות passing security gates (threat model, SBOM, signed update, VDP present) 

• % מכשירים בתוך קו בסיס מוקשח

תמונת מצב RACI:

• בעל המוצר: accountable for Technical File completeness and user disclosures 

• הנדסת אבטחה: responsible for threat modelling, SBOM automation, update signing 

• אחראי ציות: responsible for conformity evidence, assessment liaison 

• משפטי/רכש: responsible for supplier clauses and enforcement 

• צוות CERT/IR: responsible for vulnerability/incident reporting and advisories 

לוח זמנים לתכנון 

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.

כמה זמן עלינו לספק עדכוני אבטחה?

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.

אנחנו פועלים בבריטניה בלבד – האם אנחנו זקוקים ל-CRA?

expand_more

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

כיצד CRA משתלב עם חוקים אחרים?

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.

כמה זמן עלינו לספק עדכונים?

expand_more

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