Fabricarea unui dispozitiv IoT a fost tratată în mod tradițional ca un proiect hardware: electronică, carcasă, alimentare, compatibilitate electromagnetică, firmware, testare în producție, documentație și, apoi, vânzare.

Un produs conectat nu rămâne însă neschimbat după livrare. Apar vulnerabilități noi în codul propriu, în bibliotecile utilizate, în sistemul de operare sau în componentele de comunicație. Peisajul amenințărilor se poate schimba, în timp ce produsul funcționează ani de zile pe același amplasament.

Actul privind reziliența cibernetică (Cyber Resilience Act, CRA) al Uniunii Europene transformă acest risc legat de ciclul de viață într-o obligație a producătorului.

Unde ne aflăm în septembrie 2026?

CRA, adică Regulamentul (UE) 2024/2847, a intrat în vigoare la 10 decembrie 2024.

Principalele cerințe privind produsele se aplică de la 11 decembrie 2027. Obligațiile de raportare se aplică însă deja de la 11 septembrie 2026. Aceasta înseamnă că pregătirea nu este un proiect îndepărtat, care ar începe abia la sfârșitul lui 2027.

Regulamentul se aplică produselor hardware și software cu elemente digitale, iar domeniul de aplicare exact, categoria de produs și procedura de evaluare a conformității trebuie stabilite de fiecare producător pentru propriul produs.

Un gateway IoT industrial, un contor capabil de comunicare în rețea, un controler inteligent sau software-ul aferent aparține, foarte probabil, unei game de produse care trebuie reanalizată în mod conștient din cauza CRA.

Security by design nu mai este un slogan

Regulamentul impune cerințe obligatorii de securitate cibernetică în etapele de proiectare, dezvoltare, producție și întreținere. Prin urmare, securitatea nu poate fi „adăugată” produsului finit printr-un test de penetrare la finalul proiectului.

Încă de la nivelul arhitecturii trebuie decis, printre altele:

  • ce servicii sunt disponibile în mod implicit;
  • cum se realizează identificarea unică a dispozitivului;
  • dacă există date de autentificare implicite din fabrică, comune sau ușor de ghicit;
  • cum sunt protejate datele în tranzit și în stare de repaus;
  • cum poate fi restricționat accesul;
  • cum pot fi înregistrate evenimentele de securitate;
  • ce se întâmplă în cazul unor date de intrare eronate sau manipulate;
  • cum poate fi restabilită o stare sigură.

Principiul suprafeței minime de atac înseamnă că tot ceea ce nu este necesar pentru funcționarea produsului nu trebuie să fie disponibil în mod implicit.

Posibilitatea de actualizare este o funcție a produsului

Nu este suficient ca un dispozitiv conectat să fie proiectat astfel încât să pară sigur în ziua vânzării. El trebuie să poată fi și actualizat în siguranță.

Pentru aceasta pot fi necesare:

  • firmware semnat digital și cu integritate verificată;
  • un canal de actualizare securizat;
  • gestionarea versiunilor și a compatibilității;
  • restaurarea după o actualizare eșuată;
  • gestionarea dispozitivelor la scară largă, dar controlată;
  • jurnal de actualizări și stare a instalării;
  • comunicarea clară a perioadei de suport.

Actualizarea OTA nu înseamnă, în sine, securitate. Fără verificarea semnăturii, gestionarea drepturilor de acces, rollback sau dovada instalării, mecanismul de actualizare poate deveni el însuși o suprafață de atac.

Gestionarea vulnerabilităților pe întreaga perioadă de suport

Una dintre schimbările esențiale aduse de CRA este că tratează securitatea produsului ca pe un proces. Producătorul trebuie să fie capabil să primească, să evalueze, să remedieze și să comunice vulnerabilitățile.

Pentru aceasta este nevoie și de o organizare internă funcțională:

  • cine primește raportările de securitate;
  • cum se evaluează gravitatea și impactul;
  • ce versiuni ale produsului sunt afectate;
  • ce componentă cauzează problema;
  • cum se elaborează și se testează remedierea;
  • cum ajunge aceasta la clienți;
  • cum poate fi documentată închiderea cazului.

