Cyber Resilience Act: jak wdrożyć secure-by-design przed 2026

Cyber Resilience Act - obowiązek secure-by-design i harmonogram zmian

Unijny Akt o cyberodporności (Cyber-Resilience Act, CRA) to przełomowe rozporządzenie UE, które wprowadza obowiązkowe wymogi cyberbezpieczeństwa dla wszystkich urządzeń i oprogramowania zawierających elementy cyfrowe. Został on formalnie przyjęty pod koniec 2024 roku - wszedł w życie 10 grudnia 2024 r. Choć większość nowych obowiązków zacznie obowiązywać dopiero po okresie przejściowym (pełne stosowanie od 11 grudnia 2027 r.), to czas na przygotowania jest właśnie teraz. Pierwsze wymogi - jak obowiązek zgłaszania incydentów i podatności - wejdą w życie już we wrześniu 2026 roku. Dla zarządów firm oznacza to, że rok 2025 i 2026 będą kluczowe na wdrożenie zmian secure-by-design, zanim nowe prawo zacznie być egzekwowane.

Dlaczego to takie ważne?

Po pierwsze, CRA wypełnia lukę w dotychczasowych przepisach, nakładając horyzontalne wymagania cyberbezpieczeństwa na niemal wszystkie produkty cyfrowe - od zabawek IoT, przez inteligentne AGD, po samodzielne oprogramowanie. To podejście „secure by design” ma zapewnić, że produkty są bezpieczne już w momencie projektowania i przed wprowadzeniem na rynek, a nie dopiero łatane po fakcie. Po drugie, stawka jest wysoka: od możliwości utraty dostępu do rynku UE (brak certyfikatu CE) dla niezgodnych produktów, po surowe kary finansowe sięgające 15 mln euro lub 2,5% globalnego obrotu firmy za naruszenie przepisów. Wreszcie, CRA wpisuje się w szerszy trend regulacyjny - obok dyrektywy NIS2 czy AI Act - akcentując odpowiedzialność za cyberbezpieczeństwo na najwyższym szczeblu zarządzania. Zarządy wszystkich branż muszą więc zrozumieć, co nowe wymogi oznaczają dla strategii produktowej, inwestycji (CAPEX) i ich własnej odpowiedzialności.

Czym jest Cyber Resilience? Zakres i harmonogram

CRA to rozporządzenie UE ustanawiające wymagania minimalne w zakresie cyberbezpieczeństwa dla produktów z elementami cyfrowymi na jednolitym rynku. Obejmuje zarówno urządzenia sprzętowe podłączone do sieci (np. kamery, routery, AGD, zabawki), jak i oprogramowanie (od aplikacji mobilnych i desktopowych po systemy operacyjne czy oprogramowanie wbudowane). Ważne: zakres jest bardzo szeroki - każdy produkt, który może łączyć się z innym urządzeniem lub siecią (bezpośrednio lub pośrednio) podlega nowym zasadom. Wyłączone są jedynie nieliczne kategorie już objęte odrębnymi regulacjami, np. wyroby medyczne, pojazdy, lotnictwo czy niektóre narzędzia open-source używane poza komercyjnym obrotem.

Harmonogram wdrożenia: Formalnie CRA obowiązuje od grudnia 2024, ale ustawodawca przewidział długi okres przejściowy na dostosowanie się:

• 36 miesięcy od wejścia w życie (czyli do grudnia 2027) - po tym terminie wszystkie nowe produkty cyfrowe wprowadzane na rynek UE muszą spełniać wymogi CRA.

• 21 miesięcy od wejścia w życie (wrzesień 2026) - już wtedy zaczną obowiązywać wybrane wymagania, przede wszystkim dotyczące zgłaszania incydentów i podatności. Oznacza to, że firmy muszą mieć procedury monitorowania i raportowania zagrożeń gotowe znacznie wcześniej przed główną datą graniczną.

W międzyczasie UE opracuje akty delegowane i wykonawcze doprecyzowujące niektóre kwestie techniczne (np. szczegółową definicję produktów krytycznych i istotnych objętych ostrzejszymi wymogami, procedury oceny zgodności, platformę raportowania ENISA itp.).

