CRA dla producentów maszyn po wytycznych Komisji z 27 lipca 2026 r. Co naprawdę trzeba wdrożyć?

Przez lata cyberbezpieczeństwo maszyny dało się opisać w trzech krokach: markowy sterownik, VPN „bo tak się robi” i klasyczne „klient zabezpieczy sieć”. A jak ktoś dorzucił firewall w szafie, to temat bywał uznawany za domknięty — przynajmniej do momentu, aż ktoś spróbował sprawdzić, co się stanie po realnym ataku, a nie w prezentacji.

Tyle że cyberbezpieczeństwo nie płynie po PROFINET. Komponenty mogą mieć certyfikaty, deklaracje i „secure by design” w folderze marketingowym, ale maszyna jako całość nadal może być przewidywalna w sposób, który nie ma nic wspólnego z bezpieczeństwem. Tak jak przekaźnik bezpieczeństwa nie czyni systemu bezpiecznym, jeśli logika sterowania pozwala go obejść, tak „bezpieczne” HMI nie rozwiązuje problemu architektury, integracji, uprawnień, aktualizacji i tego, co się dzieje, gdy ktoś przestaje pytać o zgodę.

CRA (Cyber Resilience Act, Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847) nie jest dodatkiem dla IT. To regulacja produktowa, która wchodzi w cykl życia maszyny bez pytania o zgodę działu automatyki. Obejmuje projekt sterowania, analizę ryzyka, łańcuch dostaw, konfigurację, aktualizacje, a także utrzymanie produktu długo po tym, jak FAT został podpisany i maszyna opuściła halę. I nie, argument „nie wystawiamy jej do internetu” nie zamyka tematu. W praktyce wystarczy serwisowy laptop, pendrive, zdalna diagnostyka „na chwilę” albo integracja z systemem zakładowym, żeby granica między izolacją a ekspozycją przestała istnieć.

Wytyczne Komisji z 27 lipca 2026 r. nie zmieniły samego rozporządzenia, ale skutecznie ograniczyły przestrzeń interpretacyjną, która wcześniej pozwalała traktować cyberbezpieczeństwo jako warstwę opcjonalną. Doprecyzowano m.in. granicę produktu, rolę zdalnego przetwarzania, odpowiedzialność za zmiany po dostawie oraz to, że „to nie nasz problem po FAT” nie jest już bezpiecznym założeniem.

Najważniejsza zmiana jest jednak bardziej fundamentalna: cyberatak przestaje być wyłącznie zdarzeniem IT, a staje się scenariuszem oddziałującym na bezpieczeństwo funkcjonalne maszyny. Jeśli nieautoryzowana zmiana programu może spowodować ruch osi, obejście blokady, zmianę parametrów procesu albo utratę funkcji bezpieczeństwa, to nie mówimy już o „incydencie sieciowym”. Mówimy o potencjalnie niekontrolowanym zachowaniu maszyny — niezależnie od tego, czy źródłem był błąd konfiguracji, luka w oprogramowaniu czy celowa ingerencja.

W tym kontekście jednorazowy pentest przed FAT-em przestaje być dowodem zgodności, a staje się jedynie migawką stanu systemu w konkretnym momencie. CRA wymaga podejścia ciągłego: od projektu, przez produkcję i uruchomienie, aż po aktualizacje, zarządzanie podatnościami, reakcję na incydenty i utrzymanie przez zadeklarowany okres wsparcia.

W praktyce oznacza to odejście od myślenia „zrobione = bezpieczne” na rzecz „utrzymywane = kontrolowane”. Bez iluzji, że firewall w szafie, VPN i certyfikat komponentu zamykają temat. I bez założenia, że cyberbezpieczeństwo kończy się w momencie podpisania protokołu odbioru.

W tym artykule rozbieramy, co wytyczne CRA realnie zmieniają dla producentów, integratorów i modernizatorów maszyn — bez redukowania całego tematu do hasła „zmieńmy hasło i dodajmy checkbox cybersecurity”.

1. Żeby maszyna nie weszła w CRA, musiałaby być niemal na stycznikach

W wielu projektach zakres CRA sprawdza się jednym pytaniem:

Czy maszyna będzie podłączona do internetu?

Nie będzie.

Czyli temat zamknięty.

Na schemacie jest PLC, HMI, kilka napędów, rozproszone wejścia i wyjścia, wyspa zaworowa, skaner bezpieczeństwa oraz port do wgrywania programu. Sterownik komunikuje się z panelem po PROFINET, z napędami wymienia słowa sterujące i statusowe, a czujniki przekazują dane przez IO-Link.

Ale routera z kartą SIM nie ma.

Jak wiadomo, dane stają się danymi dopiero wtedy, gdy opuszczą halę produkcyjną.

Tyle że CRA nie pyta, czy maszyna ma dostęp do internetu.

