Regulacje •

Cyber Resilience Act (UE) 2024/2847 — obowiązki producenta od 11 września 2026

Cyber Resilience Act obejmuje każdy produkt z elementami cyfrowymi. Zgłaszanie podatności rusza 11 września 2026, pełne stosowanie 11 grudnia 2027. Okres wsparcia, SBOM i informacje dla użytkownika stają się polami danych.

Autor: Zespół myDPP

Cyber Resilience Act (UE) 2024/2847 — obowiązki producenta od 11 września 2026

Przez dwadzieścia lat cyberbezpieczeństwo produktu było w Unii regulowane wyrywkowo: trochę przez dyrektywę radiową, trochę przez przepisy sektorowe, w większości wcale. Rozporządzenie (UE) 2024/2847 — Cyber Resilience Act — kończy ten stan. Obejmuje każdy produkt z elementami cyfrowymi udostępniany na rynku unijnym, od routera po bibliotekę oprogramowania sprzedawaną jako produkt, i wiąże go z oznakowaniem CE.

Najbliższy termin nie jest odległy. 11 września 2026 zaczynają obowiązywać obowiązki zgłoszeniowe: aktywnie wykorzystywane podatności i poważne incydenty trzeba raportować w ciągu 24 godzin. Dotyczy to również produktów, które są już na rynku. Pełne stosowanie przychodzi 11 grudnia 2027. Dla producentów oznacza to nie tylko nową pracę inżynierską, ale też nowy zestaw danych, które muszą trafić do użytkownika i pozostać prawdziwe przez lata — ten sam problem, który cyfrowy paszport produktu rozwiązuje w innych obszarach zgodności.


Najważniejsze w skrócie

  • Rozporządzenie (UE) 2024/2847 weszło w życie 10 grudnia 2024. Stosuje się etapami: przepisy o jednostkach notyfikowanych od 11 czerwca 2026, obowiązki zgłoszeniowe od 11 września 2026, pełne stosowanie od 11 grudnia 2027.
  • Zakres jest horyzontalny: produkty z elementami cyfrowymi — sprzęt i oprogramowanie, których użycie obejmuje bezpośrednie lub pośrednie połączenie danych z urządzeniem lub siecią. Wyłączone są produkty objęte odrębnymi reżimami: wyroby medyczne, pojazdy silnikowe, lotnictwo cywilne, wyposażenie morskie oraz obszar obronności.
  • Większość produktów przechodzi samoocenę (moduł A). Produkty ważne z załącznika III klasy I wymagają jednostki notyfikowanej, jeżeli nie zastosowano w pełni norm zharmonizowanych; klasa II i produkty krytyczne z załącznika IV wymagają jednostki notyfikowanej albo certyfikacji zawsze.
  • Okres wsparcia ustala producent, ale co do zasady nie może być krótszy niż pięć lat — chyba że przewidywany czas użytkowania produktu jest krótszy. Data jego zakończenia (miesiąc i rok) musi być podana przy zakupie.
  • SBOM — wykaz komponentów oprogramowania w formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu — jest wymogiem załącznika I. Trzeba go utrzymywać w aktualności i okazać organom nadzoru rynku na żądanie.
  • Aktualizacje bezpieczeństwa są bezpłatne, a po wydaniu muszą pozostać dostępne przez co najmniej dziesięć lat albo do końca okresu wsparcia, jeżeli jest dłuższy.
  • Zgodność potwierdza deklaracja zgodności UE i oznakowanie CE — te same instrumenty co w pozostałym prawie produktowym.
  • Najwyższy próg sankcji za naruszenie wymagań zasadniczych oraz obowiązków z art. 13 i 14 to 15 mln EUR albo 2,5% światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa.
  • CRA nie ustanawia cyfrowego paszportu produktu. Tworzy natomiast zestaw informacji przypisanych do produktu i wersji, które muszą pozostać osiągalne przez lata — a to jest problem zarządzania danymi.

Czym właściwie jest Cyber Resilience Act

CRA jest aktem horyzontalnym, czyli takim, który nie opisuje jednej branży, lecz cechę wspólną produktów. Tą cechą jest obecność elementu cyfrowego i zdolność do wymiany danych. Konstrukcyjnie rozporządzenie należy do rodziny prawa produktowego znanej z oznakowania CE: są wymagania zasadnicze w załączniku, jest ocena zgodności, jest dokumentacja techniczna, jest deklaracja i jest znak.

