O 123% więcej zgłoszonych CVE dziennie w 2026 niż przed rokiem.

Czym jest Cyber Resilience Act?

Unijne prawo ustanawiające zasady cyberbezpieczeństwa dla sprzętu i oprogramowania oraz to, czego wymaga od firm, które je tworzą

Cyber Resilience Act (CRA), rozporządzenie (UE) 2024/2847, to unijne rozporządzenie ustanawiające obowiązkowe wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi: sprzętu i oprogramowania łączących się z urządzeniem lub siecią, od routerów i urządzeń inteligentnego domu po aplikacje, systemy operacyjne i komponenty oprogramowania sprzedawane osobno. Weszło w życie 10 grudnia 2024. Od 11 września 2026 producenci muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty, a pozostałą część rozporządzenia stosuje się od 11 grudnia 2027.

Większość obowiązków spoczywa na producentach. Oceniają ryzyko cyberbezpieczeństwa, budują produkty zgodnie z zasadniczymi wymaganiami z załącznika I, prowadzą zestawienie komponentów oprogramowania (SBOM), obsługują podatności przez okres wsparcia wynoszący co najmniej pięć lat, przechodzą ocenę zgodności i umieszczają oznakowanie CE. Importerzy i dystrybutorzy sprawdzają, czy to zrobiono. Kary sięgają €15 milionów lub 2,5% światowego rocznego obrotu.

CRACI automatyzuje gromadzenie znacznej części dowodów potrzebnych do realizacji tych obowiązków: rejestruje komponenty pobierane przez każdy build w postaci SBOM, ponownie sprawdza je pod kątem nowych podatności po wydaniu i eksportuje dowody audytowe do Państwa dokumentacji technicznej. Gdy podatność trzeba zgłosić, CRACI składa zgłoszenia CRA do organów w Państwa imieniu. Zob. jak CRACI wspiera zgodność z CRA.

What the Cyber Resilience Act asks manufacturers to do

Zakres rozporządzenia (UE) 2024/2847, daty jego stosowania, terminy zgłoszeń oraz miejsce obowiązków dotyczących SBOM i obsługi podatności.

Petteri Pulkkinen i Erika Marttinen na Kubernetes Community Days Helsinki 2026, od 8:03 do 15:20 nagrania SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

Kluczowe daty

DataCo się dzieje
23 października 2024 Przyjęcie rozporządzenia (UE) 2024/2847 przez Parlament Europejski i Radę
20 listopada 2024 Publikacja w Dzienniku Urzędowym Unii Europejskiej
10 grudnia 2024 Wejście w życie
11 czerwca 2026 Początek stosowania przepisów o notyfikacji jednostek oceniających zgodność (rozdział IV)
11 września 2026 Początek stosowania obowiązku zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów (art. 14), także dla produktów już obecnych na rynku
11 grudnia 2027 Początek stosowania pozostałej części rozporządzenia

Kluczowe aspekty CRA

Obowiązkowe wymagania bezpieczeństwa

Produkty muszą spełniać zasadnicze wymagania cyberbezpieczeństwa z załącznika I w chwili wprowadzenia do obrotu i przez cały okres wsparcia.

Klasyfikacja oparta na ryzyku

Większość produktów należy do kategorii domyślnej. Produkty ważne i krytyczne podlegają surowszym ścieżkom oceny zgodności.

Obsługa podatności

Producenci prowadzą SBOM, niezwłocznie usuwają podatności i zgłaszają te aktywnie wykorzystywane w ciągu 24 godzin.

Oznakowanie CE

Po ocenie zgodności producent podpisuje deklarację zgodności UE i umieszcza oznakowanie CE.

Dokumentacja i przejrzystość

Dokumentację techniczną przechowuje się przez co najmniej 10 lat lub przez okres wsparcia, a użytkownicy dowiadują się, kiedy wsparcie się kończy.

Nadzór rynku

Organy krajowe mogą żądać dokumentacji, nakazywać działania naprawcze lub wycofanie produktu i nakładać kary.

The CRA timeline is ticking

Key milestones you need to prepare for under the Cyber Resilience Act.

Notified body rules apply
June 2026
Vulnerability reporting enforcement
September 2026
We are here
Full application of the CRA act
December 2027
€15M
maximum fine, or 2.5% of global annual turnover
24 hours
to send an early warning of an actively exploited vulnerability
72 hours
to follow up with a full vulnerability notification

Kogo dotyczy CRA?

Producenci

