Cyber Resilience Act: raportarea vulnerabilităților (sept. 2026)

De la 11 septembrie 2026, orice firmă care pune pe piața Uniunii Europene un produs software sau hardware trebuie să raporteze vulnerabilitățile exploatate activ și incidentele grave de securitate în cel mult 24 de ore de la momentul în care află de ele. Este prima obligație din Cyber Resilience Act (Regulamentul (UE) 2024/2847) care devine aplicabilă, cu mai bine de un an înaintea restului regulamentului, și prinde nepregătite exact firmele mici de software din România care nu se consideră „producători". Articolul de față explică cine intră sub incidența obligației, ce se raportează, cui, în ce termene, ce amenzi sunt prevăzute și cum arată un proces de raportare care ține la 3 dimineața, inclusiv unde ajută și unde încurcă uneltele AI.

Ce se schimbă pe 11 septembrie 2026 și ce rămâne pentru 2027

Cyber Resilience Act a fost publicat în Jurnalul Oficial al UE în noiembrie 2024 și a intrat în vigoare pe 10 decembrie 2024, dar articolul 71 eșalonează aplicarea în trei trepte:

Diferența practică e uriașă. Cerințele de proiectare sigură, documentația tehnică sau lista de componente software (SBOM) sunt obligații pe care le poți planifica până la finalul lui 2027. Raportarea, în schimb, nu se planifică: ori ai un proces care funcționează în ziua în care afli de o exploatare, ori ratezi termenul de 24 de ore. Un detaliu pe care multe firme îl trec cu vederea: conform articolului 69, obligațiile de raportare din articolul 14 se aplică și produselor introduse pe piață înainte de 11 decembrie 2027, așa cum subliniază și analiza Freshfields din 31 august 2026. Software-ul pe care îl vinzi deja de trei ani intră sub obligație din prima zi.

Cine este „producător": mai multe firme decât crezi

Regulamentul folosește vocabularul legislației de produs, nu pe cel al industriei software, și de aici vine prima confuzie. Articolul 3 definește la punctul (1) produsul cu elemente digitale ca „un produs software sau hardware și soluțiile sale de prelucrare la distanță a datelor, inclusiv componentele software sau hardware introduse pe piață separat". O aplicație desktop, o aplicație mobilă, un plugin, o bibliotecă vândută sub licență comercială, un dispozitiv IoT cu firmware, un SaaS în măsura în care are o componentă locală sau o prelucrare la distanță necesară funcționării produsului: toate sunt produse cu elemente digitale.

Producătorul, la punctul (13), este persoana fizică sau juridică ce dezvoltă sau fabrică un astfel de produs, ori îl comandă spre dezvoltare, și îl comercializează sub numele sau marca proprie. Nu contează dacă produsul este vândut contra cost sau oferit gratuit: „punerea la dispoziție pe piață", la punctul (22), acoperă furnizarea în cadrul unei activități comerciale, cu sau fără plată. Testul relevant este activitatea comercială, nu prețul. O firmă de outsourcing care livrează cod clientului nu este producător pentru acel cod; devine producător în momentul în care publică un produs sub propriul brand.

Există și o categorie nouă, administratorul de software open-source (punctul (14)): entitatea juridică ce susține în mod sistematic dezvoltarea unui produs open-source destinat activităților comerciale. Pentru administratorii de open-source, regimul este mult mai blând: obligațiile lor de raportare, prevăzute la articolul 24 alineatul (3), se aplică abia de la 11 decembrie 2027, iar articolul 64 îi exceptează de la amenzi.

Ce nu intră sub CRA: serviciile pure de tip SaaS fără produs (acestea sunt acoperite de NIS2, nu de CRA), software-ul dezvoltat exclusiv pentru uz intern și software-ul open-source necomercial. Delimitarea este uneori subtilă și merită validată cu un consilier juridic, mai ales pentru produsele hibride.

Ce se raportează: două categorii, definite strict

Articolul 14 nu cere raportarea oricărei vulnerabilități. Obligația se declanșează în două situații precise.

Vulnerabilitatea exploatată activ este definită la articolul 3 punctul (42) drept „o vulnerabilitate pentru care există dovezi fiabile că un actor rău-intenționat a exploatat-o într-un sistem fără permisiunea proprietarului sistemului". Cuvântul-cheie este „dovezi fiabile": un raport de la un cercetător care demonstrează exploatabilitatea teoretică nu declanșează obligația; un log care arată exploatarea reală, un raport de la un client compromis sau includerea vulnerabilității într-un catalog de exploatări active, da.