Pyta, czy jej przeznaczenie albo racjonalnie przewidywalne użycie obejmuje bezpośrednie lub pośrednie, logiczne albo fizyczne połączenie danych z urządzeniem lub siecią. Nie musi to być połączenie z chmurą, serwerem producenta ani publicznym internetem. Może przebiegać przewodem, przez fale radiowe, interfejs programowy albo jako część większego systemu.

I teraz kluczowe pytanie: co w typowej maszynie rzeczywiście przesyła dane?

Czy HMI odczytuje stany z PLC i zapisuje nastawy?

Czy PLC wysyła do napędu słowo sterujące, a w odpowiedzi otrzymuje prędkość, status i kod błędu?

Czy wyspa wejść i wyjść przekazuje obraz procesu?

Czy czujnik IO-Link wysyła wartość pomiarową, identyfikator urządzenia i dane diagnostyczne?

Czy safety PLC komunikuje się z modułami przez PROFIsafe?

Czy program, konfiguracja sprzętowa albo firmware są wgrywane z laptopa serwisowego?

Czy receptury, raporty lub aktualizacje można przenieść przez USB?

Jeżeli odpowiedź choć raz brzmi „tak”, to prawdopodobnie mamy do czynienia z połączeniem danych.

I nie zmienia tego fakt, że:

• maszyna pracuje w sieci lokalnej,
• nie ma publicznego adresu IP,
• port Ethernet jest używany tylko podczas uruchomienia,
• laptop podłącza wyłącznie serwis,
• komunikacja odbywa się tylko wewnątrz układu sterowania,
• klient obiecał, że nigdy nie podłączy maszyny do internetu.

CRA obejmuje nie tylko użycie opisane w instrukcji jako podstawowe, ale również użycie racjonalnie przewidywalne. Port serwisowy nie przestaje więc przesyłać danych tylko dlatego, że na schemacie dopisano przy nim „SERVICE ONLY”.

Wytyczne Komisji z 27 lipca 2026 r. wprowadzają jednak ważne rozróżnienie.

Nie każdy przewód i nie każdy sygnał elektryczny jest połączeniem danych.

Jeżeli sygnał służy wyłącznie do załączenia, wyłączenia albo zasilenia określonej funkcji i nie przekazuje cyfrowo zakodowanej informacji, samo występowanie dwóch stanów elektrycznych nie wystarcza jeszcze do uznania go za połączenie danych.

Przycisk podający napięcie na cewkę stycznika nie staje się interfejsem cyfrowym tylko dlatego, że jego stan można opisać jako zero albo jeden.

Podobnie klasyczna krańcówka włączona w obwód przekaźnikowo-stycznikowy może jedynie przerwać albo zamknąć obwód. Nie przesyła numeru urządzenia, wartości procesowej, kodu diagnostycznego, wersji firmware’u ani telegramu zawierającego kilka informacji.

Ale gdy ten sam stan trafia do inteligentnego urządzenia, zostaje zakodowany, przesłany przez magistralę, powiązany z diagnostyką i zinterpretowany przez odbiornik jako informacja, sytuacja wygląda już inaczej.

Granica nie przebiega więc między maszyną „online” i „offline”.

Przebiega między zwykłym sygnałem sterującym a wymianą cyfrowo zakodowanej informacji.

Dlatego w praktyce maszyna, która miałaby pozostać poza CRA wyłącznie z powodu braku połączenia danych, musiałaby bardziej przypominać klasyczny układ z przyciskami, krańcówkami, przekaźnikami i stycznikami niż współczesny projekt otwierany w TIA Portal.

Nie jest to oczywiście ustawowe wyłączenie dla styczników.

Można zbudować prostą maszynę z PLC, która po szczegółowej analizie nie spełni kryterium zakresu. Można też dodać do układu stycznikowego cyfrowy regulator, interfejs serwisowy albo moduł komunikacyjny i znaleźć się dokładnie po drugiej stronie granicy.

Nazwa komponentu nie rozstrzyga sprawy.

Rozstrzyga to, co produkt faktycznie robi i z czym wymienia dane.

Dlatego przed odpowiedzią na pytanie, czy dana maszyna podlega CRA, trzeba ustalić:

• gdzie przebiega granica ocenianego produktu,
• jakie urządzenia i elementy oprogramowania wchodzą w jego skład,
• jakie interfejsy fizyczne i logiczne posiada,
• jakie informacje są przez nie przesyłane,
• które połączenia są bezpośrednie, a które odbywają się przez większy system,
• które z nich występują podczas normalnej pracy, uruchomienia, diagnostyki, aktualizacji albo serwisu,
• jakie sposoby użycia są racjonalnie przewidywalne, nawet jeśli producent wolałby ich nie przewidywać.

Dopóki nie odpowiemy na te pytania, nie wiemy, czy maszyna pozostaje poza zakresem CRA.

Mamy co najwyżej wygodne zdanie:

„Maszyna nie jest podłączona do internetu”.

Tyle że jest to odpowiedź na pytanie, którego CRA nie zadaje.

PROFINET nie jest internetem. Dla CRA wcale nie musi nim być.

2. Cyberbezpieczeństwo nie rozchodzi się po PROFINET

W wielu projektach temat zgodności maszyny zaczyna się już na etapie zakupów.

PLC od uznanego producenta.
HMI z aktualnym firmware’em.
Zarządzalny switch.
Router przemysłowy z VPN.
Napędy z funkcjami bezpieczeństwa.
Safety PLC z odpowiednim certyfikatem.

Do każdego urządzenia deklaracja zgodności, instrukcja i kilka dokumentów z hasłami „secure”, „encrypted” oraz „defence in depth”.

Na schemacie wszystko wygląda profesjonalnie.

Tyle że nadal nie wiadomo, czy kompletna maszyna jest cyberbezpieczna.

Bo cyberbezpieczeństwo nie „przechodzi” po PROFINET.

To trochę jak z zamkiem w drzwiach:
możesz mieć bardzo dobry zamek w każdym pokoju, certyfikowany, testowany, z piękną dokumentacją i hologramem „secure”, ale to nadal nie gwarantuje bezpieczeństwa, jeśli ktoś zostawił drzwi wejściowe szeroko otwarte „bo tak było szybciej na uruchomieniu”.

I dokładnie tak samo jest tutaj: komponenty mogą być wzorcowe, a system i tak może być… kreatywnie otwarty.

PLC nie „przekazuje” bezpieczeństwa do HMI.
Firewall nie „naprawia” logiki aplikacji.
Switch nie „porządkuje” dostępu użytkowników.
A fakt, że każdy element ma certyfikat, nie oznacza jeszcze, że cała maszyna nie jest jedną wielką, uprzejmie udokumentowaną luką.

PROFINET przesyła dane.

Nie przesyła odpowiedzialności.
I niestety nie przesyła też zdrowego rozsądku.

CRA obejmuje zarówno kompletne produkty, jak i komponenty wprowadzane do obrotu oddzielnie. Oznacza to, że sterownik, panel operatorski czy moduł komunikacyjny mogą być oceniane osobno. Ale producent maszyny nadal musi wykazać, że całość działa bezpiecznie w realnej konfiguracji u klienta — czyli w tej wersji, w której ktoś „na pewno nic już nie zmienił… prawda?”.

I tu pojawia się najczęstszy błąd.

To dokładnie ten sam mechanizm, który od lat znamy z bezpieczeństwa maszyn.

Kurtyna ma PL e.
Safety PLC ma SIL 3.
Napęd ma STO.

Czy to oznacza, że cała maszyna jest automatycznie na tym poziomie?

To tak jak fakt, że każdy element rusztowania spełnia normy bezpieczeństwa, nie gwarantuje jeszcze, że cała konstrukcja będzie stabilna.

Nie.

Bo nadal trzeba sprawdzić, jak to wszystko działa razem — czyli ten mało popularny etap „myślenia systemowego”, który niestety nie ma przycisku „auto-certify”.

W cyberbezpieczeństwie jest identycznie.

Możesz mieć „bezpieczne” elementy, ale w praktyce:

• operator widzi i może zmieniać więcej danych niż potrzebuje, bo „tak było wygodniej”,
• jedno hasło serwisowe działa na wszystkich maszynach, bo „serwis i tak wie co robi”,
• port serwisowy jest dostępny „na wszelki wypadek”, czyli na każdy wypadek,
• zdalny dostęp obejmuje całą sieć, bo ktoś kiedyś powiedział „przecież to tylko diagnostyka”,
• aktualizacje można wgrać bez kontroli, bo „nigdy nic się nie zepsuło”,
• urządzenia „ufają sobie” bez ograniczeń, bo zaufanie jest tańsze niż segmentacja,
• a integracja zakłada, że nikt nigdy nie popełni błędu, co jest — jak pokazuje historia — najbardziej optymistycznym założeniem w inżynierii.

Każdy element osobno może być poprawny.

Ale system jako całość potrafi z tych poprawnych elementów zbudować coś, co działa… tylko niekoniecznie tak, jak zakładano.

I to jest ważne: ryzyko nie siedzi w urządzeniach, tylko w ich połączeniu, konfiguracji i w legendarnym „tymczasowo zostawionym” dostępie.

CRA wymaga od producenta maszyny czegoś więcej niż kolekcjonowania deklaracji jak trofeów. Wymaga sprawdzenia, czy to, co zostało złożone z komponentów, nadal jest bezpieczne jako całość — a nie tylko „ładnie wygląda w tabelce zgodności”.

W praktyce oznacza to proste, biznesowe pytania:

