CRA pre výrobcov strojov po usmerneniach Komisie z 27. júla 2026. Čo je naozaj potrebné zaviesť?

Roky sa kybernetická bezpečnosť stroja dala opísať tromi krokmi: značkový riadiaci systém, VPN „lebo tak sa to robí“ a klasické „zákazník si zabezpečí sieť“. A keď niekto pridal firewall do rozvádzača, téma sa často považovala za uzavretú — aspoň dovtedy, kým sa niekto nepokúsil overiť, čo sa stane pri skutočnom útoku, nie iba v prezentácii.

Lenže kybernetická bezpečnosť netečie po PROFINETe. Komponenty môžu mať certifikáty, vyhlásenia a v marketingovom letáku „secure by design“, no stroj ako celok môže byť stále predvídateľný spôsobom, ktorý s bezpečnosťou nemá nič spoločné. Rovnako ako bezpečnostné relé samo osebe neurobí systém bezpečným, ak ho logika riadenia umožňuje obísť, ani „bezpečné“ HMI nerieši problém architektúry, integrácie, oprávnení, aktualizácií a toho, čo sa deje, keď sa niekto prestane pýtať na súhlas.

CRA (Cyber Resilience Act, Nariadenie Európskeho parlamentu a Rady (EÚ) 2024/2847) nie je dodatok pre IT. Je to produktová regulácia, ktorá vstupuje do životného cyklu stroja bez toho, aby sa pýtala na súhlas oddelenia automatizácie. Zahŕňa návrh riadenia, analýzu rizík, dodávateľský reťazec, konfiguráciu, aktualizácie, ako aj údržbu produktu dlho po tom, čo bol FAT podpísaný a stroj opustil výrobnú halu. A nie, argument „nevystavujeme ho internetu“ tému neuzatvára. V praxi stačí servisný notebook, USB kľúč, vzdialená diagnostika „na chvíľu“ alebo integrácia s podnikovým systémom a hranica medzi izoláciou a vystavením prestáva existovať.

Usmernenia Komisie z 27. júla 2026 samotné nariadenie nezmenili, ale účinne zúžili priestor na výklad, ktorý predtým umožňoval považovať kybernetickú bezpečnosť za voliteľnú vrstvu. Spresnila sa okrem iného hranica produktu, úloha vzdialeného spracovania, zodpovednosť za zmeny po dodaní, ako aj to, že „to po FAT už nie je náš problém“ už nie je bezpečný predpoklad.

Najdôležitejšia zmena je však ešte zásadnejšia: kybernetický útok prestáva byť výlučne IT udalosťou a stáva sa scenárom, ktorý ovplyvňuje funkčnú bezpečnosť stroja. Ak môže neoprávnená zmena programu spôsobiť pohyb osi, obídenie blokovania, zmenu parametrov procesu alebo stratu bezpečnostnej funkcie, už nehovoríme o „sieťovom incidente“. Hovoríme o potenciálne nekontrolovanom správaní stroja — bez ohľadu na to, či bol zdrojom chybný konfiguračný zásah, zraniteľnosť softvéru alebo úmyselný zásah.

V tomto kontexte jednorazový penetračný test pred FAT prestáva byť dôkazom zhody a stáva sa iba snímkou stavu systému v konkrétnom okamihu. CRA vyžaduje priebežný prístup: od návrhu cez výrobu a uvedenie do prevádzky až po aktualizácie, riadenie zraniteľností, reakciu na incidenty a údržbu počas deklarovaného obdobia podpory.

V praxi to znamená odklon od uvažovania „hotové = bezpečné“ smerom k „udržiavané = pod kontrolou“. Bez ilúzie, že firewall v rozvádzači, VPN a certifikát komponentu tému uzatvárajú. A bez predpokladu, že kybernetická bezpečnosť sa končí podpisom preberacieho protokolu.

V tomto článku rozoberáme, čo usmernenia CRA reálne menia pre výrobcov, integrátorov a modernizátorov strojov — bez toho, aby sa celá téma zredukovala na heslo „zmeňme heslo a pridajme checkbox cybersecurity“.

1. Aby stroj nespadal pod CRA, musel by byť takmer len na stykačoch

V mnohých projektoch sa rozsah CRA overuje jedinou otázkou:

Bude stroj pripojený na internet?

Nebude.

Teda téma je uzavretá.

Na schéme je PLC, HMI, niekoľko pohonov, decentralizované vstupy a výstupy, ventilový ostrov, bezpečnostný skener a port na nahratie programu. Riadiaci systém komunikuje s panelom cez PROFINET, s pohonmi si vymieňa riadiace a stavové slová a snímače prenášajú údaje cez IO-Link.

Ale router so SIM kartou tam nie je.

Veď predsa údaje sa stávajú údajmi až vtedy, keď opustia výrobnú halu.

