11 września 2026: pierwszy obowiązek CRA, który może dotknąć producentów

Cyber Resilience Act zacznie w pełni obowiązywać w grudniu 2027 roku. Producenci nie mogą jednak czekać z przygotowaniami do tej daty. Już 11 września 2026 roku uruchomiony zostanie obowiązek zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów dotyczących produktów z elementami cyfrowymi. Pierwsza informacja może być wymagana w ciągu 24 godzin.

Pierwszym krokiem powinno być ustalenie, czy dany produkt znajduje się w zakresie CRA. Można to sprawdzić w naszym bezpłatnym teście:

Sprawdź produkt w CRA Readiness Check

Test pomaga wstępnie ocenić zakres regulacji i wskazuje obszary wymagające dalszej analizy.

CRA zaczyna się wcześniej, niż wielu producentów zakłada

Większość wymagań Cyber Resilience Act zacznie być stosowana 11 grudnia 2027 roku. Obowiązki sprawozdawcze z art. 14 CRA wchodzą jednak w życie piętnaście miesięcy wcześniej, 11 września 2026 roku. Komisja Europejska wskazuje, że od tej daty producenci będą zobowiązani zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktów z elementami cyfrowymi.

Dla biznesu oznacza to bardzo konkretną zmianę. Firma musi posiadać działający proces, który pozwala:

1. odebrać informację o problemie,

2. ustalić, którego produktu i wersji dotyczy,

3. ocenić, czy zdarzenie podlega obowiązkowemu zgłoszeniu,

4. rozpocząć obsługę incydentu,

5. przekazać pierwszą informację w wymaganym terminie,

6. powiadomić użytkowników,

7. udokumentować podjęte decyzje.

Polityka zapisana w dokumencie nie wystarczy. Proces musi działać także w weekend, podczas urlopu osoby odpowiedzialnej za produkt i w sytuacji, w której pierwsza informacja trafia do zwykłego działu wsparcia.

Ten obowiązek może objąć także starsze produkty

Szczególnie istotny jest przepis przejściowy. Obowiązek raportowania z art. 14 obejmuje produkty znajdujące się w zakresie CRA, które zostały wprowadzone na rynek przed rozpoczęciem pełnego stosowania rozporządzenia.

Producent może więc otrzymać zgłoszenie dotyczące produktu wprowadzonego na rynek kilka lat wcześniej. Brak aktywnego rozwoju produktu nie usuwa automatycznie obowiązku raportowania. Proces powinien uwzględniać starsze wersje oprogramowania, urządzenia pozostające u klientów oraz komponenty, które nadal funkcjonują w produktach dostępnych na rynku.

To zmienia sposób planowania przygotowań. Analiza ograniczona do produktów rozwijanych obecnie może pozostawić dużą część ryzyka poza procesem.

Kogo CRA nazywa producentem?

Producentem w rozumieniu CRA może być firma, która:

• samodzielnie rozwija produkt,

• zleca jego zaprojektowanie lub wytworzenie,

• sprzedaje produkt pod własną nazwą lub marką,

• udostępnia go za opłatą, w modelu monetyzowanym albo bezpłatnie.

Nie musi to być fabryka urządzeń. Producentem może być software house rozwijający własny produkt, dostawca aplikacji, producent urządzenia IoT, firma oferująca oprogramowanie desktopowe, dostawca firmware’u lub podmiot sprzedający rozwiązanie stworzone przez zewnętrzny zespół pod własną marką.

Zakres CRA wymaga oceny konkretnego produktu i sposobu jego udostępniania na rynku. Sama informacja, że firma działa w branży IT, nie daje jeszcze jednoznacznej odpowiedzi.

Co trzeba zgłaszać od 11 września 2026 roku?

Artykuł 14 CRA przewiduje dwa główne rodzaje obowiązkowych zgłoszeń.

Aktywnie wykorzystywana podatność

Chodzi o podatność, dla której istnieją wiarygodne dowody, że została wykorzystana przez atakującego w systemie bez zgody jego właściciela.

Samo znalezienie błędu bezpieczeństwa nie uruchamia automatycznie obowiązku raportowania w ramach art. 14. Zespół nadal powinien obsłużyć podatność, ocenić jej ryzyko i przygotować poprawkę. Obowiązek zgłoszenia powstaje przy wiarygodnych przesłankach wskazujących na faktyczne wykorzystanie podatności przez złośliwego aktora.

Źródłem informacji może być:

• telemetria produktu,

• analiza logów,

• informacja od klienta,

• zgłoszenie badacza bezpieczeństwa,

• komunikat producenta komponentu,

• informacja przekazana przez CERT,

• wykrycie złośliwego ruchu lub kodu,

• analiza powłamaniowa.

