CRA pentru producătorii de mașini, după orientările Comisiei din 27 iulie 2026. Ce trebuie implementat în realitate?

Mulți ani, securitatea cibernetică a unei mașini părea să poată fi rezumată în trei pași: un controler de marcă, un VPN „pentru că așa se face” și clasica formulă „clientul își va securiza rețeaua”. Iar dacă cineva mai adăuga și un firewall în dulapul de comandă, subiectul era adesea considerat închis — cel puțin până în momentul în care cineva încerca să verifice ce se întâmplă după un atac real, nu într-o prezentare.

Doar că securitatea cibernetică nu circulă prin PROFINET. Componentele pot avea certificate, declarații și „secure by design” în broșura de marketing, dar mașina, ca ansamblu, poate rămâne în continuare previzibilă într-un mod care nu are nimic de-a face cu siguranța. Așa cum un releu de siguranță nu face sistemul sigur dacă logica de comandă permite ocolirea lui, tot așa un HMI „sigur” nu rezolvă problema arhitecturii, a integrării, a drepturilor de acces, a actualizărilor și a ceea ce se întâmplă când cineva nu mai cere permisiune.

CRA (Cyber Resilience Act, Regulamentul Parlamentului European și al Consiliului (UE) 2024/2847) nu este un adaos pentru IT. Este o reglementare de produs, care intră în ciclul de viață al mașinii fără să ceară acordul departamentului de automatizare. Acoperă proiectarea sistemului de comandă, analiza riscurilor, lanțul de aprovizionare, configurarea, actualizările, precum și menținerea produsului mult timp după ce FAT a fost semnat și mașina a părăsit hala. Și nu, argumentul „nu o expunem la internet” nu închide subiectul. În practică, este suficient un laptop de service, un stick USB, o diagnoză la distanță „doar pentru moment” sau integrarea cu sistemul fabricii pentru ca granița dintre izolare și expunere să înceteze să mai existe.

Orientările Comisiei din 27 iulie 2026 nu au modificat regulamentul în sine, dar au limitat în mod eficient spațiul de interpretare care anterior permitea tratarea securității cibernetice ca pe un strat opțional. Au fost clarificate, printre altele, limita produsului, rolul prelucrării la distanță, răspunderea pentru modificările după livrare, precum și faptul că „nu mai este problema noastră după FAT” nu mai reprezintă o presupunere sigură.

Cea mai importantă schimbare este însă mai fundamentală: un atac cibernetic încetează să mai fie exclusiv un eveniment IT și devine un scenariu care influențează siguranța funcțională a mașinii. Dacă o modificare neautorizată a programului poate provoca mișcarea unei axe, ocolirea unei interblocări, schimbarea parametrilor de proces sau pierderea unei funcții de siguranță, atunci nu mai vorbim despre un „incident de rețea”. Vorbim despre un comportament potențial necontrolat al mașinii — indiferent dacă sursa a fost o eroare de configurare, o vulnerabilitate software sau o intervenție intenționată.

În acest context, un test de penetrare efectuat o singură dată înainte de FAT încetează să mai fie o dovadă a conformității și devine doar o imagine de moment a stării sistemului la un anumit moment. CRA impune o abordare continuă: de la proiectare, prin producție și punere în funcțiune, până la actualizări, gestionarea vulnerabilităților, reacția la incidente și mentenanța pe durata perioadei de suport declarate.

În practică, asta înseamnă renunțarea la gândirea de tipul „gata = sigur” în favoarea unei abordări de tipul „menținut = controlat”. Fără iluzia că un firewall în dulapul de comandă, un VPN și certificatul unei componente închid subiectul. Și fără presupunerea că securitatea cibernetică se încheie în momentul semnării procesului-verbal de recepție.

În acest articol, desfacem pe bucăți ce schimbă în mod real orientările CRA pentru producători, integratori și cei care modernizează mașini — fără a reduce întregul subiect la sloganul „schimbăm parola și adăugăm un checkbox de cybersecurity”.

1. Ca o mașină să nu intre sub incidența CRA, ar trebui să fie aproape numai pe contactoare

În multe proiecte, domeniul de aplicare al CRA este verificat printr-o singură întrebare:

Mașina va fi conectată la internet?

Nu va fi.

Deci subiectul este închis.

În schemă apar un PLC, un HMI, câteva acționări, intrări și ieșiri distribuite, o insulă de valve, un scanner de siguranță și un port pentru încărcarea programului. Controlerul comunică cu panoul prin PROFINET, schimbă cu acționările cuvinte de comandă și de stare, iar senzorii transmit date prin IO-Link.

Dar nu există un router cu cartelă SIM.

