Cyber Resilience Act (CRA) 2026–2027: čo už vieme, čo ešte chýba a ako sa reálne pripraviť s produktom — skôr než sa objavia harmonizované normy

Čo dnes vieme určite (a prečo to nie je „téma na rok 2027“)

Cyber Resilience Act môže pôsobiť ako ďalší dokument „z Bruselu“, ktorý sa dá odložiť na neskôr. Je to prirodzená reakcia, najmä ak firma funguje v rytme projektov: prototyp, zavedenie, sériová výroba, servis. Regulácie často prichádzajú ako „záverečná požiadavka“ — niečo, čo sa doťahuje na konci. CRA túto logiku mení, pretože sa netýka iba toho, čo je na produkte viditeľné v deň predaja. Týka sa toho, či výrobca dokáže udržať bezpečnosť produktu v čase a preukázať, že to urobil vedome, nie náhodou.

Najdôležitejší fakt je jednoduchý, no má strategické dôsledky: CRA je produktová regulácia, ukotvená v mechanike trhu EÚ (vrátane označovania CE). Európska komisia výslovne uvádza, že produkty majú niesť označenie CE ako signál súladu s CRA a vymáhanie je v kompetencii orgánov dohľadu nad trhom. Nie je to teda „IT štandard“, ktorý sa dá brať ako interný program zlepšovania. Je to rámec, ktorý ovplyvňuje možnosť predaja.

Dátumy, ktoré dávajú uvažovaniu poriadok

V samotnom texte nariadenia (EÚ) 2024/2847 je viditeľné postupné uplatňovanie. CRA sa uplatňuje od 11. decembra 2027, ale s jasne uvedenými výnimkami. Článok 14 (nahlasovanie) sa uplatňuje od 11. septembra 2026 a kapitola o notifikácii orgánov posudzovania zhody (Chapter IV) od 11. júna 2026. Sú to tri dátumy, ktoré sa oplatí vnímať ako „míľniky“, pretože zodpovedajú trom rôznym typom pripravenosti: prevádzkovej, inštitucionálnej a produktovej.

Komisia to komunikuje ešte jednoduchšie: CRA nadobudlo účinnosť 10. decembra 2024, kľúčové povinnosti od 11. decembra 2027 a nahlasovanie od 11. septembra 2026. Ak niekto vo firme hovorí „máme čas do 2027“, najčastejšie tým myslí projektové požiadavky a posudzovanie zhody. Nahlasovanie je však skôr a týka sa udalostí, ktoré nečakajú na harmonogram.

Nahlasovanie: povinnosť, ktorá si vynucuje proces (nie dokument)

Požiadavka na nahlasovanie je dobrým lakmusovým papierikom, pretože ukazuje, ako CRA chápe „kybernetickú bezpečnosť produktu“. Nie je to vyhlásenie zámeru ani „politika“. Je to proces, ktorý musí fungovať v stresovej situácii: keď sa objaví aktívne zneužívaná zraniteľnosť alebo závažný incident.

Komisia to opisuje jednoznačne: výrobca má nahlasovať aktívne zneužívané zraniteľnosti a závažné incidenty, ktoré ovplyvňujú bezpečnosť produktu. Vyžaduje sa „early warning“ do 24 hodín od momentu, keď sa o tom dozvie, úplné hlásenie do 72 hodín a záverečná správa: do 14 dní od dostupnosti nápravného opatrenia pri aktívne zneužívaných zraniteľnostiach a do jedného mesiaca pri závažných incidentoch.

V praxi to znamená, že organizácia potrebuje viac než checklist. Potrebuje mechanizmus, ktorý odpovie na tri otázky: odkiaľ sa dozvieme, že problém existuje; kto posúdi, či už ide o „aktívne zneužívané“ alebo „závažné“; a ako zorganizujeme tok informácií aj opravu v čase, ktorý nenecháva priestor na improvizáciu.

Ak sa na školeniach objavuje chaos, často je to preto, že CRA zasahuje medzeru medzi IT a produktom. Pre IT býva „incident“ udalosťou v infraštruktúre. Pre výrobcu je „incident“ udalosť, ktorá sa týka produktu u zákazníka, verzie, konfigurácie, spôsobu nasadenia. CRA si vynucuje prepojenie týchto svetov do jednej zodpovednosti.

