Dne 11. září 2026 začíná pro výrobce produktů s digitálními prvky jedna z prvních operativních povinností podle Cyber Resilience Act (CRA): aktivně zneužívané zranitelnosti a závažné bezpečnostní incidenty musí být nahlášeny prostřednictvím nové centrální platformy pro hlášení. Nejde jen o nový termín pro splnění povinností. Během několika hodin je nutné propojit identitu produktu, dotčené trhy, technické posouzení a přijatá opatření.
Digitální produktový pas nebo produktová stránka propojená s QR kódem může pomoci jednoznačně přiřadit zařízení a později informovat uživatele o aktualizaci. Není však zákonným kanálem pro hlášení ani správným úložištěm důvěrných detailů zneužití. Výrobci by proto nyní měli oddělit tři datové cesty: hlášení orgánům, veřejné informace o produktu a interní historii aktualizací.
Nový podnět: pokyny z 27. a 31. července
Evropská komise zveřejnila 27. července 2026 své první komplexní pokyny k CRA. Zabývají se mimo jiné povinnostmi hlášení, hodnocením rizik, obdobími podpory a významnými změnami. Pokyny nejsou závazné, ale na 67 příkladech konkretizují, jak mohou podniky nařízení prakticky uplatňovat.
O čtyři dny později, 31. července, aktualizovala agentura ENISA své informace o Single Reporting Platform. Nyní zde najdete plánovaný postup, zamýšlená vstupní pole a informace k registraci. Platforma má být do 11. září 2026 připravena k provozu; podle Komise již probíhají funkční a bezpečnostní testy.
Časové rozvržení je důležité: hlavní povinnosti podle CRA platí obecně od 11. prosince 2027. Článek 14 s povinnostmi hlášení však platí již od 11. září 2026. Potvrzuje to jak článek 71 nařízení (EU) 2024/2847, tak 31. července aktualizovaný přehled Komise o postupu hlášení podle CRA.
Tři datové prostory namísto jednoho přeplněného produktového pasu
Hlášení podle CRA a veřejná produktová stránka sledují odlišné cíle. Kdo obojí zobrazí v jediném datovém souboru, riskuje buď nedostatek informací pro incidentový tým, nebo příliš mnoho citlivých údajů ve veřejném webu.
1. Důvěrné hlášení platformám SRP, CSIRT a ENISA
Single Reporting Platform je zákonným vstupním kanálem. Je nutné hlásit dva typy událostí: aktivně zneužívanou zranitelnost, u níž existují spolehlivé indicie neoprávněného zneužití, a závažný incident, který narušuje dostupnost, autenticitu, integritu nebo důvěrnost dat či funkcí.
Hlášení neobsahuje pouze označení produktu. ENISA mezi poli uvádí mimo jiné dotčené členské státy, první posouzení, již přijatá protiopatření, možná opatření uživatelů a citlivost informace. Pozdější fáze mohou obsahovat závažnost, dopady, informace o útočníkovi a technické podrobnosti bezpečnostní aktualizace. Takové informace automaticky nepatří na volně dostupnou DPP-stránku.
2. Veřejné informace o produktu a bezpečnosti
Veřejná datová cesta odpovídá na jiné otázky: Jaký produkt a jakou verzi mám? Je stále podporována? Je k dispozici bezpečnostní aktualizace? Co mám jako uživatel konkrétně udělat? K tomu může být vhodná stabilní produktová stránka přístupná prostřednictvím QR kódu nebo jiného nosiče dat.
Veřejná stránka by měla zobrazovat pouze schválené informace: dotčené rozsahy modelů a verzí, dostupnou bezpečnou verzi, pokyny k instalaci, kontakt podpory a datum zveřejnění. Podrobnosti o zneužití, interní pravidla detekce, neopravené způsoby útoku nebo osobní údaje o incidentu zůstávají v chráněném procesu. O zveřejnění varování nerozhoduje QR kód: podle článku 17 CRA může koordinující CSIRT informovat veřejnost nebo k tomu výrobce vyzvat, pokud je to nezbytné pro prevenci či omezení dopadů.
3. Interní historie aktualizací a podkladů
Třetí cestou je dohledatelný pracovní záznam. Propojuje ID produktu, hardwarovou a softwarovou verzi, seznam softwarových komponent, okamžik získání informace, rozhodnutí v rámci triáže, úrovně hlášení, schválení opravy a veřejné oznámení. Tato historie musí změny verzovat, nikoli starší posouzení tiše přepisovat.
Pro provoz DPP je tento rozdíl zásadní: veřejné zobrazení ukazuje aktuální schválený stav, zatímco interní historie dokládá, jak vznikl. Kdo již produktová data spravuje na základě událostí, může použít stejný princip jako u DPP-aktualizací a webhooků: událost spustí navazující procesy, ale každý příjemce obdrží pouze pole určená pro jeho roli.
Hodiny podle CRA začínají běžet okamžikem získání informace
Článek 14 pracuje s odstupňovanými lhůtami. U aktivně zneužívané zranitelnosti je bez zbytečného odkladu, nejpozději do 24 hodin od zjištění, nutné zaslat předběžné varování. Do 72 hodin následuje podrobnější hlášení zranitelnosti. Závěrečná zpráva musí být k dispozici nejpozději do 14 dnů od zpřístupnění nápravného nebo zmírňujícího opatření.
U závažného bezpečnostního incidentu platí pro předběžné varování rovněž lhůta 24 hodin a pro hlášení incidentu 72 hodin. Závěrečná zpráva následuje do jednoho měsíce od 72hodinového hlášení. Lhůty tedy nezačínají zveřejněním CVE ani vydáním další standardní verze, ale okamžikem, kdy se má za to, že výrobce získal potřebné informace.
V praxi se doporučuje jasný postup:
- Zaznamenat přijetí ze supportu, monitoringu, výzkumu nebo dodavatelského řetězce s časovým razítkem.
- Přiřadit produkt a verzi ke stabilnímu internímu ID produktu.
- Posoudit zneužití, respektive závažnost incidentu příslušným týmem.
- Vytvořit 24hodinový datový soubor z potvrzených minimálních údajů a odeslat jej prostřednictvím SRP.
- Doplnit technické poznatky do 72hodinové fáze, aniž by se ztratil původní stav.
- Samostatně schválit opravu, opatření pro uživatele a veřejné informace.
- Propojit závěrečnou zprávu s interní historií.
Tento řetězec by měl být před zářím procvičen. ENISA upozorňuje, že organizace mohou automatizovat své interní postupy a databáze, platforma však při spuštění nebude nabízet API. Realističtější je proto export a proces kontroly dvěma osobami než neprověřená přímá integrace.
Jedno společné ID produktu, ale oddělená přístupová práva
Oddělení neznamená udržovat tři nepropojené kopie. Lepším přístupem je společná neměnná reference produktu s pohledy závislými na roli.
Měly by být k dispozici přinejmenším tyto vazby:
- interní ID produktu a vazba na model, šarži nebo sérii;
- hardwarová, firmwarová a softwarová verze;
- členské státy, v nichž byla dotčená varianta dodávána;
- stav bezpečnostního posouzení a okamžik získání informace;
- odkazy na 24hodinové a 72hodinové hlášení a závěrečnou zprávu;
- schválené opatření pro uživatele a bezpečná cílová verze;
- stav zveřejnění veřejné produktové stránky.
Autorizaci je třeba navrhnout na úrovni jednotlivých polí. Incidentový tým a osoby odpovědné za CRA potřebují úplný záznam. Podpora a obchod potřebují schválené pokyny k postupu. Uživatelé vidí pouze veřejné oznámení. QR kód by v ideálním případě měl přenášet pouze stabilní adresu produktu; platforma v pozadí podle stavu a role rozhodne, jaké informace poskytne.
Co by měli výrobci do září otestovat
Vhodný testovací případ nepotřebuje skutečnou zranitelnost. Vyberte propojený produkt, dotčenou verzi firmwaru a tři členské státy. Simulujte získání informace v pracovní den a ověřte:
- Dokáže tým do 24 hodin potvrdit pokrytí produktu a minimální údaje?
- Je jasné, kdo má jako zástupce přistupovat k SRP prostřednictvím EU Login?
- Lze doplnit 72hodinové informace, aniž by se důvěrné podrobnosti dostaly na veřejnost?
- Vede schválení opravy k ověřeným informacím pro uživatele ve všech požadovaných jazycích?
- Zůstane veřejná URL stabilní, když se změní verze a opatření?
- Je dohledatelné, kdo který stav kdy schválil?
U posledního bodu pomáhá důsledná správa verzovaných dat. Příspěvek qr3 o průběžné DPP aktualizaci ukazuje základní myšlenku: identita zůstává stabilní, zatímco odborná data se kontrolovaně průběžně doplňují. V procesu CRA k tomu přistupuje přísnější vrstva důvěrnosti a schvalování.
Závěr: Produktový pas je distribuční nástroj, nikoli místo pro hlášení
Nové pokyny činí zářijový termín konkrétním z hlediska praxe. Výrobci nemusí do svého digitálního produktového pasu zabudovat důvěrnou databázi zranitelností. Potřebují především spolehlivé propojení tří jasně oddělených oblastí: hlášení orgánům, interní podklady a schválené informace pro uživatele.
Společné ID produktu tyto oblasti propojuje. Role, schvalování a verzování zabraňují úniku důvěrných podrobností nebo tomu, aby se uživatelé o dostupném opatření dozvěděli příliš pozdě. QR kód tak zůstává užitečný, ale záměrně nenápadný: trvale vede ke správnému kontextu produktu. Skutečný soulad s CRA vzniká v procesech na pozadí.
