Od 11 września 2026 r. producenci CRA muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty przez platformę ENISA Single Reporting Platform. Ten przewodnik wyjaśnia, co uruchamia zgłoszenie, jak działają terminy 24h, 72h, 14 dni i 1 miesiąca oraz gdzie w tym procesie mieszczą się CVD, VEX i informowanie użytkowników.
Podsumowanie
- Pilne zgłaszanie zaczyna się 11 września 2026 r.: oba strumienie używają ostrzeżenia 24h i powiadomienia 72h; raport końcowy jest składany 14 dni po udostępnieniu środka korygującego lub ograniczającego ryzyko dla podatności oraz w ciągu 1 miesiąca po powiadomieniu 72h dla poważnych incydentów.
- Wyślij raz przez ENISA SRP: platforma kieruje zgłoszenie do koordynującego CSIRT i udostępnia je ENISA.
- Aktywne wykorzystanie wymaga wiarygodnych dowodów, że złośliwy podmiot wykorzystał podatność w systemie bez upoważnienia; publiczne ujawnienie, publiczna PoC lub demonstracja badacza same nie wystarczą.
- Polityka CVD jest obowiązkowa: pisemna, opublikowana, stosowana i połączona z progiem zgłaszania, gdy triage wykryje aktywne wykorzystanie.
- VEX wspiera decyzje o zgłoszeniu, dokumentując, czy CVE w komponencie SBOM rzeczywiście wpływa na produkt.
- Szczegóły kar należą do przewodnika egzekwowania: spóźnione lub brakujące zgłoszenia mogą stworzyć poważne ryzyko sankcji; poziomy i wyjątki dla MŚP są w karach i egzekwowaniu CRA.
Model zgłaszania w praktyce: ostrzeżenie, szczegółowe powiadomienie, raport końcowy i odesłanie do egzekwowania.
Co trzeba zgłaszać
Zgłaszanie CRA ma dwa obowiązkowe strumienie zdarzeń i osobny obowiązek informowania użytkowników. Obowiązek spoczywa na producencie produktu z elementami cyfrowymi na rynku UE:
- Zgłaszaj każdą aktywnie wykorzystywaną podatność w produkcie do koordynującego CSIRT i ENISA według cyklu 24h / 72h / 14d.
- Zgłaszaj każdy poważny incydent wpływający na bezpieczeństwo produktu według cyklu 24h / 72h / 1 miesiąc.
- Informuj dotkniętych użytkowników o podatności lub incydencie oraz środkach korygujących bez zbędnej zwłoki.
Ta strona obejmuje także dwie powiązane kontrole: obowiązkową politykę CVD oraz dowody zastosowania, takie jak VEX. Żaden z tych obowiązków nie ma progu wielkości. Mikroprzedsiębiorstwa i małe przedsiębiorstwa mają tylko wąskie złagodzenie kar za ostrzeżenie 24h; nie są zwolnione ze zgłaszania.
Platforma ENISA Single Reporting Platform (SRP)
SRP jest jedynym kanałem obowiązkowych zgłoszeń CRA dotyczących podatności i incydentów. Producent zgłasza raz przez elektroniczny punkt koordynującego CSIRT; zgłoszenie jest jednocześnie dostępne dla ENISA, chyba że zastosowano wyjątkowy mechanizm opóźnionego rozpowszechniania. Koordynujący CSIRT przekazuje następnie informacje właściwym CSIRT w innych państwach członkowskich.
Status w czerwcu 2026 r.: SRP ma działać najpóźniej 11 września 2026 r., z wcześniejszym okresem testowym. ENISA zapowiedziała, że instrukcje dostępu i rejestracji oraz materiały szkoleniowe i wsparcie dry-run udostępni w czerwcu 2026 r., więc mechanizm rejestracji jest wciąż w trakcie publikacji. ENISA informuje ponadto, że na tym etapie nie przewiduje API SRP. Gotowość do zgłaszania należy planować wokół składania zgłoszeń bezpośrednio przez platformę, a nie przez automatyzację API. Mechanizm rejestracji opisuje onboarding ENISA SRP. Śledź stronę Komisji o zgłaszaniu CRA i stronę ENISA SRP, zanim oprzesz proces na konkretnym kroku rejestracji.
Terminy zgłaszania w szczegółach
Harmonogram zgłaszania
| Krok | Podatność | Poważny incydent | Punkt startowy |
|---|---|---|---|
| Wczesne ostrzeżenie | 24 godziny | 24 godziny | Producent uzyskuje wiedzę |
| Szczegółowe powiadomienie | 72 godziny | 72 godziny | Producent uzyskuje wiedzę |
| Raport końcowy | 14 dni po udostępnieniu środka korygującego lub ograniczającego ryzyko | 1 miesiąc po zgłoszeniu incydentu 72h | Różne kotwice |
| Informacja dla użytkowników | Bez zbędnej zwłoki | Bez zbędnej zwłoki | Informacja dla użytkowników |
Co zawiera każde zgłoszenie
Wczesne ostrzeżenie jest ostrzeżeniem, a nie pełną analizą. Powiadomienie 72h daje ogólne informacje o produkcie, exploicie lub incydencie, podjętych środkach, działaniach użytkowników i wrażliwości, gdy ma to znaczenie. Raport końcowy zawiera co najmniej dane wymagane dla danego strumienia: opis podatności, wagę, wpływ i środki korygujące albo opis incydentu, prawdopodobną przyczynę i trwające działania.
- Producent uzyskuje wiedzę. Zegar 24h startuje, gdy producent ma wiarygodne dowody aktywnego wykorzystania.
- +24h. Wyślij wczesne ostrzeżenie przez ENISA SRP.
- +72h. Dodaj szczegóły techniczne, dotknięte wersje, status wykorzystania i status naprawy.
- Środek dostępny. Dla podatności zegar raportu końcowego zaczyna się tutaj, nie przy wykryciu.
- +14d. Wyślij końcowe dane dla strumienia podatności lub incydentu.
Poważne incydenty przechodzą przez te same kroki wstępne (ostrzeżenie 24h i powiadomienie 72h); raport końcowy jest składany w ciągu 1 miesiąca po powiadomieniu 72h.
Pola danych w szablonie zgłoszeń SRP
Dokument FAQ ENISA dotyczący SRP (Q16) wskazuje pola oczekiwane na każdym etapie zgłoszenia. ENISA przedstawia je jako pola, które będą obowiązkowe (bezpośrednio z rozporządzenia lub jako logiczna konsekwencja jego wymogów) albo opcjonalne, dlatego należy traktować je jako wstępne do czasu ostatecznego uruchomienia platformy. Kody: X obowiązkowe, O opcjonalne, C skopiowane z poprzedniego etapu domyślnie lub zaktualizowane, A automatyczne (niewidoczne dla składającego), I obowiązkowe, jeśli informacja jest dostępna.
| # | Pole | 24h | 72h | Końcowy |
|---|---|---|---|---|
| Pola wspólne | ||||
| 1 | Typ powiadomienia (podatność / incydent) | X | C | C |
| 2 | Poziom powiadomienia (24h / 72h / końcowy) | X | X | X |
| 3 | Czas zgłoszenia, 24h | A | A | A |
| 4 | Czas zgłoszenia, 72h | A | A | A |
| 5 | Czas zgłoszenia, końcowy | A | A | A |
| 6 | Zgłaszający | A | A | A |
| 7 | Producent | X | C | C |
| 8 | Produkt | X | C | C |
| 9 | Typ produktu (domyślny / istotny / krytyczny) | O | C | C |
| 10 | Kategoria produktu (jeśli typ to istotny lub krytyczny) | O | C | C |
| 11 | Państwa członkowskie, w których produkt jest dostępny | I | C | C |
| 12 | Tytuł | X | C | C |
| Podatność | ||||
| v13 | CVE ID | O | C | C |
| v14 | EUVD ID | O | C | C |
| v15 | Informacje ogólne, w szczególności: | O | X | C |
| v16 | a. Ogólny charakter podatności | O | X | C |
| v17 | b. Ogólny charakter exploita | O | X | C |
| v18 | Podjęte środki korygujące lub ograniczające ryzyko | O | X | C |
| v19 | Środki korygujące lub ograniczające ryzyko, jakie mogą podjąć użytkownicy | O | X | C |
| v20 | Ocena wrażliwości informacji | O | I | C |
| v21 | Data udostępnienia środka korygującego lub ograniczającego ryzyko | O | O | X |
| v22 | Pełny opis podatności, w tym: | O | O | X |
| v23 | a. Waga podatności | O | O | X |
| v24 | b. Wpływ podatności | O | O | X |
| v25 | Złośliwy podmiot, który ją wykorzystał lub wykorzystuje | O | O | I |
| v26 | Szczegóły aktualizacji zabezpieczeń / środków korygujących | O | O | X |
| Incydent | ||||
| i13 | Incydent podejrzewany jako skutek działań niezgodnych z prawem lub złośliwych | X | C | C |
| i14 | Informacje ogólne o charakterze incydentu | O | X | C |
| i15 | Data i godzina wykrycia incydentu | O | X | C |
| i16 | Data i godzina wystąpienia incydentu | O | X | C |
| i17 | Wstępna ocena incydentu | O | X | C |
| i18 | Podjęte środki korygujące lub ograniczające ryzyko | O | X | C |
| i19 | Środki korygujące lub ograniczające ryzyko, jakie mogą podjąć użytkownicy | O | X | C |
| i20 | Ocena wrażliwości informacji | O | I | C |
| Szczegółowy opis incydentu, w tym: | O | O | X | |
| i21 | a. Waga incydentu (kryteria poniżej) | O | O | X |
| i23 | b. Wpływ incydentu | O | O | X |
| i24 | Rodzaj zagrożenia lub prawdopodobna przyczyna źródłowa | O | O | X |
| i25 | Zastosowane i bieżące środki ograniczające ryzyko | O | O | X |
Kryteria wagi (i22): poważny incydent to incydent, który (1) negatywnie wpływa lub może negatywnie wpływać na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo istotnych danych bądź funkcji, albo (2) doprowadził lub może doprowadzić do wprowadzenia lub uruchomienia złośliwego kodu w produkcie bądź w sieci i systemach informatycznych użytkownika.
Źródło: FAQ ENISA SRP, Q16.
Co uruchamia obowiązek zgłoszenia
1. Aktywnie wykorzystywane podatności
Aktywnie wykorzystywana podatność oznacza, że istnieją wiarygodne dowody, iż złośliwy podmiot wykorzystał podatność w systemie bez upoważnienia i producent uzyskał o tym wiedzę. Publiczna PoC lub demonstracja badacza sama nie wystarcza.
2. Poważne incydenty
Poważny incydent podlega zgłoszeniu, gdy wpływa lub może wpływać na ochronę przez produkt dostępności, autentyczności, integralności lub poufności wrażliwych lub ważnych danych lub funkcji, albo gdy prowadzi lub może prowadzić do wprowadzenia lub uruchomienia złośliwego kodu w produkcie lub w sieci i systemach informatycznych użytkownika.
Scenariusze zgłaszane i niezgłaszane
| Scenariusz | Obowiązek zgłoszenia? | Dlaczego |
|---|---|---|
| Prywatny raport badacza | Nie | Brak dowodu wykorzystania; obsłuż przez CVD |
| Publiczna PoC | Nie | Publikacja nie jest wykorzystaniem |
| Klient zgłasza aktywność pasującą do wykorzystania | Oceń | Zgłoś, jeśli dowody są wiarygodne |
| Wykorzystanie zaobserwowane w środowisku rzeczywistym | Tak | Wiarygodny dowód złośliwego użycia |
| Komponent SBOM ze znaną wykorzystywaną CVE | Oceń | Tylko jeśli produkt jest rzeczywiście dotknięty |
Wiedza i dowody
Definicja CRA wymaga wiarygodnych dowodów, nie pewności forensycznej. Jeśli dowody nie są jeszcze wiarygodne, zdarzenie pozostaje w triage CVD lub incydentu; gdy stają się wiarygodne, 24-godzinny termin biegnie od uzyskania wiedzy przez producenta.
Przyjmowanie CVD i bramka zgłoszenia
Polityka CVD jest kanałem, który zmienia zewnętrzne raporty w ustrukturyzowany triage. Gdy triage daje wiarygodne dowody aktywnego wykorzystania, pilne zgłaszanie biegnie równolegle z naprawą i skoordynowanym ujawnieniem. Publiczna strona CVD i security.txt w /.well-known/security.txt to praktyczny sposób, aby kontakt był łatwy do znalezienia.
VEX i zastosowanie podatności
VEX nie jest wymagany z nazwy, ale rejestr zastosowania jest bardzo przydatny. Dokumentuje, czy CVE w komponencie SBOM ma status not_affected, affected, fixed albo under_investigation dla konkretnej wersji produktu. Zobacz przewodnik VEX.
Ulga dla małych producentów
Mikroprzedsiębiorstwa i małe przedsiębiorstwa (definiowane jako mniej niż 50 pracowników oraz roczny obrót lub suma bilansowa do 10 mln EUR; mikroprzedsiębiorstwa: mniej niż 10 pracowników, do 2 mln EUR) mają wąską ulgę od kar administracyjnych wyłącznie za pominięcie pierwszego ostrzeżenia 24h. Ulga nie usuwa obowiązku zgłoszenia i nie obejmuje powiadomienia 72h ani raportów końcowych. Średnie przedsiębiorstwa nie mają takiej ulgi. Pełną strukturę kar opisuje przewodnik kary i egzekwowanie CRA.
Typowe błędy
- Czekanie na pewność forensyczną. Wystarczą wiarygodne dowody; zakończone dochodzenie forensyczne nie jest wymagane przed wczesnym ostrzeżeniem.
- Mieszanie CVD i pilnego zgłaszania. Raport badacza to intake CVD; zgłaszanie CRA zaczyna się od wiarygodnych dowodów aktywnego wykorzystania.
- Jedna osoba eskalacyjna. Zegar 24h nie zatrzymuje się na weekend.
- Brak opublikowanej polityki CVD. Dokument wewnętrzny nie wystarcza.
- Brak decyzji o zastosowaniu. Bez VEX lub odpowiednika trudno obronić, dlaczego CVE nie wpływa na produkt.
- Traktowanie SRP jako przyszłego problemu. Szablony, dyżury i relacje z CSIRT są potrzebne przed wrześniem 2026 r.
Najczęściej zadawane pytania
Kiedy zaczynają się obowiązki zgłaszania CRA?
Obowiązkowe zgłaszanie podatności i incydentów w CRA zaczyna się 11 września 2026 r. Od tej daty producenci muszą używać ENISA SRP do ostrzeżeń 24h, powiadomień 72h i raportów końcowych. Szersze wymagania produktowe obowiązują od 11 grudnia 2027 r.
Czym jest ENISA SRP?
SRP jest wspólnym kanałem obowiązkowych zgłoszeń CRA i dobrowolnych zgłoszeń; ENISA informuje, że funkcja dobrowolnych zgłoszeń zostanie uruchomiona po 11 września 2026 r. Śledź stronę Komisji i stronę ENISA SRP w sprawie szczegółów rejestracji.
Czy polityka CVD jest obowiązkowa?
Tak. Każdy producent potrzebuje polityki CVD i praktycznego kanału przyjmowania zgłoszeń. security.txt nie jest wymieniony w CRA, ale jest praktycznym sposobem publikacji adresu kontaktowego.
Czy potrzebny jest VEX?
VEX nie jest wymagany z nazwy, ale rejestr zastosowania jest bardzo przydatny do uzasadnienia, dlaczego znane CVE nie wpływa na produkt.
Jakie kary obowiązują?
Spóźnione lub brakujące zgłoszenia mogą stworzyć poważne ryzyko sankcji; tylko mikroprzedsiębiorstwa i małe przedsiębiorstwa mają wąską ulgę dla pierwszego ostrzeżenia 24h. Zobacz kary i egzekwowanie CRA.
Gdzie składamy zgłoszenie, jeśli produkt jest sprzedawany w kilku państwach członkowskich?
Złóż raz przez punkt SRP swojego koordynującego CSIRT. Bez głównego miejsca prowadzenia działalności w Unii stosuje się łańcuch: upoważniony przedstawiciel, importer, dystrybutor, największa koncentracja użytkowników.
Czy zegar 24h zatrzymuje się w weekendy?
Nie. Terminy biegną w czasie kalendarzowym, więc dyżur weekendowy i świąteczny jest operacyjnie potrzebny.
Jak CRA współdziała z NIS 2?
Oba reżimy mogą dotyczyć tego samego zdarzenia, ale CRA działa na poziomie produktu przez SRP, a NIS 2 na poziomie podmiotu lub usługi przez kanał krajowy. Twierdzenia, że jedno zgłoszenie wystarczy dla obu, traktuj jako niepotwierdzone do czasu publikacji ostatecznych wytycznych przez organy.