Lenže CRA sa nepýta, či má stroj prístup na internet.

Pýta sa, či jeho určenie alebo rozumne predvídateľné používanie zahŕňa priame alebo nepriame, logické alebo fyzické dátové spojenie so zariadením alebo sieťou. Nemusí ísť o spojenie s cloudom, serverom výrobcu ani verejným internetom. Môže prebiehať káblom, rádiovo, cez programové rozhranie alebo ako súčasť väčšieho systému.

A teraz kľúčová otázka: čo v typickom stroji skutočne prenáša údaje?

Číta HMI stavy z PLC a zapisuje nastavenia?

Posiela PLC do pohonu riadiace slovo a dostáva späť rýchlosť, stav a chybový kód?

Prenáša ostrov vstupov a výstupov obraz procesu?

Posiela snímač IO-Link nameranú hodnotu, identifikátor zariadenia a diagnostické údaje?

Komunikuje safety PLC s modulmi cez PROFIsafe?

Nahráva sa program, hardvérová konfigurácia alebo firmware zo servisného notebooku?

Dajú sa receptúry, reporty alebo aktualizácie preniesť cez USB?

Ak odpoveď čo i len raz znie „áno“, potom s veľkou pravdepodobnosťou ide o dátové spojenie.

A nemení na tom nič ani to, že:

• stroj pracuje v lokálnej sieti,
• nemá verejnú IP adresu,
• port Ethernet sa používa iba pri uvádzaní do prevádzky,
• notebook pripája výlučne servis,
• komunikácia prebieha len v rámci riadiaceho systému,
• zákazník sľúbil, že stroj nikdy nepripojí na internet.

CRA zahŕňa nielen použitie opísané v návode ako základné, ale aj rozumne predvídateľné použitie. Servisný port teda neprestáva prenášať údaje len preto, že je pri ňom v schéme dopísané „SERVICE ONLY“.

Usmernenia Komisie z 27. júla 2026 však zavádzajú dôležité rozlíšenie.

Nie každý vodič a nie každý elektrický signál predstavuje dátové spojenie.

Ak signál slúži výlučne na zapnutie, vypnutie alebo napájanie určitej funkcie a neprenáša digitálne zakódovanú informáciu, samotná prítomnosť dvoch elektrických stavov ešte nestačí na to, aby sa považoval za dátové spojenie.

Tlačidlo, ktoré privádza napätie na cievku stykača, sa nestáva digitálnym rozhraním len preto, že jeho stav možno opísať ako nula alebo jedna.

Podobne aj klasický koncový spínač zapojený do reléovo-stykačového obvodu môže iba prerušiť alebo uzavrieť obvod. Neprenáša číslo zariadenia, procesnú hodnotu, diagnostický kód, verziu firmvéru ani telegram obsahujúci viacero informácií.

Ak sa však ten istý stav dostane do inteligentného zariadenia, zakóduje sa, prenesie po zbernici, prepojí s diagnostikou a prijímač ho vyhodnotí ako informáciu, situácia už vyzerá inak.

Hranica teda nevedie medzi strojom „online“ a „offline“.

Vedie medzi obyčajným riadiacim signálom a výmenou digitálne zakódovaných informácií.

Preto by v praxi stroj, ktorý by mal zostať mimo rozsahu CRA výlučne z dôvodu absencie dátového spojenia, musel viac pripomínať klasický obvod s tlačidlami, koncovými spínačmi, relé a stykačmi než moderný projekt otváraný v TIA Portal.

To samozrejme neznamená zákonné vylúčenie pre stykače.

Je možné zostrojiť jednoduchý stroj s PLC, ktorý po podrobnej analýze nesplní kritérium rozsahu. Rovnako možno do stykačového obvodu pridať digitálny regulátor, servisné rozhranie alebo komunikačný modul a ocitnúť sa presne na druhej strane hranice.

Názov komponentu o tom nerozhoduje.

Rozhoduje to, čo výrobok skutočne robí a s čím si vymieňa údaje.

Preto treba pred odpoveďou na otázku, či konkrétny stroj podlieha CRA, určiť:

• kde vedie hranica posudzovaného výrobku,
• aké zariadenia a softvérové prvky sú jeho súčasťou,
• aké fyzické a logické rozhrania má,
• aké informácie sa cez ne prenášajú,
• ktoré spojenia sú priame a ktoré prebiehajú cez väčší systém,
• ktoré z nich sa vyskytujú počas bežnej prevádzky, uvádzania do prevádzky, diagnostiky, aktualizácie alebo servisu,
• aké spôsoby použitia sú rozumne predvídateľné, aj keď by ich výrobca radšej nepredvídal.

Kým si na tieto otázky neodpovieme, nevieme, či stroj zostáva mimo rozsahu CRA.

Máme nanajvýš pohodlnú vetu:

„Stroj nie je pripojený na internet“.

Lenže to je odpoveď na otázku, ktorú CRA nekladie.

PROFINET nie je internet. A pre CRA ním vôbec nemusí byť.

2. Kybernetická bezpečnosť sa nešíri cez PROFINET

V mnohých projektoch sa téma zhody stroja začína už vo fáze nákupu.

PLC od renomovaného výrobcu.
HMI s aktuálnym firmvérom.
Spravovateľný switch.
Priemyselný router s VPN.
Pohony s bezpečnostnými funkciami.
Safety PLC s príslušným certifikátom.

Ku každému zariadeniu vyhlásenie o zhode, návod a niekoľko dokumentov s heslami „secure“, „encrypted“ a „defence in depth“.

Na schéme vyzerá všetko profesionálne.

Stále však nie je jasné, či je kompletný stroj kyberneticky bezpečný.

Pretože kybernetická bezpečnosť sa po PROFINETe „neprenáša“.

Je to trochu ako so zámkom na dverách:
môžete mať veľmi dobrý zámok v každej miestnosti, certifikovaný, testovaný, s krásnou dokumentáciou a hologramom „secure“, ale to stále nezaručuje bezpečnosť, ak niekto nechal vstupné dvere dokorán otvorené „lebo pri uvádzaní do prevádzky to bolo rýchlejšie“.

A presne tak je to aj tu: komponenty môžu byť ukážkové, no systém môže byť aj tak… tvorivo otvorený.

PLC „neprenáša“ bezpečnosť do HMI.
Firewall „neopravuje“ logiku aplikácie.
Switch „nespravuje“ prístup používateľov.
A to, že má každý prvok certifikát, ešte neznamená, že celý stroj nie je jedna veľká, zdvorilo zdokumentovaná zraniteľnosť.

PROFINET prenáša údaje.

Neprenáša zodpovednosť.
A žiaľ, neprenáša ani zdravý rozum.

CRA zahŕňa kompletné výrobky aj komponenty uvádzané na trh samostatne. To znamená, že riadiaci systém, operátorský panel alebo komunikačný modul možno posudzovať samostatne. Výrobca stroja však stále musí preukázať, že celok funguje bezpečne v reálnej konfigurácii u zákazníka — teda v tej verzii, v ktorej už „určite nikto nič nemenil… však?“.

A práve tu sa objavuje najčastejšia chyba.

Je to presne ten istý mechanizmus, ktorý už roky poznáme z bezpečnosti strojov.

Záclona má PL e.
Safety PLC má SIL 3.
Pohon má STO.

Znamená to, že celý stroj je automaticky na tejto úrovni?

Je to podobné, ako keď každý prvok lešenia spĺňa bezpečnostné normy, no to ešte samo osebe nezaručuje, že celá konštrukcia bude stabilná.

Nie.

Pretože stále treba overiť, ako to všetko funguje spolu — teda absolvovať ten málo obľúbený krok „systémového myslenia“, ktorý, žiaľ, nemá tlačidlo „auto-certify“.

V kybernetickej bezpečnosti je to úplne rovnaké.

Môžete mať „bezpečné“ prvky, ale v praxi:

• operátor vidí a môže meniť viac údajov, než skutočne potrebuje, lebo „tak to bolo pohodlnejšie“,
• jedno servisné heslo funguje na všetkých strojoch, lebo „servis aj tak vie, čo robí“,
• servisný port je dostupný „pre istotu“, teda v podstate pri každej príležitosti,
• vzdialený prístup pokrýva celú sieť, lebo niekto kedysi povedal „veď je to len diagnostika“,
• aktualizácie sa dajú nahrať bez kontroly, lebo „nikdy sa nič nepokazilo“,
• zariadenia si bez obmedzení „dôverujú“, lebo dôvera je lacnejšia než segmentácia,
• a integrácia predpokladá, že nikto nikdy neurobí chybu, čo je — ako ukazuje história — najoptimistickejší predpoklad v inžinierstve.

Každý prvok samostatne môže byť v poriadku.

No systém ako celok vie z týchto správnych prvkov vytvoriť niečo, čo funguje… len nie nevyhnutne tak, ako sa predpokladalo.

A to je podstatné: riziko nespočíva v zariadeniach, ale v ich prepojení, konfigurácii a v legendárnom prístupe „dočasne ponechanom“.

CRA od výrobcu stroja vyžaduje viac než len zbieranie vyhlásení ako trofejí. Vyžaduje overiť, či to, čo bolo poskladané z komponentov, zostáva bezpečné ako celok — a nielen že to „pekne vyzerá v tabuľke zhody“.

V praxi to znamená jednoduché obchodné otázky:

