Akt o kybernetické odolnosti (CRA): povinnosti výrobců a praktické příklady

Nařízení (EU) 2024/2847, známé jako akt o kybernetické odolnosti nebo Cyber Resilience Act (CRA), je první celoevropský předpis, který stanoví povinné požadavky na kybernetickou bezpečnost hardwaru a softwaru po celou dobu jeho životního cyklu. Od 11. září 2026 už výrobci musí hlásit aktivně zneužívané zranitelnosti a závažné incidenty, v plném rozsahu se nařízení použije od 11. prosince 2027. Vysvětlujeme, na koho CRA dopadá a co konkrétně vyžaduje – na praktických příkladech.

Akt o kybernetické odolnosti (Cyber Resilience Act, CRA) je nařízení EU, které ukládá výrobcům, dovozcům a distributorům povinnost zajistit, aby hardware a software uváděný na trh EU byl bezpečně navržen, po stanovenou dobu dostával bezpečnostní aktualizace a nesl označení CE. Jde o první horizontální produktovou regulaci kybernetické bezpečnosti – dosavadní předpisy (zákon o kybernetické bezpečnosti, směrnice NIS2 nebo akt o kybernetické bezpečnosti tzv. CSA) povinné požadavky na bezpečnost samotných produktů s digitálními prvky přímo nestanovily.

Zatímco NIS2 reguluje organizace a bezpečnost jejich systémů, CRA reguluje produkt, který firma uvádí na trh – bez ohledu na její velikost či odvětví. Nejdůležitější milníky:

Produkty uvedené na trh před 11. 12. 2027 musí požadavky CRA splnit jen tehdy, pokud po tomto datu projdou podstatnou změnou (čl. 69 odst. 2). Ohlašovací povinnost se na ně ale vztahuje vždy (čl. 69 odst. 3).

CRA se vztahuje na produkty s digitálními prvky dodané na trh v rámci obchodní činnosti, jejichž zamýšlené nebo rozumně předvídatelné použití zahrnuje přímé nebo nepřímé logické či fyzické datové připojení k zařízení nebo síti. Produktem je software i hardware včetně samostatně uváděných komponent a včetně jejich řešení pro zpracování dat na dálku. 

V praxi tedy routery, modemy, chytré televize, zámky a hodinky, chůvičky, průmyslové senzory a řídicí systémy, operační systémy, desktopové a mobilní aplikace, hry, softwarové knihovny či firmware.

Odůvodnění vysvětluje, proč je rozsah tak široký následovně: i méně kritický hardware nebo software může posloužit jako vstupní bod útoku, ze kterého se útočník přesune dál v síti. Proto se CRA týká i produktů propojených jen logicky – přes síťové sokety, roury, soubory nebo API – a i produktů připojených jen nepřímo, protože útoky se šíří i řetězením několika zranitelností.

Cloud a backend: kdy spadají pod CRA? Rozhoduje, zda jde o řešení pro zpracování dat na dálku – tedy software navržený výrobcem (nebo na jeho odpovědnost), bez kterého by produkt nemohl plnit některou ze svých funkcí.

Veřejná správa: produkt poskytovaný v rámci služby za poplatek, který jen pokrývá skutečné náklady, není jen z tohoto důvodu obchodní činností. Software, který si úřad vyvine nebo upraví výhradně pro vlastní potřebu, se nepovažuje za dodaný na trh.

Výjimky: CRA se nepoužije na zdravotnické prostředky a diagnostické prostředky in vitro (mají vlastní požadavky na IT bezpečnost), vozidla podle typového schvalování, certifikované letecké výrobky, lodní vybavení, produkty vyvinuté výhradně pro národní bezpečnost a obranu a náhradní díly vyrobené podle stejné specifikace jako nahrazovaná komponenta. Výjimka pro náhradní díly má umožnit opravy a delší životnost výrobků – kryje díly pro starší produkty i díly, které už posouzením shody prošly.

CRA se vztahuje jen na produkty dodané v rámci obchodní činnosti. U open-source softwaru proto nerozhoduje, jak byl vyvinut nebo financován, ale zda ho výrobce zpeněžuje (body 15 a 18 odůvodnění).

Komponenta s otevřeným kódem určená k integraci do produktů jiných výrobců se považuje za dodanou na trh jen tehdy, pokud ji zpeněžuje její původní výrobce.

