Co trzeba zrobić, aby spełnić wymagania CRA?

Nie wypuszczasz już po prostu produktu na rynek. Zobowiązujesz się utrzymywać go przez kolejne 5-10 lat. Akt o cyberodporności (CRA) zmienia cyberbezpieczeństwo z funkcji produktu w odpowiedzialność prawną. Oto co to oznacza dla Twojego produktu, Twojej organizacji i Twojego modelu biznesowego.

CRA w jednym akapicie

CRA (rozporządzenie 2024/2847) sprawia, że cyberbezpieczeństwo staje się wymogiem prawnym dla każdego produktu z elementami cyfrowymi sprzedawanego w UE. Sprzęt, oprogramowanie, IoT - jeśli produkt ma połączenie do przesyłania danych i sprzedajesz go w Europie, CRA ma zastosowanie. Pełna zgodność do grudnia 2027 r. Zgłaszanie podatności od września 2026 r. Kary do 15 mln EUR lub 2,5% światowego obrotu.

Tyle o kiju. Reszta artykułu to mapa drogowa.

Co tak naprawdę zmienia CRA

Przed CRA cyberbezpieczeństwo było przewagą konkurencyjną. Po CRA jest warunkiem dostępu do rynku. Ta różnica zmienia trzy rzeczy:

Koszt cyklu życia produktu

Każdy produkt podłączony do sieci ciągnie teraz za sobą co najmniej 5 lat utrzymywania bezpieczeństwa. W IoT oznacza to infrastrukturę aktualizacji OTA, monitorowanie podatności, testowanie i wdrażanie poprawek, i to nie jako miły dodatek, tylko jako obowiązek prawny. Jeśli sprzedajesz czujnik za 50 EUR i musisz dbać o jego bezpieczeństwo przez 5 lat, Twoja ekonomika jednostkowa zmienia się od podstaw. Produkt, który wysyłasz do klientów pierwszego dnia, to początek zobowiązania kosztowego, a nie jego koniec.

Czas wejścia na rynek

Wymagania bezpieczeństwa, modelowanie zagrożeń i dokumentacja przesuwają się z etapu „przed premierą” na etap „przed projektowaniem”. Architektura bezpieczeństwa trafia teraz do pierwszego sprintu, a nie do ostatniego. Dla zespołów IoT przyzwyczajonych do szybkiego wypuszczania produktu i łatania go później to zmiana kultury pracy. Ocena zgodności (samoocena albo ocena przez stronę trzecią) wydłuża czas, zanim umieścisz oznakowanie CE i zaczniesz sprzedawać. W przypadku produktów klasy II ocena przez stronę trzecią oznacza od kilku tygodni do kilku miesięcy oczekiwania na jednostkę notyfikowaną.

Bariera wejścia

Mały zespół, który wypuszcza urządzenie podłączone do sieci przy minimalnym budżecie? CRA podnosi poprzeczkę. Zanim pojawi się pierwszy klient, potrzebujesz procesu obsługi podatności, opublikowanej polityki ujawniania podatności, SBOM, infrastruktury aktualizacji i dokumentacji technicznej. Dla MŚP to nie jest niemożliwe (EN 303 645 zaprojektowano tak, żeby dało się ją spełnić), ale przestało być opcjonalne. Na drodze z garażu na rynek stoi teraz punkt kontroli zgodności.

Trzy filary zgodności z CRA

Większość zespołów skupia się na produkcie. To filar pierwszy. CRA wymaga jednak trzech elementów działających razem:

Produkt - bezpieczny od etapu projektu, przetestowany, udokumentowany
Organizacja - zdolna do obsługi podatności, zarządzania dostawcami i utrzymywania bezpieczeństwa
Procesy - ciągłe, a nie jednorazowe. Trudne nie jest osiągnięcie zgodności. Trudne jest jej utrzymanie.

Bez któregokolwiek z nich nie spełniasz wymagań.

Filar 1 - produkt

Wymagania bez wyjątków

Każdy produkt podłączony do sieci musi spełnić wszystkie poniższe wymagania. Nie ma czegoś takiego jak częściowa zgodność.

Bezpieczne ustawienia domyślne - żadnych domyślnych haseł. Nieużywane interfejsy wyłączone. Minimalna powierzchnia ataku od razu po wyjęciu z pudełka. W IoT oznacza to, że każde urządzenie we flocie liczącej tysiące sztuk trafia do klienta z unikalnymi danymi uwierzytelniającymi. Provisioning na dużą skalę staje się wymogiem bezpieczeństwa, a nie tylko ułatwieniem w produkcji.

