Ghid CRA pentru companiile din România

---

CRA este denumirea uzuală a Regulamentului (UE) 2024/2847↗, adoptat pe 23 octombrie 2024 și publicat în Jurnalul Oficial al UE pe 20 noiembrie 2024. Este prima lege din UE care impune, în mod obligatoriu, un nivel minim de securitate cibernetică pentru produsele cu elemente digitale (Cyber Resilience Act / EU CRA compliance). Până la CRA, securitatea unui produs era mai degrabă o promisiune de marketing. Acum devine o condiție legală de a putea vinde în Uniunea Europeană.

Regulamentul răspunde la două probleme concrete pe care piața nu le-a rezolvat singură:

• Produsele nu erau securizate din fabricație, cu vulnerabilități răspândite, configurări nesigure din cutie și actualizări de securitate întârziate sau inexistente.
• Clienții nu aveau cum să compare, pentru că nu puteau să își dea seama cât de sigur este un produs și nici cât timp va primi actualizări.

CRA mută securitatea din anexa de marketing în condiția de punere pe piață: un produs neconform nu primește marcaj CE și nu poate fi vândut legal în UE.

Partea importantă este calendarul. CRA a intrat în vigoare pe 10 decembrie 2024. Obligațiile de raportare se aplică deja din 11 septembrie 2026, iar aplicarea completă începe pe 11 decembrie 2027. Comisia a publicat pe 27 iulie 2026 primul set de orientări practice (guidance C(2026)5252), iar primele standarde armonizate sunt așteptate în T3 2026. Faza „mai avem timp" s-a terminat. Pentru orice produs software sau hardware care ajunge în UE, pregătirea ar trebui să înceapă acum.

---

Un punct esențial: CRA nu clasifică companii, clasifică produse. Nu există „companie importantă" sau „companie critică" în sensul acestei legi. Există produse importante și produse critice. O companie poate avea un produs în scop și altul în afara lui. Testul se aplică per artefact, conform Art. 2 și Art. 3 din regulament↗.

În esență, CRA se aplică produselor cu elemente digitale puse la dispoziție pe piața UE, a căror utilizare prevăzută sau previzibilă include o conexiune logică sau fizică directă ori indirectă la un dispozitiv sau la o rețea Art. 2(1)↗.

„Produs cu elemente digitale" înseamnă „un produs hardware sau software și soluțiile sale de prelucrare la distanță a datelor, inclusiv componente hardware sau software plasate separat pe piață" Art. 3(1)↗.

Ce intră în scop

• Software instalabil (aplicații desktop, mobile, SDK-uri, librării) furnizat comercial
• Firmware, sisteme de operare, echipamente de rețea, dispozitive IoT
• Componente plasate separat pe piață, inclusiv soluția de prelucrare la distanță necesară funcționării produsului (Art. 3(2))

Ce nu intră în scop

• SaaS pur, adică o aplicație doar din browser, fără nimic instalat la client. Este considerat serviciu, nu produs, și intră sub NIS2 sau DORA, nu sub CRA.
• Site-uri care nu susțin funcționalitatea unui produs și servicii cloud dezvoltate în afara responsabilității producătorului unui produs. Vezi Considerentul 12↗
• Software open-source furnizat fără activitate comercială, adică dezvoltare necomercială, fără monetizare
• Produse deja reglementate sectorial, de exemplu dispozitivele medicale sub MDR/IVDR

Cazul care creează cea mai multă confuzie

Cel mai frecvent scenariu care provoacă discuții este modelul de livrare. Iată un tabel rezumativ:

Regula practică: dacă livrezi ceva ce clientul rulează în mediul lui, acel ceva este produs. Dacă backend-ul este indispensabil ca produsul să își îndeplinească funcția, partea relevantă din backend intră și ea, conform definiției prelucrării la distanță.

Chiar dacă o companie este doar o componentă din lanțul de aprovizionare, nu este scutită. În România, la fel ca în tot restul UE, clienții enterprise supuși NIS2 vor cere deja dovezi CRA-like prin chestionare și clauze contractuale, chiar și pentru componente care formal ar fi „default". Practic, securitatea fiecărui furnizor este verificată oricum.

---

Clasificarea decide un singur lucru: cât de strictă este evaluarea prin care trebuie să treci. Nu schimbă lista de cerințe tehnice, pentru că cerințele esențiale din Anexa I se aplică tuturor, de la cel mai banal produs la cele mai critice.

