قانون المرونة السيبرانية مقابل قانون PSTI: الاختلافات الرئيسية والامتثال والعقوبات

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: مقارنة جنبًا إلى جنب 

جانب	قانون PSTI البريطاني	EU CRA
الاختصاص والنطاق	ينطبق فقط داخل المملكة المتحدة. يستهدف المصنّعين غير البريطانيين الذين يبيعون أجهزة إنترنت الأشياء أو الأجهزة الذكية في المملكة المتحدة.	ينطبق على جميع الدول الأعضاء الـ 27 في الاتحاد الأوروبي. يغطي المصنّعين من داخل الاتحاد الأوروبي وخارجه الذين يقدمون منتجات ذات عناصر رقمية في الاتحاد الأوروبي.
المنتجات المشمولة	منتجات المستهلك «القابلة للاتصال»: أجهزة إنترنت الأشياء أو الأجهزة الذكية المتصلة بالإنترنت أو بشبكة منزلية.	جميع المنتجات التي تحتوي على عناصر رقمية: الأجهزة أو البرمجيات التي يمكنها الاتصال بجهاز أو شبكة. تشمل الأنظمة الاستهلاكية والصناعية على حد سواء.
متطلبات الأمان الرئيسية	ثلاثة التزامات أساسية: عدم وجود كلمات مرور افتراضية، ووسيلة للإبلاغ عن الثغرات، والشفافية بشأن فترات التحديث.	أمان دورة الحياة الكاملة: مبادئ الأمان حسب التصميم وحسب الإعداد الافتراضي، وتقييم المخاطر، وإدارة الثغرات الأمنية، والإفصاح الإلزامي، والتحديثات في الوقت المناسب.
عملية الامتثال	الإقرار الذاتي من خلال بيان الامتثال. لا حاجة لاختبار طرف ثالث.	تختلف تقييمات المطابقة حسب المخاطر. قد تتطلب المنتجات الحيوية شهادة مستقلة قبل دخول سوق الاتحاد الأوروبي.
سلطة الإنفاذ	المكتب البريطاني لسلامة المنتجات والمعايير (OPSS).	سلطات مراقبة السوق الوطنية في كل دولة عضو في الاتحاد الأوروبي.
الغرامات	ما يصل إلى 10 ملايين جنيه إسترليني أو 4% من حجم الأعمال العالمي (أيهما أعلى) وغرامات يومية تصل إلى 20,000 جنيه إسترليني.	ما يصل إلى 10 ملايين جنيه إسترليني أو 4% من حجم الأعمال العالمي (أيهما أعلى) وغرامات يومية تصل إلى 20,000 جنيه إسترليني. تصل إلى 15 مليون يورو أو 2.5% من حجم الأعمال العالمي للمخالفات الجسيمة؛ والفئات الأدنى عند 10 ملايين يورو/2% و5 ملايين يورو/1%.
الجدول الزمني	ساري اعتبارًا من أبريل 2024 (اكتملت الفترة الانتقالية).	دخل حيز التنفيذ في ديسمبر 2024. الامتثال الإلزامي بحلول ديسمبر 2027.

متى يجب على الشركات البريطانية الامتثال لقانون المرونة السيبرانية؟ 

على الرغم من أن المملكة المتحدة لم تعد جزءًا من الاتحاد الأوروبي، فإن قانون المرونة السيبرانية ينطبق على الشركات البريطانية التي تبيع أو توزع أو تقدم منتجات ذات عناصر رقمية لعملاء الاتحاد الأوروبي.

إذا كانت مؤسستك تطور أو تبيع برمجيات أو أجهزة متصلة أو أنظمة رقمية تُطرح في سوق الاتحاد الأوروبي، بشكل مباشر أو عبر الموزعين، فإنك تندرج ضمن نطاق CRA.

وبعبارة أخرى، إذا قدمت خدماتك خارج المملكة المتحدة، وكانت تلك الخدمات أو المنتجات متاحة في دول الاتحاد الأوروبي، فيجب عليك الامتثال لقانون المرونة السيبرانية.

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. 

بالنسبة للشركات البريطانية، يعني هذا التخطيط لما يلي:

• تحديد جميع المنتجات الرقمية المقدمة في أسواق الاتحاد الأوروبي.

• دمج ممارسات الأمان حسب التصميم عبر دورة حياة التطوير.

• توثيق تدابير الأمن السيبراني وخطط الاستجابة للحوادث.

• استعد لتقييمات المطابقة، خاصة إذا كانت منتجاتك تقع ضمن الفئات الحرجة.

