Cyber Resilience Act: od 11 września 2026 masz 24 godziny na zgłoszenie podatności — jak przygotować infrastrukturę?

O unijnych regulacjach cyberbezpieczeństwa w polskich firmach mówi się dziś głównie w kontekście NIS2 i nowelizacji ustawy o KSC. Tymczasem równolegle dojrzewa druga regulacja, która uderzy w zupełnie inną grupę podmiotów — i której pierwszy twardy termin wypada wcześniej, niż większość zespołów zakłada. Cyber Resilience Act wszedł w życie 10 grudnia 2024 roku, a jego główne obowiązki zaczną obowiązywać od 11 grudnia 2027 roku. Ale obowiązki raportowe ruszają już 11 września 2026 (źródło: digital-strategy.ec.europa.eu).

To mniej niż dwa miesiące.

Cyber Resilience Act — kogo naprawdę dotyczy

CRA nie jest kolejną wersją NIS2. Adresatem tej regulacji nie są „podmioty kluczowe i ważne", lecz producenci produktów z elementami cyfrowymi — zarówno sprzętu, jak i oprogramowania. Zakres jest szeroki: od urządzeń konsumenckich, przez aplikacje mobilne, po programy komputerowe. Zgodność potwierdza oznaczenie CE, a obowiązki rozciągają się na cały łańcuch dostaw.

W praktyce oznacza to, że regulacja obejmie firmy, które nigdy nie uważały się za „podmiot regulowany": software house’y sprzedające własny produkt, integratorów dostarczających urządzenia z firmware’em, producentów automatyki i IoT, dostawców systemów wbudowanych. Jeżeli wprowadzasz na rynek UE produkt zawierający oprogramowanie — prawdopodobnie jesteś w zakresie.

11 września 2026: co i w jakim czasie trzeba zgłosić

Artykuł 14 CRA wprowadza dwie kategorie zdarzeń podlegających zgłoszeniu: aktywnie wykorzystywane podatności oraz poważne incydenty mające wpływ na bezpieczeństwo produktu. Zgłoszenie trafia jednocześnie do CSIRT-u wyznaczonego jako koordynator oraz do ENISA — za pośrednictwem wspólnej platformy zgłoszeniowej.

Harmonogram jest trzystopniowy i liczony od momentu, w którym producent poweźmie wiadomość o zdarzeniu:

• 24 godziny — wczesne ostrzeżenie,
• 72 godziny — właściwe zgłoszenie podatności lub incydentu, wraz z opisem oraz informacją o zastosowanych lub dostępnych środkach naprawczych i ograniczających,
• raport końcowy — nie później niż 14 dni po udostępnieniu środka naprawczego (dla aktywnie wykorzystywanej podatności) albo w ciągu miesiąca od zgłoszenia (dla poważnego incydentu).

Kluczowa jest ta pierwsza doba. Zegar nie startuje w chwili, gdy zespół skończy analizę i uzgodni komunikat — startuje wtedy, gdy ktoś w organizacji dowie się o problemie. Jeśli informacja przyjdzie w piątek wieczorem, termin nie przesuwa się na poniedziałek.

Dlaczego to jest wyzwanie infrastrukturalne, a nie tylko prawne

Większość opracowań o CRA kończy się na polityce i procedurze. Problem w tym, że w 24 godziny nie da się napisać zgłoszenia, jeśli nie ma z czego. Dotrzymanie terminu z art. 14 zakłada, że kilka rzeczy jest gotowych zanim cokolwiek się wydarzy:

Telemetria i logi, do których faktycznie masz dostęp. Żeby stwierdzić, czy podatność jest aktywnie wykorzystywana — a nie tylko teoretycznie istnieje — potrzebujesz danych o ruchu i zachowaniu produktu w terenie. To wymaga świadomej polityki retencji logów i miejsca, w którym te logi bezpiecznie leżą.

Monitoring, który działa poza godzinami pracy. Doba to doba, również w święta. Warto tu sięgnąć po te same zasady, które opisywaliśmy przy monitoringu serwerów 24/7/365 — różnica polega na tym, że tym razem konsekwencją przegapionego alertu jest nie tylko przestój, ale i uchybienie regulacyjne.

Środowisko, w którym da się szybko wydać poprawkę. Obowiązek zgłoszenia idzie w parze z obowiązkiem obsługi podatności przez cały cykl życia produktu. Jeżeli pipeline budowania i podpisywania kodu stoi na przypadkowej maszynie pod biurkiem, to właśnie ta maszyna jest wąskim gardłem zgodności — i jednocześnie łakomym celem, bo kompromitacja środowiska build to kompromitacja każdego klienta.

Kopie i odtwarzalność. Raport końcowy wymaga opisania przyczyny źródłowej. Bez zachowanych migawek i kopii off-site analiza po fakcie bywa po prostu niemożliwa.

CRA to nie NIS2 — ale możesz podlegać obu naraz