Każdy, kto opracowuje lub wytwarza produkt z elementami cyfrowymi albo zleca jego wykonanie i wprowadza go do obrotu pod własną nazwą lub znakiem towarowym, odpłatnie lub bezpłatnie. Producenci spoza UE są objęci, gdy sprzedają na jej rynek.

Importerzy i dystrybutorzy

Importerzy i dystrybutorzy muszą sprawdzić, czy produkt ma oznakowanie CE i czy producent spełnił swoje obowiązki, zanim udostępnią go w UE.

Oprogramowanie open source

Objęte jest tylko oprogramowanie open source dostarczane w ramach działalności handlowej. Opiekunowie oprogramowania open source podlegają lżejszemu reżimowi, a producenci pozostają odpowiedzialni za włączane komponenty open source.

Dostawcy oprogramowania i SaaS

Objęte jest oprogramowanie sprzedawane jako produkt, a także backend chmurowy potrzebny do działania produktu. Samo oprogramowanie jako usługa podlega NIS2, a nie CRA.

Poza zakresem: produkty objęte już unijnymi przepisami o wyrobach medycznych, wyrobach do diagnostyki in vitro i homologacji pojazdów, certyfikowane produkty lotnicze, wyposażenie morskie, identyczne części zamienne oraz produkty budowane wyłącznie na potrzeby bezpieczeństwa narodowego lub obronności (art. 2).

Kategorie produktów i ocena zgodności

Każdy producent przeprowadza ocenę zgodności przed wprowadzeniem produktu do obrotu. Ścieżka zależy od kategorii produktu.

KategoriaPrzykładyOcena zgodności
Domyślna Większość produktów z elementami cyfrowymi niewymienionych w załączniku III ani IV Dozwolona samoocena (kontrola wewnętrzna)
Ważne, klasa I (załącznik III) Zarządzanie tożsamością i dostępem, przeglądarki, menedżery haseł, VPN, systemy operacyjne, routery i przełączniki, produkty bezpieczeństwa inteligentnego domu Samoocena tylko przy stosowaniu norm zharmonizowanych, wspólnych specyfikacji lub programu certyfikacji; w przeciwnym razie jednostka notyfikowana
Ważne, klasa II (załącznik III) Hipernadzorcy i środowiska uruchomieniowe kontenerów, zapory sieciowe i systemy wykrywania włamań, odporne na manipulacje mikroprocesory i mikrokontrolery Ocena strony trzeciej przez jednostkę notyfikowaną lub europejski program certyfikacji cyberbezpieczeństwa
Krytyczne (załącznik IV) Urządzenia sprzętowe z modułami bezpieczeństwa, bramy inteligentnych liczników, karty inteligentne i elementy zabezpieczające Europejski certyfikat cyberbezpieczeństwa, jeśli wymaga go Komisja; w przeciwnym razie ocena strony trzeciej

Zasadnicze wymagania

Załącznik I określa dwie grupy zasadniczych wymagań. Pierwsza dotyczy samego produktu i opiera się na udokumentowanej ocenie ryzyka cyberbezpieczeństwa:

  • Brak znanych podatności możliwych do wykorzystania w chwili wprowadzenia produktu do obrotu
  • Domyślnie bezpieczna konfiguracja
  • Aktualizacje bezpieczeństwa, w stosownych przypadkach domyślnie automatyczne
  • Ochrona przed nieuprawnionym dostępem oraz ochrona poufności i integralności danych
  • Minimalizacja danych, dostępność podstawowych funkcji i ograniczona powierzchnia ataku
  • Bezpieczne, trwałe usuwanie danych i ustawień użytkownika

Druga dotyczy sposobu obsługi podatności przez producenta:

  • SBOM obejmujący co najmniej zależności najwyższego poziomu
  • Niezwłoczne usuwanie podatności, z aktualizacjami bezpieczeństwa oddzielonymi od aktualizacji funkcji, gdy to wykonalne
  • Regularne testy i przeglądy bezpieczeństwa
  • Polityka skoordynowanego ujawniania podatności i kontakt do zgłaszania podatności
  • Publiczne ujawnianie usuniętych podatności po udostępnieniu aktualizacji
  • Bezpieczna, bezpłatna dystrybucja aktualizacji, wraz z komunikatami doradczymi

Producenci określają też okres wsparcia wynoszący co najmniej pięć lat, chyba że przewidywane użytkowanie produktu jest krótsze, utrzymują każdą aktualizację bezpieczeństwa dostępną przez co najmniej 10 lat, a dokumentację techniczną i deklarację zgodności UE przechowują przez co najmniej 10 lat lub przez okres wsparcia, w zależności od tego, który z nich jest dłuższy (art. 13).

Obowiązki zgłaszania i terminy

