Cyber Resilience Act: první termín není prosinec 2027. Je 11. září 2026

První vymahatelná povinnost Cyber Resilience Actu nezačíná v prosinci 2027, ale za několik týdnů. Týká se i produktů, které máte na trhu už řadu let. A pro mnoho výrobců nebude problémem samotné hlášení, ale proces, který mu musí předcházet.

Když se v českých firmách mluví o Cyber Resilience Actu, nejčastěji se zmiňuje jedno datum: 11. prosinec 2027. Tehdy začne nařízení platit v plném rozsahu – označení CE, technická dokumentace a posouzení shody.

Článek 14 však začíná platit už 11. září 2026. A na rozdíl od zbytku CRA se netýká jen nových produktů. Podle článku 69 odst. 3 se ohlašovací povinnosti vztahují i na produkty s digitálními prvky, které byly uvedeny na trh před 11. prosincem 2027.

Pokud jste si přípravu na CRA naplánovali až na příští rok, článek 14 tento plán mění. Chcete-li si nejdříve ujasnit, zda váš produkt vůbec spadá pod CRA, začněte naším kompletním přehledem nařízení.

Co podléhá ohlašovací povinnosti

Článek 14 zavádí dvě samostatné ohlašovací povinnosti, přičemž obě se vztahují na výrobce. Ne na zákazníka ani na provozovatele. Dovozce a distributor, kteří se o problému dozvědí, informují výrobce. Samotné hlášení však nepodávají a 24hodinová lhůta se na ně nevztahuje.

• Aktivně zneužívaná zranitelnost – zranitelnost ve vašem produktu, u které existuje spolehlivý důkaz, že ji útočník zneužil v systému bez souhlasu jeho vlastníka.
• Závažný incident s dopadem na bezpečnost produktu – například kompromitace vývojového, výrobního nebo distribučního prostředí, kdy se útočníkovi podaří dostat škodlivý kód do distribučního kanálu nebo do podpisového řetězce. Nejde o incident u zákazníka, ale o incident u výrobce, který zvyšuje riziko pro uživatele produktu.

V určitých případech se obdobné povinnosti vztahují i na správce open source softwaru podle článku 24, a to v rozsahu jejich zapojení do vývoje dotčených produktů.

Co naopak povinnost nespouští

Samotný nález bezpečnostního výzkumníka, proof of concept ani vysoké CVSS skóre automaticky neznamenají povinnost podle článku 14. Nařízení rozlišuje zranitelnost, která existuje, od zranitelnosti, která je aktivně zneužívána. Rozhodujícím kritériem je spolehlivý důkaz o reálném zneužití, nikoli závažnost samotné chyby. Běžná zranitelnost nahlášená prostřednictvím vašeho CVD kanálu a odstraněná v rámci standardního procesu vydávání oprav se nehlásí.

Na první pohled to může působit jako úleva. V praxi jde o nejnáročnější část celé povinnosti. Právě proto, že rozhodující je otázka zneužití, musíte být schopni na ni odpovědět – a to není právní otázka, ale otázka detekčních a analytických schopností.

Povinnost informovat uživatele

Ohlášení orgánům není jedinou povinností a právě tato část se v textech o CRA často opomíjí.

Poté, co se výrobce dozví o aktivně zneužité zranitelnosti nebo o závažném incidentu, musí zároveň bez zbytečného odkladu informovat dotčené uživatele a podle potřeby i uživatele obecně o problému a o opatřeních, která mohou přijmout ke zmírnění rizika. V praxi to znamená, že vedle hlášení musíte mít připravený i komunikační kanál směrem k zákazníkům a text, který jeho prostřednictvím odešlete.

Jak funguje ohlašování prostřednictvím platformy ENISA

Hlášení se podává jednou prostřednictvím jednotné ohlašovací platformy (Single Reporting Platform), kterou podle článku 16 zřizuje agentura ENISA. Jedno podání směřuje současně ke koordinujícímu CSIRT a k agentuře ENISA. Nemusíte tedy obcházet národní orgány v každém členském státě, kde produkt prodáváte.

