Cyber Resilience Act (Regulamentul 2024/2847) — obligații pentru produse cu element digital, vulnerability disclosure, SBOM și security updates

CRA, Regulamentul (UE) 2024/2847, a fost adoptat la 23 octombrie 2024 și a intrat în vigoare la 11 decembrie 2024. Aplicare integrală a obligațiilor substanțiale: 11 decembrie 2027. Articolul 14 (raportare incidente active și vulnerabilități exploatate activ) se aplică deja de la 11 septembrie 2026 — deci unul dintre cele mai stringente deadlines pentru fabricanți este în următoarele 16 luni.

Ce e fundamental nou față de regimul anterior: CRA introduce CE marking pentru produse cu element digital, exact cum funcționa CE marking pentru securitatea fizică sau compatibilitatea electromagnetică. Securitatea cibernetică devine condiție de plasare pe piața UE.

TL;DR

• CRA acoperă “produse cu elemente digitale” (PDE) — hardware sau software cu conectare directă/indirectă la rețea sau dispozitiv.
• Trei clase: standard (auto-evaluare), important class I/II, critical (third-party assessment + certificare).
• Obligații substanțiale: secure-by-design, vulnerability handling 5 ani, security updates gratuite, SBOM, raportare incidente active la ENISA.
• Aplicare integrală 11 dec 2027; raportarea vulnerabilităților active deja de la 11 sept 2026.
• Sancțiuni: până la 15 milioane EUR sau 2,5% din cifra de afaceri.

Domeniul de aplicare — ce e produs cu element digital (PDE)

Articolul 3 definește PDE ca “orice produs software sau hardware și soluțiile sale de prelucrare a datelor de la distanță, inclusiv componentele software sau hardware care urmează să fie introduse pe piață separat”. Domeniul e larg intenționat. Acoperă:

• Toate dispozitivele IoT (de la routere și NVR-uri la frigidere conectate).
• Software comercial (sistemele de operare, aplicațiile, browserele, suite-urile de productivitate, tooling-ul dev).
• Componente hardware cu firmware (microcontrolere, plăci de bază).
• Soluții cloud-conectate vândute împreună cu hardware sau software.

Excepții importante (Art. 2):

• Dispozitive medicale (acoperite de MDR/IVDR).
• Vehicule cu motor (Reg. 2018/858, UNECE WP.29).
• Aviație (Reg. 2018/1139, EASA).
• Echipamente militare și securitate națională.
• Software open-source non-comercial (vezi mai jos).
• SaaS pur (acoperit de NIS2 și DORA).

Open-source — clarificare critică. Dezbaterea din 2023-2024 pe CRA s-a concentrat pe impactul asupra ecosistemului open-source. Compromisul final introduce conceptul de “open-source software steward” pentru proiecte non-comerciale și exclude software-ul OSS personal/contributiv. Doar software-ul OSS comercializat (oferit ca produs cu suport plătit) intră sub CRA.

Cele trei clase de produs

Articolul 7 plus Anexele III și IV împart PDE-urile în:

Clasa standard (default). Majoritatea produselor — laptop-uri obișnuite, software desktop, IoT consumer. Auto-evaluare a conformității de către fabricant + declarație UE de conformitate + CE marking. Aproximativ 90% din PDE-uri intră aici.

Important class I (Anexa III, Section 1). Produse cu rol senzitiv în lanțul de securitate. Lista include: parolă-managere, anti-malware, firewall-uri rețea, VPN-uri, sisteme management identitate, browsere cu funcții enterprise, password manageri în general. Cerere: auto-evaluare PE BAZA UNUI STANDARD ARMONIZAT (când va fi publicat) sau third-party assessment.

Important class II (Anexa III, Section 2). Produse mai sensibile: hypervizori, container runtime, sisteme PKI, sisteme HSM software, IDS/IPS. Cerere: third-party assessment obligatoriu.

Critical (Anexa IV). Listă mică de produse considerate critice pentru NIS2/CER: smart meters cu funcții de securitate, hardware tokens FIDO2, smartcards cu chip-uri sensibile. Certificare obligatorie sub schema EUCC sau echivalent.

Cele 13 cerințe substanțiale (Anexa I)

Anexa I listează 13 cerințe esențiale pe care orice PDE trebuie să le îndeplinească:

1. Secure-by-default. Configurația livrată implicit este sigură. Parolele admin nu sunt “admin/admin”.
2. Confidentiality protection — criptare tranzit + repaus pentru date sensibile.
3. Integrity protection — împotriva manipulării codului, datelor de configurare, datelor de utilizator.
4. Data minimisation — produsul colectează doar datele necesare funcționării.
5. Availability protection — împotriva DoS, inclusiv prin rate limiting.
6. Surface attack minimisation — porturi închise default, servicii dezactivate care nu sunt necesare.
7. Mitigare incident impact — segmentare logică, fail-safe defaults.
8. Logging și monitoring — evenimente relevante de securitate logate cu timestamp și retenție.
9. Mecanism update sigur, automatizat unde posibil, cu integritate verificată.
10. Patch policy — patches gratuite în “support period” minim 5 ani.
11. Vulnerability disclosure policy publică (security.txt + procedura).
12. Secure default cu efort minim utilizator — securitatea nu cere config avansat.
13. Mecanism de uninstall sigur care șterge corect datele.

