Czym jest Cyber Resilience Act i kogo dotyczy?
Cyber Resilience Act (CRA) – oficjalnie Rozporządzenie (UE) 2024/2847 Parlamentu Europejskiego i Rady z dnia 23 października 2024 roku – to pierwsza w Unii Europejskiej horyzontalna regulacja wprowadzająca obowiązkowe wymogi cyberbezpieczeństwa dla produktów z elementami cyfrowymi. Akt został opublikowany w Dzienniku Urzędowym UE 20 listopada 2024 roku i wszedł w życie 10 grudnia 2024 roku.
CRA dotyczy wszystkich podmiotów gospodarczych uczestniczących w wprowadzaniu produktów z elementami cyfrowymi na rynek UE:
- Producentów – podmiotów projektujących, wytwarzających lub zlecających produkcję urządzeń
- Importerów – wprowadzających produkty z krajów trzecich na rynek unijny
- Dystrybutorów – udostępniających produkty w łańcuchu dostaw
Co oznacza „produkt z elementami cyfrowymi”?
Zgodnie z Artykułem 3(1) CRA, produkt z elementami cyfrowymi to produkt sprzętowy lub programowy oraz jego rozwiązania do zdalnego przetwarzania danych, w tym komponenty programowe lub sprzętowe. W praktyce oznacza to, że regulacja dotyczy każdego urządzenia, które:
- Posiada firmware lub oprogramowanie wbudowane
- Ma port komunikacyjny (USB, Ethernet, Wi-Fi, Bluetooth)
- Łączy się z siecią lub innym urządzeniem – bezpośrednio lub pośrednio
- Przetwarza dane zdalnie w chmurze producenta
Kluczowa zasada: Jeśli Twoje urządzenie może być podłączone fizycznie (poprzez interfejsy sprzętowe) lub logicznie (poprzez gniazda sieciowe, API, interfejsy programowe) do innego urządzenia lub sieci – nawet jeśli połączenie jest pośrednie – CRA ma do niego zastosowanie.
Przykłady produktów objętych CRA
Regulacja obejmuje szeroki zakres urządzeń elektronicznych stosowanych w różnych sektorach:
Elektronika przemysłowa:
- Sterowniki PLC i systemy automatyki
- Przemysłowe komputery i HMI
- Urządzenia do monitorowania i akwizycji danych (SCADA)
- Falowniki i przemienniki częstotliwości z komunikacją sieciową
Urządzenia sieciowe i IoT:
- Routery, przełączniki, firewalle
- Urządzenia IoT (czujniki, aktuatory)
- Systemy smart home (inteligentne zamki, alarmy, monitoring)
Elektronika konsumencka:
- Smartfony i tablety
- Noszone urządzenia monitorujące zdrowie (wearables)
- Zabawki z funkcjami sieciowymi
- Monitory dla niemowląt z kamerą IP
Automotive i transport:
- Systemy informacyjno-rozrywkowe w pojazdach
- Urządzenia diagnostyczne OBD
Urządzenia medyczne, lotnicze i motoryzacyjne podlegające odrębnym regulacjom UE (Rozporządzenia 2017/745, 2017/746, 2018/1139, 2019/2144) są wyłączone z CRA, ponieważ posiadają już dedykowane wymogi cyberbezpieczeństwa.
Jakie obowiązki wprowadza CRA?
Bezpieczeństwo „by design”
Fundamentalna zasada CRA to security by design – bezpieczeństwo wbudowane od etapu projektowania. Załącznik I Część I Rozporządzenia definiuje podstawowe wymogi cyberbezpieczeństwa, które muszą być spełnione jeszcze przed wprowadzeniem produktu na rynek.
Projektowanie z uwzględnieniem cyberbezpieczeństwa
Zgodnie z Art. 13(1) CRA, producent musi:
- Przeprowadzić analizę ryzyka cybernetycznego – zidentyfikować zagrożenia dla produktu w kontekście przewidywanego zastosowania
- Zaprojektować architekturę bezpieczną – wdrożyć mechanizmy ochrony na poziomie sprzętu i oprogramowania
- Zastosować zasadę minimalnych uprawnień – ograniczyć dostęp do funkcji tylko do niezbędnego zakresu
- Wyeliminować domyślne hasła – każde urządzenie musi posiadać unikalne dane dostępowe lub mechanizm wymuszający ich ustawienie przy pierwszym użyciu
Aktualizowalność oprogramowania
Kluczowym wymogiem jest zapewnienie możliwości bezpiecznej aktualizacji oprogramowania przez cały okres wsparcia (support period):
- Minimum 5 lat od daty wprowadzenia na rynek – zgodnie z Art. 13(8) CRA
- Jeśli przewidywany czas użytkowania jest krótszy niż 5 lat, okres wsparcia musi odpowiadać przewidywanemu czasowi użytkowania
- Aktualizacje muszą być dostarczane bezpłatnie dla użytkownika
- Mechanizm aktualizacji musi być bezpieczny – zabezpieczony przed podszywaniem się i nieautoryzowanymi modyfikacjami
Wymóg dostępności aktualizacji: Zgodnie z Art. 13(9), każda aktualizacja bezpieczeństwa musi pozostać dostępna do pobrania przez minimum 10 lat od daty jej wydania lub przez pozostały okres wsparcia – w zależności od tego, który okres jest dłuższy.
Brak podatności znanych w momencie wprowadzenia na rynek
Producent ma obowiązek wykonać due diligence wobec komponentów pochodzących od stron trzecich, w tym komponentów open-source. Załącznik I Punkt 2(1) wymaga, aby produkty były wolne od znanych podatności w momencie wprowadzenia na rynek. Oznacza to konieczność:
- Weryfikacji komponentów pod kątem znanych luk w bazie CVE (Common Vulnerabilities and Exposures)
- Sprawdzenia historii aktualizacji bezpieczeństwa komponentów
- Przeprowadzenia testów bezpieczeństwa przed certyfikacją
Zarządzanie podatnościami
CRA wprowadza szczegółowe obowiązki w zakresie vulnerability handling przez cały cykl życia produktu.
Obowiązek reagowania i raportowania
Artykuł 14 CRA definiuje szczegółowy tryb raportowania incydentów:
1. Aktywnie wykorzystywane podatności (actively exploited vulnerabilities)
Producent musi zgłosić każdą aktywnie wykorzystywaną podatność, o której się dowiedział. Oznacza to sytuacje, gdy:
- Naruszenie bezpieczeństwa użytkowników wynikło z wykorzystania luki w produkcie
- Złośliwy aktor wykorzystał wadę w funkcjach identyfikacji, uwierzytelniania lub innych mechanizmach bezpieczeństwa
Harmonogram raportowania (od 11 września 2026):
- Wczesne ostrzeżenie (early warning) – w ciągu 24 godzin od powzięcia informacji
- Powiadomienie o podatności – w ciągu 72 godzin z bardziej szczegółowymi informacjami
- Raport końcowy – w ciągu 14 dni po udostępnieniu środków zaradczych
2. Poważne incydenty (severe incidents)
Raportowaniu podlegają również poważne incydenty wpływające na bezpieczeństwo produktu, w tym sytuacje, gdy:
- Incydent cybernetyczny zakłócił procesy rozwoju, produkcji lub konserwacji produktu
- Zakłócenie może zwiększyć ryzyko cybernetyczne dla użytkowników
- Przykład: atak na kanał dystrybucji aktualizacji bezpieczeństwa z wstrzyknięciem złośliwego kodu
Harmonogram raportowania:
- Wczesne ostrzeżenie – w ciągu 24 godzin
- Powiadomienie o incydencie – w ciągu 72 godzin
- Raport końcowy – w ciągu 1 miesiąca
Wszystkie zgłoszenia muszą być przesyłane przez Jednolitą Platformę Raportowania (Single Reporting Platform), która zostanie ustanowiona przez ENISA (European Union Agency for Cybersecurity).
Utrzymywanie aktualizacji przez określony czas
Producent jest zobowiązany do:
- Monitorowania podatności przez cały okres wsparcia
- Dostarczania poprawek w rozsądnym czasie po wykryciu luki
- Publicznego ujawniania informacji o naprawionych podatnościach po udostępnieniu aktualizacji
- Prowadzenia polityki koordynowanego ujawniania podatności (Coordinated Vulnerability Disclosure) – producent musi udostępnić adres kontaktowy do zgłaszania luk bezpieczeństwa
Dokumentacja i identyfikowalność
To kluczowa sekcja dla branży EMS – tutaj produkcja nabiera strategicznego znaczenia.
Software Bill of Materials (SBOM)
Załącznik VII punkt 2(b) CRA wymaga od producenta stworzenia SBOM – spisu wszystkich komponentów programowych zawartych w produkcie. SBOM musi być:
- W powszechnie używanym, maszynoczytelnym formacie (np. SPDX, CycloneDX, SWID)
- Zawierać przynajmniej zależności najwyższego poziomu (top-level dependencies)
- Być częścią dokumentacji technicznej produktu
- Dostępny dla organów nadzoru rynku na żądanie
Praktyczne znaczenie SBOM:
- Umożliwia szybką identyfikację produktów zawierających podatne komponenty
- Pozwala na precyzyjne śledzenie, które partie produkcyjne wymagają aktualizacji
- Jest podstawą do zarządzania ryzykiem w łańcuchu dostaw
Traceability komponentów i partii produkcyjnych
Artykuł 13(13) CRA stanowi, że producent musi zapewnić, aby produkty posiadały numer typu, partii, seryjny lub inny element umożliwiający ich identyfikację. W praktyce oznacza to konieczność:
1. Numeracji partii produkcyjnych
- Każda seria PCB musi posiadać unikalny identyfikator
- Umożliwia to powiązanie konkretnej płytki z:
- Datą produkcji
- Wersją BOM (Bill of Materials)
- Wersją wgranego firmware
- Użytymi komponentami (partie)
2. Rejestru użytych komponentów
- Dokumentacja musi zawierać pełną listę komponentów użytych w każdej partii
- Szczególnie istotne przy wykryciu podatności w komponencie od dostawcy
- Pozwala na szybką identyfikację, które produkty są dotknięte problemem
3. Możliwości odtworzenia konfiguracji produkcji
- Zapisane parametry procesu montażu
- Wersje oprzyrządowania (solder paste stencil, fixtury)
- Kalibracja urządzeń testowych
Dlaczego to ma znaczenie w kontekście CRA?
Gdy zostanie wykryta podatność w komponencie (np. moduł Bluetooth, układ kryptograficzny), producent musi:
- Natychmiast zidentyfikować wszystkie dotknięte produkty
- Powiadomić użytkowników i organy nadzoru
- Dostarczyć aktualizację lub instrukcje mitigation
Bez pełnej traceability jest to niemożliwe do wykonania w wymaganym przez CRA terminie 24-72 godzin.
Kontrola zmian i zarządzanie wersjami
Załącznik VII punkt 1(b) wymaga dokumentacji wersji oprogramowania wpływających na zgodność z wymogami cyberbezpieczeństwa. W praktyce EMS musi:
- Prowadzić rejestr wersji firmware dla każdej partii
- Dokumentować procedury ECO (Engineering Change Order)
- Zapewnić, że wersja firmware jest zgodna z wersją hardware
- Umożliwić weryfikację, która wersja oprogramowania została wgrana do konkretnego urządzenia
Co Cyber Resilience Act oznacza dla produkcji elektroniki?
CRA przenosi cyberbezpieczeństwo z wymiaru czysto programistycznego do dziedziny produkcji fizycznej. Dla partnerów EMS oznacza to przejście z roli wykonawcy montażu do współodpowiedzialnego uczestnika procesu zapewniania bezpieczeństwa.
1️⃣ Znaczenie kontroli jakości
Automated Optical Inspection (AOI)
AOI to technologia wykorzystująca kamery i algorytmy wizyjne do automatycznej inspekcji płytek PCB. W kontekście CRA, AOI nabiera nowego znaczenia:
Wykrywanie wad montażu wpływających na bezpieczeństwo:
- Niepoprawne lutowanie komponentów odpowiedzialnych za funkcje bezpieczeństwa (np. układy kryptograficzne)
- Brakujące komponenty w obwodach zabezpieczeń
- Zwary mogące prowadzić do nieprzewidywalnego działania
Weryfikacja autentyczności komponentów:
- Nowoczesne systemy AOI mogą wykrywać podrobione układy scalone poprzez analizę markingu
- Weryfikacja zgodności fizycznego wyglądu z dokumentacją producenta komponentu
Testy funkcjonalne (Functional Testing)
Zgodnie z Załącznikiem VII punkt 6, producent musi dostarczyć raporty z testów weryfikujących zgodność z wymogami cyberbezpieczeństwa. W kontekście produkcji oznacza to:
Testy komunikacji i szyfrowania:
- Weryfikacja poprawnej implementacji protokołów bezpiecznej komunikacji
- Sprawdzenie działania mechanizmów szyfrowania
- Test portów komunikacyjnych pod kątem nieautoryzowanego dostępu
Testy mechanizmów uwierzytelniania:
- Potwierdzenie braku domyślnych haseł
- Weryfikacja poprawności mechanizmów secure boot
Testy programowania firmware
Nieprawidłowo zaprogramowana seria PCB może oznaczać masowe naruszenie bezpieczeństwa – to najważniejszy wniosek dla branży EMS.
Kluczowe aspekty testów firmware w kontekście CRA:
- Weryfikacja integralności firmware:
- Po wgraniu firmware należy zweryfikować checksum/hash
- Potwierdzenie, że wgrane oprogramowanie jest identyczne z zatwierdzoną wersją
- Kontrola wersji przy produkcji:
- System musi uniemożliwić wgranie niewłaściwej wersji firmware
- Automatyczne logowanie wersji wgranej do konkretnego numeru seryjnego
- Testy post-programming:
- Uruchomienie urządzenia i weryfikacja podstawowych funkcji bezpieczeństwa
- Test bootowania zabezpieczonego (secure boot)
- Weryfikacja certyfikatów i kluczy kryptograficznych
Scenariusz ryzyka: Jeśli w trakcie produkcji partii 10 000 sztuk zostanie wgrana podatna wersja firmware (np. zawierająca hard-coded credentials), producent musi:
- Zgłosić incydent w ciągu 24 godzin
- Zidentyfikować wszystkie dotknięte jednostki
- Powiadomić dystrybutorów i użytkowników końcowych
- Dostarczyć aktualizację lub przeprowadzić recall
Bez precyzyjnej dokumentacji procesu programowania, skala problemu jest niemożliwa do ustalenia.
2️⃣ Identyfikowalność partii produkcyjnych
Numeracja partii
CRA wymaga, aby każdy produkt był identyfikowalny (Art. 13(13)). W produkcji EMS przekłada się to na:
Numery seryjne lub partii na poziomie PCB:
- Naniesienie identyfikatora poprzez laser marking, druk UV lub etykietę
- Powiązanie numeru z bazą danych produkcji
Identyfikacja na poziomie produktu końcowego:
- Oznakowanie obudowy (label, grawerowanie)
- Digital twin – cyfrowa reprezentacja fizycznego urządzenia w systemie MES
Rejestr użytych komponentów
Dlaczego jest to krytyczne w kontekście CRA?
W 2023 roku wykryto krytyczną podatność w popularnym module Wi-Fi używanym w milionach urządzeń IoT. Producenci, którzy nie posiadali precyzyjnego rejestru komponentów, musieli przeprowadzić kosztowne analizy każdej partii produkcyjnej, aby ustalić, które urządzenia są dotknięte. Proces ten trwał tygodnie – znacznie przekraczając 24-godzinny termin zgłoszenia wymagany przez CRA.
Elementy systemu traceability komponentów:
- Incoming Quality Control (IQC):
- Rejestracja numeru partii (lot code) komponentu przy przyjęciu
- Weryfikacja certyfikatów autentyczności od dystrybutorów
- Przechowywanie próbek z każdej partii (dla późniejszej analizy w razie potrzeby)
- Material Resource Planning (MRP) z funkcją traceability:
- System musi rejestrować, która partia komponentu została użyta w której partii PCB
- Powiązanie: Lot Code komponentu → Numer partii PCB → Numer seryjny produktu końcowego
- Dokumentacja zmian BOM:
- Każda zmiana komponentu (np. zamiennik z powodu EOL) musi być udokumentowana
- Oznaczenie punktu granicznego w produkcji – od której sztuki zmiana została wdrożona
Możliwość odtworzenia konfiguracji produkcji
Scenariusz praktyczny: Wykryto, że w określonym okresie czasu (np. 15-17 marca 2027) parametry profilu termicznego pieca reflow były nieprawidłowe, co mogło wpłynąć na jakość połączeń lutowniczych układu kryptograficznego.
System traceability musi umożliwić:
- Identyfikację wszystkich PCB wyprodukowanych w tym okresie
- Powiązanie z numerami seryjnymi produktów końcowych
- Szybkie powiadomienie klientów o potencjalnym problemie
Elementy do udokumentowania:
- Parametry procesu montażu:
- Profile termiczne (temperatura, czas, krzywa nagrzewania)
- Ciśnienie i prędkość pick-and-place
- Rodzaj i producent pasty lutowniczej (z numerem partii)
- Kalibracja urządzeń:
- Daty ostatniej kalibracji AOI, X-ray, flying probe tester
- Wersje oprogramowania urządzeń produkcyjnych
- Środowisko produkcji:
- Temperatura i wilgotność w strefie ESD
- Klasa czystości pomieszczenia (jeśli dotyczy)
3️⃣ Kontrola łańcucha dostaw
Oryginalność komponentów
Podrobione układy scalone to rosnące zagrożenie. Według raportu Semiconductor Industry Association z 2018 roku, fałszywe komponenty kosztują amerykańską branżę półprzewodników ponad 7,5 miliarda USD rocznie.
W kontekście CRA, podrobiony komponent może zawierać backdoor lub znaną podatność, której producent nie jest świadomy. To narusza fundamentalny wymóg Załącznika I Punkt 2(1) – produkt nie może zawierać znanych podatności w momencie wprowadzenia na rynek.
Metody weryfikacji autentyczności komponentów:
- Zakup od autoryzowanych dystrybutorów:
- Weryfikacja statusu dystrybutora u producenta komponentu
- Wymaganie certyfikatów autentyczności (CoC – Certificate of Conformity)
- Testy fizyczne i elektryczne:
- Analiza markingu pod mikroskopem (podróbki często mają nieostre oznaczenia)
- Testy elektryczne parametrów (porównanie z danymi katalogowymi)
- X-ray inspection (weryfikacja struktury wewnętrznej die)
- Blockchain dla traceability:
- Niektóre dystrybutory wprowadzają systemy blockchain do potwierdzania autentyczności łańcucha dostaw
Ryzyko End-of-Life (EOL) komponentów i zamienników
Problem: Komponent użyty w projekcie przechodzi w status EOL (End-of-Life) w trakcie cyklu życia produktu. Producent musi znaleźć zamiennik.
Wpływ na CRA:
- Zamiennik może mieć różne właściwości bezpieczeństwa (np. inna implementacja protokołu kryptograficznego)
- Wymaga ponownej analizy ryzyka cyberbezpieczeństwa
- Może być konieczna aktualizacja SBOM i dokumentacji technicznej
- W skrajnych przypadkach – nowy cykl testów i certyfikacji
Rola profesjonalnego EMS:
- Proactive Obsolescence Management:
- Monitorowanie statusu PCN (Product Change Notification) i EOL notices
- Wczesne ostrzeganie klienta o zbliżającym się EOL komponentu
- Proponowanie alternatywnych komponentów z zachowaniem właściwości bezpieczeństwa
- Qualification nowych komponentów:
- Wsparcie w procesie kwalifikacji zamiennika
- Przeprowadzenie testów porównawczych
- Walidacja wpływu zmiany na funkcje bezpieczeństwa
- Dokumentacja zmian:
- Precyzyjne oznaczenie, od której partii produkcyjnej wdrożono zamiennik
- Aktualizacja BOM w systemie MES
- Umożliwienie klientowi aktualizacji SBOM
Jak profesjonalny EMS może wspierać producenta w realiach CRA?
Warto podkreślić: profesjonalny partner EMS nie „wdraża CRA” za klienta – odpowiedzialność prawna za zgodność z rozporządzeniem spoczywa na producencie (manufacturer w rozumieniu CRA). Jednak prawidłowo zorganizowana produkcja może znacząco ograniczyć ryzyko operacyjne związane z wymogami regulacji.
Stabilne procesy produkcyjne
Standaryzacja
ISO 9001 jako fundament: Certyfikowany system zarządzania jakością to minimum w kontekście wymogów CRA. Profesjonalny EMS powinien posiadać:
- Udokumentowane procedury dla wszystkich etapów produkcji
- Kontrolę procesu – monitoring parametrów krytycznych w czasie rzeczywistym
- Niezgodności i działania korygujące – system CAPA (Corrective and Preventive Actions)
Dodatkowe standardy branżowe:
- IPC-A-610 – Standard akceptacji montażu elektronicznego
- IPC-J-STD-001 – Wymagania dla lutowanych połączeń elektrycznych
- IEC 61340-5-1 – Standard ochrony ESD
Przestrzeganie tych norm zapewnia powtarzalność procesu, co jest kluczowe dla traceability wymaganej przez CRA.
Kontrola zmian (Engineering Change Order – ECO)
ECO w kontekście CRA:
Każda zmiana w procesie produkcyjnym, która może wpłynąć na bezpieczeństwo produktu, musi być:
- Udokumentowana – formalna procedura ECO z opisem zmiany
- Oceniona pod kątem ryzyka – analiza wpływu na funkcje bezpieczeństwa
- Zatwierdzona przez klienta (producenta w rozumieniu CRA)
- Oznakowana w produkcji – jasne określenie punktu granicznego wdrożenia
Przykładowe zmiany wymagające ECO:
- Zmiana dostawcy komponentu (nawet jeśli part number pozostaje ten sam)
- Modyfikacja profilu termicznego reflow
- Zmiana typu pasty lutowniczej
- Update oprogramowania urządzeń testowych
Dokumentacja technologiczna
Work Instructions i Process Flow:
Profesjonalny EMS prowadzi szczegółową dokumentację procesu:
- Assembly drawings – schematy montażu z oznaczeniem orientacji komponentów
- Process travelers – karty produkcyjne towarzyszące każdej partii
- Inspection criteria – kryteria akceptacji dla AOI, X-ray, testów funkcjonalnych
- Test procedures – procedury testowe, w tym testy związane z bezpieczeństwem
Ta dokumentacja stanowi część dowodu zgodności z wymogami CRA – udowadnia, że proces produkcji jest kontrolowany i powtarzalny.
Pełna traceability
Partia PCB
Unique Device Identifier (UDI):
Każda płytka PCB (lub produkt końcowy) otrzymuje unikalny identyfikator, który pozwala na:
- Śledzenie wstecz (backward traceability): Z produktu końcowego → do partii PCB → do partii komponentów → do dostawcy
- Śledzenie w przód (forward traceability): Z partii komponentów → do partii PCB → do produktów końcowych → do klienta końcowego
Technologie identyfikacji:
- QR code / Data Matrix – najczęściej używane, możliwość skanowania w procesie
- RFID tags – dla wymagających środowisk (np. automotive)
- Laser marking – trwałe oznaczenie na PCB (nie usuwalne)
Partia komponentów
Powiązanie component lot code z PCB serial number:
System MES (Manufacturing Execution System) powinien automatycznie rejestrować:
- Z której szpuli/paczki (reel/tray) został pobrany komponent
- Lot code producenta komponentu (odczytany z etykiety)
- Data code komponentu (data produkcji przez producenta)
- Do której płytki PCB komponent został zamontowany
Praktyczne wdrożenie:
- Barcode scanning na stacji pick-and-place – operator skanuje etykietę szpuli przed załadowaniem
- Automatic reel ID – automat SMD automatycznie odczytuje RFID tag ze szpuli
- Manual logging – dla komponentów montowanych ręcznie (THT)
Wersja BOM (Bill of Materials)
BOM Control:
W trakcie życia produktu, BOM może ewoluować (zmiany komponentów, optymalizacje). System traceability musi:
- Wersjonować BOM – każda zmiana otrzymuje nowy numer wersji
- Powiązać wersję BOM z partią produkcyjną – w systemie MES zapisane, która wersja BOM była używana dla danej partii
- Umożliwić porównanie wersji – identyfikacja różnic między wersjami
Wpływ na CRA: Jeśli w nowej wersji BOM zmieniono komponent zawierający podatność, producent może szybko zidentyfikować, które partie produktów są dotknięte (tylko te wyprodukowane według starej wersji BOM).
Wersja firmware
Firmware Version Control w produkcji:
1. Secure firmware storage:
- Firmware jest przechowywane na zabezpieczonym serwerze
- Każda wersja ma unikalny hash (SHA-256)
- System kontroli dostępu – tylko autoryzowani operatorzy mogą pobrać firmware
2. Programming station:
- Programator weryfikuje hash firmware przed wgraniem
- Po wgraniu przeprowadzane jest readback – odczyt pamięci urządzenia i porównanie z oryginałem
- Automatyczne logowanie: Serial Number → Firmware Version → Data/czas → Operator ID
3. Zapis w bazie danych:
- System MES zapisuje, która wersja firmware została wgrana do którego numeru seryjnego
- Umożliwia to późniejszą identyfikację wszystkich urządzeń z konkretną wersją
Scenariusz wykorzystania: Wykryto krytyczną podatność w firmware v2.3.1. System MES pokazuje, że:
- Firmware v2.3.1 został wgrany do urządzeń SN 10000-15000
- Te urządzenia zostały wyprodukowane w marcu 2027
- Dystrybutor X otrzymał 3000 sztuk z tego zakresu
- Producent może natychmiast powiadomić dystrybutora i użytkowników końcowych
Programowanie i testowanie
Bezpieczne wgrywanie firmware
Secure Boot Chain:
Profesjonalny proces wgrywania firmware w kontekście CRA powinien obejmować:
- Weryfikacja źródła firmware:
- Firmware jest podpisany cyfrowo przez producenta (klienta EMS)
- Programator weryfikuje podpis przed wgraniem
- Zapobiega to wgraniu nieautoryzowanego firmware
- Encrypted firmware transfer:
- Firmware jest przesyłany w postaci zaszyfrowanej z serwera do programatora
- Deszyfrowanie następuje dopiero w urządzeniu docelowym (jeśli jest wyposażone w secure element)
- Device authentication:
- Przed programowaniem weryfikowana jest autentyczność urządzenia (nie podróbka)
- Np. poprzez odczyt unikalnego ID chipu (UID)
Kontrola wersji
Version Lock-Out Mechanism:
System produkcyjny powinien uniemożliwić wgranie niewłaściwej wersji firmware. Przykładowy workflow:
- Work Order określa:
- Numer partii PCB: LOT-2027-0315
- Wymagana wersja firmware: v3.1.5
- Wymagana wersja hardware (PCB revision): Rev B
- Programator weryfikuje:
- Czy firmware v3.1.5 jest kompatybilny z hardware Rev B (sprawdzenie w bazie danych)
- Czy operator próbuje wgrać właściwą wersję
- Jeśli niezgodność – blokada i alarm
- Po wgraniu:
- Readback i weryfikacja
- Automatyczny zapis w systemie MES: „Device SN 10523 programmed with FW v3.1.5 at 2027-03-15 14:32 by Operator ID 045”
Testy funkcjonalne przed wysyłką
Post-Programming Functional Test:
Po wgraniu firmware i zamknięciu obudowy, urządzenie musi przejść kompleksowy test funkcjonalny. W kontekście CRA, test powinien obejmować:
1. Security Functions Test:
- Boot Sequence: Urządzenie uruchamia się poprawnie, secure boot weryfikuje integralność firmware
- Authentication Test: Test mechanizmów logowania, weryfikacja braku domyślnych haseł
- Encryption Test: Jeśli urządzenie szyfruje dane, test poprawności szyfrowania/deszyfrowania
- Communication Security: Test protokołów bezpiecznej komunikacji (TLS, HTTPS, SSH)
2. Interface Test:
- Test wszystkich portów komunikacyjnych (Ethernet, USB, RS-485, etc.)
- Weryfikacja, że niezabezpieczone porty diagnostyczne są wyłączone lub odpowiednio zabezpieczone
3. Firmware Version Verification:
- Odczyt wersji firmware poprzez interfejs (np. CLI, API)
- Porównanie z oczekiwaną wersją z Work Order
Dokumentacja wyników testów:
- Każdy test generuje raport z Pass/Fail dla każdego urządzenia
- Raporty są archiwizowane i powiązane z numerem seryjnym
- W przypadku Fail – urządzenie nie opuszcza linii, rozpoczyna się analiza przyczyn (Root Cause Analysis)
Wsparcie przy redesignie
Zmiany komponentów pod kątem bezpieczeństwa
Scenariusz: Producent (klient EMS) dowiaduje się, że komponent używany w jego produkcie zawiera podatność. Należy znaleźć zamiennik.
Rola profesjonalnego EMS w procesie:
- Component Recommendation:
- Inżynierowie EMS proponują alternatywne komponenty o podobnych parametrach
- Kluczowe: Zamiennik musi spełniać te same lub wyższe wymogi bezpieczeństwa (np. wspierać TLS 1.3, nie tylko 1.2)
- Risk Assessment Support:
- Pomoc w ocenie, czy zmiana komponentu wpływa na funkcje bezpieczeństwa
- Analiza, czy wymaga to ponownej certyfikacji (w przypadku produktów kategorii „important” lub „critical” – prawdopodobnie tak)
- Prototyping and Testing:
- Szybkie wyprodukowanie prototypów z nowym komponentem
- Przeprowadzenie testów funkcjonalnych i bezpieczeństwa
- Weryfikacja, że zmiana nie wprowadza nowych podatności
- Qualification Run:
- Produkcja małej serii (np. 50-100 sztuk) z nowym komponentem
- Extended testing – testy przyspieszonej niezawodności, testy środowiskowe
- Potwierdzenie, że produkcja na dużą skalę jest możliwa
Konsultacje DFM/DFT (Design for Manufacturing / Design for Testing)
DFM w kontekście CRA:
Profesjonalny EMS oferuje Design Review już na etapie projektu, co pozwala uniknąć problemów w produkcji, które mogłyby wpłynąć na bezpieczeństwo.
Przykładowe rekomendacje DFM wpływające na bezpieczeństwo:
- Component Placement:
- Układy kryptograficzne i secure elements powinny być umieszczone w trudno dostępnych miejscach na PCB
- Ogranicza to możliwość fizycznych ataków (probing, bus sniffing)
- Test Points:
- W fazie produkcji potrzebne są test points do weryfikacji funkcji bezpieczeństwa
- Ale w produkcie końcowym powinny być usunięte lub zabezpieczone (zalane epoxydem), aby uniemożliwić nieautoryzowany dostęp
- Debug Interfaces:
- Interfejsy JTAG, SWD używane w fazie development muszą być wyłączone lub zabezpieczone w produkcji finalnej
- DFM: Rekomendacja, aby projekt PCB uwzględniał możliwość fizycznego odcięcia debug interface (jumper, fusible link)
DFT w kontekście CRA:
Design for Testability to projektowanie z myślą o możliwości testowania. W kontekście CRA:
- Testability Security Functions:
- Projekt musi umożliwiać test funkcji bezpieczeństwa na linii produkcyjnej
- Np. test szyfrowania wymaga dostępu do API – należy zaprojektować interfejs testowy
- Built-In Self-Test (BIST):
- Wbudowanie w firmware funkcji self-test security functions
- Możliwość uruchomienia testu z linii poleceń podczas produkcji
- Boundary Scan (IEEE 1149.1 JTAG):
- Umożliwia test połączeń na PCB bez fizycznych test points
- Użyteczne w fazie produkcji, ale JTAG musi być później wyłączony (secure boot lockdown)
Praktyczne wsparcie EMS:
- Design Review Meetings: Inżynierowie EMS spotykają się z zespołem R&D klienta na etapie projektu
- DFM Report: Szczegółowy raport z analizą projektu pod kątem produkowalności i testowalności
- Security-focused recommendations: Konkretne rekomendacje dotyczące aspektów bezpieczeństwa (np. „Sugerujemy dodanie test pointa dla weryfikacji secure boot, ale z możliwością fizycznego usunięcia w wersji produkcyjnej”)
Jak przygotować się już teraz? Checklista dla producenta
CRA w pełni wchodzi w życie 11 grudnia 2027 roku, ale obowiązki raportowania zaczynają się już 11 września 2026 – za mniej niż 2 lata od dzisiaj. Oto praktyczna checklista działań:
☑ Zweryfikuj czy Twoje urządzenie podlega CRA
Kroki weryfikacji:
- Czy produkt ma elementy cyfrowe?
- Firmware, oprogramowanie wbudowane, komponenty programowe – TAK
- Brak oprogramowania, czysto mechaniczne – NIE
- Czy produkt łączy się z innym urządzeniem lub siecią?
- Bezpośrednio (Wi-Fi, Ethernet, Bluetooth) – TAK
- Pośrednio (przez gateway) – TAK
- W ogóle nie łączy się – NIE (wyjątek: jeśli ma możliwość aktualizacji przez USB, nadal TAK)
- Czy produkt jest wprowadzany na rynek UE w ramach działalności komercyjnej?
- Sprzedaż na terenie UE – TAK
- Tylko do użytku wewnętrznego firmy (nie wprowadzane na rynek) – NIE
- Open-source bez monetyzacji – NIE (z wyjątkami, patrz Art. 18 CRA)
- Czy produkt jest wykluczony przez inne regulacje?
- Urządzenia medyczne (wg Rozp. 2017/745, 2017/746) – TAK, wyłączone
- Pojazdy (wg Rozp. 2019/2144) – TAK, wyłączone
- Lotnictwo (certyfikowane wg Rozp. 2018/1139) – TAK, wyłączone
- Inne produkty – Prawdopodobnie podlegają CRA
☑ Sprawdź kategorię produktu (default / important / critical)
Kategorie produktów według CRA:
1. Default (domyślne) – około 90% wszystkich produktów
- Conformity assessment: Samoocena przez producenta
- Wymogi: Spełnienie essential cybersecurity requirements (Załącznik I)
- Przykłady: Większość urządzeń IoT, elektroniki konsumenckiej
2. Important (ważne) – Załącznik III CRA
- Conformity assessment: W większości przypadków wymagana ocena przez notified body (jednostkę notyfikowaną)
- Kryteria: Produkt pełni funkcję niosącą znaczne ryzyko w zakresie wpływu na zdrowie, bezpieczeństwo lub ochronę użytkowników
- Przykłady z Załącznika III:
- Klasa I: Systemy zarządzania tożsamością (identity management), przeglądarki internetowe, menedżery haseł, VPN
- Klasa II: Mikrokontrolery, mikroprocesory, systemy operacyjne dla serwerów/PC/mobile, smartkarty
- Klasa II: Routery, przełączniki, firewalle, inteligentne zamki, systemy alarmowe, monitory dla niemowląt
3. Critical (krytyczne) – Załącznik IV CRA
- Conformity assessment: Ocena przez notified body
- Kryteria: Produkt spełnia kryteria „important” oraz jest użytkowany w kontekście krytycznej infrastruktury lub pełni krytyczną funkcję w ramach sieci lub usług
- Przykłady z Załącznika IV:
- Zarządzanie urządzeniami PKI (Public Key Infrastructure)
- Hypervisory do wirtualizacji
- Przemysłowe firewalle i IDS/IPS
Jak określić kategorię?
- Sprawdź Załącznik III i IV CRA – produkty są wymienione z opisami
- Jeśli produktu nie ma na liście → Kategoria „default”
☑ Upewnij się, że masz dokumentację wersji produkcyjnych
Minimalna dokumentacja wymagana:
- Version Matrix:
- Tabela powiązań: Hardware Version ↔ Compatible Firmware Versions
- Przykład: PCB Rev. B jest kompatybilne z Firmware v2.x.x i v3.x.x, ale nie z v1.x.x
- Changelog for each version:
- Co zostało zmienione w każdej wersji
- Czy zmiana dotyczy funkcji bezpieczeństwa (jeśli tak, to wymaga szczególnej uwagi)
- Configuration Management Plan:
- Procedury kontroli wersji
- Kto ma uprawnienia do zatwierdzania nowych wersji
- Proces ECO (Engineering Change Order)
Jeśli nie masz tej dokumentacji:
- Rozpocznij od teraz – nawet jeśli produkt jest już na rynku
- Retrospektywne odtwarzanie – przejrzyj historie Git, dokumenty produkcyjne, e-maile – odtwórz historię wersji
- Zdefiniuj „baseline” – obecna wersja staje się baseline, od której wszystkie zmiany będą dokumentowane
☑ Zadbaj o identyfikowalność komponentów
Co należy wdrożyć:
- Component Traceability System:
- System MES lub ERP z funkcją traceability
- Rejestracja lot codes komponentów przy przyjęciu materiałów
- Powiązanie lot code → numer partii PCB → numer seryjny produktu
- SBOM Generation:
- Użyj narzędzi do generowania SBOM (np. Syft, CycloneDX, SPDX tools)
- SBOM powinien być w formacie maszynoczytelnym (JSON, XML)
- Aktualizuj SBOM przy każdej zmianie komponentu
- Supplier Declarations:
- Wymagaj od dostawców komponentów deklaracji zgodności lub certyfikatów
- Dla komponentów kategorii „important” – weryfikuj czy posiadają CE marking (po 2027)
Praktyczne narzędzia:
- Open-source SBOM tools: Syft (Anchore), CycloneDX CLI, SPDX Tools
- Commercial solutions: Finite State, Fortress, FOSSA
- ERP/MES integration: Wiele systemów (SAP, Oracle, Epicor) oferuje moduły traceability
☑ Zadbaj o kontrolę firmware na etapie produkcji
Procedury do wdrożenia:
- Firmware Release Process:
- Każda wersja firmware przeznaczona do produkcji musi być formalnie „zwolniona” (released)
- Firmware jest podpisany cyfrowo przez R&D
- Hash firmware jest zapisany w bazie danych
- Production Programming Procedure:
- Programator pobiera firmware z centralnego serwera (nie z lokalnego dysku operatora)
- Przed programowaniem – weryfikacja hash
- Po programowaniu – readback i weryfikacja
- Automatyczne logowanie: SN → FW version → Timestamp → Operator
- Version Control in Production:
- Work Order określa wersję firmware dla danej partii
- System blokuje możliwość wgrania innej wersji
- Alert, jeśli operator próbuje użyć niewłaściwej wersji
- Archive and Retention:
- Wszystkie wersje firmware są archiwizowane przez co najmniej 10 lat (wymóg CRA Art. 13(9))
- Dokumentacja, która wersja była używana w którym okresie produkcji
☑ Wybierz partnera produkcyjnego, który zapewnia traceability
Kryteria wyboru EMS w kontekście CRA:
- Certyfikaty i standardy:
- ISO 9001 (zarządzanie jakością) – minimum
- ISO/IEC 27001 (zarządzanie bezpieczeństwem informacji) – zalecane
- IPC-A-610 (standard akceptacji montażu) – wymagane
- IATF 16949 (automotive, jeśli dotyczy)
- Systemy IT:
- Posiadanie systemu MES (Manufacturing Execution System) z traceability
- Możliwość generowania raportów: Component lot code → PCB batch → Serial numbers
- Integracja z systemem klienta (API, EDI)
- Doświadczenie w branżach regulowanych:
- Produkcja dla sektorów medycznego, automotive, aerospace – te sektory mają już wysokie wymogi traceability
- Doświadczenie z audytami i compliance
- Bezpieczeństwo fizyczne i cybernetyczne:
- Zabezpieczona przestrzeń produkcyjna (kontrola dostępu)
- Cybersecurity w systemach produkcyjnych (zabezpieczony serwer firmware)
- Procedury ochrony danych (GDPR compliance jako wskaźnik dojrzałości)
- Wsparcie techniczne:
- Inżynierowie z doświadczeniem w embedded security
- Możliwość konsultacji DFM/DFT
- Wsparcie przy redesignie i zarządzaniu obsolescence
Pytania do zadania potencjalnemu partnerowi EMS:
- „Czy Wasz system MES rejestruje lot codes komponentów i potrafi powiązać je z numerami seryjnymi produktów?”
- „Jak długo przechowujecie dokumentację produkcyjną?” (CRA wymaga minimum 10 lat)
- „Czy posiadacie procedury bezpiecznego programowania firmware z kontrolą wersji?”
- „Czy przeprowadzacie testy funkcjonalne weryfikujące funkcje bezpieczeństwa (np. secure boot)?”
- „Jakie systemy stosujecie do weryfikacji autentyczności komponentów?”
Podsumowanie – regulacja to ryzyko, ale też przewaga konkurencyjna
Cyber Resilience Act nie jest wyłącznie regulacją prawną nakładającą dodatkowe obowiązki. To zmiana paradygmatu w podejściu do projektowania, produkcji i utrzymania urządzeń elektronicznych w Unii Europejskiej. CRA wyraźnie komunikuje: cyberbezpieczeństwo jest fundamentalnym wymogiem, na równi z bezpieczeństwem elektrycznym czy kompatybilnością elektromagnetyczną.
Produkcja ma znaczenie strategiczne
Tradycyjnie, cyberbezpieczeństwo było postrzegane jako domena programistów – secure coding, testy penetracyjne, analiza kodu. CRA rozszerza to na cały łańcuch wartości, w tym produkcję fizyczną. Nieprawidłowo zaprogramowana seria PCB, użycie podrobionego komponentu, brak traceability partii – to wszystko może skutkować masowym naruszeniem bezpieczeństwa, obowiązkiem raportowania w ciągu 24 godzin i potencjalnie kosztownym recall.
Dla producentów oznacza to, że wybór partnera EMS nie jest już tylko decyzją o kosztach i terminach – to decyzja o zdolności do spełnienia wymogów regulacyjnych i zarządzania ryzykiem cybernetycznym.
Przewaga konkurencyjna wczesnych adopters
Firmy, które proaktywnie wdrożą wymogi CRA przed 2027 rokiem, uzyskają przewagę rynkową:
- Szybsze wprowadzenie produktów na rynek:
- Gdy CRA stanie się obowiązkowe, firmy bez przygotowania będą musiały przejść długi proces audytu, poprawek, re-testowania
- Early adopters przejdą przez ten proces wcześniej, bez presji czasu
- Lepsza pozycja negocjacyjna:
- Klienci B2B (szczególnie w sektorach regulowanych – finanse, infrastruktura krytyczna) już teraz wymagają od dostawców wysokiego poziomu cyberbezpieczeństwa
- Posiadanie CE marking zgodnego z CRA stanie się wymogiem przetargowym
- Niższe ryzyko operacyjne:
- Pełna traceability i kontrola łańcucha dostaw to nie tylko compliance – to narzędzie zarządzania jakością i szybkiej reakcji na problemy
- Zmniejszenie ryzyka kosztownych recall i utraty reputacji
- Możliwość ekspansji na rynki spoza UE:
- Inne jurysdykcje (USA, Australia, Japonia) pracują nad podobnymi regulacjami
- Doświadczenie z CRA ułatwi przystosowanie się do przyszłych regulacji w innych regionach
Rola profesjonalnego partnera produkcyjnego
Wybór profesjonalnego partnera EMS, który rozumie wymogi CRA, to nie inwestycja w „wdrożenie regulacji” – to inwestycja w stabilność operacyjną i zdolność do szybkiego reagowania na incydenty bezpieczeństwa.
Profesjonalny EMS:
- Zapewnia traceability – umożliwia identyfikację dotkniętych produktów w ciągu godzin, nie tygodni
- Kontroluje łańcuch dostaw – minimalizuje ryzyko podrobionych komponentów i nieautoryzowanego firmware
- Wspiera w procesie certyfikacji – dostarcza dokumentację produkcyjną wymaganą dla conformity assessment
- Umożliwia szybką reakcję – w przypadku wykrycia podatności, możliwość przeprogramowania partii lub wycofania konkretnych numerów seryjnych
W praktyce, bezpieczeństwo zaczyna się nie tylko w kodzie, ale również na linii montażowej. Cyber Resilience Act to uznanie tej prawdy na poziomie unijnej legislacji.
Źródła
- Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, L, 2024/2847. Dostępne: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
- European Commission – Digital Strategy. „Cyber Resilience Act | Shaping Europe’s digital future”. Dostępne: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- TXOne Networks. „The Cyber Resilience Act: A Guide for Manufacturers”. April 18, 2025. Dostępne: https://www.txone.com/blog/cra-guide-for-manufacturers/
- Anchore. „EU CRA SBOM Requirements: Overview & Compliance Tips”. Updated June 4, 2025. Dostępne: https://anchore.com/sbom/eu-cra/
- Cyber Resilience Act official resource. „Annex VII – Content of the technical documentation”. Dostępne: https://cyber-resilience-act.com/annexes/annex-vii/
- The Embedded Kit. „The 3 product categories covered by the Cyber Resilience Act”. June 2025. Dostępne: https://theembeddedkit.io/blog/product-categories-cyber-resilience-act/
- PCBONLINE. „PCB Component Traceability: The Complete Guide”. Dostępne: https://www.pcbonline.com/blog/PCB-Component-Traceability.html
- Siemens Digital Industries Software. „Are Counterfeit PCBA Parts Still A Risk In 2025?”. Dostępne: https://siemensmfg.com/electronics-manufacturing-trends/are-counterfeit-pcba-parts-still-a-risk-in-2025/
- Semiconductor Industry Association. „Detecting and Removing Counterfeit Semiconductors in the U.S. Supply Chain”. 2018. Dostępne: https://www.semiconductors.org/wp-content/uploads/2018/06/ACTF-Whitepaper-Counterfeit-One-Pager-Final.pdf
- Finite State. „Understanding The EU CRA’s SBOM & Technical Documentation Requirements”. Dostępne: https://finitestate.io/blog/eu-cra-sbom-technical-documentation-guide
- Memfault. „EU Cyber Resilience Act: A Guide for Manufacturers & Developers”. Dostępne: https://memfault.com/blog/eu-cyber-resilience-act-guide/
- ENISA (European Union Agency for Cybersecurity). „Cyber Resilience Act Requirements Standards Mapping”. November 2024. Dostępne: https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber Resilience Act Requirements Standards Mapping
- NTT DATA Benelux. „Cyber Resilience Act: What manufacturers must do”. Dostępne: https://benelux.nttdata.com/insights/blog/cyber-resilience-act-what-manufacturers-must-do
- Taylor Wessing. „Cyber Resilience Act: Overview for affected companies”. 2025. Dostępne: https://www.taylorwessing.com/en/insights-and-events/insights/2025/11/cyber-resilience-act-overview
- ArmorCode. „EU Cyber Resilience Act (CRA) Requirements Guide”. Dostępne: https://www.armorcode.com/learning-center/eu-cyber-resilience-act-cra-requirements-guide
Nota prawna: Artykuł został przygotowany na podstawie oficjalnej wersji Rozporządzenia (UE) 2024/2847 oraz publikacji instytucji europejskich i specjalistycznych firm branżowych. Nie stanowi porady prawnej. W przypadku wątpliwości dotyczących stosowania CRA do konkretnego produktu, zaleca się konsultację z prawnikiem specjalizującym się w prawie UE oraz z jednostką notyfikowaną.
