Cyberbezpieczeństwo dla producentów maszyn

Od 2027 roku maszyna ze sterownikiem, wyświetlaczem operatora lub połączeniem do transmisji danych podlega dwóm rozporządzeniom UE. Oba zaczynają się od tego samego pytania: jakie oprogramowanie jest w tej maszynie, wersja po wersji, i co ono zawiera?

1. 11 września 2026Zaczynają obowiązywać wymogi Cyber Resilience Act dotyczące zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.
2. 20 stycznia 2027Zaczyna być stosowane rozporządzenie w sprawie maszyn, (UE) 2023/1230, które zastępuje dyrektywę maszynową.
3. 11 grudnia 2027Cyber Resilience Act, (UE) 2024/2847, jest stosowany w pełni.

Rozporządzenie w sprawie maszyn

Dwa zasadnicze wymagania w zakresie ochrony zdrowia i bezpieczeństwa z załącznika III dotyczą cyberbezpieczeństwa:

• 1.1.9, zabezpieczenie przed uszkodzeniem. Podłączenie do maszyny innego urządzenia, bezpośrednio lub zdalnie, nie może prowadzić do sytuacji niebezpiecznej. Oprogramowanie i dane, które mają kluczowe znaczenie dla zgodności maszyny z zasadniczymi wymaganiami w zakresie ochrony zdrowia i bezpieczeństwa, muszą być zidentyfikowane i chronione przed przypadkowym lub celowym uszkodzeniem. Maszyna musi identyfikować zainstalowane w niej oprogramowanie, którego potrzebuje do bezpiecznego działania, i zawsze udostępniać tę informację. Musi też gromadzić dowody uprawnionych lub nieuprawnionych ingerencji w to oprogramowanie lub jego konfigurację.
• 1.2.1, bezpieczeństwo i niezawodność układów sterowania. Układy sterowania muszą być odporne na racjonalnie przewidywalne złośliwe próby osób trzecich prowadzące do sytuacji niebezpiecznej. Zgodnie z 1.2.1 lit. f) muszą prowadzić rejestr ingerencji oraz wersji oprogramowania bezpieczeństwa wgranych po wprowadzeniu maszyny do obrotu, przez pięć lat od wgrania.

Cyber Resilience Act

Maszyna z połączeniem do transmisji danych lub jej część sprzedawana osobno to produkt z elementami cyfrowymi. Producent musi zachować należytą staranność wobec integrowanych komponentów stron trzecich, sporządzić SBOM obejmujący co najmniej zależności najwyższego poziomu, obsługiwać podatności przez okres wsparcia, który wynosi co najmniej pięć lat, chyba że produkt ma być używany krócej, oraz przechowywać dokumentację techniczną przez co najmniej dziesięć lat lub przez okres wsparcia, w zależności od tego, który z tych okresów jest dłuższy.

Nie automatycznie. Cyber Resilience Act nie daje domniemania zgodności z rozporządzeniem w sprawie maszyn. Jego motyw 53 stanowi, że spełnienie zasadniczych wymagań CRA może ułatwić spełnienie wymagań rozporządzenia w sprawie maszyn dotyczących ochrony przed uszkodzeniem oraz bezpieczeństwa i niezawodności układów sterowania. Stanowi też, że producent musi to wykazać, na przykład stosując normy zharmonizowane po przeprowadzeniu oceny ryzyka, oraz że procedury oceny zgodności obu rozporządzeń nadal mają zastosowanie.

Normą zharmonizowaną opracowywaną dla pkt 1.1.9 jest EN 50742, Safety of machinery – Protection against corruption. W listopadzie 2026 r. był to projekt końcowy, FprEN 50742, obejmujący pkt 1.1.9 i powiązane punkty 1.2.1; dopóki odniesienie do wersji ostatecznej nie zostanie opublikowane w Dzienniku Urzędowym UE, norma nie daje domniemania zgodności. Łączy ocenę ryzyka z EN ISO 12100 z koncepcjami bezpieczeństwa z IEC 62443 i uznaje konsekwentne stosowanie IEC 62443-4-1, IEC 62443-3-3 i IEC 62443-4-2 za równoważną drogę do osiągnięcia jej celów ochrony. IEC 62443-4-2 określa techniczne wymagania bezpieczeństwa dla komponentów systemów sterowania, stopniowane według poziomu zdolności bezpieczeństwa (security capability level). W Niemczech zasady badań GS-IFA-M25 z lipca 2026 r. przekładają zabezpieczenie przed uszkodzeniem na 66 kryteriów badań, z terminologią prEN 50742. Jedno z nich, T46, wymaga, aby produkt mógł na żądanie podać zainstalowaną wersję oprogramowania i konfigurację. Aby odpowiedzieć na to dla każdej konfiguracji, potrzebny jest zapis tego, co zawiera każda wersja oprogramowania.

Rozporządzenie w sprawie maszyn ma własne domniemanie, które działa inną drogą: przez europejskie programy certyfikacji cyberbezpieczeństwa przyjęte na podstawie aktu o cyberbezpieczeństwie (Cybersecurity Act), rozporządzenia (UE) 2019/881. Certyfikat lub deklaracja zgodności w ramach takiego programu daje domniemanie zgodności z 1.1.9 i 1.2.1 w zakresie, w jakim obejmuje te wymagania.

Jedna ocena ryzyka i jeden zestaw dowodów mogą więc służyć obu rozporządzeniom, ale zgodność wykazuje się z każdym z nich. Jeśli Państwa maszyna ma połączenie do transmisji danych, warto planować pod oba. Dowody dotyczące oprogramowania, czyli SBOM-y, rejestry podatności i historia aktualizacji, to część, która jest im wspólna.

