OTÁZKY K AKTU CRA

Ne. Vstup v platnost a použitelnost jsou dvě různé věci. Nařízení vstoupilo v platnost 10. prosince 2024 (čl. 71 odst. 1), ale povinnosti výrobce se rozbíhají později a po částech (čl. 71 odst. 2).

První datum, které dopadá přímo na výrobce, je 11. září 2026 — od něj platí čl. 14 s ohlašovacími povinnostmi. Zbytek nařízení včetně základních požadavků, posouzení shody a označení CE se použije od 11. prosince 2027. Co se mezitím děje na straně Komise a členských států a proč je mezitermín 11. června 2026 pravidlem pro úřady, a ne pro vás, rozebírá sekce průvodce o platnosti a použitelnosti.

Praktický důsledek: dnes není povinnost mít označení CE ani technickou dokumentaci podle přílohy VII, ale je krajní čas mít funkční proces hlášení.

Stane se použitelným čl. 14, tedy dvě ohlašovací povinnosti výrobce: aktivně zneužívané zranitelnosti v produktu a závažné incidenty s dopadem na bezpečnost produktu. Hlásí se současně týmu CSIRT určenému jako koordinátor a agentuře ENISA, ve lhůtách 24 hodin a 72 hodin, se závěrečnou zprávou do 14 dnů u zranitelnosti, respektive do jednoho měsíce u incidentu.

Nic jiného se toho dne nemění. Základní požadavky přílohy I, posouzení shody, EU prohlášení o shodě ani označení CE se 11. září 2026 nezačínají uplatňovat — ty přicházejí 11. prosince 2027.

Co přesně se do které zprávy píše, od čeho se která lhůta počítá a komu se zpráva podává, je rozepsané v sekci průvodce o hlášení.

Kvůli základním požadavkům ne. Produkty uvedené na trh před 11. prosincem 2027 se jimi řídí jen tehdy, pokud po tomto datu projdou podstatnou změnou (čl. 69 odst. 2 ve spojení s čl. 3 bodem 30).

Ohlašovací povinnost je z tohoto pravidla výslovně vyňatá: čl. 14 se vztahuje i na produkty uvedené na trh dřív (čl. 69 odst. 3). Od 11. září 2026 tedy hlásíte aktivně zneužívané zranitelnosti napříč celým portfoliem, které máte na trhu Unie, ne jen v novinkách. Přechodná ustanovení včetně toho, co se za podstatnou změnu považuje, rozebírá průvodce.

Z toho plyne úkol, který se často přehlíží: mít aktuální seznam všeho, co je na trhu, u každé položky znát verzi, komponenty a vlastníka. Bez toho nelze 24hodinovou lhůtu splnit, protože se v ní nedá zjistit, kterých produktů se zranitelnost týká.

Ano, dva a oba jsou už vyhlášené:

• Prováděcí nařízení Komise (EU) 2025/2392 ze dne 28. 11. 2025 (vyhlášeno 1. 12. 2025) — technický popis kategorií důležitých a kritických produktů z příloh III a IV. Pro zařazení konkrétního produktu je to dnes hlavní dokument.
• Nařízení Komise v přenesené pravomoci (EU) 2026/881 ze dne 11. 12. 2025 (vyhlášeno 20. 4. 2026) — podmínky, za nichž lze z kybernetických důvodů odložit rozesílání oznámení mezi týmy CSIRT podle čl. 16 odst. 2.

K tomu vydala Komise 27. července 2026 první pokyny k uplatňování CRA (sdělení C(2026) 5252) — působnost, řešení pro zpracování dat na dálku, open source, podstatná změna, doba podpory, hlášení. Pokyny nejsou závazné, ale jsou dnes nejlepší vodítko k tomu, jak Komise nařízení čte.

Kam který z nich v čase zapadá, ukazuje časová osa v průvodci.

