Cyber Resilience Act i EU Data Act 2026: co polska firma produkcyjna musi zrobić przed 11 września

Wrzesień 2026 przynosi dwa unijne rozporządzenia, które wchodzą w życie praktycznie równocześnie i które polska branża produkcyjna w dużej mierze zignoruje do ostatniej chwili. Cyber Resilience Act zaczyna egzekwować obowiązki raportowania 11 września, EU Data Act uderza dzień później - 12 września. Nie jest to przypadkowy zbieg dat, lecz efekt wieloletniego procesu legislacyjnego, który zakończył się w podobnym czasie dla obu aktów. Skutek praktyczny jest taki, że firmy mają do ogarnięcia dwa różne reżimy naraz, każdy z własną logiką i własną listą wymagań.

Dlaczego właśnie teraz? Unia odpowiada na konkretne problemy z ostatnich lat. Ataki na infrastrukturę przemysłową - od Notpetya przez Triton po dziesiątki mniej głośnych incydentów w fabrykach - pokazały, że urządzenia IoT i oprogramowanie przemysłowe to otwarta furtka. Równocześnie firmy zaczęły zauważać, że dane z ich własnych maszyn są de facto własnością dostawcy - nie można ich łatwo wyeksportować ani przenieść do innego systemu. CRA adresuje bezpieczeństwo produktów cyfrowych, Data Act adresuje dostęp do danych. Razem tworzą nowe minimalne standardy dla cyfrowej infrastruktury produkcji.

Dla polskiej firmy produkcyjnej oba rozporządzenia mają jedno wspólne: wymagają, żeby ktoś faktycznie zajął się tematem przed wrześniem, a nie po pierwszej karze. Kary za naruszenie CRA sięgają 15 mln EUR lub 2,5% rocznego obrotu globalnego - wyższa z tych dwóch wartości. To nie jest przepis, który można zignorować z nadzieją, że inspektorzy nie dotrą do Łodzi czy Kielc.

Pierwsza i najważniejsza rzecz do ustalenia: czy twoja firma jest producentem urządzeń czy ich użytkownikiem. Różnica jest fundamentalna, bo CRA uderza bezpośrednio w producentów i importerów produktów z elementami cyfrowymi, a nie w końcowych użytkowników. Jeśli firma produkuje maszyny przemysłowe, które mają firmware, interfejs sieciowy albo możliwość zdalnego sterowania - jesteś producentem w rozumieniu CRA i masz pełny zestaw obowiązków. Jeśli kupujesz gotowe systemy MES od zewnętrznego dostawcy i używasz ich na hali - jesteś użytkownikiem, ale nadal powinieneś wiedzieć, czego wymagać od swojego dostawcy.

Wiele polskich firm jest jednocześnie w obu rolach i tego nie wie. Zakład, który produkuje maszyny pakujące z PLC i interfejsem webowym do zdalnego monitoringu, jest producentem w rozumieniu CRA - nawet jeśli sprzedaje te maszyny tylko do innych polskich fabryk. Zakład, który używa kupionego systemu SCADA do zarządzania linią, jest użytkownikiem - ale jeśli dobudował do tego SCADy własny moduł raportowy i udostępnia go klientom, sytuacja zaczyna się komplikować.

CRA obejmuje sterowniki PLC z interfejsem sieciowym, urządzenia IoT zbierające dane produkcyjne, oprogramowanie firmware wbudowane w maszyny, a także samodzielne aplikacje sprzedawane komercyjnie. Wyłączone są między innymi mikroprzedsiębiorcy spełniający określone warunki oraz oprogramowanie open-source rozwijane niekomercyjnie - ale wyłączenia mają swoje granice i warto je sprawdzić z prawnikiem znającym temat, zanim założymy, że nas to nie dotyczy.

Trzy obowiązki, które wchodzą od 11 września 2026, są konkretne i operacyjne. Pierwsze dwa dotyczą raportowania: aktywnie wykorzystywana podatność w produkcie musi być zgłoszona do ENISA w ciągu 24 godzin od jej wykrycia. Poważny incydent bezpieczeństwa musi być zgłoszony w ciągu 72 godzin. To nie jest termin "dobrze by było" - to obowiązek prawny z możliwością kary.