După cum se știe, datele devin date abia atunci când părăsesc hala de producție.

Numai că CRA nu întreabă dacă mașina are acces la internet.

Întreabă dacă destinația ei sau utilizarea previzibilă în mod rezonabil include o conexiune de date directă sau indirectă, logică ori fizică, cu un dispozitiv sau o rețea. Nu trebuie să fie o conexiune la cloud, la serverul producătorului sau la internetul public. Poate avea loc prin cablu, prin unde radio, printr-o interfață software sau ca parte a unui sistem mai mare.

Și acum întrebarea-cheie: ce anume, într-o mașină tipică, transmite efectiv date?

HMI-ul citește stările din PLC și scrie setările?

PLC-ul trimite către acționare un cuvânt de comandă și primește înapoi viteză, stare și cod de eroare?

Insula de intrări și ieșiri transmite imaginea procesului?

Senzorul IO-Link trimite valoarea măsurată, identificatorul dispozitivului și datele de diagnostic?

Safety PLC comunică cu modulele prin PROFIsafe?

Programul, configurația hardware sau firmware-ul sunt încărcate de pe laptopul de service?

Rețetele, rapoartele sau actualizările pot fi transferate prin USB?

Dacă răspunsul este măcar o dată „da”, atunci cel mai probabil avem de-a face cu o conexiune de date.

Și acest lucru nu este schimbat de faptul că:

• mașina funcționează într-o rețea locală,
• nu are adresă IP publică,
• portul Ethernet este folosit doar la punerea în funcțiune,
• laptopul este conectat exclusiv de service,
• comunicarea are loc numai în interiorul sistemului de comandă,
• clientul a promis că nu va conecta niciodată mașina la internet.

CRA acoperă nu doar utilizarea descrisă în instrucțiuni ca utilizare de bază, ci și utilizarea previzibilă în mod rezonabil. Prin urmare, un port de service nu încetează să transmită date doar pentru că pe schemă s-a adăugat lângă el mențiunea „SERVICE ONLY”.

Totuși, orientările Comisiei din 27 iulie 2026 introduc o distincție importantă.

Nu orice cablu și nu orice semnal electric reprezintă o conexiune de date.

Dacă semnalul servește exclusiv la pornirea, oprirea sau alimentarea unei anumite funcții și nu transmite informație codificată digital, simpla existență a două stări electrice nu este suficientă pentru a-l considera o conexiune de date.

Un buton care aplică tensiune pe bobina unui contactor nu devine o interfață digitală doar pentru că starea lui poate fi descrisă ca zero sau unu.

În mod similar, un limitator de cursă clasic conectat într-un circuit cu relee și contactoare poate doar să întrerupă sau să închidă circuitul. El nu transmite numărul dispozitivului, o valoare de proces, un cod de diagnostic, versiunea de firmware sau un telegram care conține mai multe informații.

Dar atunci când aceeași stare ajunge la un dispozitiv inteligent, este codificată, transmisă prin magistrală, asociată cu diagnostica și interpretată de receptor ca informație, situația arată deja diferit.

Așadar, limita nu trece între o mașină „online” și una „offline”.

Limita trece între un simplu semnal de comandă și schimbul de informații codificate digital.

De aceea, în practică, o mașină care ar trebui să rămână în afara CRA exclusiv din cauza lipsei unei conexiuni de date ar trebui să semene mai degrabă cu un sistem clasic cu butoane, limitatoare de cursă, relee și contactoare decât cu un proiect modern deschis în TIA Portal.

Desigur, aceasta nu este o excludere legală pentru contactoare.

Se poate construi o mașină simplă cu PLC care, după o analiză detaliată, să nu îndeplinească criteriul de încadrare în domeniu. De asemenea, se poate adăuga la un sistem cu contactoare un regulator digital, o interfață de service sau un modul de comunicație și să te afli exact de cealaltă parte a limitei.

Denumirea componentei nu decide cazul.

Decisiv este ce face efectiv produsul și cu ce schimbă date.

De aceea, înainte de a răspunde la întrebarea dacă o anumită mașină intră sub incidența CRA, trebuie stabilit:

• unde se află limita produsului evaluat,
• ce dispozitive și ce elemente software intră în componența lui,
• ce interfețe fizice și logice are,
• ce informații sunt transmise prin acestea,
• care conexiuni sunt directe și care au loc printr-un sistem mai mare,
• care dintre ele apar în timpul funcționării normale, al punerii în funcțiune, al diagnosticării, al actualizării sau al service-ului,
• ce moduri de utilizare sunt previzibile în mod rezonabil, chiar dacă producătorul ar prefera să nu le prevadă.

