Cyber Resilience Act (CRA) 2026–2027: co już wiemy, czego jeszcze nie ma i jak realnie przygotować produkt — zanim pojawią się normy zharmonizowane

Co dziś wiemy na pewno (i dlaczego to nie jest “temat na 2027”)

Cyber Resilience Act potrafi wyglądać jak kolejny dokument “z Brukseli”, który będzie się dało odłożyć na później. To naturalna reakcja, zwłaszcza jeśli firma żyje w rytmie projektów: prototyp, wdrożenie, seryjna produkcja, serwis. Regulacje często przychodzą jako “wymaganie końcowe” — coś, co dopina się na finiszu. CRA zmienia tę logikę, bo nie dotyczy wyłącznie tego, co widać w produkcie w dniu sprzedaży. Dotyczy tego, czy producent potrafi utrzymać bezpieczeństwo produktu w czasie i udowodnić, że zrobił to świadomie, a nie przypadkiem.

Najważniejszy fakt jest prosty, ale ma konsekwencje strategiczne: CRA to regulacja produktowa, osadzona w mechanice rynku UE (w tym oznakowania CE). Komisja Europejska opisuje wprost, że produkty mają nosić znak CE jako sygnał zgodności z CRA, a egzekwowanie spoczywa na organach nadzoru rynku. To nie jest więc “standard IT”, który można traktować jako wewnętrzny program poprawy. To rama, która wpływa na możliwość sprzedaży.

Daty, które porządkują myślenie

W samym tekście rozporządzenia (UE) 2024/2847 widać etapowe stosowanie. CRA stosuje się od 11 grudnia 2027, ale z wyraźnymi wyjątkami. Artykuł 14 (raportowanie) ma zastosowanie od 11 września 2026, a rozdział o notyfikacji jednostek oceny zgodności (Chapter IV) od 11 czerwca 2026. To są trzy daty, które warto potraktować jak “kamienie milowe”, bo odpowiadają trzem różnym rodzajom gotowości: operacyjnej, instytucjonalnej i produktowej.

Komisja komunikuje to jeszcze prościej: CRA weszło w życie 10 grudnia 2024, obowiązki zasadnicze od 11 grudnia 2027, a raportowanie od 11 września 2026. Jeśli ktoś w firmie mówi “mamy czas do 2027”, najczęściej ma na myśli wymagania projektowe i oceny zgodności. Ale raportowanie jest wcześniejsze i dotyczy zdarzeń, które nie czekają na harmonogram.

Raportowanie: obowiązek, który wymusza proces (a nie dokument)

Wymóg raportowania jest dobrym papierkiem lakmusowym, bo pokazuje, jak CRA rozumie “cyberbezpieczeństwo produktu”. To nie jest deklaracja intencji ani “polityka”. To proces, który ma zadziałać w sytuacji stresu: gdy pojawia się aktywnie wykorzystywana podatność albo poważny incydent.

Komisja opisuje to jednoznacznie: producent ma zgłaszać aktywnie wykorzystywane podatności oraz severe incidents wpływające na bezpieczeństwo produktu. Wymagany jest “early warning” w 24 godziny od uzyskania wiedzy, pełne zgłoszenie w 72 godziny, a raport końcowy: do 14 dni po dostępności środka naprawczego dla aktywnie wykorzystywanych podatności oraz w ciągu miesiąca dla severe incidents.

W praktyce oznacza to, że organizacja potrzebuje czegoś więcej niż checklisty. Potrzebuje mechanizmu, który odpowiada na trzy pytania: skąd dowiemy się, że problem istnieje; kto kwalifikuje, czy to już “aktywnie wykorzystywane” lub “severe”; i jak zorganizujemy przekaz informacji oraz poprawkę w czasie, który nie zostawia miejsca na improwizację.

Jeśli na szkoleniach pojawia się chaos, to często dlatego, że CRA trafia w lukę między IT a produktem. Dla IT “incydent” bywa zdarzeniem w infrastrukturze. Dla producenta “incydent” jest zdarzeniem, które dotyka produktu u klienta, wersji, konfiguracji, sposobu wdrożenia. CRA wymusza połączenie tych światów w jedną odpowiedzialność.

