CRA za proizvođače strojeva nakon smjernica Komisije od 27. srpnja 2026. Što je doista potrebno provesti?

Godinama se kibernetička sigurnost stroja mogla svesti na tri koraka: PLC poznatog proizvođača, VPN „jer se tako radi” i klasično „kupac će osigurati mrežu”. A ako bi netko još dodao vatrozid u ormaru, tema se često smatrala zatvorenom — barem dok netko nije pokušao provjeriti što se događa nakon stvarnog napada, a ne na prezentaciji.

No kibernetička sigurnost ne teče kroz PROFINET. Komponente mogu imati certifikate, izjave i „secure by design” u marketinškoj brošuri, ali stroj kao cjelina i dalje može biti predvidljiv na način koji nema nikakve veze sa sigurnošću. Kao što sigurnosni relej sam po sebi ne čini sustav sigurnim ako ga logika upravljanja dopušta zaobići, tako ni „siguran” HMI ne rješava problem arhitekture, integracije, ovlasti, ažuriranja i onoga što se događa kada netko prestane tražiti dopuštenje.

CRA (Cyber Resilience Act, Uredba Europskog parlamenta i Vijeća (EU) 2024/2847) nije dodatak za IT. To je proizvodna regulativa koja ulazi u životni ciklus stroja bez pitanja traži li to odjel automatizacije. Obuhvaća projekt upravljanja, analizu rizika, opskrbni lanac, konfiguraciju, ažuriranja, kao i održavanje proizvoda dugo nakon što je FAT potpisan i stroj napustio halu. I ne, argument „ne izlažemo ga internetu” ne zatvara temu. U praksi su dovoljni servisni laptop, USB memorija, udaljena dijagnostika „nakratko” ili integracija sa sustavom postrojenja da granica između izolacije i izloženosti prestane postojati.

Smjernice Komisije od 27. srpnja 2026. nisu promijenile samu uredbu, ali su učinkovito suzile prostor za tumačenje koji je ranije dopuštao da se kibernetička sigurnost tretira kao opcionalni sloj. Dodatno su pojašnjeni, među ostalim, granica proizvoda, uloga udaljene obrade, odgovornost za izmjene nakon isporuke te činjenica da „to više nije naš problem nakon FAT-a” više nije sigurna pretpostavka.

Najvažnija promjena ipak je dublja: kibernetički napad prestaje biti isključivo IT događaj i postaje scenarij koji utječe na funkcionalnu sigurnost stroja. Ako neovlaštena izmjena programa može uzrokovati gibanje osi, zaobilaženje blokade, promjenu parametara procesa ili gubitak sigurnosne funkcije, tada više ne govorimo o „mrežnom incidentu”. Govorimo o potencijalno nekontroliranom ponašanju stroja — neovisno o tome je li uzrok bila pogreška u konfiguraciji, ranjivost softvera ili namjerna intervencija.

U tom kontekstu jednokratni pentest prije FAT-a prestaje biti dokaz usklađenosti i postaje tek snimka stanja sustava u određenom trenutku. CRA zahtijeva kontinuiran pristup: od projektiranja, preko proizvodnje i puštanja u rad, pa sve do ažuriranja, upravljanja ranjivostima, odgovora na incidente i održavanja tijekom deklariranog razdoblja podrške.

U praksi to znači odmak od razmišljanja „odrađeno = sigurno” prema „održavano = pod kontrolom”. Bez iluzije da vatrozid u ormaru, VPN i certifikat komponente zatvaraju temu. I bez pretpostavke da kibernetička sigurnost završava u trenutku potpisivanja zapisnika o primopredaji.

U ovom članku raščlanjujemo što smjernice CRA stvarno mijenjaju za proizvođače, integratore i modernizatore strojeva — bez svođenja cijele teme na poruku „promijenimo lozinku i dodajmo checkbox cybersecurity”.

1. Da stroj ne bi ulazio u CRA, morao bi biti gotovo samo na sklopnicima

U mnogim se projektima opseg CRA provjerava jednim pitanjem:

Hoće li stroj biti spojen na internet?

Neće.

Znači, tema je zatvorena.

Na shemi su PLC, HMI, nekoliko pogona, distribuirani ulazi i izlazi, ventilni otok, sigurnosni skener te priključak za učitavanje programa. Upravljač komunicira s panelom preko PROFINET-a, s pogonima razmjenjuje upravljačke i statusne riječi, a senzori prenose podatke putem IO-Linka.

Ali nema rutera sa SIM karticom.

Kao što je poznato, podaci postaju podaci tek kada napuste proizvodnu halu.

Samo što CRA ne pita ima li stroj pristup internetu.

