Embedded · Regulacje UE

Pół branży embedded świętuje przesunięcie terminu, którego nikt nie przesunął.

Po czerwcowych zmianach w unijnych przepisach po firmach produkujących elektronikę krąży plotka, że „cyberrozporządzenie poczeka”. Nie poczeka. Pierwszy twardy termin Cyber Resilience Act już minął, a obowiązek raportowania obowiązuje i obejmuje także urządzenia sprzedane lata temu. Niżej: skąd wzięła się plotka i osiem kroków: trzy pierwsze są już obowiązkowe, pięć to przygotowanie do grudnia 2027.

Autor: · Ostatnia aktualizacja:

11.09.2026 start raportowania 24h/72h, obejmuje też produkty już na rynku
11.12.2027 pełne wymogi: secure by design, SBOM, dokumentacja, CE
do 15 mln € lub 2,5% światowego obrotu (górna granica kar)

Wtorek, 15 września 2026, godzina 9:40.

Dzwoni klient. Ktoś opublikował w sieci gotowy exploit na sterownik, który sprzedaliście mu w 2023 roku. Według CERT-u podatność jest od kilku dni aktywnie wykorzystywana. Produkt jest w okresie wsparcia, więc od czterech dni biegnie Wam ustawowy zegar: 24 godziny na wstępne zgłoszenie do ENISA. Tylko że nikt w firmie nie wie, że taki obowiązek w ogóle istnieje, bo na naradzie w lipcu ktoś rzucił, że „te unijne cyberprzepisy przecież przesunęli”.

Jeśli podobne zdanie padło ostatnio i na Waszej naradzie, czytajcie dalej. Coś faktycznie przesunięto. Tylko nie to, co myślicie.

Przesunięto AI Act. CRA — nie.

Źródło plotki jest łatwe do wskazania. 7 maja 2026 Rada i Parlament uzgodniły tzw. Digital Omnibus dla AI Act: obowiązki dla systemów wysokiego ryzyka, które miały wejść 2 sierpnia 2026, rozdzielono i przesunięto: część na grudzień 2027, część na sierpień 2028. Zmiana przeszła przez Parlament (16.06) i Radę (29.06) i już obowiązuje. Jeśli ktoś w firmie usłyszał „unijne przepisy o cyfrowych produktach przesunięte: część teraz, część za rok”, to niemal na pewno chodziło o AI Act. Terminy CRA Komisja potwierdziła bez zmian (aktualizacja oficjalnej strony: 22 czerwca 2026).

przesunięty

AI Act (systemy AI)

  • High-risk (Annex III): 2.08.2026 → 2.12.2027
  • AI w produktach regulowanych (Annex I): → 2.08.2028
  • Obowiązki transparentności: zostają na 2.08.2026
bez zmian