Kluczowe jest to, że CRA ma bezpośrednie zastosowanie (to rozporządzenie, nie dyrektywa) - nie wymaga wdrażania do prawa krajowego. Od grudnia 2027 r. każdy produkt cyfrowy niespełniający wymogów będzie nielegalny na rynku UE. Dla firm oznacza to konieczność uzyskania oznakowania CE potwierdzającego zgodność cyberbezpieczeństwa zanim produkt trafi do sprzedaży. Nowe prawo ma więc podobną wagę jak przepisy o bezpieczeństwie elektrycznym czy oznaczeniach środowiskowych - tyle że dotyczy bezpieczeństwa cyfrowego.

Wpływ CRA na polski rynek i łańcuch dostaw

Secure-by-design i inne nowe obowiązki - na czym polegają?

CRA wprowadza szereg obowiązków „secure-by-design” - czyli takich, które wymuszają uwzględnienie bezpieczeństwa od początku cyklu życia produktu (projektowanie, rozwój, produkcja), a nie dopiero reaktywne działania po wystąpieniu problemu. Poniżej podsumowanie najważniejszych wymogów stawianych producentom (a w pewnym zakresie także importerom i dystrybutorom) urządzeń i oprogramowania:

• Bezpieczeństwo by design i by default: Producent musi zapewnić odpowiedni poziom bezpieczeństwa już na etapie projektu i domyślnej konfiguracji produktu. Urządzenie/oprogramowanie ma być dostarczane bez znanych podatności oraz z bezpiecznymi ustawieniami fabrycznymi (np. unikalne hasła, wyłączone zbędne usługi) . W praktyce oznacza to wdrożenie bezpiecznych praktyk deweloperskich - m.in. bezpiecznego kodowania, testów penetracyjnych przed wydaniem, ograniczania powierzchni ataku i stosowania najnowszych mechanizmów ochrony (szyfrowanie danych „w tranzycie” i „w spoczynku”, kontrola dostępu, odporność na ataki typu DoS itp.).

• Analiza ryzyka i certyfikacja: Przed wprowadzeniem produktu na rynek producent musi przeprowadzić ocenę ryzyka cyberbezpieczeństwa i odpowiednio zaprojektować zabezpieczenia, aby zminimalizować ryzyka dla użytkowników (w tym ryzyka dla ich zdrowia i bezpieczeństwa w świecie fizycznym) . Ocena ma być udokumentowana i aktualizowana w razie potrzeby. Ponadto, w zależności od kategorii produktu, wymagane będzie przeprowadzenie procedury oceny zgodności z wymogami CRA - samodzielnie lub z udziałem niezależnej jednostki certyfikującej (notyfikowanej) dla produktów o podwyższonym ryzyku. Produkty uznane za krytyczne mogą wymagać nawet uzyskania certyfikatu cyberbezpieczeństwa UE (na poziomie co najmniej „substantial”) zanim trafią na rynek.

• Zarządzanie podatnościami i incident response: Nowe prawo kładzie mocny nacisk na cykl życia podatności. Producent ma monitorować bezpieczeństwo swojego produktu już w użyciu i niezwłocznie reagować na wykryte luki. W szczególności: pojawia się obowiązek usuwania znanych podatności poprzez aktualizacje oraz zgłaszania poważnych incydentów bezpieczeństwa i aktywnie wykorzystywanych luk do odpowiednich instytucji w ciągu 24 godzin od wykrycia. Zgłoszenie ma trafić do krajowego zespołu CSIRT oraz do Agencji UE ds. Cyberbezpieczeństwa (ENISA), a dodatkowe raporty uzupełniające - w ciągu 72 godzin i 14 dni. Użytkownicy produktu muszą być również poinformowani o incydencie bez zbędnej zwłoki. Co istotne, obowiązek raportowania wejdzie w życie wcześniej niż pozostałe wymogi - już we wrześniu 2026 r. - co ma zapewnić wczesne wykrywanie zagrożeń nawet przed pełnym obowiązywaniem CRA.

• Aktualizacje bezpieczeństwa i wsparcie: Producent musi zapewnić regularne aktualizacje zabezpieczeń (łatki) dla produktu przez co najmniej 5 lat od wprowadzenia go na rynek lub przez przewidywany okres użytkowania (w zależności co dłuższe) . Aktualizacje te mają być darmowe i udostępniane w sposób umożliwiający łatwe ich zastosowanie przez użytkownika. Co więcej, wszystkie udostępnione poprawki mają pozostać dostępne do pobrania przez minimum 10 lat od premiery produktu. Idea jest taka, by nawet pod koniec cyklu życia urządzenia użytkownik mógł zabezpieczyć je najnowszą łatką. W praktyce firmy muszą zorganizować proces patch management na lata do przodu - łącznie z mechanizmami zdalnej aktualizacji urządzeń IoT, aby skutecznie załatać je u klientów.