Čo zahŕňa CRA: produkt ako vzťah so sieťou, nie „zariadenie na stole“

V praxi sme sa pri posudzovaní rizika strojov učili, že riziko nie je vlastnosťou samotného stroja — vzniká vo vzťahu človek – stroj. V CRA nastáva podobný posun perspektívy: bezpečnosť neexistuje „v zariadení“, ale vo vzťahu produktu k digitálnemu prostrediu, v spôsobe používania a v schopnosti výrobcu reagovať.

Komisia pri zhrnutí CRA upozorňuje na definíciu „produktov s digitálnymi prvkami“ a na to, že povinnosti nahlasovania sa týkajú všetkých takýchto produktov sprístupnených na trhu EÚ — vrátane tých, ktoré boli uvedené pred 11. decembrom 2027. Ide o kľúčové spresnenie, pretože vyvracia častý mýtus: „pri starých produktoch to nehrá rolu“. Nahlasovanie — hrá.

Čo ešte nie je k dispozícii (harmonizované normy) a prečo by to nemalo paralyzovať

V diskusiách o CRA sa často objavuje veta: „ešte nie sú harmonizované normy, takže sa nedá konať“. Znie to logicky, no skrýva sa v tom pasca. Harmonizované normy sú nástroj, ktorý uľahčuje preukázanie zhody (predpoklad zhody), ale nie sú jedinou cestou k vybudovaniu skutočnej bezpečnosti produktu. A nie sú ani podmienkou na to, aby ste začali navrhovať správne.

Komisia túto tému štandardov priamo rieši cez stránku „CRA Standardisation“ a informuje, že prijala štandardizačnú požiadavku M/606, ktorá zahŕňa súbor 41 štandardov podporujúcich CRA — a to horizontálnych aj vertikálnych (produktových). Je to dôležité, pretože to ukazuje, že EÚ rozumie problému trhu: bez štandardov budú firmy preukazovať zhodu každá po svojom a dohľad nad trhom to bude mať ťažšie.

Horizontálne a vertikálne štandardy: čo to znamená pre výrobcu

Zjednodušene:

• horizontálne štandardy majú opisovať „ako“ budovať a udržiavať bezpečnosť produktu bez ohľadu na kategóriu (procesy, metódy, prístup založený na riziku),
• vertikálne štandardy majú spresniť požiadavky pre konkrétne triedy produktov (tam, kde sú riziká a architektúry typické).

Toto rozlíšenie má praktické dôsledky. Ak vytvárate priemyselný produkt, v ktorom je časť prostredia „OT“ a životný cyklus je dlhý, budete potrebovať štandardy, ktoré nie sú písané pre aplikáciu SaaS. A práve preto majú vertikálne štandardy význam: pomáhajú zísť z úrovne všeobecných zásad k tomu, čo kontrolovať v reálnych architektúrach.

Harmonogram prác: štandardy budú pribúdať postupne, nie „v balíku pred 2027“

Komisia v materiáloch k implementácii CRA ukazuje, že CRA sa zavádza postupne a štandardy majú tento proces v čase podporovať. Z faktov, ktoré sú dnes isté: máme formálne prijaté nariadenie a máme spustený mechanizmus štandardizácie (M/606).

Pre prax je najdôležitejšie pochopiť jednu vetu: aj keď štandard vypracujú normalizačné organizácie, „predpoklad zhody“ v právnom zmysle vzniká až vtedy, keď sa odkaz na normu zverejní ako harmonizovaná norma v Úradnom vestníku EÚ. Je to mechanizmus spoločný pre európsky prístup k harmonizácii: štandardy sú mostom medzi právom a inžinierskou praxou, no tento most musí EÚ formálne „uznať“.

Z pohľadu výrobcu to znamená, že roky 2026 – 2027 budú obdobím, keď časť firiem bude postupovať na základe vlastných metód preukazovania zhody (risk-based + dôkazy) a časť sa už bude mapovať na postupne sa objavujúce štandardy. A je to normálne.

„Neexistencia noriem“ neznamená „neexistenciu povinnosti“ — znamená väčšiu váhu dôkazov

