Cyber Resilience Act (CRA) 2026–2027: co už víme, co ještě chybí a jak produkt reálně připravit — ještě předtím, než se objeví harmonizované normy

Co dnes víme jistě (a proč to není „téma na rok 2027“)

Cyber Resilience Act může na první pohled působit jako další dokument „z Bruselu“, který se dá odložit na později. Je to přirozená reakce, zvlášť když firma funguje v rytmu projektů: prototyp, zavedení, sériová výroba, servis. Regulace často přicházejí jako „finální požadavek“ — něco, co se doladí až na konci. CRA tuhle logiku mění, protože se netýká jen toho, co je na produktu vidět v den prodeje. Týká se toho, zda výrobce dokáže udržet bezpečnost produktu v čase a prokázat, že to udělal vědomě, nikoli náhodou.

Nejdůležitější fakt je jednoduchý, ale má strategické důsledky: CRA je produktová regulace, zasazená do fungování trhu EU (včetně označení CE). Evropská komise výslovně uvádí, že produkty mají nést označení CE jako signál shody s CRA a vymáhání spadá na orgány dozoru nad trhem. Nejde tedy o „IT standard“, který lze pojmout jako interní program zlepšování. Je to rámec, který ovlivňuje možnost produkt prodávat.

Data, která pomáhají ujasnit si souvislosti

Už v samotném znění nařízení (EU) 2024/2847 je vidět postupné uplatňování. CRA se použije od 11. prosince 2027, ale s jasně danými výjimkami. Článek 14 (hlášení) se použije od 11. září 2026 a kapitola o notifikaci subjektů posuzování shody (Chapter IV) od 11. června 2026. Jsou to tři data, která stojí za to brát jako „milníky“, protože odpovídají třem různým typům připravenosti: provozní, institucionální a produktové.

Komise to komunikuje ještě jednodušeji: CRA vstoupilo v platnost 10. prosince 2024, klíčové povinnosti od 11. prosince 2027 a hlášení od 11. září 2026. Když někdo ve firmě říká „máme čas do 2027“, nejčastěji tím myslí požadavky na návrh a posuzování shody. Jenže hlášení je dřív a týká se událostí, které se neřídí projektovým harmonogramem.

Hlášení: povinnost, která vynucuje proces (ne dokument)

Požadavek na hlášení je dobrým lakmusovým papírkem, protože ukazuje, jak CRA chápe „kybernetickou bezpečnost produktu“. Není to prohlášení o záměru ani „politika“. Je to proces, který musí fungovat ve stresu: když se objeví aktivně zneužívaná zranitelnost nebo závažný incident.

Komise to popisuje jednoznačně: výrobce má hlásit aktivně zneužívané zranitelnosti a závažné incidenty, které ovlivňují bezpečnost produktu. Požaduje se „early warning“ do 24 hodin od okamžiku, kdy se o tom výrobce dozví, úplné hlášení do 72 hodin a závěrečná zpráva: do 14 dnů od dostupnosti nápravného opatření u aktivně zneužívaných zranitelností a do jednoho měsíce u závažných incidentů.

V praxi to znamená, že organizace potřebuje víc než jen checklist. Potřebuje mechanismus, který odpoví na tři otázky: odkud se dozvíme, že problém existuje; kdo posoudí, zda už jde o „aktivně zneužívané“ nebo „závažné“; a jak zorganizujeme předání informací i opravu v čase, který nenechává prostor pro improvizaci.

Pokud se na školeních objevuje zmatek, bývá to často proto, že CRA míří do mezery mezi IT a produktem. Pro IT může být „incident“ událostí v infrastruktuře. Pro výrobce je „incident“ událost, která se týká produktu u zákazníka, konkrétní verze, konfigurace a způsobu nasazení. CRA vynucuje propojení těchto světů do jedné odpovědnosti.

Co CRA zahrnuje: produkt jako vztah k síti, ne „zařízení na stole“

