Nařízení Cyber Resilience Act (CRA): Nové paradigma kybernetické bezpečnosti pro digitální produkty, legislativní kontext a aplikační praxe

Úvod do problematiky: Geopolitický a legislativní kontext evropské kybernetické bezpečnosti

V současném hyperkonektivním světě, kde se stírají hranice mezi fyzickou a digitální realitou, představuje bezpečnost technologických produktů jeden z nejkritičtějších pilířů stability moderní společnosti. Historický vývoj evropského trhu s digitálními technologiemi byl dlouhodobě charakterizován značnou mírou fragmentace a absencí jednotného, právně vymahatelného standardu pro kybernetickou bezpečnost hardwaru a softwaru. Předchozí iniciativy se spoléhaly převážně na dobrovolná certifikační schémata nebo na izolované národní předpisy, což vedlo ke vzniku asymetrického tržního prostředí. V tomto prostředí nesli koncoví uživatelé – ať už jde o spotřebitele, podniky, nebo provozovatele kritické infrastruktury – neúměrně vysoké riziko spojené s nákupem a provozem zranitelných zařízení.

Evropská unie v reakci na eskalující kybernetické hrozby a rostoucí ekonomické ztráty způsobené kyberkriminalitou představila na konci roku 2020 novou Strategii kybernetické bezpečnosti EU (EU Cybersecurity Strategy) a Strategii bezpečnostní unie (EU Security Union Strategy). Tyto strategické dokumenty položily ideové základy pro vznik zcela nového, horizontálního legislativního nástroje, kterým je nařízení Evropského parlamentu a Rady (EU) 2024/2847, formálně označované jako Akt o kybernetické odolnosti (Cyber Resilience Act – CRA). Nařízení CRA vstoupilo oficiálně v platnost dne 10. prosince 2024 a představuje naprostý zlom v přístupu k technologické regulaci. Zatímco dosavadní směrnice se soustředily na bezpečnost provozovatelů a organizací, CRA přesouvá primární břemeno odpovědnosti přímo k počátku hodnotového řetězce – na výrobce, vývojáře, dovozce a distributory produktů s digitálními prvky.

Je zřejmé, že nařízení CRA nevzniklo ve vakuu. Je organickou součástí masivní evropské regulační vlny, jež zahrnuje směrnici NIS2 (v České republice implementovanou prostřednictvím nového zákona o kybernetické bezpečnosti – nZKB), nařízení DORA pro finanční sektor, Akt o umělé inteligenci (AI Act) a Akt o datech (Data Act). Ve společnosti Váš Pověřenec identifikujeme tento regulační vývoj jako moment, kdy kybernetická bezpečnost přestává být volitelným parametrem či marketingovým benefitem a stává se absolutní právní podmínkou pro uvedení jakéhokoliv digitálního produktu na jednotný evropský trh. 

Cílem tohoto článku je poskytnout analýzu nařízení CRA, detailně rozebrat jeho technické a administrativní požadavky, nabídnout praktické příklady z praxe a formulovat strategická doporučení pro subjekty působící v dodavatelských řetězcích.

Materiální působnost nařízení: Definice produktů s digitálními prvky a výjimky z působnosti

Architektura nařízení CRA je navržena jako horizontální právní rámec, což znamená, že jeho působnost je záměrně definována co nejšířeji, aby pokryla dynamicky se vyvíjející spektrum digitálních technologií. Základním stavebním kamenem legislativy je pojem „produkt s digitálními prvky“ (Product with Digital Elements – PDE). Tato definice zahrnuje jakýkoli softwarový nebo hardwarový produkt a jeho řešení pro vzdálené zpracování dat, včetně softwarových a hardwarových komponent, které jsou na trh uváděny samostatně.

