Cyber Resilience Act od 11 września 2026 r. Kto musi zgłaszać podatności i incydenty?

Od 11 września 2026 roku producenci produktów z elementami cyfrowymi będą musieli zgłaszać aktywnie wykorzystywane podatności i poważne incydenty wpływające na bezpieczeństwo produktu. Pierwsze ostrzeżenie trzeba przekazać bez zbędnej zwłoki, nie później niż w ciągu 24 godzin od uzyskania wiedzy o zdarzeniu. W ciągu 72 godzin należy uzupełnić zgłoszenie, a następnie złożyć raport końcowy. Obowiązek obejmie nie tylko nowe urządzenia i programy, lecz także produkty udostępnione na rynku Unii Europejskiej przed pełnym rozpoczęciem stosowania Cyber Resilience Act. Nie oznacza to jednak, że 11 września 2026 roku zaczynają obowiązywać wszystkie wymagania CRA. Zasadnicza część rozporządzenia, w tym wymagania dotyczące projektowania, dokumentacji technicznej, oceny zgodności i oznakowania CE, będzie stosowana od 11 grudnia 2027 roku. Wyjaśniamy, kogo dotyczy wcześniejszy termin, co podlega zgłoszeniu i jak przygotować firmę do działania w rytmie 24 i 72 godzin.

Najważniejsze informacje

• 11 września 2026 roku zaczynają być stosowane obowiązki sprawozdawcze z art. 14 CRA, a nie całe rozporządzenie.
• Pełne stosowanie zasadniczych wymagań Cyber Resilience Act rozpocznie się 11 grudnia 2027 roku.
• Obowiązek raportowania dotyczy przede wszystkim producentów sprzętu i oprogramowania udostępnianego na rynku Unii Europejskiej pod ich nazwą lub znakiem towarowym.
• Zgłoszeniu podlega aktywnie wykorzystywana podatność oraz poważny incydent wpływający na bezpieczeństwo produktu z elementami cyfrowymi.
• Samo odkrycie błędu albo podatności typu zero-day nie oznacza automatycznie obowiązku zgłoszenia. Potrzebne są wiarygodne dowody wykorzystania podatności przez złośliwego aktora albo spełnienie kryteriów poważnego incydentu.
• Wczesne ostrzeżenie należy przesłać bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin, a rozszerzone zgłoszenie najpóźniej w ciągu 72 godzin od uzyskania wiedzy o zdarzeniu.
• Zgłoszenia będą składane przez Single Reporting Platform utrzymywaną przez ENISA i kierowane do właściwego CSIRT oraz ENISA.
• Producent musi także poinformować użytkowników dotkniętych zdarzeniem, a w odpowiednich przypadkach wszystkich użytkowników, oraz przekazać im dostępne środki ograniczające ryzyko.
• Obowiązek obejmie również produkty udostępnione na rynku przed 11 grudnia 2027 roku.
• Jedno zdarzenie może jednocześnie wymagać zgłoszenia na podstawie CRA, NIS2 lub KSC, DORA i RODO. Każdy reżim trzeba ocenić osobno.

Zapraszamy do współpracy

Szczegółowe informacje o ofercie i warunkach współpracy można uzyskać telefonicznie lub wysyłając zapytanie za pomocą formularza kontaktowego.

BPPZ – Biuro Porad Prawnych Zacharski

– Chcesz przygotować produkty i procedurę zgłoszeń do wymagań CRA?

• +48 600 784 526
• kontakt@bppz.pl

Zadzwoń Napisz wiadomość

Co dokładnie zmienia się 11 września 2026 roku?

Cyber Resilience Act, czyli rozporządzenie (UE) 2024/2847, wszedł w życie 10 grudnia 2024 roku. Ustawodawca przewidział jednak kilka etapów jego stosowania.

Data	Co się zmienia	Znaczenie dla firmy
10 grudnia 2024 r.	Wejście CRA w życie	Rozpoczął się okres przygotowawczy
11 czerwca 2026 r.	Stosowanie przepisów o notyfikacji jednostek oceniających zgodność	Państwa członkowskie organizują system jednostek notyfikowanych
11 września 2026 r.	Stosowanie obowiązków zgłaszania z art. 14	Producenci muszą raportować określone podatności i incydenty
11 grudnia 2027 r.	Pełne stosowanie zasadniczej części CRA	Zaczynają obowiązywać między innymi wymagania dla produktu, dokumentacji, oceny zgodności i CE

Najważniejszy wniosek jest prosty: 11 września 2026 roku nie jest datą pełnego wdrożenia Cyber Resilience Act. Jest to jednak rzeczywisty termin operacyjny. Firma objęta art. 14 musi już wtedy potrafić rozpoznać zdarzenie podlegające raportowaniu, ustalić moment rozpoczęcia biegu terminu, zebrać podstawowe informacje i wysłać zgłoszenie przez właściwą platformę.

Nie wystarczy więc dopisać CRA do planu zgodności na 2027 rok. Jeżeli producent nie ma procesu przyjmowania informacji o podatnościach, monitorowania wykorzystania błędów oraz całodobowej eskalacji, może nie zdążyć z pierwszym zgłoszeniem.

Czym jest Cyber Resilience Act?

CRA ustanawia horyzontalne wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi udostępnianych na rynku Unii Europejskiej. Obejmuje zarówno sprzęt, jak i oprogramowanie, w tym komponenty sprzedawane osobno.

Rozporządzenie ma doprowadzić do tego, aby cyberbezpieczeństwo było uwzględniane przez cały cykl życia produktu. Producent ma między innymi oceniać ryzyko, projektować produkt zgodnie z zasadami security by design i security by default, zarządzać podatnościami, dostarczać aktualizacje bezpieczeństwa, prowadzić dokumentację oraz informować użytkowników o okresie wsparcia.

Od 11 grudnia 2027 roku zgodność z tymi wymaganiami będzie powiązana z oceną zgodności, deklaracją zgodności UE i oznakowaniem CE. Dla określonych produktów ważnych i krytycznych przewidziano bardziej wymagające procedury, w tym udział zewnętrznej jednostki oceniającej zgodność.

