CRA od 11 września 2026: raportowanie podatności w 24 godziny, kto zgłasza i jak

Czas czytania: około 8 minut

Spis treści

1. Co dokładnie zaczyna obowiązywać 11 września
2. Trzy zegary: 24 h, 72 h, 14 dni albo miesiąc
3. Kto podlega obowiązkowi
4. CRA a NIS2: dwie role, dwa komplety obowiązków
5. Jak przebiega zgłoszenie i do kogo trafia
6. Co zrobić przed 11 września
7. Częsty błąd: mylenie zegara zgłoszeniowego z pełnym CRA
8. FAQ

Odpowiedź najpierw

Od 11 września 2026 producent produktu z elementami cyfrowymi ma obowiązek zgłaszać aktywnie wykorzystywane podatności i poważne incydenty w trybie trzech zegarów: wczesne ostrzeżenie w ciągu 24 godzin, pełne zgłoszenie w ciągu 72 godzin, a raport końcowy w ciągu 14 dni od udostępnienia poprawki dla podatności lub w ciągu miesiąca dla incydentu. Zgłaszasz raz, przez jedną platformę (CRA Single Reporting Platform), do właściwego CSIRT, a informacja trafia równocześnie do ENISA. To pierwszy termin CRA, który realnie zaczyna działać. Pełne obowiązki produktowe aktu wchodzą dopiero 11 grudnia 2027. Jeśli wprowadzasz do obrotu sprzęt lub oprogramowanie z elementami cyfrowymi, ten zegar dotyczy cię niezależnie od tego, czy podlegasz NIS2.

Co dokładnie zaczyna obowiązywać 11 września

CRA, czyli akt o cyberodporności (Cyber Resilience Act), wchodzi etapami. Większość obowiązków produktowych, jak wymagania bezpieczeństwa w cyklu życia, dokumentacja techniczna czy oznaczenie CE dla elementów cyfrowych, zaczyna obowiązywać 11 grudnia 2027. Ale jeden blok rusza wcześniej i to on jest tematem tej notatki: obowiązek raportowania.

Od 11 września 2026 producent ma zgłaszać dwie rzeczy. Pierwsza to aktywnie wykorzystywana podatność w produkcie z elementami cyfrowymi, czyli taka, wobec której istnieje dowód, że ktoś ją realnie wykorzystuje, a nie sama teoretyczna możliwość. Druga to poważny incydent mający wpływ na bezpieczeństwo produktu. Oba zdarzenia uruchamiają ten sam wieloetapowy tryb zgłoszeniowy z twardymi terminami liczonymi w godzinach.

To ważne rozróżnienie, bo termin wrześniowy nie oznacza, że od tego dnia trzeba mieć domknięty cały CRA. Oznacza, że od tego dnia trzeba umieć wykryć kwalifikujące się zdarzenie i zgłosić je w wymaganym czasie. Zdolność zgłoszeniowa jest więc obowiązkiem, który wyprzedza resztę aktu o ponad rok.

Trzy zegary: 24 h, 72 h, 14 dni albo miesiąc

Zgłoszenie nie jest jednym dokumentem, tylko sekwencją. Licznik startuje w momencie, w którym producent dowiaduje się o zdarzeniu.

Wczesne ostrzeżenie: 24 godziny. W ciągu doby od powzięcia wiedzy o aktywnie wykorzystywanej podatności lub poważnym incydencie producent składa wstępne powiadomienie. Na tym etapie nie chodzi o pełną analizę, tylko o sygnał: co się dzieje, jakiego produktu dotyczy, czy zdarzenie jest wykorzystywane.

Pełne zgłoszenie: 72 godziny. W ciągu trzech dób od powzięcia wiedzy producent uzupełnia zgłoszenie o właściwą treść: charakter podatności lub incydentu, dotychczasową ocenę, podjęte i planowane środki zaradcze.

Raport końcowy: 14 dni albo miesiąc. Dla aktywnie wykorzystywanej podatności raport końcowy składa się nie później niż 14 dni po udostępnieniu środka naprawczego, czyli poprawki lub obejścia. Dla poważnego incydentu termin jest inny: raport końcowy w ciągu miesiąca od zgłoszenia z 72 godzin. Ta różnica bywa gubiona, bo notatki branżowe często podają tylko regułę 14 dni. Przy incydencie zegar końcowy jest dłuższy.

Trzy zegary znaczą jedno w praktyce: procedura reagowania musi umieć rozpoznać, że zdarzenie kwalifikuje się pod CRA, i uruchomić zgłoszenie w godzinach, a nie w tygodniach. Doba to mało czasu, jeśli decyzja o zgłoszeniu wymaga eskalacji przez kilka osób, których nie ma w procedurze.

Kto podlega obowiązkowi