• czy każdy użytkownik ma tylko taki dostęp, jaki rzeczywiście jest mu potrzebny, a nie „bo może kiedyś się przyda”,
• czy zdalny dostęp jest ograniczony do minimum, czy raczej do maksimum wygody,
• czy serwis nie ma „pełnych praw wszędzie”, bo ktoś uznał, że to przyspiesza życie,
• czy sieć nie jest jedną wspólną płaszczyzną, bo segmentacja „komplikuje projekt”,
• czy aktualizacje są kontrolowane, czy raczej „wrzucane i modlimy się”,
• czy da się szybko zidentyfikować, które maszyny są narażone, czy raczej „sprawdzimy po incydencie”,
• czy awaria jednego elementu nie otwiera całego systemu, bo „tak wyszło w integracji”.

To nie są pytania techniczne „dla inżynierów od trudnych rzeczy”.

To są pytania o ryzyko biznesowe: przestoje, koszty, odpowiedzialność i ten drobny szczegół, że produkcja jednak ma działać.

Dlatego nie wystarczy powiedzieć:

„wszystkie komponenty są zgodne”

Bo to nadal nie odpowiada na pytanie:

czy cała maszyna jest bezpieczna w realnym użyciu, czy tylko w PowerPoincie z przeglądu projektu?

Deklaracja dostawcy jest ważna.

Ale dotyczy tylko jednego elementu — tego, który akurat był testowany w warunkach laboratoryjnych, a nie w środowisku „gdzieś na hali, z VPN-em, USB i presją czasu”.

Nie obejmuje tego, jak został użyty.
Nie obejmuje konfiguracji.
Nie obejmuje integracji.
Nie obejmuje decyzji podjętych „na szybko podczas uruchomienia, bo klient czekał”.
Nie obejmuje tego, co dzieje się po latach eksploatacji, kiedy nikt już nie pamięta, dlaczego coś było „tymczasowo otwarte”.

Dlatego ocena nie może kończyć się na liście urządzeń.

Trzeba spojrzeć na system jako całość:

• kto ma dostęp i dlaczego (a nie „bo zawsze miał”),
• co jest naprawdę potrzebne, a co tylko „zostawiono, bo nie przeszkadzało”,
• gdzie dane mogą wypłynąć poza kontrolę, bo ktoś uznał, że „to tylko diagnostyka”,
• co się stanie, gdy ktoś użyje legalnego dostępu w nielegalny sposób (czyli dokładnie tak, jak robią to ataki),
• jak szybko da się zareagować, gdy pojawi się problem, a nie „po kwartalnym przeglądzie”.

Dopóki nie ma odpowiedzi na te pytania, mamy tylko zestaw bardzo porządnych komponentów.

Nie mamy jeszcze bezpiecznej maszyny.

Zgodność komponentów nie tworzy automatycznie zgodności systemu. Zgodność maszyny trzeba zaprojektować, sprawdzić i — co najtrudniejsze — utrzymać mimo pokusy, żeby „już nic nie ruszać, bo działa”.

3. Nie dopisuj cyberataku do listy zagrożeń. Połącz dwie analizy we właściwym miejscu

Na rynku maszyn formalna analiza ryzyka cyberbezpieczeństwa nadal jest raczej wyjątkiem niż standardowym elementem projektu.

Najczęściej jest router przemysłowy.

Jest VPN.

Jest hasło do PLC.

Czasem jest zarządzalny switch, którym nikt później nie zarządza.

W bardziej ambitnym wariancie producent otrzymuje od dostawcy prezentację o „defence in depth” i uznaje, że właśnie zakończył analizę ryzyka cyberbezpieczeństwa całej maszyny.

Nie zakończył.

Kupił kilka środków technicznych.

To nie jest jeszcze analiza.

Nie ma więc sensu opisywać problemu tak, jakby w każdym projekcie powstawały dwie profesjonalne oceny — jedna według ISO 12100, druga dotycząca cyberbezpieczeństwa — które tylko przypadkiem nie zostały ze sobą połączone.

Najczęściej powstaje jedna.

Ocena ryzyka maszyny.

A analiza cyberbezpieczeństwa produktu nie powstaje wcale.

Ocena ryzyka maszyny według ISO 12100 nie polega na wpisaniu do tabeli:

awaria czujnika → nieoczekiwany ruch → zmiażdżenie.

To może być fragment konkretnego scenariusza, ale nie punkt wyjścia.

Najpierw trzeba określić ograniczenia maszyny.

Jakie jest jej przeznaczenie?

Jakie są fazy cyklu życia?

Kto będzie z niej korzystał?

Jakie zadania będą wykonywane podczas transportu, montażu, uruchomienia, produkcji, regulacji, czyszczenia, usuwania zacięć, konserwacji, diagnostyki i demontażu?

W jakich trybach maszyna może pracować?

Gdzie znajduje się człowiek podczas każdej z tych operacji?

Które części maszyny pozostają wtedy pod napięciem, ciśnieniem, obciążeniem albo w ruchu?

