CRA od 11 września: zegar, który uruchamia ktoś spoza Państwa organizacji

11 września 2026 r. zaczyna być stosowany art. 14 rozporządzenia (UE) 2024/2847, czyli Cyber Resilience Act. To nie jest wejście w życie całego CRA. Wymagania projektowe, dokumentacja techniczna, ocena zgodności i oznakowanie CE zaczną obowiązywać dopiero 11 grudnia 2027 r. Od września działa jeden przepis: obowiązek zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu.

Ten jeden przepis ma jednak cechę, której nie ma żaden inny obowiązek zgłoszeniowy funkcjonujący dziś na polskim rynku.

Zegar startuje na informacji, której Państwo nie wygenerują

W KSC i w DORA zdarzenie podlegające zgłoszeniu dzieje się w Państwa infrastrukturze. Wykrywa je Państwa monitoring, a jakość reakcji zależy przede wszystkim od dojrzałości własnego zespołu bezpieczeństwa.

Art. 14 CRA działa odwrotnie. Obowiązek uruchamia się w chwili, w której producent poweźmie wiadomość, że podatność w produkcie wprowadzonym przez niego do obrotu jest aktywnie wykorzystywana — najczęściej w środowisku klienta, nie u producenta. Tego zdarzenia Państwa SOC nie zobaczy. Sygnał przyjdzie z zewnątrz: e-mailem od badacza, zgłoszeniem klienta, biuletynem dostawcy komponentu, publikacją zespołu CERT. CERT Polska wskazuje to wprost — źródłem informacji o podatności mogą być zarówno własne obserwacje producenta, jak i zgłoszenia użytkowników, klientów czy niezależnych badaczy.

Od tej chwili biegną 24 godziny. Wąskim gardłem nie jest więc zdolność wykrywania, lecz obsługa informacji przychodzącej z zewnątrz. Warto sprawdzić to jednym pytaniem: ile czasu zajmuje wiadomość, która w piątek po południu trafia na ogólny adres kontaktowy, zanim dotrze do osoby zdolnej ocenić, czy jest to zdarzenie podlegające zgłoszeniu? Jeżeli odpowiedź brzmi „w poniedziałek”, termin jest już przekroczony.

Producentem można być bez żadnego statusu pod KSC

CRA nie przypisuje obowiązków sektorowi ani wielkości podmiotu, lecz roli pełnionej wobec konkretnego produktu. Producentem jest ten, kto wprowadza produkt z elementami cyfrowymi do obrotu w UE pod własną nazwą lub znakiem towarowym — również wtedy, gdy kod pisze zewnętrzny software house, a sprzęt powstaje w fabryce w Azji. Kwalifikację przeprowadza się osobno dla każdego produktu i niezależnie od tego, czy firma jest podmiotem kluczowym albo ważnym w rozumieniu ustawy o KSC. Poza zakresem pozostaje natomiast oprogramowanie świadczone wyłącznie jako usługa, choć rozwiązanie zdalnego przetwarzania danych, bez którego produkt nie wykonałby swojej funkcji, do zakresu CRA już wchodzi.

Obowiązek obejmuje też portfel historyczny. Art. 69 ust. 2 CRA zwalnia produkty wprowadzone do obrotu przed 11 grudnia 2027 r. z wymagań rozporządzenia, o ile nie zostaną istotnie zmodyfikowane — ale ust. 3 wprowadza od tej zasady wyjątek właśnie dla art. 14. Sterownik sprzedany w 2022 r., który nigdy nie będzie wymagał oznakowania CE, jest objęty obowiązkiem zgłoszeniowym. Nie ma natomiast obowiązku wstecznego: eksploatacja, o której producent wiedział przed 11 września 2026 r., zgłoszeniu nie podlega.

Terminy i jeden kanał

Wczesne ostrzeżenie — 24 godziny od powzięcia wiadomości. Zgłoszenie właściwe — 72 godziny. Raport końcowy — 14 dni od udostępnienia środka naprawczego lub ograniczającego ryzyko w przypadku podatności, albo miesiąc od zgłoszenia 72-godzinnego w przypadku poważnego incydentu.