Detaliile tehnice ale categoriilor se precizează prin acte de punere în aplicare ale Comisiei. Pentru CRA contează funcționalitatea de bază (core functionality). Un produs care integrează un firewall nu devine automat produs important Clasa II dacă funcția lui de bază nu este firewall. Nu este relevant un singur component, ci funcția produsului în ansamblu.

---

CRA descrie un traseu clar, liniar, cu responsabilitatea la producător, de la proiectare până la suport post-vânzare. Iată pașii, în ordine:

1. Analiza de risc și secure by design. Primul pas este înțelegerea produsului și a riscurilor implicate. Se identifică activele, amenințările și riscul asociat produsului, proporțional cu expunerea lui. Se aleg măsuri care reduc riscul la un nivel acceptabil și se documentează deciziile. Aceasta este baza pentru tot ce urmează.

2. Implementarea cerințelor esențiale (Anexa I).

• Partea I, pentru produs: fără vulnerabilități exploatabile cunoscute la livrare, configurare implicită sigură, protecția integrității și confidențialității, minimizarea suprafeței de atac, mecanisme de actualizare securizată
• Partea a II-a, pentru procese: gestionarea vulnerabilităților pe toată durata de viață a produsului, inclusiv SBOM (software bill of materials)

3. Testare și evaluare (Art. 32 și Anexa VII). Se verifică prin teste sau alte metode adecvate că produsul respectă cerințele relevante. Este o evaluare proporțională cu riscul. Metodologia o alege producătorul, dar trebuie să fie adecvată și documentată. Nu există o metodă impusă, există o obligație de a demonstra.

4. Documentația tehnică (Anexa VII). Se păstrează un dosar complet: descrierea produsului, arhitectura, analiza de risc, lista componentelor și SBOM, măsurile aplicate, rezultatele testelor, procedurile de gestionare a vulnerabilităților și perioada de suport. Autoritățile o pot cere oricând, până la 10 ani de la introducerea pe piață sau pe durata perioadei de suport, oricare e mai lungă.

5. Alegerea traseului de evaluare (Art. 32). În funcție de categoria produsului și de măsura în care au fost aplicate standarde armonizate, se alege autoevaluare, examinare UE de tip (Modul B+C) sau asigurarea completă a calității (Modul H). Producătorii de FOSS din Anexa III pot folosi autoevaluarea dacă documentația este publică la momentul punerii pe piață.

6. Autoevaluare vs. organism notificat, comparație directă

7. Standarde armonizate și certificarea europeană. Standardele armonizate (EN) publicate în JOUE oferă prezumția de conformitate. Dacă sunt aplicate integral, producătorul poate rămâne pe autoevaluare la Clasa I. Pentru Clasa II și Critice, ele nu scutesc de organism notificat sau certificare, dar simplifică demonstrația. Primele livrabile de standardizare sunt așteptate în T3 2026, iar până atunci traseul prin organism notificat este regula practică pentru produsele importante.

8. Declarația UE și marcajul CE. După evaluarea cu rezultat pozitiv, se întocmește declarația UE de conformitate (Anexele V-VI), se aplică marcajul CE și se pune produsul pe piață. Orice modificare substanțială cere o nouă evaluare, la același sau alt organism notificat, și poate duce la revizuirea certificatului.

---

Marcajul CE nu este linia de sosire. Punerea pe piață nu încheie obligațiile, ci le deschide pe cele din exploatare, pe toată perioada de suport declarată. Iată ce trebuie menținut:

• Identificarea și documentarea vulnerabilităților, inclusiv printr-un SBOM actualizat și o politică de divulgare coordonată. Se oferă un punct de contact public pentru raportări.
• Tratarea vulnerabilităților fără întârziere: evaluare, prioritizare și livrarea actualizărilor de securitate gratuite, separate de cele de funcționalitate unde e posibil.
• Testare efectivă și regulată. Formularea din regulament este „effective and regular tests" (Anexa I, Partea a II-a). În practică, ghidul BSI TR-03183 recomandă o abordare bazată pe risc și monitorizare continuă, nu securitate universală nedefinită. Pentru majoritatea echipelor, asta înseamnă scanări regulate, audit de cod și testare dinamică repetată, proporțional cu riscul produsului.
• Divulgarea publică a vulnerabilităților remediate, cu descriere și ghid de remediere.
• Distribuirea actualizărilor fără întârziere, cu mecanisme sigure și, unde e cazul, automate.

CRA cere un pentest?