Jakie użycie nie jest zgodne z instrukcją, ale nadal pozostaje racjonalnie przewidywalne?

Dopiero później dla konkretnego zadania lub operacji identyfikuje się między innymi:

• źródło zagrożenia,
• rodzaj zagrożenia,
• strefę zagrożenia,
• osobę narażoną,
• sytuację zagrożenia,
• zdarzenie niebezpieczne, jeżeli występuje w danym scenariuszu,
• możliwe następstwa i rodzaj szkody.

Tak wygląda analiza ryzyka maszyny.

Nie zaczynamy od komponentu.

Zaczynamy od człowieka wykonującego określone zadanie przy maszynie znajdującej się w określonym stanie. ISO 12100 ustanawia właśnie taką metodykę identyfikowania zagrożeń oraz szacowania i oceny ryzyka podczas odpowiednich faz cyklu życia maszyny.

Weźmy prosty przykład.

Operator usuwa zacięty detal z wnętrza celi paletyzującej.

Mamy więc:

Zadanie: usunięcie zacięcia.

Faza użytkowania: eksploatacja, interwencja po zatrzymaniu procesu.

Tryb pracy: ręczny albo serwisowy.

Osoba narażona: operator lub pracownik utrzymania ruchu.

Strefa zagrożenia: wnętrze celi, w szczególności przestrzeń pomiędzy chwytakiem, detalem i konstrukcją maszyny.

Źródło zagrożenia: energia mechaniczna robota, osi liniowej albo chwytaka pneumatycznego.

Sytuacja zagrożenia: człowiek znajduje się w strefie, podczas gdy wykonanie ruchu nadal jest możliwe.

Zdarzenie niebezpieczne: nieoczekiwany ruch osi, zamknięcie chwytaka albo uwolnienie zmagazynowanej energii.

Możliwe następstwo: uderzenie, zmiażdżenie, złamanie lub amputacja.

Dopiero teraz można oceniać ryzyko i określać środki jego redukcji.

Może być potrzebna blokada osłony.

Może być potrzebne bezpieczne zatrzymanie.

Może być konieczne zapobieganie nieoczekiwanemu uruchomieniu.

Być może trzeba odprowadzić energię pneumatyczną.

Być może ruch w trybie ręcznym może odbywać się wyłącznie przy urządzeniu zezwalającym i bezpiecznie ograniczonej prędkości.

To nadal jest klasyczna ocena ryzyka maszyny.

Gdzie pojawia się cyberbezpieczeństwo?

Nie jako nowa pozycja obok zagrożenia mechanicznego, elektrycznego i termicznego.

„Haker” nie jest źródłem zagrożenia mechanicznego

Dopisanie do tabeli ISO 12100 pozycji:

Zagrożenie: cyberatak

niewiele wnosi.

Cyberatak nie jest wirującym wałem, ostrą krawędzią, wysoką temperaturą ani energią pneumatyczną.

Nie jest też osobną strefą zagrożenia.

Operator nie doznaje zmiażdżenia od podatności CVE.

Doznaje go od elementu maszyny, który wykonał ruch, gdy człowiek znajdował się w niewłaściwym miejscu.

Cyberatak może natomiast zmienić stan układu sterowania, dane, program, konfigurację albo sposób działania środka ochronnego.

Może więc stać się:

• przyczyną zdarzenia niebezpiecznego,
• dodatkową drogą prowadzącą do sytuacji zagrożenia,
• przyczyną utraty skuteczności środka redukcji ryzyka,
• albo sposobem obejścia założeń przyjętych podczas projektowania funkcji bezpieczeństwa.

I to jest właściwy punkt styku.

Nie lista zagrożeń.

Zachowanie maszyny.

Analiza cyberbezpieczeństwa powinna powstać osobno

Dla maszyny lub układu automatyki analiza cyberbezpieczeństwa będzie miała inną strukturę niż ocena ryzyka według ISO 12100.

Najbardziej naturalnego szkieletu dla systemu automatyki przemysłowej dostarcza IEC 62443-3-2.

Norma wymaga między innymi:

• zdefiniowania systemu podlegającego analizie, czyli SUC,
• podziału systemu na strefy i kanały komunikacyjne,
• oceny ryzyka dla poszczególnych stref i kanałów,
• określenia docelowych poziomów bezpieczeństwa SL-T,
• udokumentowania wymagań bezpieczeństwa.

To zupełnie inny punkt startowy niż w ISO 12100.

W IEC 62443 pytamy między innymi:

Co dokładnie należy do analizowanego systemu?

Jakie zasoby trzeba chronić?

Jakie urządzenia, aplikacje i interfejsy znajdują się w systemie?

Które elementy powinny należeć do tej samej strefy?

Jak przebiega komunikacja pomiędzy strefami?

Kto może uzyskać dostęp?

Z jakiego miejsca?

