Raportarea CRA se aplică din 11 septembrie 2026: ce face un producător

Raportarea CRA se aplică din 11 septembrie 2026 pentru producătorii de produse cu elemente digitale care intră în sfera Actului privind Reziliența Cibernetică (Cyber Resilience Act sau CRA). Temeiul este art. 71 alin. (2) din Regulamentul (UE) 2024/2847: regulamentul se aplică integral de la 11 decembrie 2027, dar art. 14, cel care impune notificarea vulnerabilităților exploatate activ și a incidentelor grave, a intrat în aplicare cu 15 luni mai devreme. Un producător vizat trebuie să poată identifica evenimentul, să îl încadreze și să îl transmită prin platforma unică de raportare administrată de ENISA, în termenele din regulament.

Documentare: 7 septembrie 2026. Actualizat: 23 octombrie 2026.

Calendarul este prevăzut de Regulamentul (UE) 2024/2847, în special art. 14 și 71. Diferența dintre cele două date nu este un detaliu de calendar: obligațiile din art. 14 sunt în vigoare acum, în timp ce cerințele esențiale de securitate, evaluarea conformității și marcajul CE urmează abia la finalul lui 2027. O firmă care își planifica pregătirea „pentru 2027” a pierdut deja prima etapă.

Ce s-a schimbat de la 11 septembrie 2026 față de prima versiune a acestei analize?

Platforma unică de raportare există și funcționează. ENISA a lansat pe 11 septembrie 2026 capacitatea operațională inițială a Single Reporting Platform (SRP), cu portalul la adresa portal.cra-srp.enisa.europa.eu. La 7 septembrie, când am scris prima versiune a acestui text, adresa publică nu fusese comunicată; la 23 octombrie 2026 raportarea CRA are un punct de intrare concret.

Accesul nu este liber. Producătorul își înregistrează „Assigned Representatives”, persoanele desemnate să transmită notificările în numele firmei, potrivit ghidurilor ENISA pentru utilizatorii principali și secundari; pagina de înregistrare a reprezentanților și condițiile de utilizare sunt datate 10 septembrie 2026. În comunicatul din 11 septembrie 2026, ENISA vorbește explicit de „initial operating capability” și anunță că funcționalitățile vor fi extinse în lunile următoare. Nu există o dată anunțată pentru capacitatea operațională completă.

Restul cadrului a rămas cel descris în septembrie: termenele din art. 14, definițiile din art. 3, obligația care revine producătorului și nu utilizatorului. Ce adaug în această versiune este un exemplu de flux intern de raportare, pentru că întrebarea pe care o primesc cel mai des nu mai este „de când”, ci „cine și cum”.

Cine este obligat la raportarea CRA și cine nu?

Obligația din art. 14 revine producătorului, definit la art. 3 pct. 13: persoana fizică sau juridică ce dezvoltă sau fabrică produse cu elemente digitale, ori le comandă altcuiva, și le comercializează sub numele sau marca proprie, contra cost sau gratuit. Prezentarea Comisiei Europene privește securitatea produselor cu elemente digitale și obligațiile operatorilor implicați. Faptul că o companie utilizează laptopuri sau aplicații nu o transformă automat în producătorul vizat de articolul 14. Încadrarea cere analiza produsului, a modului în care este pus pe piață și a rolului economic exercitat.

Firmele care doar folosesc software, de la contabilitate în cloud la sisteme ERP, nu intră sub art. 14. Art. 14 alin. (8) le tratează ca destinatari ai informării pe care producătorul este obligat să o facă, nu ca raportori. Dacă aceste firme au obligații de notificare a incidentelor, ele vin din NIS2 și din actul de transpunere, un regim cu alte roluri, alte termene și altă autoritate.

Aș cere ca această concluzie să fie explicată și păstrată în documentația de conformare. Formula „suntem o firmă IT” este prea largă pentru o asemenea decizie. Producerea unui produs, distribuirea lui și utilizarea sa internă sunt situații care trebuie analizate distinct, inclusiv prin raportare la excluderile și regulile speciale ale regulamentului. Un integrator care pune marca proprie pe un produs asamblat din componente terțe este producător; un distribuitor care îl revinde neschimbat nu este.

Care sunt termenele raportării CRA și ce anume se raportează?