Pod tuto definici spadá obrovské množství technologií. Nařízení dopadá na běžná spotřebitelská zařízení typu chytrých hodinek, připojených dětských chůviček, domácích routerů, chytrých televizorů a spotřebičů spadajících do kategorie internetu věcí (IoT). Stejně tak se však vztahuje na čistě softwarová řešení, jako jsou operační systémy, správci hesel, počítačové hry, účetní software, mobilní aplikace, systémy pro správu sítí a cloudové služby, které jsou s hardwarem úzce provázány. Pro výrobce je klíčové pochopit, že jakmile má zařízení logické nebo fyzické datové připojení pro běžné použití (například rozhraní USB, Wi-Fi, Ethernet, Bluetooth nebo připojení do cloudu), spadá plně pod režim CRA.

Navzdory této široké definici legislativa inteligentně reaguje na specifika některých tržních segmentů a definuje přesné výjimky z působnosti:

Zcela vyloučeny z působnosti CRA jsou čistě elektronická zařízení, která neobsahují žádný software (například pasivní senzory nebo tradiční zvonky s analogovými obvody). Dále jsou zpravidla vyňata zařízení vybavená pouze digitální logikou bez jakéhokoliv datového připojení, jako jsou mikrokontroléry spouštějící lokální kód bez drátového či bezdrátového komunikačního rozhraní.

Značná pozornost je věnována produktům, které již podléhají jiným, oborově specifickým nařízením Evropské unie, jež obsahují ekvivalentní úroveň požadavků na bezpečnost. Do této kategorie spadají certifikované zdravotnické prostředky, systémy v civilním letectví, automobilový průmysl (vozidla podléhající vlastním homologačním pravidlům pro kybernetickou bezpečnost), námořní systémy a obranné či vojenské technologie. Integrace těchto výjimek zabraňuje vzniku regulačních duplicit a zbytečné administrativní zátěži pro výrobce operující ve vysoce regulovaných odvětvích.

Zásadní a velmi nuancovanou oblastí, která byla předmětem rozsáhlých debat během legislativního procesu, je svobodný a open-source software (Free and Open-Source Software – FOSS). Z textu nařízení a příslušných recitálů (zejména recitálu 18) vyplývá, že produkty s digitálními prvky, které nejsou dodávány v rámci komerční činnosti (tedy nejsou formálně „uvedeny na trh“ za účelem zisku či jako součást monetizované služby), nařízení CRA nepodléhají. Pokud však nezávislý vývojářský open-source projekt převezme komerční entita a integruje tento software do svého vlastního komerčního produktu, plnou odpovědnost za shodu s CRA přebírá tento finální výrobce. Navíc, pokud právnická osoba působí jako tzv. „správce open-source softwaru“ (open-source software steward), vztahují se na ni specifické, byť mírnější povinnosti popsané v článku 24 nařízení CRA. Komunita OpenSSF (Open Source Security Foundation) v této souvislosti upozorňuje, že integrace požadavků CRA do open-source ekosystému bude vyžadovat vývoj nových komunitních bezpečnostních standardů, na čemž již spolupracují technologičtí giganti s orgány EU.

Taxonomie produktů, analýza rizik a postupy posuzování shody

Základním metodologickým principem nařízení CRA je přístup založený na analýze rizik (risk-based approach). Bylo by ekonomicky neúnosné vyžadovat od výrobce jednoduché mobilní hry stejnou úroveň bezpečnostní certifikace, jaká je vyžadována od výrobce průmyslového řídicího systému pro jadernou elektrárnu. Z tohoto důvodu nařízení kategorizuje produkty do několika tříd, od nichž se odvíjejí postupy posuzování shody (Conformity Assessment Procedures). Evropská komise tento rámec dále specifikovala vydáním návrhu prováděcího nařízení 2025/2392 (dostupného k veřejné konzultaci do dubna 2025), které obsahuje vyčerpávající technické popisy důležitých a kritických produktů.

Následující analytická tabulka poskytuje ucelený přehled kategorizace produktů podle CRA, včetně příkladů a požadavků na certifikaci:

 

 