Čekání není strategie. Presumpce shody vzniká teprve tím, že se odkaz na harmonizovanou normu zveřejní v Úředním věstníku (čl. 27 odst. 1), a k 8. 8. 2026 není citovaná žádná — normy se teprve připravují podle žádosti o normalizaci M/606. Stav normalizace a jeho dopad na dokumentaci popisuje sekce průvodce o kategoriích a shodě.

Ve zkratce z toho plynou dvě věci. Do technické dokumentace se dnes místo normy zapisuje popis vlastního řešení a důvod, proč splňuje přílohu I (příloha VII bod 5). A u důležitých produktů třídy I nelze normy „plně použít“, takže cesta vede přes oznámený subjekt (čl. 32 odst. 2).

Co se ale citací norem nezmění vůbec: posouzení kybernetických bezpečnostních rizik podle čl. 13 odst. 2 a 3, procesy řešení zranitelností z přílohy I části II a doba podpory. To bude potřeba v každém scénáři, takže tady se čekáním nic neušetří.

Ano, zakázkovost povinnosti neruší. Dodáním na trh se rozumí dodání k distribuci nebo použití na trhu Unie v rámci obchodní činnosti, ať už za úplatu, nebo bezplatně (čl. 3 bod 22). Jeden zákazník je také trh. Časté nedorozumění: „to je přece jeho systém, ne náš produkt“ — pokud jste ho vyvinuli a dodali pod svým jménem, jste výrobce podle čl. 3 bodu 13.

Úlevy jsou přesně dvě a ani jedna není výjimkou z působnosti: u bezpečné výchozí konfigurace (příloha I část I bod 2 písm. b) a u bezplatnosti bezpečnostních aktualizací (příloha I část II bod 8) si můžete s podnikatelským uživatelem dohodnout něco jiného. Obě jsou rozebrané v sekci průvodce o rolích.

Vše ostatní platí stejně jako u produktu z katalogu: posouzení rizik, SBOM, politika koordinovaného zveřejňování zranitelností, doba podpory, hlášení.

Čisté cloudové modely — SaaS, PaaS, IaaS — patří pod směrnici NIS2, ne pod CRA (bod 12 odůvodnění). V Česku to znamená zákon č. 264/2025 Sb., pokud splňujete jeho kritéria.

Hranice ale není tam, kde ji lidé obvykle hledají. Vedle samotného produktu spadá do CRA i řešení pro zpracování dat na dálku — serverová část, bez které by produkt některou ze svých funkcí neplnil a kterou postavil sám výrobce (čl. 3 bod 2, vymezení v průvodci).

Praktické rozlišení: pokud zákazník kupuje přístup ke službě, jde o NIS2. Pokud kupuje produkt (aplikaci, zařízení, krabici) a váš backend je to, bez čeho by produkt nefungoval, jde o CRA včetně toho backendu. Jeden subjekt může mít obojí — nabídku služby i produkt — a řeší pak oba režimy zvlášť.

Vy. Výrobcem je nejen ten, kdo produkt vyvíjí nebo vyrábí, ale i ten, kdo si ho nechal vyrobit a nabízí ho pod svým jménem nebo ochrannou známkou (čl. 3 bod 13). White label je tedy výrobce se všemi povinnostmi včetně posouzení shody, technické dokumentace a hlášení podle čl. 14; totéž platí pro dovozce a distributory, kteří produkt uvedou na trh pod svým jménem nebo ho podstatně změní (čl. 21, rozpad rolí v průvodci).

Tohle je v praxi nejnepříjemnější zjištění, protože povinnosti dopadají na někoho, kdo do produktu technicky nevidí. Nejde je přenést smlouvou — smlouva vám může zajistit součinnost dodavatele, ale odpovědnost vůči dozoru zůstává na výrobci.

Klíčové věci, které od dodavatele reálně potřebujete: SBOM, dobu podpory jeho komponent, kanál pro bezpečnostní aktualizace a závazek, že vás bude o zranitelnostech informovat dřív než zákazníky.

