CRA din 11 septembrie 2026: raportare în 24/72 de ore

Articolul 14 din Cyber Resilience Act, Regulamentul (UE) 2024/2847, se aplică din 11 septembrie 2026. Producătorii produselor cu elemente digitale din sfera CRA trebuie să raporteze vulnerabilitățile exploatate activ și incidentele grave care afectează securitatea produselor lor. ENISA a lansat în aceeași zi prima versiune operațională a Single Reporting Platform (SRP).

Cerințele principale privind securitatea produselor și evaluarea conformității se aplică din 11 decembrie 2027. Pentru conducerea unei firme de software, decizia imediată este cine evaluează evenimentul, cine pregătește informațiile și cine poate transmite notificarea în timp util. Verificarea acestui articol a fost încheiată la 13 septembrie 2026.

CRA privește produsele hardware și software cu elemente digitale puse la dispoziție pe piața UE, în condițiile și cu excluderile regulamentului. Publicul relevant include producători de aplicații distribuite, echipamente conectate și componente comercializate separat. Raportarea din articolul 14 acoperă și produse din sferă introduse pe piață înainte de 11 decembrie 2027.

Un serviciu SaaS nu intră automat în sferă: trebuie analizat dacă reprezintă o soluție de procesare la distanță necesară funcționării unui produs și dacă îndeplinește definiția legală. Nici folosirea unei biblioteci open-source nu face din companie un «open-source software steward». Obligațiile specifice acestei categorii din articolul 24(3) încep la 11 decembrie 2027.

Stabilește încadrarea pe produs și pe entitatea producătoare. Apartenența la un sector NIS2 nu este un test de încadrare CRA. Pentru o organizație care doar cumpără software, lecția practică este să ceară furnizorului un contact de securitate și un proces clar de comunicare.

Pentru o vulnerabilitate exploatată activ trebuie să existe dovezi credibile de exploatare de către un actor malițios, fără permisiunea proprietarului sistemului. Un CVE, un scor CVSS ridicat sau un test realizat cu bună-credință nu sunt singure suficiente. EPSS estimează probabilitatea exploatării; nu dovedește că un atac a avut loc.

Pentru incidente, articolul 14(5) include afectarea efectivă sau potențială a protecției datelor ori funcțiilor sensibile/importante, precum și introducerea ori executarea de cod malițios în produs sau sistemele utilizatorului. Nu este necesar să existe deja o scurgere de date confirmată pentru a analiza acest prag.

O alertă despre o componentă terță cere verificarea versiunii și a modului în care componenta este folosită în produs. FAQ-ul Comisiei precizează că o vulnerabilitate care nu poate fi exploatată în produsul respectiv nu este supusă acestei raportări obligatorii. Documentează raționamentul și reanalizează-l dacă apar dovezi noi.

Cele 72 de ore nu se adaugă peste cele 24. Termenul de 14 zile nu este o perioadă generală acordată pentru a crea un patch. Păstrează separat cronologia semnalului inițial, a luării la cunoștință, a transmiterilor și a disponibilității măsurilor.

Nu aștepta încheierea investigației pentru avertizarea timpurie. Etapele permit completarea informațiilor. Pe lângă raportarea către autorități, articolul 14(8) cere informarea utilizatorilor afectați și, după caz, a tuturor utilizatorilor, inclusiv despre măsurile relevante.

• Avertizare timpurie: fără întârziere nejustificată și în cel mult 24 de ore de la luarea la cunoștință.
• Notificare: fără întârziere nejustificată și în cel mult 72 de ore de la aceeași luare la cunoștință, cu informațiile disponibile și măsurile relevante.
• Raport final pentru vulnerabilitate: în cel mult 14 zile după ce devine disponibilă o măsură corectivă sau de atenuare.
• Raport final pentru incident grav: în termen de o lună de la transmiterea notificării din etapa de 72 de ore.

Notificarea se transmite prin SRP către CSIRT-ul desemnat coordonator și este, de regulă, accesibilă simultan ENISA. Competența depinde în principal de sediul unde sunt luate predominant deciziile privind securitatea produselor; există reguli suplimentare pentru producători fără sediu principal în UE. Lista oficială ENISA indică DNSC pentru România.

Reprezentantul care raportează are nevoie de un cont personal EU Login cu MFA. Potrivit FAQ-ului ENISA din 12 septembrie, înregistrarea și validarea asocierii în SRP sunt recomandate când trebuie transmisă o notificare; verificarea asocierii se poate desfășura în paralel cu raportarea. Pregătește contul și responsabilitățile înainte de incident.

La lansare, SRP nu oferă API pentru transmiterea automată a notificărilor. Dacă platforma este temporar indisponibilă, ENISA indică transmiterea la restabilire și, dacă este necesară comunicarea imediată, contactarea directă a CSIRT-ului; notificarea trebuie ulterior introdusă și în SRP.

Recomandarea noastră este un flux comun pentru securitate, dezvoltare, suport și management. Inventarul componentelor, contactele furnizorilor și dovezile trebuie să poată fi găsite de persoana de serviciu, nu doar de un singur dezvoltator. Relatarea independentă ITPro din 11 septembrie evidențiază tocmai dificultatea reconstruirii inventarului software în timpul unui incident.

Ca exercițiu intern, pornește de la un semnal fictiv despre o bibliotecă: cine confirmă versiunile folosite, cine analizează exploatabilitatea, unde ajung sesizările clienților și cine păstrează justificarea deciziei? Repetă apoi scenariul pentru un incident grav fără CVE public. Nu trimite notificări de test în SRP.

• Un responsabil și un înlocuitor pentru evaluare, escaladare, transmitere și comunicarea cu utilizatorii.
• Inventar de produse și versiuni, componente urmărite, surse publice și canale pentru sesizări nepublice.
• O cronologie cu date, ore, fusuri orare, dovezi și decizii motivate.
• Un dosar de caz care leagă notificarea, acțiunile, comunicările și verificarea măsurilor.

Funcționalitățile prezentate pentru Monitor includ agregarea programată la două ore din NVD, CISA KEV, EUVD și GitHub Advisories, prioritizare CVSS + EPSS, watchlist, asignare, note și exporturi de dovezi. Pro adaugă inventar pe versiuni din SBOM, package.json sau requirements.txt și integrări pentru fluxul echipei.

Aceste funcții pot susține investigarea semnalelor publice și documentarea acțiunilor. Inventarul trebuie corelat de echipă cu produsele comercializate, iar informațiile despre exploatare trebuie evaluate în context. Frecvența de două ore este caracteristica serviciului descris, nu un termen de scanare impus de CRA.

Monitor nu înlocuiește canalele pentru incidente și vulnerabilități nepublice, evaluarea juridică sau SRP. Nu prezentăm exporturile interne drept notificări oficiale și nu promitem conformitate CRA prin simpla utilizare a aplicației.

Checklistul AWARELY transformă aceste decizii în 12 pași, de la încadrare și acces până la notificare, raport final și exercițiu. Este disponibil integral pe site, în română și engleză, și poate fi parcurs împreună de echipe. Bifarea pașilor urmărește progresul de lucru; nu certifică încadrarea sau conformitatea.