Cyberzagrożenia w systemach zrobotyzowanych: ryzyka i ochrona

Roboty przemysłowe przestały być izolowanymi maszynami – dziś są pełnoprawnymi węzłami sieciowymi, podatnymi na ataki z zewnątrz tak samo jak serwery czy stacje robocze. Cyberzagrożenia w systemach zrobotyzowanych to temat, który łączy klasyczne bezpieczeństwo IT z konsekwencjami fizycznymi, jakich żaden administrator sieci wcześniej nie musiał brać pod uwagę. Ten artykuł jest dla inżynierów automatyki, specjalistów ds. bezpieczeństwa OT oraz osób odpowiedzialnych za wdrożenia robotyczne, które chcą rozumieć realne ryzyka, a nie tylko ogólne hasła. Znajdziesz tu konkretne wektory ataku, ich skutki i sprawdzone sposoby obrony.

• Roboty przemysłowe działają jako systemy cyber-fizyczne oparte na Linuksie i ROS/ROS2, co zbliża ich profil zagrożeń do klasycznych systemów IT.
• Ataki na kanały komunikacyjne robota, czujniki i algorytmy planowania ruchu mogą prowadzić bezpośrednio do kolizji, uszkodzenia sprzętu lub zagrożenia zdrowia pracowników.
• Autonomiczne roboty mobilne są narażone na spoofing czujników nawigacyjnych, który stopniowo i niewidocznie zniekształca ich trasę.
• Standard ISO 10218:2025 po raz pierwszy formalnie włącza cyberbezpieczeństwo jako element bezpieczeństwa funkcjonalnego robotów, odwołując się do normy IEC 62443.
• Skuteczna ochrona systemów zrobotyzowanych wymaga połączenia segmentacji sieci, kontroli dostępu, hardeningu czujników i systemów detekcji anomalii uwzględniających fizykę ruchu robota.

Jakie cyberzagrożenia występują w systemach zrobotyzowanych?

Współczesny robot przemysłowy to system operacyjny oparty na Linuksie, middleware komunikacyjny (najczęściej ROS2 z DDS), interfejsy sieciowe do sieci zakładowej i chmury, a do tego firmware z możliwością aktualizacji przez sieć – OTA. To oznacza, że powierzchnia ataku takiego systemu jest porównywalna z powierzchnią ataku serwera przemysłowego, z jedną zasadniczą różnicą: błąd przetwarzania w IT powoduje przestój systemu, natomiast błąd w robocie może skończyć się kolizją z człowiekiem.

Cykle sterowania robotów przemysłowych wynoszą poniżej 10 milisekund. Przy takich wymaganiach czasowych nawet krótkie zakłócenie komunikacji – rzędu sekund, co w klasycznym IT jest pomijalną anomalią – może destabilizować trajektorię ramienia lub powodować niekontrolowane ruchy napędów. Ta właściwość sprawia, że całe środowisko cyberzagrożeń należy analizować inaczej niż w typowych systemach informatycznych.

Poniżej zestawiam główne klasy zagrożeń, które dotyczą systemów zrobotyzowanych – od ataków sieciowych, przez manipulację czujnikami, po ataki czysto fizyczne na nawigację.

Ataki na kanał komunikacyjny – MITM i ARP spoofing

Kanał między klientem sterującym a robotem (lub między sterownikiem a sensorami) to jeden z najczęściej atakowanych punktów. Atakujący, który dostanie się do segmentu sieci OT, może przeprowadzić atak typu man-in-the-middle (MITM) z wykorzystaniem ARP spoofingu – przejąć kanał komunikacyjny i wstrzykiwać zmodyfikowane komendy sterujące lub fałszywe dane sprzężenia zwrotnego. Robot wykonuje wtedy ruchy zaprogramowane przez atakującego, a nie przez operatora.

Eksperymenty z platformami robotycznymi opartymi na ROS i ROS2 potwierdzają, że ataki MITM na warstwie łącza i aplikacji pozwalają na modyfikację integralności przesyłanych danych oraz wywołanie ataku DoS – odmowy obsługi – przez przeciążenie kanału sterowania. Skutek jest bezpośredni: niebezpieczne trajektorie ruchu albo zatrzymanie produkcji. Więcej o tym, jak bezpieczeństwo sieci robotów przemysłowych przekłada się na ochronę tych kanałów, omawiam w oddzielnym miejscu.

Luki w ROS2, DDS i SROS2 – gdzie middleware zawodzi?

