Obowiązek z artykułu 14 CRA dotyczy każdego producenta produktu z elementami cyfrowymi wprowadzanego na rynek Unii, także za darmo5. Od 11 września 2026 r. musi on zgłaszać aktywnie wykorzystywaną podatność oraz poważny incydent jednocześnie CSIRT-owi koordynatorowi i ENISA, przez jedną platformę: wczesne ostrzeżenie w 24 godziny, zgłoszenie w 72 godziny od powzięcia wiadomości, a sprawozdanie końcowe w terminie, który zależy od rodzaju zdarzenia5. Zgłoszenie do złego CSIRT-u może zostać unieważnione2.
Większość omówień CRA kończy na przepisaniu artykułu 14 słowo w słowo. Ten tekst dochodzi dalej - do adresu platformy, do konta, które trzeba założyć, i do usterki licznika, przez którą zgłoszenie złożone w terminie ustawowym platforma może oznaczyć jako spóźnione.
Kogo obejmuje obowiązek zgłoszenia z artykułu 14 CRA
Rozporządzeniem (UE) 2024/2847, czyli aktem o cyberodporności (Cyber Resilience Act, CRA), rządzi definicja producenta z artykułu 3 punkt 13, i jest ona szersza, niż podpowiada intuicja. Producent to osoba fizyczna lub prawna, która opracowuje lub wytwarza produkt z elementami cyfrowymi albo zleca jego zaprojektowanie, opracowanie lub wytworzenie, i wprowadza go do obrotu pod własną nazwą handlową lub znakiem towarowym - za opłatą, na zasadzie monetyzacji albo bezpłatnie5. Model biznesowy nie zwalnia z obowiązku: darmowa aplikacja, wtyczka czy biblioteka wydana pod własną marką liczy się tak samo jak płatna licencja korporacyjna.
Produktem z elementami cyfrowymi jest przy tym każde oprogramowanie komputerowe lub sprzęt komputerowy, razem z powiązanymi rozwiązaniami zdalnego przetwarzania danych, w tym komponenty wprowadzane do obrotu oddzielnie od całości5. Zakres nie obejmuje wyrobów medycznych podlegających rozporządzeniom 2017/745 i 2017/746, pojazdów objętych rozporządzeniem 2019/2144, produktów certyfikowanych zgodnie z przepisami lotniczymi 2018/1139, wyposażenia morskiego z dyrektywy 2014/90/UE, części zamiennych wymieniających identyczne komponenty ani produktów opracowanych lub zmodyfikowanych wyłącznie na potrzeby bezpieczeństwa narodowego lub obronności. Osobnym wyłączeniem, niezależnym od branży, są produkty zaprojektowane specjalnie w celu przetwarzania informacji niejawnych5.
Kalendarz stosowania rozporządzenia nie jest jeden. Artykuł 71 ust. 2 mówi, że całość rozporządzenia obowiązuje od 11 grudnia 2027 r., ale wyłącza z tej daty dwa fragmenty: artykuł 14 obowiązuje już od 11 września 2026 r., a rozdział IV, czyli artykuły 35-51 o ocenie zgodności, od 11 czerwca 2026 r.5 Obowiązek zgłoszenia z tego tekstu biegnie więc ponad rok przed tym, nim reszta rozporządzenia zacznie formalnie obowiązywać.
Co się zgłasza: aktywnie wykorzystywana podatność i poważny incydent
Artykuł 14 uruchamia dwa niezależne obowiązki zgłoszeniowe, każdy dla innego zdarzenia, i różnica między nimi nie jest kosmetyczna - inny jest też termin sprawozdania końcowego, o czym dalej.
Pierwszym zdarzeniem jest aktywnie wykorzystywana podatność. Rozporządzenie definiuje ją wąsko: to podatność, co do której istnieją wiarygodne dowody, że podmiot działający w złych zamiarach wykorzystał ją w systemie bez zgody właściciela tego systemu5. Sama obecność luki w kodzie tego progu nie przekracza - zarządzanie podatnościami jako proces obejmuje też luki znane, ale niewykorzystywane, i tych artykuł 14 nie dotyczy. Dopiero dowód eksploatacji, zwykle powiązany z konkretnym numerem CVE, uruchamia zegar.
Drugim zdarzeniem jest poważny incydent mający wpływ na bezpieczeństwo produktu. Rozporządzenie uznaje incydent za poważny, jeżeli negatywnie wpływa albo 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 bądź funkcji, albo jeżeli prowadził lub może prowadzić do wprowadzenia lub uruchomienia złośliwego kodu w produkcie albo w sieci i systemach informatycznych użytkownika5. Wystarczy jedna z tych dwóch przesłanek.
Komu i w jakim terminie: 24 godziny, 72 godziny, raport końcowy
Zgłoszenie nie idzie do jednego adresata wybieranego przez producenta. Artykuł 14 ust. 1 każe zgłosić zarówno aktywnie wykorzystywaną podatność, jak i poważny incydent jednocześnie CSIRT-owi wyznaczonemu na koordynatora oraz ENISA, za pośrednictwem pojedynczej platformy sprawozdawczej, którą zgodnie z artykułem 16 ust. 1 ustanawia, prowadzi i utrzymuje sama ENISA5. Platforma nosi adres portal.cra-srp.enisa.europa.eu i ma być operacyjna od 11 września 2026 r. - dokładnie tego samego dnia, w którym zaczyna obowiązywać artykuł 1412. Zgłoszenie nie zatrzymuje się przy tych dwóch adresatach: artykuł 16 ust. 3 każe CSIRT-om koordynatorom przekazać z niego organom nadzoru rynku swoich państw te informacje, które są tym organom niezbędne do wykonywania obowiązków z rozporządzenia5.
Który CSIRT jest koordynatorem, ustala hierarchia z artykułu 14 ust. 7: co do zasady jest to CSIRT państwa, w którym producent ma główną siedzibę w Unii, rozumianą jako miejsce podejmowania decyzji o cyberbezpieczeństwie jego produktów. Gdy nie da się tego ustalić, rozstrzyga liczba pracowników, a gdy producent nie ma głównej siedziby w Unii wcale, kolejność wyznaczają upoważniony przedstawiciel, importer, dystrybutor i wreszcie liczba użytkowników5. W Polsce tym CSIRT-em jest CSIRT NASK, znany szerzej jako CERT Polska - wynika to z ustawy z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa, wdrażającej dyrektywę NIS2, tak jak pisze o sobie sam zespół w bazie wiedzy CERT Polska4. Potwierdza to prowadzona przez ENISA lista CSIRT-ów wyznaczonych na koordynatorów, zaktualizowana 4 września 2026 r., która przy pozycji Poland podaje adres programu skoordynowanego ujawniania podatności CERT Polska3. Wybór CSIRT-u należy do producenta, a pomyłka kosztuje więcej niż chwilę - zgłoszenie do złego adresata może zostać unieważnione i wtedy trzeba je złożyć od nowa, tym razem do właściwego CSIRT-u2.
Sam termin ma trzy kroki i różni się treścią w zależności od zdarzenia, ale w obu przypadkach liczy się od chwili, w której producent się dowiedział, nie od dnia, w którym ktokolwiek inny wykrył problem.
| Krok | Aktywnie wykorzystywana podatność | Poważny incydent |
|---|---|---|
| Wczesne ostrzeżenie | 24 godziny od powzięcia wiadomości | 24 godziny, z informacją o podejrzeniu działania bezprawnego lub w złym zamiarze |
| Zgłoszenie | 72 godziny od powzięcia wiadomości | 72 godziny od powzięcia wiadomości |
| Sprawozdanie końcowe | najpóźniej 14 dni po udostępnieniu środka naprawczego lub łagodzącego | najpóźniej miesiąc od zgłoszenia 72-godzinnego, nie od wykrycia |
Powyższe terminy wynikają z artykułu 14 ust. 2 i ust. 45. Różnica w trzecim kroku nie jest przypadkowa. Sprawozdanie końcowe dla podatności nie ma stałego terminu kalendarzowego, bo zależy od tego, kiedy producent w ogóle udostępni łatkę - może to być tydzień, a może pół roku. Sprawozdanie dla incydentu ma twardy termin miesiąca, liczony od zgłoszenia 72-godzinnego, nie od wykrycia5. Zgodnie z tym samym rozróżnieniem platforma CRA-SRP w obecnym kształcie w ogóle nie pokazuje licznika dla sprawozdania końcowego podatności, a dla incydentu wyświetla licznik miesiąca odmierzany od zgłoszenia 72-godzinnego2.
Zgłoszenie składa się z osobistego konta EU Login zabezpieczonego uwierzytelnianiem wieloskładnikowym - konta są imienne, więc formalnym zgłaszającym staje się konkretny człowiek, nie skrzynka działu bezpieczeństwa2. Producent rejestruje do platformy swojego przedstawiciela: jednego Primary Assigned Representative i do dwudziestu Secondary Assigned Representative. To rola techniczna na platformie i nie ma nic wspólnego z upoważnionym przedstawicielem z artykułu 3 pkt 15, czyli podmiotem z pisemnym pełnomocnictwem producenta, który pojawił się wyżej przy ustalaniu właściwego CSIRT-u5. Powiązanie przedstawiciela z producentem waliduje CSIRT koordynator, ale walidacja biegnie równolegle i nie blokuje składania zgłoszeń - niezwalidowany przedstawiciel może złożyć do dwudziestu zgłoszeń, zanim walidacja stanie się obowiązkowa2. ENISA odradza rejestrację na zapas: przy aktywnym koncie EU Login sama rejestracja zajmuje kilka minut, więc radzi zakładać konto i uruchamiać walidację dopiero wtedy, gdy trzeba faktycznie coś zgłosić, żeby nie obciążać CSIRT-ów zbędną pracą2.
W obecnej wersji CRA-SRP licznik 72 godzin pokazuje termin 48 godzin po złożeniu wczesnego ostrzeżenia, a nie 72 godziny od powzięcia wiadomości o podatności czy incydencie. Zgłoszenie złożone zgodnie z artykułem 14 może więc zostać oznaczone przez platformę jako spóźnione, mimo że termin ustawowy jeszcze nie minął. ENISA zapowiada zmianę tej logiki na liczenie od pola z datą i godziną powzięcia wiadomości i zastrzega, że sam licznik nie zastępuje odpowiedzialności za dotrzymanie terminów z artykułu 142.
Niedostępność platformy nie zawiesza obowiązku. Producent czeka na jej przywrócenie i składa zgłoszenie, gdy ona wróci; jeśli uzna sprawę za na tyle pilną, że nie może czekać, może skontaktować się z CSIRT-em bezpośrednio, ale zgłoszenie i tak musi później przejść przez platformę2.
Obowiązek nie działa wstecz, z jednym zastrzeżeniem, które łatwo przeoczyć. Producent nie musi zgłaszać aktywnego wykorzystania, o którym dowiedział się przed 11 września 2026 r. Jeśli jednak dowiaduje się o nim po tej dacie, obowiązek działa - także wtedy, gdy sama podatność istniała albo była mu znana już wcześniej2.
Dwie rzeczy, które CRA przewiduje, na start platformy jeszcze nie działają. Dobrowolne zgłaszanie z artykułu 15, przeznaczone dla podatności niewykorzystywanych aktywnie i dla incydentów bez poważnego wpływu, wejdzie w kolejnej fazie platformy. Obowiązki opiekunów oprogramowania z otwartym kodem z artykułu 24 ust. 3 zaczynają się dopiero 11 grudnia 2027 r., razem z resztą rozporządzenia2.
Obowiązek wobec użytkowników produktu
Zgłoszenie do CSIRT-u i ENISA nie kończy obowiązków producenta. Po otrzymaniu informacji o podatności lub incydencie ma on poinformować użytkowników, na których zdarzenie wpływa, o samym zdarzeniu oraz o środkach łagodzących i naprawczych, jakie mogą podjąć5. Jeżeli nie zrobi tego w odpowiednim czasie, CSIRT może przekazać tę informację użytkownikom sam, gdy uzna to za proporcjonalne i konieczne5. Milczenie producenta nie chroni więc użytkowników przed informacją - najwyżej ją opóźnia i przenosi obowiązek na CSIRT.
Kary za brak zgłoszenia z artykułu 14
Niezgodność z obowiązkami z artykułów 13 i 14 oraz z zasadniczymi wymaganiami z załącznika I podlega administracyjnej karze pieniężnej do 15 000 000 EUR albo, jeżeli za naruszenie odpowiada przedsiębiorstwo, do 2,5% jego łącznego rocznego światowego obrotu z poprzedniego roku obrotowego - w zależności od tego, która z tych kwot jest wyższa5. Przy wymiarze kary organ uwzględnia między innymi wielkość podmiotu, w tym mikroprzedsiębiorstwa, małe i średnie firmy oraz startupy5, więc górna granica nie jest punktem startowym dla każdego naruszenia.
Ten przepis o karach ma jednak własny, osobny kalendarz. Artykuł 71 ust. 2, opisany na początku tego tekstu, wyłącza z ogólnej daty 11 grudnia 2027 r. tylko artykuł 14 i rozdział IV - artykułu 64 wśród tych wyjątków nie ma5. Obowiązek zgłoszenia zaczyna więc obowiązywać wcześniej niż przepis rozporządzenia, który wprost reguluje sankcje za jego naruszenie.
Kto w Polsce pomoże wdrożyć artykuł 14 CRA
Artykuł 14 zakłada, że producent w ogóle wie, kiedy jego produkt jest aktywnie atakowany - a to wymaga procesu, nie jednorazowej reakcji po fakcie. Zarządzanie podatnościami jako cykl wykrywania, oceny i usuwania luk jest tu punktem wyjścia, ale samo rozpoznanie eksploatacji wymaga też bieżącego monitorowania telemetrii produktu i infrastruktury, w której działa. Tę pracę w praktyce prowadzą zespoły SOC korzystające z systemów klasy SIEM; w katalogu CyberKatalog odpowiada im kategoria Monitoring i SOC, dziś kilkadziesiąt firm.
Dowód aktywnego wykorzystania rzadko przychodzi sam od siebie - zwykle trzeba go poszukać testem albo audytem gotowości na reżim liczony godzinami, nie dniami roboczymi. Tę pracę prowadzą firmy z kategorii Testy Penetracyjne i Audyty, dziś kilkadziesiąt podmiotów w katalogu.
Obowiązek z artykułu 14 dotyczy producenta produktu i jest osobny od obowiązków operatora usługi kluczowej lub ważnej z ustawy o krajowym systemie cyberbezpieczeństwa, wdrażającej dyrektywę NIS26. Firma, która jest jednocześnie dostawcą oprogramowania i podmiotem objętym tą ustawą, ma dwa osobne reżimy zgłoszeniowe naraz, nie jeden - stronę operatorską opisaliśmy w tekście o tym, kto w Polsce wdroży NIS2 i ustawę o KSC, a pełny wykaz aktów regulujących polski system cyberbezpieczeństwa zestawia narzędzie do sprawdzania Krajowego Systemu Cyberbezpieczeństwa.
Źródła
- ENISA, "Single Reporting Platform (SRP)" - adres i termin uruchomienia platformy CRA-SRP (odczyt 08.09.2026)
- ENISA, "Frequently Asked Questions" - konto EU Login, role AR, licznik 72h, brak retroaktywności, niedostępność platformy (odczyt 08.09.2026)
- ENISA, "List of CSIRTs Designated as Coordinators", 04.09.2026 - CSIRT NASK jako koordynator dla Polski (odczyt 08.09.2026)
- CERT Polska, "Skoordynowane Ujawnianie Podatności" - rola CSIRT NASK wynikająca z nowelizacji ustawy o KSC (odczyt 08.09.2026)
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 (akt o cyberodporności), art. 2, art. 3 pkt 1, 13 i 42, art. 14, art. 16 ust. 1 i 3, art. 64 ust. 2 i 5 oraz art. 71 ust. 2 (odczyt 08.09.2026)
- Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, akt wdrażający dyrektywę NIS2 (odczyt 08.09.2026)