Trzecim wymaganiem, które wejdzie nieco później w ramach pełnego wdrożenia CRA, jest SBOM - Software Bill of Materials. To lista wszystkich komponentów oprogramowania: bibliotek, frameworków, zależności, ich wersji i znanych podatności. Producent musi wiedzieć, co dokładnie jest w jego produkcie, i być w stanie przekazać tę listę na żądanie. W praktyce oznacza to, że każda firma produkująca oprogramowanie przemysłowe musi mieć narzędzia do generowania SBOM i proces utrzymywania go na bieżąco.

Poza raportowaniem CRA wymaga, żeby producenci przez cały cykl życia produktu aktywnie monitorowali podatności, wydawali aktualizacje bezpieczeństwa i informowali użytkowników o problemach. To zmienia model biznesowy: sprzedanie maszyny z firmware i zapomnienie o niej nie jest już opcją. Oprogramowanie przemysłowe musi być serwisowane - analogicznie do tego, jak serwisuje się mechanikę. W aveneo od lat projektujemy systemy MES z myślą o aktualizacjach i monitoringu, ale branżowy standard nadal jest daleko od tego modelu. CRA wymusi zmianę, czy firmy tego chcą, czy nie.

EU Data Act wychodzi z innego miejsca niż CRA, ale dla fabryk jest równie praktyczny. Kluczowa zasada to data by design - produkty połączone z siecią, w tym maszyny przemysłowe z czujnikami, muszą być projektowane tak, żeby dane były domyślnie dostępne dla użytkownika, który za maszynę zapłacił. Brzmi oczywisto, ale branżowa rzeczywistość wyglądała inaczej: producenci maszyn często trzymali dane we własnych chmurach, dostęp przez API był ograniczony albo płatny, a przejście do konkurencyjnego serwisanta było technicznie zablokowane.

Data Act zabrania technicznego blokowania portabilności danych. Jeśli twoja fabryka zbiera dane produkcyjne przez system IoT lub SCADA, dostawca tego systemu nie może projektować go w sposób, który uniemożliwia eksport danych lub zmianę dostawcy chmury. Dla firm używających systemów MES oznacza to, że ich dane - parametry procesów, historię zdarzeń, dane jakościowe - powinny być dostępne przez standardowe API, niezależnie od tego, u kogo trzymana jest infrastruktura.

W praktyce Data Act dotyka przede wszystkim producentów maszyn z czujnikami sprzedawanych do innych firm, systemów IoT w fabrykach zbierających dane procesowe oraz rozwiązań MES i SCADA, które gromadzą dane produkcyjne. Dla firm budujących oprogramowanie przemysłowe - takich jak aveneo - oznacza to konieczność zadbania o otwarte API, mechanizmy eksportu danych w standardowych formatach i brak technicznych barier przy zmianie środowiska. To dobra zmiana, choć wymaga pracy po stronie dostawców, którzy przez lata budowali swoje przewagi na zamkniętych ekosystemach.

Pierwszym krokiem jest inwentaryzacja - i to zaskakująco często pomijany etap. Trzeba przejrzeć, które urządzenia i systemy w firmie mieszczą się w zakresie CRA lub Data Act: maszyny z firmware i interfejsem sieciowym, sterowniki PLC podłączone do sieci zakładowej, systemy zbierające dane z czujników, oprogramowanie sprzedawane lub licencjonowane klientom. Dopiero gdy masz tę listę, wiesz, co robić dalej. Wiele firm odkryje przy tej okazji, że ich portfel jest mniejszy niż myślały - albo większy.

Drugi krok to rozmowa z dostawcami oprogramowania i sprzętu. Każdy dostawca systemu MES, SCADA czy IoT, który wchodzi w zakres CRA, powinien mieć plan: jak generuje SBOM, jaki ma proces zarządzania podatnościami, jak wygląda procedura raportowania incydentów. Jeśli dostawca nie potrafi odpowiedzieć na te pytania przed końcem wakacji, to sygnał ostrzegawczy.

Trzeci krok to aktualizacja umów. Kontrakty z dostawcami oprogramowania powinny zawierać klauzule dotyczące CRA-compliance: zobowiązanie do wydawania aktualizacji bezpieczeństwa, czas reakcji na incydenty, dostarczanie SBOM. Bez tego firma-użytkownik nie ma żadnej formalnej dźwigni, gdy dostawca zaniedbuje bezpieczeństwo.