Tu sa objavuje dôležitý dôsledok: ak nie sú normy, ktoré poskytujú najjednoduchšiu cestu preukázania zhody, rastie význam toho, čo je v audítorskej praxi vždy rozhodujúce: konzistentná rozhodovacia stopa.

Aké riziká sme posúdili? Aké scenáre sme prijali ako realistické? Ako sme zvolili ochranné opatrenia? Ako riadime zraniteľnosti? Ako dlho produkt podporujeme? Ako informujeme zákazníka? CRA nevyžaduje, aby výrobca „hádal budúce EN normy“. Vyžaduje, aby výrobca vedel ukázať, že jeho rozhodnutia neboli náhodné, ale vychádzali z rizika a zo state of the art.

Ako sa reálne pripraviť s produktom na CRA (roadmapa pre výrobcu a integrátora)

Najväčšou hodnotou CRA je to, že vynucuje vyspelosť: kybernetická bezpečnosť prestáva byť doplnkom produktu a stáva sa jeho vlastnosťou. Lenže vyspelosť nevzniká z deklarácií. Vzniká z procesu, ktorý je dostatočne presný, aby fungoval v praxi, a zároveň dostatočne jednoduchý, aby ho inžinierstvo nezačalo obchádzať.

Pri posudzovaní rizík strojov vznikajú najlepšie konštrukčné rozhodnutia vtedy, keď sa prestaneme pýtať „aké nebezpečenstvá má stroj“ a začneme sa pýtať „pri akých úlohách a v akých stavoch je človek vystavený riziku“. Pri CRA je to analogické: prestaneme sa pýtať „aké zraniteľnosti má produkt“ a začneme sa pýtať „za akých podmienok sa produkt stáva zraniteľným a čo vtedy výrobca dokáže urobiť“. Tento posun dáva práci poriadok.

Krok 1: Definujte produkt ako systém (nie ako zariadenie)

Začnite tým, že si určíte, čo je vo vašom prípade „produkt s digitálnymi prvkami“. Nielen hardvér a firmvér, ale aj to, čo sa často vynecháva, lebo sa to nezmestí do krabice: komponenty, knižnice, mechanizmy aktualizácií, služby, bez ktorých produkt neplní svoju funkciu. V CRA je to dôležité, pretože zodpovednosť výrobcu sa týka toho, čo sa uvádza na trh ako produkt — a nie iba toho, čo vyrobilo oddelenie mechaniky.

Je to aj prvý moment, keď by si integrátori mali úprimne priznať: ak integrujete komponenty a konfigurujete ich spôsobom, ktorý v očiach zákazníka vytvára „konečný produkt“, nie ste len „implementátor“. Ste spolutvorcom rizika aj spolutvorcom zodpovednosti.

Krok 2: Urobte posúdenie rizika CRA tak, aby bolo nástrojom rozhodovania

Nejde o „maticu“ na slidoch. Ide o posúdenie rizika, ktoré vedie k projektovým rozhodnutiam a dá sa opakovane uplatniť.

V praxi sa dobrý prístup k CRA začína jednoduchou otázkou: aké sú reálne scenáre zneužitia v prostredí zákazníka, a nie iba v laboratóriu? Kto má servisný prístup? Ako vyzerá sieť? Ako často aktualizujeme? Aké sú dôsledky odstávky? V priemysle sú tieto otázky nepríjemnejšie než v IT, pretože odpovede často znejú: „nemôžeme aktualizovať každý týždeň“ alebo „nemáme telemetriu“. A práve preto ich treba položiť. CRA je právna povinnosť, ale jej dôsledky sú projektové.

Krok 3: Vybudujte „vulnerability handling“ ako výrobný proces, nie ako krízovú reakciu

Požiadavky na nahlasovanie opísané Komisiou (24 h/72 h/14 dní/mesiac) sú neúprosné pre organizáciu, ktorá nemá proces. Ak chcete byť pripravení na 11. septembra 2026, musíte brať „vulnerability handling“ ako súčasť životného cyklu produktu, nie ako „úlohu security tímu“.

To znamená:

• jeden kanál na prijímanie hlásení (CVD policy + kontakt),
• triage, ktorý má vlastníka a kritériá,
• mechanizmus na tvorbu a dodávanie security updates,
• model komunikácie so zákazníkmi, ktorý nie je improvizáciou,
• pripravenosť na reportovanie (kto hlási, s akými údajmi, ako rýchlo).