Pita obuhvaća li njegova namjena ili razumno predvidiva uporaba izravnu ili neizravnu, logičku ili fizičku podatkovnu vezu s uređajem ili mrežom. To ne mora biti veza s oblakom, poslužiteljem proizvođača ni javnim internetom. Može se ostvarivati kabelom, radiovalovima, programskim sučeljem ili kao dio većeg sustava.

I sada ključno pitanje: što u tipičnom stroju zapravo prenosi podatke?

Očitava li HMI stanja iz PLC-a i upisuje li zadane vrijednosti?

Šalje li PLC pogonu upravljačku riječ, a zauzvrat prima brzinu, status i kod pogreške?

Prenosi li otok ulaza i izlaza sliku procesa?

Šalje li IO-Link senzor mjernu vrijednost, identifikator uređaja i dijagnostičke podatke?

Komunicira li safety PLC s modulima putem PROFIsafe-a?

Učitavaju li se program, hardverska konfiguracija ili firmware sa servisnog laptopa?

Mogu li se recepture, izvještaji ili ažuriranja prenijeti putem USB-a?

Ako odgovor makar jednom glasi „da”, vrlo je vjerojatno da imamo podatkovnu vezu.

I to ne mijenja činjenica da:

• stroj radi u lokalnoj mreži,
• nema javnu IP adresu,
• Ethernet priključak koristi se samo tijekom puštanja u rad,
• prijenosno računalo priključuje isključivo servis,
• komunikacija se odvija samo unutar upravljačkog sustava,
• kupac je obećao da stroj nikada neće spojiti na internet.

CRA ne obuhvaća samo uporabu koja je u uputama opisana kao osnovna, nego i razumno predvidivu uporabu. Servisni priključak zato ne prestaje prenositi podatke samo zato što je na shemi uz njega dopisano „SERVICE ONLY”.

Smjernice Komisije od 27. srpnja 2026. ipak uvode važnu razliku.

Nije svaki vodič i nije svaki električni signal podatkovna veza.

Ako signal služi isključivo za uključivanje, isključivanje ili napajanje određene funkcije i ne prenosi digitalno kodiranu informaciju, sama prisutnost dvaju električnih stanja još nije dovoljna da bi ga se smatralo podatkovnom vezom.

Tipkalo koje dovodi napon na zavojnicu kontaktora ne postaje digitalno sučelje samo zato što se njegovo stanje može opisati kao nula ili jedan.

Slično tome, klasična granična sklopka uključena u relejno-kontaktorski krug može samo prekinuti ili zatvoriti strujni krug. Ne prenosi broj uređaja, procesnu vrijednost, dijagnostički kod, verziju firmwarea ni telegram koji sadrži više informacija.

Ali kada to isto stanje stigne do inteligentnog uređaja, bude kodirano, poslano preko sabirnice, povezano s dijagnostikom i protumačeno od strane prijamnika kao informacija, situacija već izgleda drukčije.

Granica, dakle, ne ide između stroja „online” i „offline”.

Ona ide između običnog upravljačkog signala i razmjene digitalno kodirane informacije.

Zato bi u praksi stroj koji bi ostao izvan područja primjene CRA isključivo zbog nepostojanja podatkovne veze morao više nalikovati klasičnom sklopu s tipkalima, graničnim sklopkama, relejima i kontaktorima nego suvremenom projektu koji se otvara u TIA Portal.

To, naravno, nije zakonsko izuzeće za kontaktore.

Moguće je izraditi jednostavan stroj s PLC-om koji nakon detaljne analize neće ispuniti kriterij područja primjene. Jednako tako, u kontaktorski sklop može se dodati digitalni regulator, servisno sučelje ili komunikacijski modul i naći se točno s druge strane granice.

Naziv komponente ne odlučuje o tome.

Odlučuje ono što proizvod stvarno radi i s čime razmjenjuje podatke.

Zato prije odgovora na pitanje podliježe li određeni stroj CRA-u, treba utvrditi:

• gdje prolazi granica proizvoda koji se ocjenjuje,
• koji uređaji i elementi softvera ulaze u njegov sastav,
• koja fizička i logička sučelja ima,
• koje se informacije preko njih prenose,
• koje su veze izravne, a koje se odvijaju preko većeg sustava,
• koje od njih postoje tijekom normalnog rada, puštanja u rad, dijagnostike, ažuriranja ili servisa,
• koji su načini uporabe razumno predvidivi, čak i ako ih proizvođač radije ne bi predviđao.

Dok ne odgovorimo na ta pitanja, ne znamo ostaje li stroj izvan područja primjene CRA-a.

U najboljem slučaju imamo samo zgodnu rečenicu:

„Stroj nije spojen na internet”.

