V pátek 11. září 2026 začne v celé EU platit povinnost, o které většina českých firem netuší, že se jich týká: kdo prodává jakýkoli software nebo připojitelné zařízení, musí od toho dne hlásit aktivně zneužívané zranitelnosti a závažné incidenty do 24 hodin — a jde to i na produkty, které uvedl na trh dávno předtím. Sankce za nesplnění je až 15 milionů eur nebo 2,5 % celosvětového obratu. Nejde o AI Act, ale o Cyber Resilience Act, jehož zbytek platí až od prosince 2027 — a právě proto to spousta firem odložila jako „ještě rok a půl čas". Ověřil jsem to v Úředním věstníku, ve výkladu Komise z 27. července a v dokumentaci ENISA. Jednu věc jsem přitom zjistil, kterou nikde nepíšou: portál, přes který se má hlásit, mi tři dny před startem vůbec neodpověděl.
Co se stalo
- Datum je v samotném nařízení, ne v novinovém článku. Článek 71 nařízení (EU) 2024/2847 (Cyber Resilience Act) říká doslova: „This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026." Článek 14 jsou přesně ty hlásicí povinnosti. Nařízení bylo přijato 23. října 2024 ve Štrasburku a v platnost vstoupilo 10. prosince 2024.
- Tři lhůty, ne jedna. Podle článku 14(2) a 14(4) musí výrobce podat včasné varování do 24 hodin od okamžiku, kdy se o věci dozví; plné oznámení do 72 hodin s popisem produktu, povahy zneužití a přijatých opatření; a závěrečnou zprávu — u zranitelností „no later than 14 days after a corrective or mitigating measure is available", u závažných incidentů do jednoho měsíce od 72hodinového hlášení.
- Platí to i na staré produkty. Tohle je ta část, která firmy překvapí nejvíc. Výklad Komise z 27. července 2026 (dokument C(2026) 5252 final, příloha, bod 210) uvádí: „the obligation to comply with Article 14 applies from 11 September 2026 to all products with digital elements that fall within the scope of the CRA, including products with digital elements placed on the market before 11 December 2027." A dodává, že „the reporting obligations continue to apply after a product with digital elements is no longer supported" — tedy i na produkt, kterému už skončila podpora.
- Sankce nejsou symbolické. Článek 64(2) nařízení: nedodržení povinností podle článků 13 a 14 „shall be subject to administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 % of the its total worldwide annual turnover for the preceding financial year, whichever is higher." (Ten překlep „of the its" je skutečně v úředním znění.)
- Co se hlásí. Aktivně zneužívaná zranitelnost je podle článku 3(42) taková, u které „there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". Incident je podle článku 14(5) závažný, když negativně ovlivňuje schopnost produktu chránit dostupnost, autenticitu, integritu nebo důvěrnost citlivých dat či funkcí, nebo když vedl či mohl vést k zavedení nebo spuštění škodlivého kódu.
- Hlásí se jednou, přes evropský portál. Podle článku 16 zřizuje ENISA jednotnou hlásicí platformu (Single Reporting Platform). ENISA ve svém FAQ uvádí adresu
portal.cra-srp.enisa.europa.eu, přihlášení přes účet EU Login s dvoufaktorovým ověřením a to, že „the platform is scheduled to be operational from 11 September 2026".
Tři věci, které jsem našel u zdroje a v přehledech nejsou
1. Hlásicí portál mi tři dny před startem neodpověděl. Zkusil jsem 8. září 2026 dopoledne načíst https://portal.cra-srp.enisa.europa.eu. TCP spojení na port 443 se naváže, ale HTTPS požadavek vyprší bez odpovědi — vyzkoušeno opakovaně ze dvou různých sítí, s časovým limitem 25 i 40 sekund. Zajímavý je i DNS záznam: doména je přesměrovaná přes wedos.global na adresy 185.8.236.7 a 185.8.236.8, což je podle databáze RIPE rozsah WEDOS-GLOBAL-ANYCAST, tedy anycast síť českého hostingu WEDOS — zatímco hlavní web ENISA běží přes CloudFront. Neberte to jako tvrzení, že platforma nebude fungovat; ENISA sama píše, že „functional and security testing are under way", a do pátku zbývají tři dny. Berte to jako důvod netestovat registraci až v okamžiku, kdy vám bude běžet 24hodinová lhůta.
2. Zpětně se nehlásí, ale pozor na formulaci. Výklad Komise (bod 217) říká, že se nemusí hlásit zranitelnost, o jejímž aktivním zneužívání firma věděla už před 11. zářím. Ale: „the obligation does apply where the manufacturer was aware of a vulnerability before 11 September 2026 but was not, at that time, aware of any active exploitation of it." Když tedy máte v šuplíku známou neopravenou díru a někdo ji začne zneužívat v říjnu, běží lhůta od okamžiku, kdy se o zneužívání dozvíte. Stáří zranitelnosti vás nechrání.
3. Registrace na portálu trvá minuty, ale schválení dělá CSIRT. Podle FAQ ENISA (bod 9) se firma na portál registruje přes tzv. Assigned Representative — jednoho hlavního a až dvacet vedlejších. Tuhle vazbu pak validuje národní CSIRT a ENISA výslovně píše, že „the specific validation procedure and processing time may vary between CSIRTs". Dobrá zpráva: validace neblokuje hlášení, nevalidovaný zástupce může podat až 20 oznámení. Špatná: potřebujete osobní účet EU Login s dvoufaktorovým ověřením, což není věc, kterou v sobotu ve tři ráno vyřídíte za pět minut. A ještě jedna praktická věc — API na začátku nebude, hlásí se ručně přes rozhraní.
Proč se to týká i vás
Většina českých firem si řekne „my nejsme výrobce softwaru". Zkontrolujte si to, definice je širší, než čekáte. Podle článku 3(1) je produktem s digitálními prvky „a software or hardware product and its remote data processing solutions" — a FAQ Komise to rozepisuje na samostatnou aplikaci ke stažení, mobilní aplikaci v obchodě, firmware určený k vestavění do hardwaru, ovladače dodávané s tiskárnou i běžný spotřební hardware.
- Prodáváte mobilní nebo desktopovou aplikaci? Jste výrobce. Platí to i na aplikaci, kterou vám kdysi udělal externí dodavatel a která je pod vaší značkou v App Storu.
- Vyrábíte stroj, senzor nebo zařízení s firmwarem a připojením? Jste výrobce. FAQ výslovně jmenuje průmyslové IoT, stroje, senzory i desky.
- Provozujete SaaS? Tady pozor na nuanci, kterou přehledy zjednodušují. Samostatná SaaS nebo cloudová služba vyvinutá mimo odpovědnost výrobce produktu není produktem s digitálními prvky. Do působnosti spadá až tehdy, když jde o „remote data processing" podle článku 3(2) — tedy zpracování na dálku, bez kterého by váš produkt nezvládl některou ze svých funkcí. Backend vaší mobilní aplikace tedy typicky ano, samostatný webový nástroj bez produktu typicky ne. Komise sama píše, že tenhle pojem dostane vlastní výklad, takže tady je legitimní odpověď „zatím není úplně jasno".
- Zranitelnost je v cizí komponentě? Hlásíte ji stejně vy, pokud je zneužitelná ve vašem produktu (bod 218 výkladu). Když zneužitelná není — třeba proto, že se na ten kód ve vašem produktu vůbec nedá dosáhnout — povinné hlášení není, ale musíte to nahlásit dodavateli komponenty podle článku 13(6).
- Jen software přeprodáváte nebo používáte? Pak vás článek 14 netíží. Povinnost leží na výrobci.
Souvislost s AI je jednodušší, než by se zdálo: pokud váš produkt obsahuje AI komponentu nebo volá model, je to pořád jen software v produktu. Nový režim hlášení na něj dopadá stejně jako na zbytek kódu — a AI Act ho nenahrazuje, běží vedle.
Co s tím
Do pátku se toho stihnout moc nedá, ale to podstatné ano. Nic z toho není nákup.
- 1. Rozhodněte jednou větou, jestli jste výrobce. Projděte seznam toho, co prodáváte pod svou značkou, a u každé položky si odpovězte: je to software nebo hardware, který se přímo či nepřímo připojuje k zařízení nebo síti? Když ano, jste v tom — včetně produktů, které jste uvedli na trh před lety. Zapište to, ať se k tomu nemusíte vracet.
- 2. Založte účet EU Login a zaregistrujte zástupce. Účet se dá vytvořit předem na ecas.ec.europa.eu. Vyberte konkrétního člověka jako hlavního zástupce a alespoň jednoho záložního — účty jsou osobní a na dovolené vám hlavní zástupce lhůtu nezachrání.
- 3. Napište si, kdo rozhoduje, že „firma se dozvěděla". Tady se láme 24hodinová lhůta. Výklad Komise (bod 213) říká, že za okamžik vědomosti se bere chvíle, kdy má firma po prvním posouzení „a reasonable degree of certainty", že je zranitelnost aktivně zneužívaná nebo že došlo k závažnému incidentu. Potřebujete tedy dvě věci: adresu, kam přijde hlášení zvenčí (od zákazníka, výzkumníka, úřadu), a jméno člověka, který posoudí, jestli hodiny začaly běžet. Bez toho zjistíte start lhůty až zpětně.
- 4. Zkuste přihlášení na portál dřív, než ho budete potřebovat. Až se rozběhne, projděte registraci nanečisto a zjistěte, jak dlouho trvá validace u vašeho CSIRT. Slepý bod je právě tenhle: lhůta běží od vaší vědomosti, ne od chvíle, kdy vám někdo účet schválí.
A teď proti vlastnímu byznysu: pokud nic pod svou značkou neprodáváte a jen používáte cizí software, tenhle článek pro vás nemá žádný úkol a nekupujte si kvůli němu nic. Povinnost je na výrobcích. A i když výrobce jste, tohle konkrétní téma nepotřebuje audit — potřebuje jeden e-mail, jedno jméno a jeden účet. Poradce si zvěte teprve u otázky, jestli je váš backend „remote data processing", protože to je jediná část, kde ani Komise zatím nedala jednoznačnou odpověď.
Kde to řeším s klienty
V auditech narážím pořád na totéž: firma má produkt, má v něm cizí komponenty a nemá jediný seznam toho, co v něm vlastně běží. Až přijde hlášení, že se něco zneužívá, začne se ten seznam skládat pod tlakem 24hodinové lhůty. Tuhle inventuru — co prodáváte, z čeho se to skládá, kdo posuzuje incident a kudy hlášení odejde — dělám jako součást AI Act Readiness Auditu, protože se z devadesáti procent překrývá s tím, co po vás chce AI Act. Když chcete jen vědět, jestli se vás CRA týká, napište mi přes kontakt, na tuhle jednu otázku odpovím zdarma. Navazuje to na text o tom, jak od prosince ručíte za software jako za vadný výrobek — dohromady je to stejný trend: software přestává být službou a začíná být výrobkem se vším, co k tomu patří.