CRA: co Cyber Resilience Act wymaga od producenta

Do tej pory bezpieczeństwo urządzenia było kwestią decyzji producenta. Od grudnia 2027 produkt z elementami cyfrowymi, który nie spełnia wymagań Cyber Resilience Act, nie może zostać wprowadzony na rynek Unii Europejskiej. Zasada jest ta sama co przy oznakowaniu CE: brak zgodności oznacza brak dostępu do rynku.

Poniżej opisuję, co konkretnie musi zrobić producent i w jakiej kolejności.

Czego CRA dotyczy, a czego nie

Zakres jest szerszy, niż zakłada większość firm. Rozporządzenie obejmuje produkty z elementami cyfrowymi (PDE), czyli każdy produkt sprzętowy lub programowy, który może być bezpośrednio albo pośrednio połączony z urządzeniem lub siecią.

Mieści się w tym czujnik, sterownik, router i kamera, ale również biblioteka programistyczna sprzedawana komercyjnie oraz aplikacja desktopowa. Kryterium jest proste: sprzedaż na rynku UE w toku działalności gospodarczej.

Poza zakresem pozostają produkty objęte regulacjami sektorowymi, w tym wyroby medyczne, lotnictwo cywilne i pojazdy homologowane, a także oprogramowanie open source rozwijane niekomercyjnie. Ta ostatnia granica bywa myląca. Pobieranie opłaty za wsparcie do własnego projektu OSS może wystarczyć, żeby znaleźć się w zakresie rozporządzenia.

Częsty błąd na tym etapie to założenie, że integrator cudzych modułów nie jest producentem. Sprzedaż produktu pod własną marką czyni Cię producentem w rozumieniu rozporządzenia, razem z odpowiedzialnością za komponenty, których nie napisałeś.

Cztery kategorie produktów

Kategoria przesądza o tym, czy wystarczy ocena własna, czy konieczny jest udział jednostki notyfikowanej. Ta decyzja przekłada się bezpośrednio na budżet i harmonogram, dlatego warto ustalić ją na samym początku.

Większość urządzeń IoT trafia do kategorii domyślnej. Upraszcza to ścieżkę formalną, ale nie zmniejsza wymagań technicznych. Samoocena oznacza jedynie, że nikt nie zweryfikuje produktu przed premierą.

Kalendarz wdrożenia

Rozporządzenie weszło w życie 10 grudnia 2024, a obowiązki wchodzą etapami.

1. 11 czerwca 2026. Przepisy dotyczące jednostek notyfikowanych. Zaczyna działać infrastruktura certyfikacji.
2. 11 września 2026. Obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.
3. 11 grudnia 2027. Pełne stosowanie rozporządzenia.

Wrzesień 2026 jest terminem najczęściej pomijanym w planach. Obowiązek zgłaszania zaczyna obowiązywać ponad rok przed resztą wymagań i zakłada gotowość organizacyjną, której nie da się zbudować w tydzień: kanał przyjmowania zgłoszeń, dyżur poza godzinami pracy, procedurę decyzyjną i osobę z mandatem do kwalifikowania zdarzeń.

Wymagania z Załącznika I

Załącznik I dzieli się na dwie części i to rozróżnienie ma praktyczne znaczenie.

Część I: właściwości produktu

Produkt ma być projektowany, wytwarzany i dostarczany tak, aby zapewniał odpowiedni poziom cyberbezpieczeństwa w oparciu o ocenę ryzyka. W praktyce oznacza to między innymi:

• dostarczanie bez znanych podatności możliwych do wykorzystania;
• bezpieczną konfigurację domyślną, z możliwością przywrócenia stanu fabrycznego;
• ochronę przed nieuprawnionym dostępem, z uwierzytelnianiem i zarządzaniem tożsamością;
• ochronę poufności i integralności danych, w spoczynku i w tranzycie;
• minimalizację powierzchni ataku i ograniczenie skutków incydentu przez odpowiednią izolację;
• rejestrowanie i monitorowanie zdarzeń istotnych dla bezpieczeństwa;
• zbieranie wyłącznie danych niezbędnych do działania produktu.

Na szczególną uwagę zasługuje pierwszy punkt. Wymóg dostarczenia produktu bez znanych podatności możliwych do wykorzystania oznacza w praktyce konieczność przeprowadzenia testu bezpieczeństwa przed premierą. Bez niego deklaracja nie ma podstawy dowodowej.

Część II: obsługa podatności

Druga część dotyczy nie produktu, lecz procesu wokół niego, i obowiązuje przez cały okres wsparcia:

• identyfikowanie i dokumentowanie podatności oraz komponentów, w tym sporządzenie SBOM-u obejmującego co najmniej zależności najwyższego poziomu;
• niezwłoczne usuwanie podatności, w tym przez aktualizacje bezpieczeństwa;
• regularne testy i przeglądy bezpieczeństwa;
• publiczne ujawnianie informacji o naprawionych podatnościach po wydaniu poprawki;
• prowadzenie polityki skoordynowanego ujawniania podatności;
• udostępnianie aktualizacji bezpieczeństwa nieodpłatnie i niezwłocznie, oddzielnie od aktualizacji funkcjonalnych tam, gdzie jest to wykonalne.