Samo što je to odgovor na pitanje koje CRA ne postavlja.

PROFINET nije internet. Za CRA to uopće ne mora biti.

2. Kibernetička sigurnost ne prenosi se preko PROFINET-a

U mnogim projektima tema usklađenosti stroja počinje već u fazi nabave.

PLC od renomiranog proizvođača.
HMI s ažurnim firmwareom.
Upravljivi switch.
Industrijski usmjerivač s VPN-om.
Pogoni sa sigurnosnim funkcijama.
Safety PLC s odgovarajućim certifikatom.

Uz svaki uređaj dolaze izjava o sukladnosti, upute i nekoliko dokumenata s izrazima „secure”, „encrypted” i „defence in depth”.

Na shemi sve izgleda profesionalno.

Samo što se i dalje ne zna je li cjeloviti stroj kibernetički siguran.

Jer se kibernetička sigurnost ne „prenosi” preko PROFINET-a.

To je pomalo kao s bravom na vratima:
možete imati vrlo dobru bravu u svakoj prostoriji, certificiranu, ispitanu, s odličnom dokumentacijom i hologramom „secure”, ali to i dalje ne jamči sigurnost ako je netko ostavio ulazna vrata širom otvorena „jer je tako bilo brže tijekom puštanja u rad”.

I ovdje je potpuno isto: komponente mogu biti uzorne, a sustav svejedno može biti… kreativno otvoren.

PLC ne „prenosi” sigurnost na HMI.
Vatrozid ne „popravlja” logiku aplikacije.
Switch ne „uređuje” pristup korisnika.
A činjenica da svaki element ima certifikat još ne znači da cijeli stroj nije jedna velika, pristojno dokumentirana ranjivost.

PROFINET prenosi podatke.

Ne prenosi odgovornost.
I nažalost ne prenosi ni zdrav razum.

CRA obuhvaća i cjelovite proizvode i komponente koje se zasebno stavljaju na tržište. To znači da se upravljač, operatorski panel ili komunikacijski modul mogu ocjenjivati odvojeno. Ali proizvođač stroja i dalje mora dokazati da cjelina radi sigurno u stvarnoj konfiguraciji kod kupca — dakle u onoj verziji u kojoj „sigurno više nitko ništa nije mijenjao… zar ne?”.

I tu se pojavljuje najčešća pogreška.

To je potpuno isti mehanizam koji godinama poznajemo iz sigurnosti strojeva.

Zavjesa ima PL e.
Safety PLC ima SIL 3.
Pogon ima STO.

Znači li to da je cijeli stroj automatski na toj razini?

Kao što ni činjenica da svaki element skele ispunjava sigurnosne norme sama po sebi ne jamči da će cijela konstrukcija biti stabilna.

Ne.

Zato što i dalje treba provjeriti kako sve to radi zajedno — odnosno proći onu ne baš popularnu fazu „sistemskog razmišljanja”, koja, nažalost, nema gumb „auto-certify”.

U kibernetičkoj sigurnosti potpuno je isto.

Možete imati „sigurne” komponente, ali u praksi:

• operater vidi i može mijenjati više podataka nego što mu stvarno treba, jer je „tako bilo praktičnije”,
• jedna servisna lozinka radi na svim strojevima, jer „servis ionako zna što radi”,
• servisni port dostupan je „za svaki slučaj”, odnosno za baš svaki slučaj,
• udaljeni pristup obuhvaća cijelu mrežu, jer je netko jednom rekao „pa to je samo dijagnostika”,
• ažuriranja se mogu učitati bez kontrole, jer „nikad se ništa nije pokvarilo”,
• uređaji si „vjeruju” bez ikakvih ograničenja, jer je povjerenje jeftinije od segmentacije,
• a integracija polazi od toga da nitko nikada neće pogriješiti, što je — kako povijest pokazuje — najoptimističnija pretpostavka u inženjerstvu.

Svaka komponenta zasebno može biti ispravna.

Ali sustav kao cjelina od tih ispravnih komponenti može sastaviti nešto što radi… samo ne nužno onako kako je bilo zamišljeno.

I to je ključno: rizik nije u uređajima, nego u njihovim međusobnim vezama, konfiguraciji i legendarnom pristupu „privremeno ostavljenom”.

CRA od proizvođača stroja traži nešto više od skupljanja izjava kao trofeja. Traži provjeru je li ono što je sastavljeno od komponenti i dalje sigurno kao cjelina — a ne samo da „lijepo izgleda u tablici usklađenosti”.

U praksi to znači jednostavna, poslovna pitanja:

• ima li svaki korisnik samo onaj pristup koji mu je doista potreban, a ne „jer bi jednog dana moglo zatrebati”,
• je li udaljeni pristup ograničen na minimum ili na maksimum komfora,
• nema li servis „puna prava svugdje” samo zato što je netko procijenio da to ubrzava stvari,
• nije li mreža jedna zajednička površina samo zato što segmentacija „komplicira projekt”,
• jesu li ažuriranja pod kontrolom ili se zapravo „ubacuju pa se molimo”,
• može li se brzo utvrditi koji su strojevi izloženi ili ćemo „provjeriti nakon incidenta”,
• otvara li kvar jednog elementa cijeli sustav zato što je „tako ispalo u integraciji”.

To nisu tehnička pitanja „za inženjere koji se bave teškim stvarima”.

To su pitanja poslovnog rizika: zastoji, troškovi, odgovornost i ona sitnica da proizvodnja ipak mora raditi.

Zato nije dovoljno reći:

„sve komponente su usklađene”

Jer to i dalje ne odgovara na pitanje:

je li cijeli stroj siguran u stvarnoj uporabi ili samo u PowerPointu s pregleda projekta?

Izjava dobavljača jest važna.

Ali odnosi se samo na jedan element — onaj koji je upravo bio ispitivan u laboratorijskim uvjetima, a ne u okruženju „negdje u hali, s VPN-om, USB-om i vremenskim pritiskom”.

Ne obuhvaća način na koji je upotrijebljen.
Ne obuhvaća konfiguraciju.
Ne obuhvaća integraciju.
Ne obuhvaća odluke donesene „na brzinu tijekom puštanja u rad, jer je kupac čekao”.
Ne obuhvaća ono što se događa nakon godina rada, kada se više nitko ne sjeća zašto je nešto bilo „privremeno otvoreno”.

Zato procjena ne može završiti na popisu uređaja.

Treba sagledati sustav kao cjelinu:

• tko ima pristup i zašto (a ne „jer ga je oduvijek imao”),
• što je stvarno potrebno, a što je samo „ostavljeno jer nije smetalo”,
• gdje podaci mogu izaći izvan kontrole jer je netko procijenio da je „to samo dijagnostika”,
• što će se dogoditi ako netko zakonit pristup iskoristi na nezakonit način (dakle upravo onako kako to rade napadi),
• koliko se brzo može reagirati kada se pojavi problem, a ne tek „nakon kvartalnog pregleda”.

Dok nema odgovora na ta pitanja, imamo samo skup vrlo urednih komponenti.

Još nemamo siguran stroj.

Usklađenost komponenti ne stvara automatski usklađenost sustava. Usklađenost stroja treba projektirati, provjeriti i — što je najteže — održavati unatoč iskušenju da se „više ništa ne dira, jer radi”.

3. Ne dodaj kibernetički napad na popis opasnosti. Poveži dvije analize na pravom mjestu

Na tržištu strojeva formalna analiza rizika kibernetičke sigurnosti i dalje je više iznimka nego standardni dio projekta.

Najčešće postoji industrijski usmjerivač.

Postoji VPN.

Postoji lozinka za PLC.

Ponekad postoji upravljivi switch kojim poslije više nitko ne upravlja.

U ambicioznijoj varijanti proizvođač od dobavljača dobije prezentaciju o „defence in depth” i zaključi da je time upravo završio procjenu rizika kibernetičke sigurnosti cijelog stroja.

Nije.

Kupio je nekoliko tehničkih mjera.

To još nije analiza.

Zato nema smisla opisivati problem kao da u svakom projektu nastaju dvije profesionalne procjene — jedna prema ISO 12100, druga za kibernetičku sigurnost — koje samo slučajno nisu međusobno povezane.

Najčešće nastaje samo jedna.

Procjena rizika stroja.

A analiza kibernetičke sigurnosti proizvoda uopće se ne izrađuje.

Procjena rizika stroja prema ISO 12100 ne svodi se na to da se u tablicu upiše:

kvar senzora → neočekivano gibanje → prignječenje.

To može biti dio konkretnog scenarija, ali nije polazišna točka.

Najprije treba odrediti ograničenja stroja.

Koja je njegova namjena?

Koje su faze životnog ciklusa?

Tko će ga koristiti?

Koji će se zadaci obavljati tijekom transporta, montaže, puštanja u rad, proizvodnje, podešavanja, čišćenja, uklanjanja zastoja, održavanja, dijagnostike i demontaže?

U kojim načinima rada stroj može raditi?

Gdje se čovjek nalazi tijekom svake od tih radnji?

Koji dijelovi stroja tada ostaju pod naponom, tlakom, opterećenjem ili u gibanju?

Koja uporaba nije u skladu s uputama, ali je i dalje razumno predvidiva?

