Cyber Resilience Act – jakie obowiązki nakłada na producentów i importerów?
Obowiązki z Cyber Resilience Act nie kończą się na kontroli przed wprowadzeniem produktu do obrotu. Rozporządzenie (UE) 2024/2847 wymaga udokumentowanej oceny ryzyka, utrzymywania bezpieczeństwa produktu przez cały okres wsparcia i zgłaszania aktywnie wykorzystywanych podatności w ciągu 24 godzin.
To drugi z trzech wpisów, które poświęcamy CRA:
- Cyber Resilience Act – co to jest i kogo powinno obchodzić?
- Cyber Resilience Act – jakie obowiązki nakłada na producentów i importerów?
- Jak się przygotować do stosowania Cyber Resilience Act?
W pierwszej części opisaliśmy zakres rozporządzenia i krąg podmiotów, które muszą się nim zainteresować. Dziś przedstawiamy obowiązki producentów i importerów produktów objętych CRA.
Od czego zacząć?
Pierwszym krokiem powinna być ocena ryzyka w cyberprzestrzeni, przeprowadzana przed wprowadzeniem produktu do obrotu, z uwzględnieniem przeznaczenia produktu, racjonalnie przewidywalnego wykorzystania, środowiska pracy i oczekiwanego czasu użytkowania. Producent musi w niej wskazać, które zasadnicze wymagania mają zastosowanie i w jaki sposób zostały wdrożone, a jeżeli któreś nie mają zastosowania – producent musi to uzasadnić w dokumentacji technicznej. Ocenę musi aktualizować przez cały okres wsparcia.
Odrębnie producent musi zachować szczególną staranność wobec komponentów pochodzących od stron trzecich, w tym komponentów otwartego oprogramowania. Ryzyka wynikające z sieci i systemów, z którymi produkt się łączy, można ograniczyć środkami wbudowanymi w sam produkt. Komponenty faktycznie w nim zintegrowane producent musi natomiast sprawdzić pod kątem tego, czy spełniają wymagania – na podstawie dokumentacji dostawcy, a w razie potrzeby własnych testów.
Wytyczne Komisji Europejskiej w sprawie stosowania CRA, zatwierdzone 27 lipca 2026 r. na podstawie art. 26 rozporządzenia (dokument C(2026) 5252, dalej „Wytyczne”), wskazują jednocześnie na dwie istotne kwestie: (i) ryzyka nie można przenieść na użytkownika instrukcją obsługi ani na dostawcę komponentu umową oraz (ii) nie można też powołać się na koszty – jeżeli zidentyfikowanego ryzyka nie da się zmitygować, producent musi zmienić projekt, funkcjonalność albo przeznaczenie produktu.
Rozporządzenie przewiduje też uproszczenie – jeśli warianty produktu mają tę samą architekturę, to samo przeznaczenie i są narażone na te same zagrożenia, wystarczy jedna ocena ryzyka, jedna dokumentacja techniczna, jedna procedura oceny zgodności i jedna deklaracja obejmująca wskazane w niej warianty. Różnice w kolorze, obudowie czy wielkości pamięci nie wymagają osobnej ścieżki – różnice w interfejsach komunikacyjnych, wykorzystywanym oprogramowaniu czy mechanizmie aktualizacji już tak.
Jak powinien być zbudowany produkt?
Producent musi udostępniać produkty bez znanych podatności nadających się do wykorzystania, z bezpieczną konfiguracją domyślną i możliwością przywrócenia stanu pierwotnego, a podatności musi usuwać aktualizacjami – domyślnie automatycznymi, z prostą możliwością rezygnacji. Producent musi ponadto zapewnić w produkcie kontrolę dostępu, ochronę poufności i integralności danych, minimalizację danych, dostępność podstawowych funkcji także po incydencie, ograniczenie powierzchni ataku, rejestrowanie zdarzeń istotnych dla bezpieczeństwa oraz trwałe usuwanie danych i ustawień.
Większość tych wymagań stosuje się „w stosownych przypadkach”, czyli w zakresie wynikającym z oceny ryzyka. Nie może to jednak być „furtka” do pomijania tych wymogów, a jedynie do dostosowania wymogów do charakteru produktu oraz zagrożeń.
Wymóg „braku znanych podatności” nierzadko jest źle rozumiany. Podatność jest „znana” nie tylko wtedy, gdy figuruje w publicznych bazach, ale również wtedy, gdy producent dowiedział się o niej ze zgłoszenia badacza, z własnych testów albo z doniesień wiarygodnych mediów. Samo zgłoszenie nie oznacza jeszcze, że podatność da się wykorzystać w danym produkcie, a decyzję o wstrzymaniu premiery do czasu poprawki producent musi uzasadnić oceną ryzyka.
Co z podatnościami po premierze?
Kolejna grupa wymagań dotyczy okresu wsparcia. Producent musi identyfikować i dokumentować podatności oraz komponenty, w tym sporządzić zestawienie komponentów oprogramowania w formacie nadającym się do odczytu maszynowego, obejmujące co najmniej zależności najwyższego poziomu. Na podatności musi reagować bezzwłocznie, a jeżeli jest to technicznie wykonalne – oddzielić aktualizacje zabezpieczeń od aktualizacji funkcjonalnych. Musi też prowadzić politykę skoordynowanego ujawniania podatności, udostępnić adres do ich zgłaszania, zapewnić bezpieczną dystrybucję aktualizacji i publikować informacje o naprawionych podatnościach. Aktualizacje zabezpieczeń muszą być bezpłatne i pozostać dostępne co najmniej 10 lat od wydania albo do końca okresu wsparcia, jeżeli ten kończy się później.
Wymóg regularnych testów i przeglądów Wytyczne interpretują rozsądnie – nie chodzi o powtarzanie tego samego zestawu testów w stałych odstępach, lecz o to, aby producent sprawdzał, czy nowe zagrożenia i nowo wykryte podatności wymagają jego zmiany.
Jak długo trzeba wspierać produkt?
Producent musi sam określić okres wsparcia, biorąc pod uwagę oczekiwany czas użytkowania produktu, uzasadnione oczekiwania użytkowników, charakter i przeznaczenie produktu oraz okresy wsparcia komponentów pozyskanych od stron trzecich. Rozporządzenie wymaga co najmniej pięciu lat, chyba że produkt ma być użytkowany krócej.
Wytyczne są w tej kwestii stanowcze – pięć lat jest okresem minimalnym, a nie „domyślnym”. Przyjęcie pięciu lat dla sterownika przemysłowego pracującego piętnaście lat będzie trudne do obrony, tym bardziej że powody wyboru okresu wsparcia powinny znajdować się W dokumentacji technicznej. Datę jego zakończenia, co najmniej z miesiącem i rokiem, trzeba podać użytkownikowi już w momencie zakupu, a po jej upływie wyświetlić użytkownikowi powiadomienie, jeżeli jest to technicznie wykonalne.
Dla oprogramowania przewidziano ułatwienie. Producent, który wprowadził do obrotu kolejne istotnie zmodyfikowane wersje, może usuwać podatności tylko w wersji ostatniej, pod warunkiem że użytkownicy wcześniejszych wersji mają do niej bezpłatny dostęp i nie ponoszą dodatkowych kosztów dostosowania sprzętu i oprogramowania.
Kiedy i komu zgłaszać podatności?
Od 11 września 2026 r. producent musi zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty mające wpływ na bezpieczeństwo produktu, jednocześnie CSIRT wyznaczonemu jako koordynator i ENISA, przez pojedynczą platformę sprawozdawczą. Terminy są trzystopniowe: wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin, sprawozdanie końcowe w ciągu 14 dni od udostępnienia środka naprawczego przy podatności albo w ciągu miesiąca od zgłoszenia 72-godzinnego przy incydencie.
Sporne w praktyce będzie to, od kiedy termin biegnie. Wytyczne wiążą jego początek z chwilą, w której producent po wstępnej ocenie sygnału osiąga rozsądny stopień pewności, że podatność w jego produkcie jest wykorzystywana albo że doszło do poważnego incydentu. Producent powinien przy tym przeprowadzić wstępną ocenę szybko, a nie wykorzystywać jej do przesunięcia terminu.
Za co odpowiada importer?
Importer co do zasady nie odpowiada za konstrukcję produktu, jego odpowiedzialność skupia się an tym, aby nie wprowadził do obrotu produktu niezgodnego. Przed wprowadzeniem musi sprawdzić, czy producent przeprowadził właściwą procedurę oceny zgodności i sporządził dokumentację techniczną, czy produkt ma oznakowanie CE, czy towarzyszą mu deklaracja zgodności i instrukcje w języku zrozumiałym dla użytkowników i organów oraz czy podano informacje o okresie wsparcia i dane kontaktowe producenta. Importer musi być w stanie przedstawić dokumenty potwierdzające te ustalenia, a przy uzasadnionym podejrzeniu niezgodności wstrzymać się od wprowadzenia produktu i zawiadomić organy nadzoru rynku.
Od tej zasady istnieje jednak istotny wyjątek. Importer lub dystrybutor, który wprowadza produkt do obrotu pod własną nazwą albo znakiem towarowym, jest uważany za producenta i podlega pełnemu zestawowi obowiązków – z oceną ryzyka, oceną zgodności, okresem wsparcia i zgłoszeniami włącznie. Ten sam skutek wywołuje istotna modyfikacja produktu już wprowadzonego do obrotu.
Podsumowanie
W myśl Cyber Reslience Act producent odpowiada za produkt i za procesy wokół niego, importer za sprawdzenie dokumentów, ale w obu przypadkach zgodności nie da się wykazać bez sformalizowanego, ustrukturyzowanego podejścia oraz bez dokumentacji, która musi „żyć” razem z produktem. Dlatego producent i importer powinni zacząć nie od pisania polityk, lecz od ustalenia, kto w organizacji będzie odpowiadał za ocenę ryzyka, zestawienie komponentów, okres wsparcia i procedurę zgłoszeniową oraz jak to wdrożyć w już istniejące procesy.
AUTOR WPISU
E: kamil.koziol@pl.Andersen.com
T: +48 668 690 891