Analýza tohoto klasifikačního rámce odhaluje zásadní dynamiku: zatímco většina spotřebních produktů bude spadat do standardní kategorie a proces uvedení na trh nebude zdržen externími audity, tvůrci bezpečnostní infrastruktury a dodavatelé B2B technologických celků čelí značnému regulačnímu tlaku. Orgány posuzování shody (Conformity Assessment Bodies – CABs), neboli akreditované zkušebny, projdou procesem certifikace a akreditace (tzv. notifikace) a jejich seznam začne platit od 11. června 2026. Kapacita těchto zkušeben na evropském trhu však bude zpočátku velmi limitovaná, což může vytvořit kritické úzké hrdlo pro uvádění nových produktů Třídy II a Kritických produktů na trh těsně před plnou účinností nařízení na konci roku 2027.

Časová osa implementace a milníky tranzice do roku 2028

Porozumění časovému harmonogramu implementace CRA je pro ekonomické subjekty naprosto klíčové, neboť neznalost termínů nemůže být omluvou pro neplnění povinností. Ačkoliv se rok 2027 může jevit jako vzdálený horizont, technická složitost adaptace softwarového vývoje a integrace principů zabezpečení od návrhu si vyžadují okamžitou akci.

Kompletní chronologie vstupu v platnost a účinnosti jednotlivých ustanovení je strukturována do následujících fází:

 

 

Mimořádně kritickým aspektem této časové osy je pravidlo takzvané „podstatné úpravy“ (substantial modification). Legislativa deklaruje, že na produkty s digitálními prvky uvedené na trh před 11. prosincem 2027 se pravidla CRA vztahují pouze tehdy, pokud od tohoto data projdou podstatnou úpravou. Toto pravidlo de facto znamená, že rozsáhlejší aktualizace softwaru (např. implementace nové funkcionality, zásadní změna architektury firmwaru, aktualizace jádra OS) transformuje starý „legacy“ produkt na produkt nový, který okamžitě podléhá plným požadavkům CRA. To výrobce nutí k velmi strategickému plánování softwarových updatů u staršího hardwaru. Zároveň je nezbytné zdůraznit, že ohlašovací povinnosti (platné od 11. září 2026) se vztahují na veškeré produkty aktivně dostupné na trhu EU, a to bez ohledu na to, zda byly na trh uvedeny před či po tomto datu.

Architektura Security by Design a Security by Default v praxi (Příloha I)

Srdcem nařízení CRA jsou esenciální kybernetické požadavky definované v Příloze I, rozdělené na požadavky na bezpečnostní vlastnosti produktu (Část I) a požadavky na zpracování zranitelností (Část II). Legislativa nařizuje přechod k metodice Security by Design a Security by Default. Tento koncept opouští praxi, kdy se bezpečnost řešila reaktivně po dodání na trh prostřednictvím dodatečných modulů či antivirových řešení. Kybernetická bezpečnost se stává nedílnou součástí plánování, architektury a samotného zdrojového kódu.

V oblasti internetu věcí (IoT), zařízení edge computingu a vestavěných webových serverů jsou důsledky těchto požadavků transformativní. Zařízení musí opustit výrobní linky bez známých a zneužitelných zranitelností a s konfigurací zajišťující maximální ochranu bez nutnosti zásahu uživatele. Z pohledu praktické hardwarové a softwarové integrace se to projevuje v následujících oblastech:

1. Zabezpečení komunikačních protokolů a šifrování: Komunikace v čistém textu (plaintext) prostřednictvím zastaralých protokolů (Telnet, nezabezpečené HTTP, FTP) je zcela nepřípustná. Nařízení CRA vyžaduje ochranu důvěrnosti a integrity přenášených dat. Všechna zařízení komunikující po síti musí implementovat moderní kryptografické sady a protokoly typu TLS (Transport Layer Security). Odborné zdroje doporučují využití integrovaných síťových stacků navržených pro vestavěná zařízení, jakým je například SharkSSL.

2. Identita zařízení a eliminace sdílených hesel: Historicky nejčastější příčinou vzniku masivních botnetů byla praxe přidělování identických továrních přihlašovacích údajů celým produktovým řadám (např. admin/1234). CRA toto výslovně zakazuje. Každé zařízení musí na úrovni výroby obdržet unikátní identitu. Toho se dosahuje buď generováním unikátních hesel odvozených od sériových čísel (vytištěných na štítku), nebo použitím asymetrické kryptografie a certifikátů infrastruktury veřejných klíčů (PKI).

