Rozporządzenie w sprawie maszyn od 20 stycznia 2027: czego wymaga od oprogramowania maszyn

20 stycznia 2027 dyrektywę maszynową zastępuje rozporządzenie (UE) 2023/1230, czyli rozporządzenie w sprawie maszyn. Większość jego treści wyda się znajoma każdemu, kto buduje maszyny z oznakowaniem CE. Jedna część nie. Po raz pierwszy prawo dotyczące maszyn nakłada obowiązki bezpośrednio na oprogramowanie: maszyna musi wskazywać, jakiego oprogramowania potrzebuje do bezpiecznego działania, zauważać zmiany tego oprogramowania lub jego konfiguracji, opierać się uszkodzeniu i przez pięć lat przechowywać ślad aktualizacji oprogramowania bezpieczeństwa.

Ten tekst jest dla kierowników działów konstrukcyjnych i automatyki u producentów maszyn. Jeśli po tej dacie dostarczasz maszyny do UE, te wymagania trafią do programów PLC, HMI, zdalnego dostępu i zaplecza aktualizacji.

Co faktycznie mówi prawo

Komisja Europejska stwierdza, że rozporządzenie „ma obowiązkowe zastosowanie od 20 stycznia 2027” i że „włącza przepisy dotyczące cyberbezpieczeństwa w odniesieniu do oprogramowania, danych istotnych dla zgodności i układów sterowania związanych z bezpieczeństwem”. Tekst opublikowany w 2023 podawał 14 stycznia; sprostowanie przesunęło tę datę.

Obowiązki dotyczące oprogramowania znajdują się w dwóch zasadniczych wymaganiach w zakresie ochrony zdrowia i bezpieczeństwa w załączniku III do rozporządzenia.

Pkt 1.1.9, zabezpieczenie przed uszkodzeniem. W skrócie:

• Połączenie z maszyną innego urządzenia, bezpośrednio albo zdalnie, nie może prowadzić do sytuacji zagrożenia.
• Oprogramowanie i dane, które mają zasadnicze znaczenie dla spełnienia wymagań bezpieczeństwa, „należy określić” i zabezpieczyć przed przypadkowym lub zamierzonym uszkodzeniem.
• Sprzęt, który przenosi sygnały lub dane dające dostęp do tego oprogramowania (na przykład port programowania albo interfejs sieciowy sterownika bezpieczeństwa), też musi być zabezpieczony, a maszyna musi rejestrować dowody interwencji w ten sprzęt.
• Maszyna lub produkt powiązany „muszą rozpoznawać zainstalowane w nich oprogramowanie, które jest niezbędne do zapewnienia bezpiecznego działania, i być w stanie dostarczyć te informacje w każdej chwili w łatwo dostępnej formie”.
• Maszyna lub produkt powiązany „rejestrują dowody uprawnionej lub nieuprawnionej interwencji w odniesieniu do oprogramowania lub zmiany oprogramowania zainstalowanego w maszynie lub produkcie powiązanym albo ich konfiguracji”.

Pkt 1.2.1, bezpieczeństwo i niezawodność układów sterowania. Układy sterowania muszą wytrzymywać „racjonalnie przewidywalne próby doprowadzenia do sytuacji zagrożenia podejmowane w złym zamiarze przez strony trzecie”. Lit. f dodaje obowiązek rejestrowania: rejestrowanie danych wygenerowanych w związku z ingerencją oraz wersji oprogramowania bezpieczeństwa zainstalowanych po wprowadzeniu maszyny do obrotu musi być „możliwe przez okres pięciu lat od daty instalacji”. Rejestr służy wyłącznie wykazaniu zgodności na uzasadniony wniosek organu krajowego i niczemu więcej.

Na liście jest też to: dokumentacja techniczna musi umożliwiać udostępnienie organowi na jego wniosek „kodu źródłowego lub logiki programowania zawartych w oprogramowaniu odnoszącym się do bezpieczeństwa” (załącznik IV).

Których maszyn to dotyczy

Przepisy obejmują maszyny wprowadzane do obrotu od 20 stycznia 2027. Maszyny wprowadzone do obrotu na podstawie starej dyrektywy przed tą datą można dalej sprzedawać (art. 52), a nowe przepisy dotyczące oprogramowania nie sięgają parku maszyn, który już pracuje u klientów.

