Cyber Resilience Act: obowiązki zgłoszeniowe od 11 września 2026

01

Fakty: co zmieniło się 11 września 2026 r.?

Cyber Resilience Act, czyli rozporządzenie (UE) 2024/2847, wszedł w życie 10 grudnia 2024 r. Komisja Europejska wskazuje, że od 11 września 2026 r. stosuje się obowiązki zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktów z elementami cyfrowymi.

Większość pozostałych obowiązków CRA zacznie być stosowana 11 grudnia 2027 r. Wymagania zgłoszeniowe nie są więc jedynie przygotowaniem do przyszłej zgodności — dla producentów objętych zakresem już obowiązują. Informacje w artykule zweryfikowano 21 września 2026 r.; materiał ma charakter informacyjny i procesowy, a nie indywidualnej porady prawnej.

02

Fakty: kogo dotyczy raportowanie CRA?

CRA dotyczy produktów z elementami cyfrowymi udostępnianych na rynku Unii, obejmujących sprzęt i oprogramowanie oraz związane z nimi rozwiązania zdalnego przetwarzania danych. Obowiązki opisane w tym artykule są skierowane przede wszystkim do producentów. Samo korzystanie z programu lub urządzenia w firmie nie czyni jeszcze użytkownika jego producentem.

Pierwszym krokiem powinno być ustalenie roli firmy wobec każdego produktu: czy rozwija go i udostępnia pod własną nazwą lub znakiem towarowym, czy działa jako importer, dystrybutor, integrator albo wyłącznie użytkownik. Zakres CRA ma wyjątki i reguły szczególne, dlatego przypadki graniczne warto sprawdzić w tekście rozporządzenia i wytycznych Komisji z 27 lipca 2026 r.

• własna aplikacja, biblioteka lub urządzenie oferowane klientom może wymagać oceny zakresu;
• produkt pod własną marką wymaga sprawdzenia roli producenta, nawet gdy część prac wykonuje dostawca;
• komponenty open source nie zwalniają automatycznie komercyjnego produktu z obowiązków;
• dla opiekunów oprogramowania open source obowiązek z art. 24 ust. 3 zacznie być stosowany 11 grudnia 2027 r.

03

Fakty: co i w jakich terminach trzeba zgłaszać?

Komisja Europejska rozróżnia aktywnie wykorzystywaną podatność oraz poważny incydent wpływający na bezpieczeństwo produktu. Nie każdy błąd lub zgłoszenie serwisowe automatycznie spełnia te przesłanki, ale decyzja o klasyfikacji powinna być szybka, udokumentowana i oparta na aktualnych definicjach CRA.

Dla obu kategorii producent przekazuje wczesne ostrzeżenie w ciągu 24 godzin od uzyskania świadomości oraz pełne zgłoszenie w ciągu 72 godzin. Dla aktywnie wykorzystywanej podatności raport końcowy składa się nie później niż 14 dni od udostępnienia środka naprawczego lub ograniczającego ryzyko. Dla poważnego incydentu termin raportu końcowego wynosi miesiąc od zgłoszenia 72-godzinnego.

• 24 godziny: wczesne ostrzeżenie po uzyskaniu świadomości zdarzenia;
• 72 godziny: pełniejsze zgłoszenie z dostępnymi informacjami i oceną;
• podatność: raport końcowy do 14 dni po udostępnieniu działania naprawczego lub ograniczającego;
• poważny incydent: raport końcowy w ciągu miesiąca od zgłoszenia 72-godzinnego.

04

Fakty: gdzie wykonuje się zgłoszenie?

ENISA uruchomiła Single Reporting Platform 11 września 2026 r. Producent składa jedno zgłoszenie za pośrednictwem platformy, kierowane do właściwego CSIRT dla państwa głównego przedsiębiorstwa; poza szczególnie wyjątkowymi okolicznościami informacje są równocześnie udostępniane ENISA.

ENISA publikuje instrukcje rejestracji, obsługi zgłoszeń, słownik pól, odpowiedzi na pytania i materiały szkoleniowe. Firma powinna korzystać z bieżącej wersji tych materiałów, ponieważ agencja zaznacza, że dokumentacja platformy może być aktualizowana wraz z jej rozwojem.

05

Rekomendacja WEBee: proces, który mieści się w 24 godzinach

Największym ryzykiem operacyjnym jest nie sam formularz, lecz czas tracony na ustalenie produktu, właściciela, skali wpływu i osoby uprawnionej do podjęcia decyzji. Proces powinien rozpoczynać się w chwili otrzymania wiarygodnego sygnału od monitoringu, badacza, klienta, dostawcy lub zespołu wsparcia.

Warto wyznaczyć właściciela raportowania, zastępcę i dostępność poza zwykłymi godzinami pracy. Zespół powinien mieć prostą matrycę klasyfikacji, zegar odnotowujący moment uzyskania świadomości, repozytorium dowodów oraz ścieżkę akceptacji, która nie wymaga zwoływania wieloosobowego komitetu przed wysłaniem wczesnego ostrzeżenia.

• rejestr produktów, wersji, właścicieli i rynków udostępnienia;
• jeden kanał przyjmowania sygnałów o podatnościach i incydentach;
• kryteria eskalacji wraz z osobą odpowiedzialną za klasyfikację;
• znacznik czasu uzyskania świadomości i automatyczne alerty przed 24 oraz 72 godzinami;
• konto i role na platformie SRP przygotowane przed zdarzeniem;
• kontrolowany dziennik decyzji, dowodów, komunikacji i działań naprawczych.

06

Rekomendacja WEBee: ćwiczenie i checklista gotowości

Przeprowadź krótkie ćwiczenie na realistycznym scenariuszu: zewnętrzny badacz zgłasza wykorzystaną podatność w produkcie używanym przez klientów w kilku krajach. Zmierz czas identyfikacji wersji, decyzji o klasyfikacji, zebrania minimum informacji i przygotowania zgłoszenia. Lista luk po takim ćwiczeniu jest bardziej użyteczna niż ogólna deklaracja zgodności.

Równolegle sprawdź umowy z dostawcami komponentów, hostingu i obsługi bezpieczeństwa. Powinny wspierać szybkie przekazanie informacji i dowodów, ale odpowiedzialności producenta nie należy opierać wyłącznie na reakcji podwykonawcy. Audyt gotowości może połączyć mapę produktów, proces obsługi podatności, role, narzędzia, integracje i plan działań do 2027 r.

• potwierdź, które produkty i role firmy podlegają analizie CRA;
• sprawdź dane kontaktowe, zastępstwa i gotowość konta SRP;
• przetestuj scenariusze podatności oraz poważnego incydentu;
• zmierz czas od sygnału do decyzji i szkicu zgłoszenia;
• uzupełnij monitoring, umowy, instrukcje i przechowywanie dowodów;
• zaplanuj dalsze obowiązki bezpieczeństwa produktu przed 11 grudnia 2027 r.