Při podání označíte členské státy, ve kterých je dotčený produkt dostupný, a koordinující CSIRT informaci následně předá příslušným CSIRT v těchto státech.

Příslušný CSIRT je ten v členském státě vaší hlavní provozovny, tedy tam, kde se primárně přijímají rozhodnutí související s kybernetickou bezpečností vašich produktů. Pokud to nelze určit, nastupuje kritérium provozovny s nejvyšším počtem zaměstnanců v EU. Pro výrobce bez hlavního místa podnikání v Unii stanovuje nařízení zvláštní pravidla.

Za výjimečných okolností může být na žádost výrobce a z odůvodněných kyberneticko-bezpečnostních důvodů odloženo další šíření oznámení příslušným CSIRT. Je to věc, kterou má smysl znát předem, nikoli ji řešit pod tlakem.

Praktická poznámka, kterou většina článků vynechává

Platforma v době psaní tohoto textu ještě nebyla v provozu. ENISA potvrdila, že bude funkční k 11. září 2026. Před spuštěním probíhá testování a v průběhu léta 2026 agentura zveřejnila první návody. Veřejná adresa platformy má být oznámena ještě před jejím spuštěním.

Pro vás z toho plyne jedna věc: nástroj není to, na co je třeba čekat. Proces, který ho bude naplňovat, si můžete nastavit už nyní – a právě ten rozhodne, zda 24 hodin stihnete. ENISA zároveň uvádí, že přístup k platformě bude založen na účtu EU Login, který si lze vytvořit předem.

Proč 24 hodin není jen administrativní lhůta

Lhůta 24 hodin se může na první pohled zdát dostatečná. V praxi však musí výrobce během této doby zvládnout několik kroků, které vyžadují technická i organizační rozhodnutí.

1. Zjistit, že se něco stalo. Informace může přijít z monitoringu, prostřednictvím threat intelligence, od zákazníka nebo od bezpečnostního výzkumníka. Bez politiky koordinovaného zveřejňování zranitelností (CVD) a funkčního kontaktního místa se k ní firma často dostane pozdě.
2. Ověřit, zda se problém týká konkrétního produktu. Které verze jsou dotčené? Je zranitelná knihovna skutečně součástí produktu? Bez aktuálního SBOM může být odpověď na tyto otázky časově náročná.
3. Posoudit, zda jde o aktivní zneužívání zranitelnosti. Rozhodující otázkou není závažnost chyby, ale existence spolehlivého důkazu o jejím zneužití. Takové posouzení vyžaduje technickou expertizu.
4. Přijmout rozhodnutí o nahlášení. Mnoho firem nemá jasně určeno, kdo za toto rozhodnutí odpovídá. Má ho přijmout vývojový tým, produktový management, právní oddělení nebo vedení společnosti?
5. Připravit hlášení a informovat uživatele. Kromě samotného podání je třeba zajistit i komunikaci směrem k zákazníkům a připravit doporučení ke zmírnění rizika.

Kritickým bodem je krok 3. Abyste dokázali posoudit, zda jde o aktivní zneužívání zranitelnosti, musíte mít přehled o tom, co se ve vašem produktu děje. Rozlišit existující zranitelnost od jejího skutečného zneužití je technický úkol, nikoli otázka compliance.

Co při testech produktů vidíme

Podle našich zkušeností z penetračního testování IoT zařízení obsahuje téměř každé testované zařízení alespoň jednu zranitelnost klasifikovanou jako high nebo critical. Nejčastěji jde o pevně zakódované přihlašovací údaje ve firmwaru, nešifrovanou komunikaci s cloudem, otevřená ladicí rozhraní nebo aktualizace bez ověřování podpisu. Podrobně jsme to popsali v článku o bezpečnosti chytré zásuvky.

Do 11. září jde o technické nálezy. Od 11. září platí, že u nálezu, u kterého získáte spolehlivý důkaz o jeho aktivním zneužití, začíná běžet 24hodinová lhůta.

Pozor na výjimky při sankcích