W styczniu 2026 roku stowarzyszenia branży maszynowej wystąpiły o odroczenie 1.1.9 i 1.2.1 lit. f), a w marcu 2026 roku o ich stosowanie od daty CRA, czyli od 11 grudnia 2027. To wniosek, a nie prawo: według stanu na listopad 2026 roku nie przyjęto żadnego odroczenia. Daty na tej stronie to daty z rozporządzeń.

• Maszyny budowlane, do przeładunku materiałów, górnicze i przemysłowe podlegają rozporządzeniu w sprawie maszyn, a także CRA, gdy maszyna lub jej części mają połączenie do transmisji danych.
• Ciągniki rolnicze i leśne objęte rozporządzeniem (UE) nr 167/2013 są wyłączone z rozporządzenia w sprawie maszyn, z wyjątkiem zamontowanych na nich maszyn. Lista wyłączeń CRA nie wymienia tego rozporządzenia, więc połączony ciągnik może podlegać CRA.
• Pojazdy drogowe homologowane na podstawie rozporządzenia (UE) 2019/2144 są wyłączone z CRA.
• Komponenty sprzedawane osobno. CRA ma zastosowanie także do komponentów oprogramowania i sprzętu wprowadzanych do obrotu oddzielnie. Dostawca, który sprzedaje osobno sterownik ECU lub jednostkę telematyczną, jest sam producentem w rozumieniu CRA. Gdy jednostka jest tylko wbudowana w maszynę, obowiązek dotyczący całej maszyny spoczywa na producencie maszyny, który musi zachować należytą staranność wobec komponentu dostawcy.

To informacja ogólna, a nie porada prawna. Proszę sprawdzić klasyfikację własnego produktu.

W jednej maszynie oprogramowanie pochodzi z różnych źródeł, a wiarygodnie powiedzieć, co jest w danym oprogramowaniu, może tylko zespół, który je buduje. Jak słyszymy od producentów maszyn, sterowniki ECU typu bare metal zawierają mało open source, a oprogramowanie dla Linuxa, Androida i Windows bardzo dużo.

Małe wolumeny, duża różnorodność. Producent maszyn może mieć na rynku setki platform, sprzedawać kilka sztuk każdej rocznie i konfigurować wiele maszyn na zamówienie. Każda konfiguracja to inny zestaw oprogramowania, więc SBOM dla każdego buildu ma większe znaczenie niż SBOM dla każdej linii produktów.

Długi cykl życia. Maszyny pracują dziesięć lat lub dłużej, a w tym czasie dostawcy się zmieniają albo znikają z rynku. Zapis tego, co trafiło do wersji oprogramowania, trzeba sporządzić podczas jej budowania, bo po latach nie da się go odtworzyć.

Dominuje oprogramowanie dostawców, a SBOM-y dostawców są często słabe. Słyszymy o SBOM-ach dostawców z brakującymi komponentami, bez package URL ani CPE, bez licencji i bez skrótów, niektórych pisanych ręcznie i niezgodnych ze schematem. Analiza binarna wgranego ECU to rozwiązanie doraźne: zgaduje zawartość, zamiast ją rejestrować.

Ryzyko leży w warstwach połączonych z siecią. Duża część logiki ECU jest generowana z modeli i zawiera mało open source. Open source i ekspozycja sieciowa koncentrują się w warstwach Linuxa, łączności i aplikacji, więc tam warto najpierw skierować wysiłki.

Przykład poglądowy: stos oprogramowania fikcyjnej platformy ładowarki kołowej, od chmury po sterowniki ECU.

1. Backend w chmurze i aplikacja towarzyszącaRozwijane we własnym zakresie. Głównie open source i dostępne z sieci. Cyber Resilience Act.
2. Bramka telematycznaEmbedded Linux, głównie open source, połączona z siecią komórkową. Cyber Resilience Act oraz 1.1.9 ze względu na połączenie zdalne.
3. Wyświetlacz operatoraObraz embedded Linux z frameworkiem UI, głównie open source, połączony z magistralą maszyny i narzędziami serwisowymi. Cyber Resilience Act i 1.1.9.
4. Sterownik maszynyWłasna aplikacja na platformie dostawcy, istotna dla bezpieczeństwa. 1.1.9 i 1.2.1 oraz Cyber Resilience Act tam, gdzie jest osiągalny przez połączenie.
5. Sterowniki ECU hydrauliki, układu kierowniczego i silnikaFirmware dostawcy, własnościowy i generowany z modeli, mało open source, istotny dla bezpieczeństwa. 1.1.9 i 1.2.1; Cyber Resilience Act przez maszynę.

Open source i ekspozycja sieciowa znajdują się w trzech górnych warstwach, i tam też zwykle są Państwa własne pipeline'y buildów. Od nich warto zacząć.

Producenci maszyn stawiają dziś wymagania dotyczące SBOM dla kupowanego oprogramowania, takie jak package URL lub CPE, licencje, skróty i format przechodzący walidację, i odsyłają pliki, które ich nie spełniają. Jeśli budują Państwo w GitHub Actions, CRACI generuje SBOM z samego buildu, więc wymienia to, co faktycznie trafiło do wydania, łącznie z komponentami, których nie wymienia żaden lockfile, z package URL i zadeklarowaną licencją dla każdego komponentu. Eksport warto sprawdzić z pełną listą pól, o które prosi klient. Więcej o odpowiadaniu na prośby klientów o SBOM.