Până nu răspundem la aceste întrebări, nu știm dacă mașina rămâne în afara domeniului CRA.

Avem cel mult o formulare comodă:

„Mașina nu este conectată la internet”.

Numai că acesta este răspunsul la o întrebare pe care CRA nu o pune.

PROFINET nu este internetul. Pentru CRA, nici nu trebuie să fie.

2. Securitatea cibernetică nu se propagă prin PROFINET

În multe proiecte, tema conformității mașinii începe deja din etapa de achiziții.

PLC de la un producător consacrat.
HMI cu firmware actualizat.
Switch administrabil.
Router industrial cu VPN.
Acționări cu funcții de siguranță.
Safety PLC cu certificatul corespunzător.

Pentru fiecare dispozitiv: declarație de conformitate, instrucțiuni și câteva documente cu formulări precum „secure”, „encrypted” și „defence in depth”.

Pe schemă, totul arată profesionist.

Numai că încă nu se știe dacă mașina completă este sigură din punct de vedere cibernetic.

Pentru că securitatea cibernetică nu se „transferă” prin PROFINET.

Este puțin ca la încuietoarea unei uși:
poți avea o încuietoare foarte bună în fiecare cameră, certificată, testată, cu documentație impecabilă și hologramă „secure”, dar asta tot nu garantează siguranța dacă cineva a lăsat ușa de la intrare larg deschisă „pentru că așa a fost mai rapid la punerea în funcțiune”.

Și exact la fel este și aici: componentele pot fi exemplare, iar sistemul poate fi totuși… deschis în mod creativ.

PLC-ul nu „transmite” securitatea către HMI.
Firewall-ul nu „repară” logica aplicației.
Switch-ul nu „pune în ordine” accesul utilizatorilor.
Iar faptul că fiecare element are certificat nu înseamnă încă faptul că întreaga mașină nu este o singură vulnerabilitate uriașă, documentată cu amabilitate.

PROFINET transmite date.

Nu transmite răspundere.
Și, din păcate, nu transmite nici bun-simț.

CRA acoperă atât produsele complete, cât și componentele introduse pe piață separat. Asta înseamnă că un controler, un panou de operare sau un modul de comunicație pot fi evaluate separat. Dar producătorul mașinii trebuie în continuare să demonstreze că ansamblul funcționează în siguranță în configurația reală de la client — adică în acea versiune în care „sigur nu a mai schimbat nimeni nimic… nu-i așa?”.

Și aici apare cea mai frecventă greșeală.

Este exact același mecanism pe care îl cunoaștem de ani de zile din domeniul securității mașinilor.

Cortina are PL e.
Safety PLC are SIL 3.
Acționarea are STO.

Înseamnă asta că întreaga mașină este automat la același nivel?

E la fel ca în cazul în care fiecare element al unei schele respectă normele de siguranță, dar asta încă nu garantează că întreaga structură va fi stabilă.

Nu.

Pentru că tot trebuie verificat cum funcționează toate acestea împreună — adică acea etapă mai puțin populară de „gândire sistemică”, care, din păcate, nu are un buton „auto-certify”.

În securitatea cibernetică este exact la fel.

Poți avea componente „sigure”, dar în practică:

• operatorul vede și poate modifica mai multe date decât are nevoie, pentru că „așa a fost mai comod”,
• o singură parolă de service funcționează pe toate mașinile, pentru că „service-ul oricum știe ce face”,
• portul de service este accesibil „pentru orice eventualitate”, adică pentru orice eventualitate,
• accesul de la distanță acoperă întreaga rețea, pentru că cineva a spus cândva „doar pentru diagnosticare”,
• actualizările pot fi încărcate fără control, pentru că „niciodată nu s-a stricat nimic”,
• dispozitivele „au încredere unele în altele” fără limitări, pentru că încrederea este mai ieftină decât segmentarea,
• iar integrarea presupune că nimeni nu va face vreodată o greșeală, ceea ce este — după cum arată istoria — cea mai optimistă presupunere din inginerie.

Fiecare element, luat separat, poate fi corect.

Dar sistemul, ca întreg, poate construi din aceste elemente corecte ceva care funcționează… doar că nu neapărat așa cum s-a presupus.

Și aici este esențialul: riscul nu stă în dispozitive, ci în modul în care sunt conectate, configurate și în acel acces legendar „lăsat temporar”.

CRA cere producătorului mașinii mai mult decât să colecționeze declarații ca pe niște trofee. Cere să verifice dacă ceea ce a fost asamblat din componente rămâne sigur ca ansamblu — nu doar că „arată bine în tabelul de conformitate”.

În practică, asta înseamnă întrebări simple, de business:

• dacă fiecare utilizator are doar accesul de care are într-adevăr nevoie, nu și acces „poate va fi util cândva”,
• dacă accesul de la distanță este limitat la minimum sau, mai degrabă, la maximum de confort,
• dacă service-ul nu are „drepturi depline peste tot”, pentru că cineva a considerat că așa viața merge mai repede,
• dacă rețeaua nu este o singură suprafață comună, pentru că segmentarea „complică proiectul”,
• dacă actualizările sunt controlate sau mai degrabă „le încărcăm și sperăm să fie bine”,
• dacă se poate identifica rapid care mașini sunt expuse sau mai degrabă „verificăm după incident”,
• dacă defectarea unui singur element nu deschide întregul sistem, pentru că „așa a ieșit la integrare”.

Acestea nu sunt întrebări tehnice „pentru inginerii care se ocupă de lucrurile dificile”.

Sunt întrebări despre riscul de business: opriri de producție, costuri, răspundere și acel mic detaliu că producția totuși trebuie să funcționeze.

De aceea nu este suficient să spui:

„toate componentele sunt conforme”

Pentru că asta tot nu răspunde la întrebarea:

întreaga mașină este sigură în utilizarea reală sau doar în PowerPoint-ul din revizuirea de proiect?

Declarația furnizorului este importantă.

Dar se referă doar la un singur element — cel care tocmai a fost testat în condiții de laborator, nu în mediul „undeva în hală, cu VPN, USB și presiune de timp”.

Nu acoperă modul în care a fost utilizat.
Nu acoperă configurarea.
Nu acoperă integrarea.
Nu acoperă deciziile luate „în grabă, la punerea în funcțiune, pentru că clientul aștepta”.
Nu acoperă ce se întâmplă după ani de exploatare, când nimeni nu-și mai amintește de ce ceva a fost „deschis temporar”.

De aceea, evaluarea nu se poate opri la lista de dispozitive.

Trebuie privit sistemul ca întreg:

• cine are acces și de ce (nu „pentru că a avut mereu”),
• ce este cu adevărat necesar și ce a fost doar „lăsat, pentru că nu deranja”,
• unde pot ieși datele de sub control, pentru că cineva a considerat că „e doar diagnosticare”,
• ce se întâmplă dacă cineva folosește un acces legitim într-un mod nelegitim (adică exact așa cum funcționează atacurile),
• cât de repede se poate reacționa când apare o problemă, nu „după revizia trimestrială”.

Până când nu există răspunsuri la aceste întrebări, avem doar un set de componente foarte solide.

Nu avem încă o mașină sigură.

Conformitatea componentelor nu creează automat conformitatea sistemului. Conformitatea mașinii trebuie proiectată, verificată și — cel mai greu — menținută, în ciuda tentației de a „nu mai atinge nimic, că funcționează”.

3. Nu adăuga atacul cibernetic pe lista pericolelor. Leagă cele două analize în locul potrivit

Pe piața mașinilor, o analiză formală a riscului de securitate cibernetică este încă mai degrabă o excepție decât un element standard al proiectului.

De cele mai multe ori există un router industrial.

Există VPN.

Există o parolă pentru PLC.

Uneori există un switch gestionabil, pe care ulterior nu îl mai gestionează nimeni.

În varianta mai ambițioasă, producătorul primește de la furnizor o prezentare despre „defence in depth” și consideră că tocmai a încheiat analiza riscului de securitate cibernetică pentru întreaga mașină.

Nu a încheiat-o.

A cumpărat câteva măsuri tehnice.

Asta nu este încă o analiză.

Prin urmare, nu are sens să descriem problema ca și cum în fiecare proiect s-ar realiza două evaluări profesioniste — una conform ISO 12100, cealaltă privind securitatea cibernetică — care doar din întâmplare nu au fost corelate între ele.

De cele mai multe ori se întocmește una singură.

Evaluarea riscurilor mașinii.

Iar analiza de securitate cibernetică a produsului nu se mai face deloc.

Evaluarea riscurilor mașinii conform ISO 12100 nu înseamnă să treci într-un tabel:

defecțiunea senzorului → mișcare neașteptată → strivire.

Acesta poate fi un fragment dintr-un scenariu concret, dar nu punctul de plecare.

Mai întâi trebuie definite limitele mașinii.

Care este destinația ei?

Care sunt fazele ciclului de viață?

Cine o va utiliza?

Ce sarcini vor fi efectuate în timpul transportului, montajului, punerii în funcțiune, producției, reglajului, curățării, eliminării blocajelor, mentenanței, diagnosticării și demontării?

În ce moduri poate funcționa mașina?

Unde se află omul în timpul fiecăreia dintre aceste operații?

