Obligațiile de notificare CRA: separarea corectă a pașaportului de produs, a notificării de securitate și a istoricului actualizărilor

La 11 septembrie 2026 începe, pentru producătorii de produse cu elemente digitale, una dintre cele mai timpurii obligații operaționale prevăzute de Cyber Resilience Act (CRA): vulnerabilitățile exploatate activ și incidentele grave de securitate trebuie raportate prin noua platformă centrală de notificare. Aceasta este mai mult decât un nou termen de conformitate. În câteva ore, identitatea produsului, piețele afectate, evaluarea tehnică și măsurile luate trebuie reunite.

Un pașaport digital al produsului sau o pagină de produs asociată unui cod QR poate ajuta la identificarea unică a unui dispozitiv și la informarea ulterioară a utilizatorilor despre o actualizare. Totuși, acesta nu este nici canalul legal de notificare, nici locul potrivit pentru stocarea detaliilor confidențiale despre exploatare. Prin urmare, producătorii ar trebui să separe încă de acum trei fluxuri de date: notificarea către autorități, informațiile publice despre produs și istoricul intern al actualizărilor.

Noul context: orientările din 27 și 31 iulie

Comisia Europeană a publicat la 27 iulie 2026 primele sale orientări CRA cuprinzătoare. Acestea abordează, printre altele, obligațiile de notificare, evaluarea riscurilor, perioadele de asistență și modificările semnificative. Orientările nu sunt obligatorii, dar explică, prin 67 de exemple, modul în care companiile pot aplica practic regulamentul.

Patru zile mai târziu, la 31 iulie, ENISA și-a actualizat informațiile despre Single Reporting Platform. Acestea includ acum fluxul planificat, câmpurile de introducere prevăzute și indicații privind înregistrarea. Platforma ar trebui să fie operațională până la 11 septembrie 2026; potrivit Comisiei, testele funcționale și de securitate sunt deja în desfășurare.

Eșalonarea în timp este importantă: obligațiile principale ale CRA se aplică, în principiu, începând cu 11 decembrie 2027. Articolul 14, care reglementează obligațiile de notificare, se aplică însă deja din 11 septembrie 2026. Acest lucru este confirmat atât de articolul 71 din Regulamentul (UE) 2024/2847, cât și de prezentarea generală a Comisiei privind procedura de notificare CRA, actualizată la 31 iulie.

Trei spații de date în locul unui pașaport de produs supraîncărcat

Notificarea CRA și o pagină publică de produs urmăresc obiective diferite. Dacă ambele sunt reprezentate într-un singur set de date, există riscul fie să nu existe suficiente informații pentru echipa de incidente, fie ca prea multe detalii sensibile să ajungă pe web-ul public.

1. Notificarea confidențială către SRP, CSIRT și ENISA

Single Reporting Platform este canalul legal de primire. Trebuie raportate două tipuri de evenimente: o vulnerabilitate exploatată activ, pentru care există indicii fiabile privind o exploatare neautorizată, și un incident grav care afectează disponibilitatea, autenticitatea, integritatea sau confidențialitatea datelor ori funcțiilor.

Notificarea nu conține doar denumirea produsului. ENISA enumeră, printre altele, statele membre afectate, o evaluare inițială, contramăsurile deja luate, posibilele măsuri pentru utilizatori și sensibilitatea informațiilor ca fiind câmpuri relevante. Etapele ulterioare pot include nivelul de gravitate, impactul, informații despre atacator și detalii tehnice privind actualizarea de securitate. Astfel de informații nu trebuie publicate automat pe o pagină DPP accesibilă liber.

2. Informații publice despre produs și securitate

Fluxul public de date răspunde altor întrebări: Ce produs și ce versiune dețin? Mai beneficiază acesta de asistență? Este disponibilă o actualizare de securitate? Ce trebuie să fac concret în calitate de utilizator? În acest scop, poate fi utilă o pagină de produs stabilă accesată printr-un cod QR sau un alt suport de date.

Pagina publică ar trebui să afișeze numai informații aprobate: intervalele de modele și versiuni afectate, versiunea sigură disponibilă, instrucțiuni de instalare, contactul pentru asistență și momentul publicării. Detaliile despre exploatare, regulile interne de detectare, căile de atac nepremiate sau datele cu caracter personal despre incidente rămân în procedura protejată. Decizia privind o avertizare publică nu aparține codului QR: în temeiul articolului 17 CRA, CSIRT-ul coordonator poate informa publicul sau poate solicita producătorului să facă acest lucru, dacă este necesar pentru prevenire sau limitare.

3. Istoricul intern al actualizărilor și al dovezilor

Al treilea flux este dosarul de lucru trasabil. Acesta asociază identificatorul produsului, versiunea hardware și software, lista componentelor software, momentul în care s-a luat cunoștință de problemă, deciziile de triere, nivelurile de notificare, aprobarea patch-ului și comunicarea publică. Acest istoric trebuie să versionizeze modificările, nu să suprascrie în tăcere evaluările anterioare.

Pentru o operațiune DPP, această diferență este esențială: vizualizarea publică arată starea curentă aprobată, iar istoricul intern demonstrează modul în care aceasta a fost creată. Cei care gestionează deja datele despre produse pe bază de evenimente pot utiliza același principiu ca în cazul DPP-actualizărilor și webhook-urilor: un eveniment declanșează procese ulterioare, însă fiecare destinatar primește doar câmpurile prevăzute pentru rolul său.

