Pluskwa w pluskwiakach

Wyobraźmy sobie taką sytuację. Polska firma — z miastem wojewódzkim w nazwie — produkuje routery LTE. Kompletny biznes: projektowanie elektroniki, własny firmware, montaż w Polsce, dystrybucja do operatorów hurtowych i klientów detalicznych w całej Unii. Sprzedaż dwadzieścia parę milionów euro rocznie, czterystu pracowników, certyfikat ISO 9001 wiszący w korytarzu między sekretariatem a serwerownią.

Pewnego ranka, w trzecim kwartale 2027 r., do siedziby firmy wchodzi inspektor Urzędu Komunikacji Elektronicznej z dwiema decyzjami administracyjnymi. Pierwsza — zakaz dalszego wprowadzania flagowego modelu routera do obrotu. Druga — nakaz wycofania z rynku stu osiemdziesięciu tysięcy egzemplarzy sprzedanych w ciągu ostatnich szesnastu miesięcy. Powód? Niespełnienie wymagań zasadniczych załącznika I do rozporządzenia (UE) 2024/2847 — Cyber Resilience Act. Konkretnie: brak procesu obsługi podatności, brak SBOM-u, brak gwarancji aktualizacji bezpieczeństwa przez okres odpowiadający spodziewanej długości użytkowania produktu, niespełnienie wymogu „secure by default", brak deklaracji zgodności obejmującej cyberbezpieczeństwo. Kara — do 2,5% globalnego rocznego obrotu lub 15 milionów euro, w zależności od tego, która kwota jest wyższa.

Brzmi jak czarny scenariusz? Po jedenastym grudnia 2027 r. będzie codziennością. I dotyczy nie tylko routerów — dotyczy każdej klamki bluetoothowej, każdego inteligentnego termometru, każdej aplikacji SaaS dla księgowych, każdej kasy fiskalnej z modułem Wi-Fi i każdego sterownika PLC, który Państwa firma wytwarza, importuje albo dystrybuuje pod własną marką. Cyber Resilience Act — rozporządzenie unijne, które weszło w życie 10 grudnia 2024 r., a od grudnia 2027 r. zaczyna w pełni obowiązywać — przebudowuje cały reżim odpowiedzialności w obszarze produktów cyfrowych.

Co dokładnie reguluje CRA

Reżim CRA nakłada zharmonizowane wymagania cyberbezpieczeństwa na „produkty z elementami cyfrowymi" — w skrócie PDE (products with digital elements). Definicja jest celowo szeroka: każdy produkt sprzętowy lub programowy, którego zamierzonym zastosowaniem jest bezpośrednia lub pośrednia komunikacja danych z innym urządzeniem albo siecią. Mówiąc prościej — wszystko, co ma „chip i Wi-Fi", a także sam czysty kod, czyli oprogramowanie wprowadzane do obrotu jako produkt — w tym SaaS w wariancie on-premise oraz aplikacje mobilne dystrybuowane komercyjnie.

Z zakresu wyłączone są: wyroby medyczne objęte rozporządzeniami MDR i IVDR, pojazdy podlegające rozporządzeniu (UE) 2019/2144, niektóre statki powietrzne, produkty obronne i jądrowe, wybrane wyroby objęte sektorowymi przepisami transportowymi, oraz oprogramowanie wolne i otwarte rozpowszechniane bez działalności gospodarczej. Wszystko inne — od kasy fiskalnej, przez termostat smart, po system ERP w wersji on-premise — wpada pod CRA.