Wrześniowy obowiązek raportowania działa wcześniej, ponieważ informacje o aktywnie wykorzystywanych podatnościach i poważnych incydentach są potrzebne do ochrony użytkowników i reagowania na zagrożenia już teraz.

Jakie produkty obejmuje CRA?

Produktem z elementami cyfrowymi jest produkt programowy lub sprzętowy oraz jego rozwiązania zdalnego przetwarzania danych. Zakres obejmuje także komponenty oprogramowania i sprzętu udostępniane na rynku osobno.

Warunkiem jest co do zasady udostępnienie produktu na rynku w ramach działalności komercyjnej oraz to, że jego przeznaczenie lub racjonalnie przewidywalne użycie obejmuje bezpośrednie albo pośrednie logiczne lub fizyczne połączenie z urządzeniem lub siecią.

Przykłady produktów, które mogą podlegać CRA, to:

• routery, przełączniki i inne urządzenia sieciowe;
• kamery IP, wideodomofony i elektroniczne systemy kontroli dostępu;
• urządzenia IoT, inteligentne liczniki, termostaty i sterowniki;
• maszyny przemysłowe zawierające połączone sterowniki lub moduły komunikacyjne;
• systemy operacyjne, aplikacje mobilne i programy komputerowe;
• oprogramowanie serwerowe i narzędzia do zarządzania infrastrukturą;
• wtyczki, biblioteki i komponenty sprzedawane lub udostępniane komercyjnie osobno;
• urządzenia dla dzieci połączone z internetem, na przykład elektroniczne nianie lub zabawki;
• rozwiązania uwierzytelniające, menedżery haseł i narzędzia bezpieczeństwa;
• oprogramowanie wbudowane w urządzenie oraz aplikacja służąca do jego obsługi.

Lista nie jest zamknięta. O objęciu rozporządzeniem nie decyduje etykieta „IoT”, „SaaS” albo „oprogramowanie”, lecz rzeczywista funkcja produktu, sposób jego udostępniania i połączenie z urządzeniem lub siecią.

Czy każda usługa SaaS podlega CRA?

Nie każda samodzielna usługa chmurowa staje się produktem z elementami cyfrowymi. CRA obejmuje jednak rozwiązanie zdalnego przetwarzania danych, jeżeli oprogramowanie zostało zaprojektowane i rozwinięte przez producenta lub na jego odpowiedzialność, a jego brak uniemożliwiłby produktowi wykonanie jednej z funkcji.

Przykładem może być chmurowy panel konieczny do konfigurowania i obsługi inteligentnego urządzenia. Jeżeli urządzenie bez tej usługi nie wykonuje określonej funkcji, zdalny element może być częścią produktu objętego CRA.

Inaczej należy ocenić ogólną usługę hostingową, pocztę internetową albo samodzielną usługę chmurową, która nie stanowi integralnego rozwiązania zdalnego przetwarzania konkretnego produktu. Granica wymaga analizy architektury i odpowiedzialności za rozwój oprogramowania.

Jakie produkty są wyłączone?

CRA nie obejmuje w takim samym zakresie każdego produktu cyfrowego. Wyłączenia dotyczą między innymi określonych produktów regulowanych odrębnymi przepisami unijnymi, jeżeli przewidują one wymagania osiągające równoważny poziom ochrony. Dotyczy to w szczególności niektórych wyrobów medycznych, produktów motoryzacyjnych, lotniczych i wyposażenia morskiego. Odrębne zasady przewidziano również dla produktów związanych z bezpieczeństwem narodowym, obronnością i informacjami niejawnymi.

Nie należy stosować tych wyłączeń automatycznie do całej firmy albo branży. Ten sam producent może oferować jeden produkt podlegający przepisom sektorowym oraz inne urządzenie albo aplikację objęte CRA.

Kto jest producentem według CRA?

Producentem jest osoba fizyczna lub prawna, która rozwija albo wytwarza produkt z elementami cyfrowymi, zleca jego zaprojektowanie, rozwinięcie lub wytworzenie i wprowadza go na rynek pod własną nazwą lub znakiem towarowym. Nie ma znaczenia, czy produkt jest oferowany odpłatnie, monetyzowany w inny sposób czy udostępniany bez opłaty w ramach działalności komercyjnej.

To oznacza, że producentem może być nie tylko fabryka urządzeń. Status ten może mieć również:

• polska spółka sprzedająca aplikację pod własną marką;
• startup oferujący urządzenie IoT wyprodukowane przez zewnętrzną fabrykę;
• firma tworząca oprogramowanie, która rozwija i sprzedaje własny produkt;
• firma zamawiająca wykonanie systemu u podwykonawcy i wprowadzająca go na rynek pod własną nazwą;
• dostawca, który wprowadza istotne modyfikacje do istniejącego produktu i następnie udostępnia go pod własną odpowiedzialnością.

Samo wykonanie kodu na zlecenie klienta nie zawsze czyni wykonawcę producentem. Trzeba ustalić, kto decyduje o przeznaczeniu produktu, kontroluje jego rozwój i wydania, udostępnia go na rynku oraz posługuje się własną nazwą lub marką.

Rola	Typowa sytuacja	Znaczenie dla raportowania od 11 września 2026 r.
Producent	Wprowadza sprzęt lub oprogramowanie pod własną nazwą	Odpowiada za obowiązkowe zgłoszenia z art. 14
Upoważniony przedstawiciel	Działa w UE na podstawie pisemnego umocowania producenta	Może wykonywać określone zadania w granicach mandatu
Importer	Wprowadza do UE produkt producenta spoza Unii	Nie zastępuje producenta w zgłoszeniu z art. 14, ale powinien zapewnić natychmiastową eskalację informacji
Dystrybutor	Udostępnia produkt w łańcuchu dostaw bez zmiany jego właściwości	Nie składa zgłoszenia jako producent, ale powinien szybko przekazać producentowi sygnały od rynku
Opiekun oprogramowania open source	Systematycznie wspiera rozwój określonego FOSS przeznaczonego do działalności komercyjnej	Ma szczególne, ograniczone obowiązki, w tym odpowiednie raportowanie

