Wielu klientów rozpoczynających projekt urządzenia elektronicznego skupia się na tym, co widać od razu: funkcji produktu, koszcie projektu, cenie montażu PCB, dostępności komponentów, terminie prototypu i możliwości uruchomienia produkcji seryjnej. To naturalne. Produkt musi działać, musi dać się wyprodukować i musi mieścić się w budżecie.

Problem zaczyna się wtedy, gdy temat oceny zgodności pojawia się dopiero pod koniec projektu. Czasem jako pytanie: „czy możecie też załatwić CE?”. Czasem jako założenie: „skoro podzespoły mają CE, to całe urządzenie też będzie zgodne”. Czasem jako presja harmonogramu: „produkt jest gotowy, potrzebujemy tylko dokumentu do sprzedaży”.

W elektronice takie podejście jest ryzykowne. Oznakowanie CE nie jest naklejką marketingową ani certyfikatem jakości. Jest deklaracją producenta, że produkt spełnia wymagania mających zastosowanie przepisów. Żeby taką deklarację podpisać odpowiedzialnie, producent OEM powinien wiedzieć, jakie wymagania dotyczą produktu, jakie normy zastosowano, jakie badania wykonano, jakie ryzyka oceniono i jak będzie utrzymywana zgodność w produkcji seryjnej.

Uwaga: ten materiał ma charakter informacyjny i nie stanowi porady prawnej. Dobór wymagań, norm i procedury oceny zgodności powinien być każdorazowo zweryfikowany dla konkretnego produktu, rynku i modelu odpowiedzialności.

Ten poradnik pokazuje, co producent OEM powinien rozumieć przed wdrożeniem urządzenia elektronicznego do produkcji. Nie chodzi o to, aby każdy klient stał się specjalistą od prawa produktowego i norm. Chodzi o to, aby na początku projektu zadać właściwe pytania i uniknąć sytuacji, w której zgodność blokuje premierę, wysyłkę, sprzedaż albo dalszą produkcję.

Dla kogo jest ten poradnik

Ten materiał jest dla firm, które opracowują, zamawiają lub wprowadzają na rynek urządzenia elektroniczne pod własną marką albo we własnym modelu biznesowym.

Typowe sytuacje:

• masz pomysł na urządzenie elektroniczne i chcesz przejść od koncepcji do prototypu,
• masz działający prototyp i planujesz produkcję seryjną,
• masz projekt przygotowany przez zewnętrzne biuro konstrukcyjne,
• przenosisz produkcję od innego dostawcy,
• importujesz lub integrujesz urządzenie z elektroniką pod własną marką,
• sprzedajesz urządzenie B2B, przemysłowe, profesjonalne lub konsumenckie,
• nie masz wewnętrznego działu compliance, ale formalnie odpowiadasz za produkt.

W praktyce problem dotyczy nie tylko małych firm. Duże organizacje również potrafią mieć rozproszoną odpowiedzialność: RD zakłada jedno, zakupy drugie, dostawca trzecie, a dział sprzedaży oczekuje gotowego produktu z oznakowaniem CE. Jeżeli nikt nie prowadzi tematu zgodności od początku, ryzyko wraca na etapie badań, dokumentacji albo kontroli rynku.

Jeżeli jesteś na etapie przechodzenia od pomysłu lub prototypu do produktu gotowego do produkcji, warto równolegle uporządkować wymagania techniczne, produkcyjne i zgodnościowe. Ten proces dobrze łączy się z projektowaniem urządzeń elektronicznych oraz przygotowaniem produktu do produkcji elektroniki na zlecenie.

CE nie jest naklejką na końcu projektu

Jednym z najczęstszych nieporozumień jest traktowanie CE jako ostatniego kroku przed sprzedażą. Produkt działa, obudowa jest gotowa, prototyp przeszedł testy funkcjonalne, więc pozostaje „zrobić CE”. Takie myślenie jest zrozumiałe, ale błędne.

Oznakowanie CE oznacza, że producent deklaruje zgodność produktu z wymaganiami właściwych przepisów Unii Europejskiej. W przypadku elektroniki mogą to być różne obszary: kompatybilność elektromagnetyczna, bezpieczeństwo elektryczne, urządzenia radiowe, ograniczenia substancji niebezpiecznych, baterie, wymagania dla produktów konsumenckich, wymagania środowiskowe albo cyberbezpieczeństwo produktów z elementami cyfrowymi.