قد يعني الفشل في التصرف مبكرًا الحظر من البيع في سوق الاتحاد الأوروبي أو مواجهة عقوبات كبيرة بمجرد بدء التنفيذ.

متى لا ينطبق قانون المرونة السيبرانية؟

هناك بعض الحالات التي لا ينطبق فيها CRA:

• لا وصول إلى سوق الاتحاد الأوروبي: إذا لم تكن منتجاتك أو برمجياتك متاحة في الاتحاد الأوروبي، فلا تنطبق التزامات CRA.

• القطاعات المنظمة بالفعل: تُستثنى الأجهزة الطبية وأنظمة السيارات ومنتجات الطيران المدني لأنها تخضع لقواعد مخصصة للأمن السيبراني ضمن الأطر الأوروبية القائمة.

• برمجيات مفتوحة المصدر غير تجارية: تُستثنى المشاريع مفتوحة المصدر المطورة أو الموزعة خارج النشاط التجاري. ومع ذلك، بمجرد دمجها في منتج تجاري، ينطبق قانون CRA.
• نماذج الخدمة البحتة: قد تخضع المنتجات السحابية أو منتجات SaaS التي لا يوجد لها "منتج" مادي أو رقمي مطروح في السوق لقوانين أخرى (مثل توجيه NIS2) بدلاً من CRA.

العقوبات المترتبة على عدم الامتثال 

يفرض كل من الإطارين البريطاني والأوروبي عقوبات صارمة على عدم الامتثال.

بموجب قانون PSTI: 

• غرامات تصل إلى10 ملايين جنيه إسترليني أو 4% من الإيرادات السنوية العالمية، أيهما أعلى.

• غرامات يومية تصل إلى£20,000 بسبب عدم الامتثال المستمر.

• احتمال الاستدعاء أو إشعارات الإيقاف للمنتجات الموجودة بالفعل في السوق.

بموجب قانون المرونة السيبرانية: 

• حتى15 مليون يورو أو 2.5% من حجم الأعمال العالمي للانتهاكات الجسيمة.

• 10 ملايين يورو أو 2% للمخالفات الأقل.

• 5 ملايين يورو أو 1% تقديم معلومات كاذبة أو مضللة للسلطات.

• يمكن للجهات التنظيمية الوطنية أن تأمر بسحب المنتجات من السوق أو استدعائها للمنتجات غير المطابقة.

بالإضافة إلى العقوبات المالية، يخاطر عدم الامتثال بضرر السمعة وفقدان العملاء والاستبعاد من واحدة من أكبر الأسواق الرقمية في العالم.

كيف يبدو الامتثال العملي؟ 

تعامل مع جاهزية CRA كانضباط منتج بدلاً من كونها مجرد إجراءات ورقية.

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

يقدم CRA إبلاغًا محددًا زمنيًا عن الثغرات الأمنية المستغلة فعليًا أو الخطيرة والحوادث الجسيمة.

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. 

القطاعات التي ينبغي أن تعطي الأولوية للجاهزية لـ CRA

التجزئة

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. 

أين تظهر الفجوات عادةً

• أسطول الأجهزة غير المُدارة في المتاجر: إعدادات افتراضية ضعيفة، وتصحيح غير متسق، وتقوية ارتجالية.
  تشتت الموردين: عدة موردي نقاط بيع وتطبيقات ومدفوعات بمستويات نضج أمني متفاوتة.

• مسارات تحديث هشة: طرح التصحيحات دون خطط للتراجع، ومخزون محدود من مكونات البرمجيات.

ما يجب إعطاؤه الأولوية هذا الربع

• خط الأساس لقائمة الأصول والبرمجيات (SBOM) لتقنيات المتاجر وتطبيقات العملاء.

• آلية تحديث آمنة لنقاط البيع والأكشاك والتطبيقات الجوّالة، مع تحديثات موقّعة وإطلاق تدريجي.

• سياسة الإفصاح عن الثغرات (VDP) وسير عمل الاستقبال؛ ونشر فترة دعم الأمان لتطبيقات العملاء والأجهزة المتصلة.

• ملاحق تعاقدية لـ CRA مع الموردين الرئيسيين: الجداول الزمنية للإفصاح، اتفاقيات مستوى خدمة التصحيحات، أدلة تقييمات المطابقة.

متوسط وقت الإصلاح (MTTR) لأجهزة المتاجر؛ نسبة الأصول التي تغطيها قائمة مكونات البرمجيات (SBOM)؛ نسبة الموردين الخاضعين لبنود متوافقة مع CRA؛ نسبة التطبيقات التي تتضمن فحوصات سلامة التحديثات داخل التطبيق.

مؤشرات الأداء الرئيسية المهمة

