CRA od 11 września: producent będzie miał 24 godziny na pierwsze zgłoszenie

Za dwadzieścia dni w unijnych przepisach o cyberbezpieczeństwie pojawi się nowy zegar. Od 11 września 2026 producent objętego produktu z elementami cyfrowymi będzie musiał wysłać pierwsze ostrzeżenie o aktywnie wykorzystywanej podatności lub poważnym incydencie bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin od powzięcia wiedzy.

To nie jest wcześniejszy start wszystkich wymagań aktu o cyberodporności, znanego jako CRA. Większość głównych obowiązków zacznie być stosowana 11 grudnia 2027. Wcześniej, 11 września 2026, zaczyna działać szczególny mechanizm zgłoszeń z art. 14. Dla polskiej firmy praktyczny problem polega więc nie na przygotowaniu jednego formularza, lecz na połączeniu monitoringu produktu, decyzji prawnej i technicznej oraz szybkiego przekazania potwierdzonych informacji.

Stan na 22 sierpnia jest przejściowy. Komisja Europejska informuje, że testy funkcjonalne i bezpieczeństwa platformy nadal trwają, a ENISA zapowiada opublikowanie jej dokładnego adresu przed uruchomieniem. Można jednak przygotować role, dane i przebieg decyzji bez czekania na sam link.

Co dokładnie trzeba będzie zgłaszać

Rozporządzenie (UE) 2024/2847 obejmuje produkty z elementami cyfrowymi, czyli szeroką grupę sprzętu, oprogramowania i powiązanych rozwiązań. Nie oznacza to jednak, że każdy błąd programu automatycznie trafia do obowiązkowego raportu. Zakres produktu i rola firmy wymagają osobnej oceny, zwłaszcza przy komponentach, usługach zdalnych, oprogramowaniu open source i sektorach objętych innymi regulacjami.

Pierwszą kategorią jest aktywnie wykorzystywana podatność. FAQ ENISA o platformie SRP opisuje ją jako lukę, wobec której istnieją wiarygodne dowody, że złośliwy podmiot wykorzystał ją w systemie bez zgody właściciela. Sama wysoka ocena techniczna albo możliwość stworzenia kodu wykorzystującego lukę nie zastępuje tej przesłanki.

Drugą kategorią jest poważny incydent wpływający na bezpieczeństwo produktu. W aktualnym opisie ENISA chodzi o zdarzenie, które poważnie narusza lub może naruszyć ochronę dostępności, autentyczności, integralności albo poufności ważnych danych lub funkcji, bądź prowadzi lub może prowadzić do umieszczenia albo wykonania złośliwego kodu. Granica wymaga oceny faktów, a nie samej etykiety „incydent”.

CERT Polska podkreśla, że źródłem wiedzy mogą być własne systemy producenta, użytkownik, klient albo niezależny badacz. Dlatego procedura nie może zaczynać się dopiero w dziale prawnym. Kanał przyjmowania zgłoszeń i zespół monitorujący produkt muszą wiedzieć, komu przekazać sygnał i jak zachować godzinę jego otrzymania.

Dwa krótkie terminy i raport końcowy

Komisja Europejska opisuje trzy etapy. Pierwsze ostrzeżenie ma trafić bez zbędnej zwłoki, nie później niż w ciągu 24 godzin od powzięcia wiedzy. Pełniejsze zgłoszenie trzeba przekazać w ciągu 72 godzin. Proces kończy raport: dla aktywnie wykorzystywanej podatności najpóźniej 14 dni po udostępnieniu środka naprawczego, a dla poważnego incydentu w ciągu miesiąca.

Zegar nie czeka na gotową poprawkę ani pełną analizę przyczyn. W praktyce oznacza to potrzebę zapisania momentu, w którym właściwa część organizacji uzyskała informację wystarczającą do rozpoznania zdarzenia. Firma powinna ustalić, kto dokonuje tej oceny, kto może ją zatwierdzić poza godzinami pracy i gdzie zapisywane są przesłanki decyzji.

Pierwszy etap ma być krótki, ale nie może być anonimowym alarmem bez produktu. Aktualna tabela ENISA wskazuje między innymi typ powiadomienia, nazwę producenta, produkt i tytuł sprawy. W etapie 72-godzinnym dochodzą ogólna natura podatności lub incydentu, wstępna ocena, podjęte działania oraz środki, które może zastosować użytkownik. Raport końcowy wymaga pełniejszego opisu wpływu i naprawy.

Najbezpieczniejszy szablon roboczy nie powinien udawać oficjalnego formularza. Wystarczy wewnętrzna lista pól z miejscem na źródło dowodu, czas wykrycia, identyfikację produktu i wersji, państwa udostępniania, charakter zdarzenia, działania ograniczające ryzyko oraz informację dla użytkownika. Zespół powinien też oznaczać dane wrażliwe i przekazywać je wyłącznie oficjalnym kanałem.