Ostatni wymóg bywa zaskoczeniem dla działów produktowych. Poprawki bezpieczeństwa mają być rozdzielone od aktualizacji funkcjonalnych wszędzie tam, gdzie jest to technicznie wykonalne, a od nieodpłatności rozporządzenie dopuszcza odstępstwo jedynie przy produktach szytych na miarę, na podstawie odrębnych ustaleń z klientem biznesowym.

Okres wsparcia

Producent określa okres wsparcia na podstawie oczekiwanego czasu użytkowania produktu, przy czym co do zasady nie może on być krótszy niż pięć lat. Wyjątkiem są produkty o krótszym cyklu życia. Okres wsparcia należy jasno zakomunikować kupującemu przed zakupem.

Przy urządzeniach przemysłowych, których cykl życia liczy się w dekadach, jest to zobowiązanie wymagające wyceny już na etapie projektowania. Koszt utrzymania wsparcia rośnie gwałtownie, gdy dostawca układu kończy wsparcie dla jądra systemu, a produkt jest wciąż w sprzedaży.

Obowiązek zgłaszania

W przypadku aktywnie wykorzystywanej podatności producent zgłasza równolegle do CSIRT wyznaczonego jako koordynator oraz do ENISA:

• wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiedzy;
• zgłoszenie podatności w ciągu 72 godzin, wraz z informacją o środkach naprawczych;
• raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego.

Przy poważnym incydencie wpływającym na bezpieczeństwo produktu schemat jest zbliżony: 24 godziny na wczesne ostrzeżenie, 72 godziny na zgłoszenie i miesiąc na raport końcowy.

Termin biegnie od powzięcia wiedzy, a nie od potwierdzenia zdarzenia. Procedura musi zatem jednoznacznie wskazywać, kto i na jakiej podstawie kwalifikuje podatność. Szczegóły opisałem w tekście o zgłoszeniu w 24 godziny.

SBOM

Dwa nieporozumienia dotyczące SBOM-u wracają na niemal każdym warsztacie.

Pierwsze dotyczy jawności. SBOM nie musi być publiczny. Rozporządzenie wymaga jego sporządzenia, utrzymywania i udostępnienia organom nadzoru rynku na żądanie, a nie publikacji na stronie produktu.

Drugie dotyczy cyklu życia. SBOM nie jest dokumentem jednorazowym. Ma odzwierciedlać aktualny stan produktu, w formacie nadającym się do odczytu maszynowego, w praktyce CycloneDX albo SPDX, i być aktualizowany razem z produktem. SBOM wygenerowany raz przed premierą i pozostawiony bez aktualizacji tworzy fałszywe poczucie kontroli nad zależnościami.

Sankcje

Za naruszenie wymagań zasadniczych z Załącznika I oraz obowiązków producenta przewidziano kary do 15 000 000 EUR albo 2,5% światowego rocznego obrotu, zależnie od tego, która kwota jest wyższa. Naruszenie pozostałych obowiązków zagrożone jest karą do 10 mln EUR albo 2% obrotu, a wprowadzenie w błąd jednostki notyfikowanej lub organu nadzoru do 5 mln EUR albo 1%.

Dla mniejszego producenta istotniejszym ryzykiem od maksymalnej kary jest jednak nakaz wycofania produktu z rynku, który potrafi zakończyć linię produktową szybciej niż jakakolwiek grzywna.

Kolejność wdrożenia

Sekwencja, która sprawdza się u producentów sprzętu:

1. Ustalenie zakresu i kategorii. Lista produktów objętych rozporządzeniem wraz z przypisaną kategorią. Pomocny będzie test w pięciu pytaniach.
2. SBOM dla jednego produktu. Nie dla całego portfolio, dla jednego. Pokaże realny stan wiedzy o zależnościach.
3. Uruchomienie kanału zgłoszeń. Adres security@, publiczna polityka ujawniania, zadeklarowany czas reakcji. Najtańszy element na tej liście i pierwszy weryfikowany podczas audytu.
4. Test bezpieczeństwa produktu. Test penetracyjny dostarcza listę podatności z dowodem wykorzystania, czyli materiał dowodowy dla deklaracji o braku znanych podatności.
5. Kompletowanie dokumentacji technicznej. Ocena ryzyka, wyniki testów, opis procesu obsługi podatności.
6. Bug Bounty

Jednym z rozwiązań jakie podaje legislator to Bug Bounty, w mojej ocenie świetne narzędzie które idealnie suplementuje proces wykrywania podatności.

W punkcie czwartym najczęściej wspieram producentów. Pełna analiza urządzenia obejmuje sprzęt, firmware, komunikację i proces aktualizacji, a kończy się raportem przygotowanym tak, aby wszedł wprost do dokumentacji technicznej.

Jeśli chcesz ustalić, na jakim etapie jest Twój produkt, napisz do mnie. Pierwsza rozmowa jest bezpłatna i zwykle wystarcza do określenia kategorii i zakresu prac.

---

Tekst opisuje rozporządzenie (UE) 2024/2847 i ma charakter informacyjny. Nie zastępuje analizy prawnej dla konkretnego produktu.