Przy użyciu jakiego interfejsu?

Jakie podatności mogą zostać wykorzystane?

Jakie dane, funkcje lub komponenty mogą zostać zmienione?

Jaką ścieżką atakujący może przejść od routera serwisowego do PLC, HMI, napędu albo stacji inżynierskiej?

Jakie konsekwencje będzie miała utrata poufności, integralności albo dostępności?

Jakie zabezpieczenia są potrzebne?

Dla procesu bezpiecznego rozwoju produktu oraz wymagań dotyczących samych komponentów znaczenie będą miały również inne części serii, w szczególności IEC 62443-4-1 i IEC 62443-4-2. IEC 62443-3-3 porządkuje natomiast techniczne wymagania bezpieczeństwa na poziomie systemu.

CRA nie nakazuje dziś producentowi napisania na okładce analizy „wykonano zgodnie z IEC 62443”.

IEC 62443 nie zastępuje również wykazania zgodności z wymaganiami CRA.

Dla przemysłowego układu automatyki jest jednak znacznie bardziej logicznym punktem odniesienia niż próba dopisania kilku scenariuszy hakerskich do tabeli ISO 12100.

Bo obie metodyki odpowiadają na inne pytania.

ISO 12100:

Podczas jakiego zadania, gdzie, od jakiego źródła i w wyniku jakiego zdarzenia człowiek może doznać szkody?

IEC 62443:

Kto, jaką drogą i z wykorzystaniem jakiej podatności może wpłynąć na system, jego dane albo funkcje?

Dopiero później trzeba sprawdzić, czy odpowiedź z drugiej analizy zmienia scenariusz z pierwszej.

Ten sam scenariusz, dwie różne analizy

Wróćmy do operatora usuwającego zacięty detal.

Analiza ISO 12100 wykazała, że człowiek wchodzi do strefy, w której może zostać zmiażdżony przez ruch robota albo chwytaka.

Środkiem redukcji ryzyka jest blokowana osłona, funkcja bezpiecznego zatrzymania oraz lokalny reset umieszczony poza strefą zagrożenia.

Teraz wykonujemy analizę cyberbezpieczeństwa systemu.

Identyfikujemy:

• router wykorzystywany do zdalnego serwisu,
• konto serwisowe,
• laptop inżynierski,
• HMI,
• standardowy PLC,
• safety PLC,
• napędy,
• interfejs programowania,
• sieć PROFINET i komunikację PROFIsafe,
• mechanizmy wgrywania programu oraz konfiguracji.

Rozpatrujemy scenariusz:

Przejęcie konta serwisowego umożliwia zdalny dostęp do standardowego PLC i wysłanie polecenia ruchu podczas obecności człowieka w celi.

Czy ten scenariusz prowadzi do zdarzenia niebezpiecznego?

Nie da się odpowiedzieć na podstawie samego faktu przejęcia PLC.

Trzeba sprawdzić architekturę funkcji bezpieczeństwa.

Jeżeli otwarcie osłony jest monitorowane przez safety PLC, funkcja bezpiecznie odłącza moment napędów, reset jest wyłącznie lokalny, a standardowy PLC nie może przywrócić ruchu niezależnie od stanu funkcji bezpieczeństwa, przejęcie standardowego sterownika może zatrzymać produkcję albo uszkodzić proces.

Ale nie powinno spowodować ruchu przy otwartej osłonie.

Wtedy analiza cyber wykazuje atak.

Ocena ryzyka maszyny wykazuje zagrożenie mechaniczne.

Prawidłowo zaprojektowana funkcja bezpieczeństwa przecina jednak drogę pomiędzy nimi.

A teraz drugi wariant.

Tryb serwisowy wybierany jest z poziomu zwykłego HMI.

Wartość ograniczonej prędkości pochodzi ze standardowego PLC.

Zdalny serwisant może wykonać reset.

To samo konto inżynierskie umożliwia zmianę programu standardowego i konfiguracji safety.

Kopia programu safety nie jest powiązana z konkretną wersją maszyny.

Nikt nie sprawdza sumy kontrolnej po interwencji.

Parametry napędu mogą zostać zmienione zdalnie.

W tej architekturze przejęcie konta nie oznacza już wyłącznie utraty poufności albo krótkiego przestoju.

Może zmienić warunki, na których opierała się redukcja ryzyka.

Może doprowadzić do:

• wyboru niewłaściwego trybu,
• zmiany parametru bezpiecznego ruchu,
• nieuprawnionego resetu,
• wgrania niezatwierdzonej konfiguracji,
• albo osłabienia funkcji, która miała zapobiec nieoczekiwanemu uruchomieniu.

I wtedy scenariusz cyber trzeba powiązać z konkretnym scenariuszem bezpieczeństwa maszyny:

zadanie usuwania zacięcia → człowiek w strefie zagrożenia → nieautoryzowana zmiana układu sterowania lub funkcji ochronnej → nieoczekiwany ruch → zmiażdżenie.