3. Hardwarově podporovaná bezpečnost a správa klíčů: K zajištění integrity kryptografických operací nestačí klíče ukládat v běžné flash paměti, kde by mohly být extrahovány útočníky. Moderní architektury využívají specializované integrované obvody. Příkladem je referenční architektura Infineon využívající bezpečnostní čip OPTIGA Trust-M, integrovaný na evaluačních deskách typu PSOC 6 WiFi-BT Pioneer Kit. Ve spojení s vývojovým prostředím ModusToolbox tento hardwarový základ vývojářům umožňuje implementovat bezpečné zavádění systému (Secure Boot), bezpečné úložiště klíčů a certifikátů a chránit zařízení proti neoprávněné fyzické manipulaci (tamper resistance).

4. Povrch útoku a princip nejmenšího privilegia: Produkt musí po zapnutí a v průběhu provozu minimalizovat útočný povrch. Nepoužívané logické porty a služby musí být deaktivovány. Vývojáři navíc musí integrovat mechanismy ochrany proti neautorizovanému přístupu a zabezpečit možnost resetu zařízení do spolehlivého výchozího stavu v případě bezpečnostního kompromitování.

5. Uživatelská dokumentace a transparentnost (Příloha II): Kromě technických parametrů klade CRA enormní důraz na „informace a pokyny pro uživatele“. Tyto dokumenty musí jasně popisovat, jak zařízení bezpečně nastavit, kdy končí doba podpory (support period) a jak zacházet se zabezpečením. V kontextu průmyslových systémů (Operational Technology – OT) analytici upozorňují, že kvalitně zpracovaná transparentní dokumentace pro zákazníky bude hrát zásadní roli. Poskytovatelé kritické infrastruktury čelí tlaku vykazovat odolnost svých systémů a dodavatel, který prostřednictvím CE štítku a perfektní dokumentace doloží plnění CRA, získá obrovskou konkurenční a komerční výhodu, neboť asset owners (majitelé aktiv) jsou ochotni za ověřitelnou bezpečnost platit.

Součástí metodiky Security by Design je také neustálé hodnocení rizik a modelování hrozeb (Threat Modeling) v průběhu návrhu i implementace, jejichž výsledky musí být po dobu minimálně 10 let evidovány v rozsáhlé technické dokumentaci.

Transparence kódu: Softwarový kusovník (SBOM) jako legislativní imperativ

Zásadním průlomem nařízení CRA, který plně rezonuje s moderními přístupy kybernetické bezpečnosti dodavatelských řetězců, je povýšení Softwarového kusovníku (Software Bill of Materials – SBOM) z kategorie doporučovaných komunitních praktik (best practices) na úroveň striktního a vymahatelného legislativního standardu (Příloha I, Část II, bod 1 nařízení). Softwarové produkty dnes nejsou monolitickými bloky proprietárního kódu, nýbrž složitými kompozicemi otevřených (open-source) komponent, knihoven třetích stran a komerčních modulů. Neschopnost rychle identifikovat zranitelnou knihovnu (jako tomu bylo například při globální krizi kolem knihovny Log4j) paralyzuje schopnost reakce na incident.

Legislativa jednoznačně nařizuje výrobcům vypracovat SBOM pro každý produkt s digitálními prvky. Tento dokument identifikuje všechny softwarové závislosti, přičemž požadované minimum zahrnuje pokrytí závislostí „nejvyšší úrovně“ (top-level dependencies) tvořících samotný produkt. Pro generování SBOM musí výrobci využívat běžně používané, mezinárodně standardizované a strojově čitelné formáty, přičemž průmyslovými standardy se v této oblasti staly formáty SPDX (Software Package Data Exchange) a CycloneDX.

