Cyber Resilience Act (CRA) – Kompleksowy Przewodnik Dla Producentów

Czym jest Cyber Resilience Act i kogo dotyczy

W świecie pełnym inteligentnych urządzeń i aplikacji, bezpieczeństwo nie może być już tylko dodatkiem – staje się obowiązkowym wymogiem prawnym. Takim właśnie wymogiem jest europejskie rozporządzenie Cyber Resilience Act (CRA), które wprowadza jednolite zasady cyberbezpieczeństwa produktów cyfrowych we wszystkich krajach UE.

Jeżeli tworzymy oprogramowanie, sprzęt IoT czy oferujemy usługi SaaS powiązane z urządzeniami, nowe przepisy bezpośrednio wpływają na sposób, w jaki projektujemy, rozwijamy i utrzymujemy nasze produkty. W tym przewodniku wyjaśniamy od podstaw, czym jest CRA, dlaczego ma znaczenie, jaki jest zakres regulacji oraz kluczowe obowiązki nakładane na producentów.

Dlaczego to ma znaczenie?

Ataki cybernetyczne przybierają na sile – według danych unijnych w 2024 r. odnotowano aż o 150% więcej cyberataków niż rok wcześniej. Wraz z tym rośnie ryzyko dla użytkowników i firm, zwłaszcza iż otacza nas coraz więcej połączonych urządzeń. Szacuje się, iż do 2030 roku globalnie będzie działać 40 miliardów urządzeń IoT, z czego ponad 4 miliardy w samej Europie. Niestety wiele z nich ma poważne luki bezpieczeństwa lub brak długoterminowego wsparcia. Klasyczny przykład to ataki typu Mirai – botnet przejmujący kontrolę nad urządzeniami IoT zabezpieczonymi fabrycznymi hasłami. Innym głośnym przypadkiem była podatność Log4Shell (CVE-2021-44228), która ujawniła, iż producenci często nie wiedzą, jakich bibliotek używają ich produkty – a tym samym nie reagują na znane luki przez wiele miesięcy.

Wobec takich zagrożeń regulatorzy postanowili działać. Cyber Resilience Act ma wymusić zmianę podejścia: bezpieczeństwo “by design” i “by default” zamiast reagowania po fakcie. Dla producentów oznacza to konieczność wprowadzenia nowych procesów (jak zarządzanie podatnościami, reagowanie na incydenty w 24 godziny) oraz dodatkowej dokumentacji (np. listy komponentów SBOM). Koszty braku zgodności będą wysokie – od kar finansowych po wycofanie produktu z rynku. Innymi słowy, cyberbezpieczeństwo przestaje być opcjonalne, stając się tak samo obowiązkowe jak atesty elektryczne czy oznaczenie CE. Poniżej krok po kroku omówimy, co dokładnie wprowadza CRA.

Czym jest Cyber Resilience Act?

Cyber Resilience Act (CRA) to rozporządzenie Unii Europejskiej ustanawiające horyzontalne (ogólnosektorowe) wymagania cyberbezpieczeństwa dla “produktów z elementami cyfrowymi”. Mowa o wszelkiego rodzaju sprzęcie i oprogramowaniu (wraz z towarzyszącymi usługami chmurowymi), które jest wprowadzane na rynek UE. Akt ten zobowiązuje producentów, by już na etapie projektowania, developmentu, testów i dystrybucji spełniali określone minimalne wymogi bezpieczeństwa. Co istotne, obowiązki nie kończą się w momencie sprzedaży produktu – obejmują też fazę użytkowania, np. reagowanie na nowe podatności i dostarczanie aktualizacji przez cały deklarowany okres wsparcia produktu.

W praktyce CRA tworzy nowe “prawo techniczne” podobne do norm CE, ale skupione na cyberbezpieczeństwie. Każdy producent będzie musiał dokonać oceny zgodności swojego wyrobu z wymaganiami bezpieczeństwa przed wprowadzeniem go na rynek. Potwierdzeniem zgodności będzie właśnie znak CE, który zyska dodatkowe znaczenie – stanie się świadectwem spełnienia norm cyberbezpieczeństwa, a nie tylko dotychczasowych wymagań np. elektrycznych czy EMC. Innymi słowy, bezpieczne oprogramowanie i urządzenia staną się formalnym wymogiem prawnym w UE, podobnie jak to ma miejsce w przypadku oznakowania CE.

Harmonogram wdrożenia CRA

Jak większość regulacji unijnych, CRA daje przedsiębiorcom czas na dostosowanie. Najważniejsze daty to:

• 10 grudnia 2024 – rozporządzenie CRA zostało oficjalnie opublikowane i weszło w życie (od tej daty liczą się okresy przejściowe).
• 11 czerwca 2026 – państwa UE zaczną notyfikować jednostki oceniające zgodność (tzw. jednostki notyfikowane). To przygotowanie do nadchodzących certyfikacji.
• 11 września 2026 – wejście w życie obowiązków raportowania incydentów i podatności. Od tego dnia producenci muszą zgłaszać poważne incydenty bezpieczeństwa w ciągu 24 godzin (szczegóły w dalszej części).
• 11 grudnia 2027 – pełne stosowanie CRA. Wszystkie nowe produkty wprowadzane na rynek UE muszą od tego dnia spełniać wymagania i przejść odpowiednią ocenę zgodności. W praktyce oznacza to ostateczny termin na dostosowanie procesów w firmach.

Warto dodać, iż produkty wprowadzone na rynek przed grudniem 2027 nie będą musiały nagle uzyskać certyfikatów, o ile nie zostaną istotnie zmodyfikowane po tej dacie. Jednak choćby dla starszych produktów będą obowiązywać wymogi dotyczące raportowania incydentów i podatności od września 2026. W razie dużej aktualizacji (uznanej za “istotną modyfikację”) starszy produkt może zostać potraktowany jak nowy i podlegać CRA od 2027 r. – to zachęta, by choćby wcześniejsze rozwiązania już projektować z myślą o nadchodzących regulacjach.