Nie zmieniło się źródło zagrożenia.

Nadal jest nim energia mechaniczna maszyny.

Nie zmieniła się strefa zagrożenia.

Nadal znajduje się wewnątrz celi.

Nie zmieniło się możliwe następstwo.

Nadal jest nim uraz operatora.

Zmieniła się droga prowadząca do zdarzenia niebezpiecznego.

Nie każda podatność trafia do ISO 12100

To rozróżnienie jest równie ważne.

Załóżmy, że podatność w HMI pozwala odczytać historyczne dane produkcyjne.

To może być istotny problem z punktu widzenia CRA.

Może naruszać poufność danych.

Może wymagać aktualizacji, oceny wpływu, działania wobec użytkowników, a w określonych okolicznościach również raportowania.

Ale jeżeli nie wpływa na zachowanie maszyny, nie zmienia środka ochronnego i nie może doprowadzić do sytuacji zagrożenia, nie ma sensu wciskać jej do oceny ryzyka według ISO 12100.

Podobnie atak powodujący wyłącznie niedostępność raportów produkcyjnych może oznaczać problem biznesowy i problem zgodności z CRA.

Nie musi jednak tworzyć ryzyka dla operatora.

Z drugiej strony niewinnie wyglądająca możliwość zmiany jednej wartości zadanej może mieć niewielkie znaczenie dla poufności danych, ale ogromne znaczenie dla bezpieczeństwa fizycznego.

Na przykład wtedy, gdy wartość określa:

• maksymalną prędkość osi,
• siłę docisku,
• temperaturę procesu,
• ciśnienie,
• pozycję zatrzymania,
• czas otwarcia zaworu,
• albo granicę dopuszczalną podczas pracy z otwartą osłoną.

Nie klasyfikujemy więc cyberzagrożenia na podstawie tego, jak technicznie brzmi.

Patrzymy, co rzeczywiście może zrobić z maszyną.

Rozporządzenie maszynowe wymusza ten most

To połączenie nie jest wyłącznie dobrą praktyką inżynierską.

Punkt 1.2.1 załącznika III do rozporządzenia maszynowego wymaga, aby układy sterowania były zaprojektowane i wykonane tak, by zapobiegać powstawaniu sytuacji zagrożenia, również w wyniku racjonalnie przewidywalnych, złośliwych prób osób trzecich.

CRA z kolei wskazuje, że jego zasadnicze wymagania cyberbezpieczeństwa mogą wspierać wykazanie zgodności między innymi z wymaganiami 1.1.9 i 1.2.1 rozporządzenia maszynowego.

Ale nie dzieje się to automatycznie.

Producent musi wykazać tę zależność na podstawie oceny ryzyka. Ocena zgodności według CRA i ocena zgodności według rozporządzenia maszynowego nadal pozostają odrębnymi procesami.

Czyli nie wystarczy przygotować:

• ocenę ryzyka ISO 12100,
• analizę IEC 62443,
• dwa osobne raporty,
• i liczyć, że podobieństwo numerów norm stworzy pomiędzy nimi ślad audytowy.

Potrzebne jest powiązanie.

Dla każdego istotnego scenariusza cyber należy ustalić:

1. jaki element lub funkcja może zostać przejęta albo zmieniona,
2. jakie zachowanie maszyny może to wywołać,
3. czy zachowanie prowadzi do sytuacji zagrożenia lub zdarzenia niebezpiecznego,
4. którego zadania i której strefy zagrożenia dotyczy,
5. jakie możliwe następstwo zostało wskazane w ocenie ISO 12100,
6. jaki środek redukcji ryzyka powinien przerwać rozwój scenariusza,
7. czy środek ten pozostaje skuteczny po przejęciu zaatakowanego elementu.

Ten ostatni punkt jest najważniejszy.

Bo jeżeli atak i zabezpieczenie zależą od:

• tego samego sterownika,
• tego samego konta,
• tej samej sieci,
• tej samej stacji inżynierskiej,
• albo tego samego programu,

to być może nie mamy dwóch niezależnych warstw ochrony.

Mamy jedną warstwę opisaną w dwóch dokumentach.

Nie potrzebujemy więc jednej ogromnej tabeli pod nazwą:

„ocena ryzyka safety & cybersecurity”.

Potrzebujemy dwóch poprawnych analiz, wykonanych odpowiednimi metodami, oraz kontrolowanego punktu styku pomiędzy nimi.

ISO 12100 ma opisać człowieka, zadanie, źródło zagrożenia, strefę, sytuację zagrożenia, zdarzenie niebezpieczne i możliwą szkodę.

IEC 62443 ma pomóc opisać system, jego strefy, kanały komunikacyjne, zasoby, zagrożenia, podatności, ścieżki ataku i wymagane zabezpieczenia.

