Cyber Resilience Act wszedł w etap, w którym część obowiązków przestała być teorią na 2027 rok. Od 11 września 2026 producenci produktów z elementami cyfrowymi muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty bezpieczeństwa. ENISA uruchomiła do tego wspólną platformę SRP, czyli Single Reporting Platform.

Najważniejsze jest to, że nie chodzi o zgłaszanie każdej znalezionej luki. CRA wyróżnia konkretną kategorię: podatność musi być aktywnie wykorzystywana, albo musi dojść do poważnego incydentu wpływającego na bezpieczeństwo produktu. Dla producenta zaczyna wtedy działać zegar.

24 godziny to dopiero pierwszy krok

  • Do 24 godzin od uzyskania wiedzy o zdarzeniu trzeba wysłać wczesne ostrzeżenie.
  • Do 72 godzin trzeba złożyć pełne zgłoszenie.
  • Przy aktywnie wykorzystywanej podatności raport końcowy ma trafić najpóźniej 14 dni po udostępnieniu środka naprawczego lub ograniczającego skutki.
  • Przy poważnym incydencie raport końcowy jest wymagany w ciągu miesiąca od zgłoszenia 72-godzinnego.

Producent nie musi wysyłać osobnych formularzy do wielu krajów. Zgłoszenie trafia przez platformę ENISA do właściwego CSIRT, a system służy do dalszej dystrybucji informacji między odpowiednimi organami. To jedna z bardziej praktycznych części całego rozwiązania: zamiast budować europejski odpowiednik kolekcji skrzynek pocztowych, powstał jeden wspólny kanał.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

Kogo to dotyczy, a kogo nie?

CRA dotyczy produktów z elementami cyfrowymi udostępnianych na rynku UE. W praktyce może więc obejmować oprogramowanie i sprzęt, ale nie oznacza, że każda firma mająca stronę internetową musi nagle raportować ENISA dziurę w swojej wtyczce WordPressa.

Kluczowa jest rola firmy względem produktu. Jeżeli przedsiębiorca tylko korzysta z WordPressa, WooCommerce, hostingu czy zewnętrznego SaaS, nie staje się przez to producentem tych produktów. Inna sytuacja może powstać, gdy firma rozwija i komercyjnie udostępnia własną wtyczkę, aplikację, urządzenie albo inne rozwiązanie objęte CRA. Wtedy warto ustalić swoją rolę i procedurę raportowania przed pierwszym incydentem, a nie w 23. godzinie.

A co z open source?

Tu łatwo o zbyt szeroki skrót. ENISA wyraźnie rozdziela producentów i open-source software stewards. Obowiązki raportowe z art. 24 ust. 3 dotyczące stewardów open source mają zacząć obowiązywać 11 grudnia 2027. Sama publikacja kodu open source nie oznacza więc automatycznie, że od września 2026 jego maintainer ma te same terminy raportowe co producent komercyjnego produktu.

Największym problemem może nie być formularz

24 godziny liczą się od momentu, w którym producent dowie się o aktywnie wykorzystywanej podatności lub poważnym incydencie. To przesuwa ciężar z samego “umieć zgłosić” na “umieć zauważyć”. Firma, która nie ma jasnej ścieżki przyjmowania zgłoszeń bezpieczeństwa, monitoringu własnego produktu i osoby odpowiedzialnej za ocenę incydentu, może stracić większość czasu zanim w ogóle ktoś zorientuje się, że uruchomił się termin regulacyjny.

Dlatego procedura nie powinna zaczynać się od linku do portalu ENISA. Powinna zaczynać się od odpowiedzi na pytania: kto odbiera zgłoszenie, kto ocenia czy luka jest aktywnie wykorzystywana, kto może podjąć decyzję o raporcie, gdzie są potrzebne dane techniczne i kto komunikuje się z klientami. Platforma jest ostatnim odcinkiem tej drogi.

Komentarz WebsiteGarage

Wokół unijnego prawa cyfrowego szybko robi się konkurs na najbardziej dramatyczny nagłówek. Tutaj ciekawsze jest coś odwrotnego: UE uruchomiła jeden punkt raportowania i podała całkiem konkretny rytm zgłoszeń. Dla firmy, która faktycznie jest producentem objętym CRA, da się z tego zrobić proces, a nie rytuał paniki po znalezieniu CVE.

Jednocześnie nie warto kopiować obowiązków z cudzej checklisty bez sprawdzenia własnej roli. Właściciel sklepu internetowego, producent wtyczki WooCommerce i firma sprzedająca urządzenie IoT mogą mieć zupełnie inne obowiązki, mimo że wszystkie trzy “robią coś w internecie”. Najpierw kwalifikacja, potem procedura. Odwrotna kolejność produkuje dokumenty, które świetnie wyglądają w folderze i niewiele pomagają podczas realnego incydentu.