Tek se potom za konkretan zadatak ili radnju identificiraju, među ostalim:

• izvor opasnosti,
• vrsta opasnosti,
• opasna zona,
• izložena osoba,
• opasna situacija,
• opasni događaj, ako se pojavljuje u danom scenariju,
• moguće posljedice i vrsta ozljede.

Tako izgleda analiza rizika stroja.

Ne polazimo od komponente.

Polazimo od čovjeka koji obavlja određeni zadatak na stroju koji se nalazi u određenom stanju. ISO 12100 upravo tako definira metodologiju za identifikaciju opasnosti te procjenu i vrednovanje rizika tijekom odgovarajućih faza životnog ciklusa stroja.

Uzmimo jednostavan primjer.

Operater uklanja zaglavljeni komad iz unutrašnjosti paletizacijske ćelije.

Imamo, dakle:

Zadatak: uklanjanje zastoja.

Faza uporabe: eksploatacija, intervencija nakon zaustavljanja procesa.

Način rada: ručni ili servisni.

Izložena osoba: operater ili radnik održavanja.

Opasna zona: unutrašnjost ćelije, osobito prostor između hvataljke, komada i konstrukcije stroja.

Izvor opasnosti: mehanička energija robota, linearne osi ili pneumatske hvataljke.

Opasna situacija: čovjek se nalazi u zoni dok je izvođenje gibanja i dalje moguće.

Opasni događaj: neočekivano gibanje osi, zatvaranje hvataljke ili oslobađanje akumulirane energije.

Moguća posljedica: udarac, prignječenje, prijelom ili amputacija.

Tek se sada može procjenjivati rizik i odrediti mjere za njegovo smanjenje.

Možda će biti potrebna blokada zaštitne ograde.

Možda će biti potrebno sigurno zaustavljanje.

Možda će biti nužno spriječiti neočekivano pokretanje.

Možda će trebati rasteretiti pneumatsku energiju.

Moguće je i da se gibanje u ručnom načinu rada smije odvijati isključivo uz uređaj za odobravanje i uz sigurno ograničenu brzinu.

To je i dalje klasična procjena rizika stroja.

Gdje se pojavljuje kibernetička sigurnost?

Ne kao nova stavka uz mehaničku, električnu i toplinsku opasnost.

„Haker” nije izvor mehaničke opasnosti

Dopisivanje stavke u tablicu ISO 12100:

Opasnost: kibernetički napad

ne donosi mnogo.

Kibernetički napad nije rotirajuće vratilo, oštar rub, visoka temperatura ni pneumatska energija.

Nije ni zasebna opasna zona.

Operater ne doživi prignječenje zbog ranjivosti CVE.

Doživi ga zbog elementa stroja koji je izvršio gibanje dok se čovjek nalazio na pogrešnom mjestu.

Kibernetički napad, međutim, može promijeniti stanje upravljačkog sustava, podatke, program, konfiguraciju ili način rada zaštitne mjere.

Stoga može postati:

• uzrok opasnog događaja,
• dodatni put koji vodi do opasne situacije,
• uzrok gubitka učinkovitosti mjere za smanjenje rizika,
• ili način zaobilaženja pretpostavki usvojenih pri projektiranju sigurnosnih funkcija.

I to je prava točka dodira.

Ne popis opasnosti.

Nego ponašanje stroja.

Analizu kibernetičke sigurnosti treba izraditi zasebno

Za stroj ili sustav automatizacije analiza kibernetičke sigurnosti imat će drukčiju strukturu od procjene rizika prema ISO 12100.

Najprirodniji okvir za sustav industrijske automatizacije daje IEC 62443-3-2.

Norma, među ostalim, zahtijeva:

• definiranje sustava koji je predmet analize, odnosno SUC-a,
• podjelu sustava na zone i komunikacijske kanale,
• procjenu rizika za pojedine zone i kanale,
• određivanje ciljnih razina sigurnosti SL-T,
• dokumentiranje sigurnosnih zahtjeva.

To je potpuno drukčija polazišna točka nego u ISO 12100.

U IEC 62443, među ostalim, pitamo:

Što točno pripada analiziranom sustavu?

Koju imovinu treba štititi?

Koji se uređaji, aplikacije i sučelja nalaze u sustavu?

Koji bi elementi trebali pripadati istoj zoni?

Kako se odvija komunikacija između zona?

Tko može dobiti pristup?

S kojeg mjesta?

Putem kojeg sučelja?

Koje se ranjivosti mogu iskoristiti?

Koji se podaci, funkcije ili komponente mogu izmijeniti?

Kojim putem napadač može doći od servisnog usmjerivača do PLC-a, HMI-ja, pogona ili inženjerske stanice?