Firma potrzebuje jasnych zasad oceny, które dowody uznaje za wystarczające do potwierdzenia aktywnego wykorzystania.

Poważny incydent wpływający na bezpieczeństwo produktu

Incydent uznaje się za poważny między innymi wtedy, gdy wpływa lub może wpłynąć na zdolność produktu do ochrony dostępności, autentyczności, integralności albo poufności ważnych danych lub funkcji.

Drugim kryterium jest możliwość wprowadzenia lub wykonania złośliwego kodu w produkcie albo w systemach użytkownika.

Przykładem może być:

• przejęcie mechanizmu aktualizacji produktu,

• dystrybucja złośliwej wersji oprogramowania,

• naruszenie podpisywania kodu,

• uzyskanie nieautoryzowanego dostępu do funkcji administracyjnych,

• kompromitacja komponentu używanego w wielu instalacjach,

• podatność pozwalająca wykonać kod w środowisku klienta,

• naruszenie integralności danych przetwarzanych przez produkt.

Każdy incydent wymaga oceny w konkretnym kontekście produktu, jego funkcji i wpływu na użytkowników.

Najważniejszy termin: 24 godziny

Proces raportowania został podzielony na kilka etapów. Czas liczony jest od momentu, w którym producent uzyska wiedzę o aktywnym wykorzystaniu podatności albo o poważnym incydencie.

Wczesne ostrzeżenie nie musi zawierać kompletnej analizy technicznej. Pełna analiza często nie będzie jeszcze dostępna. Producent powinien jednak umieć zidentyfikować zdarzenie, produkt, charakter problemu oraz kraje, w których produkt został udostępniony.

Zgłoszenie przekazywane w ciągu 72 godzin powinno już zawierać ogólne informacje o produkcie, charakterze podatności lub incydentu, wstępnej ocenie oraz podjętych działaniach. Należy również wskazać działania, które mogą wykonać użytkownicy.

Gdzie będzie składane zgłoszenie?

Zgłoszenia mają być przekazywane przez Single Reporting Platform, czyli pojedynczą platformę sprawozdawczą zarządzaną przez ENISA.

Producent składa jedno zgłoszenie. Platforma kieruje je do CSIRT wyznaczonego jako koordynator dla państwa głównej siedziby producenta oraz udostępnia je ENISA. Następnie informacja może zostać przekazana do CSIRT-ów w państwach, w których produkt jest dostępny.

ENISA wskazuje, że platforma ma być operacyjna 11 września 2026 roku. Dostęp będzie wymagał konta EU Login. Publiczny adres platformy ma zostać opublikowany przed jej uruchomieniem. Na początkowym etapie nie jest planowane udostępnienie API do automatycznego składania zgłoszeń.

Organizacja nie powinna uzależniać całego procesu od technicznego uruchomienia SRP. Przed tą datą można przygotować osoby odpowiedzialne, formularze, wymagane dane, ścieżkę zatwierdzania i procedurę komunikacji.

Jak zbudować proces raportowania podatności i incydentów?

1. Ustal, które produkty obejmuje proces

Punktem wyjścia jest rejestr produktów. Dla każdego produktu należy określić:

• właściciela biznesowego,

• właściciela technicznego,

• aktywne i starsze wersje,

• kraje dystrybucji,

• grupy użytkowników,

• model aktualizacji,

• okres wsparcia,

• kluczowe komponenty zewnętrzne,

• miejsce przechowywania dokumentacji technicznej.

Rejestr powinien obejmować produkty sprzedawane obecnie oraz wcześniejsze produkty pozostające u użytkowników.

Przydatnym elementem jest aktualny SBOM, czyli wykaz komponentów oprogramowania. Pozwala sprawdzić, czy ujawniona podatność biblioteki lub zależności dotyczy konkretnego produktu i wersji. CERT Polska rekomenduje utrzymywanie aktualnego SBOM, monitorowanie podatności komponentów oraz łączenie dokumentacji z codziennym procesem wytwórczym.

2. Uruchom jednoznaczny kanał przyjmowania zgłoszeń

Badacz bezpieczeństwa nie powinien szukać właściwej osoby przez formularz sprzedażowy albo profil pracownika na LinkedIn.

Producent powinien posiadać publiczny kanał zgłoszeń, na przykład:

• dedykowany adres e-mail,

• formularz bezpieczeństwa,

• plik security.txt,

• instrukcję zgłaszania podatności,

• procedurę eskalacji dla działu wsparcia.

Plik security.txt pozwala wskazać adres kontaktowy, zasady ujawniania podatności, klucz szyfrujący i preferowany język komunikacji. CERT Polska rekomenduje jego publikację zgodnie z RFC 9116.

