Prvá vymáhateľná povinnosť Cyber Resilience Actu nezačína v decembri 2027, ale o niekoľko týždňov. Týka sa aj produktov, ktoré máte na trhu roky. A pre mnohých výrobcov nebude problémom samotné hlásenie, ale proces, ktorý mu musí predchádzať.

Keď sa v slovenských firmách hovorí o Cyber Resilience Acte, najčastejšie sa spomína jeden dátum: 11. december 2027. Vtedy začne nariadenie platiť v plnom rozsahu – CE označenie, technická dokumentácia a posúdenie zhody.

Článok 14 však začína platiť už 11. septembra 2026. A na rozdiel od zvyšku CRA sa netýka len nových produktov. Podľa článku 69 ods. 3 sa ohlasovacie povinnosti vzťahujú aj na produkty s digitálnymi prvkami, ktoré boli uvedené na trh pred 11. decembrom 2027.

Ak ste si prípravu na CRA naplánovali až na budúci rok, článok 14 tento plán mení. Ak si chcete najprv ujasniť, či váš produkt vôbec spadá pod CRA, začnite naším kompletným prehľadom nariadenia.

Čo podlieha ohlasovacej povinnosti

Článok 14 zavádza dve samostatné ohlasovacie povinnosti, pričom obe sa vzťahujú na výrobcu. Nie na zákazníka ani na prevádzkovateľa. Dovozca a distribútor, ktorí sa o probléme dozvedia, informujú výrobcu. Samotné hlásenie však nepodávajú a 24-hodinová lehota sa na nich nevzťahuje.

• Aktívne zneužívaná zraniteľnosť – zraniteľnosť vo vašom produkte, pri ktorej existuje spoľahlivý dôkaz, že ju útočník zneužil v systéme bez súhlasu jeho vlastníka.

   

• Závažný incident s vplyvom na bezpečnosť produktu – napríklad kompromitácia vývojového, výrobného alebo distribučného prostredia, keď sa útočníkovi podarí dostať škodlivý kód do distribučného kanála alebo do podpisového reťazca. Nejde o incident u zákazníka, ale o incident u výrobcu, ktorý zvyšuje riziko pre používateľov produktu.

V určitých prípadoch sa obdobné povinnosti vzťahujú aj na správcov open source softvéru podľa článku 24, a to v rozsahu ich zapojenia do vývoja dotknutých produktov.

Čo naopak povinnosť nespúšťa

Samotný nález bezpečnostného výskumníka, proof of concept ani vysoké CVSS skóre automaticky neznamenajú povinnosť podľa článku 14. Nariadenie odlišuje zraniteľnosť, ktorá existuje, od zraniteľnosti, ktorá je zneužívaná. Rozhodujúcim kritériom je spoľahlivý dôkaz o reálnom zneužití, nie závažnosť samotnej chyby. Bežná zraniteľnosť ohlásená cez váš CVD kanál a opravená v riadnom patch cykle sa nehlási.

Znie to ako úľava, ale je to najnáročnejšia časť povinnosti. Práve preto, že rozhoduje otázka zneužitia, musíte byť schopní ju zodpovedať - a to nie je právna otázka, ale otázka detekčnej a analytickej schopnosti.

Tri lehoty, dva rôzne štarty

Rozdiel v záverečnej správe má priamy dôsledok na plánovanie. Pri zraniteľnosti si 14 dní spúšťate sami tým, že vydáte opravu. Pri incidente beží mesiac bez ohľadu na to, kde ste s riešením.

A čo používatelia?

Ohlásenie orgánom nie je jediná povinnosť a je to jedna z vecí, ktoré sa v obsahu o CRA pravidelne strácajú.

Po tom, čo sa výrobca dozvie o aktívne zneužitej zraniteľnosti alebo o závažnom incidente, musí zároveň bez zbytočného odkladu informovať dotknutých používateľov a podľa potreby aj používateľov všeobecne o probléme a o opatreniach, ktoré môžu prijať na zmiernenie rizika. V praxi to znamená, že popri hlásení musíte mať pripravený aj komunikačný kanál smerom k zákazníkom a text, ktorý cezeň pôjde.

Ako funguje ohlasovanie prostredníctvom platformy ENISA