• či má každý používateľ len taký prístup, aký skutočne potrebuje, a nie „lebo sa to možno raz zíde“,
• či je vzdialený prístup obmedzený na minimum, alebo skôr na maximum pohodlia,
• či servis nemá „plné práva všade“, lebo niekto usúdil, že to urýchli život,
• či sieť netvorí jednu spoločnú plochu, lebo segmentácia „komplikuje projekt“,
• či sú aktualizácie riadené, alebo sa skôr „nahodia a modlíme sa“,
• či sa dá rýchlo identifikovať, ktoré stroje sú vystavené riziku, alebo skôr „to preveríme po incidente“,
• či porucha jedného prvku neotvorí celý systém, lebo „tak to vyšlo pri integrácii“.

To nie sú technické otázky „pre inžinierov na zložité veci“.

To sú otázky obchodného rizika: prestoje, náklady, zodpovednosť a ten drobný detail, že výroba má jednoducho fungovať.

Preto nestačí povedať:

„všetky komponenty sú v zhode“

Pretože to stále neodpovedá na otázku:

je celý stroj bezpečný pri reálnom používaní, alebo len v PowerPointe z projektovej revízie?

Vyhlásenie dodávateľa je dôležité.

No týka sa len jedného prvku — toho, ktorý bol práve testovaný v laboratórnych podmienkach, a nie v prostredí „niekde vo výrobe, s VPN, USB a časovým tlakom“.

Nepokrýva to, ako bol použitý.
Nepokrýva konfiguráciu.
Nepokrýva integráciu.
Nepokrýva rozhodnutia prijaté „narýchlo pri uvádzaní do prevádzky, lebo zákazník čakal“.
Nepokrýva to, čo sa deje po rokoch prevádzky, keď si už nikto nepamätá, prečo bolo niečo „dočasne otvorené“.

Preto sa hodnotenie nemôže skončiť pri zozname zariadení.

Treba sa pozrieť na systém ako na celok:

• kto má prístup a prečo (a nie „lebo ho mal vždy“),
• čo je naozaj potrebné a čo sa len „ponechalo, lebo to neprekážalo“,
• kde môžu údaje uniknúť mimo kontroly, lebo niekto usúdil, že „je to len diagnostika“,
• čo sa stane, keď niekto použije legálny prístup nelegálnym spôsobom (teda presne tak, ako to robia útoky),
• ako rýchlo sa dá reagovať, keď sa objaví problém, a nie až „po štvrťročnej revízii“.

Kým na tieto otázky neexistujú odpovede, máme len súbor veľmi slušných komponentov.

Ešte nemáme bezpečný stroj.

Zhoda komponentov automaticky nevytvára zhodu systému. Zhodu stroja treba navrhnúť, overiť a — čo je najťažšie — udržať napriek pokušeniu „už sa ničoho nedotýkať, lebo to funguje“.

3. Nepridávaj kybernetický útok do zoznamu nebezpečenstiev. Prepoj dve analýzy na správnom mieste

Na trhu so strojmi je formálna analýza rizík kybernetickej bezpečnosti stále skôr výnimkou než štandardnou súčasťou projektu.

Najčastejšie je tam priemyselný router.

Je tam VPN.

Je tam heslo do PLC.

Niekedy je tam aj manažovateľný switch, ktorý už potom nikto nespravuje.

V ambicióznejšom variante výrobca dostane od dodávateľa prezentáciu o „defence in depth“ a usúdi, že tým práve ukončil analýzu rizík kybernetickej bezpečnosti celého stroja.

Neukončil.

Kúpil niekoľko technických opatrení.

To ešte nie je analýza.

Preto nemá zmysel opisovať problém tak, akoby v každom projekte vznikali dve profesionálne hodnotenia — jedno podľa ISO 12100, druhé týkajúce sa kybernetickej bezpečnosti — ktoré sa len náhodou navzájom neprepojili.

Najčastejšie vznikne len jedno.

Posúdenie rizík stroja.

A analýza kybernetickej bezpečnosti produktu často nevznikne vôbec.

Posúdenie rizík stroja podľa ISO 12100 nespočíva v tom, že sa do tabuľky zapíše:

porucha snímača → neočakávaný pohyb → pomliaždenie.

Môže to byť časť konkrétneho scenára, ale nie východiskový bod.

Najprv je potrebné určiť hranice stroja.

Aký je jeho určený účel?

Aké sú fázy životného cyklu?

Kto ho bude používať?

Aké úlohy sa budú vykonávať počas prepravy, montáže, uvedenia do prevádzky, výroby, nastavovania, čistenia, odstraňovania zaseknutí, údržby, diagnostiky a demontáže?

V akých režimoch môže stroj pracovať?

Kde sa nachádza človek počas každej z týchto operácií?

Ktoré časti stroja sú vtedy pod napätím, tlakom, zaťažením alebo v pohybe?

Aké použitie nie je v súlade s návodom, ale stále zostáva rozumne predvídateľné?

