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: Tomek Wojciechowski · Ostatnia aktualizacja:
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).
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
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.
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.
Early warning
Wstępne ostrzeżenie do ENISA/CSIRT od momentu, gdy dowiedzieliście się o exploitowanej podatności lub poważnym incydencie.
Pełne zgłoszenie
Charakterystyka podatności/incydentu, dotknięte produkty, dostępne środki zaradcze i obejścia.
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.
| Klasa | Przykł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 manipulacje | zawsze ocena strony trzeciej |
| Critical (Annex IV) | karty inteligentne, HSM, inteligentne liczniki | docelowo 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ą.
Obiecana lista: punkty 1–3 są obowiązkowe od 11 września 2026, punkty 4–8 to przygotowanie do grudnia 2027.
- Inwentaryzacja produktów w okresie wsparcia. Lista wszystkiego, co sprzedaliście i wciąż wspieracie. To te produkty od września podlegają raportowaniu.
- 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).
- 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.
- Klasyfikacja produktów. Default / important I / important II / critical — od tego zależy ścieżka na 2027.
- 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.
- Polityka Coordinated Vulnerability Disclosure. Kontakt security@, zasady przyjmowania zgłoszeń od badaczy, publikacja advisories.
- 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.
- 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ń)
- Komisja Europejska: Cyber Resilience Act (aktualizacja 22.06.2026)
- Komisja Europejska: CRA reporting obligations
- Rada UE: porozumienie ws. omnibusu AI (7.05.2026)
- Bird & Bird: CRA phased entry into application
- Crowell & Moring: countdown do 11.09.2026
- cyberresilienceact.eu: przepisy o notified bodies od 11.06.2026
- Gibson Dunn: przesunięte terminy AI Act
Powiązane tematy.
AI dla embedded
Agenci AI w zespołach firmware, m.in. automatyczny SBOM i testy bezpieczeństwa w pipeline.
Zgodność z AI Act
Druga regulacja z tej historii: co faktycznie przesunięto i kogo dotyczy transparentność od 2.08.2026.
Benchmark: GCC vs Keil
Nasz raport z pomiarów na prawdziwym STM32: open source kontra komercyjny toolchain.
Vibe coding a prawo
CRA to jedna z dziesięciu pułapek aplikacji pisanej z AI. Pozostałe: RODO, PKE, prawa konsumenta, DSA, EAA i AI Act.
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ń.