Bezpośredni obowiązek z art. 14 dotyczy przede wszystkim producenta. Zasadnicze obowiązki CRA przewidziane dla importerów i dystrybutorów będą stosowane od 11 grudnia 2027 roku. Już od września 2026 roku łańcuch dostaw powinien jednak umożliwiać producentowi terminowe raportowanie. Jeżeli importer albo dystrybutor otrzyma od klienta informację o wykorzystanej podatności lub kompromitacji produktu, potrzebuje szybkiego kanału przekazania jej do podmiotu odpowiedzialnego. Umowa handlowa powinna określać osoby kontaktowe, terminy eskalacji i zasady komunikacji z użytkownikami.

Jeżeli status firmy, podział ról w grupie albo odpowiedzialność za produkt nie są jasne, punktem wyjścia może być projektowe doradztwo prawne. Analiza powinna objąć nie tylko umowy, lecz także markę produktu, kontrolę nad rozwojem, sposób dystrybucji, aktualizacje i faktyczne decyzje dotyczące cyberbezpieczeństwa.

Oprogramowanie open source a CRA

Bezpłatne i otwarte oprogramowanie, które nie jest udostępniane na rynku w ramach działalności komercyjnej, co do zasady nie podlega pełnym obowiązkom producenta. Rozporządzenie nie ma przenosić odpowiedzialności na indywidualnych kontrybutorów, którzy bez wynagrodzenia rozwijają kod poza własną odpowiedzialnością produktową.

Sytuacja zmienia się, gdy firma udostępnia produkt open source w ramach działalności komercyjnej albo buduje własny produkt z wykorzystaniem takich komponentów. Producent produktu końcowego nadal odpowiada za bezpieczeństwo swojej integracji.

CRA wprowadza również kategorię opiekuna oprogramowania open source. Jest to osoba prawna, która systematycznie i trwale wspiera rozwój konkretnego otwartego oprogramowania przeznaczonego do działalności komercyjnej oraz zapewnia jego żywotność. Taki podmiot ma lżejszy reżim, ale powinien między innymi posiadać politykę cyberbezpieczeństwa i realizować określone obowiązki sprawozdawcze.

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

Obowiązek producenta obejmuje dwa rodzaje zdarzeń:

1. aktywnie wykorzystywaną podatność znajdującą się w produkcie z elementami cyfrowymi;
2. poważny incydent mający wpływ na bezpieczeństwo produktu z elementami cyfrowymi.

Nie każda podatność i nie każde zdarzenie techniczne trafiają więc do obowiązkowego trybu z art. 14.

Zdarzenie	Obowiązkowe zgłoszenie	Dlaczego
Podatność jest aktywnie wykorzystywana przez złośliwego aktora i dotyczy produktu	Tak	Spełnia definicję aktywnie wykorzystywanej podatności
Poważny incydent narusza albo może naruszyć poufność, integralność, autentyczność lub dostępność ważnych danych lub funkcji	Tak	Spełnia kryterium poważnego wpływu na bezpieczeństwo produktu
Incydent prowadzi albo może prowadzić do wykonania złośliwego kodu w produkcie lub systemie użytkownika	Tak	CRA uznaje taki skutek za przesłankę poważnego incydentu
Badacz odkrywa zero-day, ale brak dowodów jego złośliwego wykorzystania	Nie automatycznie	Sama możliwość wykorzystania nie oznacza aktywnej eksploatacji
Skan wykrywa nieaktualny komponent bez dowodu wykorzystania i bez poważnego incydentu	Nie automatycznie	Potrzebna jest ocena wpływu i rzeczywistej ekspozycji produktu
Występuje próba ataku bez skutku i bez spełnienia kryteriów poważnego incydentu	Nie zawsze	Możliwe jest zgłoszenie dobrowolne
Zdarzenie, które mogło doprowadzić do incydentu, ale do niego nie doprowadziło, czyli near miss	Dobrowolne	Art. 15 pozwala na dobrowolne raportowanie

Aktywnie wykorzystywana podatność

Jest to podatność, w odniesieniu do której istnieją wiarygodne dowody, że złośliwy aktor wykorzystał ją w systemie bez zgody jego właściciela. Informacja może pochodzić z własnego monitoringu producenta, od użytkownika, partnera, badacza, CSIRT, organu publicznego albo wiarygodnego raportu o kampanii ataków.

Samo opublikowanie opisu błędu, nadanie numeru CVE albo przygotowanie demonstracyjnego kodu proof of concept nie zawsze wystarcza. Zespół musi ustalić, czy istnieje wiarygodny dowód faktycznej złośliwej eksploatacji oraz czy podatność znajduje się w konkretnym produkcie.

Nie oznacza to prawa do prowadzenia wielodniowej analizy przed uruchomieniem procedury. Gdy pojawia się sygnał o kompromitacji, producent powinien niezwłocznie przeprowadzić wstępną ocenę. Bieg terminu rozpoczyna się, gdy organizacja ma rozsądny stopień pewności, że podatność jest aktywnie wykorzystywana albo wystąpił poważny incydent. Nie należy czekać na pełną analizę powłamaniową, ustalenie sprawcy czy zakończenie prac nad poprawką.

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

Incydent jest poważny, jeżeli:

• negatywnie wpływa albo może negatywnie 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; lub
• doprowadził albo może doprowadzić do wprowadzenia lub wykonania złośliwego kodu w produkcie albo w sieci i systemach informacyjnych użytkownika.

Ocena nie powinna opierać się wyłącznie na liczbie poszkodowanych klientów. Krytyczna możliwość zdalnego wykonania kodu w urządzeniu przemysłowym może być poważna nawet wtedy, gdy producent na początku zna tylko jeden potwierdzony przypadek.

Czy trzeba zgłaszać podatność w komponencie zewnętrznym?

Tak, jeżeli aktywnie wykorzystywana podatność pochodząca z biblioteki, modułu albo innego komponentu znajduje się również w produkcie producenta i może być w nim wykorzystana. Obowiązek może wówczas dotyczyć zarówno producenta produktu końcowego, jak i producenta komponentu, jeżeli komponent został osobno udostępniony na rynku.