Až potom sa pre konkrétnu úlohu alebo operáciu identifikujú okrem iného:

• zdroj nebezpečenstva,
• druh nebezpečenstva,
• nebezpečná zóna,
• ohrozená osoba,
• nebezpečná situácia,
• nebezpečná udalosť, ak sa v danom scenári vyskytuje,
• možné následky a druh ujmy.

Takto vyzerá analýza rizík stroja.

Nezačíname komponentom.

Začíname človekom, ktorý vykonáva konkrétnu úlohu pri stroji nachádzajúcom sa v určitom stave. ISO 12100 stanovuje práve takúto metodiku identifikácie nebezpečenstiev, ako aj odhadu a hodnotenia rizika počas príslušných fáz životného cyklu stroja.

Uveďme si jednoduchý príklad.

Operátor odstraňuje zaseknutý diel z vnútra paletizačnej bunky.

Máme teda:

Úloha: odstránenie zaseknutia.

Fáza používania: prevádzka, zásah po zastavení procesu.

Pracovný režim: ručný alebo servisný.

Ohrozená osoba: operátor alebo pracovník údržby.

Nebezpečná zóna: vnútro bunky, najmä priestor medzi chápadlom, dielom a konštrukciou stroja.

Zdroj nebezpečenstva: mechanická energia robota, lineárnej osi alebo pneumatického chápadla.

Nebezpečná situácia: človek sa nachádza v zóne, zatiaľ čo vykonanie pohybu je stále možné.

Nebezpečná udalosť: neočakávaný pohyb osi, zatvorenie chápadla alebo uvoľnenie akumulovanej energie.

Možný následok: náraz, pomliaždenie, zlomenina alebo amputácia.

Až teraz možno hodnotiť riziko a určovať opatrenia na jeho zníženie.

Môže byť potrebné blokovanie krytu.

Môže byť potrebné bezpečné zastavenie.

Môže byť nevyhnutné zabrániť neočakávanému spusteniu.

Možno bude potrebné odviesť pneumatickú energiu.

Možno sa pohyb v ručnom režime môže vykonávať výlučne pomocou povoľovacieho zariadenia a pri bezpečne obmedzenej rýchlosti.

Stále ide o klasické posúdenie rizík stroja.

Kde sa tu objavuje kybernetická bezpečnosť?

Nie ako nová položka vedľa mechanického, elektrického a tepelného nebezpečenstva.

„Hacker“ nie je zdrojom mechanického nebezpečenstva

Doplnenie položky do tabuľky ISO 12100:

Nebezpečenstvo: kybernetický útok

veľa neprinesie.

Kybernetický útok nie je rotujúci hriadeľ, ostrá hrana, vysoká teplota ani pneumatická energia.

Nie je ani samostatnou nebezpečnou zónou.

Operátor neutrží pomliaždenie v dôsledku zraniteľnosti CVE.

Utrpí ho od prvku stroja, ktorý vykonal pohyb v čase, keď sa človek nachádzal na nesprávnom mieste.

Kybernetický útok však môže zmeniť stav riadiaceho systému, údaje, program, konfiguráciu alebo spôsob fungovania ochranného opatrenia.

Môže sa teda stať:

• príčinou nebezpečnej udalosti,
• dodatočnou cestou vedúcou k nebezpečnej situácii,
• príčinou straty účinnosti opatrenia na zníženie rizika,
• alebo spôsobom obídenia predpokladov prijatých pri navrhovaní bezpečnostných funkcií.

A práve to je správny styčný bod.

Nie zoznam nebezpečenstiev.

Správanie stroja.

Analýza kybernetickej bezpečnosti by mala vzniknúť samostatne

Pre stroj alebo systém automatizácie bude mať analýza kybernetickej bezpečnosti inú štruktúru než posúdenie rizík podľa ISO 12100.

Najprirodzenejší rámec pre systém priemyselnej automatizácie poskytuje IEC 62443-3-2.

Norma okrem iného vyžaduje:

• definovanie systému, ktorý je predmetom analýzy, teda SUC,
• rozdelenie systému na zóny a komunikačné kanály,
• posúdenie rizika pre jednotlivé zóny a kanály,
• určenie cieľových úrovní bezpečnosti SL-T,
• zdokumentovanie bezpečnostných požiadaviek.

To je úplne iný východiskový bod než v ISO 12100.

V IEC 62443 sa okrem iného pýtame:

Čo presne patrí do analyzovaného systému?

Aké aktíva treba chrániť?

Aké zariadenia, aplikácie a rozhrania sa v systéme nachádzajú?

Ktoré prvky by mali patriť do rovnakej zóny?

Ako prebieha komunikácia medzi zónami?

Kto môže získať prístup?

Z akého miesta?

Pomocou akého rozhrania?

Aké zraniteľnosti môžu byť zneužité?