O simplă adresă de e-mail nu reprezintă, în sine, un proces de gestionare a vulnerabilităților.

Trebuie să știi ce conține firmware-ul

Firmware-ul și software-ul modern sunt rareori construite exclusiv din cod propriu. Biblioteci open-source, componente ale sistemului de operare, stive de rețea și SDK-uri ale furnizorilor se suprapun unele peste altele.

Dacă una dintre acestea devine vulnerabilă, producătorul trebuie să știe ce produse și ce versiuni sunt afectate. Pentru aceasta este necesară o evidență ordonată a dependențelor și componentelor. Lista componentelor software, adică SBOM, poate fi un instrument important în acest sens.

SBOM este însă doar un inventar. Aduce valoare atunci când este legat de gestionarea versiunilor, de informațiile privind vulnerabilitățile, de parcul de dispozitive afectat și de procesul de actualizare.

Obligația de raportare necesită capacitate de detectare

De la 11 septembrie 2026, producătorii au obligația de raportare în cazul anumitor vulnerabilități exploatate activ și al incidentelor de securitate grave. Procedura detaliată și îndrumările actuale ale autorităților trebuie urmate de producător în funcție de propriul rol și de propriul produs.

Din punct de vedere practic, un lucru este însă sigur: nu poți raporta la timp ceea ce organizația nu este capabilă să detecteze, să escaladeze intern și să asocieze cu versiunile produsului.

Prin urmare, condițiile prealabile ale procesului de raportare sunt:

  • o evidență a produselor și versiunilor;
  • o persoană de contact pentru securitate;
  • clasificarea incidentelor;
  • reguli de decizie și aprobare;
  • comunicarea cu clienții;
  • un jurnal de evenimente care poate servi drept dovadă.

În spatele marcajului CE vor sta dovezi privind dezvoltarea

Conform CRA, marcajul CE al produselor conforme va indica și faptul că acestea îndeplinesc cerințele de securitate cibernetică. În funcție de clasificarea de risc a produsului, poate fi necesară o procedură diferită de evaluare a conformității, pentru anumite categorii cu implicarea unui organism notificat (notified body).

Acest lucru presupune un proces de dezvoltare documentat. Trebuie păstrate evaluarea riscurilor, deciziile de arhitectură, rezultatele testelor, informațiile despre componente, gestionarea vulnerabilităților și dovezile privind lansările.

Este foarte dificil să reconstitui ulterior, în mod credibil, de ce a fost luată o decizie de securitate cu ani în urmă. De aceea, documentația trebuie construită odată cu dezvoltarea.

Ce înseamnă acest lucru pentru o dezvoltare de tip OrigSmart?

Având în vedere capabilitățile OrigSmart în domeniul hardware, al gateway-urilor și al platformei, securitatea nu se poate opri la carcasa dispozitivului. Întregul ciclu de viață al sistemului trebuie gestionat unitar:

  • hardware și firmware personalizate;
  • comunicație de teren;
  • identitatea și configurarea dispozitivelor;
  • actualizare securizată;
  • drepturi de acces la nivelul platformei;
  • jurnal de evenimente și monitorizare;
  • gestionarea incidentelor și a vulnerabilităților;
  • procese de operare la client.

Acoperirea întregului lanț valoric reprezintă în același timp o responsabilitate și un avantaj competitiv. Producătorul și integratorul care leagă hardware-ul, software-ul, operarea și procesele de securitate demonstrabile încă din faza de proiectare a produsului nu va fi nevoit să întocmească în grabă documente de conformitate la sfârșitul lui 2027.

Esența CRA nu este ca alături de dispozitivul IoT să existe mai multe hârtii, ci ca produsul digital să rămână un risc de securitate cibernetică gestionabil pe întreaga durată a ciclului său de viață suportat.

Să discutăm despre proiectul dumneavoastră

Surse

Notă: articolul oferă informații profesionale cu caracter general și nu constituie consultanță juridică sau de conformitate.