إذا كنت بحاجة إلى المساعدة في الامتثال وضمان استعدادك الجيد لـ CRA، فتأكد من الاطلاع على التجزئة العرض.

بدعمنا، تحصل على تقييمات أمنية شاملة تُقيّم جاهزيتك ليس فقط لقانون 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 دون فحوصات السلامة أو تثبيت الإصدارات.

• كود الطرف الثالث (SDKs, OSS) ذات مصدر غير معروف وبدون إمكانية تتبع SBOM.

ما يجب إعطاؤه الأولوية هذا الربع

• نمذجة التهديدات ومتطلبات الأمان عند تعريف المنتج؛ حظر الإصدارات التي تفتقر إلى VDP وSBOM وخط إصدار موقّع.

• خطوط الأساس للتحصين: إزالة كلمات المرور الافتراضية، وقفل واجهات التصحيح، وفرض أقل امتياز، وتشفير البيانات أثناء النقل وفي حالة السكون.

• التحديثات اللاسلكية الآمنة: حزم موقّعة، ومقاومة للتراجع، واسترداد آمن عند الفشل، وقياس عن بُعد لحالة التحديث.

• سياسة الدعم ونهاية العمر التشغيلي: نشر الجداول الزمنية لدعم الأمان لكل طراز وتعريب اتصالات العملاء لغويًا.

مؤشرات الأداء الرئيسية المهمة

نسبة الطُرز المزودة بتحديثات OTA موقعة؛ نسبة المكونات المزودة بـ SBOM وإخلاء المسؤولية عن التراخيص؛ متوسط وقت الإصلاح للثغرات حسب الخطورة؛ نسبة الإصدارات التي تجتاز بوابة نموذج التهديد.

الضيافة

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. 

أين تظهر الفجوات عادةً

• إنترنت الأشياء في مناطق الضيوف (الأقفال، والثرموستات، وأجهزة التلفزيون) التي تعمل بالإعدادات الافتراضية للمورّد أو ببرامج ثابتة قديمة.

• تكاملات مع أطراف ثالثة بين محركات الحجز وأنظمة إدارة العقارات والدخول بدون مفاتيح ومعالجات الدفع دون اختبار أمني شامل من البداية إلى النهاية.

• قياس عن بعد محدود للحوادث من أجهزة الغرفة، مما يجعل الكشف والاستجابة بطيئين.

ما يجب إعطاؤه الأولوية هذا الربع

• التقسيم والثقة الصفرية للأجهزة الموجهة للضيوف: اعزل الشبكات، وقيّد حركة المرور شرق-غرب، وبدّل بيانات الاعتماد على نطاق واسع.

• تحليل مطابقة الموردين: اشترط أدلة متوافقة مع CRA لموردي الغرف الذكية وأنظمة إدارة العقارات (PMS)؛ وضمّن اتفاقية مستوى خدمة للتصحيحات والإفصاح المنسق في العقود.

• الصورة الذهبية وأدلة الأسطول لأجهزة الغرف مع تحديثات مجدولة وفحوصات الحالة والتراجع السريع.

• اتصالات جاهزة للاختراق: إشعارات محددة مسبقًا للضيوف حول تحديثات الأمان والتعامل مع الحوادث.

مؤشرات الأداء الرئيسية المهمة

نسبة أجهزة الغرف الذكية على الخط الأساسي الحالي؛ الوقت اللازم لمعالجة الثغرات الأمنية الحرجة؛ نسبة الموردين الذين لديهم أدلة مطابقة معتمدة؛ متوسط الوقت اللازم لاكتشاف الحوادث عبر شبكات الضيوف.

السفر 

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. 

أين تظهر الفجوات عادةً

• الاتصال عبر واجهات برمجة التطبيقات والشركاء مع مصادقة غير متسقة وتحديد معدل غير متسق.

• أسطول الأكشاك والخدمة الذاتية مع مستويات برامج ثابتة مختلطة وحمايات مادية ضعيفة.

• الوحدات القديمة في تطبيقات العملاء ومنصات الولاء دون رؤية SBOM.

ما يجب إعطاؤه الأولوية هذا الربع

• خطوط الأساس لأمن واجهات برمجة التطبيقات: مصادقة قوية، وطلبات موقّعة، والتحقق من صحة المخطط، وتحديد معدل السلوك، والاكتشاف الآلي.

• تقوية وتحديثات أجهزة الكشك: الإقلاع الموقّع، وإثبات هوية الجهاز، وإغلاق المنافذ، وتسجيل العبث، ونوافذ الترقيع المرحلية.