Ktoré údaje, funkcie alebo komponenty môžu byť zmenené?

Akou cestou sa môže útočník dostať od servisného routera k PLC, HMI, pohonu alebo inžinierskej stanici?

Aké dôsledky bude mať strata dôvernosti, integrity alebo dostupnosti?

Aké ochranné opatrenia sú potrebné?

Pre proces bezpečného vývoja produktu a požiadavky na samotné komponenty budú dôležité aj ďalšie časti tejto série, najmä IEC 62443-4-1 a IEC 62443-4-2. IEC 62443-3-3 zasa usporadúva technické požiadavky na bezpečnosť na úrovni systému.

CRA dnes výrobcovi neprikazuje uviesť na titulnej strane analýzy „vypracované v súlade s IEC 62443“.

IEC 62443 zároveň nenahrádza preukázanie zhody s požiadavkami CRA.

Pre priemyselný automatizačný systém je to však oveľa logickejší referenčný rámec než pokus doplniť niekoľko hackerských scenárov do tabuľky ISO 12100.

Pretože obe metodiky odpovedajú na odlišné otázky.

ISO 12100:

Pri akej úlohe, kde, z akého zdroja a v dôsledku akej udalosti môže človek utrpieť ujmu?

IEC 62443:

Kto, akou cestou a s využitím akej zraniteľnosti môže ovplyvniť systém, jeho údaje alebo funkcie?

Až potom treba overiť, či odpoveď z druhej analýzy mení scenár z prvej.

Ten istý scenár, dve rozdielne analýzy

Vráťme sa k operátorovi, ktorý odstraňuje zaseknutý diel.

Analýza ISO 12100 ukázala, že človek vstupuje do zóny, v ktorej môže byť pritlačený pohybom robota alebo chápadla.

Opatrením na zníženie rizika je blokovaný kryt, funkcia bezpečného zastavenia a lokálny reset umiestnený mimo nebezpečnej zóny.

Teraz vykonáme analýzu kybernetickej bezpečnosti systému.

Identifikujeme:

• router používaný na vzdialený servis,
• servisný účet,
• inžiniersky notebook,
• HMI,
• štandardné PLC,
• safety PLC,
• pohony,
• programovacie rozhranie,
• sieť PROFINET a komunikáciu PROFIsafe,
• mechanizmy nahrávania programu a konfigurácie.

Posudzujeme scenár:

Prevzatie servisného účtu umožní vzdialený prístup k štandardnému PLC a odoslanie príkazu na pohyb v čase, keď sa v bunke nachádza človek.

Vedie tento scenár k nebezpečnej udalosti?

Na základe samotného faktu prevzatia PLC sa na to odpovedať nedá.

Treba preveriť architektúru bezpečnostnej funkcie.

Ak otvorenie krytu monitoruje safety PLC, funkcia bezpečne odpojí moment pohonov, reset je výlučne lokálny a štandardné PLC nemôže obnoviť pohyb nezávisle od stavu bezpečnostnej funkcie, prevzatie štandardného riadiaceho systému môže zastaviť výrobu alebo narušiť proces.

Nemalo by však spôsobiť pohyb pri otvorenom kryte.

V takom prípade kybernetická analýza preukáže útok.

Posúdenie rizika stroja preukáže mechanické nebezpečenstvo.

Správne navrhnutá bezpečnostná funkcia však medzi nimi preruší cestu.

A teraz druhý variant.

Servisný režim sa volí z úrovne bežného HMI.

Hodnota obmedzenej rýchlosti pochádza zo štandardného PLC.

Vzdialený servisný technik môže vykonať reset.

Ten istý inžiniersky účet umožňuje zmenu programu štandardného riadenia aj konfigurácie safety.

Kópia safety programu nie je naviazaná na konkrétnu verziu stroja.

Po zásahu nikto nekontroluje kontrolný súčet.

Parametre pohonu možno meniť na diaľku.

V tejto architektúre už prevzatie účtu neznamená iba stratu dôvernosti alebo krátky výpadok.

Môže zmeniť podmienky, na ktorých bolo založené zníženie rizika.

Môže viesť k:

• voľbe nesprávneho režimu,
• zmene parametra bezpečného pohybu,
• neoprávnenému resetu,
• nahratiu neschválenej konfigurácie,
• alebo oslabeniu funkcie, ktorá mala zabrániť neočakávanému spusteniu.

A vtedy treba kybernetický scenár prepojiť s konkrétnym scenárom bezpečnosti stroja:

úloha odstránenia zaseknutia → človek v nebezpečnej zóne → neautorizovaná zmena riadiaceho systému alebo ochrannej funkcie → neočakávaný pohyb → pritlačenie.

Zdroj nebezpečenstva sa nezmenil.

Stále ním je mechanická energia stroja.

Nebezpečná zóna sa nezmenila.