Rozporządzenie dzieli produkty z elementami cyfrowymi na cztery kategorie ryzyka. Domyślna — czyli typowy produkt konsumencki — wymaga samokontroli zgodności (self-assessment) z wymaganiami zasadniczymi załącznika I. Klasa „ważna" I i II (Important Class I, II) obejmuje produkty, których kompromitacja może prowadzić do większych szkód: menedżery haseł, antywirusy, systemy uwierzytelnienia tożsamości, urządzenia smart home klasy A, sterowniki PLC, routery przemysłowe, monitoring CCTV. Tu konieczna jest weryfikacja przez jednostkę notyfikowaną dla wybranych aspektów (klasa II) lub zastosowanie norm zharmonizowanych (klasa I). Kategoria „krytyczna" — produkty, których awaria może mieć daleko idące skutki dla bezpieczeństwa publicznego, w tym moduły kryptograficzne klasy enterprise i pewne komponenty infrastruktury klucza publicznego — będzie objęta dedykowanymi schematami certyfikacji w rozumieniu Cybersecurity Act.

Każdy produkt — zanim trafi na rynek po 11 grudnia 2027 r. — musi mieć deklarację zgodności CE, w której producent oświadcza spełnienie wymagań CRA. To ten sam mechanizm, który większość producentów zna z dyrektyw EMC i niskonapięciowej, tylko wzbogacony o nowy obszar — cyberbezpieczeństwo — i o trzeci, dotąd nieznany komponent: notyfikację „bug-related" do ENISA.

Wymagania zasadnicze — co musi mieć produkt

Załącznik I do CRA składa się z dwóch części. Część pierwsza opisuje właściwości cyberbezpieczeństwa samego produktu, których spełnienie producent musi udokumentować i zadeklarować. Część druga — proces obsługi podatności, który producent musi utrzymywać przez cały oczekiwany okres użytkowania produktu, z dolnym limitem pięciu lat od ostatniego wprowadzenia danego modelu do obrotu, niezależnie od tego, jak krótki cykl handlowy producent zaplanował.

Z części pierwszej najistotniejsze są: dostarczenie produktu bez znanych eksploatowalnych podatności w momencie wprowadzania do obrotu; konfiguracja domyślna stanowiąca „secure by default" — bez fabrycznych haseł typu admin/admin, bez otwartych portów, które nie są niezbędne, bez niepotrzebnych usług; ochrona poufności i integralności danych przetwarzanych i przesyłanych za pomocą najnowocześniejszych mechanizmów kryptograficznych; uwierzytelnienie i kontrola dostępu, w tym możliwość uwierzytelnienia wieloskładnikowego tam, gdzie ma to sens funkcjonalny; rejestrowanie zdarzeń bezpieczeństwa w sposób umożliwiający użytkownikowi monitorowanie i analizę post mortem; mechanizmy automatycznych aktualizacji bezpieczeństwa, dostarczanych użytkownikowi bez opłat przez okres oczekiwanej długości użytkowania.

Z części drugiej kluczowe są dwa obowiązki, które wybijają polskim producentom z głowy ostatnie złudzenia, że CRA jest „papierową regulacją". Po pierwsze, obowiązek tworzenia i utrzymywania listy materiałów programowych — SBOM (Software Bill of Materials) — w formacie nadającym się do automatycznego przetwarzania. Bez SBOM nie ma zarządzania podatnościami zewnętrznymi: jeśli producent nie wie, jakich bibliotek używa, nie wie też, gdzie uderzy następny CVE. Po drugie — proces skoordynowanego ujawniania podatności (CVD/VDP): opublikowana polityka, w której każdy badacz bezpieczeństwa znajduje kanał kontaktu, ramy czasowe odpowiedzi, zasady embargo i zobowiązanie producenta do publikacji łatki w określonym terminie.

Trzy zegary, które ruszyły 11 grudnia 2024 r.

Od momentu wejścia rozporządzenia w życie biegną trzy odrębne zegary, których lekceważenie będzie kosztowne — i każdy z nich uruchamia inne obowiązki.