Nie każda podatność opublikowana dla biblioteki automatycznie oznacza zgłoszenie przez wszystkich korzystających z niej producentów. Jeżeli podatna funkcja nie została włączona, kod nie jest osiągalny albo sposób integracji uniemożliwia wykorzystanie błędu w danym produkcie, trzeba udokumentować tę ocenę. Dobrowolne zgłoszenie nadal może być możliwe.

W praktyce firma potrzebuje aktualnej informacji o tym, jakie komponenty i wersje znajdują się w poszczególnych produktach. Właśnie dlatego mapa zależności i SBOM są potrzebne przed 2027 rokiem, nawet jeśli pełne wymagania dokumentacyjne zaczną być stosowane później. Bez tej wiedzy nie da się w kilka godzin ocenić, czy nowa podatność biblioteki wpływa na konkretną wersję produktu.

Terminy 24 godziny, 72 godziny i raport końcowy

CRA wprowadza etapowy model zgłoszenia. Pierwsza informacja ma być szybka i może być ograniczona. Kolejne etapy służą uzupełnianiu ustaleń.

Etap	Termin	Minimalny cel
Wczesne ostrzeżenie	Bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin od uzyskania wiedzy	Zidentyfikowanie rodzaju zdarzenia, produktu i dostępnego zasięgu geograficznego
Zgłoszenie podatności lub incydentu	Bez zbędnej zwłoki, najpóźniej w ciągu 72 godzin od uzyskania wiedzy	Przekazanie natury zdarzenia, wstępnej oceny oraz podjętych i dostępnych środków ograniczających ryzyko
Raport końcowy o podatności	Najpóźniej 14 dni od udostępnienia środka naprawczego lub ograniczającego ryzyko	Opis podatności, dotkliwości, wpływu, możliwego sprawcy i poprawki
Raport końcowy o poważnym incydencie	W ciągu miesiąca od zgłoszenia 72-godzinnego	Szczegółowy opis, wpływ, prawdopodobna przyczyna i zastosowane środki
Informacja dla użytkowników	Terminowo po uzyskaniu wiedzy, odpowiednio do ryzyka	Ostrzeżenie dotkniętych użytkowników i przekazanie możliwych działań ochronnych

Określenie „najpóźniej w ciągu 24 godzin” nie oznacza, że firma zawsze może czekać do końca doby. Rozporządzenie wymaga działania bez zbędnej zwłoki. Jeżeli organizacja ma już wystarczające informacje do wysłania wczesnego ostrzeżenia, powinna je przekazać.

Pierwsze zgłoszenie nie musi zawierać wyniku całego dochodzenia. Celem jest szybkie ostrzeżenie. Zespół powinien jednak potrafić wskazać produkt, producenta, rodzaj zgłoszenia, dostępne informacje o państwach, w których produkt udostępniono, oraz podstawowe fakty pozwalające zrozumieć zdarzenie.

Gdzie składa się zgłoszenie?

Zgłoszenia będą składane elektronicznie przez CRA Single Reporting Platform, czyli SRP, ustanowioną i utrzymywaną przez ENISA.

Producent dokonuje jednego zgłoszenia. Platforma kieruje je do CSIRT wyznaczonego jako koordynator dla państwa głównego miejsca prowadzenia działalności producenta i co do zasady udostępnia je jednocześnie ENISA. CSIRT przekazuje następnie informację do właściwych zespołów w innych państwach członkowskich, w których produkt został udostępniony.

Dla producenta spoza Unii właściwy CSIRT ustala się według sekwencji wskazanej w art. 14 ust. 7 CRA. Znaczenie może mieć siedziba upoważnionego przedstawiciela, importera, dystrybutora albo miejsce, w którym znajduje się największa liczba użytkowników. Taki producent powinien ustalić właściwy punkt raportowania przed incydentem, a nie dopiero w ostatniej godzinie terminu.

ENISA wskazuje, że użytkownik reprezentujący producenta uwierzytelnia się za pomocą EU Login. Walidacja upoważnienia przez właściwy CSIRT odbywa się równolegle i nie powinna blokować złożenia zgłoszenia. Według aktualnej instrukcji ENISA producent nie powinien inicjować pełnej rejestracji i walidacji wyłącznie na zapas, jeżeli nie składa konkretnego zgłoszenia. Warto jednak wcześniej przygotować EU Login, wewnętrzne upoważnienie, dane producenta oraz zastępstwo dla osoby raportującej.

Jakie informacje trzeba przygotować?

Zakres danych rośnie wraz z kolejnymi etapami. Aktualne materiały ENISA przewidują między innymi następujące pola:

Wczesne ostrzeżenie w ciągu 24 godzin

• rodzaj zgłoszenia: podatność albo incydent;
• dane producenta lub opiekuna oprogramowania open source;
• identyfikację produktu;
• krótki tytuł zdarzenia;
• informację, czy incydent może wynikać z działania bezprawnego lub złośliwego;
• państwa członkowskie, w których produkt został udostępniony, jeżeli informacja jest dostępna.

Zgłoszenie w ciągu 72 godzin

• ogólny charakter podatności i sposobu jej wykorzystania albo naturę incydentu;
• datę i czas wykrycia oraz, jeśli to możliwe, wystąpienia incydentu;
• wstępną ocenę zdarzenia;
• podjęte środki naprawcze lub ograniczające ryzyko;
• działania, które mogą podjąć użytkownicy;
• ocenę wrażliwości przekazywanych informacji;
• dostępne identyfikatory, na przykład CVE lub EUVD.

Raport końcowy

• szczegółowy opis podatności albo incydentu;
• ocenę dotkliwości i wpływu;
• znane informacje o złośliwym aktorze, jeśli są dostępne;
• prawdopodobne źródło albo przyczynę incydentu;
• opis udostępnionej aktualizacji lub innego środka zaradczego;
• zastosowane i nadal prowadzone działania ograniczające skutki.