Nowość polega na czymś innym. Dotychczasowe prawo produktowe oceniało wyrób w momencie wprowadzenia do obrotu — potem zainteresowanie regulatora w praktyce się kończyło. CRA tego założenia nie przyjmuje. Obowiązek obsługi podatności, wydawania aktualizacji i zgłaszania incydentów biegnie przez cały zadeklarowany okres wsparcia. Produkt zgodny w dniu sprzedaży może stać się niezgodny dwa lata później, jeżeli producent przestanie łatać znane podatności.

Warto też odnotować porządkowanie, które CRA wprowadza w istniejącym prawie. Rozporządzenie delegowane (UE) 2022/30, które od 2025 roku realizowało wymagania cyberbezpieczeństwa przez dyrektywę radiową, zostaje uchylone z dniem pełnego stosowania CRA — 11 grudnia 2027. Wymagania zasadnicze załącznika I obejmują wszystko, co pokrywały przepisy radiowe, więc podwójny reżim zniknie.

Co to jest „produkt z elementami cyfrowymi”

Definicja jest szeroka i to jest celowe. Chodzi o produkt sprzętowy lub programowy, którego zamierzone albo racjonalnie przewidywalne użycie obejmuje bezpośrednie lub pośrednie połączenie danych z urządzeniem lub siecią. Obejmuje to zdalne rozwiązania przetwarzania danych, jeżeli są niezbędne do działania produktu.

W praktyce łatwiej wskazać, co jest poza zakresem, bo lista wyłączeń jest zamknięta i konkretna:

  • Wyroby medyczne i wyroby medyczne do diagnostyki in vitro — rozporządzenia (UE) 2017/745 i (UE) 2017/746.
  • Pojazdy silnikowe — rozporządzenie (UE) 2019/2144.
  • Lotnictwo cywilne — rozporządzenie (UE) 2018/1139.
  • Wyposażenie morskie — dyrektywa 2014/90/UE.
  • Produkty opracowane wyłącznie do celów bezpieczeństwa narodowego lub obronności oraz produkty nieudostępniane w ramach działalności handlowej.

Poza tymi wyłączeniami zakres jest bardzo szeroki. Oprogramowanie sprzedawane jako produkt jest objęte tak samo jak urządzenie. Wolne i otwarte oprogramowanie rozwijane niekomercyjnie nie jest — ale rozporządzenie tworzy w art. 24 osobną, lżejszą rolę opiekuna oprogramowania open source, dla podmiotów, które w sposób trwały wspierają rozwój takiego oprogramowania przeznaczonego do zastosowań komercyjnych.

Trzy poziomy ryzyka i trzy ścieżki oceny

Rozporządzenie stopniuje rygor według skutków, jakie może wywołać naruszenie bezpieczeństwa danego produktu.

Produkty domyślne — zdecydowana większość rynku. Producent przeprowadza ocenę wewnętrzną (moduł A), sam sporządza dokumentację techniczną i deklarację. Jednostka notyfikowana nie jest potrzebna.

Produkty ważne, załącznik III klasa I — między innymi menedżery haseł, oprogramowanie antywirusowe, systemy zarządzania tożsamością i dostępem uprzywilejowanym, VPN, systemy operacyjne, routery i przełączniki, mikroprocesory z funkcjami związanymi z bezpieczeństwem, asystenci domowi, zabawki podłączone do internetu i urządzenia ubieralne. Samoocena pozostaje możliwa, ale tylko przy pełnym zastosowaniu norm zharmonizowanych albo wspólnych specyfikacji. Bez nich wchodzi jednostka notyfikowana.

Produkty ważne, załącznik III klasa II — na przykład zapory sieciowe, systemy wykrywania i zapobiegania włamaniom, hipernadzorcy oraz mikroprocesory odporne na manipulację. Tu jednostka notyfikowana albo europejski program certyfikacji cyberbezpieczeństwa jest obowiązkowy.