Kogo dotyczy CRA?

Zakres podmiotowy CRA jest bardzo szeroki. Obejmuje wszystkich producentów sprzętu lub systemu z elementami cyfrowymi udostępnianych na rynku UE, bez względu na branżę. Dotyczy to zarówno dużych producentów elektroniki czy oprogramowania, jak i startupów IoT wypuszczających nowe urządzenie “smart”. Przepisy obejmują cały łańcuch dostaw – producentów, importerów i dystrybutorów. Producent (firmy wprowadzające produkt pod własną marką) ponosi główną odpowiedzialność za spełnienie wymagań. Importerzy muszą sprawdzać, czy sprowadzane spoza UE produkty posiadają certyfikację CRA, a dystrybutorzy – upewnić się, iż sprzedawane urządzenia mają wymagane oznakowanie i dokumentację.

Na marginesie warto wspomnieć, iż dostawcy czysto usługowi (np. wyłącznie SaaS) nie są bezpośrednio objęci CRA, o ile ich usługa nie stanowi produktu w rozumieniu “sprzęt/oprogramowanie na rynku”. Typowe usługi chmurowe i wewnętrzne systemy IT podlegają raczej pod inne regulacje (np. dyrektywę NIS2 dla usług kluczowych). Jednak granica bywa cienka – jeżeli np. oferujemy urządzenie IoT z usługą cloud (smart-kamera + platforma online), to całość jest traktowana jako produkt z elementami cyfrowymi i podpada pod CRA.

Wyłączenia: Pewne kategorie produktów są wyłączone z CRA, gdyż podlegają już sektorowym regulacjom o cyberbezpieczeństwie. Dotyczy to m.in. wyrobów medycznych, urządzeń transportowych (samochody), lotnictwa itp., gdzie odrębne przepisy nakładają własne wymagania. Oprogramowanie open-source również nie jest objęte CRA pod warunkiem, iż nie jest rozwijane w ramach działalności komercyjnej. Oznacza to, iż hobbystyczne projekty FOSS udostępniane za darmo nie muszą spełniać wymagań CRA. Uwaga: jeżeli jednak wykorzystujesz komponent open-source w swoim komercyjnym produkcie, odpowiadasz za jego bezpieczeństwo tak samo, jak za własny kod. Producent musi dochować należytej staranności co do komponentów zewnętrznych (o czym w sekcji o łańcuchu dostaw). Wprowadzono co prawda pojęcie “opiekuna” open-source (open-source software steward) – organizacji wspierającej rozwój ważnego projektu OSS – ale jego obowiązki ograniczono jedynie do posiadania polityki bezpieczeństwa i raportowania poważnych luk. Co istotne, takim opiekunom nie grożą kary finansowe za naruszenia CRA, w przeciwieństwie do producentów komercyjnych. To celowy ukłon ustawodawcy, aby nie “zamrozić” oddolnego rozwoju open source, jednocześnie wymuszając bezpieczeństwo na tych, którzy zarabiają na integracji takiego systemu w produktach.

Kluczowe wymagania CRA dla producentów

Rozporządzenie CRA definiuje zbiór podstawowych wymagań bezpieczeństwa, które musi spełniać każdy produkt z elementami cyfrowymi. Szczegółowy katalog znajduje się w Aneksie I do aktu i obejmuje zarówno właściwości produktu (część I), jak i procesy obsługi podatności (część II). Poniżej omawiamy główne obowiązki nałożone na producentów – od etapu projektowania, przez certyfikację, po wsparcie posprzedażowe. Dla przejrzystości przedstawiamy je w formie tematycznych sekcji. Warto zwrócić uwagę, iż spełnienie tych wymagań będzie weryfikowane przed wprowadzeniem produktu na rynek, a następnie może być kontrolowane przez organy nadzoru w dowolnym momencie cyklu życia produktu.

Bezpieczeństwo “by design” i “by default”

CRA wymaga, aby bezpieczeństwo stało się integralną częścią cyklu życia produktu – od pierwszych linijek kodu po użytkowanie końcowe. Producent musi zapewnić, iż już na etapie projektu i domyślnej konfiguracji produkt spełnia odpowiedni poziom ochrony. W praktyce oznacza to implementację zasad secure by design (bezpieczne projektowanie) oraz secure by default (bezpieczna konfiguracja domyślna):

• Minimalizacja podatności w projekcie: Kod powinien być tworzony zgodnie z zasadami bezpiecznego programowania. Warto korzystać z wytycznych takich jak OWASP Top 10 czy CWE/SANS Top 25, by unikać najczęstszych błędów (np. SQL Injection, XSS, buffer overflow). Przed wydaniem wersji należy przeprowadzać testy bezpieczeństwa – od statycznej analizy kodu (SAST), przez skanowanie zależności pod kątem CVE, aż po testy penetracyjne aplikacji i urządzeń.. Przykładowo, jeżeli nasz produkt to aplikacja web, wdrożenie HTTPS/TLS z adekwatną konfiguracją jest obowiązkowe, podobnie jak silne haszowanie haseł użytkowników. jeżeli to urządzenie IoT, projekt musi przewidywać mechanizmy kontroli dostępu i odporność na typowe ataki sieciowe (np. DoS) już od pierwszego prototypu.
• Bezpieczna konfiguracja domyślna: Produkt nie może trafiać do klienta z “łatwymi” ustawieniami, które obniżają bezpieczeństwo. Domyślne hasła admin/admin są zakazane – każde urządzenie powinno mieć unikalne, silne hasło lub wymuszać ustanowienie hasła przy pierwszym użyciu. Zbędne usługi i porty mają być wyłączone. Szyfrowanie komunikacji ma być włączone domyślnie (np. TLS 1.3 zamiast czystego HTTP). Wszystko to ma sprawić, iż użytkownik bez dodatkowej konfiguracji dostaje produkt ustawiony na możliwie najbezpieczniejszy tryb. Przykładowo, o ile urządzenie wystawia interfejs WWW do konfiguracji, powinno wymuszać połączenie HTTPS i unikalne poświadczenia. o ile aplikacja używa tokenów dostępowych, to krótko żyjące tokeny JWT podpisane mocnym kluczem uniemożliwią przejęcie sesji przez atakującego (np. brak współdzielenia jednego klucza JWT między różnymi urządzeniami, co byłoby groźnym naruszeniem bezpieczeństwa).

