Artykuł ekspercki przygotowany na podstawie webinaru „Cyberbezpieczeństwo maszyn i linii produkcyjnych – nowe obowiązki i realne ryzyka”, zorganizowanego przez Akademię ELOKON (28 lipca 2026 r.), prowadzonego przez Tomasza Otrębskiego.

O ekspercie: kim jest Tomasz Otrębski

Tomasz Otrębski to Dyrektor Działu Inżynierii w ELOKON Polska, inżynier z prawie 25-letnim doświadczeniem w bezpieczeństwie maszyn, systemach sterowania i ocenie zgodności linii produkcyjnych. Absolwent Politechniki Śląskiej, trener i wykładowca od 2003 roku, specjalizujący się m.in. w ocenie ryzyka, certyfikacji maszyn oraz normach IEC. Pełny profil eksperta: akademiaelokon.pl/trenerzy/tomasz-otrebski.

Dlaczego temat jest dziś kluczowy dla każdego zakładu produkcyjnego

Cyberbezpieczeństwo od lat kojarzy się przede wszystkim z działem IT: ochroną danych, sieciami korporacyjnymi, firewallami. Już na wstępie warto jednak precyzyjnie określić grupę odbiorców i zakres tematu:

„To nie będzie webinar, który dotyczy branży IT, czy administratorów sieci, czy specjalistów z branży IT. Będziemy rozmawiać o kwestiach dotyczących bezpośrednio maszyn – z perspektywy producenta, integratora, użytkownika, czy też inżyniera bezpieczeństwa maszyn.”

To rozróżnienie jest fundamentalne. Nowe regulacje unijne nie traktują cyberbezpieczeństwa jako dodatkowego, „informatycznego” wymogu, lecz jako integralny element bezpieczeństwa funkcjonalnego maszyny – a więc obszar, za który odpowiada dokładnie ten sam inżynier, który do tej pory zajmował się oceną ryzyka mechanicznego, elektrycznego czy ergonomicznego.

Kiedy cyberbezpieczeństwo staje się częścią bezpieczeństwa maszynowego

Kluczowe pytanie, które powinno stać się punktem wyjścia każdej analizy, brzmi:

„Czy ta ingerencja cyfrowa może doprowadzić do sytuacji niebezpiecznej?”

Jeśli odpowiedź jest pozytywna, temat trzeba „zaopiekować” w klasycznym procesie oceny ryzyka – tak samo, jak dotychczas traktowano ryzyko urazu mechanicznego, porażenia elektrycznego czy nadmiernego hałasu. Podejście metodologiczne się nie zmienia – zmienia się jedynie zakres identyfikowanych zagrożeń:

„Takie podejście pozwala wykorzystać te same metody oceny ryzyka, które używamy – tylko tyle, że musimy zidentyfikować we właściwy sposób nowe zagrożenia, które się pojawiają.”

Istotna różnica w filozofii oceny dotyczy tego, co właściwie mierzymy. W klasycznym podejściu do bezpieczeństwa IT ocenia się prawdopodobieństwo ataku. W bezpieczeństwie maszynowym logika jest inna:

„Nie oceniamy prawdopodobieństwa pojawienia się anonimowego hakera, tak jak podchodzilibyśmy do systemu IT. Oceniamy wpływ możliwej ingerencji na maszynę i człowieka.”

To rozróżnienie ma praktyczne konsekwencje: nie trzeba modelować scenariuszy ataku i szacować, jak prawdopodobny jest włam hakera z zewnątrz. Trzeba natomiast rzetelnie ustalić, co się stanie z funkcją bezpieczeństwa maszyny, jeśli dojdzie do błędnej aktualizacji, pomyłki serwisanta, nieautoryzowanej zmiany parametru albo wgrania nieprawidłowego backupu do sterownika safety PLC.

Warto też zapamiętać jedną kluczową myśl, przydatną w rozmowach z osobami sceptycznymi wobec „kolejnych unijnych wymogów”:

„Cyberbezpieczeństwo nie pojawiło się dlatego, że ustawodawca wymyślił nowy obowiązek. Regulacje  uległy zmianie, ponieważ zmieniła się nasza rzeczywistość, a wraz z nią architektura nowoczesnych maszyn.”

