Cyber Resilience Act.
Bezpieczne projektowanie produktów z elementami cyfrowymi, obsługa podatności i przygotowanie właściwego potwierdzenia zgodności.
- Rozporządzenie (UE) 2024/2847
- Autor: Derya Altinay
- Stan na: 22.10.2026
- Czas czytania: 7 min
Krótka odpowiedź.
Cyber Resilience Act to unijne rozporządzenie o cyberbezpieczeństwie objętych nim produktów z elementami cyfrowymi. Producenci odpowiadają za bezpieczeństwo podczas rozwoju, udostępniania i wsparcia. Obowiązki zgłaszania przez producentów stosuje się od 11 września 2026 r.; ogólne obowiązki produktowe od 11 grudnia 2027 r. Podstawę stanowi rozporządzenie (UE) 2024/2847.
Cyber Resilience Act i terminy CRA.
Cyber Resilience Act, w skrócie CRA, czyli akt o cyberodporności, reguluje cyberbezpieczeństwo produktów. Rozporządzenie (UE) 2024/2847 łączy wymagania projektowe z obowiązkami w cyklu życia produktu. Przedmiotem analizy jest konkretny produkt z istotnymi komponentami i powiązanym zdalnym przetwarzaniem danych. Program bezpieczeństwa całego przedsiębiorstwa może wspierać te prace, ale sam nie rozstrzyga kwestii produktowych.
Terminy CRA są rozłożone w czasie. Zgodnie z art. 71 ust. 2 CRA ogólne wymagania zaczynają obowiązywać 11 grudnia 2027 r.; zgłoszenia producentów z art. 14 obowiązują już od 11 września 2026 r. Rozdział IV o notyfikacji jednostek oceny zgodności stosuje się od 11 czerwca 2026 r. Ten termin instytucjonalny nie jest wcześniejszą ogólną datą obowiązku CE dla wszystkich produktów programowych.
Starsze produkty nie są ogólnie wyłączone z obowiązków zgłaszania przez producentów. Art. 69 ust. 2 i 3 CRA rozróżnia przepisy przejściowe dotyczące zgodności produktu i zgłoszeń. Wytyczne Komisji C(2026) 5252, sekcja 9.1, wyjaśniają ten podział również dla produktów wprowadzonych do obrotu przed grudniem 2027 r. Wytyczne są niewiążącą prawnie pomocą interpretacyjną; rozstrzygające pozostaje rozporządzenie.
Jakich produktów i przedsiębiorstw dotyczy CRA.
CRA dotyczy objętych nim produktów sprzętowych i programowych udostępnianych na rynku UE, które przewidują bezpośrednie lub pośrednie połączenie danych z urządzeniem lub siecią. Art. 2 i 3 CRA określają zakres zastosowania i definicje. Mogą obejmować komponenty oferowane samodzielnie. Przed jednakową klasyfikacją całego portfolio należy sprawdzić rzeczywistą funkcję i ustawowe wyjątki.
Rola przedsiębiorstwa określa jego obowiązki. Producenci, importerzy i dystrybutorzy mają różne zadania; rola producenta może mieć znaczenie także przy sprzedaży pod własną marką. W przypadku oprogramowania open source należy odróżnić komercyjne udostępnianie, wkład poszczególnych osób i szczególną rolę zarządcy oprogramowania open source. Wolna licencja nie zwalnia ogólnie producenta komercyjnego produktu z odpowiedzialności.
Usługa SaaS nie podlega CRA ani nie jest z niego wyłączona wyłącznie ze względu na nazwę modelu dystrybucji. Decydują granice produktu i powiązane zdalne przetwarzanie danych. Wytyczne Komisji, sekcje 2 i 8, rozróżniają produkty programowe i usługi świadczone zdalnie. Należy zapisać uzasadnienie dla konkretnej architektury; ogólne stwierdzenie o wszystkich ofertach chmurowych byłoby zbyt szerokie.
Główne obszary wymagań CRA.
Wymagania CRA łączą oparte na ryzyku bezpieczeństwo produktu z ciągłą odpowiedzialnością. Art. 13 i załącznik I CRA stanowią podstawę obowiązków produktowych; art. 14 reguluje wcześniejsze obowiązki zgłaszania przez producentów. Poniższe obszary ułatwiają orientację, nie zastępując szczegółowych wymagań ustawowych.
Zrozumienie produktu i ryzyk.
Ocena ryzyka cyberbezpieczeństwa stanowi podstawę decyzji bezpieczeństwa w cyklu życia. Producenci uwzględniają zamierzone i racjonalnie przewidywalne zastosowania. W praktyce należy opisać funkcje, interfejsy i zależności produktu oraz skutki problemu bezpieczeństwa dla użytkowników.
Uwzględnienie bezpieczeństwa w produkcie.
Bezpieczny projekt i bezpieczne ustawienia domyślne tworzą całość. Załącznik I CRA obejmuje właściwości produktu, takie jak ochrona dostępu i danych oraz ograniczenie powierzchni ataku. Polityka napisana po fakcie nie zastępuje właściwości technicznych; decyzje rozwojowe i ich weryfikacja muszą odpowiadać ocenie ryzyka.
Odpowiedzialna integracja komponentów.
Zintegrowane komponenty pozostają częścią analizy produktu. Producenci potrzebują przejrzystych informacji o tym, co dostarczają i jak podatności w zależnościach wpływają na produkt. Komisja wyraźnie opisuje należytą staranność względem komponentów zewnętrznych; samo przekazanie informacji dostawcy nie rozstrzyga każdej kwestii produktowej.
Obsługa podatności i aktualizacji.
Obsługa podatności jest stałym zadaniem w odpowiednim okresie wsparcia. Obejmuje dostępne kanały zgłoszeń, ocenę, usuwanie problemów i bezpieczne udostępnianie aktualizacji bezpieczeństwa. Należy oddzielić techniczną obsługę ustalenia od oceny prawnej obowiązku zgłoszenia aktywnie wykorzystywanej podatności lub poważnego incydentu.
Ustalenie wsparcia i informacji dla użytkowników.
Okres wsparcia zależy od kryteriów art. 13 ust. 8 CRA i oczekiwanego użytkowania. Co do zasady przewiduje się co najmniej pięć lat; przy krótszym oczekiwanym użytkowaniu obowiązuje jego czas, a przy dłuższym może być wymagany dłuższy okres. Wytyczne Komisji, sekcja 5, wyraźnie wskazują, że pięć lat nie jest ogólną granicą maksymalną.
Zapewnienie możliwości zgłaszania przez producenta.
Art. 14 CRA rozróżnia aktywnie wykorzystywane podatności i poważne incydenty bezpieczeństwa. Producenci zgłaszają je etapami: niezwłocznie, najpóźniej w ciągu 24 godzin wczesne ostrzeżenie i w ciągu 72 godzin dalsze informacje od uzyskania wiedzy. Terminy końcowe różnią się zależnie od przyczyny zgłoszenia. Sam wynik skanera nie jest więc automatycznie obowiązkowym zgłoszeniem ani wystarczającym powodem zamknięcia zdarzenia.
Przygotowanie zgodności i dokumentacji.
Dokumentacja techniczna i ocena zgodności muszą wyjaśniać oferowany produkt. Art. 32 CRA i kategoria produktu określają dopuszczalną procedurę. Należy zachować wybraną podstawę oceny razem z wersją produktu; ogólny zbiór dokumentów bez przejrzystego związku z badaną wersją nie wystarcza jako praktyczna strategia dowodowa.
Wdrożenie CRA jako proces produktowy.
Wyznaczenie portfolio i ról.
Na początek należy opisać oferowane produkty, ich istotne funkcje, odpowiedzialny podmiot prawny i rolę w danym kanale dystrybucji.
Rozróżnienie etapów stosowania.
Należy oddzielić obowiązującą już gotowość producenta do zgłoszeń od przygotowania ogólnej zgodności produktowej i sprawdzić zasady przejściowe dla istniejących produktów.
Przełożenie ryzyk na decyzje produktowe.
Należy powiązać ocenę ryzyka z projektem, wyborem komponentów i weryfikowalnymi kryteriami bezpieczeństwa dla rozwoju i dopuszczenia do wydania.
Przećwiczenie kanałów zgłoszeń.
Należy wskazać osoby odpowiedzialne i zastępstwa oraz przećwiczyć ocenę, eskalację i przekazywanie przy niepełnych informacjach w obowiązujących terminach.
Ustalenie wsparcia i ścieżki dowodowej.
Należy zaplanować utrzymanie wspieranych wersji produktu i na podstawie kategorii ustalić wymaganą ocenę zgodności i dokumentację techniczną.
Oznakowanie CE oprogramowania i potwierdzenie produktu.
Potwierdzenie CRA jest oceną zgodności dotyczącą produktu. Komisja wyjaśnia w odniesieniu do art. 32 CRA, że dla kategorii standardowej możliwa jest ocena wewnętrzna. Dla określonych ważnych lub krytycznych produktów obowiązują bardziej rygorystyczne procedury z udziałem jednostki notyfikowanej lub innymi dopuszczalnymi ścieżkami dowodowymi. O kategorii decyduje rzeczywista funkcja produktu; nazwa marketingowa nie wystarcza.
Deklaracja zgodności UE i oznakowanie CE wynikają z właściwej procedury. Nie są ogólnym certyfikatem całego przedsiębiorstwa ani obietnicą, że produkt nigdy nie będzie miał podatności. Dlatego jednolita ważność certyfikatu nie jest właściwym opisem CRA: dokumentację, obsługę podatności i obowiązki należy rozpatrywać w odpowiednim cyklu życia.
Inne ramy i odrębne obowiązki.
ISO 27001 organizuje system zarządzania bezpieczeństwem informacji; odpowiedni certyfikat sam nie potwierdza zgodności produktu z CRA. NIS2 dotyczy objętych podmiotów i ich organizacji bezpieczeństwa. RODO chroni dane osobowe, dlatego zdarzenie produktowe może wywołać dodatkowe kwestie ochrony danych. Powiązane procesy można koordynować, lecz ich prawne przesłanki i dowody wymagają osobnej analizy.
W Secani.
Secani zawiera autorski katalog roboczy CRA ze źródłami, pytaniami kontrolnymi i przykładami dowodów. Profil przedsiębiorstwa obejmuje między innymi role i datę oceny; niewyjaśnione przesłanki pozostają widoczne jako wymagające weryfikacji. Pomoc porządkuje analizę, ale nie potwierdza ani klasyfikacji prawnej, ani zgodności produktu.
Początek od wyodrębnionego produktu.
Należy wybrać konkretny produkt i najpierw ustalić jego granice, odpowiedzialny podmiot prawny i osoby zajmujące się zgłoszeniami bezpieczeństwa. Następnie sprawdzić, jakie obecne i przyszłe obowiązki go dotyczą. Taki początek upraszcza przygotowanie i zapobiega przesłonięciu już wymaganej gotowości do zgłoszeń przez ogólny projekt zgodności.
Źródła.
- Rozporządzenie (UE) 2024/2847 – Cyber Resilience Act
- Komisja Europejska: Cyber Resilience Act i daty stosowania
- Komisja Europejska: streszczenie aktu prawnego
- Komisja Europejska: obowiązki producentów
- Komisja Europejska: ocena zgodności
- Komisja Europejska: CRA i open source
- Komisja Europejska: wytyczne C(2026) 5252 z załącznikiem
Najczęstsze pytania.
Tak, zgłoszenia z art. 14 CRA obowiązują objętych producentów od 11 września 2026 r. Ogólne obowiązki produktowe zaczynają obowiązywać 11 grudnia 2027 r.; szczególne role i przepisy przejściowe należy sprawdzić osobno.
Nie, określenie SaaS nie rozstrzyga zakresu zastosowania. Należy sprawdzić produkt programowy, jego funkcje i powiązane zdalne przetwarzanie danych na podstawie konkretnej architektury.
Nie, szczególne traktowanie wcześniejszego wkładu open source nie zwalnia ogólnie producenta komercyjnego produktu z obowiązków. Należy rozróżniać rolę producenta i ewentualną rolę zarządcy oprogramowania open source.
Nie, certyfikat ISO 27001 dotyczy wyodrębnionego systemu zarządzania. CRA wymaga osobnej analizy produktu i właściwego potwierdzenia zgodności.
Przejrzysta organizacja bezpieczeństwa produktu.
Uporządkowana praca nad wymaganiami CRA i ich weryfikacją w Secani.
Strona ogólnie wyjaśnia Cyber Resilience Act i nie zastępuje analizy prawnej konkretnego produktu. Rozstrzygające są obowiązujące akty prawne.