Nagyító · Kibervédelem
Augusztus 12-én számolva harminc nap van 2026. szeptember 11-ig. Aznap élnek a Cyber Resilience Act (CRA) jelentési kötelezettségei a digitális elemmel rendelkező termékek gyártóira — a teljes megfelelőség 2027. decemberéig csúszik, a jelentés nem. A Bizottság július 27-én közzétett alkalmazási iránymutatása (C(2026) 5252) éppen azért készült, hogy a kisebb gyártók ne a jogszabály szövegén akadjanak el. Nem kötelező, de a piacfelügyelet innen fog olvasni.
Ez tájékoztató összefoglaló, nem jogi tanácsadás. A saját terméklistát és a „manufacturer” besorolást belső compliance-szel vagy ügyvéddel érdemes lezárni.
Mi indul szeptember 11-én — és mi nem
| Él | Nem él még |
|---|---|
| Aktívan kihasznált sebezhetőség jelentése | Teljes termék-megfelelőség (2027.12.11) |
| Súlyos, biztonságot érintő incidens jelentése | Annex I SBOM mint későbbi teljeskörű kötelezettség |
| 24 óra / 72 óra / zárójelentés órái | Visszamenőleges jelentés a 09-11 előtt ismert kihasználásokról* |
*A guidance szerint nincs kötelezettség a szeptember 11. előtt már ismert, aktív kihasználás visszamenőleges bejelentésére — de innentől minden új tudomásszerzés órázik.
A jelentés egy csatornán megy: az ENISA Single Reporting Platform (SRP), a főtelephely szerinti CSIRT felé, információval az ENISA-nak is. A platformnak szeptember 11-re működőképesnek kell lennie; az ENISA helpdesk KKV-knak is nyitva áll (CRA reporting).
A három óra — magyar KKV nyelven
- Korai figyelmeztetés — 24 óra a tudomásszerzéstől (aktív kihasználás vagy súlyos incidens).
- Értesítés — 72 óra — általános információ + első értékelés.
- Zárójelentés — sebezhetőségnél a javítás elérhetősége után legfeljebb 14 nap; súlyos incidensnél a 72 órás jelentéstől számított egy hónap.
A guidance kulcsmondatja: „tudomásszerzés” akkor áll fenn, ha az első értékelés után ésszerű bizonyossággal látod, hogy a termékben lévő sebezhetőséget aktívan kihasználják, vagy súlyos incidens érintette a termék biztonságát. Nem kell azonnal jelentenod a nyers CVE-t — de nem várhatsz a „majd a pénteki status meetingre” sem.
Mi a csapda
A csapda nem a 24 óra. A csapda az, hogy nem tudod, mi van a termékben. EOL függőség (régi Node, Vue 2, elhagyott könyvtár) nélkül nincs 24 órás válasz. A teljes SBOM-bírság-logika 2027-ben élesedik; a szeptemberi jelentéshez gyakorlatilag most kell inventár. Aki csak a 2027-es dátumot nézi, szeptemberben vakon áll az SRP előtt.
Másik csapda: „mi csak viszonteladók vagyunk”. Ha te helyezed forgalomba az EU-ban a digitális elemmel rendelkező terméket, a CRA manufacturer-fogalma elérhet. A guidance scope- és „substantial modification” fejezeteit ezért érdemes a saját katalógusodra olvasni — nem a LinkedIn-összefoglalót.
Peer: a Loop CRA előtti EOL-lista cikke a függőség-listáról szól; ez a darab az óra és a guidance utáni harminc napról.
Harminc nap — döntési szabály
Ma írj fel három sort a táblára:
- Terméklista — minden digitális elemmel rendelkező termék / SaaS-csomag, amit EU-ban forgalmazol.
- Ki dönt 24 órán belül — név + helyettes; hétvégére is.
- EU Login / SRP próba — regisztráció most; ne szeptember 11. reggelén.
Ha a háromból kettő üres: a guidance elolvasása nem a következő teendő. A lista igen.
Gyakorlati forgatókönyv — 50 fős szoftvercég
Tegyük fel: van egy SaaS-otok EU-ügyfeleknek, és egy „dobozos” eszközfirmware-etek viszonteladókon keresztül. Szeptember 11. után egy nyilvános exploit jelenik meg a firmware egyik függőségében. A kérdés nem az, hogy a fejlesztő „hallott-e” a CVE-ről a Twitteren — hanem hogy mikor van ésszerű bizonyosságotok arról, hogy a ti terméktekben aktív a kihasználás.
Ha nincs:
- termék–függőség térkép,
- felelős, aki hétvégén is dönt,
- SRP-fiók,
akkor a 24 óra nem „szigorú”, hanem elvileg teljesíthetetlen. A júliusi guidance pont azért hosszabb, mert a KKV-k itt akadnak el: scope, substantial modification, support period, reporting órák. Olvasd a saját katalógusodra — ne a sajtócímet.
Mit ne csinálj ezen a 30 napon
- Ne várd a „CRA teljes megfelelőség 2027” workshopot a jelentési órák helyett.
- Ne bízd a 24 órás döntést egyetlen, szabadságon lévő DevOps-ra.
- Ne keverd a NIS2 incidensjelentést a CRA SRP-vel — más jogalap, más csatorna, más órák. Ha mindkettő érint, két folyamat kell a táblán.
A bírságplafon a CRA-nál magas (akár 15 millió euró vagy a forgalom 2,5%-a a sajtóösszefoglalók szerint) — de a gyakorlati kockázatod ma a működésképtelen folyamat, nem a bírságkalkulátor.
Checklist a mérnöki és a jogi asztal között
Nyomtasd ki, vagy tedd Confluence-be — mindegy, legyen egy tulajdonos:
| Kérdés | Felelős | Kész? |
|---|---|---|
| Melyik termék CRA-köteles (digitális elem, EU forgalom)? | Termék | |
| Hol a függőség / komponenslista? | Fejlesztés | |
| Ki indítja az SRP-t 24 órán belül? | Üzemeltetés + jog | |
| Hétvégi / ünnepi helyettes? | HR / ügyvezetés | |
| Ügyfél-értesítés szövege készen áll? | Kommunikáció |
Ha a tábla üres cellákkal megy a szeptemberi hétre, a guidance elolvasása önmagában nem compliance.
Ha a terméked nyílt forráskódú steward-szerepben is érintett, az ENISA anyagai külön említik az OSS steward jelentési kötelezettségeket az aktív kihasználás / súlyos incidens körében. Ellenőrizd, ti gyártók vagytok-e, vagy steward — a címke más, az óra hasonlóan rövid.
Holnap reggel a vezetői mondat: „Szeptember 11-től a CRA-jelentés órázik — ki a 24 órás döntőnk, és hol van a terméklistánk?”