Szyfrowanie - dane szyfrowane w spoczynku i w transmisji. W IoT obejmuje to telemetrię z czujników, komendy wysyłane do elementów wykonawczych i paczki z aktualizacjami firmware. „To tylko dane o temperaturze” nie jest wymówką: jeśli kanał da się przejąć, żeby wgrać złośliwy firmware, same dane przestają mieć znaczenie.

Kontrola dostępu - uwierzytelnianie na każdym interfejsie. W IoT oznacza to komunikację urządzenie-chmura, urządzenie-urządzenie i lokalne porty debugowania. Zapomniana konsola UART z dostępem roota oznacza, że to wymaganie nie jest spełnione.

Integralność oprogramowania - secure boot. Firmware weryfikowany przed uruchomieniem. W urządzeniach IoT o ograniczonych zasobach sprzętowych trzeba to uwzględnić już przy wyborze układu, a nie doklejać później.

Odporność i minimalizacja - odporność na ataki DoS. Ograniczenie wpływu na sąsiednie urządzenia w razie przejęcia. Zbieranie tylko tych danych, które są potrzebne do realizacji celu produktu. We flotach IoT jedno przejęte urządzenie nie może stać się punktem wyjścia do ataku na resztę sieci.

Która norma to potwierdza?

Twój produkt	Norma	Jak to wykazać
Konsumenckie IoT inteligentny dom, urządzenia ubieralne, technologie dla handlu	EN 303 645	Przypadki testowe ETSI TS 103 701
Przemysł / OT SCADA, sterowniki PLC, fabryki	IEC 62443-4-1 + 4-2	Certyfikacja na poziom bezpieczeństwa (Security Level) 1-4
Energetyka inteligentne liczniki, sieć energetyczna, ładowanie pojazdów elektrycznych	IEC 62443 + IEC 62351	Certyfikacja + zgodność protokołów
Motoryzacja sterowniki ECU, telematyka, łączność	ISO/SAE 21434 + UNECE R155/R156	Audyt dostawcy przeprowadzany przez OEM
Medycyna monitorowanie pacjentów, bramki medyczne	IEC 81001-5-1	Jednostka notyfikowana w ramach MDR
Produkty krytyczne moduły HSM, układy TPM, karty inteligentne	Common Criteria (ISO/IEC 15408)	Ocena EAL w akredytowanym laboratorium

Twoja ścieżka oceny zgodności

Klasyfikacja	Ocena zgodności	Przykłady IoT
Domyślna	Samoocena	Większość czujników, elementów wykonawczych i prostych urządzeń podłączonych do sieci
Ważne, klasa I	Samoocena, JEŚLI stosujesz normę zharmonizowaną	Routery, kamery do inteligentnego domu, inteligentne zamki, elektroniczne nianie
Ważne, klasa II	Wymagana ocena przez stronę trzecią. Zawsze.	Firewalle, przemysłowe bramki IoT, mikrokontrolery odporne na manipulacje
Krytyczne (załącznik IV)	Europejska certyfikacja cyberbezpieczeństwa	Moduły HSM, elementy zabezpieczające (secure elements), bramki inteligentnych liczników

Filar 2 - organizacja

CRA pyta: „Czy ten producent jest w stanie utrzymać bezpieczeństwo produktu przez cały cykl jego życia?”

Obsługa podatności

Potrzebujesz wyznaczonego właściciela bezpieczeństwa. Nie „zespół deweloperski się tym zajmie”. Konkretnej osoby albo zespołu, który odpowiada za cały proces od początku do końca:

Opublikowana polityka ujawniania podatności z publicznym punktem kontaktowym i gwarancją bezpieczeństwa prawnego (safe harbour) dla zgłaszających
Proces przyjmowania zgłoszeń, triażu i klasyfikacji powagi podatności
Zdolność do przygotowania i dystrybucji poprawek

W IoT oznacza to łatanie w skali całej floty. Gdy pojawi się podatność, czy jesteś w stanie wysłać aktualizację do 10 000 urządzeń w terenie? A do 100 000? Czy wiesz, na którym urządzeniu działa która wersja firmware? Zarządzanie flotą urządzeń staje się kluczowe, nie ze względu na funkcje, ale ze względu na zgodność w obszarze bezpieczeństwa.

Zgłaszanie do organów (od września 2026 r.)

Wykryto aktywnie wykorzystywaną podatność:

24 godziny na powiadomienie CSIRT (Computer Security Incident Response Team, każdy kraj ma własny)
72 godziny na szczegółowe zgłoszenie
14 dni na raport końcowy z analizą przyczyny źródłowej.

W IoT „aktywnie wykorzystywana” może oznaczać botnet, który używa Twoich urządzeń. Zegar zaczyna tykać w chwili, gdy się o tym dowiadujesz. Potrzebujesz monitoringu, żeby to wykryć, szablonów, żeby to zgłosić, i kontaktów, pod które trzeba to zgłosić.

SBOM i śledzenie zależności