Správci softwaru s otevřeným zdrojovým kódem (open-source stewards) jsou právnické osoby, které soustavně podporují vývoj open-source produktů určených pro obchodní využití – typicky nadace nebo firmy a neziskovky publikující open source v podnikatelském kontextu. Podpora zahrnuje např. hosting platforem pro spolupráci a zdrojového kódu nebo řízení a směrování vývoje. Záměr zahrnout komponentu do zpeněžených produktů je dán i tehdy, když výrobci, kteří ji integrují, pravidelně přispívají k jejímu vývoji nebo ji finančně podporují (bod 19). Správci mají jen mírný režim (čl. 24), nesmí připojovat označení CE (bod 19) a nelze jim uložit pokutu (čl. 64 odst. 10).

Příklad z praxe: Česká firma vyvíjí IoT bránu a používá v ní knihovnu z GitHubu, kterou nikdo nezpeněžuje. Knihovna sama pod CRA nespadá, výrobce brány ale odpovídá za celý produkt včetně této komponenty – musí u ní vykonat náležitou péči (čl. 13 odst. 5) a nalezenou zranitelnost nahlásit jejímu správci a odstranit (čl. 13 odst. 6).

Podle míry rizika se produkty dělí do čtyř kategorií. Od kategorie se odvíjí, zda si výrobce posoudí shodu sám, nebo potřebuje třetí stranu. Naprostá většina produktů spadá do výchozí kategorie.

Proč zrovna tyto produkty? Odůvodnění zdůrazňuje spotřebitelské produkty pro zranitelné skupiny – hračky a dětské chůvičky – a výrobky, jejichž zneužití může poškodit zdraví nebo bezpečí uživatelů: chytré dveřní zámky, alarmy, připojené hračky a osobní nositelnou zdravotní techniku (bod 10). U produktů s bezpečnostní funkcí, jako jsou správci zavádění, se zranitelnost může šířit celým dodavatelským řetězcem (bod 43).

Rozhoduje hlavní funkce. Za důležitý produkt se považuje jen ten, jehož hlavní funkcí je některá z kategorií přílohy III. Firewall je produkt třídy II, ale jiný produkt, který firewall jen obsahuje, se tím důležitým nestává (bod 45, čl. 7 odst. 1). Chytrá televize s vestavěným prohlížečem tedy není „prohlížeč“ ve smyslu třídy I. Technické popisy kategorií upřesňuje prováděcí nařízení Komise (EU) 2025/2392.

Výrobci open-source produktů třídy I a II mohou použít vlastní posouzení (modul A), pokud zveřejní technickou dokumentaci (čl. 32 odst. 5).

1. Posouzení rizik a bezpečnost od návrhu. Výrobce musí posoudit kybernetická rizika produktu a zohlednit je ve všech fázích – od plánování po údržbu (čl. 13 odst. 2 až 4). Produkt nesmí být uveden na trh se známými zneužitelnými zranitelnostmi, má mít bezpečné výchozí nastavení, řízení přístupu, šifrování a co nejmenší plochu útoku (příloha I). Pokud některý požadavek pro produkt není relevantní, musí to výrobce zdůvodnit. Odůvodnění uvádí příklad: produkt musí dodržovat široce uznávaný standard interoperability, i když jeho bezpečnostní prvky už nejsou na úrovni stavu techniky. Rizika pak má výrobce řešit jinak – např. omezit zamýšlený účel na důvěryhodná prostředí nebo uživatele o rizicích informovat (bod 55).

2. Komponenty třetích stran. Výrobce musí u nakupovaných komponent – včetně open source – vykonat náležitou péči (čl. 13 odst. 5). Odůvodnění ji konkretizuje: ověřit, zda komponenta nese označení CE, zkontrolovat historii bezpečnostních aktualizací, prověřit, zda nemá zranitelnosti v evropské nebo jiné veřejné databázi zranitelností, případně provést další bezpečnostní testy (bod 34). Hned po skončení přechodného období ještě komponenty CE mít nemusí – výrobce pak musí postupovat jinými prostředky (bod 35). Součástí dokumentace je i softwarový kusovník (SBOM).

3. Doba podpory a aktualizace. Doba podpory má odpovídat době, po kterou se produkt očekávaně používá, a činí nejméně 5 let (čl. 13 odst. 8). Odůvodnění uvádí příklady:

• delší než 5 let – hardwarové komponenty jako základní desky a mikroprocesory, síťová zařízení jako routery, modemy a switche, operační systémy nebo nástroje pro střih videa; výrazně delší u průmyslových řídicích systémů (bod 60),
• kratší než 5 let – jen pokud se produkt reálně používá kratší dobu, např. aplikace pro trasování kontaktů po dobu pandemie nebo aplikace dostupná jen v rámci předplatného (bod 60),
• software ve více verzích – výrobce smí aktualizovat jen poslední verzi, pokud ji uživatelé dostanou zdarma a bez nutnosti nového hardwaru (např. upgrade operačního systému bez potřeby rychlejšího procesoru). Pokud ale smartphone nový operační systém nezvládne, musí výrobce aktualizovat alespoň poslední kompatibilní verzi (bod 40, čl. 13 odst. 10).

Každá bezpečnostní aktualizace musí zůstat dostupná alespoň 10 let nebo po zbytek doby podpory (čl. 13 odst. 9). Datum konce podpory (alespoň měsíc a rok) musí být jasně uvedeno při nákupu a produkt má uživatele o konci podpory upozornit, je-li to technicky možné (čl. 13 odst. 19). Po skončení podpory může výrobce zvážit uvolnění zdrojového kódu jiné firmě, která bude zranitelnosti řešit dál, nebo veřejnosti; vlastnictví si může chránit smluvně (bod 61).

4. Jednotné kontaktní místo. Uživatelé musí mít snadný způsob, jak výrobci nahlásit zranitelnost (čl. 13 odst. 17). Chatbot nestačí – výrobce musí nabídnout i telefon, e-mail nebo kontaktní formulář (bod 63). Potřebná je také politika koordinovaného zveřejňování zranitelností.

5. Dokumentace a ukončení činnosti. Technickou dokumentaci a EU prohlášení o shodě je nutné uchovávat 10 let nebo po dobu podpory, podle toho, co je delší (čl. 13 odst. 13). Pokud výrobce končí činnost, musí o tom předem informovat dozorové orgány i uživatele (čl. 13 odst. 23).

Podstatná změna je změna po uvedení na trh, která ovlivní soulad se základními požadavky nebo změní zamýšlený účel (čl. 3 bod 30). Je důležitá ze dvou důvodů: vyžaduje ověření shody, případně nové posouzení (bod 41), a u produktů uvedených na trh před 11. 12. 2027 spouští použití CRA (čl. 69 odst. 2). Kdo produkt podstatně změní, stává se výrobcem (čl. 22).

Nezáleží na tom, zda je nová funkce dodána samostatně, nebo „zabalena“ spolu s bezpečnostní aktualizací (bod 39). Spojit novou funkci se záplatou proto nepomůže.

Od 11. 9. 2026 musí výrobci hlásit dva typy událostí, a to současně CSIRT určenému jako koordinátor a agentuře ENISA přes jednotnou platformu pro podávání zpráv (čl. 14, bod 65):

• aktivně zneužívanou zranitelnost – existuje spolehlivý důkaz, že ji útočník zneužil bez svolení vlastníka systému. Odůvodnění jako příklad uvádí slabinu ve funkcích identifikace a autentizace. Zranitelnosti nalezené v dobré víře při testování nebo výzkumu se povinně nehlásí (bod 68),
• závažný incident s dopadem na bezpečnost produktu – incident ohrožuje dostupnost, autenticitu, integritu nebo důvěrnost citlivých dat či funkcí, nebo vedl či může vést ke spuštění škodlivého kódu (čl. 14 odst. 5). Typický příklad z odůvodnění: útočník vloží škodlivý kód do kanálu, kterým výrobce distribuuje bezpečnostní aktualizace (bod 68).

Modelový příklad: Výrobce chytrých kamer zjistí v pátek ve 20:00, že útočníci obcházejí přihlašování a sledují záznamy uživatelů. Včasné varování musí podat do soboty 20:00, oznámení do pondělí 20:00 a závěrečnou zprávu do 14 dnů od vydání opravy. Současně musí informovat dotčené uživatele a doporučit jim opatření – např. zveřejněním na webu nebo přímým kontaktováním (čl. 14 odst. 8, bod 67). Pokud to výrobce neudělá včas, může uživatele informovat CSIRT.

Komu hlásit: CSIRT členského státu, v němž má výrobce hlavní provozovnu, tedy tam, kde se převážně rozhoduje o kybernetické bezpečnosti jeho produktů; nelze-li to určit, rozhoduje provozovna s nejvíce zaměstnanci v EU (čl. 14 odst. 7). V České republice roli CSIRT koordinátora plní vládní CERT při NÚKIB. Výrobce bez provozovny v EU hlásí podle státu svého zplnomocněného zástupce, dovozce, distributora nebo největšího počtu uživatelů.