Záleží na tom, co s produktem uděláte, a hranicí je podstatná změna podle čl. 3 bodu 30 — změna, která ovlivní soulad se základními požadavky přílohy I, nebo mění zamýšlený účel produktu (souvislosti v průvodci).

• Dodáváte cizí produkt bez zásahu do jeho vlastností a pod jeho značkou — jste distributor a máte povinnosti podle čl. 20: ověřit označení CE, EU prohlášení o shodě a informace pro uživatele, nedodat produkt, o němž víte nebo máte důvod se domnívat, že nesplňuje požadavky.
• Přidáváte vlastní firmware, měníte konfiguraci tak, že to mění bezpečnostní vlastnosti, nebo řešení nabízíte pod svým jménem — jste výrobce.

Nemá cenu si to nechat rozhodnout až kontrolou. Užitečné je projít portfolio zakázek a u každé napsat jednu větu o tom, jakou roli tam máte a proč — s odkazem na to, co konkrétně jste změnili. Ke stejné odpovědi pak dojdete i za dva roky, a je to zároveň podklad, který dozoru předložíte. Sporné případy popisují pokyny Komise ze 27. 7. 2026, které pracují se 67 příklady mířenými na menší firmy.

Rozhoduje zpeněžení, ne způsob vývoje. Svobodný a otevřený software poskytovaný mimo obchodní činnost do působnosti nařízení nespadá a samotné přispívání zdrojovým kódem do cizího projektu povinnosti výrobce nezakládá (bod 18 odůvodnění).

Kdo naopak vývoj konkrétního svobodného softwaru pro obchodní použití dlouhodobě financuje a drží při životě, může spadnout do mírnější role správce softwaru s otevřeným zdrojovým kódem (čl. 3 bod 14 a čl. 24) — bez označení CE a bez správních pokut (čl. 64 odst. 10). Co všechno tahle role obnáší, shrnuje sekce průvodce o rolích.

Kde se to naopak láme: pokud open source komponentu zabudujete do svého komerčního produktu, jste za ni v rámci produktu odpovědní vy — včetně náležité péče při jejím začlenění a povinnosti oznámit nalezenou zranitelnost tomu, kdo komponentu udržuje (čl. 13 odst. 5 a 6, podrobně v průvodci). „Bereme a nevracíme“ tímhle přestává být udržitelný model.

Nařízení dopadá na produkty dodávané na trh (čl. 2 odst. 1) a dodání na trh je definované jako dodání k distribuci nebo použití v rámci obchodní činnosti (čl. 3 bod 22). Interní nástroj, který nikam nedodáváte, do působnosti nespadá.

Dvě věci ale stojí za pozor. Za prvé se to snadno změní — dodání jedinému zákazníkovi, sesterské firmě jako dodávka nebo nabídnutí nástroje vně organizace situaci překlopí, a na tom, že je bezplatné, nezáleží (čl. 3 bod 22). Za druhé: pokud jste zároveň regulovaným subjektem podle zákona č. 264/2025 Sb., vlastní vývoj vám z povinností nezmizí, jen se řeší jiným předpisem — tam jde o bezpečnost vaší služby, ne o vlastnosti produktu na trhu.

Hraniční případy uvnitř skupiny podniků řeší pokyny Komise ze 27. 7. 2026; než na ně sáhnete, vyplatí se mít jasně napsané, co je interní nástroj a co už je dodávka.

Ne. Hlásí se jen aktivně zneužívaná zranitelnost, tedy ta, u které máte spolehlivé důkazy o zneužití v reálném systému bez svolení jeho vlastníka (čl. 3 bod 42). Nález ve skenu, zranitelná verze knihovny v SBOM ani veřejně publikované CVE bez důkazu o zneužití pod tuhle definici nespadají.

To ale neznamená, že se s nimi nic nedělá — příloha I část II je řadí do běžného procesu řízení zranitelností: neprodleně opravit a po vydání opravy zveřejnit informace o zranitelnosti a o tom, jak ji uživatel odstraní. Jen se o nich nepodává zpráva na platformu ENISA. Rozdíl mezi oběma režimy rozebírá sekce průvodce o SBOM a řízení zranitelností.