To oznacza, że ocena zgodności zaczyna się dużo wcześniej niż w laboratorium. Zaczyna się od zrozumienia produktu:

• do czego służy,
• kto będzie go używał,
• gdzie będzie pracował,
• jak jest zasilany,
• czy komunikuje się radiowo,
• czy zawiera firmware lub software,
• czy ma baterię,
• czy jest częścią większej maszyny albo systemu,
• na jakim rynku ma być sprzedawany.

Jeżeli te pytania nie padną na początku, projekt może pójść w kierunku, który później będzie trudny lub kosztowny do obrony. Problemem może być layout PCB podatny na emisję EMC, brak odstępów izolacyjnych, nieodpowiedni zasilacz, brak miejsca na etykietę, brak kontroli wersji firmware, brak dokumentacji komponentów albo obudowa, która nie spełnia wymagań środowiskowych.

Dlatego CE trzeba traktować jako proces projektowy i dowodowy, a nie jako formalność po produkcji.

W praktyce temat CE powinien pojawić się już wtedy, gdy powstaje architektura produktu, pierwsze założenia techniczne i plan prototypu. Więcej o całej ścieżce od koncepcji do wdrożenia opisaliśmy w poradniku: Od pomysłu do gotowego urządzenia elektronicznego.

Kim jest producent OEM i kto odpowiada za produkt

W projektach elektronicznych często bierze udział kilka stron: klient, projektant elektroniki, dostawca PCB, firma montażowa EMS, dostawca obudowy, producent modułów, laboratorium badawcze, dystrybutor komponentów i czasem integrator końcowy. To może tworzyć mylne wrażenie, że odpowiedzialność za zgodność „rozłoży się” między wszystkich uczestników projektu.

W praktyce trzeba jasno ustalić, kto wprowadza produkt na rynek jako producent. Jeżeli firma sprzedaje urządzenie pod własną marką, definiuje jego przeznaczenie, decyduje o konstrukcji i bierze odpowiedzialność za udostępnienie produktu klientom, to najczęściej właśnie ona pełni rolę producenta OEM w sensie biznesowym i formalnym.

Partner projektowy lub EMS może bardzo pomóc. Może zaprojektować elektronikę z myślą o EMC, przygotować dokumentację produkcyjną, kontrolować wersje BOM, prowadzić traceability, wspierać badania, współpracować z laboratorium i utrzymywać stabilność procesu. Nie oznacza to jednak automatycznie, że przejmuje odpowiedzialność producenta za deklarację zgodności końcowego produktu.

To rozróżnienie jest kluczowe. EMS zwykle produkuje według ustalonej dokumentacji i procesu. OEM odpowiada za to, że produkt jako całość jest zgodny z wymaganiami, właściwie opisany, oznakowany, udokumentowany i utrzymywany w zgodności po zmianach.

OEM, EMS, importer i dystrybutor: uproszczona mapa odpowiedzialności

Najbezpieczniej jest ustalić model odpowiedzialności już na starcie projektu. Kto określa wymagania? Kto wybiera normy? Kto prowadzi dokumentację techniczną? Kto zleca badania? Kto podpisuje deklarację zgodności? Kto zatwierdza zmiany w produkcji? Bez tych odpowiedzi projekt może działać technicznie, ale organizacyjnie pozostawać niegotowy do rynku.

Od czego zacząć ocenę zgodności urządzenia elektronicznego

Pierwszym krokiem nie jest wybór laboratorium. Pierwszym krokiem jest opis produktu i jego kontekstu użycia. Dopiero na tej podstawie można sensownie ustalić, które wymagania mogą mieć zastosowanie.

Minimum informacji, które warto zebrać:

• nazwa i funkcja produktu,
• opis użytkownika końcowego,
• rynek docelowy i kraj sprzedaży,
• środowisko pracy: dom, przemysł, pojazd, maszyna, teren, zewnętrze, wilgoć, temperatura,
• sposób zasilania: sieć, zasilacz zewnętrzny, bateria, PoE, instalacja przemysłowa,
• interfejsy komunikacyjne: przewodowe, radiowe, Bluetooth, Wi-Fi, LTE, LoRa, NFC,
• obecność firmware, aplikacji, chmury lub aktualizacji,
• elementy mechaniczne i obudowa,
• warianty produktu i opcje konfiguracji,
• przewidywany wolumen produkcji,
• planowany cykl życia produktu i obsługa zmian.

Ten opis jest praktyczny, nie akademicki. Jeżeli produkt ma moduł radiowy, temat zgodności będzie inny niż dla prostego sterownika przewodowego. Jeżeli produkt jest zasilany z sieci, dochodzi inny poziom wymagań bezpieczeństwa niż przy niskim napięciu z zasilacza zewnętrznego. Jeżeli produkt ma firmware i komunikację sieciową, trzeba myśleć nie tylko o funkcji, ale też o aktualizacjach, konfiguracji i potencjalnych wymaganiach cyber.

Im wcześniej te informacje trafią do rozmowy z partnerem projektowo-produkcyjnym, tym łatwiej zaplanować architekturę produktu, prototypy, badania pre-compliance, dokumentację i harmonogram wdrożenia.

Takie uporządkowanie danych wejściowych jest częścią dobrego procesu NPI. W Inventronics opisujemy go jako serię kroków od kwalifikacji projektu, przez prototyp, walidację, przygotowanie dokumentacji i pilotaż, aż po produkcję seryjną. Zobacz: Proces NPI: 16 etapów od pomysłu do produkcji.

Jak ustalić, które przepisy mogą mieć zastosowanie

Nie każde urządzenie elektroniczne podlega tym samym wymaganiom. Dlatego jednym z pierwszych zadań producenta OEM jest identyfikacja przepisów i obszarów zgodności właściwych dla konkretnego produktu.

Poniższa tabela nie zastępuje analizy prawnej, ale pokazuje typowy sposób myślenia.

W praktyce najczęściej analizuje się kilka obszarów równolegle. Przykładowo niewielkie urządzenie IoT zasilane z baterii i komunikujące się przez Bluetooth może wymagać spojrzenia na RED, EMC, RoHS, baterie, instrukcję użytkowania, oznakowanie i cyberbezpieczeństwo. Jeżeli to samo urządzenie trafia do środowiska przemysłowego, dochodzą oczekiwania klientów dotyczące odporności, traceability, jakości i utrzymania wersji.

Najgorszym scenariuszem jest odkrycie właściwych wymagań po zakończeniu projektu PCB i obudowy. Wtedy zmiana może oznaczać redesign, kolejną serię prototypów, powtórzenie testów i przesunięcie produkcji seryjnej.

W przypadku produktów z firmware, komunikacją sieciową lub aktualizacjami warto od początku uwzględnić także wymagania cyberbezpieczeństwa. Ten temat rozwijamy osobno w artykule: Gotowość na CRA dla producenta elektroniki.

Normy zharmonizowane: po co są i dlaczego warto myśleć o nich wcześnie

Przepisy określają wymagania ogólne, ale często nie mówią projektantowi wprost, jak zaprojektować konkretny układ, obudowę, zasilanie, interfejs czy procedurę testu. W praktyce ogromne znaczenie mają normy zharmonizowane, które pomagają wykazać zgodność z wymaganiami.

Dla producenta OEM ważne są trzy rzeczy.

Po pierwsze, norma to nie tylko dokument dla laboratorium. Wybór norm wpływa na projekt. Może determinować wymagania dotyczące odporności EMC, emisji, odstępów izolacyjnych, temperatur, sposobu testowania, oznakowania lub instrukcji.

Po drugie, normy warto wskazać przed zamrożeniem konstrukcji. Jeżeli zespół projektuje elektronikę bez świadomości docelowych testów, zwiększa się ryzyko, że produkt będzie działał funkcjonalnie, ale nie przejdzie badań albo będzie wymagał kosztownych poprawek.

Po trzecie, lista norm jest częścią logicznej historii zgodności produktu. Producent powinien umieć wyjaśnić, dlaczego wybrał dane normy, jaki zakres badań wykonano i jakie dowody znajdują się w dokumentacji technicznej.