To všetko znie ako „organizačná“ práca. V praxi je to produktová práca, pretože sa týka verzií, kompatibility, architektúry aktualizácií a stratégie podpory.

Krok 4: Zvoľ obdobie podpory ako biznisové rozhodnutie, nie ako minimálnu požiadavku

Ak tvoje produkty v priemysle fungujú 10–15 rokov, obdobie podpory je strategická vec. CRA vynucuje, aby podpora nebola prísľubom bez reálneho krytia. To znamená, že obdobie podpory má vychádzať z analýzy: ako dlho sa bude produkt používať, ako vyzerá dodávateľský reťazec komponentov, ako dlho budeš schopný dodávať opravy. V praxi obdobie podpory začne „ťahať“ celý ekosystém: zmluvy s dodávateľmi, dostupnosť build environment, udržiavanie toolchainov a dokonca aj rozhodnutia o tom, či má produkt vzdialené funkcie, alebo je izolovaný.

Ak budeš obdobie podpory brať ako formalitu, najneskôr v roku 2027 narazíš na konflikt: zákazník očakáva podporu, no ty už nemáš zdroje ani závislosti, aby si ju vedel dodať. CRA tento problém nevytvára — CRA ho iba odhaľuje.

Krok 5: Usporiadaj dodávateľský reťazec: rozhovor s dodávateľmi je súčasťou zhody

V CRA nie je žiadna „mágia“, ktorá by spôsobila, že externé komponenty budú bezpečné. Ak tvoje zariadenie stojí na knižniciach, komunikačných moduloch, operačnom systéme, SDK alebo hardvérových komponentoch, tvoje riziko je priamo závislé od kvality postupov dodávateľa.

Preto sa už teraz oplatí otvoriť diskusiu o veciach, ktoré neznejú ako marketing, ale ako inžinierstvo:

• či dodávateľ vie informovať o zraniteľnostiach predvídateľným spôsobom,
• aký má reakčný čas,
• či má proces publikovania opráv,
• či dokáže udržať komponent počas obdobia, ktoré je v súlade s tvojím obdobím podpory.

Tu sa CRA naozaj dotýka biznisu: dodávateľ, ktorý nevie zvládať zraniteľnosti, nie je „lacnejší“. Je regulačným rizikom.

Krok 6: Vybuduj dokumentáciu ako súvislú stopu: právo → riziko → rozhodnutie → dôkaz

V auditoch zhody vždy vyhráva konzistentnosť. Ak z posúdenia rizika vyplýva, že dané rozhranie je kritické, a dokumentácia nepopisuje, ako ho zabezpečuješ; ak deklaruješ, že aktualizácie sú bezpečné, no nevieš ukázať, ako zabezpečuješ integritu balíkov; ak hovoríš, že máš proces obsluhy zraniteľností, no nevieš ukázať, ako robíš triedenie hlásení — to nie je „chýbajúci papier“. To je chýbajúci dôkaz, že proces funguje.

V CRA, pri absencii harmonizovaných noriem, je táto stopa obzvlášť dôležitá. Pretože bude základom rozhovoru s orgánom dohľadu nad trhom, enterprise zákazníkom a v niektorých kategóriách produktov aj s jednotkou posudzovania zhody. A čo je rovnako dôležité: bude základom vnútornej stability. Tím vie, prečo niečo robíme, a nie iba „že musíme“.

Záver: CRA ako nová projektová požiadavka, nie „compliance projekt“

Ak by som mal nechať jednu myšlienku, ktorá spája všetky tri časti: CRA nie je problém, ktorý sa rieši na konci. Je to rámec, ktorý mení spôsob uvažovania o produkte. Tak ako ISO 12100 učí, že riziko vzniká vo vzťahu človek–stroj, tak CRA učí, že kybernetická bezpečnosť vzniká vo vzťahu produkt–prostredie–životný cyklus výrobcu.

Harmonizované normy prídu a zjednodušia niektoré postupy. Ich absencia však nie je dôvodom na nečinnosť. Je to dôvod sústrediť sa na to, čo CRA vždy hodnotí: na rozhodnutia, dôkazy a schopnosť fungovať v realite — nie v prezentácii.