Kde je v praxi problém: rozhodnutí „tohle je aktivně zneužívané“ musí někdo umět udělat rychle a doložitelně, protože od něj běží 24 hodin. Doporučujeme mít předem napsané, kdo to rozhoduje, z jakých vstupů (telemetrie, hlášení od zákazníka, upozornění CSIRT, veřejné zdroje) a jak se rozhodnutí zaznamená.

Ve zkratce jde o incident, který ohrožuje schopnost produktu chránit dostupnost, autenticitu, integritu nebo důvěrnost citlivých či důležitých dat nebo funkcí, případně vedl nebo může vést ke spuštění škodlivého kódu v produktu nebo u jeho uživatele (čl. 14 odst. 5; plné znění definice a typické příklady v průvodci).

Rozdíl proti ZKB a NIS2 je v tom, čeho se incident týká. ZKB řeší dopad na vaši regulovanou službu, CRA dopad na bezpečnost produktu, který jste dodali na trh. Výpadek vaší kanceláře incidentem podle čl. 14 není, i když je pro vás nepříjemný.

Jeden incident může spadnout pod oba režimy zároveň a lhůty se počítají samostatně. Pokud jste zároveň regulovaným subjektem podle ZKB, hlásíte podle ZKB do 24 h / 72 h / 30 dnů (adresát podle režimu přes Portál NÚKIB) a podle CRA do 24 h / 72 h / 1 měsíc přes jednotnou platformu — a je dobré, aby to nebyly dva nezávislé procesy, které o sobě nevědí.

Hlásí se současně týmu CSIRT určenému jako koordinátor a agentuře ENISA, prostřednictvím jednotné platformy pro podávání zpráv podle čl. 16. Který CSIRT je váš, určuje hlavní provozovna v Unii; kdo ji v Unii nemá, postupuje kaskádou podle čl. 14 odst. 7 (rozepsáno v průvodci). V České republice má oznámení přijímat NÚKIB, zatím ale jen podle nepřijatého návrhu adaptačního zákona.

K platformě: podle informací ENISA má být pro povinné hlášení používána od 11. září 2026 a agentura k ní zveřejnila návody pro registraci zástupců výrobce (aktualizace 31. 7. 2026).

Přístupy si proto vyřiďte dřív, než je budete potřebovat — na běh lhůt registrace vliv nemá. A mějte i záložní postup pro případ, že platforma zrovna v tu chvíli nepojede.

Lhůta běží od okamžiku, kdy se výrobce o zranitelnosti nebo incidentu dozví, a plní se „bez zbytečného odkladu a v každém případě do 24 hodin“. Nonstop směna k tomu potřeba není — potřeba je předem rozhodnuté, kdo lhůtu drží a jak se k němu informace dostane.

Minimum, které v praxi funguje:

• Jeden vstupní kanál pro hlášení zranitelností zvenčí (příloha I část II bod 6 ho vyžaduje) a jasné pravidlo, kdo ho sleduje i mimo pracovní dobu.
• Rozhodovací kritéria pro „aktivně zneužívaná“ a „závažný incident“ napsaná dřív, ne až ve chvíli rozhodování.
• Pojmenovaná role s eskalací a zástupem, včetně kontaktu na někoho, kdo umí schválit externí komunikaci.
• Předpřipravené texty včasného varování a oznámení se statickými údaji (identifikace výrobce, produkty, kontakty), aby se ve 24 hodinách dopisoval jen popis situace.
• Zkoušku naslepo — projít celý postup na vymyšleném případu a změřit, za jak dlouho by odešlo první varování.

Kritický není nástroj, ale to, že postup někdo jednou nasucho projde a najde v něm místo, kde se zasekne. Tuhle zkoušku děláme jako cvičení nad konkrétním produktem.