Pełny spis wszystkich komponentów: bibliotek open source, modułów od podmiotów trzecich, własnego kodu. W formacie do odczytu maszynowego (SPDX lub CycloneDX). Gotowy do przekazania na żądanie.

W IoT sięga to głębiej niż w typowym oprogramowaniu. Twój SBOM obejmuje RTOS, stos sieciowy, bibliotekę kryptograficzną, bootloader i firmware radia. Podatność w bibliotece TLS wbudowanej w firmware Twojego modułu Zigbee to Twój problem. Musisz wiedzieć, że ta biblioteka tam jest, śledzić ją i być gotowym do jej aktualizacji.

Odpowiadasz za każdy komponent, także open source. Weryfikuj zależności. Monitoruj podatności w projektach źródłowych (upstream). Zgłaszaj znalezione błędy opiekunom tych projektów.

Dokumentacja techniczna

Twoja dokumentacja zgodności obejmuje:

Opis produktu i instrukcje dla użytkownika
Architekturę systemu - jak komponenty ze sobą współpracują
Procesy obsługi podatności, SBOM, politykę ujawniania podatności, mechanizm aktualizacji
Ocenę ryzyka cyberbezpieczeństwa (modelowanie zagrożeń - nie jest opcjonalne)
Uzasadnienie okresu wsparcia
Zastosowane normy i ich odniesienie do załącznika I
Raporty z testów
Deklarację zgodności UE

Przechowywana przez 10 lat. W przypadku produktów IoT z 5-letnim okresem wsparcia oznacza to, że dokumentacja żyje 15 lat od pierwszej sprzedaży.

Normy dla organizacji

CRA nie wymaga ISO 27001. Ale klienci będą wymagać.

Kupujący objęci NIS2 (energetyka, ochrona zdrowia, transport, produkcja) muszą weryfikować bezpieczeństwo łańcucha dostaw. Certyfikat ISO/IEC 27001 albo udokumentowana zgodność z tą normą to skrót do tej rozmowy. CRA tego prawnie nie wymaga, ale coraz częściej jest to warunek zapisany w umowach.

Filar 3 - procesy (najtrudniejsza część)

Osiągnięcie zgodności to projekt. Utrzymanie zgodności to stała działalność operacyjna. Tu CRA uderza najmocniej, zwłaszcza w IoT.

Cykl aktualizacji

Co najmniej 5 lat obsługi podatności od daty wprowadzenia do obrotu. Aktualizacje zabezpieczeń dostępne przez co najmniej 10 lat. Bezpłatne. Tam, gdzie to wykonalne, oddzielone od aktualizacji funkcjonalnych. Preferowane aktualizacje automatyczne, domyślnie włączone.

W IoT 5 lat aktualizacji zabezpieczeń oznacza:

Infrastrukturę aktualizacji, która przetrwa Twój zespół produktowy. Inżynierowie, którzy zbudowali wersję 1.0, w trzecim roku mogą już pracować gdzie indziej. Twój pipeline aktualizacji, automatyzacja testów i narzędzia do wdrażania muszą działać bez wiedzy, która istnieje tylko w czyichś głowach. W urządzeniach IoT o ograniczonych zasobach aktualizacje OTA muszą radzić sobie z zawodną łącznością, częściowo pobranymi plikami, rollbackiem w razie niepowodzenia i weryfikacją podpisu, a wszystko to trzeba zaprojektować od pierwszego dnia.
Zarządzanie wersjami w rozdrobnionej flocie. Nie wszystkie urządzenia w terenie będą miały ten sam firmware. Część ominie aktualizacje. Część będzie offline przez miesiące. Musisz wiedzieć, które wersje są wdrożone, które są podatne i które urządzenia nie łączyły się z serwerem. W IoT to nie jest ładny dashboard, tylko wymóg zgodności.
Testowanie na dużą skalę. Każdą poprawkę bezpieczeństwa trzeba przetestować przed wdrożeniem, nie tylko na stole laboratoryjnym, ale z uwzględnieniem różnorodności floty. Różne rewizje sprzętu, różne konfiguracje, różne warunki w terenie. Poprawka, która zamieni w cegłę 1% urządzeń, jest gorsza niż podatność, którą naprawia.
Realia budżetowe. Jeśli sprzedajesz 50 000 czujników po 30 EUR, a utrzymanie bezpieczeństwa kosztuje 2 EUR na urządzenie rocznie, daje to 500 000 EUR w ciągu 5 lat. Czy Twój cennik to uwzględnia? CRA oznacza, że Twój model kosztów musi obejmować działania związane z bezpieczeństwem po sprzedaży. Dla każdego produktu w portfolio. Dla każdego roku okresu wsparcia.

Monitorowanie po wprowadzeniu do obrotu