Zespół prawny nie przygotuje tych informacji sam. Potrzebna jest współpraca product security, developmentu, IT, obsługi klienta, działu prawnego, compliance, komunikacji i zarządu. Procedura powinna wskazywać właściciela każdego pola, aby w czasie incydentu nie ustalać od początku, kto zna listę wersji produktu albo zasięg sprzedaży.

Obowiązek poinformowania użytkowników

Zgłoszenie do SRP nie zastępuje komunikacji z użytkownikami. Po uzyskaniu wiedzy o aktywnie wykorzystywanej podatności albo poważnym incydencie producent powinien poinformować użytkowników, których zdarzenie dotyczy, a gdy jest to odpowiednie, wszystkich użytkowników produktu.

Komunikat powinien wyjaśniać:

• jakiego produktu i wersji dotyczy problem;
• na czym polega ryzyko, w języku zrozumiałym dla odbiorcy;
• jakie działania użytkownik powinien wykonać;
• czy dostępna jest poprawka, aktualizacja albo bezpieczna konfiguracja;
• czy należy czasowo wyłączyć funkcję, odłączyć urządzenie albo ograniczyć dostęp;
• gdzie można uzyskać dalsze informacje i wsparcie.

Nie należy publikować szczegółów technicznych, które nie są potrzebne użytkownikowi i mogłyby ułatwić kolejne ataki. Jednocześnie zbyt ogólny komunikat typu „zaktualizuj urządzenie ze względów bezpieczeństwa” może nie pozwolić odbiorcy ocenić pilności sytuacji.

Jeżeli producent nie poinformuje użytkowników w odpowiednim czasie, właściwy CSIRT może przekazać taką informację, gdy uzna to za proporcjonalne i konieczne do zapobieżenia skutkom albo ich ograniczenia.

Czy obowiązek obejmuje produkty sprzedane przed 2027 rokiem?

Tak. Obowiązki sprawozdawcze z art. 14 mają zastosowanie do wszystkich produktów z elementami cyfrowymi objętych CRA, które zostały udostępnione na rynku Unii, w tym produktów wprowadzonych przed 11 grudnia 2027 roku.

Jest to ważny wyjątek od ogólnej reguły przejściowej. Starszy produkt co do zasady nie musi zostać natychmiast dostosowany do wszystkich wymagań technicznych CRA tylko dlatego, że nadal znajduje się u klientów. Jeżeli jednak po 11 września 2026 roku producent uzyska wiedzę o aktywnie wykorzystywanej podatności albo poważnym incydencie dotyczącym takiego produktu, obowiązek zgłoszenia może powstać.

Komisja wskazuje również, że nie ma obowiązku wstecznego zgłaszania aktywnego wykorzystania, o którym producent wiedział już przed rozpoczęciem stosowania obowiązków raportowych. Inaczej będzie, gdy sama podatność była wcześniej znana, ale wiarygodna informacja o jej aktywnym wykorzystaniu pojawi się po 11 września 2026 roku.

Firma powinna więc uwzględnić w procedurze produkty wycofane ze sprzedaży, ale nadal używane przez klientów. Brak aktywnego zespołu projektowego, stare środowisko kompilacji albo odejście pierwotnych programistów nie usuwa obowiązku raportowania.

CRA, NIS2, KSC, DORA i RODO. Czy jedno zgłoszenie wystarczy?

Nie należy zakładać, że jedno zgłoszenie zamyka wszystkie obowiązki. Regulacje chronią inne dobra, posługują się odmiennymi kryteriami i mogą wskazywać różne organy oraz terminy.

Status producenta według CRA nie przesądza, czy organizacja jest równocześnie podmiotem kluczowym albo ważnym. Tę kwalifikację można przeprowadzić osobno, korzystając z materiału Czy moja firma podlega NIS2? Praktyczny test kwalifikacyjny. Jeżeli firma podlega polskiej ustawie o krajowym systemie cyberbezpieczeństwa, powinna również sprawdzić zasady wpisu do wykazu KSC.

Regulacja	Główny przedmiot	Typowy podmiot zobowiązany	Co uruchamia analizę
CRA	Bezpieczeństwo produktu z elementami cyfrowymi	Producent produktu	Aktywnie wykorzystywana podatność albo poważny incydent wpływający na produkt
NIS2 i KSC	Bezpieczeństwo organizacji, sieci, systemów i usług	Podmiot kluczowy albo ważny	Incydent spełniający ustawowe kryteria znaczenia
DORA	Odporność cyfrowa sektora finansowego	Podmiot finansowy objęty DORA	Poważny incydent związany z ICT
RODO	Ochrona danych osobowych	Administrator danych	Naruszenie ochrony danych osobowych powodujące określone ryzyko

Przykładowo wykorzystanie podatności w aplikacji może jednocześnie:

• podlegać CRA, ponieważ dotyczy bezpieczeństwa produktu;
• stanowić incydent znaczący według KSC u producenta albo klienta;
• prowadzić do naruszenia poufności danych osobowych wymagającego oceny zgodnie z RODO;
• dotknąć podmiot finansowy i uruchomić procedurę DORA.

Zespół powinien posiadać jedną kartę kwalifikacji, która pozwala równolegle ocenić wszystkie właściwe reżimy. Więcej o obowiązkach organizacyjnych wynikających z NIS2 opisujemy w poradniku Wdrożenie NIS2 krok po kroku.

Organizacje, które łączą rolę producenta z działalnością objętą KSC, mogą uporządkować ten obszar w ramach wdrożenia NIS2. Procedura powinna jednak zachować osobne kryteria kwalifikacji oraz osobne ścieżki raportowania dla CRA i KSC.

Jak przygotować firmę do 11 września 2026 roku?

1. Ustal, czy firma jest producentem

Zmapuj produkty udostępniane pod własną nazwą lub znakiem towarowym. Uwzględnij aplikacje, urządzenia, firmware, biblioteki, płatne wtyczki, bezpłatne wersje wspierające model komercyjny oraz produkty wykonywane przez podwykonawców.