Ohlašovací povinnost platí stejně — mikropodniky a malé podniky z ní vyňaté nejsou. Rozdíl je v sankci, ale je užší, než se často uvádí: podle čl. 64 odst. 10 písm. a) se jim neukládá pokuta jen za nedodržení lhůty pro včasné varování do 24 hodin (čl. 14 odst. 2 písm. a a odst. 4 písm. a). Na lhůtu 72 hodin ani na závěrečnou zprávu se výjimka nevztahuje — tam se pokuta uložit může.

Neznamená to, že se lhůty dají ignorovat. Povinnost hlásit zůstává a její nesplnění zůstává porušením nařízení; odpadá pouze pokuta za pozdní odeslání. A hlavně: smysl 24hodinové lhůty je, aby se CSIRT a ENISA o aktivně zneužívané zranitelnosti dozvěděly dřív, než se rozšíří na další zákazníky. To je zájem výrobce, ne jen povinnost.

Pro menší firmy nabízí nařízení i další ústupky — zjednodušený formát technické dokumentace podle čl. 33 odst. 5 (formulář má stanovit Komise prováděcím aktem) a podpůrná opatření členských států podle čl. 33 včetně regulatorních sandboxů. Ostatní výjimky ze sankcí shrnuje sekce průvodce o sankcích.

Nemusíte. Softwarový kusovník musíte mít v běžně používaném strojově čitelném formátu a musí pokrývat alespoň nejdůležitější závislosti produktu (příloha I část II bod 1), ale zveřejnění povinné není.

Ven jde jen dvěma směry: dozorovému orgánu na odůvodněnou žádost při ověřování souladu, a uživateli tehdy, když se tak výrobce sám rozhodne. Kam přesně SBOM v dokumentaci patří a co k němu ještě může doplnit Komise, popisuje sekce průvodce o SBOM.

Praktická poznámka: „strojově čitelný“ je v tomhle kontextu podstatnější než „úplný“. SBOM, který nikdo nedokáže automaticky srovnat s databází zranitelností, splní literu a k ničemu neposlouží. Užitečný SBOM se generuje v buildu, verzuje se s produktem a je vstupem do řízení zranitelností — ne dokument, který se udělá jednou před auditem.

Dolní hranice je pět let. Kratší je přípustná jen u produktu, u kterého se počítá s používáním kratším než pět let; pak se doba podpory rovná té očekávané době použití (čl. 13 odst. 8).

Vedle toho běží samostatná lhůta: už vydané bezpečnostní aktualizace musíte držet dostupné deset let, nebo po zbytek doby podpory, je-li delší (čl. 13 odst. 9). To se s dobou podpory plete, ale jde o jinou věc — ne o vydávání nových oprav, ale o dostupnost už vydaných.

Z čeho se délka podpory odvozuje, proč nejde o volnou úvahu a co ji shora omezuje u produktů se zabudovanými komponentami, rozebírá sekce průvodce o době podpory.

Pozor na to, že jde o rozhodnutí, které padne před uvedením na trh: měsíc a rok konce podpory musí být uvedeny už v době nákupu (čl. 13 odst. 19), a pak už se mění těžko.

V zásadě ne. Příloha I část II bod 8 vyžaduje šířit bezpečnostní aktualizace neprodleně a bezplatně, spolu s poradní zprávou pro uživatele obsahující relevantní informace včetně potřebných opatření. Zpoplatnit lze funkční aktualizace, ne bezpečnostní.

Výjimka existuje jedna a je úzká: u produktů zhotovených na zakázku je možná odchylná dohoda s podnikatelským uživatelem. Neplatí to na produkty z katalogu ani na spotřebitele.

Souvisí s tím další požadavek, který se často opomíná: tam, kde je to technicky možné, mají být bezpečnostní aktualizace oddělené od funkčních (příloha I část II bod 2; ostatní procesní povinnosti části II jsou v průvodci). Důvod je provozní — zákazník, který musí kvůli bezpečnostní opravě přijmout i změnu chování produktu, ji odkládá. Pokud vaše release strategie tuhle možnost nemá, je to změna v architektuře vydávání, ne v dokumentaci, a nedělá se za měsíc.