Produkty krytyczne, załącznik IV — najwyższy rygor, obowiązkowa jednostka notyfikowana albo certyfikacja. Opisy techniczne kategorii doprecyzowuje rozporządzenie wykonawcze (UE) 2025/2392.

Praktyczny wniosek jest ten sam, co przy każdej regulacji z udziałem jednostek notyfikowanych: klasyfikację trzeba przeprowadzić wcześnie. Jeżeli produkt trafia do klasy II albo do załącznika IV, termin jednostki notyfikowanej staje się elementem planu wprowadzenia produktu na rynek, a nie formalnością na końcu.

Obowiązki producenta — co realnie trzeba zrobić

Wymagania zasadnicze, część pierwsza: właściwości produktu

Załącznik I część I opisuje, jaki produkt ma być. Kluczowe punkty: wprowadzany do obrotu bez znanych podatności możliwych do wykorzystania, dostarczany z bezpieczną konfiguracją domyślną i możliwością przywrócenia do stanu fabrycznego, chroniący poufność, integralność i dostępność danych, minimalizujący powierzchnię ataku, ograniczający zbieranie danych do niezbędnych oraz umożliwiający instalowanie aktualizacji bezpieczeństwa — w miarę możliwości automatycznie i z wyraźnym powiadomieniem użytkownika.

Wymagania zasadnicze, część druga: obsługa podatności

Załącznik I część II opisuje proces, który musi działać przez cały okres wsparcia:

  • SBOM w formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu, utrzymywany w aktualności. Nie ma obowiązku publikowania go użytkownikom, ale trzeba go okazać organom nadzoru rynku na żądanie.
  • Usuwanie podatności bez zbędnej zwłoki, w tym przez wydawanie aktualizacji bezpieczeństwa.
  • Regularne testy i przeglądy bezpieczeństwa.
  • Publiczne ujawnienie informacji o usuniętych podatnościach po udostępnieniu poprawki.
  • Polityka skoordynowanego ujawniania podatności oraz jeden punkt kontaktowy do ich zgłaszania.
  • Bezpłatna dystrybucja aktualizacji bezpieczeństwa bez zbędnej zwłoki.

Okres wsparcia — nowe pole danych o skutkach handlowych

To zobowiązanie, które najczęściej zaskakuje. Producent sam ustala okres wsparcia, w którym skutecznie obsługuje podatności produktu, ale nie może on być krótszy niż pięć lat — chyba że przewidywany czas użytkowania produktu jest krótszy niż pięć lat. Data zakończenia, z dokładnością do miesiąca i roku, musi być jasno podana w momencie zakupu.

Do tego dochodzi drugi horyzont. Aktualizacja bezpieczeństwa raz wydana musi pozostać dostępna przez co najmniej dziesięć lat od jej udostępnienia albo do końca okresu wsparcia, jeżeli ten kończy się później. To zobowiązanie infrastrukturalne: ktoś musi utrzymać osiągalność plików i informacji przez dekadę, przez zmiany systemów i domen.

Zgłaszanie podatności i incydentów — termin 11 września 2026

Artykuł 14 wprowadza obowiązki, które ruszają najwcześniej i obejmują także produkty już obecne na rynku. Zgłaszać trzeba aktywnie wykorzystywane podatności oraz poważne incydenty mające wpływ na bezpieczeństwo produktu — do zespołu CSIRT państwa głównej siedziby producenta oraz do ENISA, za pośrednictwem wspólnej platformy zgłoszeniowej.

EtapTermin
Wczesne ostrzeżenie24 godziny
Zgłoszenie właściwe72 godziny
Sprawozdanie końcowe — podatność14 dni od udostępnienia środka naprawczego
Sprawozdanie końcowe — poważny incydent1 miesiąc

Doba na wczesne ostrzeżenie jest terminem operacyjnym, nie prawniczym. Oznacza to, że dyżur, ścieżka decyzyjna i dostęp do platformy muszą istnieć zawczasu. Mikroprzedsiębiorstwa i małe przedsiębiorstwa nie podlegają grzywnie za uchybienie terminowi 24 godzin, ale sam obowiązek zgłoszenia ich dotyczy.

Informacje dla użytkownika — załącznik II