Haczyk tkwi w znaczeniu „wprowadzenia do obrotu”. Niebieski przewodnik Komisji mówi, że to pojęcie „odnosi się do każdego egzemplarza produktu, a nie typu produktu”. Każdy egzemplarz, który od 20 stycznia 2027 opuszcza fabrykę do klienta w UE, musi spełniać nowe wymagania, łącznie z oprogramowaniem. Rodzina maszyn produkowana w sposób ciągły potrzebuje gotowego oprogramowania sterującego przed pierwszym egzemplarzem z 2027, a nie przy następnej zmianie modelu.

Przemyślenia wymagają też późniejsze aktualizacje. Zmiana dokonana „za pomocą środków fizycznych lub cyfrowych”, której producent nie przewidział, a która tworzy nowe zagrożenie albo zwiększa ryzyko, może być istotną modyfikacją. Motyw 32 mówi, że ocena ryzyka powinna obejmować aktualizacje oprogramowania przewidziane w chwili wprowadzenia do obrotu, więc opisz w niej swoją ścieżkę aktualizacji już teraz.

Co to oznacza w każdej warstwie maszyny

Sterownik bezpieczeństwa i PLC

• Zdecyduj, co jest istotne dla bezpieczeństwa. Zwykle jest to program bezpieczeństwa, ale może obejmować standardowy kod PLC zasilający funkcję bezpieczeństwa, parametry bezpieczeństwa w napędach oraz konfigurację skanerów laserowych albo kurtyn świetlnych. Zapisz to dla każdej rodziny maszyn; od tego zależy cała reszta.
• Wzorzec i porównanie. Dla każdej wydanej konfiguracji zapisz sumę kontrolną albo podpis każdego elementu istotnego dla bezpieczeństwa. Przy starcie i w regularnych odstępach maszyna porównuje to, co działa, z tym wzorcem i rejestruje każdą różnicę. To wyłapuje interwencję, która ominęła kontrolę dostępu, na przykład laptop podłączony bezpośrednio do sterownika.
• Zablokuj dostęp inżynierski. Hasła na programie bezpieczeństwa, wyłączone nieużywane porty i usługi oraz dostęp inżynierski wyłącznie ścieżką, która uwierzytelnia osobę i rejestruje, co zrobiła.

HMI

• Ekran identyfikacji oprogramowania z listą oprogramowania istotnego dla bezpieczeństwa, z wersjami i sumami kontrolnymi. Odczytuj wartości na żywo z urządzeń. Strona przepisana ręcznie w chwili wydania rozjeżdża się z rzeczywistością, a wymaganie mówi „w każdej chwili”.
• Ekrany parametrów. Pkt 1.2.1 lit. d wyklucza zmiany ustawień lub zasad, które mogą prowadzić do sytuacji zagrożenia. Parametry związane z bezpieczeństwem należą za poziomy dostępu, z limitami egzekwowanymi w sterowniku, a nie tylko w HMI, a każda zmiana jest rejestrowana: kto, kiedy, stara wartość i nowa.

Zdalny dostęp

Pkt 1.1.9 wprost wymienia urządzenia zdalne. W praktyce:

• Funkcje bezpieczeństwa pozostają lokalne. Sesja zdalna może czytać, diagnozować i przygotować zmianę. Nie może obejść zatrzymania, osłony ani urządzenia zezwalającego.
• Sesje są uwierzytelniane dla każdej osoby, a nie przez wspólne konto serwisowe, a klient widzi, kiedy sesja jest otwarta.
• Każdy początek i koniec sesji oraz każda zmiana trafiają do tego samego rejestru dowodów co interwencje lokalne.

Zaplecze i proces aktualizacji

Jeśli dostarczasz aktualizacje po wysyłce maszyny, Twój serwer aktualizacji wchodzi w zakres tej pracy. Dla każdego numeru seryjnego musisz wiedzieć, która wersja oprogramowania bezpieczeństwa została zainstalowana, kiedy i przez kogo. Podpisuj aktualizacje i niech maszyna sprawdza podpis, zanim cokolwiek zainstaluje.

Sam rejestr

Rozporządzenie nie mówi, gdzie ma się znajdować rejestr. Naszym zdaniem kopia, która się liczy, jest na maszynie, bo wielu klientów nie zgodzi się na stałe połączenie. Lustrzana kopia w chmurze się przydaje, ale nie może być jedyną.

Wolumen jest niewielki: interwencje i instalacje oprogramowania bezpieczeństwa, a nie dane procesowe. Pięć lat zmieści się w pamięci lokalnej, jeśli celowo dobierzesz jej rozmiar. Chroń rejestr przed usunięciem i upewnij się, że przetrwa wymianę sterownika. Jeśli wpisy wskazują technika z imienia i nazwiska, są to dane osobowe w zakładzie klienta: rejestruj to, czego wymaga przepis, i nic więcej.