Je to první požadavek přílohy I části I bodu 2, písmene a): produkt se dodává na trh bez známých zneužitelných zranitelností. Neznamená to „bez zranitelností“ — to by nešlo splnit. Znamená to, že o zranitelnosti, která je známá a zneužitelná, víte a odstranili jste ji, než produkt šel na trh.

V praxi to tlačí na dvě věci ve vývoji. První je přehled o tom, co v produktu je — bez SBOM a jeho automatického vyhodnocování proti databázím zranitelností nejde tvrdit, že žádná známá zneužitelná zranitelnost v produktu není. Druhá je brána před vydáním: rozhodnutí, které nálezy vydání blokují a kdo smí udělat výjimku, se dělá dopředu, ne při release.

Písmeno a) je přitom jen jedním ze třinácti požadavků bodu 2 a nad nimi stojí obecný bod 1 — přiměřená úroveň bezpečnosti podle rizik. Celý výčet i to, na co se u něj dozor ptá, je v sekci průvodce o bezpečnosti v návrhu. Tu bránu před vydáním u zákazníků obvykle stavíme dohromady s tím, jak se v produktu vyhodnocují nálezy ze skenů.

Ano. Příloha I část II bod 5 vyžaduje zavést a prosazovat politiku koordinovaného zveřejňování zranitelností a bod 6 kontaktní adresu pro hlášení zranitelností, včetně informace o tom, kde je politika zveřejněná.

Co má být uvnitř, nařízení nepředepisuje do detailu, ale z ostatních bodů části II se to dá odvodit: jak zranitelnost nahlásit, co může nahlašující očekávat a v jakém čase, jak se řeší souběh s opravou, a kdy a co se zveřejní (přehled bodů části II je v průvodci).

Na politiku se dá koukat jako na provozní dokument, ne právní. Pokud v ní stojí lhůta, kterou nedokážete držet, uškodí vám víc než její absence. Užitečné minimum: adresa, která je opravdu čtená, potvrzení příjmu, jedna odpovědná role a interní pravidlo, že hlášení zvenčí jde do stejného procesu jako nález z vlastního testování.

Nařízení pracuje se třemi úrovněmi:

• Běžný produkt — vše, co není v přílohách III a IV.
• Důležitý produkt — příloha III, třída I: mimo jiné operační systémy, prohlížeče, správci hesel, VPN, SIEM, správa identit a privilegovaných přístupů, routery a přepínače, systémy řízení sítě, mikroprocesory a mikrokontrolery s bezpečnostními funkcemi, prvky smart home s bezpečnostní funkcí, připojené hračky a nositelná zařízení pro monitorování zdraví.
• Důležitý produkt — příloha III, třída II: hypervizory a běhová prostředí kontejnerů, firewally, systémy detekce a prevence průniku a mikroprocesory a mikrokontrolery odolné proti neoprávněné manipulaci.
• Kritický produkt — příloha IV: hardwarová zařízení s bezpečnostními schránkami, brány inteligentních měřicích systémů a další zařízení pro bezpečné kryptografické zpracování, čipové karty a podobná zařízení včetně zabezpečených prvků. Druhou položku přílohy IV hledejte v úředním českém znění pod formulací „přístroje pro účely zajištění větší bezpečnosti, mj. pro bezpečné přijímání plateb v kryptoměně“ — jde o týž bod, jen přeložený z anglického „secure cryptoprocessing“ nešťastně; věcně jde o bezpečné kryptografické zpracování, ne o platby.

Rozhoduje klíčová funkce produktu jako celku (čl. 7 odst. 1) — zabudovaná komponenta z produktu ještě důležitý produkt nedělá; příklad je v sekci průvodce o kategoriích a shodě.