Pierwszy — zegar raportowania. Od 11 września 2026 r. każdy producent ma obowiązek raportować do ENISA, za pośrednictwem nowej, jednolitej platformy zgłoszeniowej, aktywnie wykorzystywane podatności — czyli takie, o których producent wie, że są w danym momencie używane przeciwko użytkownikom — oraz poważne incydenty dotyczące produktu. Reżim raportowania jest trzystopniowy i będzie znany każdemu, kto pracował z RODO i NIS-2: wczesne ostrzeżenie w 24 godziny od pozyskania wiedzy, zgłoszenie pełne w 72 godziny, raport końcowy w 14 dni. Nieprzestrzeganie tych terminów to autonomiczna podstawa kary administracyjnej.

Drugi — zegar zgodności produktu. Od 11 grudnia 2027 r. każdy nowy produkt z elementami cyfrowymi wprowadzany do obrotu w UE musi spełniać wymagania zasadnicze załącznika I i mieć deklarację zgodności CE obejmującą CRA. Produkty „w drodze" (już wprowadzone do obrotu wcześniej) korzystają z ograniczonego okresu przejściowego, ale każda nowa wersja, każda istotna modyfikacja, każdy nowy SKU — startuje od nowa, w pełnym reżimie.

Trzeci — zegar cyklu życia. Producent jest zobowiązany do dostarczania bezpłatnych aktualizacji bezpieczeństwa przez okres odpowiadający oczekiwanemu okresowi użytkowania produktu, a w żadnym wypadku nie krótszy niż pięć lat od ostatniego wprowadzenia danego modelu do obrotu. Dla producentów, którzy budowali biznes wokół „dwuletnich generacji" — to fundamentalna zmiana modelu finansowego.

Osiemdziesiąt procent — nie statystyka, polski problem

Z naszych rozmów z polskimi producentami sprzętu i oprogramowania w drugiej połowie 2025 r. i pierwszym kwartale 2026 r. wyłania się obraz, który Fib.Code obserwuje z rosnącym niepokojem. Spośród około dwustu firm wytypowanych jako PDE-relevant — producenci IoT, automatyki, oprogramowania użytkowego, sprzętu sieciowego — z którymi prowadziliśmy rozmowy diagnostyczne, ponad 80% nie ma żadnego procesu obsługi podatności, ponad 70% nigdy nie wytworzyło SBOM, ponad 60% nie ma kanału CVD, a niemal połowa ankietowanych członków zarządu nie kojarzy nawet skrótu CRA. Co więcej — w grupie firm wdrażających ISO/IEC 27001 albo posiadających certyfikat — dane wyglądają podobnie. Bo norma 27001 obejmuje organizację, a nie produkt.

To nie jest zaniedbanie. To efekt poślizgu informacyjnego. CRA nie ma swojej polskiej ustawy implementującej, bo nie potrzebuje — rozporządzenie unijne stosowane jest bezpośrednio. Nie ma więc rządowej kampanii, sejmowej debaty, audycji w radiowej Trójce. Jest cicho — i to milczenie odbija się czkawką w kalendarzu produktowym, w którym data 11 grudnia 2027 r. wygląda jak „daleka przyszłość". W rzeczywistości oznacza ona, że do końca 2026 r. trzeba mieć gotowy proces, dokumentację i zaprojektowany pipeline aktualizacji — bo produkt wprowadzany na rynek w 2027 r. powstaje i jest projektowany dziś.

Kary — wzorowane na RODO, liczone od obrotu globalnego

System sankcji jest skopiowany z mechaniki znanej z ogólnego rozporządzenia o ochronie danych. Naruszenie wymagań zasadniczych załącznika I — do 15 milionów euro lub 2,5% globalnego rocznego obrotu, w zależności od tego, która kwota jest wyższa. Naruszenie pozostałych obowiązków (raportowanie, oznakowanie CE, dokumentacja techniczna) — do 10 milionów euro lub 2% obrotu. Wprowadzanie organu nadzoru rynku w błąd — do 5 milionów euro lub 1% obrotu.