Wdrażając zasadę secure by design, producenci często sięgają po frameworki i biblioteki o wbudowanych mechanizmach bezpieczeństwa (np. stosowanie standardowych bibliotek do uwierzytelniania OAuth2/OIDC zamiast tworzenia własnych rozwiązań). Należy jednak pamiętać o aktualizacji tych komponentów – co prowadzi nas do kolejnych wymagań CRA.

Analiza ryzyka i procedura oceny zgodności

Bezpieczny produkt musi wynikać z świadomego procesu zarządzania ryzykiem. CRA nakłada obowiązek przeprowadzenia cybersecurity risk assessment, czyli oceny ryzyka cyberbezpieczeństwa produktu. Producent powinien zidentyfikować potencjalne zagrożenia (zarówno dla użytkowników, jak i dla otoczenia – np. ryzyko fizyczne, gdyby ktoś shakował urządzenie medyczne) i dobrać środki zaradcze. Wyniki analizy ryzyka muszą zostać udokumentowane i uwzględnione na każdym etapie: od planowania, przez projekt, po wdrożenie i utrzymanie produktu. jeżeli produkt jest rozwijany iteracyjnie, analiza powinna być aktualizowana wraz ze zmianami.

Co więcej, dokumentacja analizy ryzyka staje się częścią obowiązkowej dokumentacji technicznej bezpieczeństwa, którą przechowujemy dla organów nadzoru (o dokumentacji więcej za chwilę). Na podstawie oceny ryzyka producent musi uzasadnić ewentualne odstępstwa – np. jeżeli uzna, iż któryś z wymagań CRA nie ma zastosowania do danego produktu, powinien to wyjaśnić w ocenie ryzyka.

Kluczowym elementem jest też procedura oceny zgodności (conformity assessment). Zanim produkt trafi na rynek, producent musi formalnie potwierdzić, iż spełnia on wszystkie istotne wymagania CRA. W zależności od kategorii ryzyka produktu, przewidziano różne ścieżki oceny:

• Produkty zwykłe (niezaliczone do grup wysokiego ryzyka) – producent może przeprowadzić wewnętrzną ocenę zgodności we własnym zakresie (tzw. moduł A: wewnętrzna kontrola produkcji). Oznacza to, iż firma sama sprawdza i oświadcza, iż spełniła wymagania (co i tak musi być poparte dokumentacją i analizami). Ta ścieżka przypomina dzisiejsze self-declaration dla niektórych oznaczeń CE.
• Produkty “ważne” klasy I – tu również dopuszczono self-assessment, ale pod warunkiem zastosowania norm zharmonizowanych lub specyfikacji wspólnych. o ile producent nie zastosuje uznanych standardów, będzie musiał skonsultować zgodność z jednostką notyfikowaną (niezależną instytucją certyfikującą).
• Produkty “ważne” klasy II oraz “krytyczne” – w przypadku tych wyższych kategorii wymagana jest ocena zgodności z udziałem strony trzeciej. Producent musi zgłosić produkt do certyfikacji przez uprawnioną jednostkę notyfikowaną, która przeprowadzi audyt i testy potwierdzające spełnienie wymagań. Alternatywnie, jeżeli istnieje odpowiedni europejski certyfikat cyberbezpieczeństwa (np. w ramach unijnego schematu EUCC), może on zastąpić ocenę – jednak na dziś brak jeszcze gotowych schematów dla wszystkich typów produktów.
• Produkty krytyczne (o najwyższym ryzyku) – mogą wymagać uzyskania formalnego certyfikatu cyberbezpieczeństwa UE na poziomie co najmniej “substantial” przed wprowadzeniem na rynek. To najsurowsza opcja, zakładająca bardzo rygorystyczne sprawdzenie produktu (podobne do dzisiejszych certyfikatów Common Criteria czy przyszłych certyfikatów wg EU Cybersecurity Act).

Szczegółowy podział na klasy produktów ważnych (Annex III) i krytycznych (Annex IV) jest dość techniczny – przykładowo za krytyczne uznano m.in. systemy operacyjne, zapory sieciowe, menedżery haseł czy niektóre elementy infrastruktury przemysłowej. Produkty nie mieszczące się w tych listach traktowane są jako “pozostałe” (niższe ryzyko). Dla producentów istotne jest, by określić kategorię swojego wyrobu już na początku prac, ponieważ od tego zależy rodzaj wymaganej certyfikacji i nakład pracy potrzebny do wprowadzenia produktu na rynek. Niezależnie jednak od ścieżki oceny, podstawowe wymagania bezpieczeństwa są wspólne – omówimy je poniżej.

Zarządzanie podatnościami i reagowanie na incydenty

Żaden produkt nie jest idealnie bezpieczny na zawsze – najważniejsze jest, jak radzimy sobie z nowymi podatnościami i incydentami bezpieczeństwa po wydaniu produktu. Cyber Resilience Act narzuca rygorystyczne obowiązki w tym zakresie, aby producenci aktywnie dbali o bezpieczeństwo swoich wyrobów w trakcie ich używania przez klientów.