Kakve će posljedice imati gubitak povjerljivosti, cjelovitosti ili dostupnosti?

Koje su zaštitne mjere potrebne?

Za proces sigurnog razvoja proizvoda i zahtjeve koji se odnose na same komponente važne su i druge cjeline ove serije, osobito IEC 62443-4-1 i IEC 62443-4-2. IEC 62443-3-3, pak, uređuje tehničke sigurnosne zahtjeve na razini sustava.

CRA danas ne nalaže proizvođaču da na naslovnici analize napiše „izrađeno u skladu s IEC 62443”.

IEC 62443 također ne zamjenjuje dokazivanje sukladnosti sa zahtjevima CRA.

Za industrijski sustav automatizacije ipak je to znatno logičnija referentna točka nego pokušaj da se nekoliko hakerskih scenarija dopiše u tablicu ISO 12100.

Zato što obje metodologije odgovaraju na različita pitanja.

ISO 12100:

Tijekom kojeg zadatka, gdje, od kojeg izvora i kao posljedica kojeg događaja čovjek može pretrpjeti štetu?

IEC 62443:

Tko, kojim putem i iskorištavanjem koje ranjivosti može utjecati na sustav, njegove podatke ili funkcije?

Tek nakon toga treba provjeriti mijenja li odgovor iz druge analize scenarij iz prve.

Isti scenarij, dvije različite analize

Vratimo se operatoru koji uklanja zaglavljeni komad.

Analiza ISO 12100 pokazala je da čovjek ulazi u zonu u kojoj ga može prignječiti kretanje robota ili hvataljke.

Mjera za smanjenje rizika jest blokirani štitnik, funkcija sigurnog zaustavljanja te lokalni reset smješten izvan opasne zone.

Sada provodimo analizu kibernetičke sigurnosti sustava.

Identificiramo:

• usmjerivač koji se koristi za daljinski servis,
• servisni račun,
• inženjersko prijenosno računalo,
• HMI,
• standardni PLC,
• safety PLC,
• pogone,
• programsko sučelje,
• mrežu PROFINET i komunikaciju PROFIsafe,
• mehanizme za učitavanje programa i konfiguracije.

Razmatramo scenarij:

Preuzimanje servisnog računa omogućuje daljinski pristup standardnom PLC-u i slanje naredbe za kretanje dok se čovjek nalazi u ćeliji.

Dovodi li taj scenarij do opasnog događaja?

Na to nije moguće odgovoriti samo na temelju same činjenice da je PLC preuzet.

Treba provjeriti arhitekturu sigurnosnih funkcija.

Ako safety PLC nadzire otvaranje štitnika, funkcija sigurno isključuje moment pogona, reset je isključivo lokalni, a standardni PLC ne može ponovno uspostaviti kretanje neovisno o stanju sigurnosne funkcije, tada preuzimanje standardnog upravljača može zaustaviti proizvodnju ili poremetiti proces.

Ali ne bi smjelo uzrokovati kretanje pri otvorenom štitniku.

Tada kibernetička analiza pokazuje napad.

Procjena rizika stroja pokazuje mehaničku opasnost.

Međutim, ispravno projektirana sigurnosna funkcija prekida put između njih.

A sada druga varijanta.

Servisni način rada odabire se na običnom HMI-ju.

Vrijednost ograničene brzine dolazi iz standardnog PLC-a.

Daljinski serviser može izvršiti reset.

Isti inženjerski račun omogućuje izmjenu standardnog programa i safety konfiguracije.

Kopija safety programa nije povezana s konkretnom verzijom stroja.

Nitko nakon intervencije ne provjerava kontrolni zbroj.

Parametri pogona mogu se mijenjati na daljinu.

U toj arhitekturi preuzimanje računa više ne znači samo gubitak povjerljivosti ili kratki zastoj.

Može promijeniti uvjete na kojima se temeljilo smanjenje rizika.

Može dovesti do:

• odabira pogrešnog načina rada,
• promjene parametra sigurnog kretanja,
• neovlaštenog reseta,
• učitavanja neodobrene konfiguracije,
• ili slabljenja funkcije koja je trebala spriječiti neočekivano pokretanje.

I tada kibernetički scenarij treba povezati s konkretnim scenarijem sigurnosti stroja:

zadatak uklanjanja zastoja → čovjek u opasnoj zoni → neovlaštena promjena upravljačkog sustava ili zaštitne funkcije → neočekivano kretanje → prignječenje.

Izvor opasnosti nije se promijenio.

To je i dalje mehanička energija stroja.

Opasna zona nije se promijenila.

Ona se i dalje nalazi unutar ćelije.

