CRA, RED DA i EN 18031: praktyczny przewodnik gotowości dla producentów elektroniki

Elektronika połączona wprowadzana na rynek Unii Europejskiej wchodzi w nowy cykl wymagań dotyczących cyberbezpieczeństwa. Akt delegowany do dyrektywy w sprawie urządzeń radiowych (RED DA) ma już zastosowanie do określonych urządzeń radiowych, natomiast Cyber Resilience Act (CRA) wprowadza szersze wymagania dla produktów z elementami cyfrowymi oraz ich producentów.

Dla producenta elektroniki gotowość nie jest ćwiczeniem certyfikacyjnym wykonywanym w ostatniej chwili. Oznacza zdolność wykazania za pomocą kontrolowanych dowodów, że ryzyka cyberbezpieczeństwa uwzględniano od planowania produktu, przez projektowanie, produkcję i dostawę, aż po wsparcie po wprowadzeniu produktu na rynek.

Ten przewodnik wyjaśnia, jak łączą się CRA, RED DA i EN 18031, co zmieni się 11 grudnia 2027 roku oraz co zespoły OEM i EMS powinny wdrożyć już teraz.

Ostatni przegląd: 9 września 2026

Mapa regulacyjna

CRA i RED DA są ze sobą powiązane, ale nie są zamienne.

• CRA oznacza Rozporządzenie (UE) 2024/2847, czyli Cyber Resilience Act. Ustanawia ono horyzontalne wymagania cyberbezpieczeństwa dla sprzętowych i programowych produktów z elementami cyfrowymi.
• RED oznacza Dyrektywę 2014/53/UE w sprawie urządzeń radiowych.
• RED DA to powszechnie używane określenie Rozporządzenia Delegowanego Komisji (UE) 2022/30. Uruchomiło ono wymagania cyberbezpieczeństwa z art. 3 ust. 3 lit. d), e) i f) RED dla określonych kategorii urządzeń radiowych.
• EN 18031-1, EN 18031-2 i EN 18031-3 są normami zharmonizowanymi wspierającymi te wymagania cyberbezpieczeństwa RED. Nie są normami zharmonizowanymi dla CRA.

Kluczowe daty

Uchylenie nie usuwa okresu obowiązywania RED DA. Nadzór rynku na podstawie RED może nadal badać urządzenia radiowe wprowadzone na rynek UE między 1 sierpnia 2025 a 10 grudnia 2027 roku pod kątem wymagań cyberbezpieczeństwa mających wtedy zastosowanie.

Produkty wprowadzone na rynek przed 11 grudnia 2027 roku zasadniczo podlegają głównym wymaganiom produktowym CRA tylko wtedy, gdy od tej daty przejdą istotną modyfikację. Inaczej jest z raportowaniem na podstawie art. 14 CRA: dotyczy ono także produktów objętych zakresem, które wprowadzono na rynek przed 11 grudnia 2027 roku.

Które produkty mogą podlegać wymaganiom?

Zakres CRA zaczyna się od produktu i jego połączenia

CRA obejmuje programowe lub sprzętowe produkty z elementami cyfrowymi, w tym sprzedawane oddzielnie komponenty programowe lub sprzętowe oraz niektóre rozwiązania zdalnego przetwarzania danych. Zakres ma zastosowanie, gdy zamierzone lub racjonalnie przewidywalne użycie obejmuje bezpośrednie albo pośrednie, logiczne albo fizyczne połączenie danych z urządzeniem lub siecią, a produkt jest udostępniany na rynku UE w ramach działalności handlowej.

Może to obejmować:

• połączone sterowniki, bramy i urządzenia telemetryczne;
• sieciowe urządzenia przemysłowe i systemy wbudowane;
• oprogramowanie desktopowe, mobilne i połączone z chmurą;
• sprzedawane oddzielnie firmware, biblioteki i komponenty sprzętowe;
• usługę backendową zaprojektowaną przez producenta lub na jego odpowiedzialność, bez której produkt nie może wykonywać jednej ze swoich funkcji.

