Cyber Resilience Act: jak zgłosić podatność lub incydent przez platformę ENISA?

Od 11 września 2026 r. producent produktu cyfrowego objętego Cyber Resilience Act (CRA) ma nowy obowiązek: zgłosić aktywnie wykorzystywaną podatność albo poważny incydent wpływający na bezpieczeństwo produktu. Zgłoszenie składa przez Single Reporting Platform (SRP), czyli uruchomiony przez ENISA pojedynczy portal do przekazywania informacji właściwym CSIRT-om.

Pierwsze zgłoszenie może być potrzebne w ciągu 24 godzin od uzyskania wiedzy o zdarzeniu. Na pełniejsze powiadomienie producent ma do 72 godzin, a potem musi przygotować raport końcowy. Ten obowiązek dotyczy także produktów wprowadzonych na rynek przed 11 grudnia 2027 r. Nie oznacza jednak, że od września wszystkie pozostałe wymogi CRA zaczęły już obowiązywać.

Czego dowiesz się z tego tekstu?

W skrócie

• Obowiązek z art. 14 CRA stosuje się od 11 września 2026 r. i obejmuje aktywnie wykorzystywane podatności oraz poważne incydenty dotyczące bezpieczeństwa produktu.
• Producent przekazuje wczesne ostrzeżenie do 24 godzin, powiadomienie do 72 godzin, a raport końcowy w innym terminie zależnym od rodzaju zdarzenia.
• Producent informuje też użytkowników, których dotyczy podatność lub incydent, oraz wskazuje potrzebne działania ograniczające ryzyko.
• Zgłoszenie składa się przez platformę ENISA, wybierając właściwy krajowy CSIRT wyznaczony jako koordynator.
• To producent odpowiada za zgłoszenie. Software house, dostawca komponentu albo klient mogą pomóc zebrać informacje, ale sam podział zadań w umowie nie zmienia automatycznie adresata obowiązku z CRA.

Kogo obejmuje obowiązek zgłoszenia z art. 14 CRA?

Obowiązek dotyczy producenta produktu z elementami cyfrowymi objętego CRA, który dowie się o aktywnie wykorzystywanej podatności w tym produkcie albo o poważnym incydencie mającym wpływ na jego bezpieczeństwo. Producent to co do zasady podmiot, który opracowuje produkt albo zleca jego opracowanie, a następnie udostępnia go na rynku pod własną nazwą lub znakiem towarowym.

Samo napisanie kodu dla klienta nie przesądza więc, że software house jest producentem. Znaczenie ma m.in. to, kto wprowadza produkt na rynek, pod jaką marką i na czyją odpowiedzialność został zaprojektowany. Umowa powinna oddawać ten model, a także wskazywać, kto zbiera informacje techniczne i przekazuje je osobie odpowiedzialnej za formalne zgłoszenie.

Nie każdy SaaS jest produktem objętym CRA. Komisja wskazuje, że samodzielna usługa SaaS zaprojektowana i rozwijana poza odpowiedzialnością producenta produktu cyfrowego co do zasady nie jest takim produktem. Inaczej może być z oprogramowaniem pobieranym na urządzenie albo zdalnym przetwarzaniem danych, które producent zaprojektował lub rozwija na swoją odpowiedzialność i bez którego produkt nie mógłby pełnić jednej ze swoich funkcji. Dlatego trzeba ocenić konkretny produkt i jego architekturę, a nie opierać się wyłącznie na etykiecie „SaaS”.

Szerszy kontekst cyklu życia produktu, aktualizacji i odpowiedzialności opisałem w tekście o Cyber Resilience Act i aktualizacjach bezpieczeństwa. CRA może mieć znaczenie także dla dostawcy rozwijającego albo utrzymującego produkt klienta, nawet jeżeli nie jest on producentem w rozumieniu rozporządzenia. Podział pracy i obowiązków warto wtedy uregulować w umowie IT.

Jakie zdarzenia trzeba zgłosić?

Art. 14 CRA obejmuje dwa rodzaje zdarzeń:

• Aktywnie wykorzystywana podatność to podatność, dla której istnieją wiarygodne dowody, że złośliwy podmiot wykorzystał ją bez zgody właściciela systemu. Samo opublikowanie CVE, wykrycie błędu w skanerze albo znalezienie podatności w kodzie nie wystarcza automatycznie do uznania jej za aktywnie wykorzystywaną.
• Poważny incydent mający wpływ na bezpieczeństwo produktu występuje, gdy zdarzenie negatywnie wpływa lub może wpłynąć na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo ważnych danych lub funkcji. Drugą przesłanką jest to, że zdarzenie doprowadziło lub może doprowadzić do wprowadzenia albo wykonania złośliwego kodu w produkcie lub w systemach użytkownika. Nie każda przerwa w działaniu usługi spełnia te warunki z art. 14 ust. 5 CRA.