Okolo povinnosti zpracovávat SBOM panovaly v technologickém sektoru obavy z vynuceného vyzrazení obchodního tajemství a duševního vlastnictví. Finální znění nařízení CRA tyto obavy mírní: legislativa výslovně nevyžaduje, aby byl SBOM zveřejněn na internetu nebo volně poskytnut koncovým uživatelům (Recitál 77). SBOM se stává integrální součástí povinné technické dokumentace, kterou musí výrobce nejen vypracovat, ale i proaktivně udržovat aktuální v průběhu celého životního a aktualizačního cyklu produktu. Výrobce je dále povinen uchovávat SBOM minimálně po dobu deseti let a na vyžádání jej okamžitě poskytnout orgánům dozoru nad trhem, případně orgánům posuzujícím shodu za účelem auditu či forenzního vyšetřování závažného incidentu. Z provozního hlediska to pro vývojářské týmy znamená naprostou nezbytnost plně integrovat generátory SBOM přímo do CI/CD (Continuous Integration / Continuous Delivery) infrastruktur, aby se nový kusovník tvořil automatizovaně s každým nasazením nového firmwaru.

Řízení zranitelností, ohlašovací povinnosti a role ENISA (Článek 14 a 16)

Nejbližším a pravděpodobně provozně nejnáročnějším milníkem pro všechny výrobce (s datem spuštění 11. září 2026) je radikální změna v systémech detekce, zpracování a ohlašování zranitelností a bezpečnostních incidentů. Nařízení CRA ukončuje dřívější model, ve kterém po prodeji softwaru končila zodpovědnost tvůrce za jeho zranitelnosti. Nově nastupuje model nepřetržitého dohledu a proaktivní součinnosti s evropskými dohledovými institucemi.

Proces ohlašování je striktně časově ohraničen a týká se dvou primárních událostí: aktivně zneužívaných zranitelností (actively exploited vulnerabilities) a závažných incidentů s dopadem na bezpečnost samotného produktu (severe incidents). K naplnění tohoto procesu definuje článek 14 nařízení CRA třístupňový oznamovací mechanismus:

1. Včasné varování (Early Warning): Výrobce musí odeslat prvotní hlášení do nekompromisních 24 hodin od okamžiku, kdy pojme podezření nebo prokazatelně zjistí existenci aktivně zneužívané zranitelnosti nebo incidentu. V tomto varování informuje o základní podstatě problému.

2. Plné oznámení (Full Notification): Následně, do 72 hodin od získání povědomí, musí následovat detailní zpráva obsahující rozsáhlé technické specifikace, indikátory kompromitace (IoC) a prvotní odhad možných systémových dopadů, případně popis mitigací.

3. Závěrečná zpráva (Final Report): Poslední fáze oznamovacího procesu závisí na povaze problému. V případě zranitelnosti musí výrobce dodat závěrečnou zprávu do 14 dnů po vydání bezpečnostní záplaty (nápravného opatření). V případě bezpečnostního incidentu pak nejpozději do 1 měsíce od incidentu.

Pro minimalizaci fragmentace a byrokratické zátěže plynoucí z nutnosti hlásit incidenty různým národním úřadům zavádí článek 16 nařízení zřízení centrální platformy. Agentura Evropské unie pro kybernetickou bezpečnost (ENISA) získala mandát a prostředky k vybudování platformy s názvem CRA Single Reporting Platform (SRP). Prostřednictvím této jediné platformy splní výrobce svou ohlašovací povinnost. Platforma SRP následně automaticky předá hlášení příslušnému národnímu týmu CSIRT (Computer Security Incident Response Team) v zemi, kde má výrobce své hlavní sídlo. CSIRT poté sdílí (pokud neexistují výjimečné důvody zpoždění z důvodu hrozícího bezpečnostního rizika) tyto informace s ostatními státy EU, na jejichž území je daný produkt dostupný.