Răspunsul corect este: nu pe nume, dar îl cere prin efect. CRA nu folosește nicăieri sintagma „test de penetrare" ca obligație nominală. Ceea ce cere este ca producătorul să demonstreze prin teste adecvate că cerințele esențiale sunt îndeplinite și să mențină un proces de tratare a vulnerabilităților pe toată durata de viață. În practică, testarea de securitate, inclusiv pentest sau audit de cod, este metoda standard prin care se dovedește „effective and regular tests" și se evaluează eficacitatea măsurilor.

Paginile care afirmă sec „CRA cere pentest anual obligatoriu" simplifică excesiv. Nu există obligație nominală de pentest, dar există obligația de a testa regulat și de a remedia, iar pentestul este calea cea mai directă de a o dovedi, mai ales pentru produsele importante și critice.

Între lansări, monitorizarea suprafeței expuse, a dependențelor și a permisiunilor rămâne singura cale de a prinde regresiile. Codul se schimbă zilnic, iar o evaluare anuală surprinde o singură zi. Securitatea este un proces continuu, nu un raport o dată pe an.

---

Raportarea: 24 de ore, 72 de ore, 14 zile sau o lună

De la 11 septembrie 2026 (Art. 14), producătorii raportează vulnerabilitățile exploatate activ și incidentele severe care afectează securitatea produsului. O fac prin Platforma Unică de Raportare (Single Reporting Platform, SRP), operată de ENISA, către CSIRT-ul statului unde au sediul principal. CSIRT-ul diseminează către celelalte CSIRT-uri unde produsul este disponibil. Fluxul este bine definit:

Două aspecte de reținut. Primul: obligația se aplică tuturor produselor deja puse pe piață, inclusiv celor lansate înainte de 11 decembrie 2027. Al doilea: în cazuri excepționale, justificate cibernetic, diseminarea către alte CSIRT-uri poate fi amânată temporar (act delegat din 11 decembrie 2025). Cele trei termene se cumulează. Niciunul nu îl înlocuiește pe cel anterior.

Calendarul complet

Produsele puse pe piață înainte de 11 decembrie 2027 rămân sub regimul vechi până la o modificare substanțială după acea dată. Dacă produsul nu este modificat, obligațiile nu îl prind imediat. Dacă se lansează o versiune majoră după 2027, atunci da.

Supraveghere și sancțiuni

Autoritățile naționale de supraveghere a pieței verifică conformitatea, pot cere documentația tehnică, pot dispune retragerea sau restricționarea produselor și aplică sancțiuni administrative.

Regulamentul stabilește plafoane proporționale cu cifra de afaceri, pe modelul GDPR/DMA, aplicate de statele membre:

• Încălcarea cerințelor esențiale și a obligațiilor de evaluare: până la 15 milioane EUR sau 2,5% din cifra de afaceri anuală mondială, oricare e mai mare
• Nerespectarea obligațiilor de raportare sau de informare: până la 10 milioane EUR sau 2%
• Furnizarea de informații incorecte sau incomplete către organismele notificate: până la 5 milioane EUR sau 1%

Cifrele exacte se stabilesc prin legislația națională de punere în aplicare. Plafoanele de mai sus sunt maximele cadrului UE. În afara amenzilor, documentarea corectă protejează compania după un incident. În cazul unei companii de securitate, încrederea clienților valorează mai mult decât orice plafon.

---

Checklist practic în 5 pași

În esență, totul se rezumă la cinci pași:

1. Cartografiază portofoliul per artefact. Pentru fiecare produs sau componentă livrată comercial în UE, decide: e produs CRA? Dacă da, care categorie (default, Important I, II sau Critic) și ce traseu de evaluare decurge de aici.
2. Fă un gap assessment pe Anexa I. Ia cerințele esențiale și evaluează onest: analiză de risc documentată, SBOM complet, proces de divulgare coordonată, canal public de raportare, mecanism de update securizat, perioadă de suport declarată.
3. Construiește dosarul tehnic din mers. Arhitectură, SBOM, rezultate de testare, dovezi de remediere. Adunate continuu, nu reconstituite la cererea autorității.
4. Testează înainte să te testeze altcineva. Rulează audit de cod și testare dinamică pe produsul real, nu pe demo, validează exploatabilitatea și păstrează dovezile. Retestează după remedieri și ține istoricul între versiuni.
5. Pregătește fluxul de raportare SRP. Definește ce înseamnă „vulnerabilitate exploatată activ" și „incident sever" pentru produsele tale, cine raportează în 24 sau 72 de ore, inclusiv în weekend, și cum urmărești cele 14 zile sau o lună.

Cum se leagă CRA de NIS2, DORA și GDPR