Aktywne, ciągłe monitorowanie podatności w Twoim kodzie, w Twoich zależnościach i w zintegrowanych komponentach. To nie jest kwartalny przegląd. W IoT nowe CVE w bibliotekach embedded (mbedTLS, lwIP, komponenty FreeRTOS) mogą pojawić się każdego dnia.

Jeśli odkryjesz podatność, przez którą Twój produkt przestaje spełniać wymagania załącznika I, musisz podjąć działania naprawcze albo wycofać produkt z rynku. We flotach IoT „działania naprawcze” oznaczają wysłanie aktualizacji na każde urządzenie, którego problem dotyczy. Jeśli nie możesz do nich dotrzeć, masz problem ze zgodnością, który rośnie z każdym nieosiągalnym egzemplarzem.

Śledzenie zależności jako ciągły proces

Bezpieczeństwo Twojego produktu zależy od jego najsłabszego komponentu. Stos Zigbee zintegrowany dwa lata temu? Biblioteka MQTT przypięta do wersji z 2024 roku? Binarny bootloader od producenta układu?

W IoT śledzenie zależności jest trudniejsze niż w oprogramowaniu chmurowym. Komponenty to często binarne bloby od podmiotów trzecich. Cykle aktualizacji są wolniejsze. Ograniczenia sprzętowe zawężają to, co da się załatać. Potrzebujesz:

Automatycznego generowania SBOM przy każdym buildzie
Ciągłego skanowania podatności w oparciu o znane bazy CVE
Alertów, gdy w zależnościach upstream zostaną ujawnione podatności
Procesu oceny, łatania, testowania i wdrażania, nie raz, ale dla każdego CVE, dla każdego produktu, przez cały okres wsparcia

Oznakowanie CE to ciągła deklaracja

Deklaracja zgodności UE to oświadczenie prawne: „ten produkt spełnia wszystkie wymagania CRA”. Jeśli przestaje to być prawdą (krytyczna podatność, przestarzały algorytm kryptograficzny, koniec życia komponentu, czyli end of life), musisz działać. Oznakowanie CE to nie jednorazowa pieczątka. To obietnica, którą składasz każdego dnia, gdy produkt jest na rynku.

Dla producentów IoT oznacza to, że Twoja zgodność jest tak dobra, jak Twoja ostatnia aktualizacja. Flota urządzeń ze znaną, niezałataną podatnością to flota niezgodnych produktów. W świetle prawa.

Harmonogram

Data	Co się dzieje	Co musisz mieć gotowe
Wrzesień 2026	Rusza obowiązek zgłaszania podatności	Proces zgłaszania, kontakt z CSIRT, szablony, polityka ujawniania podatności, monitoring
Grudzień 2027	Pełna zgodność z CRA	Bezpieczny produkt, kompletna dokumentacja, oznakowanie CE, infrastruktura aktualizacji, działające procesy
Czerwiec 2028	Wygasają dotychczasowe certyfikaty badania typu	Zaktualizowane certyfikaty, jeśli dotyczy
Grudzień 2030	Pierwsze sprawozdanie Komisji z oceny	Liczy się Twoja historia zgodności

Prawdziwy koszt

Zgodność z CRA nie jest droga, jeśli wbudujesz ją od początku. Jest bardzo droga, jeśli doklejasz ją na końcu.

Wbudowanie od początku:

Wymagania bezpieczeństwa w pierwszym sprincie
SBOM generowany automatycznie w CI/CD
Infrastruktura aktualizacji OTA projektowana razem z produktem
Zarządzanie flotą, które śledzi wersje, łączność i stan poprawek
Okres wsparcia uwzględniony w ekonomice jednostkowej od dnia zero
Monitorowanie podatności działające, zanim pierwsze urządzenie trafi do klienta

Łatanie po fakcie:

Gorączkowe dokumentowanie architektury, której nikt nigdy nie spisał
Generowanie SBOM dla produktu z binarnymi blobami i nieśledzonymi zależnościami
Dorabianie aktualizacji OTA do urządzeń zaprojektowanych w modelu „wgraj raz i zapomnij”
Odkrycie, że Twój czujnik za 30 EUR wymaga 5-letniego utrzymania, na które nigdy nie było budżetu
Budowanie zarządzania flotą, żeby śledzić 50 000 urządzeń, do których nigdy wcześniej nie trzeba było docierać

CRA nie zmienia tego, jak wygląda dobra inżynieria IoT. Sprawia tylko, że przestaje ona podlegać negocjacjom. Zespoły, które już robią to dobrze, ledwie zauważą termin. Pozostałe odczują każdy miesiąc.

Dalsza lektura

Pełny tekst CRA (rozporządzenie 2024/2847)
Pełny tekst NIS2 (rozporządzenie 2022/2555)