Interfejs radiowy nie jest warunkiem objęcia zakresem CRA. Znaczenie mogą mieć Ethernet, USB, interfejs serwisowy, łączność przez magistralę przemysłową albo pośrednie połączenie przez inny system. Z drugiej strony sama obecność mikrokontrolera nie rozstrzyga o zakresie. Należy ocenić kompletny produkt, przeznaczenie, racjonalnie przewidywalne użycie, sposób połączenia i handlowe wprowadzenie na rynek.

CRA zawiera również wyłączenia i szczególne zasady dla obszarów już regulowanych przepisami sektorowymi. Wyroby medyczne objęte Rozporządzeniami (UE) 2017/745 i 2017/746, niektóre produkty motoryzacyjne i lotnicze, wyposażenie morskie oraz produkty opracowane wyłącznie do celów bezpieczeństwa narodowego lub obronności wymagają odrębnej analizy prawnej, a nie założenia, że CRA stosuje się w pełnym zakresie.

Zakres RED DA jest węższy i oparty na kategoriach

Do czasu wejścia w życie uchylenia RED DA ma zastosowanie wyłącznie do kategorii urządzeń radiowych wskazanych w Rozporządzeniu (UE) 2022/30:

• art. 3 ust. 3 lit. d) RED: ochrona sieci ma zastosowanie do urządzeń radiowych połączonych z internetem;
• art. 3 ust. 3 lit. e) RED: dane osobowe i prywatność ma zastosowanie do urządzeń radiowych połączonych z internetem i przetwarzających odpowiednie dane oraz do określonych urządzeń radiowych dla opieki nad dziećmi, zabawek i urządzeń ubieralnych, które przetwarzają takie dane;
• art. 3 ust. 3 lit. f) RED: ochrona przed oszustwami ma zastosowanie do urządzeń radiowych połączonych z internetem, które umożliwiają transfer pieniędzy, wartości pieniężnej lub waluty wirtualnej.

Należy również sprawdzić wyłączenia z Rozporządzenia (UE) 2022/30. Przykładowo urządzenia radiowe regulowane Rozporządzeniem w sprawie wyrobów medycznych lub Rozporządzeniem w sprawie wyrobów medycznych do diagnostyki in vitro są wyłączone ze wszystkich trzech uruchomionych wymagań. Inne wyłączenia sektorowe ograniczają się do konkretnych wymagań.

Klasyfikuj produkt CRA po potwierdzeniu zakresu

Większość produktów objętych CRA podlega domyślnej ścieżce oceny zgodności. Produkt jest ważnym produktem z elementami cyfrowymi tylko wtedy, gdy jego podstawowa funkcja mieści się w kategorii z załącznika III CRA. Załącznik III dzieli ważne produkty na klasę I i klasę II. Załącznik IV CRA zawiera odrębny wykaz krytycznych produktów z elementami cyfrowymi.

Nie należy klasyfikować kompletnego urządzenia przemysłowego jako ważnego lub krytycznego wyłącznie dlatego, że zawiera wymieniony komponent. Artykuł 7 stanowi, że integracja produktu z wykazu sama w sobie nie przenosi tej klasyfikacji na produkt zawierający. Podstawowa funkcja i właściwe definicje prawne muszą zostać udokumentowane.

Co gotowość do CRA oznacza w praktyce

Gotowość do CRA to kontrolowany cykl życia produktu, a nie folder tworzony przed audytem.

1. Udokumentowana ocena ryzyka cyberbezpieczeństwa

Producent musi ocenić ryzyka cyberbezpieczeństwa i wykorzystywać wynik przez cały proces planowania, projektowania, rozwoju, produkcji, dostawy i utrzymania. Ocena powinna wskazywać co najmniej:

• przeznaczenie oraz racjonalnie przewidywalne użycie lub niewłaściwe użycie;
• środowisko operacyjne i interfejsy zewnętrzne;
• zasoby wymagające ochrony, w tym poświadczenia, dane osobowe, konfigurację, firmware i dostępność usług;
• scenariusze zagrożeń i założenia bezpieczeństwa;
• wymagania załącznika I CRA mające i niemające zastosowania wraz z uzasadnieniem;
• wybrane środki kontroli, ryzyka rezydualne i dowody weryfikacji.

Ocena jest częścią dokumentacji technicznej i musi być aktualizowana, gdy istotne informacje, podatności lub zmiany produktu wpływają na obraz ryzyka.

2. Zabezpieczenia security-by-design i security-by-default

W zależności od oceny ryzyka załącznik I CRA wymaga uwzględnienia takich środków jak:

• brak znanych podatności możliwych do wykorzystania w chwili wprowadzenia produktu na rynek;
• bezpieczna konfiguracja domyślna i możliwość przywrócenia bezpiecznego stanu początkowego;
• odpowiednie uwierzytelnianie i kontrola dostępu;
• poufność i integralność danych przechowywanych, przesyłanych i przetwarzanych;
• minimalizacja danych;
• ochrona podstawowych funkcji i ograniczenie powierzchni ataku;
• rejestrowanie lub monitorowanie zdarzeń bezpieczeństwa, gdy jest to właściwe;
• bezpieczne usuwanie danych i ustawień użytkownika;
• aktualizacje bezpieczeństwa, z automatyczną instalacją domyślnie włączoną tam, gdzie ma to zastosowanie, oraz z jasnym mechanizmem rezygnacji.

Sformułowanie „w stosownych przypadkach” nie usuwa potrzeby posiadania dowodów. Jeżeli wymaganie uznano za niemające zastosowania, dokumentacja techniczna powinna wyjaśniać dlaczego w kontekście ryzyk i przeznaczenia produktu.

3. Kontrola komponentów stron trzecich i SBOM

Producenci pozostają odpowiedzialni za należytą staranność przy integracji komponentów stron trzecich, w tym wolnego i otwartego oprogramowania. Użyteczny Software Bill of Materials (SBOM) powinien być czytelny maszynowo, wersjonowany i powiązany z dokładną konfiguracją wydanego produktu.

SBOM jest danymi wejściowymi do zarządzania podatnościami, a nie samodzielnym dowodem zgodności. Proces operacyjny musi również odpowiadać na pytania:

• Kto monitoruje biuletyny i źródła informacji o podatnościach?
• Jak komponent jest dopasowywany do wersji produktu, których dotyczy problem?
• Kto ocenia możliwość wykorzystania podatności i jej wpływ na produkt?
• Jak poprawki są testowane, zatwierdzane i dystrybuowane?
• Jak zachowywane są dowody dla każdego wydania i okresu wsparcia?

Gdy producent zidentyfikuje podatność w zintegrowanym komponencie, art. 13 ust. 6 CRA wymaga również zgłoszenia jej producentowi lub opiekunowi komponentu oraz, gdy jest to właściwe, udostępnienia opracowanej poprawki lub odpowiedniej dokumentacji.

4. Obsługa podatności przez zadeklarowany okres wsparcia

Okres wsparcia musi uwzględniać oczekiwany czas używania, uzasadnione oczekiwania użytkowników, charakter produktu i inne czynniki wskazane w CRA. Zasadniczo wynosi co najmniej pięć lat, chyba że oczekiwany czas używania produktu jest krótszy niż pięć lat. Długowieczne produkty przemysłowe mogą wymagać dłuższego okresu.

Data zakończenia okresu wsparcia, obejmująca co najmniej miesiąc i rok, musi zostać jasno przekazana w chwili zakupu. Aktualizacje bezpieczeństwa wydane w okresie wsparcia muszą pozostać dostępne przez co najmniej dziesięć lat od wydania albo przez pozostałą część okresu wsparcia, w zależności od tego, który okres jest dłuższy.