Co istotne — kary nakładają organy nadzoru rynku poszczególnych państw członkowskich. W przypadku Polski najprawdopodobniej Urząd Komunikacji Elektronicznej, choć trwa dyskusja o roli Urzędu Ochrony Konkurencji i Konsumentów oraz Departamentu Cyberbezpieczeństwa MSWiA. Niezależnie od ostatecznego rozdziału kompetencji, kara administracyjna nie jest jedynym ryzykiem. W parze z nią idą decyzje o wycofaniu produktu z rynku, decyzje o zakazie wprowadzania do obrotu oraz dramatyczne ryzyko reputacyjne wynikające z wpisu produktu do bazy Safety Gate (dawniej RAPEX) i publikacji informacji o niespełnieniu wymagań.

Dla kontekstu — pewien zachodnioeuropejski producent, który w 2025 r. dał się zaskoczyć rozporządzeniu o akumulatorach, zapłacił karę pięciocyfrową w euro, ale stracił dwa kontrakty hurtowe o wartości ośmiu cyfr. Schemat się powtórzy.

CRA, NIS-2 i RODO — splot, którego nie da się rozplątać osobno

Producent wytwarzający routery dla operatora telekomunikacyjnego podpada jednocześnie pod CRA — jako producent produktu z elementami cyfrowymi — i pod NIS-2 — jako uczestnik łańcucha dostaw podmiotu kluczowego. A jeśli produkt przetwarza dane użytkowników, to także pod RODO — jako podmiot, który projektuje narzędzie wpływające na ochronę danych osobowych w rozumieniu art. 25 (privacy by design). To samo dotyczy producentów oprogramowania dla samorządów, sprzętu monitoringu wizyjnego, urządzeń telemedycznych nieobjętych MDR i systemów ERP.

W praktyce oznacza to, że dokumentacja techniczna CRA, polityki bezpieczeństwa NIS-2 i rejestr czynności przetwarzania RODO muszą być spójne, a nie konkurujące. Wdrożenie CRA „obok" istniejącego systemu zarządzania bezpieczeństwem informacji to dyplomatyczne określenie na podwojenie kosztów i podwojenie ryzyka błędu. O integracji NIS-2 i RODO w jednolity system bezpieczeństwa pisaliśmy w artykule poświęconym nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa — CRA dokłada do tego trzecią warstwę, ale logika integracji jest ta sama: jedna metodyka analizy ryzyka, jeden zestaw polityk, jeden zarząd, który podpisuje całość.

Dziewięć kroków do CRA-readiness

Na podstawie projektów, które Fib.Code prowadzi obecnie z producentami z trzech krajów Unii, wypracowaliśmy sekwencję, którą polecamy każdemu zarządowi, dla którego CRA brzmi nadal abstrakcyjnie. Kolejność kroków ma znaczenie.

Krok pierwszy — kwalifikacja produktu. Czy produkt jest PDE w rozumieniu CRA? Jaka kategoria ryzyka — domyślna, ważna I, ważna II, krytyczna? Czy obejmują go wyłączenia sektorowe? To jednostronicowy dokument, ale bez niego cała dalsza praca może okazać się robieniem zgodności z niewłaściwym reżimem.

Krok drugi — gap-analysis wobec załącznika I. Lista wszystkich wymagań zasadniczych zestawiona z aktualnym stanem produktu i procesów. Co już jest, co trzeba zbudować, co trzeba przeprojektować. Tu zwykle ujawnia się skala pracy — i to, że kluczowe braki nie są w kodzie, lecz w procedurach.

Krok trzeci — SBOM i inwentaryzacja zależności. Wybór formatu (CycloneDX, SPDX), konfiguracja narzędzi do automatycznego generowania, wpięcie w pipeline CI/CD, korelacja z bazami CVE. Bez SBOM żaden proces zarządzania podatnościami nie zadziała powyżej rozmiaru zespołu pięcioosobowego.