Co obejmuje CRA: produkt jako relacja z siecią, nie “urządzenie na stole”

W praktyce oceny ryzyka maszyn uczyliśmy się, że ryzyko nie jest cechą samej maszyny — powstaje w relacji człowiek–maszyna. W CRA jest podobne przesunięcie perspektywy: bezpieczeństwo nie istnieje “w urządzeniu”, tylko w relacji produktu z otoczeniem cyfrowym, sposobem użycia i zdolnością producenta do reagowania.

Komisja, streszczając CRA, zwraca uwagę na definicję “produktów z elementami cyfrowymi” oraz to, że obowiązki raportowania dotyczą wszystkich takich produktów udostępnionych na rynku UE — również tych wprowadzonych przed 11 grudnia 2027. To jest kluczowe doprecyzowanie, bo usuwa częsty mit: “dla starych produktów to nie ma znaczenia”. Raportowanie — ma.

Czego jeszcze nie ma (norm zharmonizowanych) i dlaczego to nie powinno paraliżować

W rozmowach o CRA przewija się fraza: “nie ma jeszcze norm zharmonizowanych, więc nie da się działać”. To brzmi logicznie, ale jest w tym ukryta pułapka. Normy zharmonizowane są narzędziem, które ułatwia wykazanie zgodności (domniemanie zgodności), ale nie są jedyną drogą do zbudowania realnego bezpieczeństwa produktu. I nie są warunkiem, żeby zacząć projektować właściwie.

Komisja wprost prowadzi temat standardów przez stronę “CRA Standardisation” i informuje, że przyjęła standardisation request M/606, obejmujący zestaw 41 standardów wspierających CRA — zarówno horyzontalnych, jak i wertykalnych (produktowych). To jest ważne, bo pokazuje, że UE rozumie problem rynku: bez standardów firmy będą budować zgodność każda na własny sposób, a nadzór rynku będzie miał trudniej.

Standardy horyzontalne i wertykalne: co to znaczy dla producenta

W uproszczeniu:

• standardy horyzontalne mają opisywać “jak” budować i utrzymywać bezpieczeństwo produktu niezależnie od kategorii (procesy, metody, podejście oparte o ryzyko),
• standardy wertykalne mają doprecyzować wymagania dla konkretnych klas produktów (tam, gdzie ryzyka i architektury są typowe).

To rozróżnienie ma praktyczne konsekwencje. Jeśli tworzysz produkt przemysłowy, w którym część środowiska jest “OT” i cykl życia jest długi, to będziesz potrzebować standardów, które nie są pisane pod aplikację SaaS. I właśnie dlatego wertykalne standardy mają znaczenie: pomagają zejść z poziomu ogólnych zasad do tego, co kontrolować w realnych architekturach.

Harmonogram prac: standardy będą dochodzić etapami, nie “w paczce przed 2027”

Komisja w materiałach o implementacji CRA pokazuje, że CRA jest wdrażane etapowo, a standardy mają wspierać ten proces w czasie. Na poziomie faktów, które są dziś pewne: mamy formalnie przyjęte rozporządzenie oraz mamy uruchomiony mechanizm standaryzacji (M/606).

Najważniejsze dla praktyki jest zrozumienie jednego zdania: nawet gdy standard zostanie opracowany przez organizacje normalizacyjne, “domniemanie zgodności” w sensie prawnym pojawia się dopiero, gdy odniesienie do normy zostanie opublikowane jako norma zharmonizowana w Dzienniku Urzędowym UE. To jest mechanika wspólna dla unijnego podejścia do harmonizacji: standardy są mostem między prawem a praktyką inżynierską, ale ten most musi zostać formalnie “uznany” przez UE.

Z perspektywy producenta to oznacza, że lata 2026–2027 będą okresem, w którym część firm będzie działać na bazie własnych metod wykazania zgodności (risk – based + dowody), a część będzie już mapować się na pojawiające się standardy. I to jest normalne.

“Brak norm” nie oznacza “brak obowiązku” — oznacza większą wagę dowodów