Nije se promijenila ni moguća posljedica.

To je i dalje ozljeda operatora.

Promijenio se put koji vodi do opasnog događaja.

Ne ulazi svaka ranjivost u ISO 12100

Ta je razlika jednako važna.

Pretpostavimo da ranjivost u HMI-ju omogućuje očitavanje povijesnih proizvodnih podataka.

To može biti važan problem s gledišta CRA.

Može narušiti povjerljivost podataka.

Može zahtijevati ažuriranje, procjenu utjecaja, postupanje prema korisnicima, a u određenim okolnostima i prijavljivanje.

Ali ako ne utječe na ponašanje stroja, ne mijenja zaštitnu mjeru i ne može dovesti do opasne situacije, nema smisla na silu je ugurati u procjenu rizika prema ISO 12100.

Slično tome, napad koji uzrokuje isključivo nedostupnost proizvodnih izvještaja može predstavljati poslovni problem i problem usklađenosti s CRA-om.

Međutim, ne mora stvarati rizik za operatera.

S druge strane, naizgled bezazlena mogućnost promjene jedne zadane vrijednosti može imati malo značenje za povjerljivost podataka, ali golemo značenje za fizičku sigurnost.

Primjerice, kada ta vrijednost određuje:

• maksimalnu brzinu osi,
• silu pritiska,
• temperaturu procesa,
• tlak,
• položaj zaustavljanja,
• vrijeme otvaranja ventila,
• ili dopuštenu granicu tijekom rada s otvorenim štitnikom.

Zato kibernetičku prijetnju ne klasificiramo prema tome kako tehnički zvuči.

Gledamo što ona stvarno može učiniti stroju.

Uredba o strojevima nameće taj most

Ta povezanost nije samo dobra inženjerska praksa.

Točka 1.2.1 Priloga III Uredbe o strojevima zahtijeva da upravljački sustavi budu projektirani i izvedeni tako da sprječavaju nastanak opasnih situacija, uključujući i one koje proizlaze iz razumno predvidivih zlonamjernih pokušaja trećih osoba.

CRA pak upućuje na to da njegovi bitni zahtjevi kibernetičke sigurnosti mogu poduprijeti dokazivanje usklađenosti, među ostalim, sa zahtjevima 1.1.9 i 1.2.1 Uredbe o strojevima.

Ali to se ne događa automatski.

Proizvođač tu povezanost mora dokazati na temelju procjene rizika prema ISO 12100. Ocjenjivanje sukladnosti prema CRA-u i ocjenjivanje sukladnosti prema Uredbi o strojevima i dalje ostaju odvojeni procesi.

Drugim riječima, nije dovoljno pripremiti:

• procjenu rizika prema ISO 12100,
• analizu prema IEC 62443,
• dva odvojena izvještaja,
• i računati na to da će sličnost brojeva normi između njih sama stvoriti revizijski trag.

Potrebno je uspostaviti poveznicu.

Za svaki bitan kibernetički scenarij treba utvrditi:

1. koji element ili funkcija mogu biti preuzeti ili izmijenjeni,
2. kakvo ponašanje stroja to može izazvati,
3. vodi li takvo ponašanje do opasne situacije ili opasnog događaja,
4. na koji se zadatak i na koju zonu opasnosti to odnosi,
5. koja je moguća posljedica navedena u procjeni prema ISO 12100,
6. koja mjera za smanjenje rizika treba prekinuti razvoj scenarija,
7. ostaje li ta mjera učinkovita nakon preuzimanja napadnutog elementa.

Ta posljednja točka je najvažnija.

Jer ako napad i zaštita ovise o:

• istom upravljaču,
• istom korisničkom računu,
• istoj mreži,
• istoj inženjerskoj stanici,
• ili istom programu,

onda možda nemamo dva neovisna sloja zaštite.

Imamo jedan sloj opisan u dva dokumenta.

Zato nam nije potrebna jedna golema tablica pod nazivom:

„procjena rizika safety & cybersecurity”.

Potrebne su nam dvije ispravne analize, provedene odgovarajućim metodama, i kontrolirana dodirna točka između njih.

ISO 12100 treba opisati čovjeka, zadatak, izvor opasnosti, zonu, opasnu situaciju, opasni događaj i moguću štetu.

IEC 62443 treba pomoći opisati sustav, njegove zone, komunikacijske kanale, resurse, prijetnje, ranjivosti, putove napada i potrebne zaštitne mjere.

A proizvođač mora dokazati može li scenarij iz druge analize pokrenuti scenarij iz prve ili oduzeti učinkovitost mjeri koja ga je trebala zaustaviti.

Kibernetički napad ne mora stvoriti novu opasnost. Dovoljno je da otvori novi put do stare nesreće.