Nie opieraj kwalifikacji na kodzie PKD ani nazwie umowy. Opisz rzeczywisty model: kto definiuje przeznaczenie produktu, kontroluje rozwój i wydania, udostępnia go klientom oraz odpowiada za markę.

2. Zbuduj rejestr produktów i wersji

Rejestr powinien wskazywać co najmniej:

• nazwę i identyfikator produktu;
• aktywne i starsze wersje;
• państwa, w których produkt udostępniono;
• liczbę lub kategorie użytkowników;
• właściciela biznesowego i technicznego;
• okres sprzedaży i wsparcia;
• krytyczne komponenty i usługi zdalne;
• kanały kontaktu z użytkownikami.

Bez takiego rejestru trudno w ciągu 24 godzin określić, czy zdarzenie obejmuje jeden wariant produktu czy klientów w wielu państwach.

3. Uporządkuj komponenty i zależności

Przygotuj wykaz bibliotek, modułów, firmware, systemów operacyjnych, komponentów sprzętowych i usług zewnętrznych używanych w produkcie. Powiąż je z wersjami produktu.

SBOM będzie ważnym elementem pełnego systemu zgodności z CRA. Już teraz jest jednak przede wszystkim narzędziem reagowania. Gdy pojawia się aktywnie wykorzystywana podatność w popularnej bibliotece, producent powinien szybko ustalić, czy jego produkt zawiera podatną wersję i czy dany kod jest osiągalny.

4. Uruchom kanał przyjmowania informacji o podatnościach

Badacz, klient i partner muszą wiedzieć, gdzie zgłosić problem. Producent powinien utrzymywać monitorowany adres bezpieczeństwa albo formularz oraz procedurę coordinated vulnerability disclosure.

Skrzynka sprawdzana raz w tygodniu nie odpowiada terminowi 24 godzin. Potrzebne są dyżury, alerty, zastępstwo i zasada natychmiastowego przekazania wiadomości do zespołu oceniającego.

5. Zdefiniuj kryteria kwalifikacji

Przygotuj krótką kartę decyzyjną obejmującą pytania:

1. Czy zdarzenie dotyczy produktu z elementami cyfrowymi objętego CRA?
2. Czy firma jest producentem tego produktu?
3. Czy istnieją wiarygodne dowody złośliwego wykorzystania podatności?
4. Czy zdarzenie wpływa albo może wpłynąć na poufność, integralność, autentyczność lub dostępność ważnych danych lub funkcji?
5. Czy doszło albo może dojść do wykonania złośliwego kodu?
6. Kiedy organizacja osiągnęła rozsądny stopień pewności co do kwalifikacji?
7. Czy zdarzenie podlega również KSC, DORA albo RODO?

Decyzję i jej podstawę trzeba zapisać. Dotyczy to również sytuacji, w której organizacja uznaje, że zgłoszenie obowiązkowe nie jest wymagane.

6. Wyznacz zespół i zastępstwa

Procedura powinna przypisywać role, a nie tylko nazwy działów. Potrzebne są osoby odpowiedzialne za:

• ocenę techniczną;
• ustalenie zasięgu produktów i wersji;
• decyzję o kwalifikacji prawnej;
• złożenie zgłoszenia w SRP;
• przygotowanie poprawki i działań ograniczających ryzyko;
• komunikację z użytkownikami;
• kontakt z CSIRT i ENISA;
• ocenę równoległych obowiązków NIS2, KSC, DORA i RODO;
• zatwierdzenie komunikacji publicznej.

Każda funkcja powinna mieć zastępcę. Incydenty nie czekają na powrót osoby uprawnionej z urlopu.

7. Przygotuj dane do SRP

Ustal właściwy CSIRT, główne miejsce prowadzenia działalności, dane producenta oraz sposób działania przedstawiciela. Przygotuj osoby z kontem EU Login i prawidłowym umocowaniem.

ENISA aktualizuje instrukcje dotyczące SRP, dlatego przed terminem i przy każdym zgłoszeniu trzeba sprawdzić bieżącą wersję dokumentacji platformy.

8. Przygotuj trzy szablony zgłoszeń

Osobne formularze robocze powinny odpowiadać etapowi 24 godzin, 72 godzin i raportowi końcowemu. Warto dodać pola wskazujące właściciela informacji, źródło danych, poziom pewności i czas ostatniej aktualizacji.

Szablon zmniejsza ryzyko, że w stresie zespół pominie wersję produktu, państwa dystrybucji albo środki dostępne użytkownikom.

9. Zaprojektuj komunikację z użytkownikami

Producent powinien wiedzieć, czy może dotrzeć do użytkowników przez aplikację, panel klienta, wiadomość e-mail, komunikat na stronie, dystrybutora albo bezpośredniego partnera. Lista adresowa nie może powstawać dopiero po incydencie.

Przygotuj warianty komunikatu dla administratora technicznego, użytkownika indywidualnego, dystrybutora i mediów. Treść musi być spójna z raportem do organów, ale dostosowana do odbiorcy.

10. Przeprowadź ćwiczenie 24-godzinne

Ćwiczenie powinno rozpocząć się od wiarygodnej informacji, że popularna biblioteka w produkcie jest aktywnie wykorzystywana. Zespół ma ustalić produkty i wersje, ocenić przesłanki, zebrać dane do wczesnego ostrzeżenia, przygotować działania użytkownika i podjąć decyzję w realnym czasie.

Po ćwiczeniu należy sprawdzić, które informacje były niedostępne, kto nie miał zastępstwa, ile trwało uzyskanie zgody zarządu i czy organizacja potrafiła równolegle ocenić RODO oraz KSC.

Praktyczny scenariusz: podatność w sterowniku IoT

Polska firma sprzedaje pod własną marką sterownik do zarządzania instalacją budynkową. Urządzenie łączy się z siecią lokalną i aplikacją mobilną. Oprogramowanie sterownika zawiera zewnętrzną bibliotekę sieciową.