5. Raportowanie incydentów i aktywnie wykorzystywanych podatności

Od 11 września 2026 roku producenci muszą zgłaszać za pośrednictwem jednolitej platformy raportowania CRA:

• aktywnie wykorzystywaną podatność: wczesne ostrzeżenie w ciągu 24 godzin, informacje uzupełniające w ciągu 72 godzin oraz raport końcowy nie później niż 14 dni po udostępnieniu środka naprawczego lub ograniczającego ryzyko;
• poważny incydent wpływający na bezpieczeństwo produktu: wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy w ciągu miesiąca od zgłoszenia incydentu.

Bieg terminu zaczyna się, gdy producent uzyska wiedzę o zdarzeniu, a nie po zakończeniu wewnętrznego dochodzenia. Umowy z projektantami, dostawcami komponentów, firmami EMS i operatorami usług muszą zatem zawierać ścieżki eskalacji wystarczająco szybkie, aby chronić termin raportowania producenta.

RED DA i EN 18031

EN 18031 zapewnia ustrukturyzowaną metodę oceny wymagań cyberbezpieczeństwa RED w okresie przejściowym RED DA:

Normy zharmonizowane, ale z ograniczeniami

Decyzja Wykonawcza Komisji (UE) 2025/138 opublikowała odniesienia do EN 18031 z ograniczeniami. W praktyce znaczenie mają trzy kwestie:

1. Sekcje oznaczone jako „rationale” i „guidance” nie dają domniemania zgodności. Pomagają w interpretacji, ale nie są specyfikacjami normatywnymi.
2. EN 18031-1, -2 i -3 nie dają domniemania zgodności, jeżeli punkty 6.2.5.1 i 6.2.5.2 są stosowane w sposób pozwalający użytkownikowi nie ustawić i nie używać żadnego hasła.
3. Dodatkowe ograniczenia dotyczą kontroli dostępu rodzica lub opiekuna w EN 18031-2 oraz kryteriów oceny bezpiecznej aktualizacji w punkcie 6.3.2.4 EN 18031-3.

Używanie listy kontrolnej EN 18031 bez przeczytania komunikatów opublikowanych w Dzienniku Urzędowym może prowadzić do fałszywego wniosku o zgodności. Dokumentacja produktu powinna wskazywać dokładne wydanie normy, właściwe wymaganie, drzewo decyzyjne, kategorię implementacji, wynik testu oraz każde ograniczenie wpływające na deklarowane domniemanie zgodności.

EN 18031 pomaga w przygotowaniu do CRA, ale nie jest dowodem zgodności z CRA

Wiele zabezpieczeń z EN 18031 stanowi użyteczny wkład inżynierski do gotowości CRA, w tym kontrola dostępu, uwierzytelnianie, bezpieczne aktualizacje, ochrona zasobów i odporność sieci. Normy zostały jednak zharmonizowane dla konkretnych wymagań art. 3 ust. 3 lit. d), e) i f) RED. Nie obejmują automatycznie całego cyklu życia z załącznika I CRA, obsługi podatności, raportowania, okresu wsparcia, informacji dla użytkownika i obowiązków dokumentacji technicznej.

Producent może ponownie wykorzystać dowody z EN 18031 w dokumentacji CRA tam, gdzie są właściwe, ale powinien utrzymywać odrębną matrycę identyfikowalności wskazującą, czego dowodzi dany materiał i które wymagania CRA nadal potrzebują dodatkowych zabezpieczeń lub zapisów.

Ocena zgodności i oznakowanie CE

W ramach RED w okresie przejściowym

Ścieżka oceny zgodności RED zależy od tego, czy w pełni zastosowano normy zharmonizowane obejmujące wszystkie właściwe wymagania zasadnicze. Jeżeli odpowiednie normy zharmonizowane nie zostały zastosowane, zastosowano je tylko częściowo, nie istnieją lub nie obejmują wszystkich właściwych wymagań, RED wymaga ścieżki oceny obejmującej badanie typu UE, po którym następuje zgodność z typem, albo pełne zapewnienie jakości, zamiast polegania wyłącznie na wewnętrznej kontroli produkcji.

