Cyber Resilience Act (CRA) 2026–2027: ce știm deja, ce încă lipsește și cum să pregătești în mod realist produsul — înainte să apară standardele armonizate

Ce știm astăzi cu certitudine (și de ce nu este un „subiect pentru 2027”)

Cyber Resilience Act poate părea încă un document „de la Bruxelles”, pe care îl poți lăsa pe mai târziu. Este o reacție firească, mai ales când compania funcționează în ritmul proiectelor: prototip, implementare, producție de serie, service. Reglementările ajung adesea ca o „cerință de final” — ceva ce se bifează la linia de sosire. CRA schimbă această logică, pentru că nu se referă doar la ceea ce se vede în produs în ziua vânzării. Se referă la faptul dacă producătorul poate menține securitatea produsului în timp și poate demonstra că a făcut asta în mod conștient, nu din întâmplare.

Cel mai important fapt este simplu, dar are consecințe strategice: CRA este o reglementare de produs, ancorată în mecanismele pieței UE (inclusiv marcajul CE). Comisia Europeană spune explicit că produsele trebuie să poarte marcajul CE ca semnal al conformității cu CRA, iar aplicarea revine autorităților de supraveghere a pieței. Așadar, nu este un „standard IT” pe care îl poți trata ca pe un program intern de îmbunătățire. Este un cadru care influențează posibilitatea de a vinde.

Date care clarifică modul de gândire

Chiar în textul Regulamentului (UE) 2024/2847 se vede aplicarea etapizată. CRA se aplică de la 11 decembrie 2027, dar cu excepții clare. Articolul 14 (raportarea) se aplică de la 11 septembrie 2026, iar capitolul privind notificarea organismelor de evaluare a conformității (Chapter IV) de la 11 iunie 2026. Acestea sunt trei date pe care merită să le tratezi ca „repere”, deoarece corespund la trei tipuri diferite de pregătire: operațională, instituțională și de produs.

Comisia comunică acest lucru și mai simplu: CRA a intrat în vigoare la 10 decembrie 2024, obligațiile esențiale încep de la 11 decembrie 2027, iar raportarea de la 11 septembrie 2026. Dacă cineva din companie spune „avem timp până în 2027”, de cele mai multe ori se referă la cerințele de proiectare și la evaluarea conformității. Dar raportarea este mai devreme și se aplică unor evenimente care nu așteaptă calendarul.

Raportarea: o obligație care impune un proces (nu un document)

Cerința de raportare este un bun test de turnesol, pentru că arată cum înțelege CRA „securitatea cibernetică a produsului”. Nu este o declarație de intenție și nici o „politică”. Este un proces care trebuie să funcționeze într-o situație de stres: când apare o vulnerabilitate exploatată activ sau un incident grav.

Comisia descrie acest lucru fără echivoc: producătorul trebuie să raporteze vulnerabilitățile exploatate activ și severe incidents care afectează securitatea produsului. Este necesar un „early warning” în 24 de ore de la momentul în care ia cunoștință, o notificare completă în 72 de ore, iar raportul final: în termen de 14 zile de la disponibilitatea măsurii de remediere pentru vulnerabilitățile exploatate activ și în decurs de o lună pentru severe incidents.

În practică, asta înseamnă că organizația are nevoie de mai mult decât o listă de verificare. Are nevoie de un mecanism care răspunde la trei întrebări: de unde aflăm că problema există; cine stabilește dacă este deja „exploatată activ” sau „severe”; și cum organizăm comunicarea informațiilor și remedierea într-un interval care nu lasă loc improvizației.

Dacă la instruiri apare haos, de multe ori este pentru că CRA lovește într-un gol dintre IT și produs. Pentru IT, un „incident” poate fi un eveniment din infrastructură. Pentru producător, un „incident” este un eveniment care afectează produsul la client, versiunea, configurația, modul de implementare. CRA obligă la conectarea acestor lumi într-o singură responsabilitate.

Ce acoperă CRA: produsul ca relație cu rețeaua, nu „un dispozitiv pe masă”

În practică, la evaluările de risc ale mașinilor am învățat că riscul nu este o caracteristică a mașinii în sine — el apare în relația om–mașină. În CRA există o schimbare similară de perspectivă: securitatea nu există „în dispozitiv”, ci în relația produsului cu mediul digital, modul de utilizare și capacitatea producătorului de a reacționa.

Comisia, rezumând CRA, atrage atenția asupra definiției „produselor cu elemente digitale” și asupra faptului că obligațiile de raportare se aplică tuturor acestor produse puse la dispoziție pe piața UE — inclusiv celor introduse înainte de 11 decembrie 2027. Aceasta este o precizare esențială, pentru că elimină un mit frecvent: „pentru produsele vechi nu contează”. Raportarea — contează.

Ceea ce încă lipsește (standardele armonizate) și de ce nu ar trebui să blocheze

W discuțiile despre CRA revine des fraza: „încă nu există standarde armonizate, deci nu se poate face nimic”. Sună logic, dar ascunde o capcană. Standardele armonizate sunt un instrument care ușurează demonstrarea conformității (prezumția de conformitate), însă nu sunt singura cale de a construi o siguranță reală a produsului. Și nu sunt o condiție ca să începi să proiectezi corect.