Incidentul grav cu impact asupra securității produsului este definit la articolul 14 alineatul (5) prin două criterii alternative: incidentul afectează sau poate afecta capacitatea produsului de a proteja disponibilitatea, autenticitatea, integritatea sau confidențialitatea datelor ori funcțiilor sensibile sau importante; sau a dus ori poate duce la introducerea sau executarea de cod rău-intenționat. Un exemplu tipic este compromiterea infrastructurii de build sau de distribuție a actualizărilor, prin care un atacator ar putea livra cod modificat utilizatorilor tăi.

Vulnerabilitățile descoperite intern și remediate înainte de orice exploatare nu se raportează obligatoriu. Platforma de raportare va accepta în viitor și notificări voluntare pentru vulnerabilități neexploatate, amenințări sau incidente evitate la limită, dar, potrivit întrebărilor frecvente publicate de ENISA, la lansare platforma acceptă doar raportările obligatorii de la articolul 14.

Aici merită făcută o observație despre pregătire. Diferența dintre o firmă care poate spune în 24 de ore „avem dovezi de exploatare, iată componenta afectată" și una care abia începe să caute prin loguri stă în modelarea amenințărilor făcută dinainte: ce componente expun ce suprafață de atac, ce se loghează, cine primește alerta. Este exact metodologia de threat modeling, de analiză a lanțului de aprovizionare și de apărare în adâncime pe care o parcurge, cu MITRE ATLAS și OWASP LLM Top 10 pentru componentele AI, cursul AI Security și Ethical Engineering. Fără această hartă, termenul de 24 de ore este pur și simplu imposibil de respectat.

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

Raportarea se face în trei etape, cu conținut progresiv. Etapele sunt aceleași pentru ambele categorii, dar termenul raportului final diferă.

Pentru o vulnerabilitate exploatată activ (articolul 14 alineatul (2))

1. Avertizare timpurie, în cel mult 24 de ore de la momentul în care producătorul află de exploatare. Conținutul minim: faptul că există o vulnerabilitate exploatată activ și, dacă se cunosc, statele membre în care produsul este pus la dispoziție.
2. Notificare, în cel mult 72 de ore, cu informații generale despre produs, natura vulnerabilității și a exploatării, măsurile corective sau de atenuare luate ori pe care utilizatorii le pot lua, precum și cât de sensibile sunt informațiile raportate.
3. Raport final, în cel mult 14 zile de la momentul în care o măsură corectivă este disponibilă, cu descrierea vulnerabilității, a severității și impactului, informații despre actorul rău-intenționat dacă sunt disponibile și detalii despre actualizarea de securitate pusă la dispoziție.

Pentru un incident grav (articolul 14 alineatul (4))

1. Avertizare timpurie, în 24 de ore, indicând cel puțin dacă se suspectează o cauză ilegală sau rău-intenționată.
2. Notificare, în 72 de ore, cu informații generale despre natura incidentului, o evaluare inițială și măsurile luate sau recomandate.
3. Raport final, în cel mult o lună de la notificare, cu descrierea detaliată a incidentului, severitatea, impactul, tipul amenințării sau cauza-rădăcină și măsurile de atenuare aplicate.

Două nuanțe practice. Prima: termenul curge de la „a lua cunoștință", adică de la momentul în care firma are informația, nu de la momentul în care cineva din conducere o citește. Un e-mail de la un cercetător de securitate care zace două zile într-o căsuță generică de contact nu suspendă termenul. A doua: articolul 14 alineatul (8) cere ca producătorul să informeze și utilizatorii afectați, fără întârzieri nejustificate, despre vulnerabilitate sau incident și, unde este cazul, despre măsurile de atenuare, de preferat într-un format prelucrabil automat.

Cui raportezi: platforma unică ENISA și rolul DNSC

Raportările nu se trimit prin e-mail și nici pe portalurile naționale existente. Articolul 16 obligă ENISA să pună la dispoziție o platformă unică de raportare (Single Reporting Platform, SRP), prin care notificarea ajunge la CSIRT-ul desemnat drept coordonator în statul membru unde producătorul își are sediul principal, iar ENISA primește simultan informația. Potrivit paginii oficiale a platformei și întrebărilor frecvente, câteva reguli de funcționare contează pentru pregătire:

• Platforma devine operațională pe 11 septembrie 2026, în aceeași zi cu obligația. Nu există perioadă de grație.
• Accesul se face pe bază de cont EU Login cu autentificare multi-factor, de către „reprezentanți desemnați" ai producătorului. Un reprezentant principal se înregistrează direct, apoi poate invita până la 20 de reprezentanți secundari.
• Validarea reprezentanților se face în paralel cu raportarea: până la validare, un reprezentant poate transmite un număr limitat de notificări, deci lipsa validării nu este o scuză pentru întârziere.
• La lansare nu există API; notificările se completează manual, în interfața web. Câmpurile includ identificarea produsului, identificatori CVE sau EUVD, descrierea severității, evaluarea impactului, măsurile de atenuare și analiza amenințării.
• „Sediul principal" este locul unde se iau predominant deciziile de securitate cibernetică; dacă nu poate fi stabilit, se folosește locul cu cei mai mulți angajați, apoi, în ordine, reprezentantul autorizat, importatorul, distribuitorul.

Pentru firmele din România, CSIRT-ul coordonator este Directoratul Național de Securitate Cibernetică (DNSC), care exercită funcția de CSIRT național în temeiul OUG 104/2021 și figurează în lista CSIRT-urilor coordonatoare publicată de ENISA la începutul lui septembrie 2026. Coordonatorul poate partaja informații cu autoritatea de supraveghere a pieței, astfel încât raportarea și eventuala anchetă de conformitate să nu fie procese separate.

Amenzile și excepția pentru firmele mici

Articolul 64 stabilește trei praguri de amenzi administrative, aplicate de autoritățile naționale:

Raportarea se află în pragul cel mai sever. Există însă o excepție importantă: microîntreprinderile și întreprinderile mici nu pot fi amendate pentru nerespectarea termenului de 24 de ore pentru avertizarea timpurie (articolul 14 alineatul (2) litera (a) și alineatul (4) litera (a)). Celelalte termene, de 72 de ore și cele ale raportului final, rămân sancționabile și pentru ele, iar autoritățile trebuie să țină cont de dimensiunea firmei la stabilirea cuantumului. Amenzile concrete și procedura se stabilesc prin legislația națională, pe care România o va adopta până la aplicarea integrală din decembrie 2027.

Cum se leagă CRA de NIS2, GDPR și AI Act

O firmă de software poate avea, pentru același eveniment, trei sau patru obligații de notificare, cu destinatari și termene diferite. Merită să le vezi una lângă alta înainte să scrii procedura internă:

• CRA (articolul 14): vulnerabilitate exploatată sau incident grav al produsului tău, către CSIRT prin platforma ENISA, 24 h / 72 h / 14 zile sau o lună.
• NIS2, transpusă în România prin OUG 155/2024 și Legea 124/2025: incident semnificativ al serviciului tău, dacă ești entitate esențială sau importantă, către DNSC, tot în 24 h / 72 h / o lună. Răspunsul operațional la incidente, cu triaj și investigație asistate de AI, este parcursul cursului AI pentru securitate cibernetică: SOC și apărare asistată de AI; contextul NIS2 pentru echipele de securitate este în ghidul despre AI în securitatea cibernetică și SOC.
• GDPR (articolul 33): încălcare a securității datelor cu caracter personal, către ANSPDCP, în 72 de ore, plus informarea persoanelor vizate când riscul este ridicat (articolul 34).
• AI Act: dacă produsul tău este un sistem AI cu grad ridicat de risc, articolul 12 din CRA prevede că respectarea cerințelor esențiale din Anexa I a CRA este considerată conformă cu cerința de securitate cibernetică din AI Act, iar organismele notificate pentru AI Act pot evalua și conformitatea cu CRA. Contextul complet al obligațiilor din AI Act este în ghidul EU AI Act pentru companiile românești.

Procesul intern cel mai robust este unul singur, cu un punct unic de intrare pentru orice semnal de securitate și cu o matrice care spune, pentru fiecare tip de eveniment, ce notificări se declanșează, cine le semnează și în ce termen. Cele patru cadre nu se exclud; se cumulează.

Unde intră AI-ul: produsele tale, procesul tău și capcanele

Cyber Resilience Act nu menționează modelele lingvistice, dar le atinge din trei direcții.

Produsele construite cu AI sunt produse cu elemente digitale. Un asistent conversațional livrat clienților, un agent care execută acțiuni în sistemul clientului sau o aplicație generată în mare parte cu unelte de vibe coding sunt produse în sensul regulamentului. Vulnerabilitățile specifice acestor produse, cum sunt injecțiile de prompt indirecte, exfiltrarea de date prin unelte sau escaladarea de privilegii a unui agent, sunt vulnerabilități în sensul articolului 3 punctul (40): o slăbiciune care poate fi exploatată de o amenințare cibernetică. Dacă cineva le exploatează în producție și ai dovezi, raportezi. Cine deține codul generat cu AI și ce riscuri de licențiere apar în lanțul de aprovizionare am analizat în articolul despre proprietatea codului scris cu AI.