Czwarty krok dotyczy procedur wewnętrznych. Niezależnie od tego, czy firma jest producentem czy użytkownikiem, warto mieć napisaną procedurę reagowania na incydenty bezpieczeństwa IT. Kto ją uruchamia, kto decyduje o eskalacji, kto kontaktuje się z ENISA lub krajowym organem nadzoru - te decyzje powinny być podjęte z wyprzedzeniem, nie w środku nocy po ataku. Procedura nie musi być skomplikowana; ważne, żeby istniała i żeby ludzie o niej wiedzieli.

Piąty krok to weryfikacja dostępu do danych. Jeśli firma korzysta z systemów IoT lub MES zbierających dane produkcyjne, warto sprawdzić, czy dostawca zapewnia API do eksportu tych danych i czy istnieje mechanizm przenoszenia danych przy ewentualnej zmianie systemu. To nie tylko kwestia zgodności z Data Act - to też ochrona własnych interesów biznesowych. Dane z maszyn mają wartość analityczną i nie powinny być zakładnikiem jednego dostawcy.

Firma produkcyjna, która kupuje systemy MES, WMS czy IoT, ma prawo zadać swojemu software house'owi konkretne pytania - i powinna to zrobić przed podpisaniem kolejnego kontraktu lub odnowieniem licencji. Pierwsze pytanie brzmi: czy macie SBOM dla oprogramowania, które nam dostarcza? Dostawca powinien mieć możliwość wygenerowania listy komponentów i ich wersji. Jeśli tego nie potrafi, nie wie, co jest w swoim produkcie - i to jest informacja sama w sobie.

Drugie pytanie dotyczy procesu aktualizacji bezpieczeństwa: jak szybko reagujecie na nowo odkryte podatności w używanych bibliotekach i jaki jest gwarantowany czas wydania poprawki? Trzecie pytanie - dla firm korzystających z systemu opartego na chmurze dostawcy - to kwestia portabilności danych: w jakim formacie można wyeksportować wszystkie dane, jakie API umożliwia odczyt i czy zmiana dostawcy jest technicznie możliwa bez utraty historii. Odpowiedź "to wymaga osobnej wyceny" lub milczenie powinny być sygnałem do renegocjacji warunków.

W umowie warto zapisać kilka rzeczy wprost: zobowiązanie dostawcy do utrzymywania aktualizacji bezpieczeństwa przez określony czas po wdrożeniu, czas reakcji na zgłoszone podatności, obowiązek informowania klienta o poważnych incydentach dotyczących oprogramowania, a dla firm-producentów maszyn - zobowiązanie do dostarczania aktualnego SBOM. Bez tych klauzul wszystko zależy od dobrej woli dostawcy, a dobra wola jest zmienna.

Do 11 września zostało kilkanaście tygodni - wystarczająco dużo, żeby wykonać inwentaryzację i porozmawiać z dostawcami, ale zdecydowanie za mało, żeby budować od zera procedury i infrastrukturę bezpieczeństwa. Firmy, które zaczynają teraz, mają realistyczną szansę być w dobrej pozycji przed terminem. Firmy, które zaczną w sierpniu, będą gasić pożar.

Najważniejsza rzecz do zrobienia w ciągu najbliższych dwóch tygodni to ustalenie, czy firma w ogóle jest producentem w rozumieniu CRA - i jeśli tak, to szybka rozmowa z prawnikiem znającym temat oraz z dostawcami technologii. Jeśli firma jest wyłącznie użytkownikiem, priorytetem są kontrakty: przejrzyj umowy z dostawcami software'u pod kątem klauzul bezpieczeństwa i zaplanuj rozmowę o aktualizacjach.

W aveneo budujemy systemy MES, WMS i IoT dla produkcji od ponad piętnastu lat. Wiemy, jak wygląda migracja danych między systemami, jak zarządzać aktualizacjami firmware w środowisku produkcyjnym i gdzie w architekturze systemu leżą rzeczywiste ryzyka bezpieczeństwa. Jeśli chcesz porozmawiać konkretnie o tym, co CRA i Data Act oznaczają dla twojej fabryki - napisz do nas. Nie po to, żeby sprzedać projekt, ale żeby pomóc zorientować się w sytuacji. Wrzesień przyjdzie niezależnie od tego, czy jesteś gotowy.