Ten artykuł powstał częściowo z pomocą sztucznej inteligencji.
W skrócie: Cyber Resilience Act (CRA, po polsku akt o cyberodporności) od 11 września 2026 r. nakłada na producentów produktów z elementami cyfrowymi obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów. Wczesne ostrzeżenie trzeba wysłać w ciągu 24 godzin od momentu, w którym producent się o nich dowie, pełne zgłoszenie w ciągu 72 godzin, a raport końcowy później. Zgłoszenia trafiają przez platformę ENISA do krajowego zespołu CSIRT. Obowiązek dotyczy także produktów, które są już na rynku. Ten tekst wyjaśnia, co trzeba zgłaszać, w jakich terminach i jak zbudować proces, który zdąży w 24 godziny.
To część naszego przewodnika po NIS2 i Cyber Resilience Act dla firm z oprogramowaniem, w którym opisujemy wszystkie obowiązki dotyczące aplikacji i produktów.
Najważniejsze fakty:
Obowiązek zgłaszania z Cyber Resilience Act spoczywa na producencie produktu z elementami cyfrowymi, czyli firmie, która projektuje lub wytwarza produkt i wprowadza go na rynek UE pod własną nazwą. Produktem z elementami cyfrowymi jest zarówno urządzenie z oprogramowaniem (sterownik, licznik, kamera, ładowarka, maszyna z panelem sterowania), jak i samodzielne oprogramowanie sprzedawane klientom. Obowiązki mają też stewardzi oprogramowania open source w zakresie, w jakim wspierają rozwój komponentów używanych komercyjnie.
CRA nie obejmuje produktów, które mają własne przepisy o cyberbezpieczeństwie, na przykład wyrobów medycznych i pojazdów silnikowych. Usługi SaaS co do zasady są poza zakresem, chyba że zdalne przetwarzanie danych jest niezbędne do działania produktu, na przykład chmura, bez której urządzenie smart home nie działa.
Cyber Resilience Act przewiduje dwa rodzaje zgłoszeń. Pierwszy dotyczy aktywnie wykorzystywanej podatności, czyli luki, co do której są wiarygodne dowody, że ktoś ją wykorzystał w systemie bez zgody właściciela. Sama informacja o podatności, nawet krytycznej, nie uruchamia obowiązku; uruchamia go dowód, że podatność jest już używana do ataków.
Drugi rodzaj to poważny incydent mający wpływ na bezpieczeństwo produktu. Chodzi o zdarzenie, które osłabia zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności danych albo funkcji, lub które doprowadziło do uruchomienia złośliwego kodu w produkcie lub w systemach użytkownika. Przykład: przejęcie serwera aktualizacji i rozesłanie zmodyfikowanego firmware.
| Etap | Aktywnie wykorzystywana podatność | Poważny incydent |
|---|---|---|
| Wczesne ostrzeżenie | do 24 godzin od uzyskania wiedzy | do 24 godzin od uzyskania wiedzy |
| Zgłoszenie | do 72 godzin: informacje o produkcie, charakterze podatności i podjętych działaniach | do 72 godzin: charakter incydentu, ocena wstępna, działania naprawcze |
| Raport końcowy | najpóźniej 14 dni od udostępnienia poprawki lub obejścia | do miesiąca od zgłoszenia |
Zgłoszenie składa się jednocześnie do zespołu CSIRT pełniącego rolę koordynatora w państwie głównej siedziby producenta i do ENISA, przez jedną platformę. Zgodnie z FAQ ENISA o platformie zgłoszeniowej platforma ma uprościć zgłoszenia, zwłaszcza gdy produkt jest sprzedawany w wielu krajach. Producent musi też poinformować użytkowników, których dotyczy problem, o podatności lub incydencie i o tym, jak ograniczyć ryzyko.
Termin 24 godzin liczy się od momentu, w którym producent dowiaduje się o wykorzystywanej podatności, a nie od chwili, gdy dział prawny skończy analizę. W praktyce oznacza to, że firma musi mieć gotowe cztery rzeczy, zanim cokolwiek się wydarzy:
Trzeci punkt jest najczęstszą luką u producentów urządzeń. O tym, jak przygotować SBOM, piszemy w osobnym tekście.
Ogólne wyjaśnienia Komisji Europejskiej do CRA znajdziesz na stronie Komisji o Cyber Resilience Act.
Producent, który jest jednocześnie podmiotem kluczowym lub ważnym według ustawy o KSC, może mieć dwa odrębne obowiązki zgłoszeniowe. Cyber Resilience Act dotyczy bezpieczeństwa produktu, który producent sprzedaje: luki w firmware sterownika albo incydentu, który dotknął urządzeń klientów. Ustawa o KSC dotyczy incydentów w systemach samej firmy, na przykład ataku na jej sieć, systemy produkcyjne czy pocztę, i takie incydenty zgłasza się przez system S46 do właściwego zespołu CSIRT.
Jedno zdarzenie może uruchomić oba obowiązki. Jeśli atakujący włamie się do sieci producenta, przejmie serwer aktualizacji i roześle klientom zmodyfikowane oprogramowanie, to jest to jednocześnie incydent w systemach firmy w rozumieniu ustawy o KSC i poważny incydent mający wpływ na bezpieczeństwo produktu w rozumieniu CRA. Terminy w obu reżimach są podobne, ale formularze, adresaci i zakres informacji się różnią. Dlatego procedura obsługi incydentów powinna mieć dwie ścieżki i jasną regułę, kto decyduje, którą z nich uruchomić, a kiedy obie.
Weźmy producenta sterowników ogrzewania z modułem Wi-Fi. W poniedziałek o 9:00 badacz bezpieczeństwa pisze na adres security@, że luka w bibliotece obsługującej połączenia sieciowe jest wykorzystywana do przejmowania urządzeń, i podaje przykłady z internetu.
Bez SBOM pierwszy krok potrafi zająć kilka dni zamiast kilku godzin, a termin 24 godzin mija, zanim ktokolwiek wie, których urządzeń dotyczy problem. Dlatego przygotowanie procesu zgłoszeń i SBOM warto prowadzić jako jeden projekt.
Wiele podatności nie pochodzi z kodu producenta, tylko z komponentów: modułu radiowego, systemu operacyjnego czasu rzeczywistego, biblioteki kryptograficznej. Cyber Resilience Act nie zwalnia producenta z obowiązku zgłoszenia tylko dlatego, że błąd zrobił ktoś inny. Jeśli komponent z luką jest w produkcie, a luka jest aktywnie wykorzystywana, terminy biegną dla producenta. Warto więc wpisać do umów z dostawcami komponentów obowiązek szybkiego informowania o podatnościach i dostarczania poprawek, a w monitorowaniu śledzić komunikaty bezpieczeństwa najważniejszych dostawców. CRA wymaga też, żeby producent, który znajdzie podatność w komponencie, także open source, poinformował o niej podmiot, który ten komponent utrzymuje.
Odpowiedzialność za zgłoszenia według Cyber Resilience Act najlepiej przypisać jednej osobie z zastępcą, zwykle z działu rozwoju produktu albo bezpieczeństwa, a nie z działu prawnego. Prawnik powinien uczestniczyć w procesie, ale decyzja, czy dowody wykorzystania podatności są wiarygodne i których wersji produktu dotyczy problem, jest techniczna. W mniejszych firmach rolę tę często łączy się z funkcją kierownika produktu. Dyżur musi obejmować także weekendy i święta, bo termin 24 godzin nie zatrzymuje się w piątek po południu. Dobrą praktyką jest też rejestr wszystkich zgłoszeń i decyzji, łącznie z decyzjami o braku obowiązku zgłoszenia, bo organ nadzoru może o nie zapytać.
Sanddev pomaga producentom urządzeń i oprogramowania zbudować techniczną część procesu: inwentarz komponentów i SBOM w procesie budowania, monitorowanie podatności, mechanizm bezpiecznych aktualizacji i przegląd kodu produktu. Pracowaliśmy z firmami z produkcji i branży półprzewodników; więcej o tym na stronie o branżach, dla których pracujemy. Kwalifikację prawną produktu zostawiamy prawnikom.
Obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów według Cyber Resilience Act obowiązuje od 11 września 2026 r. Pozostałe wymagania CRA, w tym oznakowanie CE i SBOM, stosuje się od 11 grudnia 2027 r.
Producent ma 24 godziny na wczesne ostrzeżenie i 72 godziny na pełne zgłoszenie od chwili, gdy dowie się o aktywnie wykorzystywanej podatności. Raport końcowy składa najpóźniej 14 dni po udostępnieniu poprawki.
Podatności i poważne incydenty według CRA zgłasza się przez jednolitą platformę zgłoszeniową ENISA. Zgłoszenie trafia jednocześnie do ENISA i do zespołu CSIRT koordynatora w państwie głównej siedziby producenta.
Tak, w zakresie zgłaszania. Obowiązki zgłoszeniowe z Cyber Resilience Act obejmują także produkty z elementami cyfrowymi wprowadzone na rynek przed 11 grudnia 2027 r., jeśli producent dowie się o wykorzystywanej podatności lub poważnym incydencie.
Za naruszenie obowiązków zgłoszeniowych Cyber Resilience Act przewiduje kary administracyjne do 15 mln euro lub do 2,5% całkowitego rocznego światowego obrotu producenta, w zależności od tego, która kwota jest wyższa.
Nie. Obowiązek zgłoszenia według CRA powstaje, gdy podatność jest aktywnie wykorzystywana, czyli są wiarygodne dowody, że ktoś jej użył bez zgody właściciela systemu. Podatności bez takich dowodów producent usuwa w ramach zwykłego procesu.
OWASP Top 10 to lista najpoważniejszych kategorii ryzyka w aplikacjach webowych, publikowana przez fundację OWASP i używana jako punkt odniesienia przez zespoły bezpieczeństwa i audytorów. Aplikacje zbudowane z pomocą AI, na przykład w Lovable z bazą Supabase, najczęściej zawodzą w tych samych miejscach, co opisuje OWASP Top 10, przede wszystkim w kontroli dostępu.
SZBI, czyli system zarządzania bezpieczeństwem informacji, to główny obowiązek podmiotów kluczowych i ważnych według znowelizowanej ustawy o KSC; trzeba go wdrożyć do 3 kwietnia 2027 r.
SBOM (software bill of materials) to wykaz komponentów oprogramowania, czyli lista bibliotek, modułów i ich wersji, z których zbudowano produkt. Od 11 grudnia 2027 r. Cyber Resilience Act wymaga od producentów produktów z elementami cyfrowymi sporządzenia SBOM w powszechnie używanym formacie odczytywalnym maszynowo, obejmującym co najmniej zależności najwyższego poziomu.