Załącznik II to lista informacji, które muszą towarzyszyć produktowi: identyfikacja typu, partii lub numeru seryjnego, dane producenta wraz z adresem i kontaktem, jeden punkt kontaktowy do zgłaszania podatności i wskazanie, gdzie znaleźć politykę ich ujawniania, przeznaczenie produktu, instrukcje bezpiecznej instalacji i eksploatacji, informacja o sposobie uzyskiwania aktualizacji oraz data zakończenia okresu wsparcia.

Harmonogram

DataCo się dzieje
10 grudnia 2024Wejście w życie rozporządzenia (UE) 2024/2847
11 czerwca 2026Stosowanie przepisów o jednostkach notyfikowanych (rozdział IV)
11 września 2026Stosowanie obowiązków zgłoszeniowych (art. 14) — także dla produktów już na rynku
11 grudnia 2027Pełne stosowanie: wymagania zasadnicze, ocena zgodności, CE, dokumentacja
11 czerwca 2028Upływ ważności certyfikatów badania typu UE wydanych w okresie przejściowym

Produkty wprowadzone do obrotu przed 11 grudnia 2027 podlegają pełnym wymaganiom dopiero wtedy, gdy po tej dacie zostaną istotnie zmodyfikowane. Obowiązki zgłoszeniowe obejmują je jednak niezależnie od tego.

Warto zestawić te daty z rozporządzeniem maszynowym (UE) 2023/1230, które stosuje się od 20 stycznia 2027. Maszyna z elementami cyfrowymi trafia w oba reżimy w odstępie niespełna jedenastu miesięcy: rozporządzenie maszynowe traktuje cyberbezpieczeństwo jako wymóg bezpieczeństwa funkcjonalnego, CRA nakłada horyzontalne obowiązki na oprogramowanie, sterowniki i łączność. To dwa uzupełniające się reżimy, nie alternatywa.

Co to znaczy dla danych produktowych

Powiedzmy wprost, bo bywa to mylone: Cyber Resilience Act nie ustanawia cyfrowego paszportu produktu. Nie ma w nim obowiązku paszportowego, nośnika danych ani rejestru. Obowiązek paszportowy wynika z ESPR i z aktów sektorowych, które go wprost nakazują.

Ale zestaw obowiązków informacyjnych, jaki CRA tworzy, jest problemem zarządzania danymi w stopniu, który trudno przeoczyć:

  • Tożsamość na poziomie wersji. SBOM zmienia się z każdym wydaniem oprogramowania. Wykaz komponentów, który nie mówi, do której wersji się odnosi, jest bezużyteczny dowodowo. To ta sama zasada wersjonowania zamiast nadpisywania, na której opiera się paszport.
  • Data końca wsparcia jako pole, nie jako zdanie w ulotce. Musi być podana przy zakupie, musi być spójna we wszystkich kanałach sprzedaży i musi dać się sprawdzić po latach. Rozjazd między kartą produktu w sklepie a kartą u dystrybutora przestaje być kosmetyczny.
  • Rozwiązywalny nośnik danych. Punkt kontaktowy do zgłaszania podatności, polityka ujawniania i informacja o aktualizacjach muszą być osiągalne przez cały okres wsparcia. Kod prowadzący do aktualnego rekordu rozwiązuje ten problem lepiej niż adres wydrukowany w instrukcji sprzed sześciu lat. Różnice między wariantami omawiamy w artykule o kodzie QR a GS1 Digital Link.
  • Wielojęzyczność. Informacje z załącznika II muszą być zrozumiałe dla użytkowników w państwach, w których produkt jest udostępniany. Przy dokumentacji cyfrowej to nie projekt tłumaczeniowy, tylko pole z wersjami językowymi.
  • Ciągłość przez dekadę. Dziesięcioletnia dostępność aktualizacji i informacji to zobowiązanie usługowe przechodzące przez migracje, rebrandingi i zmiany dostawców.

Dla elektroniki dochodzi jeszcze jeden argument praktyczny. Ta sama kategoria produktów jest jednocześnie w polu widzenia ESPR, dyrektywy RoHS i przepisów o elektroodpadach. Firma, która osobno prowadzi dane o substancjach, osobno dane o naprawialności i osobno dane o wsparciu oprogramowania, utrzymuje trzy rejestry o tym samym produkcie. Uporządkowanie danych produktowych raz obsługuje wszystkie te kierunki — punktem wyjścia jest nasz artykuł o tym, dlaczego dane produktowe są fundamentem DPP.