Dobry partner projektowo-produkcyjny nie zastępuje specjalisty compliance ani laboratorium, ale powinien umieć zadać pytania, które wpływają na projekt: czy produkt ma radio, jakie są limity środowiskowe, gdzie będzie zasilacz, jakie są długości przewodów, czy obudowa jest metalowa, czy potrzebne są filtry, czy przewidziano punkty testowe i jak będą obsługiwane zmiany komponentów.

Dlatego rozmowa o normach nie powinna być oderwana od projektowania elektroniki. Decyzje dotyczące zasilania, layoutu PCB, separacji obwodów, filtracji, obudowy i testowalności najlepiej podejmować razem z zespołem, który zna zarówno projektowanie, jak i późniejszą produkcję. Ten zakres mieści się w naszej usłudze projektowania urządzeń elektronicznych.

Ocena ryzyka jako fundament dokumentacji

Ocena zgodności nie polega wyłącznie na zebraniu raportów z badań. Producent powinien rozumieć i udokumentować ryzyka związane z produktem. W elektronice te ryzyka mogą być techniczne, użytkowe, środowiskowe, jakościowe i organizacyjne.

Przykładowe obszary ryzyka:

• porażenie elektryczne,
• przegrzewanie lub pożar,
• zakłócenia elektromagnetyczne emitowane przez produkt,
• podatność produktu na zakłócenia zewnętrzne,
• błędne działanie firmware,
• utrata komunikacji,
• nieprawidłowe ładowanie baterii,
• błędny montaż lub zamiennik komponentu,
• niewłaściwe użytkowanie, które jest możliwe do przewidzenia,
• brak instrukcji, ostrzeżeń lub oznakowania,
• zmiana wersji produktu bez ponownej oceny wpływu na zgodność.

W dojrzałym procesie ocena ryzyka nie jest osobnym dokumentem tworzonym po fakcie. Powinna wpływać na decyzje projektowe: dobór komponentów, separację obwodów, layout PCB, obudowę, zabezpieczenia, testery produkcyjne, procedury kontroli jakości i sposób zatwierdzania zmian.

Badania i testy: co zaplanować przed produkcją seryjną

Badania finalne są ważne, ale nie powinny być pierwszym momentem, w którym produkt spotyka się z wymaganiami zgodności. W projektach elektronicznych często opłaca się wykonać wcześniejsze testy pre-compliance albo przynajmniej przegląd konstrukcji pod kątem EMC, bezpieczeństwa i produkowalności.

Testy, które mogą być istotne dla urządzenia elektronicznego:

• emisja EMC,
• odporność EMC,
• bezpieczeństwo elektryczne,
• badania radiowe dla urządzeń z komunikacją bezprzewodową,
• weryfikacja materiałowa RoHS,
• testy temperatury i obciążenia,
• testy środowiskowe zależne od zastosowania,
• testy funkcjonalne i produkcyjne,
• kontrola wersji firmware i konfiguracji.

Największą wartość daje plan testów połączony z etapami projektu. Inaczej testuje się pierwszy prototyp, inaczej serię inżynierską, inaczej pilotaż produkcyjny, a inaczej produkt gotowy do deklaracji zgodności. Jeżeli harmonogram nie przewiduje czasu na poprawki po badaniach, ryzyko opóźnienia jest bardzo wysokie.

Z perspektywy produkcji ważne jest też to, aby testy laboratoryjne nie były oderwane od testów produkcyjnych. Produkt, który przeszedł badania jako prototyp, musi później dać się wytwarzać powtarzalnie, kontrolować i identyfikować w partiach. To jeden z powodów, dla których warto łączyć ocenę zgodności z przygotowaniem do produkcji elektroniki na zlecenie.

Dokumentacja techniczna CE: co powinno znaleźć się w teczce produktu

Dokumentacja techniczna jest dowodem, że producent przeprowadził ocenę zgodności w sposób uporządkowany. Nie jest to tylko jeden certyfikat ani jeden raport. To zestaw informacji, który pozwala odtworzyć, czym jest produkt, jakie wymagania go dotyczą, jak został zaprojektowany, jak został zbadany i jak jest produkowany.