Wewnętrzny proces powinien obejmować także zgłoszenia pochodzące z działu sprzedaży, obsługi klienta, serwisu, monitoringu i od partnerów technologicznych.

3. Rejestruj moment uzyskania informacji

Termin 24 godzin wymaga ustalenia początku liczenia czasu.

Każde zgłoszenie powinno otrzymać:

• numer sprawy,

• datę i godzinę wpływu,

• źródło informacji,

• nazwę produktu i wersję,

• opis dostępnych dowodów,

• osobę prowadzącą,

• status klasyfikacji,

• historię podjętych decyzji.

Moment otrzymania wiadomości przez pracownika nie zawsze oznacza automatycznie potwierdzenie aktywnego wykorzystania podatności. Organizacja musi jednak umieć wykazać, kiedy informacja została odebrana, kiedy została przeanalizowana i na jakiej podstawie podjęto decyzję o zgłoszeniu.

Brak takiej osi czasu utrudnia późniejsze wykazanie terminowej reakcji.

4. Przygotuj kryteria klasyfikacji

Zespół analizujący zdarzenie powinien odpowiedzieć na cztery pytania:

1. Czy problem dotyczy produktu znajdującego się w zakresie CRA?

2. Czy mamy do czynienia z podatnością albo incydentem wpływającym na bezpieczeństwo produktu?

3. Czy istnieją wiarygodne dowody aktywnego wykorzystania podatności?

4. Czy incydent spełnia kryteria poważnego incydentu?

Ocena powinna być udokumentowana. Wątpliwości nie mogą zatrzymywać procesu na poziomie pojedynczego programisty albo pracownika wsparcia.

5. Wyznacz właściciela procesu i zastępstwo

W mniejszej organizacji funkcję koordynatora CRA może pełnić osoba odpowiedzialna za bezpieczeństwo, CTO albo wyznaczony product owner wspierany przez eksperta technicznego.

W większej firmie proces zwykle angażuje:

Proces musi działać podczas nieobecności głównego koordynatora. Wymagane jest formalne zastępstwo i aktualna lista kontaktów.

6. Przygotuj szablony przed pierwszym incydentem

Zespół nie powinien tworzyć formularza zgłoszeniowego w trakcie incydentu.

Warto wcześniej przygotować trzy szablony:

Wczesne ostrzeżenie, 24 godziny

Powinno umożliwiać szybkie zebranie nazwy producenta, produktu, rodzaju zdarzenia, czasu wykrycia, dostępnych dowodów oraz państw, w których produkt jest udostępniany.

Zgłoszenie rozszerzone, 72 godziny

Powinno obejmować opis podatności lub incydentu, wstępną ocenę wpływu, podjęte działania, dostępne zabezpieczenia tymczasowe oraz instrukcje dla użytkowników.

Raport końcowy

Powinien dokumentować przyczynę, poziom ryzyka, wpływ, przebieg zdarzenia, poprawkę, proces testowania i dalsze środki ochronne.

ENISA opublikowała zestaw pól planowanych w SRP. Obejmuje on między innymi produkt, państwa dystrybucji, CVE lub EUVD, charakter podatności, zastosowane zabezpieczenia, wpływ incydentu i środki dostępne dla użytkowników.

7. Połącz raportowanie z procesem naprawczym

Zgłoszenie do SRP nie zamyka sprawy. Producent musi równolegle:

• ograniczyć skutki zdarzenia,

• zabezpieczyć materiał dowodowy,

• ustalić podatne wersje,

• przygotować rozwiązanie tymczasowe,

• opracować poprawkę,

• przetestować aktualizację,

• ustalić sposób jej dystrybucji,

• monitorować dalsze wykorzystanie podatności.

W procesie powinien znaleźć się również etap retestu. Poprawka wymagająca pilnego wdrożenia może wprowadzić nowy błąd, naruszyć kompatybilność albo pozostawić inną drogę wykorzystania podatności.

8. Przygotuj komunikację z użytkownikami

CRA wymaga poinformowania użytkowników dotkniętych aktywnie wykorzystywaną podatnością lub poważnym incydentem. Komunikat powinien opisywać problem oraz działania, które użytkownik może podjąć w celu ograniczenia ryzyka.

Firma potrzebuje odpowiedzi na pytania:

• Gdzie znajdują się dane kontaktowe użytkowników?

• Którzy użytkownicy korzystają z podatnej wersji?

• Czy produkt pozwala wyświetlić komunikat bezpieczeństwa?

• Kto zatwierdza treść?

• Jak przekazywane będą aktualizacje instrukcji?

• Jak firma potwierdzi dostarczenie informacji?

Komunikat techniczny dla administratora może różnić się od wiadomości kierowanej do użytkownika biznesowego. Obie grupy powinny otrzymać instrukcję możliwą do wykonania.