To rozróżnienie warto zrobić świadomie, bo w rozmowach handlowych oba akty często się zlewają. NIS2 i ustawa o KSC regulują sposób, w jaki organizacja zarządza własnym bezpieczeństwem — kto się rejestruje, jak zgłasza incydenty, kto odpowiada w zarządzie. Opisywaliśmy to szczegółowo we wpisie o samoidentyfikacji i wpisie do wykazu KSC. CRA reguluje natomiast produkt, który wprowadzasz na rynek.

Producent oprogramowania, który jednocześnie jest średnią firmą świadczącą usługi cyfrowe, może więc znaleźć się w zakresie obu reżimów — z dwoma różnymi ścieżkami zgłoszeń i dwoma różnymi adresatami. Podobna logika „regulacja plus wymagania wobec dostawcy" pojawia się także w sektorze finansowym, o czym pisaliśmy przy okazji DORA i dostawców ICT.

Czego wymagać od centrum danych, które ma to udźwignąć

Żaden operator data center nie „załatwi" za Ciebie zgodności z CRA — odpowiedzialność za produkt zostaje po stronie producenta. Ale infrastruktura albo pomaga dotrzymać terminów, albo je sabotuje. O co pytać:

• Certyfikacje, które faktycznie coś znaczą dla audytora. Sprint Data Center dysponuje m.in. ISO 27001, ISO 22301 i ISO 9001, a także NATO AQAP 2210, Wewnętrznym Systemem Kontroli oraz Świadectwem Bezpieczeństwa Przemysłowego Pierwszego Stopnia wydanym przez ABW.
• Kontrola dostępu z pełną rejestracją. Monitoring wizyjny 24h z pełnym zapisem zdarzeń oraz dostęp do serwerowni wyłącznie w asyście personelu technicznego to dokumentacja, którą pokażesz przy analizie incydentu.
• Zasilanie i chłodzenie bez pojedynczego punktu awarii. Własna stacja transformatorowa, zasilanie dwutorowe, UPS-y oraz przemysłowy agregat prądotwórczy przystosowany do pracy ciągłej; klimatyzacja precyzyjna utrzymująca 23°C ±2°C i wilgotność 50 rH% ±10%.
• Dostęp serwisowy w trybie 24/7/365 i remote hands. Jeśli o drugiej w nocy trzeba fizycznie odłączyć albo przepiąć maszynę, to nie jest moment na szukanie kluczy.
• Dane w Polsce. Przy zgłoszeniach do krajowego CSIRT-u lokalizacja infrastruktury i jurysdykcja przestają być kwestią wyłącznie techniczną.

Te wymagania spełnia zarówno kolokacja własnych maszyn, jak i serwery dedykowane — wybór zależy od tego, czy chcesz zachować kontrolę nad własnym sprzętem, czy wolisz gotową platformę.

Podsumowanie

Do 11 września 2026 zostało mniej niż dwa miesiące. Jeżeli wprowadzasz na rynek produkt z elementami cyfrowymi, to jest ostatni moment, żeby odpowiedzieć sobie na trzy pytania: kto u nas odbiera zgłoszenie o podatności poza godzinami pracy, gdzie leżą logi potrzebne do oceny, czy podatność jest aktywnie wykorzystywana, i czy środowisko, w którym wydajemy poprawkę, jest wystarczająco chronione.

Jeśli odpowiedź na którekolwiek z nich brzmi „musielibyśmy sprawdzić" — porozmawiajmy o infrastrukturze, zanim ruszy zegar. Sprawdź ofertę kolokacji serwerów w Sprint Data Center albo skontaktuj się z nami i opisz swój przypadek.

FAQ – najczęściej zadawane pytania o Cyber Resilience Act

Czy Cyber Resilience Act dotyczy mnie, jeśli sprzedaję tylko oprogramowanie, bez sprzętu?

Tak. CRA obejmuje produkty z elementami cyfrowymi, a więc zarówno sprzęt, jak i samo oprogramowanie — w tym aplikacje mobilne i programy komputerowe. Kryterium jest wprowadzanie produktu na rynek Unii Europejskiej, a nie jego forma fizyczna.

Czym CRA różni się od NIS2 i ustawy o KSC?

NIS2 reguluje sposób, w jaki organizacja zarządza własnym cyberbezpieczeństwem, i dotyczy podmiotów kluczowych oraz ważnych. CRA reguluje bezpieczeństwo produktu wprowadzanego na rynek i dotyczy jego producenta. Jedna firma może podlegać obu reżimom jednocześnie, z osobnymi ścieżkami zgłoszeń.

Od kiedy dokładnie obowiązują poszczególne przepisy CRA?

Rozporządzenie weszło w życie 10 grudnia 2024 roku. Obowiązki raportowe — zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów — zaczynają obowiązywać 11 września 2026 roku. Główne obowiązki producentów będą stosowane od 11 grudnia 2027 roku.

Czy kolokacja serwerów pomaga spełnić wymagania CRA?

Kolokacja nie zapewnia zgodności sama w sobie — odpowiedzialność za produkt pozostaje po stronie producenta. Ułatwia jednak dotrzymanie terminów: daje kontrolowane środowisko dla logów i pipeline’ów, całodobowy dostęp serwisowy oraz udokumentowaną kontrolę dostępu fizycznego, którą można przedstawić przy analizie incydentu.