Raportarea CRA are termene de 24 de ore, 72 de ore, 14 zile și o lună, iar obiectul ei este fie o vulnerabilitate exploatată activ, fie un incident grav. Cele două categorii au definiții proprii și repere diferite pentru raportul final, deci încadrarea corectă este prima decizie din orice flux.

Ce se raportează: vulnerabilitate exploatată activ sau incident grav

Raportarea CRA are două obiecte distincte: vulnerabilitatea exploatată activ și incidentul grav. Vulnerabilitatea exploatată activ este definită la art. 3 pct. 42 ca o vulnerabilitate pentru care există dovezi credibile că un actor rău intenționat a exploatat-o într-un sistem fără permisiunea proprietarului. Incidentul cu impact asupra securității produsului este definit la art. 3 pct. 44, iar art. 14 alin. (5) stabilește când devine grav: afectează sau poate afecta capacitatea produsului de a proteja disponibilitatea, autenticitatea, integritatea sau confidențialitatea unor date sau funcții sensibile ori importante, sau a dus ori poate duce la introducerea sau executarea de cod malițios în produs sau în sistemele unui utilizator.

Termenele din art. 14

Ghidul Comisiei privind raportarea CRA descrie avertizarea timpurie în 24 de ore și notificarea în 72 de ore de la luarea la cunoștință, în condițiile regulamentului. Pentru vulnerabilitățile exploatate activ, raportul final este legat de disponibilitatea măsurii corective. Pentru incidentele grave, reperul raportului final este notificarea incidentului.

Etapa	Reperul prevăzut de CRA
Avertizare timpurie	Fără întârzieri nejustificate și în cel mult 24 de ore de la luarea la cunoștință (art. 14 alin. (2) lit. a) și alin. (4) lit. a)).
Notificare	Fără întârzieri nejustificate și în cel mult 72 de ore de la luarea la cunoștință, în condițiile art. 14 alin. (2) lit. b) și alin. (4) lit. b).
Raport final pentru vulnerabilitate exploatată activ	Cel târziu în 14 zile de la disponibilitatea unei măsuri corective sau de atenuare (art. 14 alin. (2) lit. c)).
Raport final pentru incident grav	Într-o lună de la transmiterea notificării incidentului prevăzute la art. 14 alin. (4) lit. b).

Două precizări contează pentru pregătire. Potrivit art. 69 alin. (3), obligația privește și produsele puse la dispoziție pe piață înainte de 11 septembrie 2026, la fel ca lansările viitoare. Iar avertizarea timpurie pentru un incident grav trebuie să spună cel puțin dacă există suspiciunea unei fapte ilicite sau rău intenționate, ceea ce înseamnă că în primele 24 de ore cineva din firmă trebuie să fie în stare să formuleze o opinie, nu să aștepte concluzia investigației.

Unde se transmite raportarea CRA și cine o primește în România?

Notificarea se transmite prin platforma unică de raportare, simultan către CSIRT-ul desemnat coordonator al statului membru în care producătorul are sediul principal în Uniune și către ENISA, potrivit art. 14 alin. (1), (3) și (7). Sediul principal este statul în care se iau în principal deciziile legate de securitatea cibernetică a produselor, nu neapărat sediul social. Pentru o firmă din România cu echipa de dezvoltare în Cluj și o entitate de facturare în altă țară, răspunsul nu este automat.

Lista ENISA a CSIRT-urilor coordonatoare, actualizată la 10 septembrie 2026, indică pentru România contactul publicat pe dnsc.ro, fără să scrie numele structurii. La data documentării acestei versiuni, 22 octombrie 2026, nu am găsit o publicație a Directoratului Național de Securitate Cibernetică despre CRA, despre platforma unică sau despre rolul de CSIRT coordonator; asta nu înseamnă că nu există, ci că un producător trebuie să verifice direct la autoritate înainte de prima notificare. Am descris într-o analiză separată ce este un CSIRT și cum funcționează în România, în UE și în SUA.

Un producător vizat ar trebui să își înregistreze reprezentanții desemnați pentru raportarea CRA în platformă acum, nu în ziua incidentului. Crearea conturilor, validarea identității și testarea accesului durează; termenul de 24 de ore curge indiferent de starea conturilor dumneavoastră.

Cum poate arăta fluxul intern al raportării CRA într-o firmă?