ROS1 był projektowany bez jakichkolwiek mechanizmów bezpieczeństwa sieciowego. ROS2 wprowadził DDS Security – uwierzytelnianie, szyfrowanie, kontrolę dostępu – jednak sam fakt uruchomienia tych mechanizmów nie rozwiązuje problemu. Badacze zidentyfikowali cztery krytyczne podatności w SROS2 (zabezpieczonym ROS2), które pozwalają ominąć jego mechanizmy i przejąć kontrolę nad robotem, mimo że formalnie bezpieczna konfiguracja jest aktywna. To ważny sygnał: włączone bezpieczeństwo to nie to samo co skuteczne bezpieczeństwo.

Sam middleware DDS, będący szyną komunikacyjną większości aplikacji ROS2, zawiera kilkanaście poważnych podatności zidentyfikowanych przez Alias Robotics. Wynika z tego systemowe ryzyko dla całego ekosystemu robotów używających tej architektury – przemysłowych, medycznych i usługowych. Dodatkowym problemem są luki konfiguracyjne: nadmiernie szerokie polityki uprawnień, brak wymuszonego szyfrowania na wszystkich krytycznych tematach komunikacyjnych (topics) i brak wymuszenia polityk na poziomie poszczególnych węzłów (nodes). Atakujący może wtedy podsłuchiwać lub wstrzykiwać komunikaty ruchu w czasie rzeczywistym.

Wskazówka: Wdrażając ROS2 w środowisku produkcyjnym, nie poprzestaj na aktywacji DDS Security. Przeprowadź audyt polityk uprawnień dla każdego węzła osobno i zweryfikuj, czy szyfrowanie jest wymuszone na wszystkich tematach obsługujących sterowanie ruchem i dane bezpieczeństwa.

Ataki DoS i flooding na sterowanie w czasie rzeczywistym

Ataki typu DoS w systemach zrobotyzowanych mają inną wagę niż w środowisku biurowym. Przeciążenie kanału sterowania lub sensorów powoduje zanik aktualizacji poleceń, a sterownik nie otrzymuje informacji niezbędnych do utrzymania zaplanowanej trajektorii. W robocie z cyklem sterowania 8 ms brak pakietu przez 200 ms może oznaczać niekontrolowany ruch ramienia.

Szczególnie groźne są ataki wieloskalowe – działające jednocześnie na różnych warstwach i przepływach danych – wymierzone w węzły sterowania o ograniczonych zasobach obliczeniowych. Jeśli są zsynchronizowane z harmonogramem zadań sterownika, ich skuteczność dramatycznie rośnie. Klasyczne systemy detekcji anomalii (IDS) oparte na sygnaturach sieciowych wykrywają takie ataki z opóźnieniem rzędu sekund – tolerowanym w IT, ale katastrofalnym w robotyce.

Adwersarialne ataki na algorytmy planowania ruchu

To kategoria ataków, która wychodzi poza klasyczne rozumienie cyberbezpieczeństwa. Zamiast atakować sieć lub oprogramowanie bezpośrednio, atakujący celuje w reprezentację środowiska używaną przez algorytm planowania ruchu (motion planning). Niewielkie, precyzyjnie zaprojektowane zakłócenia w mapie przeszkód lub grafie konfiguracji sprawiają, że planer wybiera trajektorie pozornie poprawne, ale prowadzące zbyt blisko operatora, poza strefę bezpieczeństwa lub wprost do kolizji.

Tradycyjne mechanizmy bezpieczeństwa software’u nie wykrywają tego typu ingerencji, bo robot nie zgłasza błędu – po prostu wykonuje wygenerowaną trajektorię. To jeden z najtrudniejszych do wykrycia wektorów ataku, bo objawia się nie awarią, lecz subtelnie zmienionym zachowaniem.

Ataki na aktuatory i sterowanie niskopoziomowe

Wstrzykiwanie złośliwych sygnałów na poziomie napędów – przez przejęcie kanału sterowania lub logiki sterownika PLC – bezpośrednio destabilizuje ruch robota. Szczególnie wrażliwe są czujniki momentu w przegubach (joint torque sensors), używane w sterowaniu siłowym i detekcji kolizji z człowiekiem. Fałszywe odczyty z tych czujników mogą sprawić, że robot nie wykryje kontaktu z operatorem – albo odwrotnie: reaguje na nieistniejący opór, zatrzymując się bez przyczyny i generując straty produkcyjne.