Kategorie jsou v přílohách popsané jen názvem. Technický popis doplnilo prováděcí nařízení (EU) 2025/2392 a pro zařazení konkrétního produktu je to dnes hlavní dokument. Doporučení: zařazení napsat, zdůvodnit a datovat. Je to první věc, kterou po vás bude dozor chtít, a druhá věc, kterou vám bude chtít rozporovat.

Podle kategorie (čl. 32; souvislost s kategorizací produktu je v průvodci):

• Běžný produkt — stačí interní kontrola, modul A. Posouzení si výrobce dělá sám na svou odpovědnost.
• Důležitý produkt třídy I — interní kontrola je možná, ale jen tehdy, pokud jste plně použili harmonizované normy, společné specifikace nebo evropskou certifikaci alespoň na úrovni záruky „významná“. Jinak je nutné EU přezkoušení typu (modul B následovaný modulem C) nebo komplexní zabezpečování kvality (modul H) — tedy oznámený subjekt.
• Důležitý produkt třídy II — třetí strana vždy, tedy modul B + C, modul H, nebo evropská certifikace.
• Kritický produkt — Komise může aktem v přenesené pravomoci vyžadovat evropský certifikát kybernetické bezpečnosti alespoň na úrovni „významná“ (čl. 8 odst. 1); dokud takový akt není, platí režim třídy II.

Praktický dopad pro rok 2026: protože k 8. 8. 2026 není citovaná žádná harmonizovaná norma, u třídy I se nelze o „plné použití“ normy opřít a cesta vede přes oznámený subjekt, jehož kapacita se teprve staví (kapitola IV je použitelná od 11. 6. 2026). Kdo bude potřebovat třetí stranu, má důvod řešit to dřív než v roce 2027.

Rozsah stanoví čl. 31 a příloha VII. Dá se to přečíst jako tři bloky:

• Co produkt je — popis, zamýšlený účel, verze ovlivňující shodu a informace pro uživatele podle přílohy II.
• Jak vznikal a jak se udržuje — návrh, vývoj a výroba, procesy řešení zranitelností, SBOM, politika koordinovaného zveřejňování, kontaktní adresa pro hlášení, bezpečná distribuce aktualizací.
• Čím je to doložené — posouzení rizik podle čl. 13, podklady k době podpory, použité normy nebo popis vlastních řešení, protokoly o zkouškách a EU prohlášení o shodě.

Položku po položce rozepisuje sekce průvodce o posuzování shody. Mikropodniky a malé podniky navíc mohou prvky dokumentace předložit ve zjednodušeném formátu, jehož formulář má stanovit Komise prováděcím aktem (čl. 33 odst. 5), a oznámené subjekty jej musí akceptovat.

Jedna věc se v dokumentaci nedá dohnat zpětně: posouzení rizik má podle čl. 13 odst. 2 a 3 vzniknout v průběhu plánování, návrhu, vývoje a údržby, ne po nich, a dokument napsaný týden před kontrolou to nedoloží (souvislosti v průvodci). V zakázkách proto začínáme u toho, jak se v týmu rozhoduje o rizicích, ne u šablony dokumentu.

Pokuty stanoví čl. 64 a jsou tři sazby podle toho, co se poruší. U každé se bere vyšší z obou hodnot, obrat je celosvětový roční za předchozí finanční rok:

• 15 000 000 EUR nebo 2,5 % obratu — základní požadavky přílohy I a povinnosti podle čl. 13 a 14, tedy vlastnosti produktu, posouzení rizik, doba podpory a hlášení (odst. 2).
• 10 000 000 EUR nebo 2 % obratu — povinnosti zplnomocněných zástupců, dovozců a distributorů (čl. 18 až 23), EU prohlášení o shodě (čl. 28), označení CE (čl. 30), technická dokumentace (čl. 31), postupy posuzování shody (čl. 32) a povinnosti oznámených subjektů (čl. 39, 41, 47, 49 a 53) — odst. 3.
• 5 000 000 EUR nebo 1 % obratu — nesprávné, neúplné nebo zavádějící informace poskytnuté oznámeným subjektům a orgánům dozoru nad trhem v odpovědi na jejich žádost (odst. 4).