Uczciwe zastrzeżenie o granicach roli dostawcy: myDPP nie prowadzi testów bezpieczeństwa, nie generuje ani nie weryfikuje SBOM, nie prowadzi procesu obsługi podatności, nie ocenia zgodności z CRA, nie jest jednostką notyfikowaną i nie składa zgłoszeń z art. 14. Przechowuje, wersjonuje i udostępnia zweryfikowane dane produktowe oraz utrzymuje nośnik, który je otwiera. Odpowiedzialność za zgodność pozostaje po stronie producenta.

Przygotowanie — pięć kroków

  1. Sklasyfikuj portfolio. Ustal, które produkty są produktami z elementami cyfrowymi, a następnie które trafiają do załącznika III klasy I lub II albo do załącznika IV. To decyduje o tym, czy potrzebna jest jednostka notyfikowana — i o tym, ile czasu zajmie ocena.
  2. Uruchom obsługę zgłoszeń przed 11 września 2026. Wyznacz odpowiedzialnych, opisz ścieżkę decyzyjną dla doby na wczesne ostrzeżenie, zarejestruj dostęp do platformy zgłoszeniowej i przećwicz to na przypadku testowym. Ten termin nie zależy od gotowości reszty projektu.
  3. Ustal okresy wsparcia i zapisz je jako dane. Dla każdej rodziny produktów wyznacz datę końca wsparcia, uzasadnij ją przewidywanym czasem użytkowania i umieść w systemie, z którego zasilane są sklep, dystrybutorzy i dokumentacja — a nie tylko w prezentacji produktowej.
  4. Zbuduj generowanie SBOM w procesie wydawniczym. Wykaz komponentów tworzony ręcznie raz na kwartał rozjedzie się z rzeczywistością przy pierwszym wydaniu poprawkowym. Powiązanie SBOM z wersją i z egzemplarzem to praca do wykonania po stronie danych, nie po stronie prawa.
  5. Uporządkuj informacje z załącznika II. Punkt kontaktowy, polityka ujawniania podatności, instrukcje bezpiecznej konfiguracji i data końca wsparcia to treści, które muszą być spójne we wszystkich językach i kanałach oraz osiągalne przez lata.

Szerszy program porządkowania danych prowadzi nasza checklista wdrożenia DPP.

Najczęściej zadawane pytania (FAQ)

Czy CRA dotyczy produktów, które sprzedałem przed 2027 rokiem?

Częściowo. Pełne wymagania — zasadnicze, ocena zgodności, CE — obejmują produkt wprowadzony do obrotu przed 11 grudnia 2027 dopiero wtedy, gdy po tej dacie zostanie istotnie zmodyfikowany. Natomiast obowiązki zgłoszeniowe z art. 14 obejmują produkty już obecne na rynku od 11 września 2026, niezależnie od daty sprzedaży.

Czy muszę publikować SBOM dla moich klientów?

Nie. Załącznik I wymaga sporządzenia i utrzymywania wykazu komponentów w formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu, oraz okazania go organom nadzoru rynku na żądanie. Publikacja SBOM dla użytkowników jest decyzją handlową, nie obowiązkiem prawnym.

Czy mogę ustalić okres wsparcia krótszy niż pięć lat?

Tylko wtedy, gdy przewidywany czas użytkowania produktu jest krótszy niż pięć lat, i trzeba to umieć uzasadnić. W pozostałych przypadkach pięć lat jest dolną granicą, a jeżeli produkt jest realnie używany dłużej, okres wsparcia powinien odpowiadać rzeczywistemu czasowi użytkowania.

Czy Cyber Resilience Act wprowadza cyfrowy paszport produktu?

Nie. CRA nie zawiera obowiązku paszportowego ani wymogu nośnika danych. Nakłada natomiast obowiązki informacyjne przypisane do produktu i wersji, które muszą pozostać dostępne przez okres wsparcia i dekadę po wydaniu aktualizacji. Wymagania na dane są zbieżne z paszportowymi, więc jedno uporządkowanie obsługuje oba kierunki.

Czytaj dalej

Źródła