Pe 11 septembrie se schimbă regulile pentru oricine vinde software în UE: 24 de ore ca să raportezi

Pe 11 septembrie 2026 intră în vigoare obligațiile de raportare din Regulamentul european privind reziliența cibernetică — Cyber Resilience Act. De la acea dată, producătorii de produse cu elemente digitale trebuie să raporteze vulnerabilitățile exploatate activ și incidentele severe către echipa națională de răspuns la incidente și către ENISA, printr-o platformă unică de raportare. Mai sunt aproximativ cinci săptămâni.

Am scris la sfârșitul lui iulie despre ghidul practic publicat de Comisia Europeană și despre ce trebuie clarificat înainte de termen. Articolul de față nu repetă acel material: se ocupă exclusiv de mecanica raportării — cine apasă butonul, de când pornește ceasul și ce se întâmplă în primele 24 de ore.

Cine intră sub incidență — probabil mai mulți decât cred

Sfera este „produse cu elemente digitale" puse la dispoziție pe piața Uniunii Europene: software, dispozitive IoT, sisteme de automatizare industrială, echipamente medicale, echipamente de rețea și sisteme încorporate. Nu este o reglementare pentru marii producători de tehnologie. O firmă românească de zece oameni care vinde o aplicație sau un dispozitiv conectat pe piața europeană este producător în sensul regulamentului, cu aceleași obligații de raportare ca oricine altcineva.

Distincția față de NIS2 merită clarificată, pentru că se confundă des. NIS2 privește modul în care îți operezi propria organizație și se aplică unor sectoare și dimensiuni definite. Cyber Resilience Act privește produsele pe care le pui pe piață și se aplică indiferent de mărimea companiei. Poți să fii în afara NIS2 și complet sub incidența CRA.

Ce înseamnă „24 de ore" în practică

Ceasul pornește din momentul în care ai aflat că o vulnerabilitate din produsul tău este exploatată activ. Nu de când ai confirmat, nu de când ai înțeles amploarea, nu de când ai pregătit patchul. Iar 24 de ore înseamnă inclusiv weekendul și inclusiv perioada de concediu a singurului om care știe cum funcționează componenta afectată.

Este exact tipul de termen care nu poate fi respectat improvizat. Dacă în momentul în care afli trebuie să stabilești cine decide, cine scrie, unde se trimite și cine semnează, cele 24 de ore se consumă în ședințe. Organizațiile care vor reuși sunt cele care au decis toate astea în avans și le-au exersat măcar o dată.

• Numește acum persoana care are dreptul să raporteze, plus un înlocuitor. Nu un departament — un om, cu nume, și un al doilea pentru când primul e indisponibil.
• Stabilește ce declanșează ceasul și scrie-o. „Exploatare activă" trebuie să însemne același lucru pentru echipa de suport, pentru dezvoltatori și pentru conducere, altfel primul dezacord costă o zi.
• Pregătește un canal prin care cercetătorii externi îți pot semnala vulnerabilități. Multe organizații vor afla despre propriile probleme de la un terț, iar dacă acel terț nu are unde să scrie, vei afla din presă.
• Fă un exercițiu de masă, cu ceasul pornit. O simulare de două ore arată imediat unde se blochează procesul, iar costul descoperirii este zero.

Contextul: ENISA a devenit și autoritate de vulnerabilități

Baza europeană de date privind vulnerabilitățile, prevăzută de NIS2, este operațională și administrată de ENISA, iar agenția a preluat și rol de autoritate în sistemul internațional de identificare a vulnerabilităților. Se conturează astfel o infrastructură europeană proprie de gestionare a vulnerabilităților, cu propriile identificatoare și propria platformă de raportare, în paralel cu cea americană.

Consecința practică pentru echipele tehnice: sursele pe care le urmăriți pentru vulnerabilități se dublează, iar procesele care presupun implicit „identificatorul CVE este singura referință" trebuie revizuite. Pentru cine face management de vulnerabilități cu unelte automate, merită verificat de pe acum dacă acestea consumă și baza europeană.

De ce contează dincolo de conformitate

Datele ENISA arată pentru organizațiile europene o creștere de 23% de la an la an a incidentelor de tip ransomware, cu dubla extorcare devenită model implicit, și o creștere de 42% a atacurilor pe lanțul de aprovizionare, în care atacatorii vizează furnizori mici și biblioteci open-source ca să ajungă la ținte mari din aval. A doua cifră este cea care explică logica întregii reglementări.

Am scris săptămâna aceasta despre două incidente care ilustrează exact tiparul: viermele care a otrăvit pachetele npm keyv și cacheable, propagându-se la sute de pachete din organizații fără nicio legătură între ele, și vulnerabilitatea TeamCity exploatată activ, unde compromiterea unui server de build oferă acces la tot ce se livrează prin el. În ambele, victima finală nu a fost atacată direct. A primit codul otrăvit de la cineva în care avea încredere.

Obligația de raportare în 24 de ore urmărește să scurteze exact intervalul în care restul lanțului nu știe încă. Nu împiedică atacul, dar reduce fereastra în care el se propagă în tăcere — iar în incidentele de acest tip, fereastra a fost măsurată în ore, nu în săptămâni.

Ce faci în următoarele cinci săptămâni

Dacă nu ai început, ordinea utilă este: stabilește dacă produsele tale intră sub incidență, numește oamenii, scrie procedura pe o pagină, deschide un canal de contact pentru raportări externe, verifică dacă echipa națională de răspuns la incidente are cerințe proprii de format, și exersează o dată. Nimic din toate astea nu cere buget. Cere doar să fie decis înainte, nu în primele 24 de ore ale unui incident real.