CRA pro výrobce strojů podle pokynů Komise ze dne 27. července 2026. Co je skutečně nutné zavést?

Po léta se kybernetická bezpečnost stroje dala shrnout do tří kroků: značkový řídicí systém, VPN „protože se to tak dělá“ a klasické „síť si zabezpečí zákazník“. A když k tomu někdo přidal firewall v rozvaděči, bývalo téma považováno za uzavřené — alespoň do chvíle, než se někdo pokusil ověřit, co se stane při skutečném útoku, a ne jen v prezentaci.

Jenže kybernetická bezpečnost neteče po PROFINETu. Komponenty mohou mít certifikáty, prohlášení a v marketingové brožuře napsáno „secure by design“, ale stroj jako celek může být stále předvídatelný způsobem, který s bezpečností nemá nic společného. Stejně jako bezpečnostní relé samo o sobě nezajistí bezpečný systém, pokud ho logika řízení umožňuje obejít, ani „bezpečné“ HMI neřeší problém architektury, integrace, oprávnění, aktualizací a toho, co se stane, když se někdo přestane ptát na svolení.

CRA (Cyber Resilience Act, Nařízení Evropského parlamentu a Rady (EU) 2024/2847) není doplněk pro IT. Je to produktová regulace, která vstupuje do životního cyklu stroje bez ohledu na to, co si o tom myslí oddělení automatizace. Zahrnuje návrh řízení, analýzu rizik, dodavatelský řetězec, konfiguraci, aktualizace i údržbu produktu dlouho poté, co byl podepsán FAT a stroj opustil výrobní halu. A ne, argument „nepřipojujeme ho k internetu“ tímto téma neuzavírá. V praxi stačí servisní notebook, USB flash disk, vzdálená diagnostika „jen na chvíli“ nebo integrace do podnikového systému a hranice mezi izolací a vystavením přestává existovat.

Pokyny Komise z 27. července 2026 samotné nařízení nezměnily, ale účinně zúžily prostor pro výklad, který dříve umožňoval považovat kybernetickou bezpečnost za volitelnou vrstvu. Upřesněna byla mimo jiné hranice produktu, role vzdáleného zpracování, odpovědnost za změny po dodání i to, že „po FAT už to není náš problém“ už není bezpečný předpoklad.

Nejdůležitější změna je ale ještě zásadnější: kybernetický útok přestává být pouze IT událostí a stává se scénářem, který ovlivňuje funkční bezpečnost stroje. Pokud může neoprávněná změna programu způsobit pohyb osy, obejití blokace, změnu parametrů procesu nebo ztrátu bezpečnostní funkce, pak už nemluvíme o „síťovém incidentu“. Mluvíme o potenciálně nekontrolovaném chování stroje — bez ohledu na to, zda příčinou byla chyba konfigurace, zranitelnost softwaru nebo úmyslný zásah.

V tomto kontextu přestává být jednorázový penetrační test před FAT důkazem shody a stává se pouze snímkem stavu systému v konkrétním okamžiku. CRA vyžaduje průběžný přístup: od návrhu přes výrobu a uvedení do provozu až po aktualizace, správu zranitelností, reakci na incidenty a údržbu po deklarovanou dobu podpory.

V praxi to znamená opustit uvažování „hotovo = bezpečné“ ve prospěch „udržované = pod kontrolou“. Bez iluze, že firewall v rozvaděči, VPN a certifikát komponenty téma uzavírají. A bez předpokladu, že kybernetická bezpečnost končí okamžikem podpisu předávacího protokolu.

V tomto článku rozebereme, co pokyny CRA reálně mění pro výrobce, integrátory a modernizátory strojů — aniž bychom celé téma zredukovali na heslo „změňme heslo a přidejme checkbox cybersecurity“.

1. Aby stroj nespadal do CRA, musel by být skoro jen na stykačích

V mnoha projektech se rozsah CRA ověřuje jedinou otázkou:

Bude stroj připojený k internetu?

Nebude.

Takže je věc vyřešená.

Ve schématu je PLC, HMI, několik pohonů, distribuované vstupy a výstupy, ventilový ostrov, bezpečnostní skener a port pro nahrání programu. Řídicí systém komunikuje s panelem přes PROFINET, s pohony si vyměňuje řídicí a stavová slova a snímače předávají data přes IO-Link.

Ale router se SIM kartou tam není.

Jak známo, data se stanou daty teprve tehdy, když opustí výrobní halu.

