Výroba zařízení IoT se tradičně chápe jako hardwarový projekt: elektronika, kryt, napájení, EMC, firmware, výrobní testování, dokumentace a nakonec prodej.

Síťově připojený produkt však po předání nezůstává beze změny. Nové zranitelnosti se objevují ve vlastním kódu, v použitých knihovnách, v operačním systému nebo v komunikačních komponentách. Hrozby se mohou měnit, zatímco produkt léta pracuje na stejném místě.

Akt Evropské unie o kybernetické odolnosti (Cyber Resilience Act, CRA) z tohoto rizika spojeného s životním cyklem činí povinnost výrobce.

Kde jsme v září 2026?

CRA, tedy nařízení (EU) 2024/2847, vstoupil v platnost 10. prosince 2024.

Hlavní požadavky na produkty se použijí od 11. prosince 2027. Oznamovací povinnosti se však uplatňují již od 11. září 2026. Příprava tedy není vzdáleným projektem, který začne až koncem roku 2027.

Nařízení se vztahuje na hardwarové a softwarové produkty s digitálními prvky; přesnou působnost, kategorii produktu a postup posuzování shody musí každý výrobce určit pro svůj vlastní produkt.

Průmyslová brána IoT, měřidlo schopné síťové komunikace, inteligentní řídicí jednotka nebo související software s velkou pravděpodobností patří do skupiny produktů, kterou je kvůli CRA třeba vědomě přezkoumat.

Security by design už není jen heslo

Nařízení stanoví závazné požadavky na kybernetickou bezpečnost při návrhu, vývoji, výrobě a údržbě. Bezpečnost proto nelze na konci projektu „přidat“ k hotovému produktu penetračním testem.

Již při návrhu architektury je třeba mimo jiné rozhodnout:

  • které služby jsou ve výchozím stavu dostupné;
  • jak probíhá jednoznačná identifikace zařízení;
  • zda existují výchozí tovární, sdílené nebo snadno uhodnutelné přihlašovací údaje;
  • jak jsou data chráněna při přenosu a při uložení;
  • jak lze omezit přístup;
  • jak lze zaznamenávat bezpečnostní události;
  • co se stane při chybném nebo zmanipulovaném vstupu;
  • jak lze obnovit bezpečný stav.

Zásada minimální útočné plochy znamená, že co není pro fungování produktu nezbytné, nemá být ve výchozím stavu dostupné.

Aktualizovatelnost je funkcí produktu

Nestačí navrhnout síťově připojené zařízení tak, aby v den prodeje působilo bezpečně. Musí být také bezpečně aktualizovatelné.

K tomu může být zapotřebí:

  • digitálně podepsaný firmware s kontrolou integrity;
  • bezpečný aktualizační kanál;
  • správa verzí a kompatibility;
  • obnova po neúspěšné aktualizaci;
  • hromadná, ale kontrolovaná správa zařízení;
  • záznam o aktualizacích a stav instalace;
  • jednoznačné sdělení doby podpory.

Aktualizace OTA sama o sobě bezpečnost nezaručuje. Pokud chybí ověření podpisu, správa oprávnění, rollback nebo doklad o instalaci, může se útočnou plochou stát samotný aktualizační mechanismus.

Řešení zranitelností po celou dobu podpory

Jednou z podstatných změn, které CRA přináší, je to, že bezpečnost produktu chápe jako proces. Výrobce musí být schopen zranitelnosti přijímat, vyhodnocovat, opravovat a komunikovat.

K tomu je potřeba i fungující vnitřní pořádek:

  • kdo přijímá bezpečnostní hlášení;
  • jak se hodnotí závažnost a dotčení;
  • které verze produktu jsou dotčeny;
  • která komponenta problém způsobuje;
  • jak se oprava připravuje a testuje;
  • jak se dostane k zákazníkům;
  • jak lze uzavření zdokumentovat.

Samotná e-mailová adresa ještě není proces řešení zranitelností.

Je třeba vědět, co je ve firmwaru

Moderní firmware a software jsou jen zřídka tvořeny výhradně vlastním kódem. Open-source knihovny, komponenty operačního systému, síťové stacky a SDK dodavatelů jsou vrstveny na sebe.

Pokud se některá z nich stane zranitelnou, výrobce musí vědět, kterých produktů a verzí se to týká. K tomu je nutná uspořádaná evidence závislostí a komponent. Důležitým nástrojem zde může být soupis softwarových komponent, tedy SBOM.

SBOM je však jen inventář. Hodnotu přináší teprve tehdy, když je propojen se správou verzí, s informacemi o zranitelnostech, s dotčenou instalovanou základnou zařízení a s procesem aktualizací.

Oznamovací povinnost vyžaduje schopnost detekce

Od 11. září 2026 se na výrobce vztahuje oznamovací povinnost u některých aktivně zneužívaných zranitelností a závažných bezpečnostních incidentů. Podrobný postup a aktuální pokyny orgánů musí výrobce dodržovat podle své role a svého produktu.

Z praktického hlediska je však jedna věc jistá: nelze včas oznámit to, co organizace nedokáže zjistit, interně eskalovat a přiřadit k verzím produktu.

Předpoklady oznamovacího procesu proto jsou:

  • evidence produktů a verzí;
  • kontaktní osoba pro bezpečnost;
  • klasifikace incidentů;
  • pravidla pro rozhodování a schvalování;
  • komunikace se zákazníky;
  • prokazatelný záznam událostí.

Za označením CE budou stát doklady o vývoji

Podle CRA bude označení CE u vyhovujících produktů vyjadřovat i to, že splňují požadavky na kybernetickou bezpečnost. V závislosti na rizikové klasifikaci produktu může být nutný odlišný postup posuzování shody, u některých kategorií se zapojením oznámeného subjektu (notified body).

To vyžaduje zdokumentovaný vývojový proces. Uchovávat je třeba posouzení rizik, architektonická rozhodnutí, výsledky testů, informace o komponentách, řešení zranitelností a doklady o vydaných verzích.

Zpětně je velmi obtížné věrohodně zrekonstruovat, proč bylo bezpečnostní rozhodnutí přijato před lety. Dokumentaci je proto nutné budovat souběžně s vývojem.

Co to znamená pro vývoj typu OrigSmart?

Vzhledem k hardwarovým, gatewayovým a platformním schopnostem OrigSmart se bezpečnost nemůže zastavit u krytu zařízení. Celý životní cyklus systému je nutné řídit jako celek:

  • zakázkový hardware a firmware;
  • komunikace v terénu;
  • identita a konfigurace zařízení;
  • bezpečná aktualizace;
  • oprávnění na straně platformy;
  • záznam událostí a monitoring;
  • řešení incidentů a zranitelností;
  • provozní procesy na straně zákazníka.

Pokrytí celého hodnotového řetězce je zároveň odpovědností i konkurenční výhodou. Výrobce a integrátor, který propojí hardware, software, provoz a prokazatelné bezpečnostní procesy už při návrhu produktu, nebude koncem roku 2027 ve spěchu vytvářet dokumenty o shodě.

Podstatou CRA není přiložit k zařízení IoT více papírů, ale zajistit, aby digitální produkt po celou dobu svého podporovaného životního cyklu zůstal zvládnutelným kybernetickým rizikem.

Proberme váš projekt

Zdroje

Poznámka: článek slouží jako obecná odborná informace a nepředstavuje právní ani compliance poradenství.