Lanțul de aprovizionare AI intră sub cerințele din 2027. Din decembrie 2027, Anexa I partea II cere identificarea și documentarea componentelor produsului, inclusiv printr-o listă de componente software în format prelucrabil automat, și o politică de divulgare coordonată a vulnerabilităților. Modelele descărcate, bibliotecile de inferență și serverele MCP pe care le împachetezi în produs sunt componente. A începe inventarul acum, în paralel cu procesul de raportare, este mai ieftin decât a-l reconstrui în 2027; un punct de plecare util este registrul de sisteme AI al companiei, care poate fi extins cu componentele fiecărui produs.

AI-ul ajută în procesul de raportare, cu două condiții. Un model poate reconstrui cronologia unui incident din loguri, poate redacta schița avertizării timpurii în formatul cerut de platformă, poate traduce raportul final și poate verifica dacă un CVE este listat ca exploatat activ. Condițiile sunt confidențialitatea și verificarea. Detaliile unei vulnerabilități neremediate sunt printre cele mai sensibile informații pe care le deține o firmă de software; nu au ce căuta într-un chatbot de consum, cu istoricul folosit la antrenare. Se folosesc fie planuri de echipă sau enterprise cu clauze contractuale de neantrenare, fie modele rulate local, așa cum descriem în ghidul despre LLM-uri locale și GDPR, iar regula se scrie explicit în politica internă de utilizare AI. Iar orice text generat se verifică înainte de trimitere: articolul 64 sancționează separat, cu până la 5 milioane EUR, informațiile incorecte sau înșelătoare transmise autorităților. O halucinație într-un raport oficial nu este o eroare de redactare, ci o încălcare distinctă.

Automatizarea detectării, de la scanarea dependențelor la agenții de code review din CI, reduce timpul dintre exploatare și „a lua cunoștință". Ce merită automatizat și ce nu, în pipeline-ul de livrare, este subiectul ghidului despre code review și CI cu agenți AI.

Planul de conformare pentru o firmă mică de software: ce faci săptămâna aceasta

Termenul este aproape, dar procesul minim viabil se poate pune în picioare în câteva zile. Ordinea de mai jos pornește de la ce este obligatoriu și continuă cu ce este util.

1. Stabilește dacă ești producător pentru fiecare produs din portofoliu, cu criteriile de mai sus, și notează pentru fiecare statele membre în care este pus la dispoziție. Acest inventar intră direct în avertizarea timpurie.
2. Desemnează reprezentanții pentru platforma ENISA: cel puțin doi, cu cont EU Login și autentificare multi-factor activată, pentru ca absența unuia să nu blocheze raportarea. Înregistrarea se face din prima zi de funcționare a platformei.
3. Creează un punct unic de intrare pentru semnalele de securitate: o adresă dedicată, monitorizată permanent, publicată pe site, plus un canal intern de escaladare cu responsabil de gardă. Termenul de 24 de ore curge de la primirea informației, nu de la citirea ei.
4. Scrie procedura pe o pagină: criteriile de calificare (exploatare activă, incident grav), cine decide, cine completează cele trei etape, cine informează utilizatorii, cine verifică textul înainte de trimitere. Include matricea CRA / NIS2 / GDPR de mai sus.
5. Pregătește șabloanele pentru cele trei etape, cu câmpurile cerute de platformă, astfel încât în ziua incidentului să completezi, nu să compui. Un model AI poate genera prima versiune a șabloanelor; verificarea finală rămâne a omului.
6. Rulează o simulare: alege o vulnerabilitate ipotetică, pornește cronometrul și verifică dacă poți produce avertizarea timpurie în 24 de ore și notificarea în 72 de ore, cu informațiile pe care le ai efectiv la dispoziție. De obicei, simularea arată că logurile lipsesc, nu că oamenii sunt lenți.
7. Începe inventarul componentelor (biblioteci, modele, servicii terțe) pentru cerințele din 2027, măcar pentru produsul principal.

Firmele care au deja un proces NIS2 sau un program de răspuns la incidente pot adăuga CRA ca o ramură nouă în același flux. Cele care nu au nimic pornesc de la pasul 3.

Întrebări frecvente

Vindem un SaaS găzduit de noi; intrăm sub Cyber Resilience Act?