Jenže CRA se neptá, zda má stroj přístup k internetu.

Ptá se, zda jeho zamýšlené nebo rozumně předvídatelné použití zahrnuje přímé nebo nepřímé, logické nebo fyzické datové spojení se zařízením nebo sítí. Nemusí jít o spojení s cloudem, serverem výrobce ani veřejným internetem. Může probíhat kabelem, bezdrátově, přes programové rozhraní nebo jako součást většího systému.

A teď klíčová otázka: co v typickém stroji skutečně přenáší data?

Čte HMI stavy z PLC a zapisuje nastavení?

Posílá PLC do pohonu řídicí slovo a dostává zpět rychlost, stav a chybový kód?

Přenáší ostrov vstupů a výstupů obraz procesu?

Posílá snímač IO-Link naměřenou hodnotu, identifikátor zařízení a diagnostická data?

Komunikuje safety PLC s moduly přes PROFIsafe?

Nahrává se program, hardwarová konfigurace nebo firmware ze servisního notebooku?

Lze receptury, reporty nebo aktualizace přenášet přes USB?

Jestliže odpověď byť jen jednou zní „ano“, pak se s velkou pravděpodobností jedná o datové spojení.

A nic na tom nemění ani to, že:

• stroj pracuje v lokální síti,
• nemá veřejnou IP adresu,
• port Ethernet se používá jen při uvádění do provozu,
• notebook připojuje výhradně servis,
• komunikace probíhá pouze uvnitř řídicího systému,
• zákazník slíbil, že stroj nikdy nepřipojí k internetu.

CRA nezahrnuje jen použití popsané v návodu jako základní, ale i použití, které lze rozumně předpokládat. Servisní port tedy nepřestává přenášet data jen proto, že je u něj ve schématu dopsáno „SERVICE ONLY“.

Pokyny Komise ze dne 27. července 2026 však zavádějí důležité rozlišení.

Ne každý vodič a ne každý elektrický signál je datovým spojením.

Jestliže signál slouží výhradně k zapnutí, vypnutí nebo napájení určité funkce a nepřenáší digitálně kódovanou informaci, samotná existence dvou elektrických stavů ještě nestačí k tomu, aby byl považován za datové spojení.

Tlačítko, které přivádí napětí na cívku stykače, se nestává digitálním rozhraním jen proto, že jeho stav lze popsat jako nulu nebo jedničku.

Podobně i klasický koncový spínač zapojený v reléově-stykačovém obvodu může obvod pouze přerušit nebo uzavřít. Nepřenáší číslo zařízení, procesní hodnotu, diagnostický kód, verzi firmware ani telegram obsahující několik informací.

Jestliže se ale tentýž stav dostane do inteligentního zařízení, je zakódován, přenesen po sběrnici, propojen s diagnostikou a příjemce jej vyhodnotí jako informaci, vypadá situace už jinak.

Hranice tedy nevede mezi strojem „online“ a „offline“.

Vede mezi běžným řídicím signálem a výměnou digitálně kódovaných informací.

Proto by v praxi stroj, který by měl zůstat mimo působnost CRA výhradně kvůli absenci datového spojení, musel mnohem více připomínat klasický obvod s tlačítky, koncovými spínači, relé a stykači než současný projekt otevíraný v TIA Portal.

Nejde samozřejmě o zákonnou výjimku pro stykače.

Lze postavit jednoduchý stroj s PLC, který po podrobné analýze nesplní kritérium rozsahu. Stejně tak lze do stykačového obvodu přidat digitální regulátor, servisní rozhraní nebo komunikační modul a ocitnout se přesně na druhé straně hranice.

Název komponenty o tom nerozhoduje.

Rozhoduje to, co výrobek skutečně dělá a s čím si vyměňuje data.

Proto je před odpovědí na otázku, zda daný stroj spadá pod CRA, nutné určit:

• kde vede hranice posuzovaného výrobku,
• jaká zařízení a softwarové prvky jsou jeho součástí,
• jaká má fyzická a logická rozhraní,
• jaké informace se přes ně přenášejí,
• která spojení jsou přímá a která probíhají přes větší systém,
• která z nich se vyskytují při běžném provozu, uvádění do provozu, diagnostice, aktualizaci nebo servisu,
• jaké způsoby použití lze rozumně předpokládat, i když by je výrobce raději nepředpokládal.

Dokud na tyto otázky neodpovíme, nevíme, zda stroj zůstává mimo rozsah CRA.

Máme nanejvýš pohodlnou větu:

„Stroj není připojen k internetu.“

Jenže to je odpověď na otázku, kterou CRA nepokládá.

PROFINET není internet. A pro CRA jím vůbec být nemusí.

2. Kybernetická bezpečnost se po PROFINET nešíří

V mnoha projektech začíná téma souladu stroje už ve fázi nákupu.

PLC od uznávaného výrobce.
HMI s aktuálním firmwarem.
Řízený switch.
Průmyslový router s VPN.
Pohony s bezpečnostními funkcemi.
Safety PLC s odpovídajícím certifikátem.

Ke každému zařízení prohlášení o shodě, návod a několik dokumentů s hesly „secure“, „encrypted“ a „defence in depth“.

Ve schématu vypadá všechno profesionálně.

Jenže stále ještě není jasné, zda je kompletní stroj kyberneticky bezpečný.

Protože kybernetická bezpečnost se po PROFINET „nepřenáší“.

Je to trochu jako se zámkem ve dveřích:
můžete mít v každé místnosti velmi dobrý zámek, certifikovaný, testovaný, s krásnou dokumentací a hologramem „secure“, ale to stále nezaručuje bezpečnost, pokud někdo nechal vstupní dveře dokořán otevřené „protože to tak bylo při uvádění do provozu rychlejší“.

A úplně stejně je tomu i tady: komponenty mohou být vzorové, a systém přesto může být… kreativně otevřený.

PLC „nepředává“ bezpečnost do HMI.
Firewall „neopravuje“ logiku aplikace.
Switch „neuspořádává“ přístupy uživatelů.
A skutečnost, že má každý prvek certifikát, ještě neznamená, že celý stroj není jedna velká, zdvořile zdokumentovaná zranitelnost.

PROFINET přenáší data.

Nepřenáší odpovědnost.
A bohužel nepřenáší ani zdravý rozum.

CRA zahrnuje jak kompletní výrobky, tak komponenty uváděné na trh samostatně. To znamená, že řídicí systém, operátorský panel nebo komunikační modul mohou být posuzovány samostatně. Výrobce stroje však stále musí prokázat, že celek funguje bezpečně v reálné konfiguraci u zákazníka — tedy v té verzi, ve které už „určitě nikdo nic nezměnil… že ano?“.

A právě tady se objevuje nejčastější chyba.

Je to přesně tentýž mechanismus, který už léta známe z bezpečnosti strojů.

Světelná závora má PL e.
Safety PLC má SIL 3.
Pohon má STO.

Znamená to, že je automaticky na stejné úrovni i celý stroj?

Je to stejné, jako když každý díl lešení splňuje bezpečnostní normy, ale to samo o sobě ještě nezaručuje, že bude stabilní celá konstrukce.

Ne.

Protože je stále nutné ověřit, jak to všechno funguje dohromady — tedy projít tím ne příliš oblíbeným krokem „systémového myšlení“, který bohužel nemá tlačítko „auto-certify“.

V kybernetické bezpečnosti je to úplně stejné.

Můžete mít „bezpečné“ prvky, ale v praxi:

• operátor vidí a může měnit více dat, než skutečně potřebuje, protože „tak to bylo pohodlnější“,
• jedno servisní heslo funguje na všech strojích, protože „servis přece ví, co dělá“,
• servisní port je dostupný „pro jistotu“, tedy vlastně pro jakoukoli situaci,
• vzdálený přístup pokrývá celou síť, protože někdo kdysi řekl „vždyť je to jen diagnostika“,
• aktualizace lze nahrát bez kontroly, protože „nikdy se nic nerozbilo“,
• zařízení si bez omezení „důvěřují“, protože důvěra je levnější než segmentace,
• a integrace počítá s tím, že nikdo nikdy neudělá chybu, což je — jak ukazuje historie — nejoptimističtější předpoklad v inženýrství.

Každý prvek může být samostatně v pořádku.

Ale systém jako celek z těchto správných prvků dokáže vytvořit něco, co funguje… jen ne nutně tak, jak se předpokládalo.

A to je podstatné: riziko nespočívá v samotných zařízeních, ale v jejich propojení, konfiguraci a v tom legendárním „dočasně ponechaném“ přístupu.

CRA od výrobce stroje vyžaduje něco víc než jen sbírání prohlášení jako trofejí. Vyžaduje ověřit, zda to, co bylo sestaveno z komponent, zůstává bezpečné jako celek — a ne jen že to „hezky vypadá v tabulce shody“.

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

