Akt o cyberodporności (CRA) – kogo dotyczy? Rozporządzenie obejmuje nie tylko producentów routerów, urządzeń IoT czy sprzętu zabezpieczającego. Obowiązki mogą dotyczyć również software house’ów rozwijających własne aplikacje, importerów elektroniki spoza UE, dystrybutorów private label oraz podmiotów stale wspierających komercyjne projekty open source. O objęciu CRA decydują przede wszystkim cechy produktu, sposób jego udostępnienia na rynku Unii i rola firmy w łańcuchu dostaw, a nie jej branża lub wielkość.
Pierwszym krokiem nie jest wybór certyfikatu ani napisanie procedury. Firma musi ustalić, czy oferuje produkt z elementami cyfrowymi, w jakiej roli działa oraz do której kategorii należy produkt. Dopiero ta kwalifikacja pozwala określić właściwą ocenę zgodności, dokumentację, okres wsparcia i sposób raportowania podatności.
Najszerszy zakres obowiązków spoczywa na producencie. Kontrolne obowiązki otrzymują importerzy i dystrybutorzy. Firma może jednak stać się producentem także bez własnej fabryki lub zespołu programistycznego, jeżeli wprowadza produkt pod własną nazwą albo istotnie go modyfikuje.
Kogo dotyczy akt o cyberodporności CRA?
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 tworzy wspólne wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi udostępnianych na rynku Unii. Nie jest regulacją przeznaczoną wyłącznie dla dużych producentów technologicznych. Co do zasady nie zawiera ogólnego zwolnienia dla mikroprzedsiębiorców ani MŚP.
W praktyce analizę należy przeprowadzić, gdy firma zarabia na sprzęcie, aplikacji, systemie operacyjnym, komponencie programowym lub rozwiązaniu powiązanym z takim produktem. Znaczenie może mieć sprzedaż licencji, subskrypcja, opłata za konkretną wersję, udostępnienie produktu razem z usługą, monetyzacja danych albo wykorzystanie produktu jako elementu większej oferty.
Czy mój produkt może podlegać CRA?
Wstępny testTest porządkuje stan faktyczny, ale nie zastępuje prawnej kwalifikacji produktu i roli przedsiębiorcy.
Odpowiedź twierdząca nie oznacza jeszcze, że produkt należy do kategorii ważnej lub krytycznej. Najpierw ustala się, czy mieści się w ogólnym zakresie CRA, następnie rolę firmy, a dopiero później klasę produktu i procedurę oceny zgodności.
Pięć pytań, od których warto rozpocząć analizę
- Czy przedmiotem oferty jest sprzęt, oprogramowanie lub ich cyfrowy komponent?
- Czy zamierzone lub racjonalnie przewidywalne użycie zakłada połączenie z urządzeniem albo siecią?
- Czy produkt jest udostępniany użytkownikom lub podmiotom gospodarczym na rynku UE?
- Czy udostępnienie ma charakter komercyjny, również pośredni?
- Czy firma działa jako producent, importer, dystrybutor, przedstawiciel albo opiekun open source?
Jakie sprzęty, aplikacje i usługi obejmuje CRA?
Produktem z elementami cyfrowymi może być produkt sprzętowy lub programowy oraz jego rozwiązania zdalnego przetwarzania danych. Warunkiem jest to, aby zamierzone albo racjonalnie przewidywalne użycie obejmowało bezpośrednie lub pośrednie połączenie z urządzeniem lub siecią.
Sprzęt i oprogramowanie
- routery, modemy, przełączniki i urządzenia IoT,
- aplikacje desktopowe i mobilne,
- systemy operacyjne i oprogramowanie wbudowane,
- systemy VPN, SIEM, zapory i menedżery haseł,
- samodzielne komponenty programowe i sprzętowe.
Usługi i rozwiązania hybrydowe
- SaaS powiązany funkcjonalnie z produktem,
- chmura niezbędna do działania urządzenia,
- oprogramowanie tworzone na indywidualne zamówienie,
- white label oraz private label,
- komercyjnie wspierane projekty open source.
Wybrane wyłączenia
- czysta usługa niewchodząca w skład produktu,
- FOSS rozwijany poza działalnością komercyjną,
- produkty objęte wskazanymi regulacjami sektorowymi,
- identyczne części zamienne dostarczane według reguł CRA,
- produkty wyłącznie dla bezpieczeństwa narodowego lub obronności.
CRA obejmuje także komponenty udostępniane oddzielnie. Biblioteka, moduł uwierzytelniania, interfejs sieciowy albo firmware mogą więc wymagać odrębnej analizy, nawet jeśli ostatecznie zostaną zintegrowane z większym systemem.
Sam fakt włączenia komponentu należącego do kategorii z załącznika III nie powoduje automatycznie, że cały produkt podlega tej samej procedurze oceny zgodności. Trzeba zbadać podstawową funkcjonalność każdego produktu i reguły jego udostępniania.
Producent, importer czy dystrybutor – jak ustalić rolę firmy?
Ta sama aplikacja lub urządzenie może wywoływać inny zakres odpowiedzialności u kilku przedsiębiorców. Producent odpowiada za bezpieczeństwo w całym cyklu życia produktu, importer sprawdza zgodność produktu pochodzącego spoza UE, a dystrybutor weryfikuje wymagane oznakowanie i dokumenty przed udostępnieniem produktu.
Producent
Projektuje, rozwija lub wytwarza produkt albo zleca te działania, a następnie wprowadza produkt pod własną nazwą lub znakiem towarowym. Odpowiada m.in. za ryzyko, dokumentację, zgodność, podatności i wsparcie.
Importer
Wprowadza na rynek UE produkt producenta mającego siedzibę poza Unią. Musi sprawdzić m.in. ocenę zgodności, dokumentację, oznakowanie CE i dane producenta oraz reagować na rozpoznane niezgodności.
Dystrybutor
Działa w łańcuchu dostaw bez bycia producentem lub importerem. Przed sprzedażą weryfikuje wymagane informacje i oznaczenia, zachowuje należytą staranność oraz nie udostępnia produktu, o którym wie, że jest niezgodny.
Upoważniony przedstawiciel
Wykonuje wskazane zadania w imieniu producenta na podstawie pisemnego umocowania. Zakres pełnomocnictwa musi odpowiadać CRA, ale nie usuwa podstawowej odpowiedzialności producenta za produkt.
Opiekun oprogramowania otwartego
Osoba prawna, inna niż producent, która systematycznie i w sposób ciągły wspiera rozwój produktów kwalifikowanych jako wolne i otwarte oprogramowanie przeznaczone do działalności komercyjnej. Podlega szczególnemu, lżejszemu reżimowi współpracy i polityki cyberbezpieczeństwa określonemu w art. 24 CRA.
Nie tworzysz kodu? Nadal możesz być producentem
Firma zlecająca wykonanie aplikacji software house’owi może być producentem, jeżeli oferuje ją pod własną nazwą. Producentem może stać się również importer lub dystrybutor, który rebranduje produkt albo dokonuje w nim istotnej modyfikacji. Umowa z wykonawcą powinna więc zapewniać dostęp do dokumentacji technicznej, informacji o komponentach, wyników testów i obsługi podatności.
Właściwy podział obowiązków warto zabezpieczyć także kontraktowo. Praktyczne zasady dotyczące czasów reakcji, bezpieczeństwa dostępu, odpowiedzialności i praw do poprawek opisuje artykuł Umowa SLA w IT – na co zwrócić uwagę?.
Produkty zwykłe, ważne i krytyczne
Większość produktów objętych CRA pozostaje w kategorii domyślnej. Załączniki III i IV wyodrębniają jednak produkty ważne klasy I i II oraz produkty krytyczne. Klasyfikacja wpływa przede wszystkim na dopuszczalną procedurę oceny zgodności, a nie na sam obowiązek zapewnienia cyberbezpieczeństwa.
Produkty zwykłe
Produkty niewymienione w załącznikach III i IV. Producent może co do zasady przeprowadzić wewnętrzną kontrolę zgodności, o ile spełni wymagania CRA i przygotuje pełną dokumentację techniczną.
Produkty ważne
Klasa I dopuszcza samoocenę tylko przy pełnym zastosowaniu właściwych norm zharmonizowanych, wspólnych specyfikacji lub programu certyfikacji. Klasa II wymaga udziału strony trzeciej albo właściwego certyfikatu.
Produkty krytyczne
Wymagają rygorystycznej oceny z udziałem jednostki notyfikowanej lub certyfikacji przewidzianej w CRA. Kategoria obejmuje m.in. wybrane elementy bezpieczne, bramy inteligentnych liczników i karty inteligentne.
Ważne produkty – klasa I
M.in. systemy zarządzania tożsamością i uprzywilejowanym dostępem, przeglądarki, menedżery haseł, antymalware, VPN, SIEM, PKI, systemy operacyjne, routery, modemy, przełączniki oraz wybrane produkty inteligentnego domu.
Ważne produkty – klasa II
Hiperwizory i systemy środowiska uruchomieniowego, zapory sieciowe, systemy wykrywania włamań lub zapobiegania włamaniom oraz mikroprocesory i mikrokontrolery odporne na manipulacje.
Produkty krytyczne
Urządzenia sprzętowe ze skrzynkami zabezpieczającymi, bramy inteligentnych liczników i inne urządzenia do zaawansowanych celów bezpieczeństwa oraz karty inteligentne lub podobne urządzenia.
Dlaczego klasyfikacja wymaga ostrożności?
Decyduje podstawowa funkcjonalność produktu, nie jego nazwa handlowa. Jeden system może łączyć kilka funkcji, a aktualizacja lub istotna modyfikacja może zmienić wcześniejszą ocenę.
Co producent musi przygotować niezależnie od klasy?
Ocena ryzyka produktu
Udokumentowana analiza zagrożeń oraz decyzji projektowych powiązana z wymaganiami załącznika I i całym okresem wsparcia.
Security by design i default
Odpowiedni poziom ochrony od projektu, bezpieczna konfiguracja domyślna, kontrola dostępu, poufność, integralność i dostępność.
Dokumentacja i zgodność
Dokumentacja techniczna, ocena zgodności, deklaracja zgodności UE, oznakowanie CE oraz jasne instrukcje dla użytkownika.
Zarządzanie podatnościami
Identyfikacja komponentów i podatności, polityka skoordynowanego ujawniania, aktualizacje bezpieczeństwa i obsługa zgłoszeń.
Okres wsparcia
Co do zasady co najmniej pięć lat, chyba że przewidywany czas używania produktu jest krótszy. Dłuższy cykl życia wymaga odpowiednio dłuższego wsparcia.
Raportowanie do ENISA
Zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów wpływających na bezpieczeństwo produktu przez jednolitą platformę raportowania.
Rola firmy przesądza o odpowiedzialności
Nie masz pewności, czy firma jest producentem, importerem czy tylko dostawcą technicznym? Prawidłowa kwalifikacja roli przesądza o zakresie dokumentacji, ocenie zgodności i odpowiedzialności za produkt.
Skonsultuj zakres CRASaaS, open source i najważniejsze wyłączenia
Czy SaaS podlega CRA?
Sama usługa SaaS nie jest automatycznie produktem z elementami cyfrowymi. Może jednak zostać objęta CRA jako rozwiązanie zdalnego przetwarzania danych, jeżeli została zaprojektowana i rozwinięta przez producenta lub na jego odpowiedzialność, a bez niej produkt nie mógłby wykonywać jednej ze swoich funkcji. Przykładem może być chmura niezbędna do sterowania urządzeniem, aktualizacji jego zabezpieczeń albo przetwarzania danych koniecznych dla podstawowego działania.
Jeżeli chmura jest niezależną usługą, a produkt zachowuje funkcjonalność bez niej, potrzebna jest odrębna analiza. Znaczenie mają architektura, warunki umowne, dokumentacja funkcjonalna i faktyczny model dostarczania, nie samo użycie słowa „SaaS”.
Czy open source jest wyłączony?
Wolne i otwarte oprogramowanie rozwijane lub dostarczane poza działalnością komercyjną co do zasady pozostaje poza zakresem pełnych obowiązków producenta. Samo przyjmowanie darowizn, wkład korporacyjny lub publiczne repozytorium nie przesądzają jeszcze o charakterze komercyjnym.
Inaczej będzie, gdy firma pobiera opłatę za konkretną wersję programu, wprowadza ją na rynek pod własną nazwą albo monetyzuje produkt w sposób wskazujący na działalność komercyjną. Osobną kategorią jest opiekun oprogramowania otwartego, który systematycznie wspiera rozwój komercyjnego ekosystemu FOSS, ale nie działa jako producent.
System zarządzania bezpieczeństwem informacji może uporządkować ryzyko, incydenty, dostawców, rozwój i dokumentację. CRA wymaga jednak także oceny konkretnego produktu, bezpiecznego cyklu jego życia, deklaracji zgodności, oznakowania CE i obsługi podatności. Zobacz, jak zbudować politykę bezpieczeństwa informacji według ISO 27001.
Najważniejsze wyłączenia sektorowe
CRA nie stosuje się w pełnym zakresie do produktów objętych wskazanymi unijnymi regulacjami sektorowymi, w tym wybranych wyrobów medycznych i wyrobów medycznych do diagnostyki in vitro, produktów motoryzacyjnych, lotniczych i wyposażenia morskiego. Wyłączone są również produkty opracowane lub zmodyfikowane wyłącznie dla bezpieczeństwa narodowego, obronności albo przetwarzania informacji niejawnych.
To, że produkt trafia do sektora regulowanego, nie wystarcza. Trzeba sprawdzić jego przeznaczenie, właściwy akt sektorowy i zakres wymagań, które rzeczywiście obejmują cyberbezpieczeństwo produktu.
Terminy CRA i plan przygotowań
Akt o cyberodporności wszedł w życie 10 grudnia 2024 r., ale jego obowiązki uruchamiają się etapami. Najbliższy termin dotyczy raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu. Pełne wymagania dla produktów zaczną być stosowane później.
CRA stał się obowiązującym prawem
Rozpoczął się okres przygotowawczy dla producentów, importerów, dystrybutorów, jednostek oceniających zgodność i administracji.
Obowiązki z art. 14
Producenci rozpoczynają raportowanie aktywnie wykorzystywanych podatności oraz poważnych incydentów przez platformę ENISA.
Wymagania dla produktów
Od tej daty wprowadzane na rynek produkty muszą spełniać zasadnicze wymagania CRA i przejść właściwą ocenę zgodności.
Raportowanie: 24 godziny i 72 godziny
W przypadku aktywnie wykorzystywanej podatności producent przekazuje wczesne ostrzeżenie bez zbędnej zwłoki, nie później niż w ciągu 24 godzin od uzyskania wiedzy, a następnie uzupełniające zgłoszenie co do zasady w ciągu 72 godzin. Analogiczne krótkie etapy dotyczą poważnego incydentu wpływającego na bezpieczeństwo produktu. Informacje trafiają przez jednolitą platformę raportowania ENISA do właściwych organów.
Terminy CRA nie powinny być utożsamiane ze zgłoszeniami incydentów na gruncie KSC/NIS2 lub RODO. Jedno zdarzenie może uruchomić kilka obowiązków wobec różnych odbiorców. Wewnętrzna procedura musi więc zawierać jedną ścieżkę kwalifikacji oraz odrębne decyzje raportowe. Więcej o terminach KSC wyjaśnia artykuł Zgłoszenie incydentu NIS2 – dwa terminy na reakcję.
Co z produktami wprowadzonymi przed 11 grudnia 2027 r.?
Produkty wprowadzone na rynek przed datą pełnego stosowania co do zasady podlegają nowym wymaganiom produktowym, gdy po tej dacie zostaną poddane istotnej modyfikacji. Obowiązki raportowania z art. 14 stosuje się jednak od 11 września 2026 r. także do objętych CRA produktów już obecnych na rynku. Firma nie powinna więc odkładać ewidencji produktów i kanału obsługi podatności do końca 2027 r.
Kary za naruszenie CRA
| Rodzaj naruszenia | Maksymalna kara | Przykładowy obszar |
|---|---|---|
| Zasadnicze wymagania i kluczowe obowiązki producenta | 15 mln EUR albo 2,5% całkowitego światowego rocznego obrotu – zależnie od tego, która kwota jest wyższa. | Bezpieczeństwo produktu, obsługa podatności, raportowanie z art. 14. |
| Inne obowiązki CRA | 10 mln EUR albo 2% całkowitego światowego rocznego obrotu. | Obowiązki pozostałych uczestników łańcucha dostaw i inne naruszenia rozporządzenia. |
| Informacje nieprawidłowe, niepełne lub wprowadzające w błąd | 5 mln EUR albo 1% całkowitego światowego rocznego obrotu. | Dane przekazywane jednostkom oceniającym zgodność lub organom nadzoru rynku. |
Plan przygotowań firmy do CRA
- Utwórz katalog sprzętu, oprogramowania, komponentów, wersji i modeli sprzedaży.
- Dla każdego produktu ustal zakres CRA, rolę firmy oraz kategorię oceny zgodności.
- Zmapuj komponenty, zależności, dostawców i informacje potrzebne do obsługi podatności.
- Włącz analizę ryzyka i wymagania security by design do procesu rozwoju produktu.
- Ustal okres wsparcia, zasady aktualizacji i skoordynowanego ujawniania podatności.
- Przygotuj raportowanie przez ENISA przed 11 września 2026 r.
- Zapewnij dokumentację techniczną, ocenę zgodności, deklarację UE i oznakowanie CE.
- Zaktualizuj umowy z twórcami, producentami kontraktowymi, importerami i dystrybutorami.
Checklista gotowości do aktu o cyberodporności
Zaznaczenie punktu powinno oznaczać, że organizacja nie tylko podjęła decyzję, lecz posiada jej aktualny i możliwy do okazania dowód.
FAQ: akt o cyberodporności CRA
Czy CRA dotyczy każdego software house’u?
Nie. Software house wykonujący wyłącznie usługę na zlecenie nie zawsze będzie producentem. Jeżeli jednak rozwija własny produkt, oferuje go pod swoją nazwą albo przyjmuje odpowiedzialność za produkt klienta, może podlegać obowiązkom producenta. Zakres zależy również od umowy i modelu udostępniania.
Czy aplikacja mobilna jest produktem z elementami cyfrowymi?
Może nim być. Samodzielne oprogramowanie udostępniane na rynku UE i przeznaczone do używania w połączeniu z urządzeniem lub siecią mieści się w szerokiej definicji produktu z elementami cyfrowymi, o ile nie zachodzi szczególne wyłączenie.
Czy zwykła usługa SaaS podlega CRA?
Nie automatycznie. SaaS może zostać objęty jako rozwiązanie zdalnego przetwarzania danych, gdy jest rozwijany przez producenta lub na jego odpowiedzialność i bez niego produkt nie mógłby wykonywać jednej ze swoich funkcji. Niezależna usługa chmurowa wymaga odrębnej kwalifikacji.
Czy importer urządzeń z Chin odpowiada za zgodność?
Tak. Importer wprowadzający produkt producenta spoza UE musi przed wprowadzeniem go na rynek sprawdzić spełnienie wymagań, dokumentację, oznakowanie CE i dane identyfikacyjne. Nie powinien udostępniać produktu, jeżeli ma podstawy uważać, że jest niezgodny.
Kiedy dystrybutor staje się producentem?
Między innymi wtedy, gdy wprowadza produkt na rynek pod własną nazwą lub znakiem towarowym albo dokonuje istotnej modyfikacji produktu już wprowadzonego na rynek. Wówczas przejmuje obowiązki producenta w zakresie objętym CRA.
Czy darmowy program może podlegać CRA?
Tak, ponieważ brak ceny nie zawsze oznacza brak działalności komercyjnej. Znaczenie ma cały model gospodarczy, w tym odpłatna wersja produktu, sprzedaż usług powiązanych, wykorzystanie pod własną marką lub monetyzacja danych. FOSS rozwijany poza działalnością komercyjną korzysta z wyłączenia.
Czy certyfikat ISO 27001 potwierdza zgodność z CRA?
Nie. ISO 27001 wspiera zarządzanie bezpieczeństwem organizacji, ale CRA stawia wymagania konkretnemu produktowi i jego cyklowi życia. Potrzebne są m.in. kwalifikacja produktu, ocena zgodności, dokumentacja techniczna, obsługa podatności i oznakowanie CE.
Czy oznakowanie CE będzie obowiązkowe dla oprogramowania?
Dla objętych CRA produktów z elementami cyfrowymi producent po przeprowadzeniu właściwej oceny zgodności sporządza deklarację zgodności UE i umieszcza oznakowanie CE zgodnie z zasadami rozporządzenia. Sposób prezentacji może zależeć od postaci produktu.
Czy CRA obejmie produkty sprzedane przed 11 grudnia 2027 r.?
Obowiązki produktowe stosuje się co do zasady do wcześniejszych produktów, gdy po tej dacie zostaną istotnie zmodyfikowane. Obowiązki raportowania z art. 14 obowiązują jednak od 11 września 2026 r. także w odniesieniu do objętych CRA produktów wprowadzonych wcześniej.
Kto raportuje podatności od 11 września 2026 r.?
Obowiązek raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu spoczywa przede wszystkim na producencie. Zgłoszenia będą przekazywane przez jednolitą platformę raportowania ENISA.
Sprawdź, czy Twoja firma i produkt podlegają CRA
Wypełnij formularz bezpłatnej konsultacji i krótko opisz produkt, model sprzedaży oraz rolę firmy w łańcuchu dostaw. Zweryfikujemy, które elementy wymagają dalszej analizy pod kątem CRA i od czego rozpocząć przygotowania.