Odpowiedzią na te zagrożenia są specjalizowane systemy RIDS (Robotic Intrusion Detection System), które łączą analizę ruchu sieciowego z modelem dynamiki robota. Jeśli sygnały elektryczne na napędach odbiegają od tego, czego oczekuje model fizyczny dla danej trajektorii, system traktuje to jako anomalię. Takie podejście jest znacznie skuteczniejsze niż samo monitorowanie pakietów sieciowych.

Które elementy systemów zrobotyzowanych są najbardziej narażone na ataki?

Nie każdy element robota jest równie podatny. Poniżej zestawiam komponenty z największą ekspozycją na zagrożenia oraz typowe wektory ataku dla każdego z nich.

Szczególnie groźna jest kombinacja słabego uwierzytelnienia w ROS2 z dostępem do sieci OT – atakujący, który dostanie się do segmentu sieci zakładowej, ma potencjalnie pełny dostęp do tematów sterowania ruchem, jeśli polityki SROS2 nie są skonfigurowane rygorystycznie. To nie jest scenariusz teoretyczny – jest to standardowy wektor w testach penetracyjnych środowisk zrobotyzowanych.

Jakie są cyberzagrożenia specyficzne dla autonomicznych robotów mobilnych?

AMR i AGV działające w magazynach i halach produkcyjnych bazują na algorytmie SLAM (Simultaneous Localization and Mapping) – jednoczesnej lokalizacji i budowie mapy otoczenia. SLAM stale aktualizuje mapę na podstawie danych z czujników: LiDAR, kamer, IMU, GPS/RTK, ultradźwięków i czujników podczerwieni. Manipulacja którymkolwiek z tych kanałów przekłada się bezpośrednio na zniekształconą mapę lub błędną estymację pozycji robota.

Co ważne, subtelne, utrwalone błędy w danych sensorycznych – na przykład stałe przesunięcie odczytu odległości z LiDAR o kilka centymetrów – mogą stopniowo wypaczać trajektorie bez gwałtownych symptomów w logach. Robot zaczyna jeździć kilka centymetrów bliżej regałów, aż do kolizji. To jest właśnie groźne: brak ostrego sygnału alarmowego.

Poza atakami sensorycznymi AMR-y są podatne jako urządzenia IoT podłączone do chmury i systemów WMS/ERP. Typowe problemy to:

• Słabe uwierzytelnianie w zdalnym API konfiguracyjnym – umożliwia zmianę parametrów trasy lub stref bezpieczeństwa bez fizycznego dostępu do robota.
• Brak segmentacji sieci – AMR w tej samej podsieci co stacje robocze IT to klasyczny wektor ruchu bocznego dla atakującego.
• Spoofing GPS/RTK w zastosowaniach zewnętrznych – całkowita zmiana trasy robota lub zatrzymanie misji bez włamania do sieci, czysto przez fałszywy sygnał radiowy.
• Inteligentny atak fizyczny – atakujący obserwuje, jak robot reaguje na przeszkody, uczy się jego logiki ruchu, a następnie układa minimalne zestawy obiektów, żeby uwięzić robota w wybranym obszarze.

Tradycyjne systemy detekcji ataków sieciowych nie wykrywają ataków GPS ani ataków fizycznych na nawigację. Tu potrzebna jest wielomodalna weryfikacja danych sensorycznych i monitorowanie spójności między różnymi źródłami informacji o pozycji.

Wskazówka: Skonfiguruj AMR-y tak, żeby weryfikowały spójność danych z co najmniej dwóch niezależnych systemów lokalizacji – np. LiDAR SLAM i odometrię kół. Rozbieżność powyżej zdefiniowanego progu powinna wywołać alarm i przełączenie w tryb bezpieczny, zanim robot dotrze do niebezpiecznego obszaru.

Jakie cyberzagrożenia dotyczą robotów humanoidalnych i usługowych?

Humanoidy łączą zagrożenia typowych systemów CPS z nowym wymiarem ryzyka: wielomodalnymi kanałami wejściowymi – głosem, obrazem i gestami. Każdy z tych kanałów można zaatakować przez tak zwane adwersarialne bodźce – specjalnie przygotowane sygnały, które dla człowieka wyglądają i brzmią normalnie, ale model AI klasyfikuje je błędnie.