• ضمان سلسلة التوريد: تفويضات SBOM لجميع مجموعات تطوير البرمجيات SDK، وشروط الإفصاح المنسق، والاختبار العشوائي قبل الإنتاج لتدفقات المستخدم الحرجة.

• دليل تشغيل الإبلاغ عن الحوادث بما يتوافق مع التزامات قانون المرونة الإلكترونية، مع أدوار واضحة لفرق المنتج والأمن والقانون.

مؤشرات الأداء الرئيسية المهمة

نسبة واجهات API الحرجة التي تخضع لاختبارات العقود وتطبيق المخططات؛ معدل الامتثال للأكشاك؛ نسبة حزم SDK الخارجية التي تتضمن SBOM ومراقبة الثغرات؛ متوسط زمن الإصلاح للثغرات في تطبيقات الجوال.

أمثلة على خرائط الطريق للبدء السريع 

استخدم هذه كملاحق في خططك الداخلية أو كمرفقات للمقال.

التجزئة والضيافة

الأسبوع 1–4: جرد الأصول + فحص SBOM؛ تحصين الصور الذهبية لنقاط البيع/الأكشاك؛ نشر VDP.

الأسبوع 5–9: قنوات تحديث موقّعة؛ تقسيم الشبكة إلى مناطق لإنترنت الأشياء الخاص بالضيوف والمتجر؛ ملاحق عقود الموردين.

الأسبوع 10–14: تمرين على الحوادث؛ حزمة أدلة لموقعين رئيسيين؛ لوحة مؤشرات الأداء على مستوى مجلس الإدارة.

السلع الاستهلاكية

الأسبوع 1–4: نموذج التهديد + متطلبات الأمان عند بوابة المنتج؛ إزالة بيانات الاعتماد الافتراضية؛ توقيع التحديثات عبر الهواء (OTA).

الأسبوع 5–9: أتمتة SBOM في CI؛ سياسة EOL والدعم؛ صفحة أمنية موجهة للعملاء لكل طراز.

الأسبوع 10–14: دليل الإفصاح المنسق؛ مجلد أدلة المطابقة؛ التدقيق التجريبي.

السفر

الأسبوع 1–4: جرد API وتصنيف المخاطر؛ خط أساس تقوية الأكشاك؛ قائمة مكونات برمجيات تطبيق الجوال (SBOM).

الأسبوع 5–9: اختبارات العقود وفرض المخططات على واجهات API الحرجة؛ والتمهيد الموقّع والتصديق على الأكشاك.

الأسبوع 10–14: تدريب على الإبلاغ عن الحوادث؛ مراجعات ضمان الموردين؛ تجميع الملف الفني.

إدارة هذا كبرنامج 

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 مع تقديم الأدلة

• % الإصدارات اجتياز بوابات الأمان (نموذج التهديد، SBOM، التحديث الموقّع، وجود VDP)

• % الأجهزة ضمن خط أساس معزّز

لمحة عن RACI:

• مالك المنتج: مسؤول عن اكتمال الملف الفني وإفصاحات المستخدم

• هندسة الأمن: مسؤولة عن نمذجة التهديدات، وأتمتة SBOM، وتوقيع التحديثات

• مسؤول الامتثال: مسؤول عن أدلة المطابقة، والتواصل بشأن التقييم

• الشؤون القانونية/المشتريات: مسؤول عن بنود الموردين وإنفاذها

• فريق الاستجابة للحوادث الأمنية CERT/IR: مسؤول عن الإبلاغ عن الثغرات الأمنية/الحوادث والإشعارات

جدول زمني للتخطيط بناءً عليه 

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. 

هل ينطبق قانون المرونة السيبرانية على 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

لفترة الدعم المعلنة المناسبة للمنتج؛ يجب عليك إبلاغ المستخدمين بها والاحتفاظ بسجل قابل للتدقيق.

هل تُحتسب تطبيقات الهاتف المحمول ضمن "المنتجات ذات العناصر الرقمية"؟

expand_more

نعم، عند طرحه في سوق الاتحاد الأوروبي (على سبيل المثال، عبر متاجر التطبيقات). ستحتاج إلى ضوابط الأمان من مرحلة التصميم، وبرنامج الإفصاح عن الثغرات (VDP)، والتصحيح في الوقت المناسب.

نحن في المملكة المتحدة فقط – هل نحتاج إلى قانون المرونة السيبرانية؟

expand_more

لا. ولكن بمجرد طرح منتجك في سوق الاتحاد الأوروبي (مباشرة أو من خلال الشركاء)، ينطبق CRA إلى جانب أي واجبات PSTI.

كيف يتوافق 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

لفترة الدعم التي تعلنها كمناسبة للمنتج؛ تواصل بها مسبقاً والتزم بها.