Tu pojawia się istotna konsekwencja: jeśli nie ma norm, które dają najprostszą ścieżkę wykazania zgodności, rośnie znaczenie tego, co w praktyce audytowej jest zawsze rozstrzygające: spójny ślad decyzyjny.

Jakie ryzyka oceniliśmy? Jakie scenariusze przyjęliśmy jako realistyczne? Jak dobraliśmy środki ochronne? Jak zarządzamy podatnościami? Jak długo wspieramy produkt? Jak informujemy klienta? CRA nie wymaga, żeby producent “odgadywał przyszłe EN-normy”. Wymaga, żeby producent umiał pokazać, że jego decyzje nie były przypadkowe, tylko oparte na ryzyku i state of the art.

Jak realnie przygotować produkt na CRA (roadmapa dla producenta i integratora)

Największą wartością CRA jest to, że wymusza dojrzałość: cyberbezpieczeństwo przestaje być dodatkiem do produktu, a staje się jego własnością. Tylko że dojrzałość nie rodzi się z deklaracji. Rodzi się z procesu, który jest wystarczająco precyzyjny, by działał w praktyce, i wystarczająco prosty, by inżynieria nie zaczęła go omijać.

W ocenie ryzyka maszyn najlepsze decyzje projektowe pojawiają się wtedy, gdy przestajemy pytać “jakie zagrożenia ma maszyna”, a zaczynamy pytać “w jakich zadaniach i stanach człowiek jest narażony”. W CRA analogicznie: przestajemy pytać “jakie podatności ma produkt”, a zaczynamy pytać “w jakich warunkach produkt staje się narażony i co producent potrafi wtedy zrobić”. To przesunięcie porządkuje pracę.

Krok 1: Zdefiniuj produkt jako system (a nie jako urządzenie)

Zacznij od zdefiniowania, co w Twoim przypadku jest “produktem z elementami cyfrowymi”. Nie tylko hardware i firmware, ale też to, co bywa pomijane, bo nie mieści się w pudełku: komponenty, biblioteki, mechanizmy aktualizacji, usługi, bez których produkt nie spełnia funkcji. W CRA to jest ważne, bo odpowiedzialność producenta dotyczy tego, co trafia na rynek jako produkt — a nie tylko tego, co wytworzył dział mechaniki.

To jest też pierwszy moment, w którym integratorzy powinni być szczerzy wobec siebie: jeśli integrujesz komponenty i konfigurujesz je w sposób, który tworzy “produkt końcowy” w oczach klienta, to nie jesteś tylko “wdrożeniowcem”. Jesteś współtwórcą ryzyka i współtwórcą odpowiedzialności.

Krok 2: Zrób ocenę ryzyka CRA tak, żeby była narzędziem decyzji

Nie chodzi o “matrycę” na slajdach. Chodzi o ocenę ryzyka, która prowadzi do decyzji projektowych i jest powtarzalna.

W praktyce dobre podejście do CRA zaczyna się od prostego pytania: jakie są realne scenariusze nadużyć w środowisku klienta, a nie tylko w laboratorium? Kto ma dostęp serwisowy? Jak wygląda sieć? Jak często aktualizujemy? Jakie są konsekwencje przestoju? W przemyśle te pytania są bardziej niewygodne niż w IT, bo odpowiedzi często brzmią: “nie możemy aktualizować co tydzień” albo “nie mamy telemetrii”. I właśnie dlatego trzeba je postawić. CRA jest prawem, ale jego skutki są projektowe.

Krok 3: Zbuduj “vulnerability handling” jako proces produkcyjny, nie jako reakcję kryzysową

Wymogi raportowania opisane przez Komisję (24h/72h/14 dni/miesiąc) są bezlitosne dla organizacji, która nie ma procesu. Jeśli chcesz być gotowy na 11 września 2026, musisz potraktować “vulnerability handling” jak element cyklu życia produktu, a nie jak “zadanie zespołu security”.

To oznacza:

• jeden kanał przyjmowania zgłoszeń (CVD policy + kontakt),
• triage, który ma właściciela i kryteria,
• mechanizm budowania i dostarczania security updates,
• model komunikacji do klientów, który nie jest improwizacją,
• gotowość do raportowania (kto zgłasza, z jakimi danymi, jak szybko).