Comisia abordează explicit subiectul standardelor prin pagina „CRA Standardisation” și informează că a adoptat standardisation request M/606, care acoperă un set de 41 de standarde ce sprijină CRA — atât orizontale, cât și verticale (pe produs). Este important, pentru că arată că UE înțelege problema pieței: fără standarde, companiile vor construi conformitatea fiecare în felul ei, iar supravegherea pieței va avea mai mult de lucru.

Standarde orizontale și verticale: ce înseamnă asta pentru producător

Pe scurt:

• standardele orizontale ar trebui să descrie „cum” se construiește și se menține securitatea produsului, indiferent de categorie (procese, metode, abordare bazată pe risc),
• standardele verticale ar trebui să detalieze cerințele pentru clase concrete de produse (acolo unde riscurile și arhitecturile sunt tipice).

Această diferențiere are consecințe practice. Dacă dezvolți un produs industrial, în care o parte din mediu este „OT” și ciclul de viață este lung, vei avea nevoie de standarde care nu sunt scrise pentru o aplicație SaaS. Tocmai de aceea standardele verticale contează: te ajută să cobori de la nivelul principiilor generale la ceea ce trebuie controlat în arhitecturi reale.

Calendarul lucrărilor: standardele vor apărea treptat, nu „la pachet înainte de 2027”

Comisia arată în materialele despre implementarea CRA că CRA se aplică etapizat, iar standardele trebuie să sprijine acest proces în timp. La nivelul faptelor certe astăzi: avem un regulament adoptat formal și avem pus în funcțiune mecanismul de standardizare (M/606).

Cel mai important pentru practică este să înțelegi o propoziție: chiar dacă un standard este elaborat de organizațiile de standardizare, „prezumția de conformitate” în sens juridic apare abia când referința la standard este publicată ca standard armonizat în Jurnalul Oficial al UE. Acesta este mecanismul comun al abordării UE privind armonizarea: standardele sunt puntea dintre drept și practica inginerească, dar această punte trebuie să fie „recunoscută” formal de UE.

Din perspectiva producătorului, asta înseamnă că anii 2026–2027 vor fi o perioadă în care unele companii vor acționa pe baza propriilor metode de demonstrare a conformității (bazat pe risc + dovezi), iar altele vor începe deja să se alinieze la standardele care apar. Și este normal.

„Lipsa standardelor” nu înseamnă „lipsa obligației” — înseamnă o greutate mai mare a dovezilor

Aici apare o consecință importantă: dacă nu există standarde care oferă cea mai simplă cale de a demonstra conformitatea, crește importanța a ceea ce, în practica de audit, este întotdeauna decisiv: un fir decizional coerent.

Ce riscuri am evaluat? Ce scenarii am considerat realiste? Cum am ales măsurile de protecție? Cum gestionăm vulnerabilitățile? Cât timp susținem produsul? Cum informăm clientul? CRA nu cere ca producătorul să „ghicească viitoarele standarde EN”. Cere ca producătorul să poată arăta că deciziile lui nu au fost întâmplătoare, ci bazate pe risc și pe state of the art.

Cum să pregătești în mod realist produsul pentru CRA (foaie de parcurs pentru producător și integrator)

Cea mai mare valoare a CRA este că impune maturitate: securitatea cibernetică încetează să mai fie un adaos la produs și devine o proprietate a lui. Doar că maturitatea nu se naște din declarații. Se naște dintr-un proces suficient de precis ca să funcționeze în practică și suficient de simplu încât ingineria să nu înceapă să-l ocolească.

În evaluarea riscului pentru mașini, cele mai bune decizii de proiectare apar atunci când încetăm să întrebăm „ce pericole are mașina” și începem să întrebăm „în ce sarcini și stări este expus omul”. În CRA, analog: încetăm să întrebăm „ce vulnerabilități are produsul” și începem să întrebăm „în ce condiții devine produsul expus și ce poate face atunci producătorul”. Această schimbare pune ordine în muncă.

Pasul 1: Definește produsul ca sistem (nu ca dispozitiv)

Începe prin a defini ce este, în cazul tău, „un produs cu elemente digitale”. Nu doar hardware și firmware, ci și ceea ce este adesea omis pentru că nu încape în cutie: componente, biblioteci, mecanisme de actualizare, servicii fără de care produsul nu își îndeplinește funcția. În CRA, acest lucru contează, pentru că responsabilitatea producătorului se referă la ceea ce ajunge pe piață ca produs — nu doar la ceea ce a realizat departamentul de mecanică.

Este și primul moment în care integratorii ar trebui să fie sinceri cu ei înșiși: dacă integrezi componente și le configurezi într-un mod care creează „produsul final” în ochii clientului, atunci nu ești doar „cel care implementează”. Ești coautor al riscului și coautor al responsabilității.

Pasul 2: Fă evaluarea riscului CRA astfel încât să fie un instrument de decizie

Nu e vorba despre o „matrice” pe slide-uri. E vorba despre o evaluare a riscului care duce la decizii de proiectare și care poate fi repetată în mod consecvent.