Porušení článku 14 spadá do nejvyššího sankčního pásma CRA – až 15 milionů eur nebo 2,5 % celosvětového ročního obratu. Nařízení však obsahuje dvě úzké výjimky:

• Mikropodnikům a malým podnikům nelze uložit pokutu za nedodržení lhůty pro včasné varování. Netýká se to 72hodinového oznámení, závěrečné zprávy ani samotné ohlašovací povinnosti.
• Správcům open source softwaru se podle nařízení nemá uložit pokuta za porušení nařízení. Jejich povinnosti podle článku 24 tím nezanikají.

Co stihnout do září

• Seznam produktů v rozsahu. Co máte dodáváno na trh EU, které verze jsou stále v oběhu a které už nevyvíjíte, ale nadále prodáváte.
• Určené odpovědnosti a eskalační cesta. Kdo rozhoduje o hlášení, kdo ho podává, kdo zastupuje odpovědnou osobu a jak se postupuje mimo pracovní dobu.
• CVD politika a jednotné kontaktní místo. Kanál, jehož prostřednictvím se k vám informace vůbec dostane. Nesmí se spoléhat pouze na automatizované nástroje.
• SBOM alespoň pro závislosti nejvyšší úrovně. Ne kvůli dokumentaci, ale proto, abyste dokázali rychle posoudit, zda se vás konkrétní zranitelnost týká.
• Triáž zranitelností a schopnost ověřit zneužití. Kdo a jak posoudí, zda jde o aktivní zneužití, a na základě jakých důkazů.
• Příprava podání a komunikace. Přístup k platformě vytvořený předem, připravená šablona hlášení a způsob komunikace s uživateli.
• Nacvičte si to. Jedno tabletop cvičení se scénářem „naši zranitelnost někdo zneužívá“ odhalí o připravenosti více než audit dokumentace.

Časté otázky

Musíme hlásit nález od bezpečnostního výzkumníka?

Ne, pokud jde pouze o nález. Povinnost podle článku 14 spouští spolehlivý důkaz o tom, že je zranitelnost aktivně zneužívána. Samotný nález, proof of concept ani vysoké CVSS skóre hlášení automaticky nespouštějí.

Vztahuje se povinnost i na náš starší produkt?

Ano. Ohlašovací povinnosti se vztahují i na produkty uvedené na trh před 11. prosincem 2027, pokud jsou stále dodávány na trh EU.

Hlásíme my, nebo náš distributor?

Vy. Povinnost podle článku 14 nese výrobce. Dovozce a distributor, kteří se o zranitelnosti dozvědí, informují výrobce.

Co když platforma ENISA nebude v den incidentu dostupná?

Lhůty stanovuje nařízení a začínají běžet od okamžiku, kdy se o události dozvíte. Proto se vyplatí vytvořit si přístup předem, mít připravený obsah hlášení a sledovat oficiální informace agentury ENISA.

Jsme malý podnik. Musíme hlásit také?

Ano. Mikropodnikům a malým podnikům se nemá ukládat pokuta za nedodržení lhůty pro včasné varování. Samotná ohlašovací povinnost se však na ně vztahuje stejně jako na ostatní výrobce.

Závěr

Rozdíl mezi oběma termíny CRA je jednoduchý: prosinec 2027 je o schopnosti prokázat soulad, září 2026 o schopnosti reagovat. Kdo stihne to druhé, má velkou část prvního hotovou. Inventář produktů, SBOM i proces zvládání zranitelností jsou totiž společné pro obě povinnosti.

Kompletní přehled povinností, kategorií produktů a termínů najdete v našem článku o Cyber Resilience Actu.

Pokud si chcete nezávisle ověřit bezpečnost svého produktu a připravenost na požadavky CRA, ozvěte se nám. Testujeme firmware a hardwarová rozhraní, mobilní, webová a API rozhraní, cloudový backend, mechanismy autentizace a aktualizace i zranitelnosti v komponentách třetích stran.

Právní poznámka: Tento článek slouží pouze k informačním účelům a nepředstavuje právní poradenství.