Typowe elementy dokumentacji technicznej dla urządzenia elektronicznego:

• opis produktu i jego przeznaczenia,
• warianty produktu,
• schematy elektryczne,
• layout PCB i pliki produkcyjne,
• BOM i informacje o komponentach krytycznych,
• opis firmware/software i wersji,
• analiza ryzyka,
• lista mających zastosowanie przepisów,
• lista zastosowanych norm,
• raporty z badań,
• instrukcja użytkowania,
• etykieta i oznakowanie,
• deklaracje materiałowe i RoHS,
• procedury kontroli produkcji,
• wyniki testów produkcyjnych,
• historia zmian ECO/ECN,
• deklaracja zgodności UE.

W praktyce dokumentacja techniczna jest tym lepsza, im bardziej powstaje razem z projektem. Jeżeli trzeba ją rekonstruować po latach albo po zmianie dostawcy, często brakuje decyzji, raportów, wersji plików, uzasadnień i śladów zatwierdzeń.

Jeżeli dopiero przygotowujesz zapytanie do partnera projektowego lub EMS, część tych danych warto zebrać już na etapie RFQ. Pomaga to szybciej ocenić zakres, ryzyka, brakujące informacje i sensowną ścieżkę wdrożenia. Zobacz poradnik: Jak przygotować RFQ na projekt i produkcję elektroniki.

Produkcja seryjna a utrzymanie zgodności

Ocena zgodności nie kończy się w dniu podpisania deklaracji. Produkt elektroniczny żyje: zmieniają się komponenty, dostawcy, firmware, partie PCB, dostępność zamienników, wymagania klientów i czasem same normy.

Dla producenta OEM szczególnie ważne są:

• kontrola wersji BOM,
• zatwierdzanie zamienników komponentów,
• ocena wpływu zmian na EMC, safety, radio i funkcję produktu,
• kontrola wersji firmware,
• identyfikowalność partii,
• zachowanie wyników testów produkcyjnych,
• procedura ECO/ECN,
• decyzja, kiedy zmiana wymaga ponownych badań lub konsultacji z laboratorium.

To jest obszar, w którym partner EMS może dać dużą wartość. Stabilny proces produkcyjny, traceability, kontrola zmian i dokumentacja partii pomagają utrzymać zgodność w czasie. Bez tego produkt może formalnie przejść badania jako prototyp, ale seryjna produkcja zacznie odbiegać od wersji ocenionej.

W produkcji seryjnej zgodność zależy nie tylko od projektu, ale też od dyscypliny procesu: kontroli BOM, wersji firmware, testów, traceability i zatwierdzania zmian. Właśnie dlatego w projektach OEM ważny jest partner EMS, który rozumie zarówno montaż elektroniki, jak i konsekwencje zmian dla produktu końcowego. Zobacz: Produkcja elektroniki na zlecenie (EMS).

Typowe błędy OEM przy wdrażaniu elektroniki

Najczęstsze błędy nie wynikają ze złej woli, tylko z braku świadomości, że zgodność jest częścią projektu produktu.

Typowe problemy:

• traktowanie CE jako zadania na koniec,
• brak ustalenia dyrektyw i rozporządzeń na początku projektu,
• założenie, że moduł z CE oznacza zgodność całego urządzenia,
• brak listy norm przed zamrożeniem konstrukcji,
• brak budżetu i czasu na badania,
• brak dokumentacji technicznej zbieranej w trakcie projektu,
• brak instrukcji, ostrzeżeń lub poprawnego oznakowania,
• brak kontroli zmian po pierwszej partii,
• zamiana komponentów bez oceny wpływu na zgodność,
• podpisanie deklaracji zgodności bez wystarczających dowodów.

Każdy z tych błędów może kosztować więcej niż wcześniejsze uporządkowanie procesu. Kosztem nie jest tylko redesign. Kosztem może być opóźnienie sprzedaży, zatrzymanie partii, spór z klientem, utrata wiarygodności albo konieczność powtórzenia badań.

Jeżeli projekt jest już po prototypie, ale pojawiły się problemy z badaniami, dokumentacją, produkowalnością albo transferem do serii, dobrym pierwszym krokiem może być uporządkowana diagnoza techniczna. Taki scenariusz opisuje usługa Rescue NPI 60.