Od 11 września 2026 producenci zgłaszają aktywnie wykorzystywane podatności i poważne incydenty przez Single Reporting Platform, jednocześnie do CSIRT wyznaczonego jako koordynator w ich głównym państwie członkowskim UE i do ENISA (art. 14). Dotyczy to także produktów już obecnych na rynku.

KrokAktywnie wykorzystywana podatnośćPoważny incydent
Wczesne ostrzeżenie W ciągu 24 godzin od uzyskania wiedzy W ciągu 24 godzin od uzyskania wiedzy
Zgłoszenie W ciągu 72 godzin, ze szczegółami dotyczącymi produktu, exploitu i ewentualnych środków łagodzących W ciągu 72 godzin, ze wstępną oceną i ewentualnymi środkami łagodzącymi
Raport końcowy Nie później niż 14 dni po udostępnieniu środka naprawczego lub łagodzącego W ciągu miesiąca od zgłoszenia incydentu

Producenci muszą też informować dotkniętych użytkowników, a w stosownych przypadkach wszystkich użytkowników, o środkach łagodzących, które mogą zastosować. Dotrzymanie 24-godzinnego terminu zależy od tego, czy w ciągu kilku godzin wiadomo, które produkty i wydania zawierają podatny komponent, a do tego właśnie służy SBOM dla każdego wydania.

Kary

Kary ustalają państwa członkowskie, w ramach tych maksymalnych wartości (art. 64). Organy nadzoru rynku mogą też nakazać działania naprawcze, wycofanie produktu z rynku lub od użytkowników.

NaruszenieMaksymalna administracyjna kara pieniężna
Zasadnicze wymagania cyberbezpieczeństwa (załącznik I) i obowiązki producenta (art. 13 i 14) Do €15 milionów lub 2,5% łącznego światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa
Inne obowiązki, w tym obowiązki importerów i dystrybutorów, deklaracja zgodności, oznakowanie CE, dokumentacja techniczna i ocena zgodności Do €10 milionów lub 2% łącznego światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa
Nieprawidłowe, niekompletne lub wprowadzające w błąd informacje przekazane jednostkom notyfikowanym lub organom nadzoru rynku Do €5 milionów lub 1% łącznego światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa

Mikro- i małe przedsiębiorstwa nie są karane za niedotrzymanie 24-godzinnego terminu wczesnego ostrzeżenia, a opiekunowie oprogramowania open source nie są karani za żadne naruszenie.

Open source a CRA

Wolne i otwarte oprogramowanie jest objęte tylko wtedy, gdy jest dostarczane w ramach działalności handlowej, a umieszczenie projektu w otwartym repozytorium lub menedżerze pakietów samo w sobie nie oznacza udostępnienia go na rynku. Opiekunowie oprogramowania open source, czyli osoby prawne, takie jak fundacje wspierające projekty open source przeznaczone do zastosowań komercyjnych, muszą mieć udokumentowaną politykę cyberbezpieczeństwa, współpracować z organami nadzoru rynku i zgłaszać aktywnie wykorzystywane podatności w zakresie, w jakim uczestniczą w rozwoju (art. 24).

Dla producentów open source to komponent jak każdy inny. Muszą zachować należytą staranność przy jego włączaniu, zgłaszać znalezione podatności do projektu, który go utrzymuje, i udostępniać opracowane poprawki (art. 13). Dlatego SBOM ma znaczenie: to zapis tego, które komponenty open source, w jakich wersjach, trafiają do każdego wydania.

Co CRA oznacza dla zespołów programistycznych

Dzisiejszy produkt to w większości cudzy kod: biblioteki open source, pakiety pobierane z rejestrów, bazowe obrazy kontenerów, zewnętrzne SDK oraz narzędzia buildu i pipeline'y CI/CD, które to wszystko składają. Atak na SolarWinds przeszedł przez system buildu, a Log4Shell był podatnością w szeroko stosowanej bibliotece; oba dotarły do gotowych produktów. CRA czyni producenta odpowiedzialnym za to wszystko, łącznie z należytą starannością wobec włączanych komponentów zewnętrznych i open source (art. 13).