Obowiązek dotyczy produktów objętych CRA, które były już na rynku przed 11 grudnia 2027 r. Producent nie musi zgłaszać wstecz podatności, o której aktywnym wykorzystaniu wiedział przed 11 września 2026 r. Jeżeli jednak uzyska taką wiedzę po tej dacie, zgłoszenie może być wymagane, nawet gdy sama podatność istniała wcześniej.

Jeśli podatność pochodzi z komponentu zewnętrznego, odpowiedzialności nie można z góry przerzucić na jego dostawcę. Komisja wyjaśnia, że producent produktu końcowego zgłasza aktywnie wykorzystywaną podatność zawartą w jego produkcie. Producent komponentu również zgłasza ją, jeżeli ten komponent sam został wprowadzony na rynek. Przy analizie trzeba ustalić, czy komponent rzeczywiście jest częścią produktu oraz czy podatność może być w nim aktywnie wykorzystana.

Jakie terminy obowiązują producenta?

Od chwili uzyskania wiedzy o zdarzeniu producent ma maksymalnie 24 godziny na wczesne ostrzeżenie i 72 godziny na powiadomienie ze wstępną oceną. Zgłoszenia należy przekazywać bez zbędnej zwłoki, więc terminy maksymalne nie są zachętą do czekania.

Etap	Termin	Co przekazać
Wczesne ostrzeżenie	Bez zbędnej zwłoki, maksymalnie 24 godziny od uzyskania wiedzy	Podstawowe informacje o podatności albo incydencie
Powiadomienie	Bez zbędnej zwłoki, maksymalnie 72 godziny od uzyskania wiedzy	Informacje ogólne i wstępną ocenę zdarzenia
Raport końcowy dla podatności	Maksymalnie 14 dni od udostępnienia poprawki lub innego środka zaradczego	Informacje o podatności, wykorzystaniu oraz sposobie jej naprawienia lub ograniczenia
Raport końcowy dla poważnego incydentu	W ciągu miesiąca od powiadomienia 72-godzinnego	Ustalenia dotyczące incydentu i podjętych działań

Przy podatności termin raportu końcowego wiąże się z udostępnieniem środka zaradczego, a przy poważnym incydencie biegnie od powiadomienia 72-godzinnego. To różne punkty startowe. Nie warto zapisywać ich w procedurze jako jednego, ogólnego terminu „miesiąc na raport”. Szczegółowe pola zmieniają się między etapami, a platforma ENISA udostępnia osobne wytyczne i słownik zgłoszeń.

Czy producent musi poinformować użytkowników?

Tak. Art. 14 ust. 8 CRA wymaga poinformowania użytkowników, których dotyczy aktywnie wykorzystywana podatność lub poważny incydent, a w stosownych przypadkach wszystkich użytkowników produktu. Gdy jest to potrzebne, producent przekazuje im także dostępne działania ograniczające ryzyko i środki zaradcze, które mogą zastosować. Komunikat dla użytkowników trzeba więc przygotować obok zgłoszenia do organów, uwzględniając to, co już wiadomo o wpływie na produkt.

Gdzie i jak złożyć zgłoszenie?

Producent składa zgłoszenie elektronicznie przez Single Reporting Platform ENISA. W portalu wybiera CSIRT wyznaczony jako koordynator. Co do zasady wybór zależy przede wszystkim od głównego miejsca prowadzenia działalności producenta. Wybór warto sprawdzić przed wysłaniem: błędnie wskazany CSIRT może unieważnić zgłoszenie, które trzeba będzie złożyć ponownie.

Do obsługi platformy potrzebne jest konto EU Login z włączonym uwierzytelnianiem wieloskładnikowym (MFA). Można wskazać głównego i dodatkowych przedstawicieli firmy. ENISA podaje, że weryfikacja powiązania przedstawiciela z producentem nie blokuje złożenia zgłoszenia; konto może przekazać maksymalnie 20 zgłoszeń, zanim weryfikacja stanie się warunkiem dalszego korzystania. Przy pierwszym uruchomieniu platforma nie oferuje API, więc zgłoszenia składa się przez jej interfejs.

W praktyce upoważniony przedstawiciel rejestruje producenta w SRP i wybiera właściwy CSIRT. Następnie wskazuje rodzaj zdarzenia i wysyła wczesne ostrzeżenie. W ciągu 72 godzin od uzyskania wiedzy uzupełnia powiadomienie o dostępne ustalenia, a później przekazuje raport końcowy w terminie właściwym dla podatności lub incydentu. Zakres pól zależy od etapu i rodzaju zdarzenia; opisuje go słownik zgłoszeń ENISA.

Co do zasady zgłoszenie jest równocześnie udostępniane ENISA, a koordynujący CSIRT przekazuje je innym właściwym CSIRT-om. W wyjątkowych okolicznościach CSIRT może opóźnić przekazanie informacji o podatności lub incydencie innym CSIRT-om. Osobny, węższy wyjątek dotyczy 72-godzinnego powiadomienia o aktywnie wykorzystywanej podatności: po wskazaniu przez producenta jednej z ustawowych przesłanek ENISA może początkowo otrzymać tylko część jego treści. O obu odstępstwach decyduje CSIRT; żadne nie zwalnia producenta ze zgłoszenia. Szczegóły określa rozporządzenie delegowane Komisji (UE) 2026/881.