Care părți ale mașinii rămân atunci sub tensiune, sub presiune, sub sarcină sau în mișcare?

Ce utilizare nu este conformă cu instrucțiunile, dar rămâne totuși în mod rezonabil previzibilă?

Abia apoi, pentru o anumită sarcină sau operație, se identifică, printre altele:

• sursa pericolului,
• tipul pericolului,
• zona periculoasă,
• persoana expusă,
• situația periculoasă,
• evenimentul periculos, dacă apare în scenariul respectiv,
• consecințele posibile și tipul vătămării.

Așa arată analiza riscurilor conform SR EN ISO 12100 pentru o mașină.

Nu pornim de la componentă.

Pornim de la omul care execută o anumită sarcină la o mașină aflată într-o anumită stare. ISO 12100 stabilește exact această metodologie de identificare a pericolelor, precum și de estimare și evaluare a riscului în fazele relevante ale ciclului de viață al mașinii.

Să luăm un exemplu simplu.

Operatorul îndepărtează o piesă blocată din interiorul unei celule de paletizare.

Avem deci:

Sarcina: eliminarea blocajului.

Faza de utilizare: exploatare, intervenție după oprirea procesului.

Mod de funcționare: manual sau service.

Persoana expusă: operatorul sau lucrătorul de mentenanță.

Zona periculoasă: interiorul celulei, în special spațiul dintre dispozitivul de prindere, piesă și structura mașinii.

Sursa pericolului: energia mecanică a robotului, a axei liniare sau a dispozitivului pneumatic de prindere.

Situația periculoasă: omul se află în zonă, în timp ce executarea unei mișcări este încă posibilă.

Eveniment periculos: mișcare neașteptată a axei, închiderea dispozitivului de prindere sau eliberarea energiei acumulate.

Consecință posibilă: lovire, strivire, fractură sau amputare.

Abia acum se poate evalua riscul și se pot stabili măsurile de reducere a acestuia.

Poate fi necesară interblocarea apărătorii.

Poate fi necesară o oprire sigură.

Poate fi necesară prevenirea pornirii neașteptate.

Poate că trebuie evacuată energia pneumatică.

Poate că mișcarea în modul manual trebuie permisă exclusiv cu un dispozitiv de validare și la o viteză limitată în siguranță.

Aceasta este în continuare o evaluare clasică a riscurilor mașinii.

Unde intervine securitatea cibernetică?

Nu ca o poziție nouă alături de pericolul mecanic, electric și termic.

„Hackerul” nu este sursa unui pericol mecanic

Adăugarea în tabelul ISO 12100 a poziției:

Pericol: atac cibernetic

aduce prea puțin.

Un atac cibernetic nu este un arbore în rotație, o muchie ascuțită, o temperatură ridicată sau energie pneumatică.

Nu este nici o zonă periculoasă separată.

Operatorul nu este strivit de o vulnerabilitate CVE.

Este strivit de un element al mașinii care a executat o mișcare atunci când omul se afla într-un loc nepotrivit.

În schimb, un atac cibernetic poate modifica starea sistemului de comandă, datele, programul, configurația sau modul de funcționare al unei măsuri de protecție.

Prin urmare, el poate deveni:

• cauza unui eveniment periculos,
• o cale suplimentară care conduce la o situație periculoasă,
• cauza pierderii eficacității unei măsuri de reducere a riscului,
• sau o modalitate de a ocoli ipotezele adoptate la proiectarea funcțiilor de siguranță.

Acesta este punctul real de intersecție.

Nu lista pericolelor.

Comportamentul mașinii.

Analiza de securitate cibernetică ar trebui elaborată separat

Pentru o mașină sau un sistem de automatizare, analiza de securitate cibernetică va avea o structură diferită de evaluarea riscurilor conform ISO 12100.

Cea mai firească structură pentru un sistem de automatizare industrială este oferită de IEC 62443-3-2.

Standardul cere, printre altele:

• definirea sistemului supus analizei, adică SUC,
• împărțirea sistemului în zone și canale de comunicație,
• evaluarea riscului pentru fiecare zonă și canal,
• stabilirea nivelurilor-țintă de securitate SL-T,
• documentarea cerințelor de securitate.

Acesta este un punct de plecare complet diferit față de ISO 12100.

În IEC 62443 întrebăm, printre altele:

Ce anume intră exact în sistemul analizat?

Ce active trebuie protejate?

Ce echipamente, aplicații și interfețe se află în sistem?

Care elemente ar trebui să aparțină aceleiași zone?

Cum se desfășoară comunicația între zone?

Cine poate obține acces?

Din ce loc?

Prin ce interfață?