Stále sa nachádza vo vnútri bunky.

Možný následok sa nezmenil.

Stále ním je zranenie operátora.

Zmenila sa cesta vedúca k nebezpečnej udalosti.

Nie každá zraniteľnosť patrí do ISO 12100

Toto rozlíšenie je rovnako dôležité.

Predpokladajme, že zraniteľnosť v HMI umožňuje čítať historické výrobné údaje.

Z pohľadu CRA to môže byť podstatný problém.

Môže narušiť dôvernosť údajov.

Môže si vyžadovať aktualizáciu, posúdenie vplyvu, opatrenia voči používateľom a za určitých okolností aj nahlásenie.

Ak však neovplyvňuje správanie stroja, nemení ochranné opatrenie a nemôže viesť k nebezpečnej situácii, nemá zmysel nasilu ju vkladať do posúdenia rizika podľa ISO 12100.

Podobne aj útok, ktorý spôsobí iba nedostupnosť výrobných reportov, môže predstavovať obchodný problém aj problém z hľadiska súladu s CRA.

Nemusí však vytvárať riziko pre obsluhu.

Na druhej strane zdanlivo nevinná možnosť zmeniť jedinú nastavenú hodnotu môže mať malý význam pre dôvernosť údajov, ale zásadný význam pre fyzickú bezpečnosť.

Napríklad vtedy, keď táto hodnota určuje:

• maximálnu rýchlosť osi,
• prítlačnú silu,
• teplotu procesu,
• tlak,
• polohu zastavenia,
• čas otvorenia ventilu,
• alebo prípustný limit pri práci s otvoreným krytom.

Kybernetickú hrozbu teda neklasifikujeme podľa toho, ako technicky znie.

Sledujeme, čo môže v skutočnosti urobiť so strojom.

Nariadenie o strojových zariadeniach si toto prepojenie priamo vyžaduje

Toto prepojenie nie je len dobrou inžinierskou praxou.

Bod 1.2.1 prílohy III k nariadeniu o strojových zariadeniach vyžaduje, aby boli riadiace systémy navrhnuté a vyhotovené tak, aby sa predchádzalo vzniku nebezpečných situácií, a to aj v dôsledku racionálne predvídateľných, škodlivých pokusov tretích osôb.

CRA zároveň uvádza, že jeho základné požiadavky na kybernetickú bezpečnosť môžu podporiť preukázanie zhody okrem iného s požiadavkami 1.1.9 a 1.2.1 nariadenia o strojových zariadeniach.

To sa však nedeje automaticky.

Výrobca musí túto súvislosť preukázať na základe posúdenia rizika. Posudzovanie zhody podľa CRA a posudzovanie zhody podľa nariadenia o strojových zariadeniach naďalej zostávajú samostatnými procesmi.

Teda nestačí pripraviť:

• posúdenie rizika podľa ISO 12100,
• analýzu podľa IEC 62443,
• dve samostatné správy,
• a dúfať, že podobnosť čísel noriem medzi nimi vytvorí auditovateľnú nadväznosť.

Potrebné je vzájomné prepojenie.

Pri každom významnom kybernetickom scenári treba určiť:

1. ktorý prvok alebo funkcia môže byť prevzatá alebo zmenená,
2. aké správanie stroja to môže vyvolať,
3. či toto správanie vedie k nebezpečnej situácii alebo nebezpečnej udalosti,
4. ktorej úlohy a ktorej nebezpečnej zóny sa to týka,
5. aký možný následok bol určený v posúdení podľa ISO 12100,
6. aké opatrenie na zníženie rizika má prerušiť rozvoj scenára,
7. či toto opatrenie zostáva účinné aj po prevzatí napadnutého prvku.

Práve tento posledný bod je najdôležitejší.

Pretože ak útok aj ochranné opatrenie závisia od:

• toho istého riadiaceho systému,
• toho istého účtu,
• tej istej siete,
• tej istej inžinierskej stanice,
• alebo toho istého programu,

tak možno nemáme dve nezávislé vrstvy ochrany.

Máme jednu vrstvu opísanú v dvoch dokumentoch.

Nepotrebujeme teda jednu obrovskú tabuľku s názvom:

„posúdenie rizika safety & cybersecurity“.

Potrebujeme dve správne analýzy vykonané vhodnými metódami a kontrolovaný styčný bod medzi nimi.

ISO 12100 má opísať človeka, úlohu, zdroj nebezpečenstva, zónu, nebezpečnú situáciu, nebezpečnú udalosť a možnú ujmu.

IEC 62443 má pomôcť opísať systém, jeho zóny, komunikačné kanály, aktíva, hrozby, zraniteľnosti, cesty útoku a požadované ochranné opatrenia.

A výrobca musí preukázať, či scenár z druhej analýzy môže spustiť scenár z prvej analýzy alebo odňať účinnosť opatreniu, ktoré ho malo zastaviť.