Przed wysłaniem trzeba też sprawdzić, jakie informacje można przekazać. SRP stosuje środki ochrony poufności, ale producent nadal powinien ograniczyć zgłoszenie do informacji wymaganych albo potrzebnych do oceny zdarzenia i nie umieszczać w nim zbędnych sekretów czy danych osobowych.

Co powinien przygotować producent produktu?

Procedura zgłoszeniowa musi działać również poza godzinami pracy i nie może zależeć od tego, czy jedna konkretna osoba odbierze telefon. Producent powinien ustalić co najmniej:

• które produkty, wersje, komponenty i usługi zdalne mogą podlegać CRA;
• kto ocenia, czy sygnał oznacza aktywne wykorzystanie podatności lub poważny incydent;
• kiedy i komu pracownicy, klienci oraz podwykonawcy przekazują wiarygodny sygnał;
• kto uruchamia zegar 24 i 72 godzin oraz zapisuje moment uzyskania wiedzy;
• kto ma dostęp do SRP i konto EU Login z MFA;
• kto przygotowuje ostrzeżenie, powiadomienie, aktualizacje i raport końcowy;
• kto przygotowuje komunikat dla użytkowników i przekazuje im potrzebne działania ochronne;
• jak producent koordynuje zgłoszenie z dostawcą komponentu, software house’em i klientami;
• jak zachowuje dowody, oceny i decyzję o zgłoszeniu albo o braku obowiązku.

Przykład modelowy: support dostaje wiarygodny sygnał o wykorzystaniu podatności w bibliotece użytej w sprzedawanej aplikacji. Przekazuje go zespołowi bezpieczeństwa i osobie odpowiedzialnej za decyzję o zgłoszeniu. Zespół sprawdza, które wersje produktu zawierają bibliotekę i czy sposób jej użycia pozwala wykorzystać błąd w aplikacji; zapisuje też moment uzyskania wiedzy. Jeżeli produkt jest objęty CRA, a wykorzystanie podatności w nim jest możliwe, producent zgłasza zdarzenie mimo pochodzenia błędu z zewnętrznej biblioteki i informuje użytkowników, których ono dotyczy. Jeżeli architektura produktu wyklucza wykorzystanie błędu, dokumentuje podstawę decyzji o braku obowiązku zgłoszenia.

W umowie z software house’em lub dostawcą komponentu warto opisać czas przekazywania informacji o podatnościach i incydentach, współpracę przy ocenie wpływu, przygotowanie poprawki, treść komunikatów i wsparcie przy raportach. Taki kontrakt porządkuje współpracę, ale nie zmienia tego, kto zgodnie z CRA ma obowiązek zgłoszenia.

Czy od 11 września 2026 r. obowiązuje już cały CRA?

Nie. Od 11 września 2026 r. stosuje się obowiązki zgłaszania z art. 14. Większość pozostałych wymogów CRA, w tym zasadnicze obowiązki cyberbezpieczeństwa producentów, nadzór rynku i egzekwowanie, zaczyna być stosowana 11 grudnia 2027 r. Warto więc osobno zaplanować procedurę zgłoszeniową, która działa już teraz, i szersze dostosowanie produktu do CRA.

Co zrobić teraz?

Jeżeli firma wprowadza do obrotu własne oprogramowanie, urządzenie albo produkt cyfrowy z funkcjami zdalnymi, warto najpierw ustalić, czy pełni rolę producenta i które produkty wchodzą w zakres regulacji. Potem trzeba przetestować ścieżkę eskalacji od pierwszego sygnału do formalnego zgłoszenia przez SRP. Warto też sprawdzić, czy umowy z software house’em, dostawcami i klientami zapewniają informacje oraz współpracę w terminie krótszym niż ustawowe 24 godziny.

Ten proces łączy obowiązki produktowe z obsługą podatności, maintenance i odpowiedzialnością kontraktową. Więcej o tym, jak ująć je w relacji z dostawcą, piszę w artykule o KSC i NIS2 w umowie z software house’em. Jeżeli porządkujesz odpowiedzialność za produkt lub umowę wsparcia, zobacz też wsparcie prawne dla firm IT.

Źródła i dalsze informacje

• Cyber Resilience Act, rozporządzenie (UE) 2024/2847
• Platforma Single Reporting Platform ENISA
• FAQ ENISA o zgłoszeniach, terminach i rejestracji w SRP
• FAQ Komisji Europejskiej o wdrażaniu CRA

Potrzebujesz uporządkować odpowiedzialność za produkt IT?

Jeżeli rozwijasz produkt cyfrowy albo utrzymujesz go dla klienta, warto ustalić, kto zbiera informacje o podatnościach, ocenia ich wpływ i prowadzi zgłoszenie. W ramach wsparcia prawnego dla firm IT i software house’ów pomagam dopasować umowy, maintenance i odpowiedzialność do tego, jak działa produkt i zespół.

Umów 30-minutową konsultację