Po pierwsze, producent musi monitorować pojawiające się podatności dotyczące produktu i jego komponentów oraz skutecznie je usuwać. Innymi słowy, firma powinna mieć wdrożony proces Vulnerability Management – od śledzenia informacji (np. nowe zgłoszenia CVE w komponentach open-source) po wypuszczanie poprawek. Wszelkie wykryte luki w swoim produkcie producent musi niezwłocznie załatać i udostępnić użytkownikom stosowną aktualizację. Co ważne, CRA wymaga posiadania oficjalnej polityki ujawniania podatności (Coordinated Vulnerability Disclosure) – aby osoby trzecie (np. badacze bezpieczeństwa) miały gdzie zgłaszać znalezione luki. Producent musi wyznaczyć punkt kontaktowy (single point of contact) do przyjmowania takich zgłoszeń i jasno komunikować go użytkownikom. To może być np. dedykowany adres e-mail do zgłaszania luk lub platforma bug bounty – ważne, by kanał był łatwo dostępny.

Po drugie, jeżeli dojdzie do poważnego incydentu bezpieczeństwa związanego z produktem (np. aktywnie wykorzystywana podatność, atak skutkujący naruszeniem bezpieczeństwa użytkowników), producent ma obowiązek notyfikacji odpowiednich organów. CRA precyzuje krótkie terminy: w ciągu 24 godzin od wykrycia incydentu lub exploita trzeba zawiadomić adekwatny zespół CSIRT krajowy oraz ENISA – unijną agencję cyberbezpieczeństwa. Następnie w ciągu 72 godzin należy przekazać dodatkowy raport uzupełniający, a pełne informacje techniczne – najpóźniej w ciągu 14 dni. Jednocześnie producent musi poinformować użytkowników o zaistniałym incydencie i dostępnych środkach zaradczych bez zbędnej zwłoki. Te wymogi mają na celu szybkie ostrzeganie zarówno klientów, jak i organów przed falą ataków wykorzystujących daną lukę. Warto zaznaczyć, iż obowiązek raportowania wchodzi w życie już we wrześniu 2026 r. – a więc choćby przed pełnym stosowaniem CRA – aby wcześniej uruchomić mechanizmy wczesnego ostrzegania.

Żeby sprostać tym wymaganiom, producent musi mieć zorganizowany wewnętrzny proces reagowania na incydenty (Incident Response). W praktyce oznacza to wyznaczenie zespołu (lub osoby) odpowiedzialnej za bezpieczeństwo produktu, przygotowanie procedur na wypadek wykrycia luki, kanałów komunikacji z klientami, szablonów zgłoszeń do CSIRT/ENISA itd. Warto z wyprzedzeniem opracować plan reakcji – tak by w stresującej sytuacji awaryjnej spełnić 24-godzinny deadline na zgłoszenie. Dla inżynierów oznacza to m.in.: wdrożenie mechanizmów telemetrii i alertowania w produkcie (aby gwałtownie dowiedzieć się o nietypowych zdarzeniach), integrację monitoringu z bazami CVE (np. NVD – National Vulnerability Database) oraz posiadanie gotowych procedur awaryjnych (np. wyłączenia podatnej usługi, zdalnego wylogowania użytkowników, wycofania certyfikatów itp.). Poniżej przykładowy wycinek logu obrazujący taki proces zarządzania podatnością i incydentem:

2027-09-11T08:15:43Z [SECURITY] CVE-2026-12345 detected in component "openssl-1.1.1t" 2027-09-11T08:15:43Z [UPDATE] Downloading security patch for OpenSSL... 2027-09-11T08:15:45Z [UPDATE] Patch applied successfully; OpenSSL updated to 1.1.1u 2027-09-11T08:15:45Z [NOTIFY] Vulnerability report sent to national CSIRT and ENISA

Przykład: log urządzenia wskazuje, iż automatycznie wykryto krytyczną podatność (np. w bibliotece OpenSSL), pobrano łatkę OTA i zaktualizowano komponent do bezpiecznej wersji. Na końcu proces raportujący wysyła powiadomienie do adekwatnych organów (CSIRT, ENISA) o incydencie. Taki zautomatyzowany pipeline reagowania – od detekcji, przez patch, po raport – to modelowy przykład proaktywnego spełnienia wymagań CRA.

Aktualizacje bezpieczeństwa i okres wsparcia

Jednym z najważniejszych wymagań CRA jest zapewnienie długoterminowego wsparcia i aktualizacji bezpieczeństwa dla produktów. Użytkownik kupujący sprzęt czy software musi mieć gwarancję, iż przez określony czas producent będzie publikował łatki na wykryte podatności. Rozporządzenie nakłada konkretne minima:

• Min. 5 lat wsparcia bezpieczeństwa – producent musi ustalić i podać do wiadomości tzw. support period, czyli okres, przez jaki będzie dostarczać aktualizacje zabezpieczeń dla produktu. Okres ten ma wynosić co najmniej 5 lat od wprowadzenia produktu na rynek, chyba że przewidywany czas życia produktu jest krótszy (np. jednorazowa aplikacja na wydarzenie). jeżeli jednak urządzenie lub program z natury jest używany dłużej (np. routery, systemy operacyjne), producent powinien adekwatnie wydłużyć okres wsparcia ponad 5 lat. w uproszczeniu – 5 lat to minimum, a dla wielu typów urządzeń oczekiwany będzie dłuższy okres (np. 7 czy 10 lat dla sprzętu infrastrukturalnego). Co ważne, wsparcie dotyczy wyłącznie aktualizacji bezpieczeństwa – nie oznacza to, iż producent musi dodawać nowe funkcje przez 5 lat, ale musi udostępniać łatki na luki wpływające na bezpieczeństwo.
• Bezpłatne i łatwo dostępne aktualizacje: Wszystkie aktualizacje bezpieczeństwa muszą być udostępniane nieodpłatnie. Ponadto powinny być dostarczane w sposób przyjazny dla użytkownika, tak aby łatwo było je zastosować. Dla systemu oznacza to np. automatyczne aktualizacje online lub proste komunikaty o dostępnych patchach. Dla urządzeń IoT – konieczność implementacji mechanizmu OTA (Over-The-Air), pozwalającego zdalnie wgrać firmware do urządzenia u klienta. Producent nie może przerzucić całego ciężaru na użytkownika (np. wymagając manualnego pobierania binarek ze strony); aktualizacja ma być możliwie bezobsługowa i niezbyt uciążliwa. Ten wymóg w praktyce wymusza, by już w fazie projektowania przewidzieć mechanizm aktualizacji – zarówno programowych, jak i sprzętowych (np. secure boot z możliwością patchowania systemu układowego). jeżeli urządzenie nie posiada interfejsu do aktualizacji, z góry nie spełni CRA.
• Dostępność poprawek przez 10 lat: Każdą udostępnioną aktualizację bezpieczeństwa producent musi utrzymywać dostępną do pobrania przez co najmniej 10 lat od momentu wydania produktu. Oznacza to, iż choćby jeżeli użytkownik kupił urządzenie 8 lat po premierze, powinien mieć możliwość ściągnięcia wszystkich wydanych dotąd łatek. Producent musi zatem zorganizować archiwum poprawek (np. serwer z plikami aktualizacji, repozytorium paczek) i nie może ich przedwcześnie usuwać. W praktyce najlepiej, aby łatki były dostępne co najmniej tak długo, jak najdłuższy deklarowany czas życia urządzenia.

Te wymagania stawiają duże wyzwanie przed firmami: trzeba zaplanować i sfinansować proces patch management na lata do przodu. Dla porównania – dziś wiele gadżetów IoT otrzymuje wsparcie najwyżej 1-2 lata, a potem producent porzuca produkt. W ramach CRA takie praktyki staną się niedopuszczalne. Firmy muszą zapewnić zaplecze infrastrukturalne (serwery aktualizacji, systemy powiadomień) i organizacyjne (personel do przygotowywania i testowania łatek przez lata). Być może będą tworzyć wspólne mechanizmy – np. platformy aktualizacji obsługujące całą linię produktową.

Z punktu widzenia dewelopera warto już teraz pomyśleć o automatyzacji procesu aktualizacji. W projektach software – wdrożyć continuous delivery na poprawki bezpieczeństwa. W urządzeniach – wbudować moduł sprawdzający okresowo dostępność update’u i pobierający go. Oczywiście wszystko to musi być realizowane bezpiecznie (podpisywanie cyfrowe aktualizacji, weryfikacja sygnatur przed instalacją, odporność na ataki roll-back itp.).

Dokumentacja techniczna i SBOM

Cyber Resilience Act dużą wagę przykłada do transparentności – zarówno wobec użytkownika, jak i organów nadzoru. Każdy produkt objęty regulacją musi posiadać szczegółową dokumentację techniczną w zakresie bezpieczeństwa. Dokumentacja ta (zwana często Technical File) będzie sprawdzana podczas oceny zgodności, a także może być wymagana przez urzędy podczas kontroli rynku. Co powinna zawierać? Rozporządzenie wymienia m.in.:

• Opis zastosowanych zabezpieczeń – czyli jakie mechanizmy ochronne zaimplementowano (np. szyfrowanie danych, kontrola dostępu, sandboxing modułów itp.).
• Wyniki analizy ryzyka – omówione wyżej. Należy przedstawić, jakie ryzyka zidentyfikowano i jak je zmitigowano.
• Instrukcje bezpiecznej konfiguracji – czyli poradnik dla użytkownika, jak bezpiecznie używać produktu. Może to być część ogólnej instrukcji obsługi, byle zawierała wskazówki dot. bezpieczeństwa (np. zmiana hasła, konfiguracja aktualizacji automatycznych, segmentacja sieci dla urządzeń itp.).
• Informacje o wykrytych zagrożeniach – znane słabe punkty czy ograniczenia bezpieczeństwa, o których użytkownik powinien wiedzieć. Tu producent uczciwie deklaruje, jakie pozostające ryzyka są znane (np. “produkt nie wykrywa ataków typu X, więc zalecamy dodatkowe środki Y”).
• Oraz – co bardzo ważne – wykaz komponentów oprogramowania, tzw. SBOM (Software Bill of Materials).

SBOM to nic innego jak lista wszystkich komponentów i bibliotek wykorzystanych w produkcie, wraz z ich wersjami. To jak “spis składników” w cyberprodukcie. CRA wymaga dostarczenia SBOM przynajmniej dla komponentów najwyższego poziomu (top-level dependencies) w formacie nadającym się do odczytu maszynowego. Format SBOM może być dowolny uznany (np. CycloneDX, SPDX lub SWID), byle zawierał niezbędne informacje. Po co SBOM? Dzięki niemu zarówno użytkownik, jak i organy nadzoru, mogą szybko sprawdzić, z jakich bibliotek składa się urządzenie/aplikacja. Gdy pojawi się nowa podatność (np. ujawniono lukę w popularnej bibliotece kryptograficznej), SBOM pozwoli od razu ustalić, czy dany produkt jest nią dotknięty. To ogromna zmiana jakościowa – dziś bez SBOM producenci często sami nie wiedzą, czy korzystają z wadliwej biblioteki, co opóźnia reakcję.

Dla zobrazowania, poniżej pokazano uproszczony fragment SBOM w formacie JSON (CycloneDX) dla hipotetycznego produktu. Wykazano dwa komponenty open-source wraz z wersjami i identyfikatorami (PURL, CPE):

