septembra 2026 sa pre výrobcov produktov s digitálnymi prvkami začína jedna z prvých praktických povinností aktu o kybernetickej odolnosti (CRA): Aktívne zneužívané zraniteľnosti a závažné bezpečnostné incidenty sa musia oznámiť prostredníctvom novej centrálnej oznamovacej platformy. To je viac než nový termín na splnenie požiadaviek. V priebehu niekoľkých hodín treba spojiť identitu produktu, dotknuté trhy, technické posúdenie a prijaté opatrenia.
Digitálny produktový pas alebo produktová stránka prepojená s QR kódom môže pomôcť jednoznačne priradiť zariadenie a neskôr informovať používateľov o aktualizácii. Nie je však zákonným oznamovacím kanálom ani správnym miestom na uchovávanie dôverných podrobností o exploite. Výrobcovia by preto už teraz mali oddeliť tri dátové cesty: hlásenie orgánom, verejné informácie o produkte a internú históriu aktualizácií.
Nový podnet: usmernenia z 27. a 31. júla
Európska komisia zverejnila 27. júla 2026 svoje prvé komplexné usmernenie k CRA. Zaoberá sa okrem iného povinnosťami oznamovania, hodnotením rizík, obdobiami podpory a podstatnými zmenami. Usmernenie nie je záväzné, ale na 67 príkladoch konkretizuje, ako môžu podniky nariadenie uplatňovať v praxi.
O štyri dni neskôr, 31. júla, ENISA aktualizovala svoje informácie o Single Reporting Platform. Nachádza sa tam už plánovaný postup, zamýšľané vstupné polia a pokyny k registrácii. Platforma má byť do 11. septembra 2026 pripravená na prevádzku; podľa Komisie už prebiehajú funkčné a bezpečnostné testy.
Časové rozvrhnutie je dôležité: Hlavné povinnosti CRA platia v zásade od 11. decembra 2027. Článok 14 s povinnosťami oznamovania však platí už od 11. septembra 2026. Potvrdzuje to článok 71 nariadenia (EÚ) 2024/2847, ako aj 31. júla aktualizovaný prehľad Komisie o postupe oznamovania podľa CRA.
Tri dátové priestory namiesto jedného preťaženého produktového pasu
Hlásenie podľa CRA a verejná produktová stránka sledujú odlišné ciele. Kto ich zobrazí v jedinom súbore údajov, riskuje buď nedostatok informácií pre incidentový tím, alebo priveľa citlivých podrobností na verejnom webe.
1. Dôverné hlásenie pre SRP, CSIRT a ENISA
Single Reporting Platform je zákonným vstupným kanálom. Oznamovať sa musia dva typy udalostí: aktívne zneužívaná zraniteľnosť, pri ktorej existujú spoľahlivé náznaky neoprávneného zneužitia, a závažný incident, ktorý narúša dostupnosť, autentickosť, integritu alebo dôvernosť údajov či funkcií.
Hlásenie neobsahuje iba označenie produktu. ENISA medzi poľami uvádza okrem iného dotknuté členské štáty, prvotné hodnotenie, už prijaté protiopatrenia, možné opatrenia používateľov a citlivosť informácie. Neskoršie fázy môžu obsahovať stupeň závažnosti, vplyvy, informácie o útočníkovi a technické podrobnosti o bezpečnostnej aktualizácii. Takéto informácie automaticky nepatria na voľne dostupnú stránku typu DPP.
2. Verejné informácie o produkte a bezpečnosti
Verejná dátová cesta odpovedá na iné otázky: Ktorý produkt a verziu mám? Je ešte podporovaná? Je k dispozícii bezpečnostná aktualizácia? Čo mám ako používateľ konkrétne urobiť? Na tento účel môže byť vhodná stabilná produktová stránka prístupná cez QR kód alebo iný nosič údajov.
Verejná stránka by mala zobrazovať iba schválené informácie: dotknuté rozsahy modelov a verzií, dostupnú bezpečnú verziu, pokyny na inštaláciu, kontakt podpory a čas zverejnenia. Podrobnosti o exploite, interné pravidlá detekcie, nezaplátané cesty útoku alebo osobné údaje o incidente zostávajú v chránenom postupe. O verejnom varovaní nerozhoduje QR kód: Podľa článku 17 CRA môže koordinujúci CSIRT informovať verejnosť alebo na to vyzvať výrobcu, ak je to potrebné na prevenciu alebo obmedzenie incidentu.
3. Interná história aktualizácií a dôkazov
Tretia cesta predstavuje dohľadateľný pracovný spis. Spája ID produktu, hardvérovú a softvérovú verziu, kusovník softvéru, čas získania informácie, rozhodnutia v rámci triedenia, fázy oznamovania, schválenie opravy a verejné oznámenie. Táto história musí zmeny verzovať, nie potichu prepisovať staršie hodnotenia.
Pre prevádzku typu DPP je tento rozdiel zásadný: Verejné zobrazenie ukazuje aktuálny schválený stav; interná história dokladá, ako vznikol. Kto už údaje o produktoch spravuje na základe udalostí, môže použiť rovnaký princíp ako pri DPP aktualizáciách a webhookoch: Udalosť spustí následné procesy, no každý príjemca dostane iba polia určené pre jeho úlohu.
Hodiny CRA sa začínajú vedomosťou
Článok 14 pracuje s odstupňovanými lehotami. Pri aktívne zneužívanej zraniteľnosti je bez zbytočného odkladu, najneskôr do 24 hodín od získania vedomosti, potrebné skoré varovanie. Do 72 hodín nasleduje podrobnejšie hlásenie zraniteľnosti. Záverečná správa je k dispozícii najneskôr do 14 dní od chvíle, keď je dostupné nápravné alebo zmierňujúce opatrenie.
Pri závažnom bezpečnostnom incidente platí pre skoré varovanie aj hlásenie incidentu takisto lehota 24 a 72 hodín. Záverečná správa nasleduje do jedného mesiaca od 72-hodinového hlásenia. Lehoty teda nezačínajú plynúť zverejnením CVE ani ďalším riadnym vydaním, ale okamihom, keď sa výrobca považuje za informovaného.
V praxi sa odporúča jasný postup:
- Zaznamenať prijatie podnetu z podpory, monitoringu, výskumu alebo dodávateľského reťazca s časovou pečiatkou.
- Priradiť produkt a verziu k stabilnému internému ID produktu.
- Príslušným tímom vyhodnotiť zneužitie, respektíve závažnosť incidentu.
- Vytvoriť 24-hodinový záznam z potvrdených minimálnych údajov a odoslať ho prostredníctvom SRP.
- Doplniť technické poznatky do 72-hodinovej fázy bez straty pôvodného stavu.
- Oddelene schváliť opravu, opatrenie pre používateľov a verejnú informáciu.
- Prepojiť záverečnú správu s internou históriou.
Tento reťazec by sa mal pred septembrom precvičiť. ENISA upozorňuje, že organizácie môžu automatizovať svoje interné postupy a databázy, no platforma pri spustení nebude ponúkať API. Preto je exportný proces so zásadou štyroch očí realistickejší než nekontrolovaná priama integrácia.
Spoločné ID produktu, ale oddelené prístupové práva
Oddelenie neznamená spravovať tri neprepojené kópie. Lepším prístupom je spoločná, nemenná referencia produktu s pohľadmi podľa rolí.
K dispozícii by mali byť prinajmenšom tieto priradenia:
- interné ID produktu a väzba na model, šaržu alebo sériu;
- hardvérová, firmvérová a softvérová verzia;
- členské štáty, v ktorých bola dotknutá verzia sprístupnená;
- stav bezpečnostného hodnotenia a čas získania vedomosti;
- odkazy na 24- a 72-hodinové hlásenie a záverečnú správu;
- schválené opatrenie pre používateľov a bezpečná cieľová verzia;
- stav zverejnenia verejnej produktovej stránky.
Autorizáciu treba chápať na úrovni jednotlivých polí. Incidentový tím a osoby zodpovedné za CRA potrebujú úplný spis. Podpora a obchod potrebujú schválený návod na postup. Používatelia vidia iba verejné oznámenie. QR kód by v ideálnom prípade mal prenášať iba stabilnú adresu produktu; platforma na pozadí podľa stavu a roly rozhodne, ktoré informácie poskytne.
Čo by mali výrobcovia do septembra otestovať
Vhodný testovací prípad nepotrebuje skutočnú zraniteľnosť. Vyberte sieťovo prepojený produkt, dotknutú verziu firmvéru a tri členské štáty. Simulujte získanie vedomosti počas pracovného dňa a overte:
- Dokáže tím do 24 hodín potvrdiť pokrytie produktu a minimálne údaje?
- Je jasné, kto má ako zástupca pristupovať k SRP prostredníctvom EU Login?
- Možno doplniť 72-hodinové informácie bez zverejnenia dôverných podrobností?
- Vedie schválenie opravy k overeným informáciám pre používateľov vo všetkých požadovaných jazykoch?
- Zostane verejná URL stabilná, keď sa zmení verzia a opatrenia?
- Je dohľadateľné, kto, čo a kedy schválil?
Pri poslednom bode pomáha dôsledná správa údajov s verziami. Príspevok qr3 o priebežnej DPP aktualizácii ukazuje základnú myšlienku: Identita zostáva stabilná, zatiaľ čo odborné údaje sa kontrolovane priebežne aktualizujú. V procese CRA k tomu pribúda prísnejšia vrstva dôvernosti a schvaľovania.
Záver: Produktový pas je distribútor, nie oznamovacie miesto
Nové usmernenia dávajú septembrovému termínu konkrétnu praktickú podobu. Výrobcovia nemusia do svojho digitálneho produktového pasu zabudovať dôvernú databázu zraniteľností. Potrebujú skôr spoľahlivé prepojenie medzi tromi jasne oddelenými oblasťami: hlásením orgánom, internými dôkazmi a schválenými informáciami pre používateľov.
Spoločné ID produktu tieto oblasti spája. Roly, schvaľovanie a verzovanie zabraňujú tomu, aby sa dôverné podrobnosti dostali navonok alebo aby sa používatelia o dostupnom opatrení dozvedeli neskoro. QR kód zostáva užitočný, ale zámerne nenápadný: Trvalo vedie k správnemu kontextu produktu. Skutočný súlad s CRA vzniká v procesoch, ktoré prebiehajú na pozadí.