Zgłoszenie składa się raz, przez pojedynczą platformę sprawozdawczą (SRP) prowadzoną przez ENISA na podstawie art. 16 CRA, a trafia ono równocześnie do ENISA i do CSIRT-u wyznaczonego jako koordynator. Producenci, którzy przy rejestracji wskażą Polskę, będą obsługiwani przez CSIRT NASK; zadania te realizuje CERT Polska.

Jeden element warto uwzględnić w planowaniu. Platforma ma być operacyjna 11 września, czyli tego samego dnia, w którym zaczyna biec obowiązek. Rejestracja producenta wymaga konta EU Login, a w niektórych przypadkach dodatkowej weryfikacji. Pierwsze zgłoszenie składane pod presją doby nie powinno być jednocześnie pierwszym logowaniem.

To nie jest przepis drugiej kategorii

Art. 64 ust. 2 CRA umieszcza naruszenie obowiązków z art. 13 i 14 w tym samym, najwyższym progu sankcyjnym co niespełnienie zasadniczych wymagań z załącznika I: do 15 mln euro albo 2,5% światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa. Obowiązek, który zaczyna obowiązywać jako pierwszy, jest więc zagrożony tak samo jak wymagania projektowe wchodzące w życie jako ostatnie. Jest przy tym najłatwiejszy do wykazania — przekroczony termin to data, a nie kwestia oceny inżynierskiej.

Wyłączenie dla mniejszych firm bywa opisywane zbyt szeroko. Art. 64 ust. 10 wyłącza administracyjne kary pieniężne wobec mikro- i małych producentów wyłącznie w zakresie niedotrzymania terminu wczesnego ostrzeżenia. Sam obowiązek zgłoszenia oraz pozostałe terminy pozostają w mocy. Odrębne wyłączenie z kar dotyczy opiekunów oprogramowania open source.

Co warto zrobić w tym tygodniu

• Rozstrzygnąć, osobno dla każdego produktu, czy są Państwo producentem w rozumieniu CRA. Kryterium jest rzeczywista kontrola nad rozwojem, marką i wydaniami, a nie kod PKD.
• Zebrać rejestr produktów i wersji obecnych na rynku UE wraz z listą użytych komponentów. Art. 14 sam w sobie nie wymaga ani SBOM, ani polityki skoordynowanego ujawniania podatności — te obowiązki są w art. 13 i załączniku I i zaczną obowiązywać w grudniu 2027 r. Bez mapy zależności termin 24-godzinny jest jednak niewykonalny.
• Wskazać jeden monitorowany kanał wejściowy i ścieżkę eskalacji z dyżurem. Skrzynka sprawdzana raz w tygodniu nie utrzyma doby.
• Założyć konto EU Login dla osoby, która będzie składać zgłoszenie w imieniu producenta.
• Przygotować jedną kartę kwalifikacji zdarzenia obejmującą równolegle CRA, KSC, DORA i RODO. Jedno zdarzenie techniczne może uruchomić kilka reżimów naraz, a każdy z nich ma własne kryterium, własny zegar i własnego adresata.

11 września nie zmienia sposobu, w jaki budują Państwo produkty. Zmienia to, ile czasu mają Państwo na reakcję na wiadomość, której nikt się nie spodziewał.

Jeżeli chcą Państwo mieć pewność co do własnego portfela, proponujemy krótki przegląd: listę produktów objętych art. 14, ocenę ścieżki od sygnału zewnętrznego do decyzji o zgłoszeniu oraz gotową kartę kwalifikacji zdarzenia dla czterech reżimów. Zapraszamy do kontaktu.

Grzegorz Bielecki

vCISO, vCIO i certyfikowany ekspert ds. bezpieczeństwa (CISM, CDPSE, CEH, ISO 27001 Lead Auditor). Od ponad 15 lat wspiera głównie sektor finansowy w budowaniu odporności cyfrowej. Architekt wdrożeń DORA, NIS2\UKSC oraz norm ISO 27001 (SZBI) i ISO 22301 (SZCD). Posiada doświadczenie w projektach zgodności IT przy pozyskiwaniu licencji KIP KNF. Członek ISSA Polska.