EU Cyber Resilience Act va fi cea mai consecințială reglementare de cybersecurity pentru producători pe piața europeană. Primele obligații se aplică din 2026 (raportare vulnerabilități și incidente), iar aplicabilitatea completă — inclusiv evaluarea de conformitate pentru marcajul CE — intră în 2027.
Dacă firma ta face un produs cu elemente digitale pe care îl plasezi pe piața UE, CRA se aplică. Pragurile nu se bazează pe mărimea companiei; se bazează pe clasa produsului. Acest articol parcurge cum ar trebui să arate planul tău de evaluare de conformitate și munca pe care ar trebui să o faci acum, nu la sfârșitul lui 2026.
Scop: cine intră?
Un „produs cu elemente digitale” e, în limbajul CRA, orice produs software sau hardware care procesează date și are conexiune logică sau fizică. Asta include:
- Produse consumer conectate (camere, dispozitive smart-home, wearables).
- Componente de automatizare industrială și PLC-uri.
- Produse software vândute sau licențiate în UE, inclusiv SaaS în unele lecturi (cazurile la limită sunt încă clarificate de ghidul Comisiei Europene).
- Sisteme de operare, browsere, produse de securitate, produse de identitate.
- Specific exclus: SaaS care nu se califică ca „produs” sub regulament, software open-source liber dezvoltat în afara activității comerciale și câteva produse specifice sectorului acoperite de alte reglementări (dispozitive medicale sub MDR, vehicule).
Anexa I — cerințele esențiale de cybersecurity
Anexa I e scurtă și severă. Produsul trebuie:
- Să fie proiectat, dezvoltat și produs să asigure un nivel adecvat de cybersecurity.
- Să nu aibă vulnerabilități exploatabile cunoscute la momentul plasării pe piață.
- Să aibă o configurare default sigură.
- Să suporte update-uri de securitate pe perioada de suport (pe care CRA îți cere să o declari).
- Să protejeze confidențialitatea datelor stocate, transmise și procesate, cu criptografie by default unde e adecvat.
- Să protejeze integritatea datelor stocate, transmise și procesate.
- Să proceseze doar date adecvate, relevante și limitate la ce e necesar.
- Să protejeze disponibilitatea funcțiilor esențiale.
- Să minimizeze impactul incidentelor.
- Să furnizeze informații relevante de securitate prin mecanisme adecvate (loguri, telemetrie).
- Să permită adresarea vulnerabilităților prin update-uri de securitate, inclusiv update-uri automate by default pentru produse consumer.
Cerința „fără vulnerabilități exploatabile cunoscute la momentul plasării pe piață” e cea mai mare schimbare comportamentală pentru echipele de produs obișnuite să livreze cu o listă cunoscută de bug-uri.
Anexa II — gestionarea vulnerabilităților
Anexa II e procesul de gestionare a vulnerabilităților pe care trebuie să îl operezi pe durata de viață a produsului:
- Identifică și documentează componentele produsului, inclusiv prin producerea unui SBOM într-un format folosit comun.
- Adresează și remediază vulnerabilitățile fără întârziere, inclusiv prin furnizarea de update-uri de securitate.
- Aplică teste eficiente și regulate de securitate ale produsului.
- Coordonează divulgarea vulnerabilităților, inclusiv cu ENISA.
- Pune la dispoziție un contact pentru raportare vulnerabilități.
- Asigură mecanisme pentru distribuirea sigură a update-urilor.
- Asigură divulgarea publică promptă a vulnerabilităților remediate, inclusiv descrierea, impactul și măsurile corective.
Articolul 14 — raportare incidente și vulnerabilități exploatate
CRA introduce două obligații distincte de raportare:
- O „vulnerabilitate exploatată activ” trebuie raportată la ENISA în 24 de ore de la conștientizare, cu follow-up în 14 zile. Pragul „exploatată activ” e exploatare în viu, nu exploitability teoretic.
- Un „incident sever cu impact asupra securității produsului” trebuie raportat la ENISA în 24 de ore, cu follow-up în 72 de ore și 1 lună.
Rute de evaluare de conformitate
Ruta depinde de clasa produsului. Majoritatea produselor vor folosi Modulul A — control intern al producției plus auto-declarare. Produsele importante (Clasa I și Clasa II) cer fie Modulul B+C, Modulul D, fie Modulul H, în funcție de clasă. Produsele critice cer implicarea unui organism notificat.
Pentru majoritatea produselor software, pachetul practic de evaluare de conformitate arată așa:
- Evaluare de risc cybersecurity a produsului, documentată.
- Probă de practici sigure de dezvoltare (recomandăm mapare pe ISO/IEC 27034 și IEC 62443-4-1).
- Raport de pentest față de cerințele Anexa I, ideal re-testat înainte de fiecare release.
- SBOM într-un format folosit comun (CycloneDX sau SPDX).
- Politică și probă de proces de gestionare a vulnerabilităților.
- O perioadă de suport declarată și o politică publicată de update-uri de securitate.
- Declarație UE de conformitate — output-ul legal al evaluării.
Ce să faci în 2026
- Construiește pipeline-ul SBOM astăzi. CycloneDX sau SPDX, generat în CI, atașat la release-uri. E munca cu cel mai mare lead-time și cea mai ușor de subestimat.
- Ridică un proces de divulgare coordonată a vulnerabilităților cu un contact clar (security.txt, vezi RFC 9116).
- Rulează un gap analysis CRA Anexa I pe produsul cel mai strategic. Findings-urile conduc backlog-ul de produs din 2026.
- Decide perioada de suport. Doi ani e podeaua de facto; mulți regulatori vor sonda pentru cinci.
- Documentează ciclul de viață al dezvoltării sigure. Auditorul citește ce ai scris, nu ce descrii verbal.
Unde se potrivește Sandline
Rulăm evaluări pre-piață de securitate față de Anexa I, ridicăm procesul de divulgare coordonată, generăm SBOM-ul și rulăm gap analysis-ul. Declarația de conformitate e a ta de făcut; noi producem proba tehnică de dedesubt.