{ "bomFormat": "CycloneDX", "components": [ { "name": "OpenSSL", "version": "1.1.1u", "purl": "pkg:generic/openssl@1.1.1u", "cpe": "cpe:/a:openssl:openssl:1.1.1u" }, { "name": "Zlib", "version": "1.2.13", "purl": "pkg:generic/zlib@1.2.13" } ] }

Taki SBOM informuje nas, iż produkt korzysta m.in. z OpenSSL 1.1.1u oraz Zlib 1.2.13. Mając te dane, można natychmiast sprawdzić w bazie NVD czy dla tych wersji istnieją znane CVE. jeżeli np. wersja OpenSSL 1.1.1t (poprzedzająca 1.1.1u) miała krytyczną lukę, to widząc w SBOM 1.1.1u wiemy, iż produkt jest bezpieczny przed tamtym CVE. Analogicznie, wykrycie nowej podatności w Zlib pozwoli łatwo ustalić, które produkty (posiadające Zlib 1.2.13 według SBOM) wymagają aktualizacji.

Z perspektywy producenta wygenerowanie SBOM powinno stać się standardowym krokiem w procesie build/release. Istnieją już narzędzia automatyzujące to zadanie (np. Syft, OWASP CycloneDX maven plugin, etc.). Warto zintegrować je z CI/CD, aby przy każdej wersji otrzymywać aktualny SBOM. Pamiętajmy, iż SBOM również wchodzi w skład dokumentacji technicznej podlegającej kontroli, a producent ma obowiązek przechowywać ją przez 10 lat od wprowadzenia produktu. Oznacza to konieczność archiwizacji wszystkich istotnych dokumentów bezpieczeństwa i udostępniania ich na żądanie organom (np. UOKiK w Polsce lub innemu organowi nadzoru rynku).

Odpowiedzialność za łańcuch dostaw (third-party components)

Nowe regulacje przenoszą ciężar odpowiedzialności na producenta za cały ekosystem komponentów użytych w produkcie. Mówiąc wprost: jeśli korzystasz z bibliotek open-source lub modułów firm trzecich, to Ty – jako producent końcowego wyrobu – odpowiadasz za ich zgodność z wymogami bezpieczeństwa CRA. Nie można zasłonić się tym, iż “to wina dostawcy komponentu” – firma integrująca musi wykazać należytą staranność (due diligence) wobec swoich dostawców.

W praktyce oznacza to konieczność wdrożenia procedur oceny i kwalifikacji dostawców pod kątem bezpieczeństwa. Producent powinien wybierać tylko te komponenty (hardware czy software), które spełniają wysokie standardy bezpieczeństwa, oraz okresowo audytować lub wymagać raportów bezpieczeństwa od dostawców. Przykładowo, jeżeli nasz produkt IoT korzysta z modułu Wi-Fi od zewnętrznego producenta, powinniśmy upewnić się, iż moduł ten ma aktualizowalne oprogramowanie i znane mechanizmy zabezpieczeń. jeżeli używamy systemu operacyjnego lub frameworka – musimy śledzić jego aktualizacje i luki (co ułatwia wspomniany SBOM).

Szczególnym wyzwaniem jest tu wszechobecne użycie open-source. Biblioteki open-source często stanowią rdzeń aplikacji (od systemów typu Linux, po drobne paczki NPM/PyPI). CRA wymusza aktywne monitorowanie podatności w zależnościach open-source. Producent powinien na bieżąco sprawdzać publiczne bazy (NVD, GitHub Advisories etc.) pod kątem nowych CVE w komponentach i niezwłocznie aktualizować zależności do bezpiecznych wersji. Wróćmy do przykładu podatności Log4Shell: ujawnienie tej luki wymagało od setek firm sprawdzenia, czy używają biblioteki Log4j. Dzięki SBOM zadanie to będzie prostsze – ale i tak producent musi mieć zespół/proces, który w ciągu dni (nie miesięcy) zidentyfikuje zagrożenie i wyda patch.

Ponadto, CRA sugeruje potrzebę zawierania odpowiednich zapisów w umowach z dostawcami. Np. jeżeli integrujemy czyjś moduł, warto w umowie zagwarantować sobie dostęp do informacji o podatnościach i aktualizacjach tego modułu w przyszłości. Ostatecznie jednak, choćby jeżeli dostawca nas zawiedzie, odpowiedzialność przed organami spadnie na producenta finalnego wyrobu.

Podsumowując: łańcuch dostaw musi być bezpieczny od podstaw, a producent pełni rolę koordynatora bezpieczeństwa całego ekosystemu swojego produktu. Wymaga to większej kontroli nad tym, co trafia do naszego kodu. W praktyce firmy będą musiały inwestować w Bill of Materials nie tylko dla software, ale i hardware (listy komponentów sprzętowych), testy bezpieczeństwa komponentów (np. czy układ zewnętrzny nie wprowadza podatności) oraz monitoring zależności. Dla projektów mocno bazujących na open-source, konieczna będzie szczególna uważność – stąd zalecenie, by korzystać z popularnych, wspieranych projektów OSS (gdzie społeczność gwałtownie reaguje na luki) i unikać porzuconych repozytoriów “no-name”.

Na tym kończymy przegląd głównych wymagań. W następnej sekcji zebraliśmy wszystko w poręczną checklistę – warto ją wykorzystać jako szybką referencję.

Checklista wymagań CRA

Poniżej znajduje się lista najważniejszych obowiązków nakładanych na producentów przez Cyber Resilience Act. Możesz użyć jej, aby zweryfikować, czy o niczym nie zapomniano przy planowaniu zgodności Twojego produktu:

• Secure by design & default: Produkt zaprojektowany zgodnie z zasadami bezpiecznego kodowania; brak znanych podatności na starcie; domyślna konfiguracja maksymalnie bezpieczna (unikalne hasła, wyłączone zbędne usługi itp.).
• Analiza ryzyka: Przeprowadzono ocenę ryzyka cyberbezpieczeństwa dla produktu; udokumentowano zagrożenia i wdrożone środki zaradcze. Ewentualne odstępstwa od wymagań uzasadniono na piśmie.
• Procedura oceny zgodności: Określono kategorię produktu (zwykły, istotny kl. I/II, krytyczny); przeprowadzono odpowiednią ocenę (samodzielną lub z udziałem jednostki certyfikującej) i sporządzono deklarację zgodności UE. Produkt oznakowany CE jako potwierdzenie spełnienia wymagań CRA.
• Zarządzanie podatnościami: Wdrożono proces monitorowania podatności (CVE) we własnym produkcie i komponentach; ustanowiono politykę zgłaszania luk (CVD) i wyznaczono punkt kontaktowy; zapewniono szybkie usuwanie znanych podatności poprzez aktualizacje.
• Reagowanie na incydenty: Przygotowano procedury Incident Response; zagwarantowano zdolność zgłoszenia poważnego incydentu/aktywnej podatności do CSIRT i ENISA w ciągu 24h od wykrycia; opracowano szablony raportów 72h/14dni; wyznaczono zespół reagowania.
• Aktualizacje bezpieczeństwa (5+ lat): Ustalono i zakomunikowano minimalny okres wsparcia bezpieczeństwa (min. 5 lat lub dłużej w zależności od produktu); zorganizowano infrastrukturę do regularnego wydawania darmowych aktualizacji zabezpieczeń.
• Mechanizm OTA: Dla urządzeń – zaimplementowano bezpieczny mechanizm zdalnych aktualizacji firmware/oprogramowania (weryfikacja podpisów, integralność); dla software – auto-update lub łatwy instalator poprawek.
• Archiwizacja poprawek (10 lat): Zapewniono, iż wszystkie udostępnione łatki będą dostępne do pobrania przez co najmniej 10 lat od premiery produktu (np. utrzymywany serwer aktualizacji, repozytorium plików).
• Dokumentacja bezpieczeństwa: Przygotowano kompletną dokumentację techniczną zgodnie z wymaganiami (opis zabezpieczeń, analiza ryzyka, instrukcje itp.). Dokumentacja jest przechowywana przez 10 lat i dostępna na żądanie organów.
• SBOM: Wygenerowano Software Bill of Materials dla produktu (co najmniej lista komponentów najwyższego poziomu); SBOM dołączony do dokumentacji i udostępniany użytkownikom/organom w czytelnym formacie.
• Bezpieczeństwo dostawców: Zweryfikowano dostawców komponentów pod kątem bezpieczeństwa; zapewniono umowne gwarancje i informacje od dostawców; wdrożono monitoring podatności w komponentach zewnętrznych (open-source i komercyjnych).
• Single Point of Contact: Wyznaczono jednolity punkt kontaktowy dla użytkowników w kwestiach bezpieczeństwa (np. adres email do zgłoszeń); informacja o kontakcie jest łatwo dostępna dla klientów (np. w instrukcji lub na stronie produktu).

Powyższa lista nie zastępuje oczywiście pełnego tekstu rozporządzenia, ale stanowi praktyczną ściągawkę. jeżeli przy którymkolwiek punkcie masz wątpliwości lub odpowiedź brzmi “nie”, produkt prawdopodobnie wymaga jeszcze pracy, aby osiągnąć zgodność z CRA.

Jak się przygotować – praktyczne kroki dla producentów

Patrząc na wymagania CRA, wielu producentów może poczuć przytłoczenie zakresem zmian. Kluczem jest jednak rozpoczęcie przygotowań już teraz, krok po kroku. Oto plan działania, który pomoże wdrożyć wymagania w sposób metodyczny:

1. Zbadaj, czy Twój produkt podlega CRA: Przeanalizuj, czy Twój obecny lub planowany produkt to “produkt z elementami cyfrowymi” w rozumieniu rozporządzenia. W 99% przypadków oprogramowanie, usługi SaaS połączone z aplikacją czy urządzenia IoT będą objęte. Sprawdź też, czy nie łapiesz się na wyłączenia sektorowe. jeżeli tworzysz coś dla branży medycznej, motoryzacyjnej itp., upewnij się, które regulacje Cię obowiązują.
2. Dokonaj wstępnej analizy luk (gap analysis): Porównaj obecne praktyki w Twojej firmie z wymaganiami CRA (np. używając powyższej checklisty). Zidentyfikuj obszary wymagające pracy – np. brak procesu CVD, zbyt krótki okres wsparcia, brak mechanizmu aktualizacji OTA, niedostateczna dokumentacja. Oceń ryzyko i priorytety: które luki mogą najbardziej przeszkodzić w uzyskaniu certyfikacji?
3. Zbuduj zespół ds. bezpieczeństwa produktu: jeżeli jeszcze nie masz wyodrębnionej roli zajmującej się bezpieczeństwem, czas to zmienić. Powinna istnieć jasno przypisana odpowiedzialność za zgodność z CRA – np. Product Security Officer lub dedykowany zespół ds. bezpieczeństwa produktu. Osoby te będą koordynować tworzenie dokumentacji, analizy ryzyka, kontakt z certyfikatorami, reakcje na incydenty itp.
4. Szkolenie i kultura bezpieczeństwa: Zapewnij szkolenia dla zespołów deweloperskich z zakresu secure codingu i wymagań CRA. Wprowadź zasady bezpieczeństwa do cyklu życia developmentu (SSDLC) – np. wymagaj przeglądów kodu pod kątem bezpieczeństwa, dodaj etap testów bezpieczeństwa do definicji “Done”. Zbuduj kulturę, w której zgłaszanie potencjalnych podatności nie jest “wstydem”, ale jest oczekiwane i nagradzane.
5. Implementacja mechanizmów technicznych: Rozpocznij prace nad brakującymi funkcjonalnościami:
   • Mechanizm aktualizacji: o ile produkt go nie miał – zaprojektuj system patchowania (np. moduł OTA dla urządzeń, auto-updater dla aplikacji desktop).
   • Logowanie zdarzeń bezpieczeństwa: Dodaj w produkcie logi i telemetrię, które umożliwią wykrycie incydentów (np. logowanie prób logowania, ważnych operacji, integracja z SIEM).
   • Hardening konfiguracji: Zmień domyślne ustawienia w firmware/software na bezpieczniejsze (silne szyfry, wyłączone debug interfejsy, unikalne klucze).
   • SBOM automatyzacja: Włącz do procesu build generowanie SBOM (np. skrypt w CI, który po zbudowaniu binarki wywoła narzędzie SBOM i zapisze wynik). Ustal format SBOM i przetestuj jego poprawność.