Hlási sa raz, cez jednotnú platformu na ohlasovanie (Single Reporting Platform), ktorú podľa článku 16 zriaďuje agentúra ENISA. Jedno podanie smeruje súčasne k CSIRT určenému ako koordinátor a k ENISA - nemusíte teda obiehať národné orgány v každom štáte, kde produkt predávate. Pri podaní označíte členské štáty, v ktorých je dotknutý produkt dostupný, a koordinujúci CSIRT informáciu ďalej rozšíri relevantným CSIRT v týchto štátoch.

Príslušný CSIRT je ten v členskom štáte vašej hlavnej prevádzkarne, teda tam, kde sa predovšetkým prijímajú rozhodnutia súvisiace s kybernetickou bezpečnosťou vašich produktov. Ak to nemožno určiť, nastupuje kritérium prevádzkarne s najvyšším počtom zamestnancov v EÚ. Pre výrobcov bez hlavného miesta podnikateľskej činnosti v Únii stanovuje nariadenie osobitné pravidlá.

Za výnimočných okolností môže byť na žiadosť výrobcu a z odôvodnených kyberneticko-bezpečnostných dôvodov odložené ďalšie šírenie oznámenia relevantným CSIRT. Je to vec, ktorú má zmysel poznať vopred, nie ju riešiť pod tlakom.

Praktická poznámka, ktorú väčšina článkov vynecháva

Platforma v čase písania tohto textu ešte nebola v prevádzke. ENISA potvrdila, že bude funkčná k 11. septembru 2026, pred spustením prebieha testovanie a v priebehu leta 2026 zverejnila k platforme prvé návody. Verejná adresa má byť oznámená pred spustením.

Pre vás z toho vyplýva jedna vec: nástroj nie je to, na čo treba čakať. Proces, ktorý ho bude napĺňať, si viete postaviť už teraz - a práve ten rozhoduje, či 24 hodín stihnete. ENISA aktuálne uvádza, že prístup na platformu bude založený na účte EU Login, ktorý je možné si vytvoriť vopred.

Prečo 24 hodín nie je len administratívna lehota

Lehota 24 hodín sa môže na prvý pohľad zdať dostatočná. V praxi však výrobca musí v tomto čase zvládnuť niekoľko krokov, ktoré si vyžadujú technické aj organizačné rozhodnutia.

1. Zistiť, že sa niečo stalo. Informácia môže prísť z monitoringu, prostredníctvom threat intelligence, od zákazníka alebo od bezpečnostného výskumníka. Bez politiky koordinovaného zverejňovania zraniteľností (CVD) a funkčného kontaktného miesta sa k nej firma často dostane neskoro.
2. Overiť, či sa problém týka konkrétneho produktu. Ktoré verzie sú dotknuté? Je zraniteľná knižnica súčasťou produktu? Bez aktuálneho SBOM môže byť odpoveď na tieto otázky časovo náročná.
3. Posúdiť, či ide o aktívne zneužívanie zraniteľnosti. Rozhodujúcou otázkou nie je závažnosť chyby, ale existencia spoľahlivého dôkazu o jej zneužití. Takéto posúdenie si vyžaduje technickú expertízu.
4. Prijať rozhodnutie o nahlásení. Mnohé firmy nemajú jasne určené, kto za toto rozhodnutie zodpovedá. Má ho prijať vývojový tím, produktový manažér, právne oddelenie alebo vedenie spoločnosti?
5. Pripraviť hlásenie a informovať používateľov. Okrem samotného podania je potrebné zabezpečiť aj komunikáciu smerom k zákazníkom a pripraviť odporúčania na zmiernenie rizika.

Kritickým bodom je krok 3. Aby ste dokázali posúdiť, či ide o aktívne zneužívanie zraniteľnosti, musíte mať prehľad o tom, čo sa vo vašom produkte deje. Rozlíšiť existujúcu zraniteľnosť od jej skutočného zneužitia je technická úloha, nie otázka compliance.

Čo pri testoch produktov vidíme

Podľa našich skúseností z penetračného testovania IoT zariadení obsahuje takmer každé testované zariadenie aspoň jednu zraniteľnosť klasifikovanú ako high alebo critical - najčastejšie pevne zakódované prihlasovacie údaje vo firmvéri, nešifrovanú komunikáciu s cloudom, otvorené ladiace rozhrania alebo aktualizácie bez overovania podpisu. Podrobne sme to popísali v článku o bezpečnosti inteligentnej zásuvky.

Do 11. septembra sú to technické nálezy. Od 11. septembra platí, že pri náleze, pri ktorom získate spoľahlivý dôkaz o jeho aktívnom zneužití, začína plynúť 24-hodinová lehota.

Pozor na výnimku pri sankciách