Ce vulnerabilități pot fi exploatate?

Ce date, funcții sau componente pot fi modificate?

Pe ce traseu poate ajunge un atacator de la routerul de service la PLC, HMI, acționare sau stația de inginerie?

Ce consecințe va avea pierderea confidențialității, integrității sau disponibilității?

Ce măsuri de protecție sunt necesare?

Pentru procesul de dezvoltare sigură a produsului și pentru cerințele aplicabile componentelor în sine, vor fi relevante și alte părți ale seriei, în special IEC 62443-4-1 și IEC 62443-4-2. În schimb, IEC 62443-3-3 structurează cerințele tehnice de securitate la nivel de sistem.

CRA nu impune astăzi producătorului să scrie pe coperta analizei „realizat în conformitate cu IEC 62443”.

De asemenea, IEC 62443 nu înlocuiește demonstrarea conformității cu cerințele CRA.

Pentru un sistem industrial de automatizare, este însă un reper mult mai logic decât încercarea de a adăuga câteva scenarii de hacking într-un tabel ISO 12100.

Pentru că cele două metodologii răspund la întrebări diferite.

ISO 12100:

În timpul cărei sarcini, unde, din cauza cărei surse și ca urmare a cărui eveniment poate suferi o persoană un prejudiciu?

IEC 62443:

Cine, pe ce cale și exploatând ce vulnerabilitate poate influența sistemul, datele sau funcțiile acestuia?

Abia apoi trebuie verificat dacă răspunsul rezultat din a doua analiză modifică scenariul din prima.

Același scenariu, două analize diferite

Să revenim la operatorul care îndepărtează o piesă blocată.

Analiza ISO 12100 a arătat că persoana intră într-o zonă în care poate fi strivită de mișcarea robotului sau a dispozitivului de prindere.

Măsura de reducere a riscului este un protector interblocat, funcția de oprire sigură și un reset local amplasat în afara zonei de pericol.

Acum efectuăm analiza de securitate cibernetică a sistemului.

Identificăm:

• routerul utilizat pentru service la distanță,
• contul de service,
• laptopul de inginerie,
• HMI,
• PLC-ul standard,
• PLC-ul de siguranță,
• acționările,
• interfața de programare,
• rețeaua PROFINET și comunicația PROFIsafe,
• mecanismele de încărcare a programului și a configurației.

Analizăm următorul scenariu:

Compromiterea contului de service permite accesul de la distanță la PLC-ul standard și trimiterea unei comenzi de mișcare în timp ce o persoană se află în celulă.

Conduce acest scenariu la un eveniment periculos?

Nu se poate răspunde doar pe baza faptului că PLC-ul a fost compromis.

Trebuie verificată arhitectura funcțiilor de siguranță.

Dacă deschiderea protectorului este monitorizată de PLC-ul de siguranță, funcția decuplează în siguranță cuplul acționărilor, resetul este exclusiv local, iar PLC-ul standard nu poate restabili mișcarea independent de starea funcției de siguranță, compromiterea controlerului standard poate opri producția sau poate afecta procesul.

Dar nu ar trebui să provoace mișcare cu protectorul deschis.

În acest caz, analiza cibernetică evidențiază atacul.

Evaluarea riscului mașinii evidențiază pericolul mecanic.

Totuși, o funcție de siguranță proiectată corect întrerupe legătura dintre ele.

Iar acum a doua variantă.

Modul de service este selectat dintr-un HMI obișnuit.

Valoarea vitezei limitate provine din PLC-ul standard.

Tehnicianul de service de la distanță poate efectua resetul.

Același cont de inginerie permite modificarea programului standard și a configurației de siguranță.

Copia programului de siguranță nu este asociată cu o versiune concretă a mașinii.

Nimeni nu verifică suma de control după intervenție.

Parametrii acționării pot fi modificați de la distanță.

În această arhitectură, compromiterea contului nu mai înseamnă doar pierderea confidențialității sau un scurt timp de nefuncționare.

Poate modifica premisele pe care se baza reducerea riscului.

Poate duce la:

• selectarea unui mod necorespunzător,
• modificarea parametrului de mișcare sigură,
• un reset neautorizat,
• încărcarea unei configurații neaprobate,
• sau slăbirea funcției care trebuia să prevină pornirea neașteptată.

Și atunci scenariul cibernetic trebuie corelat cu scenariul concret de siguranță al mașinii:

sarcina de eliminare a blocajului → persoană în zona de pericol → modificare neautorizată a sistemului de comandă sau a funcției de protecție → mișcare neașteptată → strivire.

Sursa pericolului nu s-a schimbat.

Rămâne energia mecanică a mașinii.