V praxi jsme se při posuzování rizik strojních zařízení učili, že riziko není vlastností samotného stroje — vzniká ve vztahu člověk–stroj. U CRA dochází k podobnému posunu perspektivy: bezpečnost neexistuje „v zařízení“, ale ve vztahu produktu k digitálnímu okolí, ve způsobu použití a ve schopnosti výrobce reagovat.

Komise při shrnutí CRA upozorňuje na definici „produktů s digitálními prvky“ a na to, že povinnosti hlášení se týkají všech takových produktů zpřístupněných na trhu EU — včetně těch uvedených na trh před 11. prosincem 2027. To je klíčové upřesnění, protože vyvrací častý mýtus: „u starých produktů to nehraje roli“. Hlášení — hraje.

Co tu ještě není (harmonizované normy) a proč by to nemělo paralyzovat

W diskusích o CRA se často objevuje věta: „zatím nejsou harmonizované normy, takže se nedá nic dělat“. Zní to logicky, ale skrývá se v tom past. Harmonizované normy jsou nástroj, který usnadňuje prokázání shody (presumpce shody), ale nejsou jedinou cestou k tomu, aby byl produkt skutečně bezpečný. A nejsou ani podmínkou pro to, abyste začali navrhovat správně.

Komise téma standardů otevřeně řeší na stránce „CRA Standardisation“ a uvádí, že přijala standardisation request M/606, který zahrnuje soubor 41 standardů podporujících CRA — jak horizontálních, tak vertikálních (produktových). Je to důležité, protože to ukazuje, že EU chápe problém trhu: bez standardů budou firmy shodu budovat každá po svém a dozor nad trhem to bude mít složitější.

Horizontální a vertikální standardy: co to znamená pro výrobce

Zjednodušeně:

• horizontální standardy mají popisovat „jak“ budovat a udržovat bezpečnost produktu bez ohledu na kategorii (procesy, metody, přístup založený na riziku),
• vertikální standardy mají zpřesnit požadavky pro konkrétní třídy produktů (tam, kde jsou rizika a architektury typické).

Toto rozlišení má praktické dopady. Pokud vyvíjíte průmyslový produkt, kde je část prostředí „OT“ a životní cyklus je dlouhý, budete potřebovat standardy, které nejsou psané pro SaaS aplikaci. A právě proto mají vertikální standardy význam: pomáhají přejít od obecných zásad k tomu, co v reálných architekturách skutečně kontrolovat.

Harmonogram prací: standardy budou přicházet postupně, ne „v balíčku před 2027“

Komise v materiálech k implementaci CRA ukazuje, že CRA se zavádí postupně a standardy mají tento proces v čase podporovat. Z hlediska faktů, které jsou dnes jisté: máme formálně přijaté nařízení a máme spuštěný mechanismus standardizace (M/606).

Pro praxi je nejdůležitější porozumět jedné větě: i když standard vypracují normalizační organizace, „presumpce shody“ v právním smyslu vzniká až ve chvíli, kdy je odkaz na normu zveřejněn jako harmonizovaná norma v Úředním věstníku EU. Takto funguje unijní přístup k harmonizaci obecně: standardy jsou mostem mezi právem a inženýrskou praxí, ale tento most musí být EU formálně „uznán“.

Z pohledu výrobce to znamená, že roky 2026–2027 budou obdobím, kdy část firem bude postupovat na základě vlastních metod prokazování shody (risk-based + důkazy) a část už bude mapovat své postupy na nově vznikající standardy. A to je normální.

„Neexistence norem“ neznamená „neexistence povinnosti“ — znamená větší důraz na důkazy

Tady se objevuje důležitý důsledek: pokud neexistují normy, které dávají nejjednodušší cestu k prokázání shody, roste význam toho, co je v auditorské praxi vždy rozhodující: konzistentní rozhodovací stopa.