Tyto požadavky generují masivní tlak na výrobce. Ke dni 11. září 2026 musí mít organizace vybudované kapacity typu Security Operations Center (SOC) a propracované směrnice pro koordinované zveřejňování zranitelností (Coordinated Vulnerability Disclosure - CVD). Budou muset implementovat systémy pro kontinuální sledování zneužití v kyberprostoru, poskytnout zákazníkům i externím bezpečnostním výzkumníkům kanály a kontaktní adresy pro podávání hlášení a mít připravenou komunikační strategii na sdílení opravených chyb (například v podobě bezpečnostních bulletinů).

Životní cyklus produktu a ustanovení o době podpory (Support Period)

Dalším pilířem, který přímo cílí na chronickou slabinu trhu s hardwarem a IoT zařízeními, je legislativní zakotvení doby podpory a povinnosti dlouhodobě poskytovat bezpečnostní aktualizace. Dříve bylo standardem, že prodejci ukončovali podporu starších zařízení velmi záhy po uvedení nového modelu na trh. Tyto opuštěné („zombie“) produkty nadále fungovaly v domácnostech či továrnách, ale vlivem chybějících bezpečnostních záplat se stávaly primárním vektorem úspěšných kyberútoků.

Nařízení CRA na tento problém reaguje tím, že ukládá výrobcům povinnost definovat tzv. dobu podpory (Support Period), během které garantují efektivní zpracovávání zranitelností a vydávání bezpečnostních oprav zcela zdarma pro uživatele. Základní pravidlo nařízení stanovuje, že tato doba by měla trvat v zásadě minimálně pět let. Legislativa však akceptuje realitu různorodých produktových segmentů; pokud se od výrobku na základě jeho povahy (například levné, spotřební senzory s krátkou fyzickou životností baterie) očekává doba používání kratší, doba podpory se tomuto zkrácenému časovému rámci proporčně přizpůsobí. Klíčovým prvkem je však transparentnost – konkrétní měsíc a rok ukončení doby podpory (tzv. End-of-Support) musí výrobce naprosto srozumitelně specifikovat a sdělit uživateli již v okamžiku nákupu zařízení, ať už fyzicky na obalu, nebo v přiložených průvodních informacích.

Zásadní inovací je rovněž požadavek CRA na oddělování bezpečnostních záplat od funkčních aktualizací. Zákazníci často odmítají instalovat objemné updaty měnící chování nebo rozhraní produktu (feature updates). Výrobce proto musí zajistit oddělený kanál pro stažení a instalaci výhradně bezpečnostních fixů.

Nařízení dále myslí na historickou dostupnost těchto záplat. Výrobce musí zaručit, že každá vydaná bezpečnostní aktualizace zůstane uživatelům plně k dispozici a snadno dostupná po dobu minimálně 10 let od svého vydání, nebo po zbytek původně garantované doby podpory – přičemž platí to delší z těchto období. Toto pravidlo radikálně mění strategii End-of-Life a End-of-Sales u výrobců. Pro splnění podmínek musí firmy pečlivě plánovat stažení produktu z trhu. Jestliže si výrobce u hardwaru nastaví pětiletou dobu podpory a zamýšlí tuto podporu finálně ukončit v roce 2035, znamená to, že musí zastavit produkci a fyzický prodej posledních kusů tohoto zařízení již v roce 2030, čímž zabezpečí, že i u posledního prodaného kusu bude plně garantován pětiletý servis kybernetické bezpečnosti.

Synergie a průsečíky: CRA, NIS2, DORA a nový zákon o kybernetické bezpečnosti (nZKB)

Pro dosažení holistického pochopení dopadů nařízení CRA na český i evropský trh je nezbytné zasadit tento akt do kontextu paralelně zaváděných legislativ, jmenovitě směrnice NIS2 a nařízení DORA. Zatímco firmy často vnímají tyto normy jako oddělené a vzájemně si konkurující administrativní překážky, jedná se o tři vrcholy integrovaného evropského trojúhelníku digitální odolnosti. Jak ukazují případové studie a webináře, CRA bude mít v reálné praxi pro mnoho výrobních a IT společností mnohem drastičtější a bezprostřednější komerční dopady než samotný zákon o kybernetické bezpečnosti, neboť se stává primární vstupenkou do B2B tržního ekosystému.