Výjimky jsou dvě, obě v čl. 64 odst. 10: mikropodnikům a malým podnikům se neukládá pokuta za nedodržení lhůty pro včasné varování do 24 hodin (písm. a; na lhůtu 72 hodin ani na závěrečnou zprávu výjimka nedopadá) a správcům softwaru s otevřeným zdrojovým kódem se správní pokuty podle nařízení neukládají vůbec. Podle čeho se výše pokuty v konkrétním případě určuje, je v sekci průvodce o sankcích.

Určení dozorových orgánů nechává nařízení členským státům (čl. 52). V Česku to má vyřešit adaptační zákon, jehož návrh poslalo Ministerstvo průmyslu a obchodu 3. července 2026 do mezirezortního připomínkového řízení. Podle návrhu je NÚKIB oznamujícím orgánem a příjemcem oznámení podle čl. 14 a 15, dozor nad trhem se má rozdělit sektorově a hlavní díl agendy včetně softwaru a spotřební elektroniky má dostat Česká obchodní inspekce.

K 8. 8. 2026 je to návrh, ne platný zákon, a rozdělení dozoru se ještě může změnit. Na povinnostech výrobce to nic nemění — nařízení je přímo použitelné.

Pomůže jako základ, ale presumpci shody nezakládá. Ta vzniká výhradně použitím harmonizované normy, jejíž odkaz je zveřejněný v Úředním věstníku (čl. 27 odst. 1) — a k 8. 8. 2026 taková norma pro CRA neexistuje. Certifikát podle ISO/IEC 27001 ani IEC 62443 tedy sám shodu s přílohou I nedokládá.

Co se z existujících systémů reálně použije: procesy řízení zranitelností, evidence aktiv a komponent, řízení změn a testování se dají mapovat na přílohu I část II. Životní cyklus bezpečného vývoje podle IEC 62443-4-1 pokrývá velkou část toho, co příloha I část II po výrobci chce.

Co v nich naopak nenajdete a bude potřeba doplnit: posouzení rizik na úrovni produktu podle čl. 13 odst. 2 a 3 (ISO 27001 řeší rizika organizace, ne vlastnosti produktu na trhu), doba podpory a její doložení, SBOM ve strojově čitelném formátu, proces hlášení podle čl. 14 a technická dokumentace podle přílohy VII včetně EU prohlášení o shodě a označení CE. Rozdíl proti ZKB je podstatný: tam se posuzuje váš systém řízení, tady vlastnosti produktu a doložitelnost toho, jak vznikly.

Ne, nařízení tuhle situaci řeší. Podle čl. 12 se produkty s digitálními prvky, které spadají do působnosti CRA a jsou zároveň klasifikované jako vysokorizikové systémy AI podle čl. 6 nařízení (EU) 2024/1689, považují za splňující požadavky na kybernetickou bezpečnost podle čl. 15 AI Actu, pokud splňují základní požadavky přílohy I části I, procesy výrobce splňují část II a dosažená úroveň ochrany je doložená v EU prohlášení o shodě.

Neplatí to obráceně a nepokrývá to celý AI Act — jen kybernetickou bezpečnost podle jeho čl. 15. Požadavky AI Actu na data, transparentnost, lidský dohled nebo řízení rizik AI zůstávají samostatné.

Podobně je zařízená hranice vůči jiným režimům: z působnosti CRA jsou vyňaté produkty pokryté odvětvovými předpisy — zdravotnické prostředky, vozidla, letectví, námořní výstroj, náhradní díly vyrobené podle stejných specifikací a produkty výlučně pro národní bezpečnost, obranu nebo utajované informace (čl. 2). Vyňato z CRA ale neznamená bez kybernetických požadavků. Seznam s odkazy na konkrétní předpisy je v sekci průvodce o rolích.