EN 303 645 - praktyczny przewodnik dla zespołów tworzących produkty podłączone do sieci

Jeśli Twój produkt łączy się z siecią i trafia do czyjegoś domu albo do czyichś rąk, to prawdopodobnie właśnie tej normy potrzebujesz. EN 303 645 to norma zharmonizowana dotycząca bezpieczeństwa konsumenckiego IoT w ramach Aktu o cyberodporności (CRA). Jeśli ją stosujesz, zyskujesz domniemanie zgodności, a to oznacza, że samoocena wystarcza nawet w przypadku produktów klasy I.

Czym jest EN 303 645?

ETSI EN 303 645 to europejska norma, która określa wymagania cyberbezpieczeństwa dla konsumenckich produktów IoT. Jest obecnie główną normą uznaną przez UE (zharmonizowaną), do której CRA odwołuje się w przypadku konsumenckich produktów podłączonych do sieci.

Obejmuje: urządzenia inteligentnego domu, urządzenia noszone, zabawki podłączone do sieci, sprzęt AGD, urządzenia monitorujące zdrowie, inteligentne głośniki, kamery, zamki do drzwi, czyli wszystko, co ma interfejs sieciowy i trafia do konsumenta.

NIE obejmuje: automatyki przemysłowej (to IEC 62443), wyrobów medycznych (MDR), motoryzacji (UN R155/R156) ani infrastruktury korporacyjnej.

Norma opiera się na 13 obszarach bezpieczeństwa (takich jak hasła, aktualizacje, szyfrowanie) oraz jednej grupie dotyczącej ochrony danych. W ramach tych obszarów jest 68 konkretnych wymagań: 33 musisz spełnić, a 35 jest zalecanych, ale nieobowiązkowych.

Dlaczego to ważne dla zgodności z CRA

Jeśli Twój produkt podłączony do sieci należy do kategorii domyślnej albo jest produktem ważnym klasy I, stosowanie EN 303 645 daje Ci wyraźną przewagę:

• Produkty z kategorii domyślnej: samoocena jest zawsze dozwolona, ale EN 303 645 daje Ci uporządkowane ramy pracy, więc nie musisz samodzielnie interpretować CRA.
• Produkty klasy I: stosowanie normy zharmonizowanej, takiej jak EN 303 645, pozwala na samoocenę. Bez niej potrzebujesz audytu strony trzeciej.

Innymi słowy: EN 303 645 to Twój skrót do łatwiejszej ścieżki oceny zgodności.

13 obszarów - co naprawdę oznaczają

1. Brak uniwersalnych haseł domyślnych

Każde urządzenie musi mieć unikalne hasło albo wymagać od użytkownika ustawienia hasła podczas konfiguracji. Żadnego „admin/admin”. Żadnych wspólnych haseł fabrycznych dla wielu urządzeń.

Dotyczy to WSZYSTKICH mechanizmów uwierzytelniania opartych na hasłach, a nie tylko interfejsów chmurowych czy webowych. Obejmuje to:

• logowanie do panelu w chmurze i do API
• interfejs webowy urządzenia
• dostęp przez SSH lub konsolę szeregową na urządzeniu
• dane uwierzytelniające do parowania BLE
• każdy lokalny dostęp do powłoki (jeśli Twoje urządzenie działa na Linuksie, hasło roota też się liczy)

Jak to wygląda w praktyce:

• unikalne dane uwierzytelniające dla każdego urządzenia, generowane podczas produkcji
• metoda generowania musi być odporna na ataki brute force (nie może być sekwencyjna ani oparta na wzorcu)
• użytkownicy muszą móc łatwo zmienić hasło
• ochrona przed atakami brute force na wszystkich interfejsach dostępnych z sieci (blokada konta, ograniczanie liczby prób)

Dla Twojego zespołu: to dotyczy produkcji (nadawanie unikalnych danych uwierzytelniających), firmware’u (mechanizm zmiany hasła) i stosu sieciowego (ochrona przed brute force). To nie jest wyłącznie zmiana w oprogramowaniu. I nie zapominaj o dostępie lokalnym: urządzenie z włączonym SSH i wspólnym hasłem roota nie spełnia tego postanowienia, nawet jeśli po stronie chmury wszystko jest bez zarzutu.