9. Dokumentuj decyzje i dowody

Dokumentacja powinna obejmować:

• pierwotne zgłoszenie,

• logi i dowody techniczne,

• ocenę aktywnego wykorzystania,

• decyzję dotyczącą obowiązku zgłoszenia,

• daty przekazania raportów,

• historię zmian w zgłoszeniu,

• treść komunikacji z użytkownikami,

• kod i wersję poprawki,

• wynik testów bezpieczeństwa,

• decyzje o akceptacji ryzyka,

• działania po zakończeniu incydentu.

CERT Polska podkreśla, że cały proces obsługi podatności, wraz z terminami reakcji i podjętymi działaniami, powinien być dokumentowany. Takie podejście wspiera zarządzanie ryzykiem i pozwala wykazać należytą staranność.

Minimalny proces dla mniejszego producenta

Mała firma nie potrzebuje rozbudowanego centrum operacji bezpieczeństwa, aby rozpocząć przygotowania. Potrzebuje jednak jasno przydzielonej odpowiedzialności.

Minimalny model powinien zawierać:

1. listę produktów objętych analizą,

2. osobę odpowiedzialną i zastępcę,

3. skrzynkę do zgłoszeń bezpieczeństwa,

4. instrukcję eskalacji dla supportu,

5. rejestr podatności i incydentów,

6. kryteria aktywnego wykorzystania oraz poważnego incydentu,

7. szablony raportów 24-godzinnego i 72-godzinnego,

8. procedurę komunikacji z użytkownikami,

9. listę kontaktów awaryjnych,

10. ćwiczenie scenariusza przed 11 września.

Najważniejsze jest ograniczenie czasu traconego na ustalanie, kto ma podjąć decyzję.

Jak przetestować proces przed 11 września?

Dobrym rozwiązaniem jest krótkie ćwiczenie symulacyjne.

Przykładowy scenariusz:

W piątek o 16:20 dział wsparcia otrzymuje wiadomość od klienta. Klient przesyła logi wskazujące, że osoba trzecia wykorzystała błąd w module aktualizacji. Podatność może pozwalać na uruchomienie kodu. Z produktu korzystają klienci w sześciu państwach UE. Główny programista jest na urlopie.

Zespół powinien przejść cały proces:

• odbiór zgłoszenia,

• eskalacja,

• identyfikacja produktu i wersji,

• zabezpieczenie logów,

• ocena dowodów,

• uruchomienie zegara raportowego,

• przygotowanie wczesnego ostrzeżenia,

• ustalenie komunikacji z klientami,

• rozpoczęcie pracy nad zabezpieczeniem tymczasowym.

Po ćwiczeniu warto sprawdzić, ile czasu zajęło dotarcie do właściwej osoby, jakie informacje były niedostępne i które decyzje nie miały właściciela.

Pytania, które zarząd powinien zadać przed 11 września

1. Które nasze produkty znajdują się w zakresie CRA?

2. Czy lista obejmuje produkty i wersje wprowadzone wcześniej na rynek?

3. Gdzie trafi zgłoszenie podatności przesłane przez klienta lub badacza?

4. Kto ocenia, czy podatność jest aktywnie wykorzystywana?

5. Kto może zatwierdzić i wysłać zgłoszenie w ciągu 24 godzin?

6. Czy posiadamy dane wymagane przez SRP?

7. Jak zidentyfikujemy użytkowników podatnej wersji?

8. Kto przygotuje i wyśle komunikat bezpieczeństwa?

9. Czy proces działa poza standardowymi godzinami pracy?

10. Kiedy ostatnio przeprowadziliśmy jego test?

Brak odpowiedzi na te pytania oznacza, że organizacja może mieć procedurę reagowania na incydenty, ale nie posiada jeszcze procesu gotowego na obowiązki CRA.

Nie zaczynaj od formularza. Zacznij od zakresu

Przed budowaniem procedury raportowania trzeba ustalić, które produkty rzeczywiście podlegają CRA oraz jaką rolę pełni przy nich firma.

Sprawdź swój produkt w bezpłatnym CRA Readiness Check

Po zakończeniu testu otrzymasz wstępną ocenę i rekomendację dalszych działań. Pozwoli to ustalić, czy organizacja powinna już przygotowywać proces raportowania podatności i incydentów przed 11 września 2026 roku.

Artykuł ma charakter informacyjny i techniczny. Nie stanowi indywidualnej interpretacji prawnej.

Materiały uwzględnione przy redakcji: poradnik CERT Polska dotyczący zarządzania bezpieczeństwem oprogramowania w kontekście CRA oraz przekazany szkic materiału landingowego CRA.