Cyber Resilience Act (produkty z software'em)

  • Raportowanie podatności i incydentów: 11.09.2026
  • Pełne wymogi + CE: 11.12.2027
  • Przepisy o jednostkach notyfikowanych: obowiązują od 11.06.2026

Jedyna rzecz, która przy CRA wisi w legislacji, to propozycja z Digital Omnibus „cyfrowego” (listopad 2025): Single Entry Point (jedno okienko raportowania incydentów wspólne dla NIS2/RODO/DORA/CRA). To uproszczenie sposobu zgłaszania, nie przesunięcie terminów. I wciąż jest tylko propozycją.

CRA od początku wchodzi etapami.

„Część teraz, część później” w CRA to nie żadna nowość z 2026 roku: fazowanie jest zapisane w rozporządzeniu od dnia publikacji. Problem w tym, że większość firm zapamiętała tylko ostatnią datę (grudzień 2027) i planuje zgodność „na spokojnie”. Pierwszy twardy obowiązek działa od 11 września 2026.

10.12.2024 wejście w życie 11.06.2026 jednostki notyfikowane (już obowiązuje) dziś · 15.10.2026 11.09.2026 raportowanie 24h/72h (już obowiązuje) 11.12.2027 pełne stosowanie: SBOM, dokumentacja, CE

Co obowiązuje od 11 września 2026.

Artykuł 14 CRA: gdy dowiadujecie się, że podatność w Waszym produkcie jest aktywnie wykorzystywana (albo macie poważny incydent wpływający na jego bezpieczeństwo), zgłaszacie to do ENISA i krajowego CSIRT przez wspólną platformę raportowania. Obowiązek obejmuje wszystkie produkty z elementami cyfrowymi będące w okresie wsparcia, nie tylko te wprowadzane na rynek po tej dacie. Sterownik sprzedany w 2023, który wciąż wspieracie, też się liczy.

24 h

Early warning

Wstępne ostrzeżenie do ENISA/CSIRT od momentu, gdy dowiedzieliście się o exploitowanej podatności lub poważnym incydencie.

72 h

Pełne zgłoszenie

Charakterystyka podatności/incydentu, dotknięte produkty, dostępne środki zaradcze i obejścia.

14 dni / 1 mies.

Raport końcowy

14 dni po udostępnieniu poprawki (podatność) lub miesiąc po zgłoszeniu (incydent): opis, przyczyny, podjęte działania.

Za niedopełnienie obowiązków raportowania grożą kary do 15 mln EUR lub 2,5% światowego obrotu (wyższa z kwot). Zgłoszenia przechodzą przez platformę raportowania ENISA (Single Reporting Platform), uruchomioną 11 września 2026.

Klasy produktów i ścieżki oceny zgodności.

CRA obejmuje praktycznie każdy produkt „z elementami cyfrowymi” sprzedawany w UE: od sterownika przemysłowego po tablicę informacji pasażerskiej. Wyłączenia sektorowe dotyczą m.in. wyrobów medycznych, lotnictwa i motoryzacji (mają własne reżimy). Elektroniki kolejowej i przemysłowej na tej liście nie ma. Od klasy produktu zależy, czy wystarczy samoocena, czy potrzebna jest jednostka notyfikowana.

KlasaPrzykładyŚcieżka zgodności
Default (~90% rynku)sterowniki, wyświetlacze, urządzenia IoT, elektronika pokładowa i przystankowa bez funkcji stricte „security”samoocena producenta (moduł A)
Important (klasa I)routery, smart home z funkcją bezpieczeństwa, menedżery hasełnorma zharmonizowana albo jednostka notyfikowana
Important (klasa II)firewalle, hypervisory, mikrokontrolery odporne na manipulacjezawsze ocena strony trzeciej
Critical (Annex IV)karty inteligentne, HSM, inteligentne licznikidocelowo certyfikacja europejska

Ważny niuans na dziś: przepisy o jednostkach notyfikowanych obowiązują od 11 czerwca 2026, ale w unijnej bazie NANDO wciąż praktycznie nie ma jednostek notyfikowanych dla CRA. Komisja celuje w „wystarczającą liczbę” do grudnia 2026. Dla klasy default to bez znaczenia (samoocena), ale jeśli macie produkt z klasy important, kolejka do audytów będzie długa. Tym bardziej nie warto czekać.

Osiem kroków: trzy pierwsze już obowiązują.

Rack modułów elektroniki przemysłowej obok laptopa z wizualizacją grafu zależności oprogramowania (SBOM) i teczką dokumentacji technicznej

Obiecana lista: punkty 1–3 są obowiązkowe od 11 września 2026, punkty 4–8 to przygotowanie do grudnia 2027.

  1. Inwentaryzacja produktów w okresie wsparcia. Lista wszystkiego, co sprzedaliście i wciąż wspieracie. To te produkty od września podlegają raportowaniu.
  2. Procedura 24h/72h. Kto decyduje, że zdarzenie jest zgłaszalne, kto zgłasza, gotowe szablony zgłoszeń. Konto producenta w platformie raportowania ENISA (działa od 11 września 2026).
  3. Monitoring podatności: ten krok pomija prawie każdy. Firmy piszą procedury raportowania i… nie mają skąd dowiedzieć się, że jest co raportować. Zegar 24h rusza w momencie, gdy powzięliście wiedzę o exploitacji, więc bez ciągłego śledzenia CVE/CERT dla własnego firmware'u i komponentów (RTOS, stosy TCP/IP, biblioteki) pierwszym „systemem monitoringu” zostaje telefon od klienta, jak w scenariuszu z początku tej strony.
  4. Klasyfikacja produktów. Default / important I / important II / critical — od tego zależy ścieżka na 2027.
  5. SBOM z pipeline'u budowania. Automatyczny spis komponentów (CycloneDX/SPDX) generowany przy każdym buildzie. Yocto, Zephyr i współczesne toolchainy mają to wbudowane.
  6. Polityka Coordinated Vulnerability Disclosure. Kontakt security@, zasady przyjmowania zgłoszeń od badaczy, publikacja advisories.
  7. Secure by design w procesie. Threat modeling, secure boot, podpisywane aktualizacje OTA, hardening domyślnej konfiguracji; okres wsparcia (min. 5 lat) z bezpłatnymi poprawkami bezpieczeństwa.
  8. Dokumentacja techniczna pod CE. Risk assessment cyberbezpieczeństwa, architektura, wyniki testów — zbierane na bieżąco, nie odtwarzane wstecznie w 2027.
Większość z tych punktów to nie „projekt compliance”, tylko dobra inżynieria firmware'u, którą i tak warto mieć: SBOM, podpisane aktualizacje, monitoring podatności. CRA jedynie wyznacza datę, od której jej brak zaczyna kosztować.

Pomagamy zespołom embedded domknąć te punkty w praktyce: od automatycznego SBOM w pipeline, przez podpisywane OTA, po procedury raportowania. Zaczynamy od krótkiej rozmowy: co już macie, czego brakuje do obowiązków z września 2026, co można odłożyć na 2027.

Co jest pewne, a co propozycją.

Pewne (obowiązujące prawo): harmonogram CRA: 11.06.2026 (jednostki notyfikowane), 11.09.2026 (raportowanie), 11.12.2027 (pełne stosowanie), potwierdzony przez Komisję Europejską (strona zaktualizowana 22.06.2026, daty bez zmian). Przesunięcie AI Act (high-risk → 2.12.2027 i 2.08.2028), przyjęte przez Parlament 16.06.2026 i Radę 29.06.2026.

Propozycje (mogą się zmienić): Single Entry Point dla raportowania incydentów (Digital Omnibus, w toku w PE i Radzie), rewizja Cybersecurity Act, normy zharmonizowane CRA (prace CEN/CENELEC trwają).

Pełna lista źródeł (rozwiń)

Sprawdźmy, czy raportowanie CRA już u Was działa.

W krótkiej rozmowie przejdziemy po Waszym portfolio produktów: które podlegają CRA, czego brakuje do obowiązków z 11 września 2026, a co może poczekać do grudnia 2027. Bez zobowiązań.