Toate cele 13 sunt cerințe obligatorii. Fabricantul nu poate scoate produsul pe piață fără să le îndeplinească.

Vulnerability handling — Anexa I Section 2

Pe lângă cele 13 cerințe pe produs, fabricantul are obligații de proces:

• Identificare și documentare componente. SBOM (Software Bill of Materials) în format machine-readable (CycloneDX sau SPDX). Trebuie disponibil la cerere către autorități și trebuie actualizat la fiecare release.
• Patches gratuite și fără întârziere pentru vulnerabilitățile descoperite, pe durata “support period”.
• Testing efectiv și regulat — internal pen-testing, fuzzing, code analysis.
• Public disclosure coordonat — odată ce un patch e disponibil, publica info despre vulnerabilitate.
• Mecanism intern de a primi rapoarte de la cercetători (security.txt + bug bounty sau echivalent).
• Distribuire patches simultan la toți utilizatorii afectați.

Articolul 14 — raportare la ENISA în 24h/72h

Articolul 14, aplicabil de la 11 septembrie 2026, este probabil cea mai operațional incomodă cerință a CRA pentru fabricanți. Două categorii de raportare:

Vulnerabilități exploatate activ.

• Avertizare timpurie către ENISA (prin platforma single reporting): 24 ore de la conștientizare.
• Raport intermediar cu detalii și măsuri inițiale: 72 ore.
• Raport final cu cauza rădăcină și măsuri corectiv-permanente: 14 zile după mitigare.
• Notificare paralelă către utilizatori afectați.

Incidente serioase ce afectează securitatea PDE-ului.

• Avertizare timpurie: 24 ore.
• Notificare detaliată: 72 ore.
• Raport final: o lună.

Important: există o singură platformă centrală operată de ENISA (single reporting) — nu trebuie raportat separat în fiecare stat membru. CSIRT-urile naționale primesc copia.

CE marking pentru securitate cibernetică

Pentru prima dată, CE marking acoperă explicit cerințe de cybersecurity. Procesul:

1. Fabricant evaluează clasa produsului (standard / important / critical).
2. Aplică procedura conformitate corespunzătoare:
   • Standard: Module A (internal control) — auto-evaluare.
   • Important: Module B (EU-type examination) + Module C / Module H (full quality assurance).
   • Critical: Module H + certificare EUCC.
3. Întocmește documentația tehnică (SBOM, threat model, test reports, vulnerability disclosure policy).
4. Emite Declarația UE de conformitate.
5. Aplică marca CE pe produs sau ambalaj.
6. Înregistrează în baza de date EU NANDO (pentru clasele important/critical care folosesc Notified Body).

Sancțiuni — până la 15 milioane EUR sau 2,5%

Articolul 64 stabilește sancțiunile maxime:

• Încălcarea cerințelor esențiale (Anexa I): până la 15 milioane EUR sau 2,5% din cifra de afaceri globală.
• Încălcarea altor obligații (raportare, retragere produs): până la 10 milioane EUR sau 2%.
• Furnizare informații false către autorități: până la 5 milioane EUR sau 1%.

În plus, autoritatea poate ordona retragerea produsului de pe piață, distrugerea stocurilor și recall.

Cum ajută Lexnomia

Lexnomia include un modul CRA care:

• Inventar produse cu auto-clasificare (standard/important/critical).
• SBOM tracker integrat cu pipeline-ul CI/CD (CycloneDX + SPDX).
• Vulnerability handling workflow cu integrare GitHub/GitLab security advisories + CVE feed NVD.
• Template Art. 14 pentru raportare 24h/72h către ENISA.
• Cross-mapping cu ISO 27001:2022 (detalii) și NIS2 (checklist).

Vezi și articolul nostru pe SIEM on-premise cu LLM local pentru cerința 8 (logging și monitoring) din Anexa I.

Articole conexe

• Implementation NIS2 — checklist operațional pentru entități esențiale și importante
• ISO/IEC 27001:2022 — migrarea de la ediția 2013 cu cele 93 controale reorganizate
• De la 10 vulnerabilități la 0 în 5 zile: hardening-ul pre-producție al unei platforme juridice
• SIEM on-premise cu LLM local: AI incident analysis fără să spargi confidențialitatea
• Pillar Lexnomia — platforma EU de compliance suveran

Pași următori

Pentru o evaluare CRA readiness pentru produsele dvs. — pe pagina Lexnomia găsiți modulul CRA. Sau scrieți la contact pentru o discuție tehnică.

Referințe

• Regulamentul (UE) 2024/2847 (CRA) — text consolidat EUR-Lex
• European Commission — CRA implementation page
• ENISA — Coordinated Vulnerability Disclosure
• CycloneDX — SBOM specification oficial
• SPDX — Software Package Data Exchange