4. Pentest prije FAT-a je fotografija. CRA zahtijeva film

U mnogim projektima kibernetička sigurnost pojavljuje se dva tjedna prije FAT-a.

Naručuje se pentest.

Nastaje izvještaj.

Kritične ranjivosti se ispravljaju, srednje se prihvaćaju, a dokument završava u projektnoj mapi.

Stroj je kibernetički siguran.

Do sljedećeg utorka.

Pentest može biti vrlo vrijedan element provjere. Međutim, on pokazuje stanje konkretne verzije proizvoda, u konkretnoj konfiguraciji i uz primjenu određenih testnih scenarija.

Ne daje odgovor na pitanje što će proizvođač učiniti poslije.

A CRA se odnosi na cijeli životni ciklus proizvoda. Procjena rizika kibernetičke sigurnosti treba utjecati na planiranje, projektiranje, razvoj, proizvodnju, isporuku i održavanje proizvoda. Nakon stavljanja na tržište proizvođač mora upravljati ranjivostima tijekom deklariranog razdoblja podrške.

Vratimo se stroju za pakiranje povrća.

Stroj je prošao FAT.

Pentest nije pokazao kritične ranjivosti.

Osam mjeseci kasnije proizvođač servisnog usmjerivača objavljuje informaciju o ranjivosti koja omogućuje preuzimanje uređaja.

I tada počinje pravi posao.

Koji isporučeni strojevi imaju taj model usmjerivača?

Koja je verzija firmvera instalirana u svakom primjerku?

Je li udaljeni pristup aktivan?

Može li se ranjivost iskoristiti u stvarnoj konfiguraciji?

Daje li preuzimanje usmjerivača pristup samo dijagnostici ili i HMI-ju, PLC-u, pogonima i safety PLC-u?

Je li moguć samo pregled podataka ili i promjena programa odnosno parametara?

Može li napad utjecati na sigurnosnu funkciju?

Je li dobavljač objavio zakrpu?

Hoće li ažuriranje usmjerivača promijeniti certifikate, komunikacijska pravila ili način uspostave tunela?

Treba li nakon ažuriranja ponovno provjeriti udaljeni servis, komunikaciju i dio sigurnosnih funkcija?

Koje korisnike treba obavijestiti?

I ispunjava li situacija kriterije za prijavu aktivno iskorištavane ranjivosti ili ozbiljnog incidenta?

Izvješće s pentesta provedenog prije FAT-a neće dati odgovor ni na jedno od tih pitanja.

Ono opisuje stroj koji više ne postoji.

Jer su se od trenutka ispitivanja promijenili verzije softvera, konfiguracije, korisničko okruženje i saznanja o ranjivostima.

Zato proizvođaču nije potreban samo test, nego proces:

• identificiranja verzija hardvera, firmwarea i softvera u svakom isporučenom primjerku,
• praćenja informacija o ranjivostima,
• procjene njihove iskoristivosti u stvarnoj arhitekturi,
• provjere mogućih posljedica za proces i sigurnost stroja,
• pripreme i testiranja ažuriranja,
• obavještavanja korisnika,
• dokumentiranja donesenih odluka,
• obrade obveznih prijava.

Od 11. rujna 2026. proizvođači su obvezni prijavljivati aktivno iskorištavane ranjivosti i ozbiljne incidente koji utječu na sigurnost proizvoda s digitalnim elementima. Početno upozorenje mora se dostaviti u roku od 24 sata, a potpuna prijava u roku od 72 sata.

To znači da nakon otkrivanja problema više neće biti vremena za početak traženja:

„Tko je zapravo radio taj router i gdje nam je popis strojeva u koje smo ga ugradili?”

IEC 62443-4-1 jasno pokazuje razliku između jednokratnog osiguravanja proizvoda i sigurnog ciklusa njegova razvoja. Obuhvaća ne samo projektiranje i verifikaciju, nego i upravljanje nedostacima, ispravcima i krajem životnog vijeka proizvoda.

FAT dakle može zatvoriti fazu projekta.

Ne zatvara životni ciklus proizvoda.

Ne zatvara razdoblje podrške.

Ne završava praćenje ranjivosti.

I ne znači da je konfiguracija na dan preuzimanja zamrznuta za sljedećih petnaest godina.

Stroj može dugo pakirati povrće za supermarkete.

No proizvođač ne može njegovo kibernetičku sigurnost zapakirati zajedno s uputama, omotati folijom i smatrati da je time isporučena jednom zauvijek.

Pentest može zatvoriti jednu stavku na FAT popisu. CRA otvara proces koji traje do kraja razdoblja podrške proizvoda.