Analýza vzájemných vazeb odhaluje tyto rozdíly a společné cíle:

●   NIS2 (Nový zákon o kybernetické bezpečnosti - nZKB): Směrnice NIS2, která v ČR vstupuje v platnost ve formě nZKB pod dohledem Národního úřadu pro kybernetickou a informační bezpečnost (NÚKIB), cílí na samotné subjekty (organizace, podniky) fungující v kritických odvětvích státu. Její podstatou je zavádění prvků ISMS (Systém řízení bezpečnosti informací), hlášení systémových incidentů, řízení rizik organizace, podstupování auditů, penetrační testování a prokazování odolnosti perimetru. Regulace rozeznává režimy vyšších a nižších povinností a pro komunikaci zřizuje NÚKIB vlastní Portál.

●   DORA (Digital Operational Resilience Act): Toto nařízení plní pro finanční sektor (bankovnictví, pojišťovnictví, obchodování na burzách) stejnou úlohu, jakou NIS2 plní pro zbytek průmyslu a infrastruktury. Zaměřuje se hluboce na digitální provozní odolnost vůči výpadkům, nastavování procesů hlášení u kritických ICT poskytovatelů pro banky a budování robustních plánů obnovy po havárii (Disaster Recovery Plans) s cílem uchránit stabilitu vnitřního finančního trhu.

●   CRA (Cyber Resilience Act): Zatímco NIS2 a DORA regulují „kdo produkt používá a jak se chová v síti“, CRA reguluje „jak kvalitně a bezpečně je produkt navržen a vyroben“. Nařízení cílí na konkrétní materiální komodity (software, hardware), nikoliv na způsob provozu podniku.

Zcela klíčový přesah, který vytváří kaskádový efekt, spočívá v požadavku směrnice NIS2 na zajištění takzvané bezpečnosti dodavatelského řetězce. Když elektrárna, krajská nemocnice (regulované pomocí NIS2) nebo banka (regulovaná DORA) budou poptávat nový síťový hardware, software pro řízení přístupů či analytické nástroje, budou mít od roku 2027 legislativní povinnost odebírat pouze systémy, u kterých byla prokazatelně ověřena kybernetická bezpečnost – tedy takové produkty, které nesou štítek shody podle pravidel CRA. Tím se tlak plynoucí z NIS2 okamžitě přesouvá i na menší a jinak neregulované vývojářské subjekty, které, pokud budou chtít prodávat svůj software větším klientům nebo státu, budou muset splňovat regule CRA.

V České republice figuruje v dohledu nad tímto ekosystémem NÚKIB, který byl určen za gestora i pro akt CRA, podílel se na přípravách technických specifikací prostřednictvím veřejných konzultací a připravuje rámce pro dozor nad trhem. Společnost Váš Pověřenec se se svými moduly zaměřuje právě na to, jak tuto složitou matrici povinností z NIS2, GDPR, umělé inteligence a CRA centralizovat.

Strategický manuál a kroky pro firmy: Jak se připravit do roku 2026 a 2027

Přestože se plné nasazení regulace a požadavek na označení CE může zdát ukryté až v horizontu konce roku 2027, realita inženýrských cyklů softwarového a hardwarového vývoje ukazuje, že čas zbývající do aktivace norem je naprosto kritický. Firmy, které nezahájí adaptační kroky nyní, podstupují masivní komerční i právní riziko. Následující ucelený rámec kroků poskytuje návod, jak proaktivně čelit nástupu CRA:

1. Klasifikace a důkladný audit existujícího i plánovaného portfolia (Gap Analysis): Organizace musí jako první krok kategorizovat každý produkt z hlediska jeho zařazení. Rozhodnutí, zda je řešení standardní, nebo náleží do Třídy I (např. VPN, password managery), Třídy II (např. hypervizory) či do kritických platforem, primárně určí alokaci finančních a personálních zdrojů na certifikační audity nezávislými institucemi.