Jaká rizika jsme posoudili? Jaké scénáře jsme přijali jako realistické? Jak jsme zvolili ochranná opatření? Jak řídíme zranitelnosti? Jak dlouho produkt podporujeme? Jak informujeme zákazníka? CRA nevyžaduje, aby výrobce „hádat budoucí EN normy“. Vyžaduje, aby výrobce uměl doložit, že jeho rozhodnutí nebyla nahodilá, ale vycházela z rizika a ze současného stavu poznání.

Jak produkt reálně připravit na CRA (roadmapa pro výrobce a integrátora)

Největší přínos CRA spočívá v tom, že vynucuje vyspělost: kybernetická bezpečnost přestává být doplňkem produktu a stává se jeho vlastností. Jenže vyspělost nevzniká z prohlášení. Vzniká z procesu, který je dostatečně přesný, aby fungoval v praxi, a zároveň dostatečně jednoduchý, aby ho inženýrská praxe nezačala obcházet.

Při posuzování rizik strojů vznikají nejlepší konstrukční rozhodnutí ve chvíli, kdy se přestaneme ptát „jaká nebezpečí má stroj“ a začneme se ptát „při jakých úkolech a v jakých stavech je člověk vystaven riziku“. U CRA je to obdobné: přestaneme se ptát „jaké zranitelnosti má produkt“ a začneme se ptát „za jakých podmínek se produkt stává zranitelným a co je výrobce v takové situaci schopen udělat“. Tento posun práci zpřehledňuje a uspořádává.

Krok 1: Definujte produkt jako systém (ne jen jako zařízení)

Začněte tím, že si vymezíte, co je ve vašem případě „produkt s digitálními prvky“. Nejen hardware a firmware, ale i to, co se často přehlíží, protože se to nevejde do krabice: komponenty, knihovny, aktualizační mechanismy, služby, bez nichž produkt neplní svou funkci. V CRA je to důležité, protože odpovědnost výrobce se vztahuje na to, co jde na trh jako produkt — a ne jen na to, co vytvořilo mechanické oddělení.

Je to také první moment, kdy by si integrátoři měli upřímně přiznat realitu: pokud integrujete komponenty a konfigurujete je způsobem, který v očích zákazníka vytváří „finální produkt“, nejste jen „implementátor“. Jste spolutvůrcem rizika i spolutvůrcem odpovědnosti.

Krok 2: Udělejte posouzení rizik CRA tak, aby bylo nástrojem pro rozhodování

Nejde o „matici“ na slidech. Jde o posouzení rizik, které vede k projektovým rozhodnutím a dá se opakovat se stejným výsledkem.

V praxi dobrý přístup k CRA začíná jednoduchou otázkou: jaké jsou reálné scénáře zneužití v prostředí zákazníka, a ne jen v laboratoři? Kdo má servisní přístup? Jak vypadá síť? Jak často aktualizujeme? Jaké jsou důsledky odstávky? V průmyslu jsou tyto otázky nepříjemnější než v IT, protože odpovědi často znějí: „nemůžeme aktualizovat každý týden“ nebo „nemáme telemetrii“. A právě proto je potřeba je položit. CRA je právní požadavek, ale jeho dopady jsou projektové.

Krok 3: Vybudujte „vulnerability handling“ jako výrobní proces, ne jako krizovou reakci

Požadavky na hlášení popsané Komisí (24 h/72 h/14 dní/měsíc) jsou nemilosrdné pro organizaci, která nemá nastavený proces. Pokud chcete být připraveni na 11. září 2026, musíte „vulnerability handling“ brát jako součást životního cyklu produktu, ne jako „úkol security týmu“.

To znamená:

• jeden kanál pro příjem hlášení (CVD policy + kontakt),
• triage s jasným vlastníkem a kritérii,
• mechanismus pro sestavení a doručování security updates,
• model komunikace se zákazníky, který není improvizací,
• připravenost na reportování (kdo hlásí, s jakými daty, jak rychle).