Depinde de arhitectură. Serviciile pure de tip SaaS, fără produs livrat utilizatorului, sunt în afara CRA și intră sub NIS2, dacă îndepliniți criteriile de entitate esențială sau importantă. Dacă însă livrați o aplicație instalabilă, un agent local, un SDK sau un dispozitiv care depinde de o prelucrare la distanță, acea componentă este produs cu elemente digitale, iar prelucrarea la distanță necesară funcționării lui intră în definiția de la articolul 3 punctul (1). Cazurile hibride merită o opinie juridică.

Trebuie să raportăm orice vulnerabilitate găsită în produsul nostru?

Nu. Obligația de la articolul 14 se declanșează doar pentru vulnerabilitățile pentru care există dovezi fiabile de exploatare activă și pentru incidentele grave cu impact asupra securității produsului. Vulnerabilitățile găsite intern sau raportate de cercetători și remediate înainte de exploatare nu intră în raportarea obligatorie, deși ele trebuie tratate și, din 2027, gestionate printr-o politică de divulgare coordonată.

Suntem o firmă cu opt angajați; ne pot amenda dacă ratăm termenul de 24 de ore?

Articolul 64 prevede că microîntreprinderile și întreprinderile mici nu sunt supuse amenzilor pentru nerespectarea termenului de 24 de ore al avertizării timpurii. Rămân sancționabile termenul de 72 de ore pentru notificare, termenele raportului final și obligația de a informa utilizatorii. Excepția nu înseamnă că avertizarea timpurie este opțională, ci că întârzierea ei nu este amendată.

Putem trimite raportarea prin e-mail către DNSC?

Nu. Potrivit ENISA, singurul canal acceptat pentru notificările de la articolul 14 este platforma unică de raportare, prin care informația ajunge la CSIRT-ul coordonator, pentru România DNSC, și simultan la ENISA. La lansare nu există nici API, deci notificările se completează manual în interfața web.

Putem folosi ChatGPT sau Claude ca să redactăm raportul?

Puteți folosi un model pentru schițe, cronologii și traduceri, cu două condiții. Prima: nu introduceți detalii despre o vulnerabilitate neremediată într-un serviciu de consum ale cărui condiții permit folosirea conversațiilor la antrenare; folosiți planuri cu clauze contractuale de confidențialitate sau un model rulat local. A doua: verificați fiecare afirmație înainte de trimitere, pentru că informațiile incorecte transmise autorităților sunt sancționate distinct, cu până la 5 milioane EUR sau 1% din cifra de afaceri.

Ce se întâmplă cu produsele noastre lansate înainte de 2027?

Obligațiile de raportare se aplică și produselor introduse pe piață înainte de 11 decembrie 2027. Cerințele esențiale de proiectare și documentare din Anexa I se aplică produselor vechi doar dacă suferă modificări substanțiale după acea dată, dar raportarea vulnerabilităților exploatate activ nu are această excepție.

Concluzie

Cyber Resilience Act începe pe 11 septembrie 2026 cu partea cea mai greu de improvizat: raportarea în 24 de ore. Definițiile sunt stricte, ceea ce e o veste bună, pentru că obligația se declanșează doar la exploatare dovedită sau la incident grav. Procesul, în schimb, trebuie să existe dinainte: un punct unic de intrare, reprezentanți înregistrați pe platforma ENISA, o procedură de o pagină, șabloane și o simulare făcută cel puțin o dată. Uneltele AI scurtează redactarea și analiza, dar nu preiau răspunderea pentru confidențialitatea detaliilor și pentru corectitudinea textului trimis autorităților. Firmele care tratează raportarea ca o ramură a unui program de securitate a produsului, cu modelarea amenințărilor și inventarul componentelor începute acum, vor ajunge în decembrie 2027 cu cea mai mare parte a temei făcute.

Surse și resurse oficiale

• Regulamentul (UE) 2024/2847 (Cyber Resilience Act), textul integral pe EUR-Lex
• Comisia Europeană: obligațiile de raportare din CRA
• ENISA: platforma unică de raportare (SRP)
• ENISA: întrebări frecvente despre SRP
• ENISA: lista CSIRT-urilor desemnate drept coordonatori
• Directoratul Național de Securitate Cibernetică (DNSC)

Articol informativ, redactat la 8 septembrie 2026 pe baza surselor citate, consultate la această dată. Nu constituie consultanță juridică sau de conformitate. Încadrarea unui produs și a unei firme sub Cyber Resilience Act depinde de situația concretă; consultă textul oficial al regulamentului și un consilier juridic specializat înainte de a lua decizii.