2. Architektonické a technologické začlenění Security by Design (Integrace vývoje): Společnosti vyvíjející software musí plně adoptovat postupy DevSecOps. Je nutné začlenit do procesů CI/CD pipelin systémy na strojové generování softwarových kusovníků (SBOM) ve formátech SPDX či CycloneDX, nasadit nástroje pro statickou a dynamickou analýzu zranitelností a opustit architektury spoléhající se na výchozí neměnná hesla či nesnadno aktualizovatelné knihovny.

3. Nastavení krizových procesů správy zranitelností (Termín do září 2026): V souvislosti se zavedením ohlašovacích lhůt (24/72 hodin/14 dnů) k rukám ENISA musí firmy radikálně přepracovat procesy reakce na incidenty. To vyžaduje zavedení plně fungujícího a dedikovaného triage kanálu pro hlášení chyb, vyčlenění odpovědných rolí komunikujících směrem ven a přípravu struktur na rychlý vývoj fixů, které budou doručovány izolovaně od standardních updatů.

4. Inovace dokumentace a řízení smluvních řetězců: Dodatečně k posilování bezpečnosti kódu je potřeba vybudovat a pro každý produkt uchovávat po dobu deseti let komplexní technickou dokumentaci (včetně analýz rizik, modelů hrozeb a SBOM). Značný objem práce bude představovat přepracování uživatelských manuálů obsahujících přesné instrukce pro uvedení do provozu, obnovu výchozího stavu a deklaraci konce doby podpory (End of Support). Nelze opomenout ani nezbytnost masivního zásahu do smluv s dodavateli, distributory i korporátními klienty (Supply Chain Agreements), pro zajištění transferu odpovědnosti a vyjasnění, kdo provádí sběr notifikací o zranitelnostech a kdo zajišťuje validaci pro štítek CE.

Vzhledem k nesmírné zátěži, jakou tato byrokracie představuje pro střední a menší technologické firmy (SME), nabývají na významu centralizované platformy zajišťující řízení compliance a management interních procesů. Moderní systémy, jako je SaaS platforma poskytovaná společností Váš Pověřenec, integrují problematiku GDPR, NIS2, whistleblowingu i nástroje využívající prvků GenAI k inteligentní analýze dokumentů. Tyto automatizované ekosystémy dokážou významně snížit chaos spojený se sháněním dokumentace a podkladů při přípravách na audity a komunikaci s úřady, čímž firmám dávají jedinou klíčovou výhodu – jistotu shody a uvolnění kapacity na reálný vývoj kvalitního a kyberneticky odolného produktu.

Závěrečné zhodnocení a predikce budoucího vývoje

Nařízení Evropské unie (EU) 2024/2847 (Cyber Resilience Act) znamená absolutní zlom v nazírání na dodavatelský řetězec digitálních produktů. Končí doba, kdy trh s hardwarem a softwarem fungoval víceméně jako divoký západ, kde odpovědnost za ztráty a úniky dat způsobené zastaralým a nedbale napsaným zdrojovým kódem nesli výhradně koncoví zákazníci. S ohlašovacími povinnostmi vstupujícími v platnost již v roce 2026 a následným plným vynucením standardů Security by Design, generování SBOM a přísným označováním CE v roce 2027, přechází evropský technologický trh do zcela nového režimu zralosti.

Firmy operující v softwarovém či hardwarovém vývoji musí procesní adaptaci zařadit do absolutních priorit představenstva. Zdržení implementace těchto rozsáhlých technických a byrokratických opatření představuje pro podniky bezprostřední hrozbu odříznutí od evropského jednotného trhu, zejména pak od strategicky zásadních a finančně lukrativních zakázek u společností nově regulovaných směrnicí NIS2. Integrací efektivních compliance nástrojů a nastavením procesů však organizace nejen splní mandatorní vládní požadavky, ale prostřednictvím transparentně odolných produktů navíc zásadním způsobem posílí svou konkurenční tržní pozici v éře, kdy důvěra je primárním determinantem digitálního obchodního úspěchu.