Un flux intern de raportare CRA are șase pași: identificare, încadrare, responsabil de raportare, aprobare, transmitere în platformă, dovezi păstrate. Ce urmează este un model de organizare pe care îl propun pentru pregătire, nu o obligație prevăzută textual de regulament; art. 14 spune ce și când se raportează, nu cum să vă organizați intern.

Identificare. Cine primește semnalul: echipa de suport, un cercetător extern, un client, monitorizarea proprie. Momentul „luării la cunoștință” se înregistrează cu dată și oră, pentru că de la el curg cele 24 și 72 de ore.
Încadrare. O persoană cu competență tehnică decide dacă este vorba despre o vulnerabilitate exploatată activ (art. 3 pct. 42) sau despre un incident grav (art. 14 alin. (5)), ori despre niciuna dintre ele. Decizia și motivele se consemnează, inclusiv când concluzia este „nu se raportează”.
Responsabil de raportare. Reprezentantul desemnat în platformă, cu un înlocuitor pentru concedii și nopți. Dacă persoana are acces doar de pe un laptop lăsat la birou, fluxul este decorativ.
Aprobare. Cine semnează transmiterea și în cât timp; aprobarea nu poate depinde de o ședință de luni dimineața când evenimentul a apărut vineri seara.
Transmitere în platformă. Avertizarea timpurie în 24 de ore, cu ce se știe atunci; notificarea în 72 de ore; raportul final la termenul aplicabil. Informarea utilizatorilor afectați, potrivit art. 14 alin. (8), este o etapă separată.
Dovezi păstrate. Jurnalul evenimentului, deciziile de încadrare, confirmările din platformă, comunicările către utilizatori. Acestea sunt materialul pe care îl poate examina un auditor sau o autoritate.

Ce poate examina auditorul înainte de un incident?

Un audit poate urmări dacă procedura de raportare CRA descrisă de firmă este susținută de dovezi. Propun ca verificarea să pornească de la un scenariu: o echipă află despre exploatarea unei vulnerabilități într-o versiune de produs. Cum identifică versiunile afectate? Cine stabilește încadrarea? Unde sunt înregistrate momentele relevante? Cine are, în acest moment, cont activ în platforma ENISA?

Apoi pot fi examinate accesul la canalele de raportare, responsabilitățile, evidența produselor și modul de informare a utilizatorilor. Lista este un exemplu de pregătire a unei misiuni, nu un inventar legal exhaustiv și nici dovada că un audit comercial produce automat conformitatea CRA.

„Într-o firmă pe care aș verifica-o, nu aș cere mai întâi procedura, ci jurnalul ultimei vulnerabilități tratate: ora la care a aflat echipa, ora deciziei de încadrare și numele persoanei care a aprobat. Dacă aceste trei lucruri nu există pentru un eveniment din trecut, nu vor exista nici pentru primul incident raportabil.”

Bogdan-Costin FÂRȘIROTU, Președinte, Centrul de Formare APSAP

Consider că proba cea mai utilă este parcurgerea efectivă a unui scenariu, cu oamenii care vor avea roluri în situația reală. Dacă aprobarea notificării depinde de o singură persoană greu de contactat, documentul poate fi corect, iar procesul poate rămâne lent. Această diferență trebuie descoperită cât timp există timp pentru corectare, iar de la 11 septembrie 2026 timpul acela se măsoară altfel.

Un test tehnic și un audit răspund la întrebări diferite?

Da. Un test de penetrare poate furniza informații despre vulnerabilități tehnice în limitele mandatului său. O misiune de audit poate examina și organizarea, controalele, responsabilitățile și dovezile funcționării proceselor. Într-o pregătire serioasă, rezultatele tehnice trebuie să poată fi legate de deciziile și măsurile organizației.

Nici obligațiile CRA nu trebuie amestecate automat cu cele NIS2. Pot exista legături și situații de suprapunere, dar rolurile, obiectul și temeiurile se verifică separat. Un termen memorat dintr-un regim nu este suficient pentru clasificarea unei obligații din celălalt. Raportarea CRA privește produsul și producătorul lui; NIS2 privește entitatea și serviciile ei.

Cum pregătește Centrul de Formare APSAP auditorii pentru astfel de verificări?

Pentru profesioniștii care vor să verifice pregătirea unei firme pentru raportarea CRA și, mai larg, să își dezvolte competențele de audit, cursul Auditor Securitate Cibernetică al Centrului de Formare APSAP, program autorizat DNSC, oferă un traseu de pregătire în domeniu. Asumarea unei misiuni se face în limitele competențelor și condițiilor de autorizare aplicabile. Primul rezultat urmărit ar trebui să fie capacitatea de a explica ce ați verificat și pe ce dovezi se bazează concluzia.