2. Wdróż politykę ujawniania podatności

Musisz opublikować publiczną politykę ujawniania podatności. Każdy, kto znajdzie problem z bezpieczeństwem w Twoim produkcie, musi wiedzieć, gdzie go zgłosić i czego się spodziewać.

Jak to wygląda w praktyce:

• plik security.txt na Twojej stronie albo osobna strona z kontaktem w sprawach bezpieczeństwa
• opublikowany czas reakcji (np. „potwierdzamy otrzymanie zgłoszenia w ciągu 48 godzin”)
• proces, który za tym stoi: kto odbiera zgłoszenie, kto je klasyfikuje, kto naprawia

Dla Twojego zespołu: to proces, a nie funkcja produktu. Ktoś w Twojej organizacji musi odpowiadać za przyjmowanie zgłoszeń podatności. W ramach CRA zgłoszone podatności mogą też uruchamiać obowiązki zgłoszeniowe wobec CSIRT.

3. Aktualizuj oprogramowanie

Całe oprogramowanie, które nie jest niezmienne, musi dać się bezpiecznie aktualizować. Aktualizacje muszą być podpisane kryptograficznie. Użytkownicy muszą być o nich powiadamiani. Okres wsparcia musi zostać opublikowany.

Jak to wygląda w praktyce:

• mechanizm aktualizacji OTA z weryfikacją podpisu
• infrastruktura serwera aktualizacji (lub usługa chmurowa)
• powiadomienie użytkownika (powiadomienie push, alert w panelu, dioda LED na urządzeniu)
• opublikowana data zakończenia wsparcia, widoczna dla kupującego w momencie zakupu
• możliwość powrotu do poprzedniej wersji, jeśli aktualizacja się nie powiedzie

Dla Twojego zespołu: to często największa inwestycja inżynieryjna. Jeśli Twoje urządzenie nie ma dziś OTA, czeka Cię spory projekt firmware’owy i infrastrukturalny. CRA wymaga aktualizacji przez co najmniej 5 lat, więc zaplanuj na to budżet.

4. Bezpiecznie przechowuj wrażliwe parametry bezpieczeństwa

Klucze prywatne, dane uwierzytelniające, tokeny: wszystko, co wrażliwe, musi być bezpiecznie przechowywane. Żadnych danych uwierzytelniających zapisanych na sztywno w kodzie źródłowym. Tam, gdzie to możliwe, sprzętowe przechowywanie kluczy.

Jak to wygląda w praktyce:

• secure element lub TPM do przechowywania kluczy na urządzeniu
• brak danych uwierzytelniających w plikach binarnych firmware’u (częsty problem we wczesnych prototypach, które trafiają do produkcji)
• szyfrowane przechowywanie danych uwierzytelniających, jeśli sprzętowe bezpieczne przechowywanie nie jest dostępne
• możliwość rotacji kluczy

Dla Twojego zespołu: przejrzyj firmware pod kątem zaszytych na sztywno sekretów. Sprawdź, czy proces produkcyjny bezpiecznie nadaje dane uwierzytelniające, czy kopiuje ten sam klucz na każde urządzenie.

5. Komunikuj się bezpiecznie

Cała komunikacja zewnętrzna musi korzystać z szyfrowania zgodnego z aktualnym stanem techniki. Połączenia muszą być uwierzytelnione. Żadnego przesyłania wrażliwych danych otwartym tekstem.

Jak to wygląda w praktyce:

• TLS 1.2+ dla całej komunikacji z chmurą (zalecany TLS 1.3)
• mTLS do uwierzytelniania urządzenia wobec chmury tam, gdzie to wykonalne
• przypinanie certyfikatów (certificate pinning) lub walidacja łańcucha zaufania
• brak awaryjnego przejścia na HTTP: jeśli TLS zawiedzie, połączenie też się nie udaje

Dla Twojego zespołu: sprawdź całą ścieżkę komunikacji. Od urządzenia do bramki, od bramki do chmury, od chmury do panelu, od panelu do użytkownika. Każdy odcinek wymaga szyfrowania. Zwróć też uwagę na komunikację w sieci lokalnej: komunikacja między urządzeniami w tej samej sieci Wi-Fi to nadal interfejs sieciowy.