W poniedziałek o godz. 9:00 producent otrzymuje od klienta logi wskazujące na nietypowe polecenia wykonane na urządzeniu. O godz. 11:30 zespół potwierdza, że podatność biblioteki została wykorzystana bez zgody klienta i umożliwia zdalne wykonanie kodu w określonych wersjach sterownika. W tym momencie producent ma rozsądny stopień pewności co do aktywnej eksploatacji i rozpoczyna się bieg terminu.

Do wtorku, godz. 11:30

Producent przesyła przez SRP wczesne ostrzeżenie. Wskazuje produkt, dotknięte wersje, rodzaj zgłoszenia oraz państwa, w których urządzenie było dystrybuowane. Informuje, że zdarzenie może wynikać z działania złośliwego.

Równolegle firma kontaktuje się z użytkownikami dotkniętych wersji. Zaleca czasowe zablokowanie dostępu z internetu, zmianę danych uwierzytelniających i zastosowanie reguły filtrującej ruch do czasu instalacji aktualizacji.

Do czwartku, godz. 11:30

Producent uzupełnia zgłoszenie. Przekazuje ogólny opis podatności i sposobu ataku, wstępną ocenę skutków, dotychczasowe działania, informacje o konfiguracjach podatnych i instrukcję ograniczenia ryzyka.

Zespół nie czeka na zakończenie całego dochodzenia ani na ustalenie tożsamości atakującego. Dane, których jeszcze nie zna, oznacza jako weryfikowane.

Po udostępnieniu poprawki

Firma publikuje podpisaną aktualizację firmware, instrukcję instalacji i komunikat dla użytkowników. Najpóźniej 14 dni po udostępnieniu środka naprawczego składa raport końcowy opisujący podatność, jej dotkliwość, wpływ i poprawkę.

Ponieważ atak doprowadził także do dostępu do danych identyfikujących użytkowników, administrator równolegle przeprowadza ocenę naruszenia ochrony danych. Jeżeli firma jest podmiotem objętym KSC albo zdarzenie dotyka klienta będącego takim podmiotem, uruchamiane są również właściwe procedury incydentowe.

Gdy incydent produktowy prowadzi również do naruszenia poufności, integralności lub dostępności danych osobowych, pomocne może być wsparcie przy obsłudze naruszenia RODO. Ocena RODO powinna przebiegać równolegle, ponieważ zgłoszenie CRA nie zatrzymuje terminu przewidzianego dla zawiadomienia Prezesa UODO.

Co powinny regulować umowy z dostawcami i partnerami?

Termin 24 godzin jest trudny do zachowania, jeżeli dostawca komponentu może przekazać informację o podatności po kilku dniach. Umowy z dostawcami oprogramowania, firmware, modułów sprzętowych, usług chmurowych i utrzymania powinny określać:

• obowiązek niezwłocznego zgłaszania podatności i incydentów;
• działający całodobowo kanał kontaktowy dla zdarzeń krytycznych;
• informacje przekazywane producentowi, w tym dotknięte wersje i znane wskaźniki kompromitacji;
• zasady współpracy przy analizie wpływu na produkt końcowy;
• czas przygotowania poprawki i obejścia;
• dostęp do informacji o komponentach i zależnościach;
• odpowiedzialność za przygotowanie komunikatów technicznych;
• współpracę przy zgłoszeniach do CSIRT i ENISA;
• zabezpieczenie dowodów oraz logów;
• zasady kontrolowanego ujawnienia podatności;
• aktualizację danych kontaktowych i testowanie eskalacji.

Nie oznacza to, że producent może przenieść odpowiedzialność regulacyjną na dostawcę. Umowa ma zapewnić przepływ informacji potrzebny do wykonania własnego obowiązku.

W sektorze finansowym podobny przegląd należy połączyć z wymaganiami DORA. Praktyczne klauzule i obszary kontroli opisujemy w artykule Jak DORA wpływa na umowy z dostawcami usług ICT?.

Kary za naruszenie Cyber Resilience Act

CRA przewiduje maksymalne poziomy administracyjnych kar pieniężnych, które mają zostać stosowane w krajowym systemie sankcji:

• do 15 mln euro albo, w przypadku przedsiębiorstwa, do 2,5 proc. całkowitego światowego rocznego obrotu za poprzedni rok obrotowy za naruszenie zasadniczych wymagań cyberbezpieczeństwa;
• do 10 mln euro albo do 2 proc. światowego rocznego obrotu za naruszenie innych obowiązków wynikających z rozporządzenia;
• do 5 mln euro albo do 1 proc. światowego rocznego obrotu za przekazanie jednostkom notyfikowanym lub organom nadzoru rynku nieprawidłowych, niekompletnych albo wprowadzających w błąd informacji.

W odniesieniu do przedsiębiorstwa zastosowanie ma wyższa z możliwych wartości maksymalnych. Ostateczna sankcja powinna uwzględniać okoliczności naruszenia, w tym jego charakter, czas trwania, skutki, działania naprawcze i współpracę z organami.

Rozporządzenie przewiduje szczególną zasadę dla producentów będących mikroprzedsiębiorstwami lub małymi przedsiębiorstwami: administracyjnych kar pieniężnych nie stosuje się wobec nich za niedochowanie 24-godzinnego terminu wczesnego ostrzeżenia. Nie zwalnia ich to jednak z obowiązku raportowania, złożenia kolejnych informacji, powiadomienia użytkowników ani realizacji pozostałych wymagań. Opiekunowie oprogramowania open source nie podlegają administracyjnym karom pieniężnym za naruszenia CRA, ale nadal mogą podlegać działaniom nadzorczym i obowiązkom naprawczym.

Najczęstsze błędy przed 11 września 2026 roku

Traktowanie CRA jako tematu na grudzień 2027 roku

Firma planuje rozpocząć prace dopiero przed pełnym stosowaniem rozporządzenia i pomija wcześniejszy obowiązek raportowania.

Założenie, że producentem jest wyłącznie fabryka

Spółka sprzedaje aplikację albo urządzenie pod własną marką, ale uważa, że odpowiada wyłącznie podwykonawca piszący kod lub montujący sprzęt.

Raportowanie każdej podatności bez kwalifikacji