Porušenie článku 14 spadá do najvyššieho sankčného pásma CRA – až 15 miliónov eur alebo 2,5 % celosvetového ročného obratu. Nariadenie však obsahuje dve úzke výnimky:

• Mikropodnikom a malým podnikom nemožno uložiť pokutu za nedodržanie lehoty na včasné varovanie podľa článku 14 ods. 2 písm. a) a ods. 4 písm. a). Netýka sa to 72-hodinového oznámenia, záverečnej správy ani samotnej ohlasovacej povinnosti - tá platí rovnako.
• Správcom open source softvéru sa podľa nariadenia nemá uložiť pokuta za porušenie nariadenia. Ich povinnosti podľa článku 24 tým nezanikajú.

Čo stihnúť do septembra

• Zoznam produktov v rozsahu. Čo máte sprístupnené na trhu EÚ, ktoré verzie sú stále v obehu a ktoré z nich už nevyvíjate, ale stále ich predávate.
• Určené zodpovednosti a eskalačná cesta. Kto rozhoduje o hlásení, kto ho podáva, kto zastupuje zodpovednú osobu a ako sa postupuje mimo pracovného času.
• CVD politika a jednotné kontaktné miesto. Kanál, cez ktorý sa k vám informácia vôbec dostane. Nesmie sa spoliehať len na automatizované nástroje.
• SBOM aspoň pre závislosti najvyššej úrovne. Nie kvôli dokumentácii, ale preto, aby ste vedeli rýchlo posúdiť, či sa vás konkrétna zraniteľnosť týka.
• Triáž zraniteľností a schopnosť overiť zneužitie. Kto a ako posúdi, či ide o aktívne zneužitie, a na základe akých dôkazov.
• Príprava podania a komunikácie. Prístup na platformu vytvorený vopred, pripravená šablóna hlásenia a spôsob komunikácie s používateľmi.
• Nacvičte si to. Jedno tabletop cvičenie so scenárom „našu zraniteľnosť niekto zneužíva“ odhalí o pripravenosti viac než audit dokumentácie.

Časté otázky

Musíme hlásiť nález od bezpečnostného výskumníka?

Nie, ak ide len o nález. Povinnosť podľa článku 14 spúšťa spoľahlivý dôkaz o tom, že zraniteľnosť je aktívne zneužívaná. Samotný nález, proof of concept ani vysoké CVSS skóre hlásenie automaticky nespúšťajú.

Vzťahuje sa povinnosť aj na náš starší produkt?

Áno. Ohlasovacie povinnosti sa vzťahujú aj na produkty, ktoré boli uvedené na trh pred 11. decembrom 2027, pokiaľ sú stále sprístupnené na trhu EÚ.

Hlásime my, alebo náš distribútor?

Vy. Povinnosť podľa článku 14 nesie výrobca. Dovozca a distribútor, ktorí sa o zraniteľnosti dozvedia, informujú výrobcu.

Čo ak platforma ENISA nebude v deň incidentu dostupná?

Lehoty stanovuje nariadenie a začínajú plynúť od chvíle, keď sa o udalosti dozviete. Preto sa oplatí vytvoriť si prístup vopred, mať pripravený obsah hlásenia a sledovať oficiálne informácie agentúry ENISA.

Sme malý podnik. Musíme hlásiť tiež?

Áno. Mikropodnikom a malým podnikom sa nemá uložiť pokuta za nedodržanie lehoty na včasné varovanie. Samotná ohlasovacia povinnosť sa však na ne vzťahuje rovnako ako na ostatných výrobcov.

Záver

Rozdiel medzi oboma termínmi CRA je jednoduchý: december 2027 je o schopnosti preukázať súlad, september 2026 o schopnosti reagovať. Kto stihne to druhé, má veľkú časť prvého hotovú. Inventár produktov, SBOM aj proces zvládania zraniteľností sú totiž spoločné pre obe povinnosti.

Kompletný prehľad povinností, kategórií produktov a termínov nájdete v našom článku o Cyber Resilience Acte.

Ak si chcete nezávisle overiť bezpečnosť svojho produktu a pripravenosť na požiadavky CRA, ozvite sa nám. Testujeme firmvér a hardvérové rozhrania, mobilné, webové a API rozhrania, cloudový backend, mechanizmy autentifikácie a aktualizácie aj zraniteľnosti v komponentoch tretích strán.

Právna poznámka: Tento článok slúži len na informačné účely a nepredstavuje právne poradenstvo.