• Dokumentacja techniczna i SBOM: Każdy produkt objęty CRA musi posiadać szczegółową dokumentację techniczną dotyczącą bezpieczeństwa. Musi ona zawierać m.in. opis zastosowanych zabezpieczeń, wyniki analizy ryzyka, instrukcje bezpiecznej konfiguracji, informacje o znanych zagrożeniach, a także - co bardzo ważne - wykaz komponentów oprogramowania (SBOM - Software Bill of Materials) użytych w produkcie. SBOM, w powszechnym formacie maszynowym, ma obejmować przynajmniej zależności najwyższego poziomu. Dzięki temu użytkownicy oraz organy nadzoru będą mieli wgląd w to, z jakich bibliotek i komponentów składa się urządzenie/soft, co ułatwi śledzenie podatności (np. gdy zostanie ujawniona luka w danej bibliotece open-source, wiadomo które produkty są nią dotknięte). Dokumentację bezpieczeństwa producent musi przechowywać i udostępniać organom nadzoru przez 10 lat od wprowadzenia produktu na rynek.

• Odpowiedzialność za łańcuch dostaw: Obowiązki ustawowe „przenoszą” teraz ciężar odpowiedzialności na producentów za cały ekosystem dostawców i komponentów ich produktu. Firma musi zapewnić, że także elementy dostarczane przez strony trzecie spełniają wymogi bezpieczeństwa CRA. W praktyce oznacza to konieczność przeprowadzania należytej staranności (due diligence) wobec dostawców hardware/software, regularnych audytów czy testów komponentów oraz posiadania procedur kwalifikacji dostawców pod kątem bezpieczeństwa. Jeżeli produkt składa się z modułów lub korzysta z usług chmurowych innych firm, producent nadal odpowiada za ich zgodność z CRA. To wyzwanie zwłaszcza dla urządzeń IoT bazujących na wielu bibliotekach open-source - stąd znaczenie SBOM i aktywnego monitorowania podatności w zależnościach.

Warto podkreślić, że powyższe wymogi nie są „papierowe” - ich niespełnienie grozi realnymi konsekwencjami. Organ nadzoru (np. UOKiK w Polsce czy dedykowane organy ds. rynku) będą uprawnione do weryfikowania dokumentacji, żądania testów produktu, a w razie stwierdzenia niezgodności - do wydawania nakazów wycofania produktu z rynku lub nałożenia kar. Każdy nowy produkt cyfrowy będzie musiał przejść ścieżkę podobną do obecnej certyfikacji CE - z tą różnicą, że znak CE będzie teraz również potwierdzeniem zgodności cyberbezpieczeństwa.

Wyzwania dla firm - dlaczego zarządy muszą się tym zająć?

Dla wielu przedsiębiorstw, zwłaszcza tych produkujących urządzenia IoT lub oprogramowanie sprzedawane w UE, CRA oznacza konieczność istotnych zmian organizacyjnych, procesowych i finansowych. Oto główne wyzwania, które wymagają uwagi zarządów:

• Szeroki zakres i niepewność co do interpretacji. Niezwykle szeroka definicja „produktów z elementami cyfrowymi” sprawia, że wiele firm może nie zdawać sobie sprawy, że podlegają pod CRA. Nawet czysto programistyczne firmy dostarczające software na rynek UE (np. aplikacje, systemy bezpieczeństwa IT, gry) będą objęte tym rozporządzeniem. Zarządy muszą zatem zainwestować w analizę prawną i techniczną, aby ustalić, które produkty/usługi podpadają pod nowe regulacje i jakie dokładnie obowiązki je obejmą. Niektóre branże mogą mieć wątpliwości - np. czy dany system jest częścią usługi online (wtedy może podlegać innym przepisom), czy samodzielnym produktem software. Ta niepewność wymaga konsultacji z ekspertami i ewentualnie regulatorami.