Centrul de Formare APSAP lucrează în proporție de aproximativ 85% cu companii, organizații și persoane fizice, iar restul cu sectorul public. Fundația a fost înființată în 2014, pe experiența unei echipe active din 2006, deci peste 20 de ani de experiență în formare profesională, cu peste 250.000 de participanți și 27 de autorizări și recunoașteri. Cei care vor să vadă cum arată evaluările pot citi cele peste 15.500 de recenzii Google, cu media 5 stele. Am explicat argumentele pentru care profesioniștii aleg Centrul de Formare APSAP și ce înseamnă un curs autorizat față de unul care se declară acreditat. Informații despre organizație găsiți pe pagina despre Centrul de Formare APSAP, iar pentru întrebări concrete despre program folosiți formularul de contact.

Întrebări frecvente despre raportarea CRA

Orice firmă care folosește software trebuie să raporteze potrivit CRA?

Nu automat. Obligația din art. 14 privește producătorii definiți la art. 3 pct. 13 și produsele cu elemente digitale care intră în sfera regulamentului. O firmă care folosește aplicații, servere sau echipamente cumpărate de la alții este utilizator, iar producătorul este cel care trebuie să o informeze dacă un incident o afectează. Rolul firmei dumneavoastră trebuie stabilit pentru situația concretă, cu argumentele păstrate în documentația de conformare, pentru că aceeași companie poate fi utilizator pentru majoritatea sistemelor și producător pentru un singur produs vândut sub marcă proprie.

De ce apare 2026 dacă aplicarea generală este în 2027?

Articolul 71 alin. (2) stabilește calendare diferite. Regulamentul se aplică de la 11 decembrie 2027, dar articolul 14 privind raportarea se aplică de la 11 septembrie 2026, iar capitolul IV, despre notificarea organismelor de evaluare a conformității, de la 11 iunie 2026. Legiuitorul european a vrut ca raportarea vulnerabilităților exploatate activ să funcționeze înainte ca restul cerințelor să devină obligatorii. Pentru dumneavoastră înseamnă că raportarea CRA este deja o obligație în vigoare, nu o pregătire pentru 2027, chiar dacă produsul nu poartă încă marcajul CE cerut de regulament.

Un audit înlocuiește raportarea incidentului?

Nu. Auditul poate evalua pregătirea și dovezile funcționării proceselor, înainte sau după un eveniment. Raportarea CRA rămâne obligația producătorului vizat, în termenele și condițiile din art. 14, indiferent de concluziile unei misiuni de audit. Un raport de audit favorabil nu suspendă termenul de 24 de ore și nu înlocuiește notificarea în platforma ENISA. Ce poate face auditul este să descopere, înainte de incident, că persoana desemnată nu are cont în platformă sau că nimeni nu știe cine aprobă transmiterea.

Unde se transmite efectiv o notificare CRA?

Prin Single Reporting Platform, platforma unică administrată de ENISA, disponibilă din 11 septembrie 2026 la adresa portal.cra-srp.enisa.europa.eu, în capacitate operațională inițială. Notificarea ajunge simultan la CSIRT-ul coordonator al statului membru în care producătorul are sediul principal și la ENISA. Accesul se face prin reprezentanții desemnați pe care producătorul îi înregistrează în platformă, conform ghidurilor ENISA din septembrie 2026. Pentru România, lista ENISA a CSIRT-urilor coordonatoare trimite la pagina de contact a Directoratului Național de Securitate Cibernetică.

Care este diferența dintre o vulnerabilitate exploatată activ și un incident grav?

Vulnerabilitatea exploatată activ, definită la art. 3 pct. 42, este o slăbiciune a produsului pentru care există dovezi credibile că cineva a folosit-o fără permisiune într-un sistem. Incidentul grav, potrivit art. 3 pct. 44 și art. 14 alin. (5), este un eveniment care afectează sau poate afecta capacitatea produsului de a proteja date sau funcții sensibile, ori care a dus sau poate duce la cod malițios în produs sau la utilizatori. Ambele se raportează în 24 și 72 de ore, dar raportul final are reper diferit: măsura corectivă pentru vulnerabilitate, notificarea incidentului pentru incident.