W ostatnich latach cyberprzestępcy coraz częściej wykorzystują luki w oprogramowaniu i urządzeniach podłączonych do sieci, a łańcuch dostaw produktów cyfrowych stał się jednym z najsłabszych ogniw europejskiej gospodarki. Unia Europejska odpowiedziała na te zagrożenia rozporządzeniem 2024/2847, znanym jako Cyber Resilience Act. Akt ten zmienia sposób, w jaki producenci, importerzy i dystrybutorzy odpowiadają za bezpieczeństwo produktów z elementami cyfrowymi przez cały ich cykl życia. W tym artykule omawiamy najważniejsze wymagania CRA oraz praktyczne kroki, jakie firmy powinny podjąć, zanim przepisy w pełni wejdą w życie.
Czym jest Cyber Resilience Act?
Cyber Resilience Act (CRA) to rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847, które ustanawia jednolite horyzontalne wymagania dotyczące cyberbezpieczeństwa dla produktów z elementami cyfrowymi wprowadzanych na rynek UE. Pełny tekst aktu został opublikowany w Dzienniku Urzędowym UE i dostępny jest w bazie EUR-Lex.
Rozporządzenie CRA ma charakter horyzontalny, co oznacza, że dotyczy wszystkich produktów sprzętowych i programowych z elementami cyfrowymi, niezależnie od branży, w której są sprzedawane. Zgodność z jego wymaganiami potwierdza oznakowanie CE, które dotychczas wiązało się głównie z bezpieczeństwem fizycznym i elektrycznym produktów. Od teraz znak CE potwierdza również cyberodporność. To pierwszy taki krok w skali UE i ma on bezpośrednie konsekwencje dla każdej firmy, która projektuje lub sprzedaje produkty cyfrowe odbiorcom w państwach członkowskich.
Dlaczego Unia Europejska wprowadziła Cyber Resilience Act?
U źródeł rozporządzenia leży kilka zjawisk, które Komisja Europejska wskazywała od 2022. Pierwszym była rosnąca liczba podatności w produktach powszechnego użytku i niewystarczające wsparcie aktualizacyjne. Drugim problemem pozostaje brak przejrzystości co do poziomu zabezpieczeń urządzeń IoT oraz oprogramowania oferowanego konsumentom i firmom.
Do chwili publikacji CRA regulacje UE dotyczące cyberbezpieczeństwa koncentrowały się na podmiotach i operatorach usług, a nie na samych produktach. Dyrektywa NIS2 nakłada obowiązki na operatorów usług kluczowych i ważnych, DORA reguluje odporność operacyjną sektora finansowego, ale żadna z regulacji dotyczących cyberbezpieczeństwa nie stawiała dotąd wymagań wobec producentów oprogramowania i sprzętu. Cyber Resilience Act wypełnia tę lukę, przenosząc ciężar odpowiedzialności za cyberbezpieczeństwo produktów na podmioty, które je projektują i dostarczają. Rozporządzenie jest częścią szerszej strategii cyfrowej UE, która zmierza do zbudowania odporności cyfrowego rynku wewnętrznego.
Jakie produkty obejmuje CRA?
Zakres przedmiotowy CRA jest bardzo szeroki. Rozporządzenie definiuje produkt z elementami cyfrowymi jako oprogramowanie lub sprzęt oraz związane z nimi rozwiązania do zdalnego przetwarzania danych, które mogą łączyć się bezpośrednio lub pośrednio z urządzeniem albo siecią. W rezultacie bezpieczeństwo produktów IT dotyczy tak oprogramowania biurowego, jak i urządzeń sieciowych typu router czy smart-TV. Do zakresu należą również inteligentne urządzenia domowe, takie jak zamki czy kamery, oraz zabawki z modułem internetowym. Rozporządzenie dotyczy także systemów sterowania przemysłowego oraz aplikacji mobilnych.
Nie każdy produkt cyfrowy podlega jednak CRA. Rozporządzenie wyraźnie wyłącza kategorie już regulowane odrębnymi aktami UE.
| Produkty wyłączone z zakresu CRA | Podstawa prawna / przyczyna |
| Wyroby medyczne | Rozporządzenie (UE) 2017/745 (MDR) |
| Diagnostyka in vitro | Rozporządzenie (UE) 2017/746 (IVDR) |
| Pojazdy silnikowe i ich komponenty | Rozporządzenie (UE) 2019/2144, regulacje ONZ |
| Wyroby lotnicze | Rozporządzenie (UE) 2018/1139 |
| Produkty wyłącznie do celów obronnych lub bezpieczeństwa narodowego | Art. 2 CRA |
| Pure SaaS (usługa bez komponentu produktowego) | CRA jest regulacją produktową |
| Wolne i otwarte oprogramowanie poza działalnością komercyjną | Motyw 18, art. 3 CRA |
Wyłączenia te wynikają z zasady niepodwajania obowiązków tam, gdzie bezpieczeństwo regulują już inne akty. Produkt, który nie mieści się w żadnej z tych kategorii, a łączy się z siecią lub urządzeniem, z dużym prawdopodobieństwem podlega CRA.
Kogo dotyczą obowiązki wynikające z CRA?
Obowiązki wynikające z CRA są rozłożone na cały łańcuch dostaw, ale główny ciężar spoczywa na producentach. Producent oprogramowania lub sprzętu to podmiot, który projektuje bądź zleca produkcję produktu i wprowadza go na rynek pod własną marką. To on przeprowadza ocenę ryzyka i sporządza dokumentację techniczną. Następnie podpisuje deklarację zgodności UE i umieszcza znak CE.
Importer odpowiada za to, że produkt spoza UE spełnia wymagania Cyber Resilience Act, zanim trafi na rynek wewnętrzny. Sprawdza on obecność znaku CE i kompletność dokumentacji, a w razie wątpliwości co do zgodności z CRA wstrzymuje sprzedaż. Dystrybutor, czyli ogniwo końcowe, weryfikuje znak CE i dopełnienie obowiązków przez producenta oraz importera. Importer i dystrybutor mają również obowiązek współpracować z organami nadzoru rynku i informować producenta o wykrytych podatnościach.
Osobną kategorią podmiotu jest opiekun otwartego oprogramowania (ang. open-source software steward). To osoba prawna, która trwale wspiera rozwój wolnego i otwartego oprogramowania przeznaczonego do celów działalności handlowej. Opiekunów obowiązują wybrane wymogi Cyber Resilience Act, takie jak polityka cyberbezpieczeństwa czy raportowanie podatności, jednak za naruszenia nie grożą im kary finansowe.
Najważniejsze wymagania CRA dla producentów
Szczegółowe wymagania CRA dla producentów zawiera Załącznik I rozporządzenia, podzielony na dwie części. Część pierwsza dotyczy właściwości samego produktu. Producent musi wprowadzać na rynek produkt wolny od znanych podatności, z bezpieczną konfiguracją domyślną zgodnie z zasadą security by default oraz z mechanizmami ochrony danych i kontroli dostępu. Liczba potencjalnych punktów wejścia atakującego powinna być ograniczona do minimum. Część druga dotyczy zarządzania podatnościami przez cały okres wsparcia produktu.
Wdrożenie CRA zaczyna się od oceny ryzyka cyberbezpieczeństwa, którą producent musi przeprowadzić i uwzględnić na wszystkich etapach cyklu życia produktu, od planowania aż po utrzymanie. Jej wyniki trafiają do dokumentacji technicznej, którą organy nadzoru rynku mogą kontrolować przez co najmniej 10 lat od wprowadzenia produktu na rynek. Producent musi też zadbać o należytą staranność wobec komponentów zewnętrznych, aby nie osłabiły one cyberbezpieczeństwa finalnego produktu. Brak weryfikacji dostawców jest tu jednym z najczęściej niedocenianych ryzyk.
Security by design i security by default jako fundament zgodności
Podejście security by design wymaga, żeby bezpieczeństwo stanowiło integralną część projektu produktu już od etapu koncepcyjnego. Decyzje architektoniczne dotyczące modelu uwierzytelniania czy sposobu przechowywania danych wrażliwych zapadają wtedy z udziałem zespołu bezpieczeństwa. Zespół produktowy i zespół bezpieczeństwa pracują razem od pierwszego szkicu specyfikacji.
Security by default oznacza, że produkt zaraz po włączeniu działa w najbezpieczniejszej konfiguracji, jaką dopuszcza jego zastosowanie. Domyślne hasła administracyjne czy włączone nieużywane usługi to elementy konfiguracji, które CRA każe eliminować u źródła. Użytkownik powinien móc używać produktu w bezpieczny sposób od razu po jego uruchomieniu, bez konieczności ręcznej konfiguracji podstawowych zabezpieczeń. Zasady security by design i security by default tworzą fundament, na którym opierają się szczegółowe wymagania zasadnicze z Załącznika I.
Jak wygląda zarządzanie podatnościami i aktualizacjami bezpieczeństwa według CRA?
Zarządzanie podatnościami w CRA opiera się na kilku filarach. Producent musi prowadzić politykę obsługi podatności, która przewiduje przyjmowanie zgłoszeń z zewnątrz (coordinated vulnerability disclosure) oraz analizę podatności bezpieczeństwa w produkcie i jego komponentach. Do tego dochodzi obowiązek dostarczania poprawek bez zbędnej zwłoki. Aktualizacje bezpieczeństwa muszą być udostępniane przez cały okres wsparcia, który producent sam wyznacza, ale nie może on być krótszy, niż uzasadnia to przewidywany czas używania produktu.
Kluczowym narzędziem operacyjnym zarządzania podatnościami jest SBOM (ang. Software Bill of Materials), czyli wykaz komponentów oprogramowania używanych w produkcie. SBOM pozwala szybko zidentyfikować, które produkty są narażone w razie wykrycia podatności w powszechnie używanej bibliotece. Aktualizacje bezpieczeństwa producent dostarcza co do zasady nieodpłatnie i razem z jasną informacją dla użytkownika o sposobie ich instalacji. Tam, gdzie to technicznie zasadne, aktualizacje bezpieczeństwa powinny być oddzielone od aktualizacji funkcjonalnych, żeby użytkownik mógł zainstalować samą poprawkę bez wymuszonej zmiany funkcji produktu.
Jakie są terminy raportowania incydentów i aktywnie wykorzystywanych podatności?
Operacyjnie raportowanie należy do najtrudniejszych obowiązków wynikających z CRA. Producent zgłasza poważny incydent lub aktywnie wykorzystywaną podatność (czyli taką, która posłużyła już do faktycznego ataku) krajowemu zespołowi CSIRT (ang. Computer Security Incident Response Team) i agencji ENISA (ang. European Union Agency for Cybersecurity). Wystarczy do tego jedno zgłoszenie złożone przez wspólną platformę raportową, którą prowadzi ta agencja. Platforma rozsyła zgłoszenie do CSIRT-ów w innych państwach członkowskich, w których produkt jest udostępniany. Art. 14 CRA przewiduje cztery rodzaje zgłoszeń z różnymi terminami.
| Rodzaj zgłoszenia | Termin wysłania | Adresat |
| Wczesne ostrzeżenie | 24 godziny | CSIRT + ENISA (Single Reporting Platform) |
| Zgłoszenie główne | 72 godziny | CSIRT + ENISA |
| Raport końcowy dla aktywnie wykorzystywanej podatności | Nie później niż 14 dni od udostępnienia środka zaradczego lub łatki | CSIRT + ENISA |
| Raport końcowy dla poważnego incydentu | 1 miesiąc od zgłoszenia głównego | CSIRT + ENISA |
Producent musi też bez zbędnej zwłoki informować użytkowników produktu o incydencie lub podatności oraz o dostępnych środkach ochrony. Obowiązki raportowe zaczynają obowiązywać od 11 września 2026 i dotyczą wszystkich produktów z elementami cyfrowymi udostępnionych na rynku UE, także tych wprowadzonych przed pełnym stosowaniem rozporządzenia. Dla zespołów SOC i zespołów produktowych oznacza to konieczność przygotowania procedur wykrywania i klasyfikacji incydentów cyberbezpieczeństwa oraz jasnych zasad przekazywania ich na wyższe poziomy organizacji, żeby termin 24 godzin był realnie osiągalny.
Kategorie produktów w CRA: standardowe, ważne i krytyczne
CRA różnicuje wymagania w zależności od kategorii ryzyka produktu. Produkty standardowe (non-critical) stanowią większość i podlegają ocenie zgodności w trybie samooceny. Produkty ważne (important) są wymienione w Załączniku III i podzielone na dwie klasy. Produkty krytyczne (critical) zawiera Załącznik IV, a ich lista jest najbardziej restrykcyjna.
Do produktów ważnych klasy I należą między innymi menedżery haseł i oprogramowanie antywirusowe. Klasa II to produkty o większym znaczeniu dla bezpieczeństwa, takie jak firewalle przedsiębiorstw czy moduły HSM. Produkty krytyczne to między innymi elementy inteligentnych liczników oraz smart cards wykorzystywane w infrastrukturze uwierzytelniania. Szczegółowy opis techniczny tych kategorii zawiera rozporządzenie wykonawcze Komisji (UE) 2025/2392 z 28 listopada 2025 r.
Kiedy wystarczy samoocena, a kiedy potrzebna jest jednostka notyfikowana?
Oznakowanie CE na produkcie cyfrowym potwierdza, że producent przeprowadził odpowiednią ocenę zgodności i produkt spełnia zasadnicze wymagania CRA. Tryb oceny zgodności zależy od kategorii ryzyka.
Dla produktów standardowych wystarczy wewnętrzna kontrola produkcji (moduł A), czyli samoocena. Producent sam weryfikuje zgodność i na tej podstawie podpisuje deklarację oraz umieszcza znak CE. W przypadku produktów ważnych klasy I samoocena jest dopuszczalna tylko wtedy, gdy producent zastosował normy zharmonizowane albo europejski schemat certyfikacji cyberbezpieczeństwa. Bez nich konieczna jest ocena przez jednostkę notyfikowaną, czyli niezależną instytucję certyfikującą wyznaczoną przez państwo członkowskie do oceny zgodności wyrobów z wymaganiami CE. Dla produktów ważnych klasy II oraz dla produktów krytycznych ocena przez jednostkę notyfikowaną jest zasadniczo obowiązkowa.
Normy zharmonizowane odgrywają tu szczególną rolę. Ich zastosowanie tworzy domniemanie zgodności z wymaganiami Cyber Resilience Act, co upraszcza ocenę zgodności i zmniejsza ryzyko sporu z organami nadzoru. Komisja Europejska przy wsparciu ENISA oraz europejskich organizacji standaryzacyjnych (CEN, CENELEC, ETSI) pracuje nad zestawem norm zharmonizowanych, które pozwolą producentom wykazać zgodność z CRA w sposób przewidywalny.
Harmonogram wdrożenia CRA: kluczowe daty
Harmonogram CRA daje producentom wieloetapowy okres przygotowań, ale nie wszystkie obowiązki ruszają w jednym momencie.
10 grudnia 2024: Wejście w życie rozporządzenia 2024/2847.
11 czerwca 2026: Państwa członkowskie zaczynają zgłaszać Komisji Europejskiej jednostki notyfikowane uprawnione do oceny zgodności produktów z wymaganiami CRA.
11 września 2026: Start obowiązków raportowych zawartych w art. 14. Producenci zgłaszają aktywnie wykorzystywane podatności i poważne incydenty.
11 grudnia 2027: Pełne stosowanie CRA. Od tej daty żaden produkt z elementami cyfrowymi niespełniający wymagań nie może być wprowadzony na rynek UE.
Jak przygotować organizację do wymogów Cyber Resilience Act?
Przygotowanie do CRA jest zadaniem wielowymiarowym i wymaga współpracy zespołów produktowych z zespołami bezpieczeństwa oraz zespołami prawnymi i zakupowymi. Pierwszym krokiem jest pełna inwentaryzacja portfela produktów. Firma musi wiedzieć, które z nich podlegają CRA i do jakiej kategorii ryzyka należą. Następnie producent przekłada wymagania Załącznika I na procesy cyklu życia produktu i identyfikuje luki.
Kolejnym obszarem jest wdrożenie SBOM dla każdego produktu oraz polityki obsługi podatności ze zdefiniowanymi kanałami zgłoszeń zewnętrznych. Zespoły bezpieczeństwa muszą zaprojektować procedurę raportowania zgodną z 24-godzinnym terminem, w tym zasady przekazywania sprawy z poziomu operacyjnego do zarządu. Umowy z dostawcami komponentów trzeba uzupełnić o klauzule dotyczące bezpieczeństwa i zgłaszania podatności.
Równolegle warto uporządkować dokumentację techniczną oraz ocenę ryzyka cyberbezpieczeństwa tak, by można je było bez przygotowania przedstawić organowi nadzoru. Tutaj sprawdza się systemowe zarządzanie zgodnością, które łączy wymagania, dowody i raporty w jednym miejscu i ogranicza pracę ręczną. Bez takiego systemu koszt utrzymania zgodności z CRA rośnie wraz z liczbą produktów i komponentów w ofercie firmy.
Wpływ CRA na producentów software, hardware i IoT
Producenci oprogramowania odczują zmianę przede wszystkim w sprawie zależności open source i okresów wsparcia. Producent ma obowiązek dochować należytej staranności wobec bibliotek stron trzecich, w tym tych pobieranych z publicznych repozytoriów. W razie podatności w zewnętrznym komponencie musi wiedzieć, co dokładnie znajduje się w jego produkcie i jak na nią zareagować. Czysty SaaS pozostaje poza zakresem CRA jako usługa, ale oprogramowanie dostarczane do instalacji u klienta podlega rozporządzeniu, co rozszerza zakres obowiązków na dużą część rynku B2B.
Producenci sprzętu, zwłaszcza w segmencie IoT, mają obowiązek zapewnić cyberbezpieczeństwo produktu przez cały zadeklarowany okres wsparcia. Dla wielu tanich urządzeń to fundamentalna zmiana, bo dotychczas okres wsparcia często istniał tylko na papierze. Producenci muszą utrzymywać aktualizacje firmware i kontrolować dostawy komponentów. W przemysłowym IoT bezpieczeństwo produktów IT trzeba dodatkowo godzić z regulacjami sektorowymi, na przykład w energetyce czy transporcie.
W segmencie open source rozporządzenie przewiduje wyjątki dla projektów niekomercyjnych, a opiekunów otwartego oprogramowania obejmuje węższy zakres obowiązków. Firmy, które komercjalizują projekty open source, dostają jasną zasadę rozdzielenia odpowiedzialności komercyjnej od wsparcia społeczności.
CRA a inne regulacje cyberbezpieczeństwa w UE
CRA nie działa w próżni. Dyrektywa NIS2 dotyczy cyberbezpieczeństwa podmiotów kluczowych i ważnych, takich jak dostawcy usług cyfrowych, operatorzy infrastruktury krytycznej czy szpitale. DORA stawia wymagania odporności operacyjnej sektorowi finansowemu oraz jego dostawcom ICT. Żadna z tych regulacji nie adresuje bezpośrednio cyberbezpieczeństwa produktów wprowadzanych na rynek i właśnie tę lukę wypełnia CRA.
CRA powiązany jest też z innymi aktami unijnymi. Dyrektywa RED (2014/53/UE) wraz z aktem delegowanym 2022/30 wprowadziła wymagania cyberbezpieczeństwa dla urządzeń radiowych. Te wymagania zostaną w znacznej części pochłonięte przez CRA, co uprości życie producentom łączności bezprzewodowej. RODO pozostaje odrębną regulacją dotyczącą ochrony danych osobowych i działa równolegle do CRA, ponieważ wiele incydentów cyberbezpieczeństwa wiąże się z naruszeniem danych. Dla firm oznacza to, że jeden incydent może rodzić obowiązki raportowe wynikające z CRA i z innych aktów, takich jak NIS2 czy RODO, co wymaga skoordynowanej reakcji prawnej i operacyjnej.
Najczęstsze wyzwania we wdrożeniu CRA
Wdrożenie CRA ujawnia w wielu firmach te same trudności. Pierwsza z nich dotyczy łańcucha dostaw komponentów. Duża część produktów korzysta z bibliotek i modułów dostarczanych przez dziesiątki firm, których polityki bezpieczeństwa bardzo różnią się jakością. Wykazanie należytej staranności wobec setek komponentów wymaga specjalistycznych narzędzi, bo arkusze kalkulacyjne już tego nie obsłużą.
Drugie wyzwanie to wyznaczenie okresu wsparcia. Producenci, którzy do tej pory wspierali produkt przez kilka lat, muszą zweryfikować swoje modele biznesowe. Nieadekwatnie dobrany okres może dla firmy oznaczać sankcje i utratę klientów.
Trzecia trudność to dowodowość, czyli umiejętność wykazania zgodności w razie kontroli. Organy nadzoru mogą żądać dokumentacji technicznej oraz wyników testów bezpieczeństwa. Firmy, które prowadziły testy, ale nie dokumentowały ich systematycznie, będą musiały zbudować ścieżkę audytu od zera.
Jeszcze jedna kwestia to status produktów już obecnych na rynku w momencie pełnego stosowania CRA, czyli 11 grudnia 2027. Producent nie musi ich przerabiać tak, żeby spełniały nowe wymagania, dopóki nie wprowadzi w nich istotnej modyfikacji. Obowiązki raportowe obejmują jednak wszystkie produkty udostępnione na rynku UE, także te sprzedane wiele lat wcześniej. Producent powinien więc jasno zdefiniować i ogłosić datę zakończenia wsparcia każdego produktu, bo bez tego trudno mu będzie odeprzeć zgłoszenia dotyczące starszych wersji.
Co CRA oznacza dla biznesu
Cyber Resilience Act zmienia model odpowiedzialności za cyberbezpieczeństwo produktów z elementami cyfrowymi w Unii Europejskiej. Dla producentów, importerów i dystrybutorów to jednocześnie obowiązek i szansa. Firmy, które już teraz zaczną porządkować procesy projektowania oraz zarządzania podatnościami wraz z dokumentacją techniczną, wejdą w rok 2027 z gotowymi deklaracjami zgodności i utrzymają dostęp do rynku bez zakłóceń. Te, które odwlekają przygotowania, ryzykują zarówno kary, jak i utratę przewagi konkurencyjnej wobec dostawców, dla których cyberodporność stała się częścią wartości produktu. Informacje o postępach wdrożenia CRA publikuje Komisja Europejska.