• má každý uživatel jen takový přístup, který skutečně potřebuje, a ne „protože by se to někdy mohlo hodit“,
• je vzdálený přístup omezen na minimum, nebo spíš nastaven na maximum pohodlí,
• nemá servis „plná práva všude“, protože si někdo řekl, že to urychlí práci,
• není síť jednou společnou plochou, protože segmentace „komplikuje projekt“,
• jsou aktualizace řízené, nebo se spíš „nahrají a doufáme“,
• lze rychle určit, které stroje jsou ohrožené, nebo se to bude řešit až „po incidentu“,
• neotevírá porucha jednoho prvku celý systém, protože „tak to vyšlo při integraci“.

To nejsou technické otázky „pro inženýry na složité věci“.

To jsou otázky obchodního rizika: odstávky, náklady, odpovědnost a ten drobný detail, že výroba má prostě fungovat.

Proto nestačí říct:

„všechny komponenty jsou v souladu“

Protože to stále neodpovídá na otázku:

je celý stroj bezpečný při reálném používání, nebo jen v PowerPointu z projektové revize?

Prohlášení dodavatele je důležité.

Ale týká se jen jednoho prvku — toho, který byl právě testován v laboratorních podmínkách, nikoli v prostředí „někde ve výrobní hale, s VPN, USB a časovým tlakem“.

Nepokrývá to, jak byl použit.
Nepokrývá konfiguraci.
Nepokrývá integraci.
Nepokrývá rozhodnutí přijatá „narychlo při uvádění do provozu, protože zákazník čekal“.
Nepokrývá to, co se děje po letech provozu, kdy už si nikdo nepamatuje, proč bylo něco „dočasně otevřené“.

Proto hodnocení nemůže skončit u seznamu zařízení.

Je nutné podívat se na systém jako na celek:

• kdo má přístup a proč (a ne „protože ho měl vždycky“),
• co je skutečně potřeba a co tam jen „zůstalo, protože to ničemu nevadilo“,
• kde mohou data uniknout mimo kontrolu, protože si někdo řekl, že „je to jen diagnostika“,
• co se stane, když někdo použije legitimní přístup nelegitimním způsobem (tedy přesně tak, jak to dělají útoky),
• jak rychle lze reagovat, když se objeví problém, a ne až „po čtvrtletní revizi“.

Dokud na tyto otázky nejsou odpovědi, máme jen sadu velmi solidních komponent.

Ještě nemáme bezpečný stroj.

Shoda komponent automaticky nevytváří shodu systému. Shodu stroje je nutné navrhnout, ověřit a — což je nejtěžší — udržet navzdory pokušení „už na nic nesahat, když to funguje“.

3. Nepřidávejte kybernetický útok jen na seznam nebezpečí. Propojte obě analýzy na správném místě

Na trhu se stroji je formální analýza rizik kybernetické bezpečnosti stále spíše výjimkou než standardní součástí projektu.

Nejčastěji je k dispozici průmyslový router.

Je tam VPN.

Je tam heslo do PLC.

Někdy i spravovatelný switch, který už pak nikdo nespravuje.

V ambicióznější variantě výrobce dostane od dodavatele prezentaci o „defence in depth“ a usoudí, že tím právě dokončil analýzu rizik kybernetické bezpečnosti celého stroje.

Nedokončil.

Jen pořídil několik technických opatření.

To ještě není analýza.

Proto nemá smysl popisovat problém tak, jako by v každém projektu vznikala dvě profesionální hodnocení — jedno podle ISO 12100, druhé zaměřené na kybernetickou bezpečnost — která jen náhodou nebyla vzájemně propojena.

Nejčastěji vznikne jen jedna.

Posouzení rizik stroje.

A analýza kybernetické bezpečnosti produktu nevznikne vůbec.

Posouzení rizik stroje podle ISO 12100 nespočívá v tom, že se do tabulky zapíše:

porucha snímače → neočekávaný pohyb → rozdrcení.

To může být část konkrétního scénáře, ale není to výchozí bod.

Nejprve je třeba stanovit meze stroje.

Jaký je jeho zamýšlený účel?

Jaké jsou fáze jeho životního cyklu?

Kdo jej bude používat?

Jaké činnosti se budou provádět při přepravě, montáži, uvedení do provozu, výrobě, seřizování, čištění, odstraňování zaseknutí, údržbě, diagnostice a demontáži?

V jakých režimech může stroj pracovat?

Kde se při každé z těchto operací nachází člověk?