6. Minimalizuj eksponowaną powierzchnię ataku

Wyłącz wszystko, czego nie potrzebujesz. Nieużywane porty, nieużywane usługi, interfejsy debugowania, narzędzia deweloperskie pozostawione w produkcyjnym firmware.

Jak to wygląda w praktyce:

• wyłącz porty debugowania UART/JTAG w buildach produkcyjnych
• zamknij nieużywane porty sieciowe (przeskanuj własne urządzenie)
• usuń z produkcyjnego firmware’u narzędzia deweloperskie, testowe endpointy i szczegółowe logowanie
• uruchamiaj każdy proces z minimalnymi niezbędnymi uprawnieniami (nie jako root)
• wyłącz Bluetooth, jeśli był potrzebny tylko podczas prac rozwojowych

Dla Twojego zespołu: tutaj audyt firmware’u naprawdę się opłaca. Przeskanuj produkcyjne urządzenie z sieci. Spisz każdy otwarty port i każdą działającą usługę. Jeśli nie potrafisz wyjaśnić, po co coś tam jest, zamknij to.

7. Zapewnij integralność oprogramowania

Secure boot (bezpieczny rozruch): weryfikacja integralności firmware’u przy starcie. Jeśli coś zostało zmodyfikowane, urządzenie powinno to wykryć i zgłosić alarm.

Jak to wygląda w praktyce:

• sprzętowy root of trust (łańcuch secure boot od bootloadera do aplikacji)
• podpisane obrazy firmware’u weryfikowane przed uruchomieniem
• jeśli weryfikacja integralności się nie powiedzie: odmowa uruchomienia albo start w trybie odzyskiwania i alarm
• ochrona przed atakami polegającymi na obniżeniu wersji firmware’u (downgrade)

Dla Twojego zespołu: jeśli Twój mikrokontroler obsługuje secure boot (obsługuje go większość nowoczesnych układów: ESP32, STM32, nRF), włącz go. Jeśli jeszcze go nie używasz, wymaga to zmian w bootloaderze i procesu zarządzania kluczami do podpisywania firmware’u.

8. Zapewnij ochronę danych osobowych

Dane osobowe muszą być szyfrowane. Użytkownicy muszą wiedzieć, jakie dane są zbierane i w jakim celu. Ochrona danych musi być uwzględniona w fazie projektowania, od samego początku.

Jak to wygląda w praktyce:

• szyfruj dane osobowe w spoczynku, na urządzeniu i w chmurze
• informacja o prywatności dostępna dla użytkownika (w aplikacji, na urządzeniu lub na stronie produktu)
• udokumentuj, jakie dane osobowe przetwarzasz i na jakiej podstawie prawnej

Dla Twojego zespołu: zacznij od spisania, jakie dokładnie dane zbiera Twoje urządzenie. Możesz się zdziwić: dane o lokalizacji z identyfikatorów SSID sieci Wi-Fi, wzorce użytkowania, znaczniki czasu, które zdradzają codzienną rutynę. Jeśli to dane osobowe w rozumieniu RODO, muszą być chronione.

9. Zapewnij odporność systemów na przerwy w działaniu

Urządzenie musi działać lokalnie, gdy chmura jest niedostępna. Po utracie zasilania musi bez problemów wrócić do pracy.

Jak to wygląda w praktyce:

• podstawowe funkcje działają offline (inteligentny zamek musi nadal się zamykać i otwierać bez internetu)
• łagodna obsługa utraty połączenia z chmurą (lokalne buforowanie danych, automatyczne ponowne łączenie)
• czysty powrót do pracy po utracie zasilania (bez uszkodzonego stanu, bez resetu do ustawień fabrycznych)

Dla Twojego zespołu: przetestuj urządzenie z odłączonym kablem internetowym. Jeśli zamienia się w cegłę, to problem ze zgodnością, a nie tylko z UX.

10. Analizuj dane telemetryczne systemu (opcjonalnie)

Jeśli zbierasz telemetrię, monitoruj ją pod kątem anomalii bezpieczeństwa. To postanowienie zalecane, a nie obowiązkowe, ale w kontekście CRA wzmacnia Twoje możliwości monitorowania podatności.