W praktyce zespoły przygotowujące się do CRA:

  • Wiedzą, co trafia do każdego wydania, tworząc SBOM z każdego buildu w formacie czytelnym maszynowo, takim jak CycloneDX lub SPDX, zamiast jednorazowo przy wydaniu
  • Monitorują wydane wersje, a nie tylko główną gałąź, ponieważ podatność znaleziona po wydaniu nadal musi zostać niezwłocznie usunięta w okresie wsparcia
  • Uzgadniają polityki zależności: jak wybierać i przeglądać nowe komponenty, jak szybko wdrażać aktualizacje i które znaleziska blokują wydanie
  • Ćwiczą 24-godzinny termin: kto potwierdza aktywne wykorzystanie, kto składa wczesne ostrzeżenie, a kto informuje użytkowników
  • Zbierają dowody na bieżąco, ponieważ zapisy buildów, SBOM-y i wyniki testów zasilają dokumentację techniczną, którą trzeba przechowywać przez co najmniej 10 lat

Wymagania w formie planu krok po kroku opisuje przewodnik po CRA. Zob. też czego CRA wymaga od SBOM oraz jak CRACI wspiera zgodność z CRA.

Cyber Resilience Act: najczęściej zadawane pytania

Krótkie odpowiedzi na pytania, które producenci najczęściej zadają o CRA

Czym jest Cyber Resilience Act?

Cyber Resilience Act (CRA), rozporządzenie (UE) 2024/2847, to unijne rozporządzenie ustanawiające obowiązkowe wymagania cyberbezpieczeństwa dla sprzętu i oprogramowania, czyli produktów z elementami cyfrowymi wprowadzanych na rynek UE. Czyni producentów odpowiedzialnymi za bezpieczeństwo od projektu przez okres wsparcia wynoszący co najmniej pięć lat, łącznie z obsługą podatności, SBOM i zgłaszaniem aktywnie wykorzystywanych podatności.

Od kiedy stosuje się Cyber Resilience Act?

Wszedł w życie 10 grudnia 2024. Obowiązki zgłaszania z art. 14 stosuje się od 11 września 2026, przepisy o jednostkach oceniających zgodność od 11 czerwca 2026, a pozostałą część rozporządzenia od 11 grudnia 2027.

Czy CRA dotyczy oprogramowania i SaaS?

Objęte jest oprogramowanie sprzedawane lub dostarczane jako produkt, w tym aplikacje, systemy operacyjne, firmware i komponenty oprogramowania wprowadzane do obrotu osobno. Usługi chmurowe są objęte tylko jako zdalne przetwarzanie danych produktu, na przykład backend chmurowy umożliwiający sterowanie urządzeniem inteligentnego domu. Samo oprogramowanie jako usługa podlega natomiast NIS2 (motyw 12).

Czy CRA dotyczy oprogramowania open source?

Tylko oprogramowania open source dostarczanego w ramach działalności handlowej. Niekomercyjne projekty open source są poza zakresem. Opiekunowie oprogramowania open source, tacy jak fundacje wspierające projekty przeznaczone do zastosowań komercyjnych, podlegają lżejszemu reżimowi i nie mogą otrzymać kary. Producenci włączający komponenty open source do swoich produktów pozostają za nie w pełni odpowiedzialni.

Jakie są wymagania CRA dotyczące zgłaszania?

Producenci zgłaszają aktywnie wykorzystywane podatności i poważne incydenty przez Single Reporting Platform do koordynującego CSIRT i ENISA: wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin i raport końcowy w ciągu 14 dni od poprawki dla podatności lub w ciągu miesiąca dla incydentów. Informują też dotkniętych użytkowników.

Czy CRA wymaga SBOM?

Tak. Załącznik I, część II wymaga zestawienia komponentów oprogramowania w powszechnie stosowanym formacie czytelnym maszynowo, obejmującego co najmniej zależności najwyższego poziomu. Jest ono częścią dokumentacji technicznej i trafia do organu nadzoru rynku na żądanie; nie trzeba go publikować.

Jakie są kary w CRA?

Do €15 milionów lub 2,5% światowego rocznego obrotu za naruszenie zasadniczych wymagań lub obowiązków producenta, do €10 milionów lub 2% za inne obowiązki i do €5 milionów lub 1% za wprowadzanie organów w błąd. Mikro- i małe przedsiębiorstwa nie są karane za niedotrzymanie 24-godzinnego terminu wczesnego ostrzeżenia.

Czy CRA dotyczy produktów już obecnych na rynku?

Obowiązki zgłaszania tak, od 11 września 2026. Poza tym produkty wprowadzone do obrotu przed 11 grudnia 2027 podlegają CRA tylko wtedy, gdy po tej dacie zostaną istotnie zmienione.

Dowody, których potrzebuje Państwa proces CRA

Proszę zobaczyć, jak CRACI rejestruje SBOM-y z Państwa buildów, monitoruje to, co Państwo dostarczyli, i składa zgłoszenia CRA w Państwa imieniu

Umów demo Proszę sprawdzić, czy CRA Państwa dotyczy