Krok czwarty — proces CVD/VDP. Polityka skoordynowanego ujawniania podatności: kanał security@, klucz PGP, zasady ramowe, deklarowane SLA, integracja z systemem zgłoszeniowym. To jeden z elementów, który najlepiej spisać raz, opublikować i pozwolić, żeby społeczność researcherów zrobiła darmowy audyt.

Krok piąty — Secure Development Lifecycle (SDL). Praktyki bezpiecznego rozwoju oprogramowania zintegrowane z dotychczasowym procesem inżynierskim: threat modeling we wczesnym projektowaniu, statyczna i dynamiczna analiza kodu, testy penetracyjne przed releasem, code review pod kątem bezpieczeństwa. ISO/IEC 27034 — standard, na który warto patrzeć — nie zastępuje 27001, ale uzupełnia go w obszarze, którego 27001 nie pokrywa wystarczająco głęboko.

Krok szósty — pipeline aktualizacji. Mechanizm dystrybucji łatek bezpieczeństwa, w idealnym świecie automatyczny i podpisany kryptograficznie, rozwiązujący problem, który niemal zawsze wraca: jak dostarczyć łatkę do urządzenia, które już rok temu sprzedaliśmy klientowi i z którym nie mamy stałego kanału kontaktu. Tu wracają tematy klucza publicznego, podpisu firmware, bootloadera bezpiecznego, OTA — w zależności od typu produktu.

Krok siódmy — dokumentacja techniczna i deklaracja zgodności. Pakiet, który musi być utrzymywany przez dziesięć lat od wprowadzenia produktu do obrotu i być w każdej chwili dostępny dla organu nadzoru. Analiza ryzyka, wyniki testów, schematy projektowe, instrukcja użytkownika z elementami bezpieczeństwa, deklaracja zgodności CE.

Krok ósmy — procedury raportowania. Ścieżka decyzyjna od pierwszego sygnału o podatności lub incydencie do zgłoszenia w ENISA — w 24 godziny. To wymaga zdefiniowanej roli (security officer, PSIRT — Product Security Incident Response Team), procedury dyżurów, gotowych szablonów zgłoszeń, próbnego ćwiczenia. Bez przeprowadzonego raz w pełnym wymiarze ćwiczenia tabletop pierwszy realny incydent skończy się przekroczeniem 24-godzinnego okna.

Krok dziewiąty — szkolenia i kultura. Inżynierowie, product managerowie, support, dział prawny, dział marketingu — wszyscy muszą rozumieć, co to jest podatność, dlaczego nie wolno publikować łatki bez koordynacji z osobą zgłaszającą i dlaczego materiały marketingowe nie mogą obiecywać „100-procentowego bezpieczeństwa". To kultura, której nie kupuje się szkoleniem e-learning, tylko buduje przez kilkanaście miesięcy.

Trzydzieści, sześćdziesiąt, dziewięćdziesiąt — co zdąży się zrobić w kwartale

Producent, który zacznie pracę dziś, w kwietniu 2026 r., a skończy w trzecim kwartale 2026 r., zdąży nie tylko na wrześniowe terminy raportowania ENISA, ale też zyskuje zapas czasu na grudzień 2027 r.

W pierwszych trzydziestu dniach — kwalifikacja produktu, gap-analysis, mapowanie zależności, wybór formatu SBOM, oszacowanie luki budżetowej i kompetencyjnej. Etap intensywnej pracy diagnostycznej.

W kolejnych trzydziestu — opublikowana polityka CVD, działający kanał security@, pierwsza wersja SBOM-u w pipeline, wstępna dokumentacja techniczna, zaprojektowana ścieżka raportowania incydentów. Etap, w którym zaczyna być widać postęp w narzędziach i procedurach.