Adresatem jest producent produktu z elementami cyfrowymi, czyli podmiot, który wprowadza taki produkt do obrotu pod własną nazwą lub znakiem. Produkt z elementami cyfrowymi to szeroka kategoria: oprogramowanie, ale też sprzęt zawierający oprogramowanie lub komponent łączności. Producent maszyny ze sterownikiem, urządzenia z firmware, komponentu z modułem sieciowym czy aplikacji sprzedawanej osobno mieści się w tej definicji.

Dla firm wdrażających AI to istotne z dwóch stron. Jeśli sam wytwarzasz produkt, w którym siedzi model lub oprogramowanie, jesteś producentem w rozumieniu CRA. Jeśli tylko używasz cudzego rozwiązania, obowiązek zgłoszeniowy CRA leży po stronie jego producenta, ale twoja umowa i twój łańcuch dostaw powinny to odzwierciedlać, bo incydent u dostawcy może uruchomić twoje własne zegary z innych reżimów.

CRA a NIS2: dwie role, dwa komplety obowiązków

Najczęstsze nieporozumienie brzmi: skoro raportuję już incydenty w NIS2, to CRA nic nie zmienia. Zmienia, bo oba akty patrzą na tę samą firmę w innej roli.

NIS2 traktuje cię jako podmiot, który używa systemów i świadczy usługi, i pyta o zgłaszanie incydentów wpływających na te usługi, do CSIRT. CRA traktuje cię jako producenta, który wprowadza produkt do obrotu, i pyta o zgłaszanie podatności i incydentów w tym produkcie. Ta sama spółka może podlegać obu, w dwóch różnych rolach, z dwoma osobnymi kompletami obowiązków i dwoma osobnymi zegarami.

Jeden incydent potrafi uruchomić kilka liczników naraz: NIS2 wobec CSIRT, CRA wobec CSIRT i ENISA, a przy naruszeniu danych osobowych także RODO wobec organu nadzorczego. Terminy i adresaci są różne, więc procedura incydentowa musi je rozgałęziać, zamiast zakładać, że jedno zgłoszenie załatwia wszystko. Rozpisujemy tę logikę szerzej w cross-mappingu NIS2, AI Act, RODO i ISO 27001, gdzie CRA jest piątą kolumną tej samej macierzy.

Jak przebiega zgłoszenie i do kogo trafia

CRA porządkuje kanał zgłoszeniowy, zamiast mnożyć okienka. Producent zgłasza raz, przez jedną platformę, tak zwaną CRA Single Reporting Platform. Zgłoszenie trafia do właściwego CSIRT, wyznaczonego jako koordynator w państwie, w którym producent ma główną siedzibę, a informacja jest równocześnie udostępniana ENISA. Jeśli produkt był udostępniony na terenie innych państw, przyjmujący CSIRT bez zbędnej zwłoki dzieli się zgłoszeniem z pozostałymi właściwymi zespołami.

Praktyczny wniosek jest taki, że zdolność zgłoszeniowa opiera się na tym, co i tak powinno działać: na wykrywaniu i na logach. Bez telemetrii, która pokazuje, że podatność jest wykorzystywana, albo że produkt zachowuje się nietypowo, zegar 24 godzin startuje za późno lub wcale. To ten sam fundament, który obsługuje obowiązki logowania z NIS2 i ISO. Co konkretnie zapisywać w systemie AI uruchomionym lokalnie, rozkładamy w notatce o observability dla on-prem LLM.

Co zrobić przed 11 września

Do wejścia obowiązku zostało niewiele czasu, a przygotowanie nie jest projektem na kwartał, jeśli masz już zręby reagowania na incydenty. Sensowna kolejność jest taka.

Po pierwsze, ustal, czy jesteś producentem w rozumieniu CRA i dla których produktów. Bez tej mapy nie wiesz, których zdarzeń zegar dotyczy.

Po drugie, wpisz CRA do istniejącej procedury incydentowej jako osobną gałąź z własnymi terminami i adresatem, a nie jako wariant zgłoszenia NIS2. Zdefiniuj wprost, kto podejmuje decyzję o zgłoszeniu i kto ma dostęp do platformy, żeby doba nie uciekała na ustalanie właściciela.

Po trzecie, sprawdź, czy twoje wykrywanie i logi w ogóle pozwalają stwierdzić, że podatność jest aktywnie wykorzystywana. To najczęstsza luka: obowiązek jest, a sygnał, który go uruchamia, nie dociera do właściwej osoby na czas.

Po czwarte, przećwicz jedno zgłoszenie na sucho. Symulacja pokazuje, gdzie 24 godziny pękają, zanim zrobi to prawdziwy incydent. Więcej o tym, jakie dowody i dokumenty warto mieć gotowe przed audytorem i regulatorem, jest w audit readiness dla NIS2 plus AI.

Częsty błąd: mylenie zegara zgłoszeniowego z pełnym CRA

Warto rozdzielić dwie daty, bo ich pomieszanie prowadzi albo do paniki, albo do uśpienia. 11 września 2026 to start obowiązku raportowania, nie całego aktu. 11 grudnia 2027 to start pełnych obowiązków produktowych, w tym wymagań bezpieczeństwa, dokumentacji technicznej i oceny zgodności.

