Unijny Akt o cyberodporności, określany skrótem CRA od angielskiej nazwy Cyber Resilience Act, zmienia zasady wprowadzania na rynek urządzeń i oprogramowania. Cyberbezpieczeństwo ma być uwzględniane od początku projektowania produktu, a producent będzie odpowiadał za zarządzanie podatnościami i dostarczanie aktualizacji także po rozpoczęciu sprzedaży.
CRA to rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847. Jest stosowane bezpośrednio we wszystkich państwach Unii Europejskiej. Nie należy utożsamiać go z dyrektywą NIS2: NIS2 koncentruje się głównie na bezpieczeństwie organizacji i świadczonych usług, natomiast CRA dotyczy cyberbezpieczeństwa produktów zawierających elementy cyfrowe.
Najpierw terminy: co obowiązuje już teraz?
We wrześniu 2026 r. nie wszystkie obowiązki przewidziane w CRA są już stosowane.
| Data | Co zaczyna być stosowane |
|---|---|
| 11 czerwca 2026 r. | Przepisy dotyczące notyfikacji jednostek oceniających zgodność. |
| 11 września 2026 r. | Art. 14: obowiązki producentów dotyczące zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów wpływających na bezpieczeństwo produktów. |
| 11 grudnia 2027 r. | Zasadnicze wymagania produktowe, obowiązki importerów i dystrybutorów, administracyjne kary pieniężne z art. 64 oraz raportowanie opiekunów oprogramowania otwartego z art. 24 ust. 3. |
Obowiązki raportowe producentów mogą dotyczyć również produktów wprowadzonych na rynek przed 11 grudnia 2027 r. Z kolei produkty wprowadzone do obrotu przed tą datą zostaną co do zasady objęte pełnymi wymaganiami produktowymi CRA, jeżeli później będą podlegały istotnej modyfikacji.
Jakich produktów dotyczy CRA?
Rozporządzenie obejmuje „produkty z elementami cyfrowymi”, czyli oprogramowanie albo sprzęt wraz z rozwiązaniami do zdalnego przetwarzania danych, których zamierzone lub racjonalnie przewidywalne użycie wiąże się z bezpośrednim albo pośrednim logicznym lub fizycznym połączeniem z urządzeniem lub siecią.
Mogą to być między innymi aplikacje instalowane na komputerach lub urządzeniach mobilnych, systemy operacyjne, przeglądarki, oprogramowanie zabezpieczające, routery, urządzenia Internetu Rzeczy, urządzenia przemysłowe oraz biblioteki i komponenty programistyczne udostępniane oddzielnie na rynku.
Nie każda usługa SaaS automatycznie podlega CRA. Samodzielna usługa chmurowa co do zasady nie jest produktem z elementami cyfrowymi. Inaczej może być wtedy, gdy zdalne przetwarzanie stanowi integralną część produktu, zostało zaprojektowane przez producenta lub na jego odpowiedzialność, a bez niego produkt nie mógłby wykonywać jednej ze swoich funkcji.
Kto podlega obowiązkom CRA?
Najszerszy zakres odpowiedzialności spoczywa na producencie. Zgodnie z art. 3 pkt 13 CRA jest nim 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ą lub znakiem towarowym.
Nie ma znaczenia, czy produkt jest oferowany odpłatnie. Udostępnienie w ramach działalności komercyjnej może następować również bez pobierania ceny za sam produkt.
Obowiązki dotyczą także importerów, dystrybutorów, upoważnionych przedstawicieli, podmiotów dokonujących istotnej modyfikacji produktu oraz określonych organizacji wspierających rozwój wolnego i otwartego oprogramowania.
Importer lub dystrybutor będzie traktowany jak producent, jeżeli wprowadzi produkt na rynek pod własną nazwą lub znakiem towarowym albo dokona jego istotnej modyfikacji. Ma to szczególne znaczenie dla produktów typu white label.
Wolne i otwarte oprogramowanie
Wolne i otwarte oprogramowanie, które nie jest udostępniane na rynku w ramach działalności komercyjnej, nie podlega obowiązkom producenta. Komisja Europejska wskazuje, że udostępnianie takiego oprogramowania bez jego monetyzacji przez producenta nie powinno być samo w sobie uznawane za działalność komercyjną. CRA nie obejmuje też osób, które jedynie wnoszą kod do projektu pozostającego poza ich odpowiedzialnością.
Jeżeli podmiot sam wprowadza wolne i otwarte oprogramowanie na rynek w ramach działalności komercyjnej, może zostać uznany za producenta.
Szczególną kategorią są opiekunowie oprogramowania otwartego (open-source software stewards): osoby prawne, które systematycznie i trwale wspierają rozwój konkretnych projektów przeznaczonych do działalności komercyjnej oraz zapewniają ich trwałość, ale nie wprowadzają ich na rynek jako producenci. Ich obowiązki raportowe z art. 24 ust. 3 będą stosowane od 11 grudnia 2027 r.
Samo wykorzystanie otwartej biblioteki przez przedsiębiorstwa nie oznacza automatycznie, że jej niezależny twórca staje się producentem. Producent produktu końcowego odpowiada jednak za bezpieczeństwo całego rozwiązania i powinien dochować należytej staranności przy wyborze oraz integracji komponentów pochodzących od osób trzecich.
Najważniejsze wyłączenia
CRA nie obejmuje części produktów, dla których wymagania cyberbezpieczeństwa wynikają już z regulacji sektorowych. Dotyczy to w szczególności niektórych wyrobów medycznych, pojazdów silnikowych, produktów lotniczych i wyposażenia morskiego.
Wyłączone są również produkty opracowane lub zmodyfikowane wyłącznie na potrzeby bezpieczeństwa narodowego albo obronności oraz produkty przeznaczone konkretnie do przetwarzania informacji niejawnych. Szczególne zasady dotyczą części zamiennych zastępujących identyczny komponent i wytworzonych według tych samych specyfikacji.
Sam fakt używania produktu w szpitalu, pojeździe, urzędzie albo zakładzie przemysłowym nie przesądza, że CRA nie ma zastosowania.
Obowiązki producenta od 11 grudnia 2027 r.
Bezpieczeństwo od początku projektowania
Zgodnie z art. 13 ust. 2 producent będzie musiał przeprowadzić ocenę ryzyka cyberbezpieczeństwa i uwzględniać jej wyniki podczas planowania, projektowania, rozwoju, produkcji, dostarczania oraz utrzymywania produktu. Ocena ma stanowić część dokumentacji technicznej.
Załącznik I część I wymaga między innymi bezpiecznej konfiguracji domyślnej, ochrony przed nieuprawnionym dostępem, ochrony poufności, integralności i dostępności danych, ograniczania powierzchni ataku, rejestrowania zdarzeń istotnych dla bezpieczeństwa oraz możliwości bezpiecznego usunięcia danych i ustawień.
Zarządzanie podatnościami i obowiązkowy SBOM
Załącznik I część II pkt 1 wymaga identyfikowania i dokumentowania podatności oraz komponentów zawartych w produkcie. Obejmuje to sporządzenie wykazu elementów oprogramowania — SBOM — w powszechnie używanym formacie nadającym się do odczytu maszynowego. SBOM ma obejmować co najmniej zależności najwyższego poziomu produktu.
Producent będzie ponadto zobowiązany do usuwania podatności bez zbędnej zwłoki, regularnych testów i przeglądów bezpieczeństwa, wdrożenia polityki skoordynowanego ujawniania podatności, udostępnienia adresu do ich zgłaszania oraz bezpiecznego rozpowszechniania aktualizacji.
CRA nie nakazuje automatycznego publicznego udostępniania całego SBOM każdemu użytkownikowi. Wykaz stanowi jednak element procesu zapewnienia zgodności i powinien być dostępny w zakresie wymaganym przez przepisy, ocenę zgodności oraz działania organów nadzoru rynku.
Aktualizacje i okres wsparcia
Zgodnie z załącznikiem I część II pkt 8 aktualizacje bezpieczeństwa mają być rozpowszechniane bez zbędnej zwłoki, w bezpieczny sposób, wraz z informacją dla użytkownika i co do zasady bezpłatnie. Wyjątek może wynikać z wyraźnego odmiennego uzgodnienia dotyczącego produktu wykonanego na zamówienie dla użytkownika biznesowego.
Na podstawie art. 13 ust. 8 producent określi okres wsparcia, w którym zapewni skuteczne postępowanie z podatnościami. Co do zasady powinien on wynosić co najmniej pięć lat. Jeżeli przewidywany czas używania produktu jest krótszy, wsparcie może odpowiadać temu okresowi; jeżeli jest dłuższy, producent powinien odpowiednio wydłużyć wsparcie.
Miesiąc i rok zakończenia wsparcia muszą zostać jasno przedstawione użytkownikowi w momencie zakupu.
Dokumentacja, ocena zgodności i CE
Przed wprowadzeniem produktu na rynek producent będzie musiał przygotować dokumentację techniczną, przeprowadzić właściwą procedurę oceny zgodności, sporządzić deklarację zgodności UE, umieścić oznakowanie CE oraz przekazać użytkownikowi wymagane informacje i instrukcje.
Bardziej rygorystyczne procedury dotyczą ważnych produktów klasy I i II oraz produktów krytycznych. O klasyfikacji decyduje jednak podstawowa funkcja produktu. Samo wykorzystanie biblioteki kryptograficznej, mechanizmu logowania lub modułu haseł nie oznacza automatycznie, że cała aplikacja staje się ważnym produktem danej kategorii.
Importerzy i dystrybutorzy od 11 grudnia 2027 r.
Importer będzie musiał zweryfikować między innymi, czy producent spełnił zasadnicze wymagania, przeprowadzono odpowiednią ocenę zgodności, sporządzono dokumentację techniczną, produkt posiada oznakowanie CE, dołączono wymagane instrukcje i wskazano okres wsparcia.
Dystrybutor będzie miał węższy zakres obowiązków, ale również sprawdzi oznakowanie CE, dane producenta i importera, identyfikację produktu, instrukcje oraz informację o okresie wsparcia.
Jeżeli importer lub dystrybutor będzie miał podstawy sądzić, że produkt jest niezgodny z CRA, nie powinien wprowadzać go na rynek ani dalej udostępniać do czasu usunięcia niezgodności.
Raportowanie producentów od 11 września 2026 r.
Producent, który dowie się o aktywnie wykorzystywanej podatności, zgłasza ją właściwemu CSIRT wyznaczonemu jako koordynator oraz ENISA. Analogiczna zasada dotyczy poważnych incydentów mających wpływ na bezpieczeństwo produktu. Zgłoszenie jest przekazywane przez jednolitą platformę SRP.
| Zdarzenie | Wczesne ostrzeżenie | Dalsze zgłoszenie i raport końcowy |
|---|---|---|
| Aktywnie wykorzystywana podatność | Bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin od uzyskania wiedzy o aktywnym wykorzystywaniu. | Zgłoszenie najpóźniej w ciągu 72 godzin od uzyskania tej wiedzy; raport końcowy najpóźniej 14 dni po udostępnieniu środka naprawczego lub ograniczającego ryzyko. |
| Poważny incydent | Bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin od uzyskania wiedzy o incydencie. | Zgłoszenie najpóźniej w ciągu 72 godzin od uzyskania wiedzy; raport końcowy co do zasady w ciągu miesiąca od zgłoszenia składanego w terminie 72 godzin. |
Terminy 24 i 72 godzin są liczone od tego samego zdarzenia. Termin 72 godzin nie zaczyna biec po przekazaniu wczesnego ostrzeżenia. Wymóg działania „bez zbędnej zwłoki” oznacza ponadto, że są to terminy graniczne.
Kary stosowane od 11 grudnia 2027 r.
System administracyjnych kar pieniężnych z art. 64 będzie stosowany od 11 grudnia 2027 r. Wcześniejsze rozpoczęcie stosowania art. 14 nie oznacza wcześniejszego stosowania całego systemu kar CRA.
- Za naruszenie zasadniczych wymagań i podstawowych obowiązków producenta: do 15 mln euro albo 2,5 proc. całkowitego światowego rocznego obrotu — zależnie od tego, która wartość jest wyższa.
- Za naruszenie innych wskazanych obowiązków: do 10 mln euro lub 2 proc. obrotu.
- Za przekazanie nieprawidłowych, niepełnych albo wprowadzających w błąd informacji: do 5 mln euro lub 1 proc. obrotu.
Wobec mikro- i małych producentów nie stosuje się administracyjnych kar pieniężnych za niedotrzymanie określonego w art. 14 terminu 24-godzinnego wczesnego ostrzeżenia. Nie jest to ogólne zwolnienie małych firm z odpowiedzialności. Opiekunowie oprogramowania otwartego nie podlegają administracyjnym karom pieniężnym za naruszenia CRA.
Jak przygotować producenta, importera lub dystrybutora?
- Zbuduj katalog produktów. Ustal ich podstawową funkcję, połączenia z siecią, zdalne usługi, rynki, czas używania i możliwą kategorię CRA.
- Ustal rolę firmy. Organizacja może być producentem jednego rozwiązania, importerem drugiego i dystrybutorem trzeciego.
- Włącz ocenę ryzyka do cyklu rozwoju. Powiąż ją z wymaganiami, architekturą, testami, wydaniami, aktualizacjami i wycofaniem produktu.
- Przygotuj SBOM. Wdróż jego tworzenie i aktualizowanie w formacie nadającym się do odczytu maszynowego oraz powiąż go z monitoringiem podatności.
- Uruchom proces zgłaszania podatności. Opublikuj politykę skoordynowanego ujawniania i wskaż monitorowany adres kontaktowy.
- Przećwicz raportowanie. Ustal, kto stwierdza moment uzyskania wiedzy, kwalifikuje zdarzenie i wysyła zgłoszenie przez SRP.
- Ustal realny okres wsparcia. Zabezpiecz personel, budżet, kod i infrastrukturę aktualizacyjną.
- Zaktualizuj umowy. Ureguluj poprawki, terminy powiadomień, informacje o komponentach, długość wsparcia i współpracę przy kontroli.
- Zbuduj ścieżkę dowodową. Zachowuj wyniki ocen, testów, decyzji projektowych i działań naprawczych.
CRA z perspektywy zamawiającego
Poniższe pytania i postanowienia są rekomendacjami zakupowymi. Należy dostosować je do produktu, sposobu używania, ryzyka i daty wprowadzenia produktu do obrotu. Nie stanowią katalogu obowiązkowych wymagań dla każdego zakupu już we wrześniu 2026 r.
Uczelnia, urząd lub przedsiębiorstwo kupujące system może nie być producentem w rozumieniu CRA, ale będzie ponosić skutki wyboru produktu krótko wspieranego, trudnego do aktualizacji albo opartego na niekontrolowanych komponentach.
Przed zakupem warto zapytać dostawcę:
- czy produkt podlega CRA i jaką rolę pełni dostawca;
- jaka jest podstawowa funkcja produktu i czy należy on do kategorii ważnej lub krytycznej;
- do kiedy producent gwarantuje wsparcie bezpieczeństwa;
- czy okres wsparcia obejmuje planowany czas eksploatacji;
- czy aktualizacje bezpieczeństwa będą dostarczane bez dodatkowych opłat;
- jak dostawca informuje o aktywnie wykorzystywanych podatnościach i incydentach;
- czy prowadzi i aktualizuje SBOM oraz kontroluje komponenty open source;
- jak wygląda bezpieczna instalacja aktualizacji i zakończenie wsparcia;
- czy produkt pozwala bezpiecznie usunąć i wyeksportować dane.
Nie zawsze uzasadnione będzie żądanie przekazania pełnego SBOM. Warto jednak wymagać potwierdzenia, że producent go prowadzi, wykorzystuje w zarządzaniu podatnościami i udostępni uzgodniony zakres informacji potrzebny do oceny ryzyka.
W umowie można określić minimalny okres wsparcia, terminy poprawek, zasady informowania o aktywnie wykorzystywanych podatnościach, obowiązek utrzymania bezpiecznego kanału aktualizacji, zasady przekazywania informacji o komponentach, pomoc przy obsłudze incydentu oraz prawo do migracji danych po zakończeniu wsparcia.
Praktyczna zasada: deklarowany okres wsparcia należy porównać z planowanym czasem używania systemu. Pięć lat może być rozsądne dla części aplikacji, ale niewystarczające dla infrastruktury sieciowej, aparatury, systemów przemysłowych lub rozwiązań administracji eksploatowanych znacznie dłużej.
Nie warto czekać do grudnia 2027 r.
Przygotowanie istniejącego produktu do pełnych wymagań CRA może zająć kilkanaście miesięcy. Uporządkowanie zależności, zbudowanie SBOM, wdrożenie bezpiecznych aktualizacji i zgromadzenie dokumentacji nie są zadaniami, które da się rzetelnie wykonać tuż przed terminem.
Organizacja powinna już teraz zapewnić gotowość do raportowania z art. 14, a równolegle przygotowywać produkty, procesy i umowy do wymagań stosowanych od 11 grudnia 2027 r.
Źródła i podstawa prawna
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 z 23 października 2024 r. — Akt o cyberodporności. Tekst rozporządzenia w EUR-Lex
- Komisja Europejska — streszczenie przepisów CRA. Omówienie aktu
- Komisja Europejska — obowiązki raportowe. Terminy i platforma SRP
- Komisja Europejska — wolne i otwarte oprogramowanie. Open source w CRA
- Rozporządzenie wykonawcze Komisji (UE) 2025/2392. Techniczny opis kategorii produktów ważnych i krytycznych
- CERT Polska — Raport roczny 2025. Informacje o harmonogramie CRA
Artykuł ma charakter ogólny i informacyjny. Klasyfikacja konkretnego produktu oraz dobór procedury oceny zgodności powinny uwzględniać jego architekturę, podstawową funkcję, przeznaczenie, model udostępniania i pozostałe mające zastosowanie regulacje sektorowe.