Wykazano na przykład możliwość przejęcia humanoidów przez pozornie niegroźne komendy głosowe, które wykorzystują słabości w przetwarzaniu mowy lub bezprzewodowych protokołach komunikacyjnych. Efektem może być wymuszenie ruchu, który omija logikę bezpieczeństwa – bez żadnego klasycznego włamania do sieci.

Specyficzna podatność humanoidów wynika też z fizyki chodu. Pętle sterowania równowagą pracują z wyjątkowo krótkimi cyklami. Nawet krótkie opóźnienie percepcji lub drobne zakłócenie danych z czujników inercyjnych może spowodować utratę stabilności i upadek robota w otoczeniu ludzi. Regulacje takie jak EU AI Act zaczynają wymuszać ścisłe wymagania cyberbezpieczeństwa, śledzalności i nadzoru ludzkiego dla systemów humanoidalnych klasyfikowanych jako wysokiego ryzyka – co zwiększa złożoność inżynierską całego stosu oprogramowania.

Jakie mogą być skutki cyberataków na systemy zrobotyzowane?

Skutki można podzielić na trzy poziomy, które narastają kaskadowo.

Poziom pierwszy to problemy jakościowe. Atak CORMAND2 na roboty przemysłowe pokazuje, jak mikroskopijne odchyłki trajektorii – poniżej progu wykrywalności przez standardowe monitorowanie – przez długi czas manifestują się wyłącznie jako drobne błędy pozycjonowania. Robot montuje elementy z minimalnym odchyleniem, spawy są nieznacznie poza tolerancją. Dopiero kontrola jakości wyłapuje problem – ale zanim to nastąpi, wadliwa seria trafia do produkcji.

Poziom drugi to zatrzymanie produkcji. Skompromitowany robot lub komórka zrobotyzowana z PLC może wywołać kaskadowe skutki:

• Zatrzymanie całej linii produkcyjnej.
• Zniszczenie narzędzi lub uszkodzenie obrabianego materiału.
• Wtórne zagrożenia – np. wyciek substancji niebezpiecznych przy zrobotyzowanych stanowiskach procesowych.

Poziom trzeci – i najtrudniejszy do zaakceptowania – to bezpośrednie zagrożenie życia. Manipulacja parametrami bezpieczeństwa robota (SS1/SS2 – zatrzymanie bezpieczne, SLS – ograniczenie prędkości) może zneutralizować funkcje ochronne zaprojektowane zgodnie ze wszystkimi wymogami normatywnymi. Czujnik momentu, który nie wykrywa kontaktu z człowiekiem, bo odczytuje fałszywe dane, to realny mechanizm wypadku. Przypadki opisywane w literaturze potwierdzają ten związek.

Jak chronić systemy zrobotyzowane przed cyberzagrożeniami?

Ochrona wymaga działania na kilku warstwach jednocześnie. Poniżej zestawiam obszary z konkretnymi działaniami.

Segmentacja sieci i kontrola dostępu

Komórki robotyczne powinny być wydzielonymi strefami sieci OT, zgodnie z modelem stref i kanałów (zones & conduits) z normy IEC 62443. Ruch między strefą IT a strefą OT powinien przechodzić przez zdefiniowane kanały z kontrolą i inspekcją.

Praktyczne kroki segmentacji i kontroli dostępu:

• Oddziel sieć robotyczną od sieci korporacyjnej fizycznie lub za pomocą VLAN z restrykcyjnymi regułami firewalla.
• Wdróż uwierzytelnianie na wszystkich interfejsach zdalnych – panelach operatorskich, API konfiguracyjnych i połączeniach serwisowych.
• Stosuj zasadę minimalnych uprawnień dla każdego węzła ROS2 – każdy node powinien mieć dostęp wyłącznie do tematów, których rzeczywiście potrzebuje.
• Wyłącz wszystkie nieużywane porty sieciowe i interfejsy bezprzewodowe na sterownikach robotów.

Szczegółowe podejście do ochrony robotów przed nieautoryzowanym dostępem obejmuje zarówno warstwę sieciową, jak i uwierzytelnianie na poziomie aplikacji sterującej.

Hardening czujników i weryfikacja wielomodalna

Każda klasa czujników ma specyficzne podatności fizyczne:

• LiDAR – podatny na spoofing laserowy; zastosuj weryfikację krzyżową z kamerą lub odometrią.
• Czujniki ultradźwiękowe – podatne na jamming; monitoruj statystyki szumu i saturacji sygnału.
• Czujniki momentu w przegubach – krytyczne dla detekcji kolizji; monitoruj dryft i koreluj z modelowymi wartościami momentu dla danej trajektorii.
• GPS/RTK – podatny na spoofing radiowy; stosuj fuzję z INS i monitorem spójności pozycji.