Zona de pericol nu s-a schimbat.

Se află în continuare în interiorul celulei.

Nici consecința posibilă nu s-a schimbat.

Rămâne vătămarea operatorului.

S-a schimbat traseul care duce la evenimentul periculos.

Nu orice vulnerabilitate ajunge în ISO 12100

Această distincție este la fel de importantă.

Să presupunem că o vulnerabilitate din HMI permite citirea datelor istorice de producție.

Acest lucru poate fi o problemă importantă din perspectiva CRA.

Poate încălca confidențialitatea datelor.

Poate necesita o actualizare, o evaluare a impactului, măsuri față de utilizatori și, în anumite circumstanțe, și raportare.

Dar dacă nu influențează comportamentul mașinii, nu modifică măsura de protecție și nu poate duce la o situație periculoasă, nu are sens să fie forțată în evaluarea riscului conform ISO 12100.

În mod similar, un atac care provoacă exclusiv indisponibilitatea rapoartelor de producție poate însemna o problemă de business și o problemă de conformitate cu CRA.

Totuși, nu trebuie neapărat să genereze un risc pentru operator.

Pe de altă parte, o posibilitate aparent inofensivă de a modifica o singură valoare setată poate avea o importanță redusă pentru confidențialitatea datelor, dar o importanță uriașă pentru siguranța fizică.

De exemplu, atunci când valoarea respectivă stabilește:

• viteza maximă a axei,
• forța de apăsare,
• temperatura procesului,
• presiunea,
• poziția de oprire,
• timpul de deschidere a supapei,
• sau limita admisă în timpul funcționării cu protecția deschisă.

Așadar, nu clasificăm o amenințare cibernetică după cât de tehnic sună.

Ne uităm la ce poate face în realitate cu mașina.

Regulamentul privind mașinile impune această punte

Această legătură nu este doar o bună practică inginerească.

Punctul 1.2.1 din anexa III la regulamentul privind mașinile cere ca sistemele de comandă să fie proiectate și realizate astfel încât să prevină apariția situațiilor periculoase, inclusiv ca urmare a unor tentative rău intenționate ale unor terți, previzibile în mod rezonabil.

La rândul său, CRA indică faptul că cerințele sale esențiale de securitate cibernetică pot sprijini demonstrarea conformității, printre altele, cu cerințele 1.1.9 și 1.2.1 din regulamentul privind mașinile.

Dar acest lucru nu se întâmplă automat.

Producătorul trebuie să demonstreze această legătură pe baza evaluării riscurilor. Evaluarea conformității potrivit CRA și evaluarea conformității potrivit regulamentului privind mașinile rămân în continuare procese distincte.

Cu alte cuvinte, nu este suficient să pregătești:

• o evaluare a riscurilor conform ISO 12100,
• o analiză IEC 62443,
• două rapoarte separate,
• și să speri că asemănarea numerelor standardelor va crea între ele o urmă de audit.

Este necesară o corelare.

Pentru fiecare scenariu cibernetic relevant trebuie stabilit:

1. ce element sau ce funcție poate fi preluată ori modificată,
2. ce comportament al mașinii poate provoca acest lucru,
3. dacă acel comportament conduce la o situație periculoasă sau la un eveniment periculos,
4. ce sarcină și ce zonă de pericol sunt vizate,
5. ce consecință posibilă a fost indicată în evaluarea ISO 12100,
6. ce măsură de reducere a riscului ar trebui să întrerupă evoluția scenariului,
7. dacă această măsură rămâne eficace după compromiterea elementului atacat.

Ultimul punct este cel mai important.

Pentru că, dacă atacul și protecția depind de:

• același controler,
• același cont,
• aceeași rețea,
• aceeași stație de inginerie,
• sau același program,

atunci este posibil să nu avem două straturi independente de protecție.

Avem un singur strat descris în două documente.

Așadar, nu avem nevoie de un singur tabel uriaș intitulat:

„evaluarea riscurilor safety & cybersecurity”.

Avem nevoie de două analize corecte, realizate prin metode adecvate, și de un punct de interfață controlat între ele.

ISO 12100 trebuie să descrie persoana, sarcina, sursa pericolului, zona, situația periculoasă, evenimentul periculos și vătămarea posibilă.

IEC 62443 trebuie să ajute la descrierea sistemului, a zonelor sale, a canalelor de comunicație, a activelor, a amenințărilor, a vulnerabilităților, a căilor de atac și a măsurilor de protecție necesare.

Iar producătorul trebuie să demonstreze dacă scenariul din a doua analiză poate declanșa scenariul din prima sau poate anula eficacitatea măsurii care trebuia să îl oprească.