Co może zrobić partner projektowo-produkcyjny

Dobry partner projektowo-produkcyjny nie powinien obiecywać, że „załatwi CE” bez zrozumienia produktu. Powinien natomiast pomóc producentowi OEM przejść przez projekt tak, aby produkt miał realną ścieżkę do zgodności i produkcji seryjnej.

Wsparcie może obejmować:

• uporządkowanie wymagań produktu,
• wskazanie pytań potrzebnych do identyfikacji wymagań zgodności,
• projektowanie elektroniki z myślą o EMC, bezpieczeństwie i produkcji,
• przygotowanie prototypów do testów,
• wsparcie w badaniach pre-compliance,
• współpracę z laboratorium,
• przygotowanie dokumentacji produkcyjnej,
• kontrolę BOM i zamienników,
• traceability partii,
• utrzymanie wersji firmware i procesu,
• wsparcie w kompletowaniu danych do dokumentacji technicznej.

Największa wartość pojawia się wtedy, gdy rozmowa o zgodności zaczyna się przed decyzjami konstrukcyjnymi. Wtedy można jeszcze dobrać architekturę, komponenty, obudowę, zasilanie, testery i proces w sposób, który zmniejsza ryzyko późniejszych poprawek.

Warto też sprawdzić, czy partner ma realne kompetencje w obszarach istotnych dla danego produktu: projektowania, montażu, testów, traceability, jakości i pracy z dokumentacją techniczną. Więcej o zakresie kompetencji Inventronics znajdziesz na stronach: Specjalizacje technologiczne, Certyfikaty oraz O nas.

Checklista pytań dla producenta OEM

Przed rozpoczęciem projektu lub przed przejściem z prototypu do produkcji seryjnej warto odpowiedzieć na poniższe pytania.

Kiedy rozmawiać o CE z partnerem EMS

Najlepiej jak najwcześniej. Nie dlatego, że każdy projekt wymaga od razu pełnych badań, ale dlatego, że wymagania zgodności wpływają na decyzje techniczne.

Rozmowa ma największą wartość:

• na etapie koncepcji produktu,
• przed wyborem modułów i architektury,
• przed pierwszym layoutem PCB,
• przed zamrożeniem obudowy,
• przed serią prototypową,
• przed testami laboratoryjnymi,
• przed transferem produkcji,
• przed zatwierdzeniem zamienników komponentów.

Jeżeli produkt jest już gotowy, rozmowa nadal ma sens, ale jej charakter się zmienia. Zamiast projektować z wyprzedzeniem, trzeba ocenić ryzyka istniejącej konstrukcji i zdecydować, czy dokumentacja, badania i proces produkcji są wystarczające do odpowiedzialnego wdrożenia.

Podsumowanie

Ocena zgodności CE dla urządzenia elektronicznego nie jest pojedynczym dokumentem ani ostatnim krokiem przed sprzedażą. To proces, który łączy wymagania prawne, decyzje projektowe, badania, dokumentację techniczną, produkcję i kontrolę zmian.

Producent OEM nie musi samodzielnie znać każdej normy i każdego scenariusza badań. Musi jednak wiedzieć, że to on jako właściciel produktu powinien zadbać o właściwe pytania, odpowiedzialności, dokumentację i dowody. Partner projektowo-produkcyjny może w tym pomóc, ale nie zastępuje świadomego procesu po stronie producenta.

Największe ryzyko powstaje wtedy, gdy zgodność pojawia się dopiero na końcu. Największa oszczędność pojawia się wtedy, gdy temat CE jest częścią projektu od początku: od koncepcji, przez prototyp, po produkcję seryjną i utrzymanie produktu na rynku.

Porozmawiaj z Inventronics o technicznej ścieżce do produkcji i danych potrzebnych do oceny zgodności. Pomożemy uporządkować wymagania, ryzyka, dokumentację produkcyjną i proces zmian, zanim staną się kosztownym problemem.

FAQ

The post Ocena zgodności CE dla producenta OEM appeared first on INVENTRONICS.

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.

The post CRA, RED DA i EN 18031: praktyczny przewodnik gotowości dla producentów elektroniki appeared first on INVENTRONICS.