În practică, o abordare bună a CRA începe cu o întrebare simplă: care sunt scenariile reale de utilizare abuzivă în mediul clientului, nu doar în laborator? Cine are acces de service? Cum arată rețeaua? Cât de des facem actualizări? Care sunt consecințele unei opriri? În industrie, aceste întrebări sunt mai incomode decât în IT, pentru că răspunsurile sună adesea: „nu putem actualiza săptămânal” sau „nu avem telemetrie”. Și tocmai de aceea trebuie puse. CRA este o obligație legală, dar efectele lui sunt de proiectare.

Krok 3: Construiește „vulnerability handling” ca proces de producție, nu ca reacție de criză

Cerințele de raportare descrise de Comisie (24h/72h/14 zile/lună) sunt necruțătoare pentru o organizație care nu are un proces. Dacă vrei să fii pregătit pentru 11 septembrie 2026, trebuie să tratezi „vulnerability handling” ca parte a ciclului de viață al produsului, nu ca „sarcina echipei de security”.

Asta înseamnă:

• un singur canal de primire a raportărilor (CVD policy + contact),
• un triage cu responsabil clar și criterii,
• un mecanism de construire și livrare a security updates,
• un model de comunicare către clienți care nu se bazează pe improvizație,
• pregătire pentru raportare (cine raportează, cu ce date, cât de repede).

Toate acestea sună ca muncă „organizațională”. În practică, este muncă de produs, pentru că ține de versiuni, compatibilitate, arhitectura actualizărilor și strategia de suport.

Krok 4: Alege support period ca o decizie de business, nu ca un minim obligatoriu

Dacă produsele tale trăiesc în industrie 10–15 ani, atunci support period este strategic. CRA obligă ca suportul să nu fie o promisiune fără acoperire. Asta înseamnă că support period ar trebui să rezulte dintr-o analiză: cât timp va fi folosit produsul, cum arată lanțul de aprovizionare pentru componente, cât timp vei putea livra remedieri. În practică, support period începe să „tragă” după el întregul ecosistem: contractele cu furnizorii, disponibilitatea build environment, mentenanța toolchain-urilor și chiar deciziile despre dacă produsul are funcții la distanță sau este izolat.

Dacă tratezi support period ca pe o formalitate, cel târziu în 2027 vei intra într-un conflict: clientul se așteaptă la suport, iar tu nu mai ai resursele sau dependențele necesare ca să îl livrezi. CRA nu creează această problemă — CRA doar o scoate la iveală.

Krok 5: Pune în ordine lanțul de aprovizionare: discuția cu furnizorii face parte din conformitate

În CRA nu există „magie” care să facă automat componentele externe sigure. Dacă dispozitivul tău se bazează pe biblioteci, module de comunicație, sistem de operare, SDK sau componente hardware, atunci riscul tău depinde direct de calitatea practicilor furnizorului.

De aceea, merită să introduci chiar de acum discuții despre lucruri care nu sună a marketing, ci a inginerie:

• dacă furnizorul poate informa despre vulnerabilități într-un mod previzibil,
• care este timpul lui de reacție,
• dacă are un proces de publicare a remedierilor,
• dacă poate menține componenta pe o perioadă compatibilă cu support period-ul tău.

Aici CRA atinge cu adevărat businessul: un furnizor care nu poate gestiona vulnerabilitățile nu este „mai ieftin”. Este un risc de reglementare.

Krok 6: Construiește documentația ca o urmă coerentă: lege → risc → decizie → dovadă

În audituri de conformitate câștigă întotdeauna coerența. Dacă din evaluarea riscului rezultă că o anumită interfață este critică, iar documentația nu descrie cum o securizezi; dacă declari că actualizările sunt sigure, dar nu poți arăta cum asiguri integritatea pachetelor; dacă spui că ai un proces de gestionare a vulnerabilităților, dar nu poți arăta cum faci triage pentru raportări — asta nu este „lipsă de hârtii”. Este lipsa dovezii că procesul funcționează.

În CRA, în lipsa standardelor armonizate, această urmă este deosebit de importantă. Pentru că ea va sta la baza discuției cu autoritatea de supraveghere a pieței, cu un client enterprise, iar în unele categorii de produse și cu organismul de evaluare a conformității. Iar la fel de important: ea va sta la baza stabilității interne. Echipa știe de ce facem ceva, nu doar „că trebuie”.

Încheiere: CRA ca o nouă cerință de proiectare, nu un „proiect de compliance”

Dacă ar fi să las o singură idee care leagă cele trei părți: CRA nu este o problemă de rezolvat la final. Este un cadru care schimbă modul de a gândi produsul. Așa cum ISO 12100 învață că riscul apare în relația om–mașină, tot așa CRA învață că securitatea cibernetică apare în relația produs–mediu–ciclul de viață al producătorului.

Standardele armonizate vor veni și vor simplifica anumite trasee. Dar lipsa lor nu este un motiv de inerție. Este un motiv să te concentrezi pe ceea ce CRA evaluează întotdeauna: pe decizii, pe dovezi și pe capacitatea de a acționa în realitate — nu în prezentare.