Ponieważ EN 18031 opublikowano z ograniczeniami, każdy produkt należy sprawdzić względem dokładnych komunikatów w Dzienniku Urzędowym. Ograniczenie nie wymusza automatycznie udziału jednostki notyfikowanej dla każdego produktu, ale może uniemożliwiać powołanie się na domniemanie zgodności dla danego wymagania lub sposobu implementacji.

W ramach CRA od 11 grudnia 2027

Dla produktów z kategorii domyślnej art. 32 CRA dopuszcza kontrolę wewnętrzną (moduł A), badanie typu UE, po którym następuje zgodność z typem (moduły B+C), pełne zapewnienie jakości (moduł H) albo właściwy europejski program certyfikacji cyberbezpieczeństwa.

Ścieżka jest bardziej rygorystyczna dla produktów z wykazów:

• ważne produkty klasy I mogą korzystać z kontroli wewnętrznej tylko przy pełnym zastosowaniu właściwych norm zharmonizowanych, wspólnych specyfikacji lub kwalifikujących się programów certyfikacji; w przeciwnym razie wymagane są moduły B+C albo H;
• ważne produkty klasy II wymagają modułów B+C, modułu H albo właściwego kwalifikującego się programu certyfikacji cyberbezpieczeństwa;
• produkty krytyczne podlegają ścieżkom certyfikacji lub oceny zgodności określonym w art. 8 i 32 CRA.

Producent musi przeprowadzić właściwą ocenę zgodności, przygotować dokumentację techniczną i deklarację zgodności UE oraz umieścić oznakowanie CE. Raport laboratorium ani dobrowolny certyfikat nie przenosi odpowiedzialności prawnej producenta i nie zastępuje wymaganej oceny zgodności.

Odpowiedzialność OEM i EMS

Definicja producenta w CRA obejmuje osobę prawną lub fizyczną, która opracowuje lub produkuje produkt albo zleca jego zaprojektowanie, opracowanie lub produkcję i wprowadza go do obrotu pod własną nazwą lub znakiem towarowym. Zlecenie projektu lub produkcji partnerowi EMS nie przenosi zatem zwykle odpowiedzialności producenta wynikającej z CRA z właściciela marki.

Ten podział powinien być jednoznacznie zapisany w umowie i interfejsach operacyjnych. Co najmniej należy określić:

• własność oraz format przekazania kodu źródłowego, zapisów buildów, SBOM i dowodów testowych;
• terminy informowania o podatnościach i incydentach, najlepiej ze znacznym marginesem względem 24-godzinnego terminu producenta;
• uprawnienia do zatwierdzania zamienników komponentów, zmian firmware i zmian backendu;
• odpowiedzialność za bezpieczny rozwój, klucze podpisujące i programowanie produkcyjne;
• odpowiedzialność za opracowanie, walidację i wdrożenie poprawek oraz komunikację z klientami;
• zapisy i wsparcie, które należy zachować po zakończeniu projektu komercyjnego.

Partner EMS lub inna strona trzecia może stać się producentem w rozumieniu CRA, jeżeli istotnie zmodyfikuje produkt i udostępni zmodyfikowany produkt na rynku. Kontrola zmian musi zatem oceniać nie tylko wpływ techniczny, ale również to, czy zmiana wpływa na zgodność, przeznaczenie lub ryzyko cyberbezpieczeństwa.

Pakiet dowodowy

Praktyczny pakiet dowodowy powinien łączyć wymagania prawne z decyzjami dotyczącymi produktu i odtwarzalnymi zapisami. Zwykle obejmuje:

• uzasadnienie zakresu, wyłączeń i klasyfikacji produktu;
• opis produktu, architekturę, przepływy danych i wykaz interfejsów zewnętrznych;
• przeznaczenie, racjonalnie przewidywalne użycie i założenia operacyjne;
• ocenę ryzyka cyberbezpieczeństwa i matrycę identyfikowalności wymagań;
• plan bezpiecznego rozwoju, zapisy przeglądów kodu i kryteria wydania;
• wersjonowany SBOM dla każdego wspieranego wydania;
• zapisy należytej staranności dla komponentów stron trzecich i dowody od dostawców;
• modelowanie zagrożeń oraz plany testów bezpieczeństwa, wyniki i zapisy działań naprawczych;
• kontrolę konfiguracji, sekretów, kluczy podpisujących i programowania produkcyjnego;
• projekt bezpiecznych aktualizacji i dowody ich walidacji;
• politykę ujawniania podatności, monitorowane źródła i zapisy triage;
• procedurę raportowania aktywnie wykorzystywanych podatności i poważnych incydentów;
• uzasadnienie okresu wsparcia, datę jego zakończenia i plan dostępności aktualizacji;
• instrukcje bezpiecznego użytkowania i bezpiecznego wycofania produktu;
• kontrolę zmian i oceny istotnych modyfikacji;
• zapisy oceny zgodności, deklarację zgodności UE i dowody oznakowania CE.

Najmocniejsza struktura zapewnia identyfikowalność w obu kierunkach: każde właściwe wymaganie wskazuje zabezpieczenie projektowe i obiektywny dowód, a każdy test lub dokument określa wymaganie i wersję produktu, które wspiera.

Plan wdrożenia 30/60/90 dni

Dni 1-30: ustalenie zakresu i odpowiedzialności

• Zinwentaryzuj produkty, warianty, firmware, aplikacje towarzyszące i podstawowe usługi zdalne.
• Zapisz decyzje dotyczące zakresu CRA i RED DA, w tym wyłączenia i założenia.
• Wskaż producenta prawnego i zmapuj odpowiedzialność OEM, EMS, dostawców oprogramowania i chmury.
• Sklasyfikuj produkty objęte CRA względem załączników III i IV.
• Określ właściwe wymagania art. 3 ust. 3 lit. d), e) i f) RED.
• Wyznacz właścicieli bezpieczeństwa produktu, przyjmowania zgłoszeń podatności i raportowania regulacyjnego.
• Otwórz rejestr luk z działaniami, właścicielami, terminami i wpływem na wydanie.

Dni 31-60: zbudowanie bazowej warstwy inżynierskiej

• Uzupełnij opisy architektury produktu, interfejsów i przepływów danych.
• Wykonaj lub zaktualizuj modelowanie zagrożeń i ocenę ryzyka cyberbezpieczeństwa.
• Wygeneruj wersjonowany SBOM z odtwarzalnego buildu lub kontrolowanej bazowej wersji wydania.
• Oceń drzewa decyzyjne EN 18031 i ograniczenia z Dziennika Urzędowego dla produktów radiowych.
• Zdefiniuj bezpieczne ustawienia domyślne oraz zabezpieczenia uwierzytelniania, aktualizacji, logowania i wycofania produktu.
• Dodaj wymagania cyberbezpieczeństwa do umów z dostawcami i EMS.
• Uruchom kanał skoordynowanego ujawniania podatności i wewnętrzną ścieżkę eskalacji.

Dni 61-90: weryfikacja i przećwiczenie procesu

• Wykonaj testy bezpieczeństwa oparte na ryzyku i zamknij ustalenia krytyczne.
• Przeprowadź ćwiczenie aktualizacji i rollbacku z użyciem produkcyjnych mechanizmów podpisywania i dystrybucji.
• Uzgodnij wydany firmware, SBOM, konfigurację produkcyjną i dokumentację techniczną.
• Przećwicz scenariusz raportowania regulacyjnego 24/72 godziny bez wysyłania rzeczywistego zgłoszenia.
• Potwierdź decyzję dotyczącą okresu wsparcia i opublikuj wymagane informacje dla użytkowników.
• Wybierz ścieżkę oceny zgodności i odpowiednio wcześnie zaangażuj jednostkę notyfikowaną, jeżeli jest wymagana.
• Przeprowadź przegląd bramki wydania i udokumentuj zaakceptowane ryzyka rezydualne.

