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

  1. Korai figyelmeztetés — 24 óra a tudomásszerzéstől (aktív kihasználás vagy súlyos incidens).
  2. Értesítés — 72 óra — általános információ + első értékelés.
  3. 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:

  1. Terméklista — minden digitális elemmel rendelkező termék / SaaS-csomag, amit EU-ban forgalmazol.
  2. Ki dönt 24 órán belül — név + helyettes; hétvégére is.
  3. 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:

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

  1. Ne várd a „CRA teljes megfelelőség 2027” workshopot a jelentési órák helyett.
  2. Ne bízd a 24 órás döntést egyetlen, szabadságon lévő DevOps-ra.
  3. 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?”