Un atac cibernetic nu trebuie să creeze un pericol nou. Este suficient să deschidă o cale nouă către un accident vechi.

4. Un pentest înainte de FAT este o fotografie. CRA cere un film

În multe proiecte, securitatea cibernetică apare cu două săptămâni înainte de FAT.

Se comandă un pentest.

Se întocmește un raport.

Vulnerabilitățile critice sunt remediate, cele medii sunt acceptate, iar documentul ajunge în dosarul proiectului.

Mașina este securizată cibernetic.

Până marțea viitoare.

Un pentest poate fi un element de verificare foarte valoros. Totuși, el arată starea unei versiuni concrete a produsului, într-o configurație concretă și pe baza unor scenarii de testare determinate.

Nu răspunde la întrebarea ce va face producătorul mai departe.

Iar CRA privește întregul ciclu de viață al produsului. Evaluarea riscului de securitate cibernetică trebuie să influențeze planificarea, proiectarea, dezvoltarea, producția, livrarea și mentenanța produsului. După introducerea pe piață, producătorul trebuie să gestioneze vulnerabilitățile pe durata perioadei de suport declarate.

Să revenim la mașina de ambalat legume.

Mașina a trecut FAT.

Pentestul nu a evidențiat vulnerabilități critice.

Opt luni mai târziu, producătorul routerului de service publică o informație despre o vulnerabilitate care permite preluarea dispozitivului.

Și de aici începe munca adevărată.

Care dintre mașinile livrate au acest model de router?

Ce versiune de firmware a fost instalată pe fiecare exemplar?

Este activ accesul de la distanță?

Poate fi exploatată vulnerabilitatea în configurația reală?

Preluarea routerului oferă acces exclusiv la diagnosticare sau și la HMI, PLC, acționări și safety PLC?

Este posibilă doar citirea datelor sau și modificarea programului ori a parametrilor?

Poate atacul să influențeze funcția de siguranță?

A pus furnizorul la dispoziție un patch?

Va modifica actualizarea routerului certificatele, regulile de comunicație sau modul de stabilire a tunelului?

După actualizare, trebuie verificate din nou service-ul la distanță, comunicația și o parte dintre funcțiile de siguranță?

Ce clienți trebuie informați?

Și această situație îndeplinește criteriile pentru raportarea unei vulnerabilități exploatate activ sau a unui incident grav?

Raportul de pentest realizat înainte de FAT nu va răspunde la niciuna dintre aceste întrebări.

El descrie o mașină care nu mai există.

Pentru că, de la momentul testării, s-au schimbat versiunile de software, configurațiile, mediul utilizatorului și cunoștințele despre vulnerabilități.

De aceea, producătorul are nevoie nu doar de un test, ci de un proces:

• de identificare a versiunilor de hardware, firmware și software din fiecare exemplar livrat,
• de monitorizare a informațiilor despre vulnerabilități,
• de evaluare a modului în care acestea pot fi exploatate în arhitectura reală,
• de verificare a efectelor posibile asupra procesului și asupra siguranței mașinii,
• de pregătire și testare a actualizărilor,
• de informare a utilizatorilor,
• de documentare a deciziilor luate,
• de gestionare a raportărilor necesare.

Începând cu 11 septembrie 2026, producătorii au obligația de a raporta vulnerabilitățile exploatate activ și incidentele grave care afectează securitatea produselor cu elemente digitale. Avertizarea preliminară trebuie transmisă în termen de 24 de ore, iar raportarea completă în termen de 72 de ore.

Asta înseamnă că, după detectarea problemei, nu va mai fi timp să înceapă căutările:

„Cine a produs, de fapt, acest router și unde avem lista mașinilor în care l-am montat?”

IEC 62443-4-1 arată foarte bine diferența dintre securizarea punctuală a unui produs și un ciclu sigur de dezvoltare a acestuia. Acoperă nu doar proiectarea și verificarea, ci și gestionarea defectelor, a corecțiilor și a sfârșitului de viață al produsului.

Prin urmare, FAT poate închide etapa de proiect.

Nu închide ciclul de viață al produsului.

Nu închide perioada de suport.

Nu pune capăt monitorizării vulnerabilităților.

Și nu înseamnă că configurația din ziua recepției rămâne înghețată pentru următorii cincisprezece ani.

Mașina poate ambala legume pentru supermarketuri o perioadă îndelungată.

Însă producătorul nu poate ambala și securitatea ei cibernetică odată cu manualul, să o sigileze în folie și să considere că a fost livrată o dată pentru totdeauna.

Pentestul poate închide un punct de pe lista FAT. CRA deschide un proces care durează până la sfârșitul perioadei de suport a produsului.