Pokyny Komise z července 2026 potvrzují, že se zpětně nehlásí zneužití, o kterém výrobce věděl už před 11. 9. 2026. Povinnost se ale vztahuje i na produkty prodané před tímto datem.

Dovozce smí uvést na trh jen produkt, u kterého výrobce provedl posouzení shody, vypracoval dokumentaci a připojil CE (čl. 19). Distributor ověřuje označení CE a průvodní dokumentaci (čl. 20). Oba musí reagovat, pokud zjistí nesoulad nebo zranitelnost.

Pozor na změnu role: dovozce nebo distributor, který produkt uvede na trh pod vlastním jménem nebo ochrannou známkou nebo jej podstatně změní, má povinnosti výrobce (čl. 21). Příklad z praxe: e-shop, který nechá vyrobit chytré kamery v Asii a prodává je pod svou privátní značkou, je pro účely CRA výrobcem – včetně doby podpory a hlášení incidentů.

Online tržiště podle odůvodnění (bod 78): pokud platforma jen zprostředkovává prodej, není hospodářským subjektem podle CRA. Pokud ale produkt sama distribuuje, je distributorem; pokud prodává produkty pod vlastní značkou, je výrobcem. Může být i poskytovatelem fulfilmentových služeb. Vždy se posuzuje konkrétní případ.

Vždy platí vyšší z obou částek. Mikropodnikům a malým podnikům nelze uložit pokutu za zmeškání 24hodinové lhůty pro včasné varování a správcům open-source softwaru nelze uložit pokutu vůbec (čl. 64 odst. 10 ve znění opravy z 2. 7. 2025). Členské státy jim nemají ukládat ani jiné peněžité sankce (bod 120). Při výměře se zohledňuje velikost podniku a pokuty uložené za stejné porušení v jiných státech – souhrnná sankce musí být přiměřená (bod 120).

Kdo bude v ČR dozorovat: Podle návrhu zákona o požadavcích na kybernetickou bezpečnost výrobků s digitálními prvky, který připravuje Ministerstvo průmyslu a obchodu, bude NÚKIB oznamujícím orgánem. Dozor nad trhem zůstane orgánům, které výrobky kontrolují již dnes – především České obchodní inspekci, ale např. také Českému báňskému úřadu, Státní energetické inspekci nebo Drážnímu úřadu. Orgán dozoru může nařídit stažení nevyhovujícího výrobku z trhu.

NIS2 (v ČR nový zákon o kybernetické bezpečnosti) se týká organizace a jejích služeb, CRA produktu. Jedna firma tak může podléhat oběma režimům: jako poskytovatel cloudové služby NIS2 a jako výrobce aplikace nebo zařízení CRA. Hlášení podle CRA má pomoci CSIRT a ENISA plněním úkolů podle NIS2 a zvýšit bezpečnost základních a důležitých subjektů (bod 66).

AI Act: vysoce rizikové AI systémy, které jsou zároveň produktem s digitálními prvky a splňují základní požadavky CRA, se považují za vyhovující požadavkům na kybernetickou bezpečnost podle čl. 15 AI Actu (čl. 12 CRA). Tuto vazbu posiluje i digitální omnibus, viz náš článek AI Act po digitálním omnibusu.

1. Inventura produktů – sepište hardware, software, firmware i backendy, které dodáváte na trh EU, včetně starších produktů (hlášení se týká i jich).
2. Určení role – jste výrobce, dovozce, distributor, nebo správce open source? Prodáváte něco pod vlastní značkou?
3. Klasifikace – výchozí, důležitý (třída I/II), nebo kritický produkt? Rozhoduje hlavní funkce.
4. Proces hlášení – kdo rozhoduje, zda jde o aktivně zneužívanou zranitelnost nebo závažný incident, kdo podává hlášení do 24 hodin (i o víkendu) a jak informujete uživatele.
5. Dodavatelský řetězec – SBOM, prověrka komponent a smlouvy s dodavateli (spolupráce při zranitelnostech, doba podpory komponent, přístup k informacím).
6. Doba podpory – stanovte ji a zdůvodněte, zapracujte datum konce podpory do obchodních podmínek, e-shopu a obalů.
7. Kontaktní místo a politika zveřejňování zranitelností – nejen chatbot.
8. Vývojový proces – security by design, posouzení rizik a určení, které aktualizace jsou podstatnou změnou.