Které části stroje jsou přitom pod napětím, tlakem, zatížením nebo v pohybu?

Jaké použití není v souladu s návodem, ale je stále rozumně předvídatelné?

Teprve potom se pro konkrétní úkol nebo operaci identifikují mimo jiné:

• zdroj nebezpečí,
• druh nebezpečí,
• nebezpečný prostor,
• ohrožená osoba,
• nebezpečná situace,
• nebezpečná událost, pokud se v daném scénáři vyskytuje,
• možné následky a druh újmy.

Takto vypadá analýza rizik stroje.

Nezačínáme od komponenty.

Začínáme od člověka, který vykonává konkrétní úkol u stroje nacházejícího se v určitém stavu. ISO 12100 stanovuje právě takovou metodiku identifikace nebezpečí a odhadu a hodnocení rizik v příslušných fázích životního cyklu stroje.

Vezměme si jednoduchý příklad.

Operátor odstraňuje zaseknutý díl z prostoru paletizační buňky.

Máme tedy:

Úkol: odstranění zaseknutí.

Fáze používání: provoz, zásah po zastavení procesu.

Pracovní režim: ruční nebo servisní.

Ohrožená osoba: operátor nebo pracovník údržby.

Nebezpečný prostor: vnitřek buňky, zejména prostor mezi chapadlem, dílem a konstrukcí stroje.

Zdroj nebezpečí: mechanická energie robota, lineární osy nebo pneumatického chapadla.

Nebezpečná situace: člověk se nachází v prostoru, zatímco provedení pohybu je stále možné.

Nebezpečná událost: neočekávaný pohyb osy, sevření chapadla nebo uvolnění akumulované energie.

Možný následek: náraz, rozdrcení, zlomenina nebo amputace.

Teprve nyní lze hodnotit riziko a určovat opatření k jeho snížení.

Může být potřebné blokování krytu.

Může být potřebné bezpečné zastavení.

Může být nutné zabránit neočekávanému spuštění.

Možná bude třeba odvést pneumatickou energii.

Možná se pohyb v ručním režimu může provádět pouze s použitím schvalovacího zařízení a při bezpečně omezené rychlosti.

To je stále klasické posouzení rizik stroje.

Kde se objevuje kybernetická bezpečnost?

Ne jako nová položka vedle mechanického, elektrického a tepelného nebezpečí.

„Hacker“ není zdrojem mechanického nebezpečí

Dopsání položky do tabulky ISO 12100:

Nebezpečí: kybernetický útok

toho mnoho nepřinese.

Kybernetický útok není rotující hřídel, ostrá hrana, vysoká teplota ani pneumatická energie.

Není to ani samostatný nebezpečný prostor.

Operátor neutrpí rozdrcení kvůli zranitelnosti CVE.

Utrpí je kvůli prvku stroje, který vykonal pohyb ve chvíli, kdy se člověk nacházel na nesprávném místě.

Kybernetický útok však může změnit stav řídicího systému, data, program, konfiguraci nebo způsob fungování ochranného opatření.

Může se tedy stát:

• příčinou nebezpečné události,
• další cestou vedoucí k nebezpečné situaci,
• příčinou ztráty účinnosti opatření ke snížení rizika,
• nebo způsobem, jak obejít předpoklady přijaté při návrhu bezpečnostní funkce.

A právě to je správný bod styku.

Ne seznam nebezpečí.

Ale chování stroje.

Analýza kybernetické bezpečnosti by měla vzniknout samostatně

U stroje nebo systému automatizace bude mít analýza kybernetické bezpečnosti jinou strukturu než posouzení rizik podle ISO 12100.

Nejpřirozenější rámec pro systém průmyslové automatizace poskytuje IEC 62443-3-2.

Norma mimo jiné vyžaduje:

• definování systému, který je předmětem analýzy, tedy SUC,
• rozdělení systému na zóny a komunikační kanály,
• posouzení rizik pro jednotlivé zóny a kanály,
• stanovení cílových úrovní bezpečnosti SL-T,
• zdokumentování bezpečnostních požadavků.

To je zcela jiný výchozí bod než v ISO 12100.

V IEC 62443 se mimo jiné ptáme:

Co přesně patří do analyzovaného systému?

Jaká aktiva je třeba chránit?

Jaká zařízení, aplikace a rozhraní se v systému nacházejí?

Které prvky by měly patřit do stejné zóny?

Jak probíhá komunikace mezi zónami?

