Czego CRA naprawdę wymaga od małej firmy sprzętowej
Spis treści7 ▾
Po wpisie o obowiązku zgłaszania, który zaczął obowiązywać we wrześniu, najczęściej słyszałem jedno proste pytanie: dobrze, zgłaszać już umiemy, a co poza tym? Większość odpowiedzi krążących w sieci to albo dwuzdaniowe podsumowanie, które kończy się na haśle „secure by design”, albo stustronicowa prezentacja od firmy doradczej. Brakowało mi czegoś pośrodku. Usiadłem więc z rozporządzeniem, załącznikami i lipcowymi wytycznymi Komisji i spisałem każdy obowiązek, jaki faktycznie ma producent urządzenia z łącznością. Tak powstała checklista gotowości, którą znajdziesz na tej stronie. W tym wpisie wyjaśniam, skąd wzięła się jej zawartość.
Dwie daty i każdy egzemplarz z osobna
Firma sprzętowa musi pamiętać o dwóch datach z CRA. Obowiązek zgłaszania z artykułu 14 stosuje się od 11 września 2026 do każdego produktu na rynku UE, także do egzemplarzy sprzedanych lata temu. Cała reszta obowiązuje od 11 grudnia 2027.
O planowaniu decyduje jednak to, co oznacza „wprowadzenie do obrotu”. Wytyczne Komisji mówią wprost, że chodzi o każdy pojedynczy egzemplarz. Model czujnika, który sprzedajesz od 2023 roku, nie dostanie w grudniu 2027 żadnej taryfy ulgowej. Egzemplarze już sprzedane pozostają poza wymaganiami projektowymi, ale każdy, który wyjedzie z magazynu od 11 grudnia 2027, musi spełniać je wszystkie. Jeśli twoja linia produktów będzie wtedy nadal w sprzedaży, wszystko, co opisuję poniżej, jej dotyczy, a przy czasach realizacji w sprzęcie tę pracę trzeba zacząć już teraz.
Ocena ryzyka, na której wisi cała reszta
Artykuł 13 wymaga udokumentowanej oceny ryzyka cyberbezpieczeństwa, która uwzględnia przewidziane zastosowanie produktu, racjonalnie przewidywalne użycie, środowisko, w którym pracuje, i to, jak długo będzie używany. Brzmi to jak papierologia i w pewnym sensie nią jest, ale na tym dokumencie opiera się cała reszta rozporządzenia. Dla każdej z trzynastu właściwości bezpieczeństwa z załącznika I ocena musi wskazać, w jaki sposób ją spełniasz albo dlaczego nie ma ona zastosowania. Wymaganie, które po prostu pominiesz, organ nadzoru rynku znajdzie najłatwiej.
W tej ocenie musi się znaleźć także backend. CRA traktuje zdalne przetwarzanie danych, którego urządzenie potrzebuje do realizacji swoich funkcji, jako część produktu, więc API, konfiguracja brokera MQTT i usługa provisioningu podlegają regulacji na równi z firmware.
Trzynaście właściwości
Kiedy pierwszy raz przeczytałem część I załącznika I, odetchnąłem z ulgą. Większość wymagań opisuje to, co staranny zespół IoT i tak już robi. Produkt nie może trafić na rynek ze znanymi podatnościami, które da się wykorzystać. Ma być domyślnie bezpieczny i pozwalać na przywrócenie urządzenia do stanu pierwotnego. Ma chronić przed nieuprawnionym dostępem, co w praktyce oznacza osobne dane uwierzytelniające dla każdego urządzenia i uwierzytelnione interfejsy lokalne. Kilka dni temu pisałem o jednym ze sposobów na nadanie urządzeniom unikalnych tożsamości na linii produkcyjnej. Ma chronić poufność i integralność danych, poleceń, firmware i konfiguracji, czyli w praktyce TLS, secure boot i podpisane obrazy. Ma wreszcie ograniczać powierzchnię ataku, co w urządzeniu oznacza zablokowane w produkcji porty JTAG i UART oraz usunięte endpointy testowe.
Kilka z tych trzynastu wymagań jest mniej oczywistych i warto przeczytać je uważnie. Aktualizacje bezpieczeństwa muszą być w ogóle możliwe, a tam, gdzie ma to zastosowanie, powinny domyślnie instalować się automatycznie w odpowiednim terminie, z jasną możliwością rezygnacji, powiadomieniem o dostępnej aktualizacji i opcją jej odłożenia. To w równym stopniu decyzja produktowa, co kwestia firmware, i lepiej podjąć ją teraz, bo późniejsza zmiana zachowania aktualizacji na całej flocie jest bolesna. Jak bezpiecznie aktualizować dużą flotę, opisałem we wcześniejszym wpisie. Produkt musi też rejestrować i monitorować istotną aktywność wewnętrzną, na przykład dostęp do danych i funkcji albo ich zmiany, i dawać użytkownikowi możliwość wyłączenia tego. Musi pozwalać użytkownikom trwale usunąć wszystkie swoje dane i ustawienia. Do tego musi ograniczać swój negatywny wpływ na inne urządzenia i sieci, co przy flocie sprowadza się głównie do ponownego łączenia z backoffem i jitterem, żeby po awarii dziesięć tysięcy urządzeń nie uderzyło w usługę w tej samej sekundzie.
Obsługa podatności przez lata
Część II załącznika I dotyczy procesów. Dla każdego wydania potrzebujesz SBOM-u w powszechnie stosowanym formacie nadającym się do odczytu maszynowego, który obejmuje co najmniej zależności najwyższego poziomu. Podatności usuwasz bez zbędnej zwłoki, a jeśli jest to technicznie wykonalne, poprawki bezpieczeństwa wydajesz osobno od nowych funkcji. Regularnie testujesz bezpieczeństwo produktu. Kiedy poprawka jest już dostępna, publikujesz informację o tym, na czym polegała podatność, których produktów dotyczy, jak jest poważna i co powinni zrobić użytkownicy. Prowadzisz politykę skoordynowanego ujawniania podatności i podajesz publicznie kontakt, pod który można zgłaszać problemy, także w komponentach zewnętrznych zintegrowanych z twoim produktem. Aktualizacje trzeba dystrybuować w bezpieczny sposób, a aktualizacje bezpieczeństwa udostępniać bezpłatnie, razem z komunikatem, co użytkownicy mają zrobić.
W artykule 13 łatwo przeoczyć dwie liczby. Okres wsparcia musi wynosić co najmniej pięć lat, a dłużej, jeśli produkt ma być dłużej używany, i jego datę końcową, co najmniej z dokładnością do miesiąca i roku, trzeba podać w momencie zakupu. Każda opublikowana aktualizacja bezpieczeństwa musi potem pozostać dostępna przez co najmniej dziesięć lat albo przez resztę okresu wsparcia, w zależności od tego, który okres jest dłuższy. Jeśli serwer aktualizacji i klucze do podpisywania nie są zaplanowane na taki horyzont, czas to zmienić.
Dokumenty, ocena zgodności i oznakowanie CE
Załącznik II wymienia, co muszą zawierać informacje dla użytkownika, od kontaktu do zgłaszania podatności i daty końca wsparcia po instrukcje bezpiecznej konfiguracji, aktualizacji i wycofania urządzenia z użytku. Załącznik VII opisuje dokumentację techniczną, która zbiera w jednym miejscu opis produktu, architekturę, procesy obsługi podatności, ocenę ryzyka, uzasadnienie długości okresu wsparcia, raporty z testów i deklarację zgodności. Jedno i drugie trzeba przechowywać przez dziesięć lat albo przez okres wsparcia, jeśli jest dłuższy.
Sposób wykazania zgodności zależy od kategorii produktu. Produkt z kategorii domyślnej, do której należy większość czujników, trackerów i sterowników, możesz ocenić sam w ramach kontroli wewnętrznej. Ważne produkty klasy I mogą skorzystać z tej ścieżki tylko wtedy, gdy w pełni stosują normy zharmonizowane, wspólne specyfikacje albo program certyfikacji. Normy zharmonizowane dla CRA są wciąż na etapie finalizacji, więc w praktyce wielu producentów produktów klasy I powinno zaplanować współpracę z jednostką notyfikowaną. Klasa II wymaga jej zawsze, a produkty krytyczne, takie jak bramki inteligentnych liczników, mogą potrzebować europejskiego certyfikatu. Przepisy dotyczące jednostek notyfikowanych stosuje się od czerwca 2026 i spodziewam się, że ich kalendarze zapełnią się na długo przed grudniem 2027. Na końcu jest deklaracja zgodności UE i oznakowanie CE, a u większości z nas CRA trafi do jednej deklaracji razem z dyrektywą w sprawie urządzeń radiowych.
Kary warto znać, nawet jeśli nikt nie zamierza ich płacić. Naruszenie zasadniczych wymagań albo obowiązków z artykułów 13 i 14 może kosztować do piętnastu milionów euro lub dwóch i pół procent światowego obrotu, w zależności od tego, która kwota jest wyższa.
Od czego bym zaczął
Gdybym dziś odpowiadał za inżynierię w małej firmie sprzętowej, zacząłbym od zgłaszania, bo ten obowiązek już się stosuje, a dotyczy głównie ludzi i kont. Zarejestrowałbym firmę na platformie ENISA, ustalił, kto podejmuje decyzję o drugiej w nocy, sprawdził, które wersje firmware działają w których krajach, i uruchomił codzienne porównywanie SBOM-ów z listami aktywnie wykorzystywanych podatności.
Potem wziąłbym się za wszystko, co wymaga zmian w firmware albo w sprzęcie, bo to zajmuje całe cykle produktowe. Chodzi o secure boot, podpisane aktualizacje z ochroną przed rollbackiem, osobne dane uwierzytelniające dla każdego urządzenia, zablokowane porty debugowania i SBOM generowany przez build. Jeśli do zmieszczenia secure elementu albo zablokowania interfejsu debugowania potrzebna będzie nowa rewizja płytki, dużo taniej jest dowiedzieć się o tym w 2026 niż pod koniec 2027.
Dokumentację zostawiłbym na koniec, bo idzie znacznie szybciej, kiedy część inżynierska już istnieje. Ocena ryzyka pisana po podjęciu decyzji projektowych w większości spisuje powody, które i tak już miałeś. Dokumentacja techniczna składana z pipeline'u, który przy każdym wydaniu generuje SBOM-y i raporty z testów, to głównie linki.
Checklista
Wszystko to zebrałem w checkliście gotowości. Trzy pytania o produkt dopasowują ją do twojej sytuacji, a potem każdą pozycję możesz oznaczyć jako zrobioną, w toku, do zrobienia albo niedotyczącą. Przy każdej jest odwołanie do artykułu lub załącznika, z którego pochodzi. Checklista działa w przeglądarce, odpowiedzi zostają na twoim urządzeniu, a na koniec dostajesz raport luk w Markdownie, z którym możesz pójść do zespołu. Jeśli nie masz jeszcze pewności, czy CRA w ogóle obejmuje twój produkt, zacznij od sprawdzenia zakresu.
Nic z tego nie jest poradą prawną, a normy zharmonizowane, kiedy zostaną opublikowane, doprecyzują, jak spełniać poszczególne wymagania. Sama struktura obowiązków wynika jednak bezpośrednio z rozporządzenia i nie będzie się zmieniać. Jeśli twój zespół patrzy na tę listę i zastanawia się, od czego zacząć, chętnie pomogę.