Uśpienie wygląda tak: skoro pełny CRA jest dopiero za rok z okładem, można poczekać. Nie można, bo zegar zgłoszeniowy działa od września i nie czeka na resztę aktu. Panika wygląda odwrotnie: skoro CRA rusza we wrześniu, trzeba mieć wszystko domknięte na ten dzień. Nie trzeba, bo obowiązki produktowe mają własny, późniejszy termin. Na wrzesień potrzebujesz działającej zdolności zgłoszeniowej, nie kompletnej zgodności produktowej.

FAQ

Od kiedy dokładnie obowiązuje raportowanie w CRA? Od 11 września 2026 dla aktywnie wykorzystywanych podatności i poważnych incydentów. Pełne obowiązki produktowe CRA zaczynają obowiązywać 11 grudnia 2027.

Jakie są terminy zgłoszenia? Wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiedzy, pełne zgłoszenie w ciągu 72 godzin, a raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego dla podatności lub w ciągu miesiąca dla poważnego incydentu.

Do kogo składa się zgłoszenie? Raz, przez CRA Single Reporting Platform. Zgłoszenie trafia do właściwego CSIRT w państwie głównej siedziby producenta, a informacja jest równocześnie udostępniana ENISA.

Czym różni się to od raportowania w NIS2? Rolą. NIS2 widzi cię jako podmiot używający systemów i świadczący usługi, CRA jako producenta wprowadzającego produkt do obrotu. Ta sama firma może podlegać obu, w dwóch rolach, z osobnymi terminami i adresatami.

Czy dotyczy mnie, jeśli tylko używam cudzego AI, a nie wytwarzam produktu? Obowiązek zgłoszeniowy CRA leży po stronie producenta produktu z elementami cyfrowymi. Jeśli jesteś wyłącznie użytkownikiem cudzego rozwiązania, ten konkretny zegar cię nie uruchamia, ale incydent u dostawcy może uruchomić twoje obowiązki z innych reżimów, więc umowa i procedura powinny to obejmować.

Co muszę mieć gotowe na 11 września? Działającą zdolność zgłoszeniową: wiedzę, które produkty czynią cię producentem, procedurę incydentową z osobną gałęzią CRA, wyznaczonego decydenta i dostęp do platformy oraz wykrywanie i logi, które w ogóle pozwalają zauważyć kwalifikujące się zdarzenie.

// co tu nie pokrywamCzego tu nie pokrywam

Nie omawiam pełnych obowiązków produktowych CRA, które wchodzą 11 grudnia 2027, bo to materiał na osobny tekst. Nie wchodzę w progi i definicje poważnego incydentu w szczegółach ani w operacyjną warstwę samej platformy zgłoszeniowej. Pomijam sektorowe reżimy nakładające własne zegary, jak DORA dla łańcucha finansowego. Nie podaję też mapowania kontroli CRA na pozostałe akty, bo prowadzimy je w osobnej macierzy zgodności.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad wdrożeniami AI uruchamianymi poza chmurą publiczną, więc naturalnie akcentuję kontrolę nad przepływem danych, wykrywanie i możliwość zaudytowania zależności. Starałem się oddzielić treść przepisów od tej preferencji architektonicznej. Ten tekst nie jest opinią prawną. Praktyka stosowania CRA dopiero się kształtuje, a szczegóły proceduralne, w tym działanie platformy zgłoszeniowej, będą doprecyzowywane przez akty wykonawcze i wytyczne. Przed decyzjami compliance skonsultuj się z prawnikiem specjalizującym się w cyberbezpieczeństwie.

Następny krok

Jeśli chcesz zobaczyć, jak CRA zazębia się z NIS2, AI Act, RODO i ISO 27001 bez robienia tej samej pracy pięć razy, przeczytaj Cross-mapping NIS2, AI Act, RODO, ISO 27001 bez dublowania, gdzie CRA wchodzi jako piąty reżim tej samej macierzy.

Powiązane

• Cross-mapping NIS2, AI Act, RODO i ISO 27001 bez dublowania
• Art. 50 AI Act od 2 sierpnia 2026: co obowiązuje przy własnym LLM
• Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem
• Monitoring i observability dla on-prem LLM: co logować i jak
• NIS2 plus AI: mapowanie Art. 21 na konkretne kontrole, jedna ściąga

Źródła

• Komisja Europejska, CRA reporting obligations, potwierdza terminy 24 h, 72 h, 14 dni i miesiąc oraz kanał zgłoszeniowy do CSIRT i ENISA.
• Jones Day, EU Cyber Resilience Act: 24-Hour Reporting Duties Start September 11, 2026.
• Crowell & Moring, September 11, 2026 Reporting Deadline.
• DLA Piper, The CRA's 24-Hour Rule.

Fryderyk Pryjma. Zajmuje się wdrożeniami AI on-prem dla europejskiej produkcji i pisze o styku architektury, compliance i regulacji.