To wszystko brzmi jak praca “organizacyjna”. W praktyce to praca produktowa, bo dotyczy wersji, kompatybilności, architektury aktualizacji i strategii wsparcia.

Krok 4: Wybierz support period jak decyzję biznesową, a nie minimalny wymóg

Jeśli Twoje produkty żyją w przemyśle po 10–15 lat, to support period jest strategiczny. CRA wymusza, żeby wsparcie nie było obietnicą bez pokrycia. To znaczy, że support period powinien wynikać z analizy: jak długo produkt będzie używany, jak wygląda łańcuch dostaw komponentów, jak długo będziesz w stanie dostarczać poprawki. W praktyce support period zaczyna “ciągnąć” cały ekosystem: umowy z dostawcami, dostępność build environment, utrzymanie toolchainów, a nawet decyzje o tym, czy produkt ma funkcje zdalne, czy jest odizolowany.

Jeśli potraktujesz support period jak formalność, najpóźniej w 2027 wpadniesz w konflikt: klient oczekuje wsparcia, a Ty nie masz już zasobów ani zależności, by je dostarczyć. CRA nie tworzy tego problemu — CRA go tylko ujawnia.

Krok 5: Uporządkuj łańcuch dostaw: rozmowa z dostawcami to część zgodności

W CRA nie ma “magii”, która sprawi, że komponenty zewnętrzne staną się bezpieczne. Jeśli Twoje urządzenie bazuje na bibliotekach, modułach komunikacji, systemie operacyjnym, SDK lub komponentach sprzętowych, to Twoje ryzyko jest wprost zależne od jakości praktyk dostawcy.

Dlatego już teraz warto wprowadzić rozmowę o rzeczach, które nie brzmią jak marketing, tylko jak inżynieria:

• czy dostawca potrafi informować o podatnościach w sposób przewidywalny,
• jaki ma czas reakcji,
• czy ma proces publikacji poprawek,
• czy potrafi utrzymać komponent przez okres, który jest spójny z Twoim support period.

To jest miejsce, gdzie CRA naprawdę dotyka biznesu: dostawca, który nie potrafi obsłużyć podatności, nie jest “tańszy”. Jest ryzykiem regulacyjnym.

Krok 6: Zbuduj dokumentację jako spójny ślad: prawo → ryzyko → decyzja → dowód

W audytach zgodności zawsze wygrywa spójność. Jeżeli z oceny ryzyka wynika, że dany interfejs jest krytyczny, a dokumentacja nie opisuje, jak go zabezpieczasz; jeżeli deklarujesz, że aktualizacje są bezpieczne, a nie potrafisz pokazać, jak zapewniasz integralność pakietów; jeżeli mówisz, że masz proces obsługi podatności, a nie potrafisz pokazać, jak triage’ujesz zgłoszenia — to nie jest “brak papieru”. To jest brak dowodu, że proces działa.

W CRA, przy braku norm zharmonizowanych, ten ślad jest szczególnie ważny. Bo to on będzie podstawą rozmowy z organem nadzoru rynku, klientem enterprise, a w niektórych kategoriach produktów również z jednostką oceny zgodności. A co równie ważne: to on będzie podstawą wewnętrznej stabilności. Zespół wie, dlaczego coś robimy, a nie tylko “że musimy”.

Zakończenie: CRA jako nowe wymaganie projektowe, nie “projekt compliance”

Jeżeli miałbym zostawić jedną myśl, która spina trzy części: CRA nie jest problemem do rozwiązania na końcu. Jest ramą, która zmienia sposób myślenia o produkcie. Tak jak ISO 12100 uczy, że ryzyko powstaje w relacji człowiek–maszyna, tak CRA uczy, że cyberbezpieczeństwo powstaje w relacji produkt–środowisko–cykl życia producenta.

Normy zharmonizowane przyjdą i uproszczą pewne ścieżki. Ale ich brak nie jest powodem do bezruchu. Jest powodem, żeby skupić się na tym, co CRA ocenia zawsze: na decyzjach, dowodach i zdolności do działania w rzeczywistości — nie w prezentacji.