Monitorowanie parametryczne czujników – śledzenie szumów, dryftów i saturacji – pozwala wykryć anomalie sensoryczne zanim przerodzą się w błędną nawigację lub pominięcie kolizji.

Aktualizacje i zarządzanie podatnościami

Długi cykl życia robotów przemysłowych to jedno z największych wyzwań zarządzania bezpieczeństwem. Roboty kupione 10 lat temu działają na firmware, dla którego dostawca może już nie wydawać poprawek bezpieczeństwa. Dlatego zarządzanie podatnościami w środowiskach zrobotyzowanych powinno obejmować:

• Regularne audyty wersji oprogramowania sterowników, systemu operacyjnego i middleware.
• Monitorowanie biuletynów bezpieczeństwa dostawców robotów i komponentów ROS/DDS.
• Segmentację jako kompensatę tam, gdzie aktualizacja firmware jest niemożliwa – starszy robot bez aktualizacji powinien być w jak najściślej izolowanej strefie sieci.
• Testowanie łatek przed wdrożeniem produkcyjnym na stanowisku testowym – OTA bez walidacji to realne ryzyko zatrzymania linii.

Jak wykrywać incydenty cyberbezpieczeństwa w środowiskach zrobotyzowanych?

Klasyczne systemy IDS oparte na sygnaturach sieciowych są niewystarczające w środowiskach robotycznych z kilku powodów. Ataki na planery ruchu, manipulacja sensorami i fizyczne ataki na nawigację AMR mogą nie generować żadnego podejrzanego ruchu sieciowego. Dlatego detekcja anomalii musi łączyć dwa wymiary.

Wymiary detekcji anomalii w systemach zrobotyzowanych:

• Warstwa sieciowa – monitorowanie ruchu DDS, nieoczekiwanych połączeń między węzłami, zmian w topologii tematów ROS2, anomalii w wolumenie pakietów.
• Warstwa fizyczna – porównywanie rzeczywistych trajektorii, prądów silników i momentów w przegubach z wartościami modelowymi dla danego programu robota.

System RIDS (Robotic Intrusion Detection System) łączy oba wymiary: anomalia w ruchu sieciowym potwierdzona przez odchylenie fizyczne od modelu dynamiki robota daje wysoki poziom pewności, że dzieje się coś złego. Samo odchylenie fizyczne bez anomalii sieciowej może sugerować atak na czujniki lub planer ruchu – bez włamania do sieci. To właśnie ta kombinacja odróżnia dedykowany system wykrywania zagrożeń dla robotów od standardowego monitoringu OT.

Warto też wdrożyć logowanie i alarmowanie dla zdarzeń takich jak: zmiana konfiguracji SROS2, próby połączenia z węzłami sterowania ruchu spoza zdefiniowanych adresów IP, nieoczekiwane zmiany w programach robota poza oknem serwisowym czy odczyty czujników momentu wykraczające poza model dla bieżącej trajektorii.

Wskazówka: Zdefiniuj bazę normalnego zachowania robota – typowe zakresy momentów, prędkości i trajektorii dla każdego programu – i używaj jej jako wzorca porównawczego w systemie monitorowania. Odchylenia od tej bazy są często pierwszym sygnałem manipulacji, zanim wystąpią widoczne problemy z jakością lub bezpieczeństwem.

Jakie normy regulują cyberbezpieczeństwo w robotyce przemysłowej?

Przez długi czas bezpieczeństwo funkcjonalne robotów i ich cyberbezpieczeństwo były traktowane jako odrębne zagadnienia. Standard ISO 10218:2025 zmienia ten stan rzeczy. Po raz pierwszy w historii tej normy wymaga się wprost ochrony przed nieautoryzowanym dostępem, manipulacją oprogramowaniem i atakami sieciowymi – i wskazuje normę IEC 62443 jako referencyjny zestaw środków bezpieczeństwa dla systemów sterowania przemysłowego.

IEC 62443 definiuje model stref i kanałów dla środowisk automatyki przemysłowej oraz cztery poziomy bezpieczeństwa (SL1–SL4). Zastosowanie tego modelu do komórek robotycznych oznacza konieczność klasyfikacji każdej funkcji ruchu i bezpieczeństwa pod kątem wymaganego poziomu SL, a następnie wdrożenia środków technicznych i proceduralnych odpowiadających temu poziomowi.