Kdo může získat přístup?

Odkud?

Pomocí jakého rozhraní?

Jaké zranitelnosti lze zneužít?

Jaká data, funkce nebo komponenty mohou být změněny?

Jakou cestou se může útočník dostat od servisního routeru k PLC, HMI, pohonu nebo inženýrské stanici?

Jaké důsledky bude mít ztráta důvěrnosti, integrity nebo dostupnosti?

Jaká ochranná opatření jsou potřebná?

Pro proces bezpečného vývoje produktu i pro požadavky na samotné komponenty budou důležité také další části této řady, zejména IEC 62443-4-1 a IEC 62443-4-2. IEC 62443-3-3 naopak systematicky vymezuje technické požadavky na bezpečnost na úrovni systému.

CRA dnes výrobci neukládá, aby na obálku analýzy napsal „zpracováno podle IEC 62443“.

IEC 62443 také nenahrazuje prokázání shody s požadavky CRA.

Pro průmyslový automatizační systém je to však výrazně logičtější referenční rámec než snaha doplnit do tabulky ISO 12100 několik hackerských scénářů.

Protože obě metodiky odpovídají na odlišné otázky.

ISO 12100:

Při jakém úkolu, kde, od jakého zdroje a v důsledku jaké události může člověk utrpět újmu?

IEC 62443:

Kdo, jakou cestou a s využitím jaké zranitelnosti může ovlivnit systém, jeho data nebo funkce?

Teprve potom je třeba ověřit, zda odpověď z druhé analýzy mění scénář z té první.

Stejný scénář, dvě různé analýzy

Vraťme se k operátorovi, který odstraňuje zaseknutý díl.

Analýza ISO 12100 ukázala, že člověk vstupuje do prostoru, kde může být rozdrcen pohybem robota nebo chapadla.

Opatřením ke snížení rizika je blokovaný kryt, funkce bezpečného zastavení a místní reset umístěný mimo nebezpečnou zónu.

Nyní provedeme analýzu kybernetické bezpečnosti systému.

Identifikujeme:

• router používaný pro vzdálený servis,
• servisní účet,
• inženýrský notebook,
• HMI,
• standardní PLC,
• safety PLC,
• pohony,
• programovací rozhraní,
• síť PROFINET a komunikaci PROFIsafe,
• mechanismy nahrávání programu a konfigurace.

Posuzujeme scénář:

Převzetí servisního účtu umožní vzdálený přístup ke standardnímu PLC a odeslání příkazu k pohybu v době, kdy je člověk uvnitř buňky.

Vede tento scénář k nebezpečné události?

Na to nelze odpovědět jen na základě samotného převzetí PLC.

Je nutné prověřit architekturu bezpečnostních funkcí.

Jestliže otevření krytu monitoruje safety PLC, funkce bezpečně odpojí moment pohonů, reset je pouze místní a standardní PLC nemůže obnovit pohyb nezávisle na stavu bezpečnostní funkce, pak převzetí standardního řídicího systému může zastavit výrobu nebo narušit proces.

Nemělo by však způsobit pohyb při otevřeném krytu.

V takovém případě kybernetická analýza prokáže útok.

Posouzení rizik stroje podle ISO 12100 prokáže mechanické nebezpečí.

Správně navržená bezpečnostní funkce však mezi nimi přeruší vazbu.

A teď druhá varianta.

Servisní režim se volí z běžného HMI.

Hodnota omezené rychlosti pochází ze standardního PLC.

Vzdálený servisní technik může provést reset.

Tentýž inženýrský účet umožňuje změnu programu standardního PLC i konfigurace safety.

Kopie safety programu není svázána s konkrétní verzí stroje.

Po zásahu nikdo nekontroluje kontrolní součet.

Parametry pohonu lze měnit vzdáleně.

V této architektuře už převzetí účtu neznamená pouze ztrátu důvěrnosti nebo krátkou odstávku.

Může změnit podmínky, na nichž bylo založeno snížení rizika.

Může vést k:

• volbě nesprávného režimu,
• změně parametru bezpečného pohybu,
• neoprávněnému resetu,
• nahrání neschválené konfigurace,
• nebo oslabení funkce, která měla zabránit neočekávanému spuštění.

A tehdy je nutné kybernetický scénář propojit s konkrétním scénářem bezpečnosti stroje:

úkol odstranění zaseknutí → člověk v nebezpečné zóně → neoprávněná změna řídicího systému nebo ochranné funkce → neočekávaný pohyb → rozdrcení.