To všechno zní jako „organizační“ práce. Ve skutečnosti je to produktová práce, protože se týká verzí, kompatibility, architektury aktualizací a strategie podpory.

Krok 4: Zvolte dobu podpory jako obchodní rozhodnutí, ne jako minimální požadavek

Pokud vaše produkty v průmyslu fungují 10–15 let, je doba podpory strategická věc. CRA vynucuje, aby podpora nebyla slib bez reálného krytí. To znamená, že doba podpory má vycházet z analýzy: jak dlouho se bude produkt používat, jak vypadá dodavatelský řetězec komponent, jak dlouho budete schopni dodávat opravy. V praxi doba podpory začne „tahat“ celý ekosystém: smlouvy s dodavateli, dostupnost build environment, udržování toolchainů, a dokonce i rozhodnutí, zda má produkt vzdálené funkce, nebo je izolovaný.

Pokud budete dobu podpory brát jako formalitu, nejpozději v roce 2027 narazíte na konflikt: zákazník očekává podporu, ale vy už nemáte zdroje ani závislosti, abyste ji dodali. CRA tento problém nevytváří — CRA ho jen odhaluje.

Krok 5: Uspořádejte dodavatelský řetězec: rozhovor s dodavateli je součástí shody

V CRA není žádná „magie“, která by z externích komponent udělala bezpečné. Pokud vaše zařízení stojí na knihovnách, komunikačních modulech, operačním systému, SDK nebo hardwarových komponentech, vaše riziko přímo závisí na kvalitě postupů dodavatele.

Proto se už teď vyplatí otevřít debatu o věcech, které nezní jako marketing, ale jako inženýrství:

• zda dodavatel umí o zranitelnostech informovat předvídatelným způsobem,
• jakou má dobu reakce,
• zda má proces publikování oprav,
• zda dokáže komponentu udržovat po dobu, která je v souladu s vaší dobou podpory.

Tady CRA skutečně dopadá na byznys: dodavatel, který neumí zranitelnosti obsluhovat, není „levnější“. Je to regulatorní riziko.

Krok 6: Vybudujte dokumentaci jako souvislou stopu: právo → riziko → rozhodnutí → důkaz

V auditech shody vždy vyhrává konzistence. Pokud z posouzení rizik vyplývá, že je určité rozhraní kritické, a dokumentace nepopisuje, jak ho zabezpečujete; pokud deklarujete, že aktualizace jsou bezpečné, ale neumíte ukázat, jak zajišťujete integritu balíčků; pokud říkáte, že máte proces obsluhy zranitelností, ale neumíte ukázat, jak provádíte třídění hlášení — není to „chybějící papír“. Je to chybějící důkaz, že proces funguje.

V CRA, při absenci harmonizovaných norem, je tato stopa obzvlášť důležitá. Protože bude základem jednání s orgánem dozoru nad trhem, s enterprise zákazníkem a u některých kategorií produktů také s jednotkou posuzování shody. A stejně důležité: bude základem vnitřní stability. Tým ví, proč něco děláme, a ne jen „že musíme“.

Závěr: CRA jako nový projektový požadavek, ne „compliance projekt“

Kdybych měl nechat jednu myšlenku, která propojuje všechny tři části: CRA není problém, který se řeší až na konci. Je to rámec, který mění způsob uvažování o produktu. Stejně jako ISO 12100 učí, že riziko vzniká ve vztahu člověk–stroj, tak CRA učí, že kybernetická bezpečnost vzniká ve vztahu produkt–prostředí–životní cyklus výrobce.

Harmonizované normy přijdou a některé postupy zjednoduší. Jejich absence ale není důvodem k nečinnosti. Je to důvod soustředit se na to, co CRA hodnotí vždy: na rozhodnutí, důkazy a schopnost fungovat v realitě — ne v prezentaci.