• Złożoność łańcucha dostaw technologii. Współczesne produkty cyfrowe są zbudowane z mnóstwa komponentów firm trzecich (sprzętowych i softwarowych) oraz bibliotek open-source. Zapewnienie zgodności każdego z tych elementów z CRA to duże wyzwanie. Wymaga to pełnej widoczności łańcucha dostaw - wiedzy, co dokładnie siedzi w naszym produkcie. Zarządy muszą wspierać tworzenie wewnętrznych baz wiedzy (np. SBOM) i procesów monitorowania dostawców. Konieczne może być renegocjowanie umów z dostawcami pod kątem wymogów bezpieczeństwa, wprowadzenie nowych standardów kwalifikacji komponentów, a nawet poszukiwanie alternatyw, jeśli dotychczasowy komponent nie spełni norm. To wszystko wymaga koordynacji i inwestycji na poziomie zarządczym, bo wpływa na architekturę produktu i relacje biznesowe.

• Ciężar dokumentacyjny i operacyjny. CRA narzuca znaczącą biurokrację techniczną - firmy muszą tworzyć i utrzymywać szczegółową dokumentację bezpieczeństwa, procesy raportowania incydentów 24/7, polityki ujawniania podatności, plany aktualizacji na lata. Dla organizacji bez dojrzałych procesów cyberbezpieczeństwa może to być szok kulturowy. Zarząd musi więc zrozumieć, że spełnienie wymogów to nie jednorazowy „projekt IT”, ale stałe zobowiązanie - podobnie jak utrzymywanie systemu zarządzania jakością (ISO) czy compliance z RODO. Konieczne będzie być może zatrudnienie dodatkowych specjalistów (np. Product Security Officer, inżynierowie bezpieczeństwa), przeszkolenie zespołów deweloperskich, zbudowanie nowych procedur (np. reagowania na incydenty produktowe). To wszystko to koszty operacyjne, które muszą znaleźć odzwierciedlenie w budżecie i planie strategicznym.

• Krótki czas na wdrożenie zmian. Choć koniec 2027 r. wydaje się odległy, cykl projektowania i wprowadzania nowych produktów potrafi trwać latami. Produkty, które wejdą na rynek po tej dacie, już teraz są w fazie projektów lub testów. Jeśli dziś nie uwzględnią wymogów bezpieczeństwa, za dwa lata mogą okazać się niezgodne z prawem. Dlatego zarządy muszą zapewnić działanie wyprzedzające: włączyć działy R&D, inżynierii i IT w proces analizy wymagań CRA natychmiast. Dotyczy to również produktów już oferowanych - może zajść potrzeba ich modernizacji lub wycofania przed 2027, jeśli nie będzie się dało zapewnić zgodności (np. zbyt stary sprzęt nieprzystosowany do aktualizacji OTA). Przykładowo, według analiz liczba urządzeń podłączonych do sieci rośnie lawinowo - w 2025 r. globalnie ma działać ponad 75 mld urządzeń IoT - co oznacza, że okno na uporządkowanie tego ekosystemu bezpieczeństwa jest bardzo wąskie.

• Ryzyko finansowe i prawne. Niespełnienie wymogów CRA to nie tylko problem działu technicznego - to poważne ryzyko biznesowe. Kary administracyjne mogą sięgnąć 2,5% globalnego rocznego obrotu firmy lub 15 mln euro (w zależności co wyższe) . Dla międzynarodowych korporacji z branży technologicznej mogą to być dziesiątki czy setki milionów euro. Co więcej, produkt niezgodny z wymogami może zostać usunięty z rynku decyzją nadzoru, co oznacza utratę przychodów i koszty akcji serwisowych (np. masowe naprawy lub wymiany). Wreszcie, CRA przewiduje możliwość pozwów zbiorowych (representative actions) ze strony konsumentów dotkniętych wadami cyberbezpieczeństwa - można sobie wyobrazić sytuację, w której producenci dziurawych kamer domowych zostaną pozwani za umożliwienie ataku na prywatność tysięcy osób. Taka wielowątkowa ekspozycja na ryzyko sprawia, że nadążanie za wymogami CRA jest obowiązkiem w ramach należytej staranności zarządczej. W erze, gdy cyberbezpieczeństwo stało się kwestią regulacyjną jak ochrona danych osobowych, lekceważenie tych wymagań może być traktowane jako zaniedbanie obowiązków przez kierownictwo.