W ostatnich trzydziestu — przeprowadzony tabletop incydentu, wdrożone zmiany w SDL, pierwsza pełna deklaracja zgodności na produkt referencyjny, plan szkoleniowy dla zespołu, plan rozjazdu na pozostałe SKU. Po dziewięćdziesiątym dniu organizacja wie, jakim kosztem dotrze do 11 grudnia 2027 r. — i może to liczbowo zaprezentować zarządowi, klientom B2B i ewentualnemu inwestorowi.

Dlaczego z Fib.Code

CRA nie jest pojedynczą regulacją, którą da się obsłużyć szablonem. Splata co najmniej cztery warstwy — produktową, procesową, organizacyjną i prawną — z których każda wymaga innej kompetencji. Inżynier bezpieczeństwa musi rozumieć threat modeling, kryptografię stosowaną i SBOM. Konsultant ISO — jak osadzić SDL w istniejącym systemie zarządzania jakością. Prawnik — jak zredagować deklarację zgodności i instrukcję użytkownika z minimalnym ryzykiem prawnym. Pełnomocnik ds. bezpieczeństwa informacji — jak spiąć CRA z NIS-2 i RODO w jednolity rejestr ryzyka.

Zespół Fib.Code pracuje z tym splotem od 2023 r. — najpierw przy projektach pilotażowych z producentami sprzętu sieciowego, potem przy wdrożeniach produkcyjnych w trzech państwach UE. Nasze podejście trzyma się trzech zasad. Po pierwsze, CRA wdraża się na produkt, nie na firmę — dlatego pierwsza decyzja zawsze dotyczy wyboru produktu pilotażowego, na którym przetestujemy procesy, zanim przeniesiemy je na pozostałe SKU. Po drugie, dokumentacja powstaje w trybie equity, nie compliance — czyli buduje wartość dla klienta i dla inwestora, a nie tylko zaspokaja audytora. Po trzecie, integracja z istniejącym SZBI jest obowiązkowa — bo bez tego organizacja zyskuje równoległy reżim, który po pół roku staje się sam dla siebie ciężarem.

Efektem współpracy jest pakiet, który można pokazać klientowi B2B w przetargu, organowi nadzoru w trakcie kontroli i inwestorowi w due diligence: udokumentowana zgodność z CRA, jednolita deklaracja CE, działający proces obsługi podatności, przeprowadzone szkolenia, zsynchronizowany rejestr ryzyka. Wszystko spójne z istniejącym systemem zarządzania bezpieczeństwem informacji — albo, jeżeli takiego nie ma, jednocześnie zbudowane od podstaw.

Co zrobić w tym tygodniu

Jedna rzecz. Wewnętrzny e-mail do CTO, dyrektora produkcji, pełnomocnika ds. bezpieczeństwa informacji i radcy prawnego, w którym zarząd zadaje cztery pytania. Po pierwsze — czy nasze produkty są PDE w rozumieniu CRA. Po drugie — który z nich kwalifikuje się jako pilotaż. Po trzecie — kto u nas odpowiada za proces obsługi podatności. Po czwarte — czy mamy SBOM. Jeżeli na którekolwiek z czterech pytań odpowiedź brzmi „nie wiem" lub „nie mamy" — zostało Państwu dwadzieścia jeden miesięcy, czas zacząć.

Fib.Code chętnie usiądzie przy tym stole. Zaczynamy od godzinnej rozmowy diagnostycznej, w której potrafimy wskazać, gdzie Państwo dziś są — i ile dzieli Państwa od stanu, w którym CRA z bariery wejścia staje się przewagą konkurencyjną w przetargach unijnych i na rynkach eksportowych.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. O powiązanych tematach pisaliśmy w artykułach Shadow AI — niewidzialny pracownik, który codziennie wynosi dane z firmy, AI Act a bezpieczeństwo informacji — co łączą nowe regulacje oraz Nowelizacja KSC 2026 — co musisz wiedzieć po 3 kwietnia — temat CRA splata się z każdym z nich bezpośrednio.