A producent musi wykazać, czy scenariusz z drugiej analizy może uruchomić scenariusz z pierwszej albo odebrać skuteczność środkowi, który miał go zatrzymać.

Cyberatak nie musi tworzyć nowego zagrożenia. Wystarczy, że otworzy nową drogę do starego wypadku.

4. Pentest przed FAT-em jest zdjęciem. CRA wymaga filmu

W wielu projektach cyberbezpieczeństwo pojawia się dwa tygodnie przed FAT-em.

Zamawiany jest pentest.

Powstaje raport.

Podatności krytyczne zostają poprawione, średnie zaakceptowane, a dokument trafia do katalogu projektu.

Maszyna jest cyberbezpieczna.

Do następnego wtorku.

Pentest może być bardzo wartościowym elementem weryfikacji. Pokazuje jednak stan konkretnej wersji produktu, w konkretnej konfiguracji i przy wykorzystaniu określonych scenariuszy testowych.

Nie odpowiada na pytanie, co producent zrobi później.

A CRA dotyczy całego cyklu życia produktu. Ocena ryzyka cyberbezpieczeństwa ma wpływać na planowanie, projektowanie, rozwój, produkcję, dostawę i utrzymanie produktu. Po wprowadzeniu go na rynek producent musi obsługiwać podatności przez zadeklarowany okres wsparcia.

Wróćmy do maszyny pakującej warzywa.

Maszyna przeszła FAT.

Pentest nie wykazał podatności krytycznych.

Osiem miesięcy później producent routera serwisowego publikuje informację o podatności pozwalającej na przejęcie urządzenia.

I teraz zaczyna się prawdziwa robota.

Które dostarczone maszyny mają ten model routera?

Która wersja firmware’u została zainstalowana w każdym egzemplarzu?

Czy zdalny dostęp jest aktywny?

Czy podatność można wykorzystać w rzeczywistej konfiguracji?

Czy przejęcie routera daje dostęp wyłącznie do diagnostyki, czy również do HMI, PLC, napędów i safety PLC?

Czy możliwy jest tylko odczyt danych, czy także zmiana programu albo parametrów?

Czy atak może wpłynąć na funkcję bezpieczeństwa?

Czy dostawca udostępnił poprawkę?

Czy aktualizacja routera zmieni certyfikaty, reguły komunikacji albo sposób zestawiania tunelu?

Czy po aktualizacji trzeba ponownie sprawdzić zdalny serwis, komunikację i część funkcji bezpieczeństwa?

Których klientów należy powiadomić?

I czy sytuacja spełnia kryteria zgłoszenia aktywnie wykorzystywanej podatności albo poważnego incydentu?

Raport z pentestu wykonany przed FAT-em nie odpowie na żadne z tych pytań.

Opisuje maszynę, która już nie istnieje.

Bo od czasu badania zmieniły się wersje oprogramowania, konfiguracje, środowisko użytkownika i wiedza o podatnościach.

Dlatego producent potrzebuje nie tylko testu, lecz procesu:

• identyfikowania wersji sprzętu, firmware’u i oprogramowania w każdym dostarczonym egzemplarzu,
• monitorowania informacji o podatnościach,
• oceny ich wykorzystania w rzeczywistej architekturze,
• sprawdzania możliwych skutków dla procesu i bezpieczeństwa maszyny,
• przygotowywania oraz testowania aktualizacji,
• informowania użytkowników,
• dokumentowania podjętych decyzji,
• obsługi wymaganych zgłoszeń.

Od 11 września 2026 r. producenci mają obowiązek raportować aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktów z elementami cyfrowymi. Wstępne ostrzeżenie trzeba przekazać w ciągu 24 godzin, a pełne zgłoszenie w ciągu 72 godzin.

To oznacza, że po wykryciu problemu nie będzie czasu na rozpoczęcie poszukiwań:

„Kto właściwie robił ten router i gdzie mamy listę maszyn, do których go wsadziliśmy?”

IEC 62443-4-1 dobrze pokazuje różnicę pomiędzy jednorazowym zabezpieczeniem produktu a bezpiecznym cyklem jego rozwoju. Obejmuje nie tylko projektowanie i weryfikację, lecz także zarządzanie defektami, poprawkami i końcem życia produktu.

FAT może więc zamknąć etap projektu.

Nie zamyka cyklu życia produktu.

Nie zamyka okresu wsparcia.

Nie kończy monitorowania podatności.

I nie powoduje, że konfiguracja z dnia odbioru zostaje zamrożona na kolejne piętnaście lat.

Maszyna może przez długi czas pakować warzywa dla supermarketów.

Producent nie może jednak zapakować jej cyberbezpieczeństwa razem z instrukcją, zgrzać folią i uznać, że zostało dostarczone raz na zawsze.

Pentest może zamknąć punkt na liście FAT. CRA otwiera proces, który trwa do końca okresu wsparcia produktu.