Zespół uznaje każdy numer CVE za obowiązkowe zgłoszenie, zamiast ocenić aktywne wykorzystanie, obecność podatności i możliwość jej wykorzystania w konkretnym produkcie.

Czekanie na pełną analizę powłamaniową

Organizacja ma wystarczające informacje do wczesnego ostrzeżenia, ale wstrzymuje zgłoszenie do czasu ustalenia wszystkich szczegółów i sprawcy.

Brak wiedzy o komponentach

Producent nie potrafi określić, które wersje produktu zawierają podatną bibliotekę, ponieważ zależności nie są powiązane z wydaniami.

Skrzynka bezpieczeństwa bez dyżuru

Informacja od badacza trafia w piątek wieczorem na adres sprawdzany w dni robocze i zostaje odczytana po upływie terminu.

Brak komunikacji z użytkownikami

Firma składa zgłoszenie do SRP, ale nie posiada listy klientów, kanału powiadomień ani gotowej instrukcji ograniczenia ryzyka.

Jedna procedura dla wszystkich regulacji bez osobnych kryteriów

Zespół zakłada, że zgłoszenie zgodnie z RODO albo KSC automatycznie realizuje również CRA.

Pominięcie starszych produktów

Rejestr obejmuje wyłącznie bieżącą ofertę, chociaż obowiązek raportowania może dotyczyć także wersji nadal używanych przez klientów.

Checklista gotowości do raportowania CRA

Obszar	Czynność	Dowód wykonania
Kwalifikacja	Ustal, które spółki i produkty podlegają CRA	Notatka kwalifikacyjna
Role	Wskaż producenta, importera, dystrybutora i przedstawiciela	Mapa ról w łańcuchu dostaw
Produkty	Utwórz rejestr produktów, wersji i państw dystrybucji	Aktualny rejestr produktów
Komponenty	Powiąż biblioteki, firmware i moduły z wersjami produktów	SBOM lub mapa zależności
Monitoring	Uruchom kanał przyjmowania i monitorowania zgłoszeń	Polityka CVD i działający kontakt
Kwalifikacja zdarzeń	Zdefiniuj aktywną eksploatację i poważny incydent	Karta decyzyjna CRA
Eskalacja	Zapewnij dyżur, zastępstwa i ścieżkę decyzyjną	Macierz RACI i lista kontaktowa
Platforma	Przygotuj EU Login, umocowanie i dane do SRP	Instrukcja raportowania
Zgłoszenia	Przygotuj formularze 24 h, 72 h i raportu końcowego	Zatwierdzone szablony
Użytkownicy	Ustal kanały powiadamiania i środki ograniczające ryzyko	Szablony komunikatów
Umowy	Dodaj szybkie zgłaszanie i współpracę dostawców	Zaktualizowane klauzule
Współistnienie regulacji	Połącz ocenę CRA z KSC, DORA i RODO	Wieloreżimowa karta kwalifikacji
Test	Przeprowadź ćwiczenie obejmujące pierwsze 24 godziny	Raport z testu i plan działań

Podsumowanie

Od 11 września 2026 roku Cyber Resilience Act staje się obowiązkiem operacyjnym dla producentów produktów z elementami cyfrowymi. Nie jest to jeszcze pełne stosowanie rozporządzenia, ale zaczynają obowiązywać krótkie terminy zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.

Producent powinien potrafić wysłać wczesne ostrzeżenie w ciągu 24 godzin, uzupełnić informacje w ciągu 72 godzin, złożyć raport końcowy i terminowo ostrzec użytkowników. Obowiązek obejmuje także produkty udostępnione na rynku przed grudniem 2027 roku.

Największym problemem nie będzie samo wypełnienie formularza. Trudność polega na szybkim ustaleniu, czy firma jest producentem, które produkty i wersje są dotknięte, czy podatność jest rzeczywiście wykorzystywana, jakie działania mogą podjąć użytkownicy oraz czy zdarzenie podlega także KSC, DORA albo RODO.

Przygotowanie powinno więc objąć rejestr produktów, mapę komponentów, całodobowy kanał zgłoszeń, kryteria kwalifikacji, zespół z zastępstwami, szablony raportów, komunikację z użytkownikami i ćwiczenie 24-godzinne. Organizacja, która rozpocznie te prace dopiero po pierwszym incydencie, będzie podejmowała decyzje pod presją biegnącego terminu.

Dzielimy się wiedzą

Cyberbezpieczeństwo produktu nie kończy się w dziale IT. Wymaga współpracy zespołów rozwoju, product security, sprzedaży, obsługi klienta, prawa, compliance i komunikacji. Dlatego materiał można wykorzystać jako punkt wyjścia do wewnętrznego przeglądu lub ćwiczenia incydentowego. Jeżeli artykuł może pomóc producentowi, dostawcy oprogramowania albo partnerowi w łańcuchu dostaw, zachęcamy do jego udostępnienia.

Chcesz przygotować produkty i procedurę zgłoszeń do wymagań CRA?

BPPZ wspiera organizacje w kwalifikacji produktów i ról, projektowaniu procedur raportowania, przeglądzie umów z dostawcami oraz łączeniu obowiązków CRA z NIS2, KSC i RODO. Zakres prac powinien być dopasowany do rzeczywistego modelu produktu, architektury, łańcucha dostaw i sposobu reagowania na podatności.

FAQ

Źródła

1. Rozporządzenie Parlamentu Europejskiego i Rady – (UE) 2024/2847 z 23 października 2024 r. EUR-Lex.
2. Cyber Resilience Act, Komisja Europejska, – aktualizacja 27 lipca 2026 r.
3. The Cyber Resilience Act – Summary of the legislative text, Komisja Europejska
4. Frequently Asked Questions on the CRA Single Reporting Platform – ENISA, aktualizacja 3 sierpnia 2026 r.
5. CRA SRP guidance – Assigned Representative User Registration, ENISA, aktualizacja 3 sierpnia 2026 r.
6. Rozporządzenie wykonawcze Komisji – (UE) 2025/2392 w sprawie technicznego opisu kategorii ważnych i krytycznych produktów z elementami cyfrowymi