Zdroj nebezpečí se nezměnil.

Nadále jím zůstává mechanická energie stroje.

Nebezpečná zóna se nezměnila.

Stále se nachází uvnitř buňky.

Možný následek se nezměnil.

Stále jím je zranění operátora.

Změnila se cesta vedoucí k nebezpečné události.

Ne každá zranitelnost patří do ISO 12100

Toto rozlišení je stejně důležité.

Předpokládejme, že zranitelnost v HMI umožňuje číst historická výrobní data.

To může být významný problém z pohledu CRA.

Může dojít k narušení důvěrnosti dat.

Může to vyžadovat aktualizaci, posouzení dopadu, kroky vůči uživatelům a za určitých okolností také oznámení.

Pokud to ale neovlivňuje chování stroje, nemění ochranné opatření a nemůže to vést k nebezpečné situaci, nemá smysl to násilně vkládat do posouzení rizik podle ISO 12100.

Podobně může útok, který způsobí pouze nedostupnost výrobních reportů, představovat obchodní problém i problém z hlediska souladu s CRA.

Nemusí však vytvářet riziko pro obsluhu.

Na druhou stranu může zdánlivě nevinná možnost změnit jedinou nastavenou hodnotu mít malý význam pro důvěrnost dat, ale zásadní význam pro fyzickou bezpečnost.

Například tehdy, když tato hodnota určuje:

• maximální rychlost osy,
• přítlačnou sílu,
• teplotu procesu,
• tlak,
• polohu zastavení,
• dobu otevření ventilu,
• nebo přípustný limit při práci s otevřeným krytem.

Kybernetickou hrozbu tedy neklasifikujeme podle toho, jak technicky zní.

Sledujeme, co může se strojem skutečně udělat.

Nařízení o strojních zařízeních tento most vyžaduje

Toto propojení není jen dobrou inženýrskou praxí.

Bod 1.2.1 přílohy III nařízení o strojních zařízeních vyžaduje, aby řídicí systémy byly navrženy a provedeny tak, aby předcházely vzniku nebezpečných situací, a to i v důsledku rozumně předvídatelných škodlivých pokusů třetích stran.

CRA naopak uvádí, že jeho základní požadavky na kybernetickou bezpečnost mohou podpořit prokázání shody mimo jiné s požadavky 1.1.9 a 1.2.1 nařízení o strojních zařízeních.

Ale neděje se to automaticky.

Výrobce musí tuto souvislost prokázat na základě posouzení rizik. Posouzení shody podle CRA a posouzení shody podle nařízení o strojních zařízeních zůstávají i nadále oddělenými procesy.

Nestačí tedy připravit:

• posouzení rizik podle ISO 12100,
• analýzu podle IEC 62443,
• dvě samostatné zprávy,
• a spoléhat na to, že podobnost čísel norem mezi nimi vytvoří auditní stopu.

Je potřeba vytvořit vazbu.

Pro každý významný kybernetický scénář je třeba určit:

1. který prvek nebo funkce mohou být převzaty nebo změněny,
2. jaké chování stroje to může vyvolat,
3. zda toto chování vede k nebezpečné situaci nebo nebezpečné události,
4. kterého úkolu a které nebezpečné zóny se týká,
5. jaký možný následek byl uveden v posouzení podle ISO 12100,
6. které opatření ke snížení rizika má přerušit rozvoj scénáře,
7. zda toto opatření zůstává účinné i po převzetí napadeného prvku.

Tento poslední bod je nejdůležitější.

Protože pokud útok i ochranné opatření závisejí na:

• stejném řídicím systému,
• stejném účtu,
• stejné síti,
• stejné inženýrské stanici,
• nebo stejném programu,

pak možná nemáme dvě nezávislé vrstvy ochrany.

Máme jednu vrstvu popsanou ve dvou dokumentech.

Nepotřebujeme tedy jednu obrovskou tabulku s názvem:

„posouzení rizik safety & cybersecurity“.

Potřebujeme dvě správně provedené analýzy, zpracované vhodnými metodami, a řízený bod styku mezi nimi.

ISO 12100 má popsat člověka, úkol, zdroj nebezpečí, zónu, nebezpečnou situaci, nebezpečnou událost a možnou újmu.

IEC 62443 má pomoci popsat systém, jeho zóny, komunikační kanály, aktiva, hrozby, zranitelnosti, cesty útoku a požadovaná ochranná opatření.