Jak to wygląda w praktyce:

• analiza logów w backendzie chmurowym pod kątem nietypowych wzorców (nieoczekiwane wersje firmware’u, nienormalne wolumeny danych, połączenia z nieoczekiwanych regionów)
• ustalenie, jak wygląda stan „normalny”, żeby móc wykryć „nienormalny”

Dla Twojego zespołu: jeśli masz już telemetrię urządzeń (a ma ją większość produktów IoT), dodaj podstawowe wykrywanie anomalii. Nie musi to być AI: proste alerty progowe dla wzorców połączeń i wolumenów danych dają bardzo dużo.

11. Ułatw użytkownikom usuwanie danych osobowych

Użytkownicy muszą mieć możliwość usunięcia swoich danych, zarówno na urządzeniu, jak i w Twoim backendzie chmurowym.

Jak to wygląda w praktyce:

• reset do ustawień fabrycznych, który faktycznie usuwa zapisane dane (a nie tylko ustawienia)
• usunięcie konta w aplikacji/panelu, które usuwa dane zapisane w chmurze
• usunięcie danych musi być kompletne, a nie polegać tylko na „ukryciu ich przed użytkownikiem”

Dla Twojego zespołu: przetestuj reset do ustawień fabrycznych. Czy naprawdę usuwa dane uwierzytelniające, logi użytkowania i dane osobowe? A może tylko przywraca ustawienia, podczas gdy w pamięci flash nadal zostaje wszystko?

12. Ułatw instalację i konserwację

Domyślna konfiguracja musi prowadzić do bezpiecznego stanu. Użytkownicy nie powinni musieć podejmować decyzji dotyczących bezpieczeństwa podczas konfiguracji, żeby być bezpieczni.

Jak to wygląda w praktyce:

• kreator pierwszej konfiguracji, który wymusza zmianę hasła
• szyfrowanie i bezpieczna komunikacja włączone domyślnie (a nie „włącz w ustawieniach”)
• ustawienia istotne dla bezpieczeństwa wyraźnie opisane i udokumentowane

Dla Twojego zespołu: przejdź przez proces konfiguracji jak użytkownik bez wiedzy technicznej. Jeśli pominięcie wszystkich opcjonalnych kroków zostawia urządzenie niezabezpieczone, to problem ze zgodnością.

13. Weryfikuj dane wejściowe

Wszystkie dane wejściowe, od użytkowników, z sieci i z API, muszą być walidowane. Nieprawidłowe dane nie mogą zawiesić urządzenia ani posłużyć do manipulowania nim.

Jak to wygląda w praktyce:

• walidacja danych wejściowych na wszystkich interfejsach zewnętrznych (wiadomości MQTT, żądania HTTP, komendy BLE, wejście szeregowe)
• ochrona przed przepełnieniem bufora
• odrzucanie nieoczekiwanych typów, rozmiarów i formatów danych
• testy fuzzingowe podczas rozwoju produktu

Dla Twojego zespołu: jeśli interfejsy sieciowe Twojego urządzenia nie przeszły jeszcze testów fuzzingowych, zacznij od tego. Zaskakująco wiele urządzeń IoT zawiesza się na nieprawidłowo sformatowanych pakietach.

Postanowienia dotyczące ochrony danych

Oprócz 13 postanowień dotyczących cyberbezpieczeństwa EN 303 645 zawiera sekcję o ochronie danych, spójną z RODO:

• Przejrzystość - informuj użytkowników, jakie dane zbierasz i po co
• Zgoda - jeśli potrzebujesz zgody, zadbaj, żeby była naprawdę świadoma
• Minimalizacja danych - zbieraj tylko to, czego potrzebujesz
• Właściwe postępowanie z danymi - przestrzegaj przepisów o ochronie danych przez cały cykl życia danych

To nie są wymagania CRA, tylko dostosowanie do RODO. Ale ponieważ Twój produkt niemal na pewno przetwarza dane osobowe, musisz prowadzić oba tory równolegle.

RODO nie jest też jedyną regulacją w tym obszarze. Unijny Akt w sprawie danych (Data Act, 2023/2854, stosowany od września 2025 r.) dodaje obowiązki, które dotyczą właśnie produktów podłączonych do sieci:

- Dostęp użytkownika do danych generowanych przez urządzenie - użytkownicy muszą mieć łatwy i bezpłatny dostęp do danych, które generuje ich urządzenie

- Przenoszalność danych - użytkownicy mogą udostępniać swoje dane stronom trzecim. Nie możesz zaprojektować produktu tak, żeby to utrudniał

- Ograniczenia wykorzystania danych przez producenta - nie możesz wykorzystywać danych generowanych przez urządzenie użytkownika do celów, na które użytkownik się nie zgodził

Sekcja 6 EN 303 645 obejmuje podstawy (przejrzystość, zgodę, minimalizację). RODO idzie dalej w zakresie praw dotyczących danych osobowych. Akt w sprawie danych idzie jeszcze dalej w kwestii dostępu do danych generowanych przez urządzenie i ich przenoszalności. W przypadku zespołów tworzących produkty podłączone do sieci wszystkie trzy regulacje obowiązują równolegle, a sekcja 6 jest najcieńszą z tych trzech warstw.

Jak testować?

EN 303 645 określa, CO trzeba zrobić. Norma uzupełniająca ETSI TS 103 701 określa, JAK to przetestować. Zawiera przypadki testowe dla każdego postanowienia: co sprawdzić, jak to zweryfikować i co oznacza wynik pozytywny lub negatywny.

Jeśli przeprowadzasz samoocenę, TS 103 701 daje Ci uporządkowany plan testów, więc nie musisz wymyślać własnego.

Czy EN 303 645 wystarczy?

W pierwszym wpisie na blogu opisaliśmy trzy filary zgodności z CRA:

1. Twój produkt - bezpieczny już na etapie projektowania, przetestowany, udokumentowany
2. Twoja organizacja - zdolna do obsługi podatności, zarządzania dostawcami i utrzymywania bezpieczeństwa
3. Twoje procesy - ciągłe, a nie jednorazowe

EN 303 645 obejmuje filar 1. Ale nie w 100%, a filarów 2 i 3 ledwie dotyka.

Luki w filarze 1:

• Minimalizacja danych - CRA traktuje ją jako wymaganie cyberbezpieczeństwa. Musisz zająć się nią wprost.
• Wpływ na inne urządzenia - według CRA Twój produkt nie może negatywnie wpływać na inne urządzenia w sieci. EN 303 645 skupia się na samym urządzeniu, a nie na jego sąsiadach.
• Ograniczanie skutków incydentów - według CRA produkt trzeba projektować tak, żeby ograniczać skutki, gdy coś pójdzie nie tak. EN 303 645 dotyka tego w obszarach 6 (powierzchnia ataku) i 7 (integralność), ale nie traktuje tego jako osobnego wymagania.

Czego brakuje zupełnie (filary 2 i 3):

• zgłaszanie do CSIRT w ciągu 24 godzin (art. 14)
• tworzenie i utrzymywanie SBOM (załącznik I, część II)
• proces skoordynowanego ujawniania podatności, wykraczający poza samo opublikowanie polityki
• aktualizacje zabezpieczeń przez co najmniej 5 lat, z poprawkami dostępnymi przez 10 lat
• ciągła zgodność: utrzymywanie aktualnej oceny ryzyka i dokumentacji przez cały okres wsparcia

Postanowienie 5.2 EN 303 645 mówi: „opublikuj politykę ujawniania podatności”. CRA mówi: „zgłaszaj organom w ciągu 24 godzin, utrzymuj SBOM, zapewnij dostępność poprawek przez 10 lat, powiadamiaj użytkowników o podatnościach”.

Podsumowanie

Stosuj EN 303 645 w zakresie bezpieczeństwa produktu. Następnie uzupełnij luki w pozostałych punktach filaru 1, opierając się bezpośrednio na tekście CRA, a filarami 2 i 3 zajmij się osobno. „Stosujemy EN 303 645” to nie to samo co „spełniamy wymagania CRA”, ale po stronie produktu ta norma prowadzi Cię przez większość drogi.

Dalsza lektura

EN 303 645 - dokument z wymaganiami

ETSI TS 103 701 - jak testować

Co trzeba zrobić, aby spełnić wymagania CRA - artykuł o pozostałych wymaganiach CRA