6. Wdrożenie procesów organizacyjnych:
   • Proces zarządzania podatnościami: Określ, jak monitorujesz CVE (np. subskrypcja alertów dla komponentów, wykorzystanie narzędzi SCA – Software Composition Analysis), kto decyduje o wydaniu patcha, jak szybko. Przygotuj plan “jeśli jutro wyjdzie krytyczny CVE w naszej bibliotece X, to…”.
   • Proces reakcji na incydenty: Spisz plan reakcji – kto zbiera informacje, kto komunikuje się z klientami i urzędami, jakie narzędzia wykorzystacie (np. czy masz gotowy szablon maila do klientów z ostrzeżeniem?). Przećwicz scenariusz ataku (np. wewnętrzny security drill na symulowany incydent).
   • Kontakt dla bezpieczeństwa: Utwórz stronę bezpieczeństwa (Security/Privacy page) dla Twojego produktu/firmy, podaj tam kontakt do zgłaszania luk. Możesz rozważyć program bug bounty lub przynajmniej jasno ogłoszoną zachętę do zgłaszania problemów.
7. Aktualizacja dokumentacji i formalności: Zacznij tworzyć wymaganą dokumentację już podczas prac rozwojowych. Łatwiej pisać na bieżąco o zabezpieczeniach i ryzykach, niż odtwarzać to po fakcie. Zbieraj wyniki testów bezpieczeństwa, twórz raporty z analizy ryzyka, zapisuj decyzje projektowe związane z bezpieczeństwem. Te materiały posłużą do skompletowania formalnej dokumentacji dla oceny zgodności.
   • Zaplanuj również proces certyfikacji – rozejrzyj się, jakie podmioty mogą pełnić rolę jednostki notyfikowanej dla Twojego typu produktu. Być może warto skonsultować się wcześniej, by dowiedzieć się, na co zwrócą uwagę audytorzy.
8. Monitoruj rozwój standardów i wytycznych: Unijny Komitet ds. cyberbezpieczeństwa będzie publikował specyfikacje wspólne, normy zharmonizowane, wytyczne dla poszczególnych branż. Śledź komunikaty ENISA, komisji UE, fora branżowe – będą pojawiać się ułatwienia, np. gotowe standardy SBOM czy schematy certyfikacji. Trzymaj rękę na pulsie, żeby wykorzystać dostępne narzędzia ułatwiające zgodność.
9. Rozważ certyfikacje i dobre praktyki już teraz: Choć pełne wymogi CRA wejdą w życie w 2027, możesz już wcześniej podnieść poziom zabezpieczeń poprzez dobrowolne certyfikacje (np. IEC 62443 dla IoT, ISO 27001 dla procesów bezpieczeństwa, certyfikaty Common Criteria dla komponentów). Spełnienie tych standardów może ułatwić późniejszą ocenę zgodności z CRA, bo wiele wymagań się pokrywa. Warto również korzystać z ram takich jak OWASP ASVS, IoT Security Foundation Guidelines itp., by mieć punkt odniesienia przy hardeningu produktu.

Na koniec – nie czekaj do ostatniej chwili. Choć 2027 wydaje się odległy, zakres prac jest duży. Firmy, które zignorują CRA, mogą obudzić się z ręką w nocniku, gdy nie będą mogły legalnie sprzedawać swoich produktów po 2027 roku. Lepiej potraktować nadchodzące miesiące i lata jako okres na ulepszenie swojego produktu. Inwestycje w bezpieczeństwo dziś nie tylko zapewnią zgodność z prawem, ale po prostu zwiększą konkurencyjność Twojego rozwiązania. Coraz więcej klientów zwraca uwagę na bezpieczeństwo i długi okres wsparcia – CRA niejako formalizuje te oczekiwania.

Podsumowanie

Cyber Resilience Act ustanawia nowy standard dla producentów – bezpieczeństwo od etapu projektowania, ciągłe zarządzanie podatnościami, transparentność komponentów (SBOM) i wieloletnie wsparcie. To wyzwanie, ale i szansa na uporządkowanie procesów tworzenia lepszych, bardziej odpornych produktów. Im wcześniej zaczniesz dostosowanie, tym łagodniej przejdziesz przez obowiązkową certyfikację. Bezpieczeństwo przestaje być tabu – staje się bezapelacyjnie obowiązkowe (co zresztą od dawna postulowali eksperci). Przygotuj swój zespół, swój kod i swoją dokumentację – tak, aby w momencie wejścia w życie CRA móc spokojnie powiedzieć: nasz produkt jest gotowy i spełnia wymagania. Powodzenia!

Zobacz też podsumowującą ikonografikę:

Bibliografia