Dla systemów opartych na AI – humanoidów i robotów usługowych – dochodzi EU AI Act, który dla systemów wysokiego ryzyka wymaga śledzalności decyzji, nadzoru ludzkiego i weryfikowalnych właściwości bezpieczeństwa. To istotna zmiana dla producentów i integratorów, bo wymogi te muszą być uwzględnione już na etapie projektowania systemu, a nie dodawane post factum.

Dobre praktyki wynikające z obu norm w kontekście robotyki przemysłowej zestawia poniższa tabela.

Temat cyberbezpieczeństwa robotów przemysłowych jest szerszy i obejmuje też praktyczne aspekty wdrożeniowe – szczegółowo opisuje to artykuł o cyberbezpieczeństwie w robotyce przemysłowej, gdzie znajdziesz m.in. podejście do oceny ryzyka zgodnie z IEC 62443.

Podsumowanie

Cyberzagrożenia w systemach zrobotyzowanych to wynik połączenia klasycznych podatności IT/OT z unikalnymi wymaganiami systemów cyber-fizycznych: ultraniską tolerancją na opóźnienia, silną zależnością od danych sensorycznych i bezpośrednim przełożeniem błędów sterowania na skutki fizyczne. Ataki mogą celować w middleware komunikacyjny, czujniki, algorytmy planowania ruchu, aktuatory lub nawigację autonomiczną – każdy z tych wektorów może skończyć się uszkodzeniem sprzętu, stratą produkcyjną lub zagrożeniem zdrowia operatorów. Skuteczna ochrona wymaga segmentacji sieci, hardeningu konfiguracji ROS2/DDS, wielomodального monitorowania anomalii i wdrożenia wymagań normy IEC 62443 w środowiskach robotycznych.

FAQ

Q: Czy roboty przemysłowe starszej generacji bez połączenia z siecią są bezpieczne przed cyberzagrożeniami?

A: Izolacja fizyczna obniża ryzyko, ale nie eliminuje go całkowicie. Ataki mogą być przeprowadzone przez nośniki zewnętrzne (pendrive), serwisowe połączenia laptopów lub interfejsy bezprzewodowe, które mogą być aktywne bez wiedzy operatora.

Q: Jak często powinno się przeprowadzać testy penetracyjne stanowisk zrobotyzowanych?

A: Testy penetracyjne środowisk zrobotyzowanych zaleca się przeprowadzać po każdej istotnej zmianie konfiguracji sieci OT, aktualizacji oprogramowania sterownika oraz co najmniej raz w roku jako audyt planowy.

Q: Czy oprogramowanie open source używane w ROS2 zwiększa ryzyko cyberataków?

A: Open source oznacza, że kod jest publicznie dostępny – atakujący mogą szukać podatności tak samo jak badacze bezpieczeństwa. Ryzyko zależy jednak głównie od konfiguracji i hardeningu wdrożenia, a nie od samego modelu licencji.

Q: Co zrobić, gdy robot przemysłowy zachowuje się anomalnie i podejrzewamy atak cybernetyczny?

A: Przede wszystkim odłącz stanowisko od sieci zakładowej i przełącz je w tryb manualny lub zatrzymaj. Zabezpiecz logi sterownika, logi sieciowe i zapisy trajektorii przed ich nadpisaniem, a następnie zgłoś incydent do zespołu bezpieczeństwa OT.

Q: Czy ubezpieczenie przemysłowe obejmuje straty wynikające z cyberataków na roboty?

A: Standardowe polisy majątkowe zazwyczaj nie obejmują strat z cyberataków. Potrzebna jest osobna polisa cyber liability lub rozszerzenie OT/ICS. Warunki ubezpieczenia coraz częściej wymagają udokumentowania wdrożonych środków bezpieczeństwa zgodnych z IEC 62443.

Weryfikacja i redakcja

Za redakcję i weryfikację artykułu odpowiadają:

Joanna Lewandowska. Specjalistka ds. automatyki i integracji. Absolwentka kierunku Automatyka i Robotyka na Akademii Górniczo-Hutniczej im. Stanisława Staszica w Krakowie.

Piotr Woźniak. Doświadczony redaktor technologiczny. Absolwent kierunku Dziennikarstwo i Komunikacja Społeczna na Uniwersytecie Warszawskim.