Co daje producent sterownika, a czego nie daje

Platforma sterownika dostarczy część tych funkcji. Zanim cokolwiek zbudujesz, sprawdź, co oferuje: podpis albo sumę kontrolną programu bezpieczeństwa, ochronę hasłem, zarządzanie użytkownikami, dziennik zmian, odczyt wersji. Wykorzystaj wszystko, co jest.

To są klocki. Producent sterownika nie wie, które z Twoich napędów i skanerów są istotne dla bezpieczeństwa, nie widzi Twojej bramki zdalnego dostępu ani serwera aktualizacji i nie zdecyduje, jak dowody przetrwają pięć lat i wymianę sterownika. Skonfigurowanie tych funkcji, połączenie ich w całej maszynie i udokumentowanie wyniku to zadanie producenta maszyny, który podpisuje deklarację zgodności.

Jak to się ma do aktu o cyberodporności

Akt o cyberodporności (Cyber Resilience Act) ma własny kalendarz. Jego obowiązki zgłoszeniowe obowiązują od 11 września 2026, a pełne wymagania od 11 grudnia 2027. Rozporządzenie w sprawie maszyn wypada między tymi datami.

CRA przyznaje, że te przepisy się nakładają. Motyw 53 rozporządzenia (UE) 2024/2847 mówi, że producenci maszyn, które są też produktami z elementami cyfrowymi, powinni spełniać oba akty i że zgodność z CRA „mogłaby ułatwić” spełnienie wymagań z pkt 1.1.9 i 1.2.1. Producent musi wykazać taką synergię. Załącznik I do CRA wymaga ochrony integralności „komend, programów i konfiguracji” oraz powiadamiania o uszkodzeniach, co jest bliskie temu, czego wymaga pkt 1.1.9.

Jedna różnica ma znaczenie dla projektu rejestru. Wymóg CRA dotyczący rejestrowania i monitorowania aktywności wewnętrznej obowiązuje „z mechanizmem opt-out dla użytkownika”. Rejestr wymagany przez rozporządzenie w sprawie maszyn musi pozostać włączony przez pięć lat. Możesz zbudować jeden mechanizm rejestrowania, ale nie pozwól, by opt-out z CRA wyłączał rejestr maszynowy.

Buduj pod rozporządzenie w sprawie maszyn już teraz, bo przychodzi pierwsze, i zaprojektuj to tak, by ten sam magazyn dowodów, podpisywanie i rejestry aktualizacji służyły CRA w grudniu 2027.

Normy i nieudane odroczenie

Nie licz na to, że do 20 stycznia 2027 zostanie przywołana norma zharmonizowana obejmująca te wymagania. Strona Komisji o normach zharmonizowanych, zaktualizowana we wrześniu 2026, mówi, że pierwsza lista na podstawie rozporządzenia w sprawie maszyn jest w przygotowaniu. Przeniesie większość norm przywołanych na podstawie dyrektywy i doprecyzuje je tam, gdzie „jeszcze nie w pełni uwzględniają” nowe wymagania, a jej publikacji „można spodziewać się przed końcem tego roku”.

W styczniu 2026 CEMA, CECE, CECIMO, EGMF i FEM zwróciły się we wspólnym stanowisku branży o odroczenie pkt 1.1.9 i 1.2.1 lit. f do 11 grudnia 2027, zgodnie z CRA. Koszty zgodności oszacowały na „ponad 1 mln euro na architekturę platformy” i stwierdziły, że oczekiwane normy pozostają bardzo ogólne, jeśli chodzi o rejestr danych z pkt 1.2.1 lit. f.

Tego wniosku nie przyjęto. Rozporządzenie w sprawie maszyn zmieniono w lipcu 2026 rozporządzeniem (UE) 2026/1744, ale ta zmiana dotyczy systemów AI wysokiego ryzyka w maszynach i nie rusza daty stosowania. Planuj na 20 stycznia 2027.

Może się więc zdarzyć, że pierwszego dnia nie będzie normy dającej domniemanie zgodności z tymi dwoma wymaganiami. Wtedy dokumentacja techniczna musi opisywać rozwiązanie zastosowane dla każdego z nich (załącznik IV). Pisz ten opis w trakcie budowy, a nie po niej. Dla maszyn wymienionych w załączniku I część B jest jeszcze jeden krok: samodzielna ocena zgodności jest możliwa tylko wtedy, gdy normy zharmonizowane albo wspólne specyfikacje obejmują wszystkie odpowiednie wymagania; w przeciwnym razie udział bierze jednostka notyfikowana (art. 25). Maszyny niewymienione w załączniku I i tak podlegają samodzielnej ocenie.