Kybernetický útok nemusí vytvoriť nové nebezpečenstvo. Stačí, ak otvorí novú cestu k starej nehode.

4. Penetračný test pred FAT-om je fotografia. CRA vyžaduje film

V mnohých projektoch sa kybernetická bezpečnosť objaví dva týždne pred FAT-om.

Objedná sa penetračný test.

Vznikne správa.

Kritické zraniteľnosti sa odstránia, stredné sa akceptujú a dokument sa založí do projektového priečinka.

Stroj je kyberneticky bezpečný.

Do budúceho utorka.

Penetračný test môže byť veľmi hodnotným prvkom overenia. Ukazuje však stav konkrétnej verzie produktu, v konkrétnej konfigurácii a pri použití určených testovacích scenárov.

Neodpovedá na otázku, čo výrobca urobí neskôr.

A CRA sa týka celého životného cyklu produktu. Posúdenie rizika kybernetickej bezpečnosti má ovplyvňovať plánovanie, návrh, vývoj, výrobu, dodanie a údržbu produktu. Po uvedení na trh musí výrobca riešiť zraniteľnosti počas deklarovaného obdobia podpory.

Vráťme sa k stroju na balenie zeleniny.

Stroj prešiel FAT-om.

Penetračný test neodhalil kritické zraniteľnosti.

O osem mesiacov neskôr výrobca servisného routera zverejní informáciu o zraniteľnosti, ktorá umožňuje prevzatie zariadenia.

A práve teraz sa začína skutočná práca.

Ktoré dodané stroje majú tento model routera?

Ktorá verzia firmvéru bola nainštalovaná v každom kuse?

Je vzdialený prístup aktívny?

Dá sa zraniteľnosť zneužiť v reálnej konfigurácii?

Poskytuje prevzatie routera prístup iba k diagnostike, alebo aj k HMI, PLC, pohonom a safety PLC?

Je možný iba odpočet údajov, alebo aj zmena programu či parametrov?

Môže útok ovplyvniť bezpečnostnú funkciu?

Sprístupnil dodávateľ opravu?

Zmení aktualizácia routera certifikáty, komunikačné pravidlá alebo spôsob vytvárania tunela?

Treba po aktualizácii znovu overiť vzdialený servis, komunikáciu a časť bezpečnostných funkcií?

Ktorých zákazníkov je potrebné informovať?

A spĺňa táto situácia kritériá na nahlásenie aktívne zneužívanej zraniteľnosti alebo závažného incidentu?

Správa z pentestu vykonaného pred FAT neodpovie ani na jednu z týchto otázok.

Opisuje stroj, ktorý už neexistuje.

Pretože od času testovania sa zmenili verzie softvéru, konfigurácie, prostredie používateľa aj poznatky o zraniteľnostiach.

Preto výrobca nepotrebuje len test, ale proces:

• identifikácie verzií hardvéru, firmvéru a softvéru v každom dodanom kuse,
• monitorovania informácií o zraniteľnostiach,
• posudzovania ich zneužiteľnosti v reálnej architektúre,
• overovania možných dôsledkov pre proces a bezpečnosť stroja,
• prípravy a testovania aktualizácií,
• informovania používateľov,
• dokumentovania prijatých rozhodnutí,
• spracovania požadovaných hlásení.

Od 11. septembra 2026 majú výrobcovia povinnosť nahlasovať aktívne zneužívané zraniteľnosti a závažné incidenty, ktoré ovplyvňujú bezpečnosť produktov s digitálnymi prvkami. Predbežné varovanie treba odovzdať do 24 hodín a úplné hlásenie do 72 hodín.

To znamená, že po odhalení problému už nebude čas začať pátrať:

„Kto vlastne vyrábal tento router a kde máme zoznam strojov, do ktorých sme ho namontovali?“

IEC 62443-4-1 dobre ukazuje rozdiel medzi jednorazovým zabezpečením produktu a bezpečným cyklom jeho vývoja. Zahŕňa nielen návrh a verifikáciu, ale aj riadenie chýb, opráv a ukončenia životného cyklu produktu.

FAT teda môže uzavrieť etapu projektu.

Neuzatvára životný cyklus produktu.

Neuzatvára obdobie podpory.

Nekončí monitorovanie zraniteľností.

A neznamená to, že konfigurácia zo dňa prevzatia zostane zmrazená na ďalších pätnásť rokov.

Stroj môže dlhý čas baliť zeleninu pre supermarkety.

Výrobca však nemôže jeho kybernetickú bezpečnosť pribaliť k návodu, zataviť do fólie a považovať ju za dodanú raz a navždy.

Pentest môže uzavrieť bod v zozname FAT. CRA otvára proces, ktorý trvá až do konca obdobia podpory produktu.