Cyber Resilience Act, zkráceně CRA, je nové evropské nařízení, které mění pohled na kybernetickou bezpečnost softwaru, hardwaru a připojených zařízení. Jeho cílem je zajistit, aby produkty s digitálními prvky byly bezpečnější už ve fázi návrhu, vývoje, výroby i následné údržby.
Na rozdíl od regulací, jako je NIS2, se CRA nezaměřuje primárně na provozovatele služeb nebo interní bezpečnost organizace. Dopadá hlavně na výrobce, dovozce a distributory produktů, které obsahují software, hardware nebo jiný digitální prvek a jsou uváděny na trh Evropské unie.
Proč Cyber Resilience Act vznikl?
Počet zařízení a aplikací připojených k síti neustále roste. Digitální prvky dnes najdeme nejen v počítačích, serverech nebo mobilních aplikacích, ale také v průmyslových zařízeních, chytré domácnosti, zdravotnických technologiích, spotřební elektronice nebo cloudově propojených produktech.
Problém je, že mnoho těchto produktů se dostává na trh bez dostatečného zabezpečení. Častými slabinami jsou například výchozí hesla, nedostatečné aktualizace, nejasná odpovědnost za opravy zranitelností nebo chybějící informace o použitých softwarových komponentách.
CRA má tento stav změnit. Zavádí povinnost řešit kybernetickou bezpečnost po celý životní cyklus produktu – od návrhu až po ukončení podpory.
Koho se CRA týká?
Cyber Resilience Act se vztahuje na produkty s digitálními prvky, které jsou uváděny na trh EU. Může jít o software, hardware i samostatné komponenty, pokud jejich zamýšlené nebo rozumně předvídatelné použití zahrnuje přímé nebo nepřímé datové připojení k zařízení nebo síti.
Typicky se může jednat například o:
- podnikový software,
- mobilní a desktopové aplikace,
- síťová zařízení,
- IoT zařízení,
- chytré spotřebiče,
- průmyslové řídicí prvky,
- bezpečnostní produkty,
- softwarové knihovny a komponenty uváděné na trh samostatně.
CRA se netýká pouze výrobců ve smyslu fyzické výroby zařízení. Povinnosti mohou dopadnout i na společnosti, které produkt vyvíjejí, nechávají si jej vyvíjet, prodávají jej pod vlastní značkou, dovážejí jej ze třetích zemí nebo jej distribuují na evropském trhu.
Pokud organizace zároveň spadá pod NIS2/ZKB, bude muset řešit nejen vlastní systém řízení kybernetické bezpečnosti, ale v některých případech také bezpečnost produktů nebo softwaru, které vyvíjí, dodává nebo provozuje.
Hlavní povinnosti podle CRA
CRA zavádí několik oblastí povinností. V praxi nejde jen o jednorázové prohlášení o shodě, ale o systémový přístup k bezpečnosti produktu.
1. Bezpečnost už při návrhu a vývoji
Výrobce musí zajistit, aby produkt odpovídal základním kyberbezpečnostním požadavkům. To znamená například přiměřenou ochranu proti neoprávněnému přístupu, bezpečné výchozí nastavení, minimalizaci útočné plochy, ochranu integrity dat a možnost bezpečných aktualizací.
Bezpečnost se tak nemá řešit až dodatečně, ale musí být součástí návrhu produktu, vývojového procesu a řízení rizik.
2. Řízení zranitelností
Výrobci budou muset zavést procesy pro identifikaci, evidenci, vyhodnocování a odstraňování zranitelností. To zahrnuje také schopnost poskytovat bezpečnostní aktualizace a komunikovat informace o zranitelnostech uživatelům nebo příslušným orgánům.
Součástí požadavků je i práce s informacemi o softwarových komponentách, typicky formou evidence komponent nebo SBOM. Bez přehledu o použitých knihovnách, modulech a závislostech bude velmi obtížné prokázat, že organizace umí řídit bezpečnost produktu v celém jeho životním cyklu.
Podobný princip platí i u interní kybernetické bezpečnosti – bez aktuální evidence a řízení aktiv podle ZKB nelze spolehlivě vyhodnotit rizika, dopady ani odpovědnosti.
3. Hlášení aktivně zneužívaných zranitelností a závažných incidentů
CRA zavádí povinnost hlásit aktivně zneužívané zranitelnosti a závažné incidenty dopadající na bezpečnost produktu. Výrobci mají podávat včasné varování do 24 hodin od okamžiku, kdy se o problému dozví, a úplné oznámení do 72 hodin. Finální zpráva má následovat ve stanovených lhůtách podle typu události.
Pro firmy to znamená, že potřebují jasný proces: kdo incident vyhodnocuje, kdo rozhoduje o hlášení, kdo komunikuje s orgány a jak se uchovávají důkazy o přijatých opatřeních.
4. Posuzování shody a technická dokumentace
Produkty budou muset projít odpovídajícím procesem posouzení shody. U řady běžných produktů může jít o interní posouzení výrobcem, u rizikovějších kategorií však může být vyžadováno zapojení oznámeného subjektu.
Výrobce bude muset vést technickou dokumentaci, která prokazuje splnění požadavků CRA. To může zahrnovat například popis produktu, analýzu rizik, bezpečnostní opatření, testování, informace o zranitelnostech, aktualizacích a procesech podpory.
V praxi se zde CRA přibližuje obecnému principu compliance: organizace musí být schopna doložit, jaká opatření zavedla, proč je zavedla a v jakém jsou stavu. Podobnou logiku má například Prohlášení o aplikovatelnosti podle ZKB, které pomáhá strukturovat požadavky, opatření a jejich aplikovatelnost.
Od kdy se CRA použije?
Cyber Resilience Act vstoupil v platnost 10. prosince 2024. Hlavní povinnosti se začnou uplatňovat od 11. prosince 2027. Některé části však začínají dříve: pravidla pro oznamování posuzování shody od 11. června 2026 a povinnosti hlášení podle článku 14 od 11. září 2026.
To znamená, že organizace mají přechodné období, ale neměly by čekat až na konec roku 2027. Zejména firmy, které vyvíjejí software nebo uvádějí digitální produkty na trh, budou potřebovat upravit vývojové, bezpečnostní, dokumentační i incidentní procesy.
Jaký je vztah CRA k NIS2 a dalším regulacím
CRA se často zmiňuje společně s DORA nebo novým zákonem o kybernetické bezpečnosti. Jejich zaměření je ale odlišné.
NIS2 a nový zákon o kybernetické bezpečnosti se soustředí hlavně na kybernetickou bezpečnost organizací a poskytovaných služeb. DORA se zaměřuje na digitální provozní odolnost finančního sektoru. CRA naproti tomu řeší bezpečnost produktů s digitálními prvky, tedy to, aby software a hardware uváděný na trh splňoval základní bezpečnostní požadavky.
V praxi se tyto regulace mohou potkávat. Organizace, která spadá pod ZKB, může zároveň používat produkty dotčené CRA. Výrobce softwaru může zase řešit CRA jako produktovou regulaci a současně NIS2 jako regulaci vlastní organizace, pokud splní podmínky pro její působnost.
Co by měly firmy udělat už teď
Příprava na CRA by neměla začít až tvorbou technické dokumentace těsně před účinností hlavních povinností. Vhodný postup je začít základním mapováním produktů a procesů.
Prvním krokem je určit, zda firma vyvíjí, vyrábí, dováží nebo distribuuje produkty s digitálními prvky. Následně je potřeba vyhodnotit, jaké role podle CRA zastává a jaké povinnosti z toho vyplývají.
Dalším krokem je provést gap analýzu vůči požadavkům CRA. Ta by měla zahrnovat zejména:
- přehled produktů a jejich digitálních komponent,
- proces řízení bezpečnostních rizik,
- proces vývoje a změnového řízení,
- správu zranitelností,
- evidenci softwarových komponent,
- bezpečnostní aktualizace,
- incidentní a reportovací proces,
- technickou dokumentaci,
- odpovědnosti jednotlivých týmů.
Výsledkem by měl být konkrétní plán opatření, nikoliv pouze obecné konstatování, že se firma musí na CRA připravit.
Pokud organizace nemá kapacitu tyto oblasti dlouhodobě řídit interně, může využít také službu manažera kybernetické bezpečnosti, který pomůže nastavit odpovědnosti, procesy a návaznost na další regulatorní požadavky.
Jak může pomoci cybreg
Cybreg pomáhá organizacím převést regulatorní požadavky do praktického řízení bezpečnosti, rizik a kontrol. V kontextu Cyber Resilience Act může sloužit jako nástroj pro evidenci požadavků, řízení odpovědností, sledování opatření a dokumentování souladu.
V praxi lze v cybregu podpořit například:
- mapování požadavků CRA na interní kontroly,
- evidenci produktů, aktiv a odpovědností,
- řízení rizik spojených s vývojem a provozem digitálních produktů,
- plánování a sledování nápravných opatření,
- dokumentaci procesů pro řízení zranitelností,
- přípravu podkladů pro audit nebo posouzení shody,
- propojení CRA s dalšími rámci, například NIS2, ISO 27001 nebo interními bezpečnostními politikami.
CRA nebude jen právní povinností. Pro řadu firem se stane testem toho, zda mají skutečně zvládnutý bezpečný vývoj, správu zranitelností a dokumentaci kybernetické bezpečnosti produktů.
Závěr
Cyber Resilience Act posouvá kybernetickou bezpečnost blíže k samotným produktům. Nestačí, aby organizace zabezpečila pouze vlastní infrastrukturu. Pokud vyvíjí, vyrábí nebo uvádí na trh produkty s digitálními prvky, bude muset prokázat, že bezpečnost řeší systematicky, průběžně a doložitelně.
Firmy, které začnou s přípravou včas, získají výhodu. Budou mít přehled o svých produktech, zranitelnostech, odpovědnostech i dokumentaci. A právě v tom může sehrát důležitou roli dobře nastavená GRC platforma, která pomůže převést požadavky CRA z legislativního textu do každodenní praxe.