Maszyny, które jeszcze kilkanaście lat temu działały w izolacji od sieci, dziś są gęsto usieciowione: panele HMI, napędy, roboty mobilne, skanery bezpieczeństwa i kurtyny świetlne mają parametry programowalne, a ich zmiana – celowa lub przypadkowa – może naruszyć funkcję bezpieczeństwa w sposób analogiczny do uszkodzenia mechanicznego elementu.

Mapa regulacji: co dotyczy maszyny, a co organizacji

Warto uporządkować cztery akty prawne, które najczęściej są ze sobą mylone lub traktowane jako jeden „pakiet cyfrowy”. Zamiast zapamiętywać numery aktów, warto zrozumieć, jakiego obszaru dotyczy każdy z nich.

Rozporządzenie Maszynowe (Machinery Regulation) – wymagania od 20 stycznia 2027 r.

To akt bezpośrednio odpowiedzialny za bezpieczeństwo i zgodność maszyn. Kluczowy jest punkt 1.1.9 załącznika III, dotyczący ochrony przed „korupcją cyfrową” (protection against corruption) – sprzęt, oprogramowanie i dane wpływające na zgodność oraz bezpieczeństwo funkcjonalne muszą być chronione przed przypadkową lub celową ingerencją, zarówno sieciową, jak i fizyczną (np. lokalny dostęp serwisowy, zmiana parametrów na panelu serwonapędu). Rozporządzenie nie nakazuje stosowania konkretnych urządzeń (firewalli, bram VPN), lecz nakłada na producenta obowiązek osiągnięcia odpowiedniego poziomu bezpieczeństwa oraz udokumentowania procesu, w tym analizowanych interfejsów, przyjętych warunków pracy i przekazanego użytkownikowi ryzyka resztkowego.

Cyber Resilience Act (CRA) – pełne zastosowanie od 11 grudnia 2027 r., obowiązki raportowania od 11 września 2027 r.

CRA wprowadza horyzontalne wymagania dla producentów produktów z elementami cyfrowymi – nie dotyczy bezpośrednio użytkowników maszyn, lecz producentów komponentów (sterowników, modułów komunikacyjnych, urządzeń sieciowych). Zgodnie z podejściem Security by Design, producent komponentu musi zarządzać podatnościami i zapewniać aktualizacje w określonym czasie wsparcia produktu. Zadaniem integratora i inżyniera bezpieczeństwa maszyn jest weryfikacja, czy dany komponent nadaje się do zastosowania w konkretnej funkcji.

AI Act – wdrażany etapowo

Sam fakt zastosowania algorytmu lub modelu do wspierania działania maszyny nie oznacza automatycznie, że mamy do czynienia z systemem wysokiego ryzyka w rozumieniu AI Act. W obszarach o wysokim ryzyku bezpieczeństwa nadrzędny musi pozostać deterministyczny, „zero-jedynkowy” system sterowania związany z bezpieczeństwem – systemy AI mogą obecnie funkcjonować jako systemy wspomagające lub asystenckie, nie jako podstawa funkcji bezpieczeństwa.

NIS-2 / Krajowy System Cyberbezpieczeństwa – w Polsce od 3 kwietnia 2024 r.

NIS-2 dotyczy poziomu organizacyjnego, nie samej maszyny. Dla osób związanych z maszynami jest to przede wszystkim kontekst organizacyjny klienta. Integratorzy współpracujący z podmiotami podlegającymi pod NIS-2 powinni zweryfikować, czy polityka bezpieczeństwa danej organizacji (np. zarządzanie hasłami, oprogramowaniem) generuje dodatkowe wymagania wpływające na dostarczaną maszynę.

Ocena ryzyka krok po kroku: od ISO 12100 do dokumentacji resztkowej

Metodyka oceny ryzyka pozostaje oparta na normie ISO 12100 – to fundament, który się nie zmienia. Zmienia się zakres analizy. Uporządkowany proces obejmuje kolejno:

1. Ocenę ryzyka wg ISO 12100 jako podstawę metodologiczną.
2. Identyfikację zagrożeń cyfrowych oraz określenie tzw. security context i interfejsów maszyny – czyli tego, gdzie maszyna pracuje, z jakimi systemami się komunikuje, kto ma do niej fizyczny i logiczny dostęp oraz jakie założenia bezpieczeństwa musi spełnić użytkownik.
3. Threat assessment, który pozwala dobrać odpowiednie środki ochronne: uwierzytelnienie, role dostępowe, segmentację, zabezpieczenie zdalnego dostępu, rejestrację zdarzeń, kontrolę zmian i procedury aktualizacji.
4. Walidację wdrożonych środków ochronnych.
5. Dokumentację ryzyka resztkowego i wymagań przekazywanych użytkownikowi w instrukcji obsługi.

Dokumentacja nabiera nowego znaczenia dowodowego – producent powinien być w stanie wykazać, jakie interfejsy analizował, jakie środki zastosował i jakie ryzyko resztkowe przekazał dalej.

Gdzie realnie rodzi się ryzyko cybernetyczne na maszynie

Poniżej pięć typowych scenariuszy, w których ingerencja cyfrowa przekłada się na sytuację niebezpieczną:

• Modyfikacja programu PLC – może doprowadzić do nieoczekiwanego ruchu maszyny.
• Zmiana parametrów w przekaźniku lub sterowniku bezpieczeństwa – może obniżyć poziom ochrony lub całkowicie wyłączyć funkcję bezpieczeństwa.
• Deaktywacja kurtyny świetlnej lub skanera (np. cyfrowe wyłączenie pól ochronnych, tzw. muting/blanking) – generuje bezpośrednie zagrożenie.
• Zmiana czasu reakcji urządzenia ochronnego (np. wydłużenie czasu próbkowania skanera) – wpływa na czas dobiegu elementów niebezpiecznych.
• Nieautoryzowane lub błędne aktualizacje, które zmieniają zachowanie systemu bez rejestracji i walidacji zmiany.

Podczas audytu czy oględzin warto zadawać konkretne pytania: kto dokonuje zmian, jak są autoryzowane, czy system rejestruje historię zmian oraz czy dostępne są poprawne pliki źródłowe przypisane do konkretnego numeru seryjnego i stanu maszyny. Zagrożenie nie musi pochodzić z sieci czy internetu:

„Nie każde zagrożenie pochodzi z sieci, z internetu, czy z zewnątrz. Musimy się zabezpieczyć również przed tym, co dzieje się bezpośrednio w kontakcie z maszyną” – w tym przez lokalne podłączenie programatora do dostępnego portu USB lub Ethernet.

Pięć grup środków ochronnych, które dają największy efekt

Poniżej pięć obszarów działań, które w praktyce przynoszą najbardziej wymierny efekt w ograniczaniu ryzyka:

1. Segmentacja sieci OT

„Nie każda maszyna powinna komunikować się z całym środowiskiem zakładu.” Połączenie z siecią zewnętrzną i internetem nie powinno być funkcją domyślną. Należy określić niezbędne przepływy danych i kontrolować ruch pomiędzy strefami sieci.

2. Dostęp i uprawnienia

Konta powinny być indywidualne, z przypisanymi rolami i uprawnieniami – zarówno w oprogramowaniu, jak i na panelach HMI czy komputerach przemysłowych.

„Wspólne hasła i stale aktywne konta serwisowe uniemożliwiają ustalenie odpowiedzialności i późniejszą weryfikację, kto dokonał zmiany.”

3. Backup i wersjonowanie

„Backup musi być aktualny, chroniony i możliwy do odtworzenia.” W przypadku sterowników bezpieczeństwa istotne jest powiązanie konkretnej wersji backupu z numerem dokumentacji walidacyjnej i sumą kontrolną oprogramowania – tak, by w każdej chwili można było jednoznacznie zweryfikować, w jakim stanie zabezpieczeń znajduje się maszyna.

4. Kontrola zmian

To często najważniejszy punkt procesu zarządzania zmianą:

„Każda istotna zmiana powinna mieć właściciela, uzasadnienie, ocenę wpływu na bezpieczeństwo, zatwierdzenie oraz testy walidacyjne.”

Po zatwierdzeniu zmiany powinien nastąpić zapis wersji w protokole.