A výrobce musí prokázat, zda scénář z druhé analýzy může spustit scénář z první analýzy nebo odebrat účinnost opatření, které ho mělo zastavit.

Kybernetický útok nemusí vytvářet nové nebezpečí. Stačí, když otevře novou cestu ke staré nehodě.

4. Penetrační test před FAT je fotografie. CRA vyžaduje film

V mnoha projektech se kybernetická bezpečnost řeší dva týdny před FAT.

Objedná se penetrační test.

Vznikne zpráva.

Kritické zranitelnosti se opraví, střední se akceptují a dokument se uloží do projektové složky.

Stroj je kyberneticky bezpečný.

Do příštího úterý.

Penetrační test může být velmi hodnotným prvkem ověření. Ukazuje však stav konkrétní verze produktu, v konkrétní konfiguraci a při použití určitých testovacích scénářů.

Neodpovídá na otázku, co výrobce udělá později.

A CRA se týká celého životního cyklu produktu. Posouzení rizik kybernetické bezpečnosti má ovlivňovat plánování, návrh, vývoj, výrobu, dodání i údržbu produktu. Po uvedení na trh musí výrobce po deklarovanou dobu podpory řešit zranitelnosti.

Vraťme se k balicímu stroji na zeleninu.

Stroj prošel FAT.

Penetrační test neodhalil žádné kritické zranitelnosti.

O osm měsíců později výrobce servisního routeru zveřejní informaci o zranitelnosti, která umožňuje převzetí zařízení.

A teď začíná skutečná práce.

Které dodané stroje mají tento model routeru?

Která verze firmware’u byla nainstalována v každém kusu?

Je vzdálený přístup aktivní?

Lze zranitelnost zneužít v reálné konfiguraci?

Dává převzetí routeru přístup pouze k diagnostice, nebo také k HMI, PLC, pohonům a safety PLC?

Je možný jen odečet dat, nebo také změna programu či parametrů?

Může útok ovlivnit bezpečnostní funkci?

Zpřístupnil dodavatel opravu?

Změní aktualizace routeru certifikáty, komunikační pravidla nebo způsob navazování tunelu?

Je po aktualizaci nutné znovu ověřit vzdálený servis, komunikaci a část bezpečnostních funkcí?

Které zákazníky je třeba informovat?

A splňuje tato situace kritéria pro oznámení aktivně zneužívané zranitelnosti nebo závažného incidentu?

Zpráva z pentestu provedeného před FAT na žádnou z těchto otázek neodpoví.

Popisuje stroj, který už neexistuje.

Od doby testování se totiž změnily verze softwaru, konfigurace, prostředí uživatele i znalosti o zranitelnostech.

Výrobce proto nepotřebuje jen test, ale celý proces:

• identifikace verzí hardwaru, firmwaru a softwaru v každém dodaném kusu,
• sledování informací o zranitelnostech,
• posouzení jejich zneužitelnosti v reálné architektuře,
• ověření možných dopadů na proces a bezpečnost stroje,
• příprava a testování aktualizací,
• informování uživatelů,
• dokumentování přijatých rozhodnutí,
• vyřizování požadovaných oznámení.

Od 11. září 2026 mají výrobci povinnost hlásit aktivně zneužívané zranitelnosti a závažné incidenty ovlivňující bezpečnost produktů s digitálními prvky. Předběžné varování je nutné předat do 24 hodin a úplné oznámení do 72 hodin.

To znamená, že po zjištění problému už nebude čas začít pátrat:

„Kdo vlastně vyráběl ten router a kde máme seznam strojů, do kterých jsme ho namontovali?“

IEC 62443-4-1 dobře ukazuje rozdíl mezi jednorázovým zabezpečením produktu a bezpečným cyklem jeho vývoje. Zahrnuje nejen návrh a ověřování, ale také řízení vad, oprav a ukončení životního cyklu produktu.

FAT tedy může uzavřít etapu projektu.

Neuzavírá životní cyklus produktu.

Neuzavírá dobu podpory.

Neukončuje sledování zranitelností.

A neznamená to, že konfigurace ze dne přejímky zůstane zmrazená na dalších patnáct let.

Stroj může po dlouhou dobu balit zeleninu pro supermarkety.

Výrobce ale nemůže jeho kybernetickou bezpečnost zabalit spolu s návodem, zatavit do fólie a považovat ji za jednou provždy dodanou.

Pentest může uzavřít položku na seznamu FAT. CRA otevírá proces, který trvá až do konce doby podpory produktu.