O întrebare frecventă este relația dintre CRA și reglementările existente. Iată un tabel de comparație:

Nu sunt patru legi separate, ci patru unghiuri din care UE privește aceeași realitate: produsul (CRA), organizația (NIS2), sectorul financiar (DORA) și datele personale (GDPR). Am detaliat separat Ghidul NIS2 pentru România↗ și Ghidul DORA pentru fintech↗, pentru aprofundare.

---

CRA transformă securitatea produsului din argument de vânzări în condiție de acces pe piață. Nu reglementează compania ca întreg, ci fiecare produs livrat comercial în UE care are o conexiune, de la aplicația mobilă la firmware-ul unui echipament de rețea. Clasificarea (default, Important, Critic) decide doar cât de strictă este evaluarea, nu dacă produsul trebuie securizat.

Metodologia este previzibilă: analiză de risc, cerințe esențiale, testare, dosar tehnic, evaluare (auto sau prin organism notificat) și marcaj CE. Apoi un ciclu de viață cu SBOM, patch-uri gratuite și raportare în 24 sau 72 de ore. Pentru majoritatea produselor business, autoevaluarea rămâne posibilă. Pentru produsele de securitate, ea depinde de existența standardelor armonizate, care încă nu sunt publicate.

Cea mai importantă concluzie: dacă livrezi on-prem sau un agent instalat la clienți din UE, ești deja producător în sensul CRA. Întrebarea nu este dacă te privește, ci dacă dosarul tău tehnic ar trece azi o cerere a autorității. Dacă răspunsul este „nu sunt sigur", acesta este momentul potrivit să afli.

Cum te ajută AISafe Labs cu conformitatea CRA

AISafe Labs rulează audituri de cod sursă și pentesturi, black-box și white-box, cu agenți AI care lucrează în paralel pe produsul tău. Este exact genul de testare care intră în documentația tehnică cerută de CRA: fiecare posibilă vulnerabilitate trece printr-o etapă de exploatare reală într-un mediu izolat, iar ceea ce nu se reproduce nu ajunge în raport. Primești pași de reproducere, severitate justificată și remedieri gata pentru echipa de dezvoltare, nu o listă de suspiciuni.

Rapoartele noastre pot contribui la dosarul tehnic de conformitate în două feluri. Pe de o parte, dovedesc cerința de testare efectivă și regulată din Anexa I, Partea a II-a. Pe de altă parte, repetând testarea după fiecare remediere și păstrând istoricul rezultatelor între versiuni, construiești deja evidența pe care autoritatea o poate cere. Aceste rezultate nu reprezintă singure o certificare CRA, dar acoperă componenta tehnică a evaluării, inclusiv pentru produsele importante și critice.

Ceea ce nu facem este evaluarea de conformitate în sine. Autoevaluarea și traseul prin organism notificat rămân responsabilitatea producătorului și a organismului desemnat. Rolul nostru se oprește la testarea tehnică și la dovezile care intră în planul de remediere și în dosarul de conformitate.

Îți poți face gratuit cont în aplicația AISafe↗, cu audituri de cod pe un singur proiect. Restul capabilităților intră în planurile plătite.

Întrebări frecvente

CRA cere obligatoriu un pentest anual? Nu nominal, dar cere teste eficiente și regulate și un proces de tratare a vulnerabilităților pe toată durata de viață. Pentestul și auditul de cod sunt metoda standard prin care se dovedește cerința, mai ales pentru produsele importante și critice.

Produsul meu e doar SaaS, fără instalare, intră sub CRA? De regulă nu. SaaS pur este serviciu, nu produs, și intră sub NIS2 sau DORA. Dacă SaaS-ul este indispensabil funcționării unui produs instalat (prelucrare la distanță necesară), partea relevantă intră ca soluție de prelucrare la distanță.

Trebuie să merg la un auditor extern? Depinde de categorie. Default nu. Important Clasa I fără standarde armonizate, da. Important Clasa II și Critice, întotdeauna organism notificat sau certificare EU.

Când trebuie să raportez? Din 11 septembrie 2026, orice vulnerabilitate exploatată activ sau incident sever la un produs deja pe piață: avertizare 24h, notificare 72h, final 14 zile sau o lună, prin SRP către CSIRT.

Unde găsesc lista exactă a produselor importante și critice? În Anexa III (importante, Clasele I și II) și Anexa IV (critice) la Regulamentul (UE) 2024/2847↗, detaliate ulterior prin acte de punere în aplicare ale Comisiei.