Platforma SRP nie jest jeszcze formularzem do wypełnienia na zapas

Zgłoszenie będzie wysyłane raz przez Single Reporting Platform zarządzaną przez ENISA. System skieruje je do CSIRT wyznaczonego jako koordynator dla państwa głównego miejsca prowadzenia działalności producenta oraz, z wyjątkami dotyczącymi szczególnie wrażliwych przypadków, równocześnie do ENISA. Pierwszy CSIRT ma następnie przekazać informację właściwym zespołom w państwach, w których produkt jest dostępny.

W polskim kontekście CERT Polska informuje, że CSIRT NASK obsługuje zgłoszenia CRA producentów związanych z Polską zgodnie z regułami wyboru państwa. Nie warto jednak kodować tego wyboru na stałe w prywatnej instrukcji bez ponownego sprawdzenia. ENISA zapowiada, że platforma pokaże listę koordynatorów, a właściwość zależy przede wszystkim od miejsca głównej siedziby lub, w określonych przypadkach, przedstawiciela.

Instrukcja rejestracji ENISA rozróżnia głównego i zapasowego przedstawiciela producenta. Logowanie będzie oparte na EU Login, które można utworzyć wcześniej. Jednocześnie ENISA wyraźnie zaleca, by nie zakładać konta SRP i nie rozpoczynać walidacji zapobiegawczo. Rejestracja ma nastąpić, gdy pojawi się konkretne zgłoszenie, a walidacja powiązania przedstawiciela z producentem będzie prowadzona równolegle i nie ma blokować wysłania powiadomienia.

To pozorny paradoks: firma powinna przygotować ludzi, ale nie klikać przedwcześnie w nieuruchomiony proces. Już teraz można utworzyć i sprawdzić EU Login, wyznaczyć główną osobę oraz zastępcę, potwierdzić pełną nazwę prawną i adres producenta, a także przygotować regułę bezpiecznego przekazania dostępu w razie urlopu lub nocnego incydentu.

Pięć sprawdzeń na najbliższe dwadzieścia dni

1. Czy firma jest producentem objętego produktu? Zrób mapę sprzętu, oprogramowania i samodzielnie sprzedawanych komponentów. Przy każdym wpisie zapisz podmiot prawny, sposób udostępniania na rynku UE i osobę odpowiedzialną za bezpieczeństwo. Wyjątków nie rozstrzygaj na podstawie nazwy marketingowej produktu.

2. Kiedy organizacja uznaje, że powzięła wiedzę? Połącz skrzynkę dla badaczy, wsparcie klienta, telemetrię i zespół reagowania jednym sposobem eskalacji. Zapisywany czas powinien być odtwarzalny, a decyzja o zakwalifikowaniu albo odrzuceniu zdarzenia mieć krótkie uzasadnienie.

3. Kto uruchamia raport i kto go zastępuje? Wskaż osobę główną, zapasową oraz decydenta technicznego i prawnego. Dwudziestoczterogodzinny termin może obejmować noc, weekend lub święto, więc procedura działająca wyłącznie w godzinach biurowych jest niewystarczająca.

4. Czy dane da się zebrać bez polowania po arkuszach? Przećwicz na fikcyjnym zdarzeniu zebranie identyfikacji produktu, wersji, rynku, dowodu aktywnego wykorzystania, wpływu, działań ograniczających ryzyko i instrukcji dla użytkownika. Ćwiczenie nie powinno być wysyłane do prawdziwej platformy ani zostawiać testowego zgłoszenia.

5. Gdzie zespół sprawdza aktualny stan? Zachowaj oficjalne adresy Komisji, ENISA i CERT Polska jako punkty wejścia, nie jako niezmienny zrzut instrukcji. ENISA zaznacza, że materiały odzwierciedlają aktualną wiedzę i mogą się zmienić. Przy realnym zdarzeniu trzeba ponownie otworzyć wskazówki oraz adres SRP.

Co z tego wynika dla użytkownika produktu

Obowiązek raportowania spoczywa na producencie, nie na osobie korzystającej z urządzenia lub aplikacji. Użytkownik nadal może być pierwszym źródłem sygnału. Podejrzane zachowanie warto zgłosić kanałem bezpieczeństwa producenta, podając wersję produktu i możliwie bezpieczny opis, ale bez publikowania działającego sposobu ataku lub cudzych danych.

Samo zgłoszenie do SRP nie oznacza automatycznie, że produkt jest niebezpieczny, że powstanie publiczny komunikat albo że organ stwierdził naruszenie prawa. Mechanizm ma przyspieszyć przepływ informacji o określonych zdarzeniach. Dla firmy najważniejszy test brzmi więc: czy potrafi w ciągu jednej doby przejść od wiarygodnego sygnału do rzetelnego, ograniczonego i odtwarzalnego ostrzeżenia.