Ceasul CRA pornește din momentul luării la cunoștință

Articolul 14 prevede termene etapizate. Pentru o vulnerabilitate exploatată activ este necesară, fără întârzieri nejustificate și cel târziu în termen de 24 de ore de la luarea la cunoștință, o avertizare timpurie. În termen de 72 de ore urmează notificarea mai detaliată a vulnerabilității. Raportul final trebuie să fie disponibil cel târziu în termen de 14 zile după ce este disponibilă o măsură de corectare sau de atenuare.

În cazul unui incident grav de securitate, se aplică de asemenea 24 de ore pentru avertizarea timpurie și 72 de ore pentru notificarea incidentului. Raportul final urmează în termen de o lună de la notificarea transmisă în 72 de ore. Prin urmare, termenele nu încep să curgă de la publicarea unui CVE și nici de la următoarea versiune regulată, ci din momentul în care producătorul este considerat informat.

În practică, se recomandă un flux clar:

Înregistrați cu marcaj temporal sesizarea provenită din asistență, monitorizare, cercetare sau lanțul de aprovizionare.
Identificați produsul și versiunea prin raportare la un identificator intern stabil al produsului.
Evaluați exploatarea, respectiv gravitatea incidentului, împreună cu echipa responsabilă.
Generați setul de date pentru 24 de ore pe baza informațiilor minime confirmate și transmiteți-l prin SRP.
Completați constatările tehnice până la etapa de 72 de ore, fără să pierdeți starea inițială.
Aprobați separat patch-ul, măsura pentru utilizatori și informațiile publice.
Corelați raportul final cu istoricul intern.

Acest lanț ar trebui exersat înainte de septembrie. ENISA subliniază că organizațiile își pot automatiza procesele interne și bazele de date, însă platforma nu va oferi un API la lansare. Prin urmare, un proces de export și verificare de către două persoane este mai realist decât o integrare directă neverificată.

Un identificator comun al produsului, dar drepturi de acces separate

Separarea nu înseamnă întreținerea a trei copii necorelate. Abordarea mai bună este o referință comună și imuabilă a produsului, cu vizualizări dependente de rol.

Cel puțin următoarele asocieri ar trebui să existe:

identificatorul intern al produsului și referința la model, lot sau serie;
versiunea hardware, firmware și software;
statele membre în care a fost pusă la dispoziție versiunea afectată;
starea evaluării de securitate și momentul luării la cunoștință;
referințe la notificarea de 24 de ore, cea de 72 de ore și raportul final;
măsura aprobată pentru utilizatori și versiunea-țintă sigură;
starea publicării paginii publice a produsului.

Autorizarea ar trebui concepută la nivel de câmp. Echipa de incidente și responsabilii CRA au nevoie de dosarul complet. Asistența și vânzările au nevoie de instrucțiuni aprobate. Utilizatorii văd doar notificarea publică. În acest context, un cod QR ar trebui să transporte ideal doar o adresă stabilă a produsului; platforma din spatele acesteia decide, în funcție de stare și rol, ce informații sunt furnizate.

Ce ar trebui să testeze producătorii până în septembrie

Un caz de testare adecvat nu necesită o vulnerabilitate reală. Alegeți un produs conectat, o versiune de firmware afectată și trei state membre. Simulați momentul luării la cunoștință într-o zi lucrătoare și verificați:

Poate echipa să confirme în termen de 24 de ore acoperirea produsului și informațiile minime?
Este clar cine ar trebui să acceseze SRP în calitate de reprezentant prin EU Login?
Pot fi adăugate informațiile pentru 72 de ore fără ca detaliile confidențiale să devină publice?
Aprobarea patch-ului conduce la o informare verificată a utilizatorilor în toate limbile necesare?
Rămâne URL-ul public stabil atunci când se schimbă versiunea și măsurile?
Se poate identifica cine a aprobat ce stare și când?

Pentru ultimul punct este utilă o gestionare consecventă și versionată a datelor. Articolul qr3 despre actualizarea continuă a DPP prezintă ideea de bază: identitatea rămâne stabilă, în timp ce datele de specialitate sunt actualizate controlat. În procesul CRA se adaugă un nivel mai strict de confidențialitate și aprobare.

Concluzie: pașaportul de produs este distribuitor, nu punct de notificare

Noile orientări fac termenul din septembrie relevant din punct de vedere operațional. Producătorii nu trebuie să integreze o bază de date confidențială privind vulnerabilitățile în pașaportul lor digital al produsului. Au nevoie, mai degrabă, de o tranziție solidă între trei domenii clar separate: notificarea către autorități, dovezile interne și informațiile aprobate pentru utilizatori.

Un identificator comun al produsului ține unite aceste domenii. Rolurile, aprobările și versionarea împiedică divulgarea detaliilor confidențiale sau informarea prea târzie a utilizatorilor despre o măsură disponibilă. Codul QR rămâne util, dar intenționat nespectaculos: conduce permanent la contextul corect al produsului. Conformitatea CRA propriu-zisă ia naștere în procesele din spatele acestuia.