Lista kontrolna przed wydaniem produktu

Przed wydaniem połączonego produktu elektronicznego potwierdź, że:

• producent prawny i role podmiotów gospodarczych są udokumentowane;
• decyzje o zakresie CRA i RED DA opierają się na rzeczywistych funkcjach i połączeniach produktu;
• klasyfikacja CRA wynika z podstawowej funkcji, a nie wyłącznie z obecności wbudowanych komponentów;
• oceniono właściwe wymagania EN 18031 i ograniczenia harmonizacji;
• ocena ryzyka odpowiada wydanemu sprzętowi, firmware, aplikacji i backendowi;
• w bazowej wersji wydania nie pozostała żadna znana podatność możliwa do wykorzystania;
• zweryfikowano bezpieczne ustawienia domyślne i nadawanie poświadczeń;
• dane przesyłane i przechowywane są chronione odpowiednio do ryzyka;
• aktualizacje bezpieczeństwa są uwierzytelniane, testowane i możliwe do cofnięcia;
• SBOM identyfikuje wersje komponentów w wydaniu;
• zamienniki produkcyjne i programowanie są kontrolowane oraz identyfikowalne;
• przyjmowanie, triage, eskalacja i raportowanie regulacyjne podatności działają operacyjnie;
• data zakończenia okresu wsparcia i instrukcje bezpiecznego użytkowania są dostępne dla użytkowników;
• ocena zgodności, dokumentacja techniczna, deklaracja zgodności i oznakowanie CE są kompletne.

Jak Inventronics może wesprzeć producenta

Jako partner w projektowaniu i produkcji elektroniki Inventronics może wspierać techniczną część przygotowań przez włączenie wymagań cyberbezpieczeństwa do architektury produktu, doboru komponentów, rozwoju firmware, weryfikacji, konfiguracji produkcyjnej i identyfikowalności.

Najskuteczniejsza współpraca zaczyna się przed zamrożeniem projektu. Własność dowodów, kryteria akceptacji bezpieczeństwa i odpowiedzialność po wprowadzeniu produktu na rynek są wtedy definiowane razem z wymaganiami kosztowymi, jakościowymi i terminowymi. Producent prawny zachowuje odpowiedzialność regulacyjną, a obie strony pracują na jednej kontrolowanej bazowej wersji produktu.

Omów z Inventronics gotowość swojego produktu do CRA i RED DA. Zacznij od zakresu produktu, architektury, podziału odpowiedzialności OEM/EMS i już dostępnych dowodów.

FAQ

Źródła urzędowe

• Rozporządzenie (UE) 2024/2847 – Cyber Resilience Act
• Komisja Europejska: Cyber Resilience Act
• Dyrektywa 2014/53/UE – dyrektywa w sprawie urządzeń radiowych
• Rozporządzenie Delegowane Komisji (UE) 2022/30 – wymagania cyberbezpieczeństwa RED, tekst skonsolidowany
• Decyzja Wykonawcza Komisji (UE) 2025/138 – odniesienia i ograniczenia EN 18031
• Rozporządzenie Delegowane Komisji (UE) 2026/339 – uchylenie Rozporządzenia (UE) 2022/30
• Komisja Europejska: dyrektywa w sprawie urządzeń radiowych

Artykuł zawiera ogólne informacje techniczne i regulacyjne. Nie stanowi porady prawnej. Zakres produktu i ścieżkę oceny zgodności należy potwierdzić dla konkretnego produktu, przeznaczenia, roli rynkowej i daty wydania.