Plan na 15 tygodni

Od poniedziałku 5 października 2026 do terminu jest nieco ponad 15 tygodni, ze świętami w środku. To mało, ale wykonalne, jeśli ustalisz priorytety według dat wysyłki: najpierw rodziny maszyn, których egzemplarze dla UE wyjeżdżają w styczniu.

1. Tygodnie 1 i 2 (od 5 do 16 października): zakres. Spisz każdą rodzinę maszyn, której egzemplarze trafią do UE po 20 stycznia 2027. Dla każdej spisz oprogramowanie i dane istotne dla bezpieczeństwa: program bezpieczeństwa, standardowy kod krytyczny dla zgodności, parametry bezpieczeństwa napędów i czujników, HMI, firmware, bramkę zdalnego dostępu. Wyznacz jednego właściciela dla każdej rodziny.
2. Tygodnie 3 i 4 (od 19 do 30 października): ocena ryzyka i luki. Zaktualizuj ocenę ryzyka o połączenia, zdalny dostęp, próby działania w złym zamiarze i ścieżkę aktualizacji. Sprawdź, co zapewnia platforma sterownika i co jest włączone.
3. Tygodnie od 5 do 9 (od 2 listopada do 4 grudnia): budowa. Ekran identyfikacji oprogramowania, porównanie ze wzorcem, kontrola dostępu inżynierskiego i zdalnego, rejestr o pojemności na pięć lat, podpisane aktualizacje i zapisy dla każdego numeru seryjnego w zapleczu.
4. Tygodnie 10 i 11 (od 7 do 18 grudnia): testy tak, jak zrobiłby to technik i atakujący. Zmień parametr bezpieczeństwa bezpośrednio narzędziem producenta i potwierdź, że maszyna to zarejestrowała. Wymień sterownik i sprawdź, czy rejestr przetrwał. Odetnij zasilanie w trakcie aktualizacji.
5. Tygodnie 12 i 13 (od 21 grudnia do 1 stycznia): święta. Nie planuj prac inżynierskich; zostaw test długotrwały, który wypełnia rejestr w stronę jego pięcioletniego rozmiaru.
6. Tygodnie 14 i 15 (od 4 do 15 stycznia): dokumentacja i wydanie. Wpisy w dokumentacji technicznej dotyczące pkt 1.1.9 i 1.2.1, instrukcja obsługi wyjaśniająca, jak klient odczytuje identyfikację oprogramowania i co zdalny dostęp może, a czego nie może, oraz krok produkcyjny, który wgrywa wydany wzorzec i zapisuje go dla każdego numeru seryjnego.

Jeśli tej pracy wymaga więcej architektur platform, niż zmieści się w tym oknie, powiedz o tym działowi sprzedaży już teraz: egzemplarz, który nie jest gotowy, nie może zostać zgodnie z prawem wprowadzony do obrotu w UE.

Dla kogo to nie jest

Maszyn wprowadzonych do obrotu przed 20 stycznia 2027 te przepisy dotyczące oprogramowania nie obejmują, chyba że ktoś później dokona ich istotnej modyfikacji. Jeśli kupujesz maszyny, a nie je budujesz, obowiązek spoczywa na dostawcy; Twoja rola to zapisanie w specyfikacjach wymogu identyfikacji oprogramowania i dostępu do rejestru.

Gdzie szukać pomocy

Jesteśmy firmą programistyczną, a nie jednostką notyfikowaną ani kancelarią prawną. Budujemy i zmieniamy oprogramowanie, w które trafiają te wymagania: aplikacje HMI i zaplecza, bramki zdalnego dostępu, procesy aktualizacji i rejestrowanie dowodów, we współpracy z automatykami, którzy odpowiadają za program bezpieczeństwa. Najtrudniejszym przypadkiem są starsze platformy z latami nagromadzonego kodu i tam zwykle zaczyna się nasza praca w ramach utrzymania systemów odziedziczonych, a stronę CRA omawia nasz przewodnik po akcie o cyberodporności. Jeśli Twój zespół ma plan, ale brakuje mu rąk, żeby skończyć do stycznia, napisz na office@c9group.dev.