5. Wyłączanie nieużywanych funkcji i portów

Dostępy i porty wykorzystywane wyłącznie w okresie rozruchowym maszyny bywają pozostawiane aktywne na wiele tygodni dłużej niż potrzeba, tworząc niepotrzebną furtkę dostępową do funkcji bezpieczeństwa. Systematyczne blokowanie nieużywanych funkcji i portów jest jednym z najprostszych, a jednocześnie najskuteczniejszych działań.

Normy wspierające wdrożenie: IEC 62443 i projekt normy IEC 5742

Dwie normy pojawiają się najczęściej w rozmowach o zgodności cyberbezpieczeństwa maszyn. Norma IEC 62443 to rozbudowana, wieloczęściowa seria dokumentów – trzy jej części dotyczą bezpośrednio maszyn, natomiast całość opisuje głównie procesy organizacyjne oraz wymagania systemowe i komponentowe dla producentów cyfrowych elementów instalowanych na maszynach.

Drugim dokumentem jest projekt normy IEC 5742, tworzony z konkretnym celem wsparcia zgodności z Rozporządzeniem Maszynowym. Projekt ten – choć dostępny do zakupu – nie jest jeszcze zharmonizowany z rozporządzeniem. Prezentuje dwie ścieżki postępowania:

• Ścieżka A – klasyczny, samodzielny proces obejmujący ocenę zagrożeń (threat assessment), określenie security context, dobór środków ochronnych, walidację i dokumentację. To droga, którą najprawdopodobniej wybierze większość organizacji nieposiadających jeszcze pełnej walidacji zgodnej z IEC 62443.
• Ścieżka B – wykorzystanie już uruchomionych procesów zgodnych z normą IEC 62443, właściwa dla organizacji, które tę normę stosują od dawna.

Co warto zrobić już teraz – rekomendowane kroki

• Przejrzeć wszystkie aktualne oceny ryzyka maszyn i uzupełnić je o identyfikację zagrożeń cybernetycznych oraz security context.
• Zaktualizować procedury zarządzania zmianą, tak aby obejmowały walidację programów bezpieczeństwa (safety PLC) i dokumentowanie ryzyka resztkowego.
• Zweryfikować, czy stosowane komponenty cyfrowe spełniają wymagania CRA i posiadają potwierdzenie podejścia Security by Design.
• Wdrożyć segmentację sieci, indywidualne konta dostępowe oraz mechanizmy backupu i wersjonowania dla sterowników bezpieczeństwa.
• Przygotować dokumentację (raporty oceny ryzyka, protokoły walidacyjne) zgodną z podejściem prezentowanym w normach IEC 62443 i projekcie IEC 5742.
• Zweryfikować z jednostką notyfikującą, czy dotychczasowe raporty oceny zgodności wymagają aktualizacji w związku z nowymi przepisami.

Podsumowanie

Cyberbezpieczeństwo maszyn i linii produkcyjnych nie jest już wyłącznie domeną działów IT – od 20 stycznia 2027 r. staje się formalnym elementem oceny bezpieczeństwa maszynowego, budowanym na tej samej metodologii (ISO 12100), lecz rozszerzonym o identyfikację zagrożeń cyfrowych. Celem nie jest spełnienie wymogu dla samego wymogu, lecz nauczenie się zadawania właściwych pytań przy każdej ocenie ryzyka, wizji lokalnej czy planowaniu nowej inwestycji. Firmy, które już teraz zaczną traktować zarządzanie dostępem, wersjonowanie i kontrolę zmian jako podstawę cyberbezpieczeństwa maszynowego, będą znacznie lepiej przygotowane na nadchodzące wymagania regulacyjne.

Niniejszy artykuł ma charakter informacyjny i edukacyjny, oparty na treści webinaru branżowego. Nie stanowi porady prawnej. W celu oceny zgodności konkretnej maszyny lub linii produkcyjnej z Rozporządzeniem Maszynowym, CRA, AI Act czy NIS-2 zalecany jest kontakt z właściwą jednostką notyfikującą lub do nas na https://www.akademiaelokon.pl/kontakt/.

FAQ – najczęściej zadawane pytania