Kiberreziliencia és CRA: felkészülés 2027-re

Szakmai háttéranyag | Jogi és technológiai állapot: 2026. szeptember 7.

Olvasási idő: kb. 22 perc

Az EU kiberrezilienciáról szóló rendelete, a Cyber Resilience Act (CRA), egységes termékbiztonsági követelményeket ír elő az uniós piacon forgalmazott, digitális elemeket tartalmazó termékekre. A rendelet közvetlenül alkalmazandó: nem egy újabb általános információbiztonsági ajánlás, hanem CE-jelöléshez, műszaki dokumentációhoz, sérülékenységkezeléshez és piacfelügyelethez kapcsolódó termékmegfelelőségi jogszabály.

A fő kötelezettségek 2027. december 11-től alkalmazandók. Az aktívan kihasznált sérülékenységek és a termék biztonságát érintő súlyos incidensek bejelentési szabályai 2026. szeptember 11-től élnek. Ez utóbbi dátum a jelen anyag lezárásakor még nem érkezett el, ezért a gyártóknak a bejelentési folyamatot már működőképes állapotba kell hozniuk.

Mit jelent a reziliens digitális termék?

A kiberreziliencia nem azonos azzal, hogy egy terméket egyszer biztonságosra fejlesztettek (secure by design). A reziliens termék a teljes életciklusa alatt képes a kiberkockázatok megelőzésére, észlelésére, kezelésére és az üzemzavar utáni helyreállás támogatására. Ehhez egyszerre kell megfelelő architektúra, biztonságos alapbeállítás, javíthatóság, naplózhatóság, felhasználói tájékoztatás és szervezett sérülékenységkezelés.

A CRA szemlélete életciklus-alapú. A gyártó feladata nem ér véget az értékesítéssel. A termék kiberbiztonsági kockázatértékelését a tervezéskor el kell készíteni, a követelményeket a fejlesztésbe és a gyártásba be kell építeni, majd a támogatási időszak alatt kezelni kell a sérülékenységeket és biztonsági frissítéseket kell rendelkezésre bocsátani.

Vezetői szempontból ez azt jelenti, hogy a kiberbiztonság termékfelelősségi és piacra lépési kérdéssé válik. Fejlesztői szempontból a biztonsági követelményeknek ugyanúgy nyomon követhetőnek kell lenniük, mint a funkcionális követelményeknek. A megfelelés bizonyítéka nem egyetlen tanúsítvány, hanem egymással konzisztens bizonyítékok lánca: kockázatértékelés, követelmények, tervezési döntések, teszteredmények, komponensjegyzék, javítási folyamat, felhasználói dokumentáció és EU-megfelelőségi nyilatkozat.

Valójában ez fog megmenteni sokakat az elfekvő, lejárt terméktámogatású, silány Android 8-as telefonoktól, amit még egyes üzletek akciósan el akartak adni. Ugyanis ezeket a termékeket nem lehet majd értékesíteni.

Fogalmi térkép és működő kiberhigiénia

Digitális elemeket tartalmazó termék. Olyan szoftver- vagy hardvertermék és annak távoli adatfeldolgozási megoldása, amelynek rendeltetésszerű vagy észszerűen előrelátható használata közvetlen vagy közvetett, logikai vagy fizikai adatkapcsolatot foglal magában. Önállóan forgalomba hozott komponens is lehet termék. A tisztán szolgáltatásként nyújtott SaaS (például: weboldalon nyújtott előfizethető szolgáltatás) főszabály szerint nem CRA-termék, de a termék működéséhez szükséges, a gyártó felelőssége alatt álló távoli adatfeldolgozás a termék része lehet.

Gyártó. Nem csak fizikai gyártóüzem lehet. Gyártó az a természetes vagy jogi személy is, aki terméket fejleszt vagy gyártat, és azt saját neve vagy védjegye alatt forgalmazza. Egy lényegesen módosító szereplő szintén gyártói kötelezettségeket vehet magára.

Forgalomba hozatal és forgalmazás. A forgalomba hozatal az egyedi termék első uniós piaci hozzáférhetővé tétele; a forgalmazás minden későbbi üzleti célú rendelkezésre bocsátás. Emiatt a raktáron maradt régi verziók, az OEM-megállapodások és a white-label konstrukciók külön jogi elemzést igényelnek.

Sérülékenység. A termék gyengesége, fogékonysága vagy hibája, amelyet kiberfenyegetés kihasználhat. Az „aktívan kihasznált” minősítéshez megbízható bizonyíték kell arra, hogy rosszindulatú szereplő a sérülékenységet a tulajdonos engedélye nélkül kihasználta.

SBOM. A software bill of materials géppel feldolgozható szoftver-összetevőjegyzék. A CRA műszaki dokumentációja legalább a legfelső szintű függőségeket lefedő SBOM-ot vár el, a gyakorlatban azonban a függőségek és verziók ismerete nélkül a sebezhetőségi érintettség nehezen dönthető el.

Support period, támogatási időszak. Az az időszak, amely alatt a gyártó sérülékenységkezelést és biztonsági frissítéseket biztosít. A rendelet szerint ennek a termék várható használati idejéhez kell igazodnia, és főszabály szerint legalább öt év; rövidebb csak akkor lehet, ha a termék várható használata rövidebb. Ha a terméket ennél rövidebb ideig forgalmazzák, attól a már értékesített példányok támogatása nem szűnik meg automatikusan.

Secure by design és by default. A kockázatcsökkentés már a felépítés és a követelmények szintjén megjelenik, a szállított alapbeállítás pedig a szükséges védelmet külön felhasználói beavatkozás nélkül adja. Ide tartozik az egyedi vagy biztonságos kezdeti hitelesítés, a legkisebb jogosultság, a támadási felület csökkentése, a megfelelő titkosítás, az integritásvédelem és a biztonságos frissítés.

Ezt egyes gyártók már most túlzásba viszik! Van olyan nyomtató, ami gyárilag letiltott nyomtató porttal kerül forgalomba és üzembe helyezéskor kell bekapcsolni rajta a funkciót.

A kiberhigiénia a CRA alatt minimum működési szint. Ide tartozik a naprakész eszköz- és komponensleltár; többtényezős hitelesítés; privilégiumkezelés; titokkezelés; biztonsági mentés és visszaállítási próba; naplógyűjtés és riasztás; rendszeres javítás; adathalászat elleni védelem; beszállítói hozzáférések kontrollja; valamint a sérülékenység-bejelentések fogadására szolgáló nyilvános csatorna. Ezek önmagukban nem bizonyítják a CRA-megfelelést, de nélkülük a rendelet szerinti folyamat sem lesz fenntartható.

Hatály, termékkategóriák és a szabályozási határidő

A CRA az EU piacán gazdasági tevékenység keretében hozzáférhetővé tett digitális elemeket tartalmazó termékekre vonatkozik, függetlenül attól, hogy a gyártónak hol van a telephelye. Tipikus példák: operációs rendszerek, üzleti és fogyasztói alkalmazások, hálózati eszközök, intelligensotthon-termékek, csatlakoztatott játékok, ipari vezérlőkomponensek, VPN-termékek, jelszókezelők és mikroprocesszorok.

Nem minden digitális megoldás tartozik ide. A kizárólag nem kereskedelmi tevékenység keretében fejlesztett vagy szolgáltatott szabad és nyílt forráskódú szoftver kivétel lehet. A kivételt nem pusztán a licenc alapján kell eldönteni: a bevételszerzési modell, a rendszeres gyártói támogatás és a kereskedelmi ökoszisztémába integrálás is számít. A kereskedelmi célú nyílt forráskódú termék gyártója teljes kötelezettségekkel számolhat; az open-source software steward (a nyílt forráskódú projekt gondozója) számára külön, enyhébb szabályok vannak.

A CRA nem alkalmazandó többek között azokra a termékekre, amelyekre az uniós jog már egyenértékű ágazati kiberbiztonsági követelményeket állapít meg. Külön szabályozás érintheti az orvostechnikai eszközöket, az in vitro diagnosztikai eszközöket (a vizsgálatot nem magában az élő szervezetben, hanem abból vett biológiai mintán, lombikban, kémcsőben vagy laboratóriumi eszközön végzik), a légiközlekedési termékeket és a gépjárműveket.

A megfelelési projekt első dokumentuma ezért hatályelemzés legyen, ne kontroll-lista.

A termékek kockázati osztálya meghatározza a megfelelőségértékelés útját:

Fő dátumok:

1. 2024. december 10. A rendelet hatályba lépett.
2. 2026. június 11. A megfelelőségértékelő szervezetek bejelentéséhez kapcsolódó szabályok alkalmazandóvá váltak.
3. 2026. szeptember 11. Elindul a kötelező CRA-jelentéstétel.
4. 2027. december 11. A rendelet fő szabályai teljes körűen alkalmazandók.

Az átmeneti szabály szerint a 2027. december 11. előtt forgalomba hozott termékek főszabály szerint csak akkor kerülnek a CRA új termékkövetelményei alá, ha e dátumtól lényeges módosításon esnek át. A bejelentési kötelezettség viszont a rendeletben meghatározott feltételek szerint a korábban piacra került, továbbra is támogatott termékeknél is releváns lehet. Egy verziófrissítés vagy funkcióbővítés „lényeges módosítás” jellegét dokumentáltan kell elbírálni: az számít, hogy változik-e a rendeltetés, illetve a megfelelőséget érintő kiberkockázat.

Felkészülési program: a termékportfóliótól a biztonságos fejlesztésig

A működő program kiindulópontja a portfólióleltár. Minden terméknél rögzítsd a gyártót, márkanevet, verziót, értékesítési modellt, EU-s piacra lépés dátumát, távoli szolgáltatásokat, várható használati időt, karbantartási státuszt és a felelős product ownert. A leltárhoz rendelj CRA-hatálydöntést és kockázati kategóriát, jogi indokolással.

Ezután építs bizonyítékláncot a secure development lifecycle köré:

• A termék kiberbiztonsági kockázatértékelése fedje le az eszközöket, védelmi célokat, fenyegetéseket, visszaélési eseteket, függőségeket és a maradványkockázatot.
• A biztonsági követelmények kerüljenek a backlogba és az elfogadási feltételek közé. Minden követelményhez legyen teszt vagy más ellenőrizhető bizonyíték.
• Alkalmazz kódellenőrzést, statikus és dinamikus elemzést, dependency- és secret-scanninget, infrastruktúrakód-ellenőrzést, fuzzingot vagy penetrációs tesztet a termék kockázatához igazítva.
• A build- és release-folyamat legyen hozzáférés-vezérelt, naplózott és reprodukálható. Védd az aláírókulcsokat, a CI/CD-környezetet és az artifact repositoryt.
• Készíts verziózott SBOM-ot minden kiadáshoz. Tartsd meg az összetevő eredetét, licencét, verzióját és sebezhetőségi státuszát.
• Legyen product security incident response team vagy kijelölt PSIRT-funkció, amely triázsolja a bejelentéseket, eldönti az érintettséget, koordinálja a javítást és kezeli a hatósági értesítést.
• A frissítés legyen biztonságos, hitelesített és lehetőség szerint automatikus. Biztonsági frissítést csak megfelelő indokkal csomagolj funkcionális változtatással együtt.
• A kiadás előtti kapu ellenőrizze a nyitott kritikus sérülékenységeket, a műszaki dokumentációt, a felhasználói tájékoztatást, a támogatási időszakot és a megfelelőségi nyilatkozatot.

A CRA az értéklánc szereplőit is kötelezi. Az importőrnek ellenőriznie kell többek között a megfelelőségértékelést, a műszaki dokumentációt, a CE-jelölést és a gyártói információkat. A forgalmazó kellő gondossággal ellenőrzi a jelölést és a szükséges dokumentumokat, és nem forgalmazhat tudottan nem megfelelő terméket. A szerződésekben rendezd az SBOM és a sebezhetőségi információ átadását, a javítási határidőt, az értesítési kötelezettséget, az auditjogot, az életciklus végi támogatást és az alvállalkozói láncot.

Pénzügyi tervezés és költséghelyek

A megfelelési költséget termék-életciklus szerint érdemes elkülöníteni. Ha minden tételt az informatikai biztonsági költséghelyre terhelsz, a termékvezető nem látja a piacra lépés valódi költségét, a CFO (pénzügyi vezető) pedig nem tud támogatási kötelezettségre tervezni.

A költségmodell alapja ne csak a fejlesztési óraszám legyen. Vedd figyelembe a termék várható használati idejét, a telepített bázist, a biztonsági frissítés terjesztési költségét, a harmadik feles értékelés díját, valamint azt, hogy egy régi toolchain vagy aláíró infrastruktúra fenntartása több évig szükséges lehet. A bírság nem tervezhető megfelelési alternatívaként; a forgalmazás korlátozása, visszahívás és reputációs kár nagyobb üzleti hatású lehet.

Dokumentumrendszer: milyen szabályzatokra és nyilvántartásokra van szükség?

A CRA nem ad kötelező magyar felsorolást a belső szabályzatokhoz. A szükséges dokumentumok a kötelezettségekből és a bizonyíthatóságból vezethetők le. A terjedelem legyen arányos, de a tényleges működés és a dokumentáció egyezzen.

Minimum dokumentumkészlet:

• Termék-kiberbiztonsági irányelv: hatály, vezetői felelősség, kockázatvállalás, kivételkezelés és döntési fórum.
• Biztonságos fejlesztési szabályzat: követelménykezelés, architekturális felülvizsgálat, kód- és függőségvizsgálat, release gate, fejlesztői hozzáférés.
• Termék-kockázatértékelési módszertan: értékelési skála, fenyegetésmodell, maradványkockázat elfogadása, felülvizsgálati események.
• Sérülékenységkezelési és koordinált közzétételi szabályzat: bejelentési csatorna, SLA-k, CVE-kezelés, kutatói kommunikáció, javítás és disclosure.
• CRA incidens- és hatósági bejelentési eljárás: döntési fa, 24/72 órás és végleges jelentési feladatok, helyettesítés, jogi kontroll, bizonyítékmegőrzés.
• SBOM- és nyíltforrás-komponens-kezelési szabályzat: formátum, generálás, ellenőrzés, megőrzés, komponensjóváhagyás és end-of-life kezelés.
• Beszállítói termékbiztonsági követelmények: szerződéses minimum, sebezhetőségi értesítés, frissítési vállalás, audit és megszűnés.
• Biztonsági frissítési és támogatási politika: support period meghatározása, frissítési csatorna, automatikus frissítés, EOL-kommunikáció.
• Megfelelőségértékelési és műszaki dokumentációs eljárás: termékbesorolás, alkalmazott szabványok, tesztbizonyítékok, változáskezelés, nyilatkozat és CE-jelölés.
• Iratmegőrzési rend: a műszaki dokumentáció és az EU-megfelelőségi nyilatkozat megőrzése a rendelet szerinti időre; a hozzáférési és változásnaplók védelme.

A műszaki dokumentáció tartalmazza a termék és verzió azonosítását, a rendeltetést, architektúrát, fejlesztési és gyártási folyamatot, kiberbiztonsági kockázatértékelést, az alapvető követelmények teljesítésének módját, alkalmazott szabványokat, vizsgálatokat, SBOM-ot, sérülékenységkezelési folyamatot és a támogatási időszak indoklását. A szabályzat azt mondja meg, hogyan dolgozol; a dokumentáció azt bizonyítja, hogy az adott terméknél megtetted.

Ki ellenőriz és ki fogad bejelentést?

Az uniós és magyar szerepek nem cserélhetők fel.

Európai Bizottság. Végrehajtási és felhatalmazáson alapuló aktusokat fogad el, iránymutatást ad, standardizációs folyamatot támogat, és uniós szinten koordinálja a végrehajtást. Nem ez végzi minden termék napi piacfelügyeletét.

ENISA. Üzemelteti a CRA egységes jelentéstételi platformját, együttműködik a CSIRT-ekkel, és uniós szintű kiberbiztonsági szakmai feladatokat lát el. A gyártó a platformon egyszer tesz bejelentést; a címzett koordinátor CSIRT és az ENISA a rendelet szerinti információmegosztásban vesz részt.

NBSZ Nemzeti Kiberbiztonsági Intézet. Magyarországon a Nemzetbiztonsági Szakszolgálat a nemzeti CSIRT, és ellátja a CRA koordinátor CSIRT-feladatait. Az NKI 2026. július 29-i tájékoztatója külön CRA-bejelentési elérhetőséget is közzétett. Ez incidenskezelési/bejelentési szerep, nem azonos a termékpiac-felügyelettel.

Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH). A 2025. évi CXXXV. törvény alapján Magyarországon a CRA szerinti bejelentő hatóság és piacfelügyeleti hatóság. A bejelentő hatóság a megfelelőségértékelő szervezetek értékeléséhez és bejelentéséhez kapcsolódik; a piacfelügyeleti hatóság ellenőrzi a piacon lévő termékeket, dokumentumot és információt kérhet, vizsgálhat, és korrekciós vagy korlátozó intézkedést hozhat.

Az már most is látszik, hogy a hatóság átalakulóban van, ami bizonytalanná teszi a következő két évet.

Megfelelőségértékelő szervezetek. Nem hatóságok, hanem a kijelölt és uniós rendszerben bejelentett, megfelelő kompetenciával rendelkező harmadik felek. Azoknál a kategóriáknál vonhatók be vagy kötelezők, ahol a választott megfelelőségértékelési modul ezt előírja.

Nemzeti akkreditáló szerv. Az akkreditáció a megfelelőségértékelő szervezet szakmai alkalmasságának bizonyításában kaphat szerepet. Az akkreditáció, a hatósági bejelentés és a terméktanúsítás három külön jogi funkció.

Piacfelügyelet, korrekció és szankciók

A CRA végrehajtása alapvetően utólagos piacfelügyeleti modell. A gyártó elvégzi vagy elvégezteti a szükséges megfelelőségértékelést, kiadja az EU-megfelelőségi nyilatkozatot és elhelyezi a CE-jelölést. A hatóság ezután kockázatalapon vagy jelzés alapján vizsgálhat.

Tipikus eljárási lánc:

1. A hatóság terméket választ ki vagy bejelentést kap.
2. Bekéri a műszaki dokumentációt, megfelelőségi nyilatkozatot, tesztbizonyítékot és ellátásilánc-információt; szükség esetén termékvizsgálatot végez.
3. Értékeli a formai és tartalmi megfelelést, illetve azt, hogy a termék kiberkockázatot jelent-e.
4. Felszólíthatja a gazdasági szereplőt a megfelelés helyreállítására vagy a kockázat megszüntetésére.
5. Elégtelen korrekció esetén korlátozhatja vagy megtilthatja a forgalmazást, kivonást vagy visszahívást rendelhet el, és bírságot szabhat ki.
6. Határon átnyúló ügyben az uniós piacfelügyeleti együttműködés és védzáradéki mechanizmus biztosítja, hogy az intézkedés ne maradjon egyetlen tagállamra korlátozva.

Az uniós bírságmaximumok három fő szintet alkotnak. Az alapvető kiberbiztonsági követelmények és egyes gyártói kötelezettségek megsértése legfeljebb 15 millió euró vagy vállalkozásnál az előző üzleti év teljes globális éves árbevételének 2,5%-a, amelyik magasabb. Más kötelezettségek megsértése legfeljebb 10 millió euró vagy 2%. Helytelen, hiányos vagy félrevezető információ adása legfeljebb 5 millió euró vagy 1%. A konkrét összegnél számít a jogsértés jellege, súlya, időtartama, következménye, szándékossága vagy gondatlansága, az együttműködés és a korábbi jogsértés.

A magyar végrehajtási törvény 500 000 forintos alsó bírsághatárral és a CRA uniós maximumaihoz igazodó felső határokkal számol; ismételt jogsértésnél a bírság a korábbi összeg legalább másfélszerese lehet, a felső korlát túllépése nélkül. A piacfelügyeleti és bírságszabályok 2027. december 11-től alkalmazandók.

A bejelentési kötelezettség elmulasztása nem pusztán adminisztratív hiba. Ha a szervezet nem tudja bizonyítani, mikor szerzett tudomást a tényekről, ki döntött a minősítésről, és mikor adott be jelentést, a határidő betartása sem igazolható. Ezért a PSIRT-jegyek időbélyege, az ügyeleti rend és a döntési napló jogi bizonyíték is.

Audit vagy megfelelőségértékelés? Két eltérő rendszer

A CRA nem ír elő minden gyártónak időszakos „kiberbiztonsági auditot” abban az értelemben, ahogy a magyar NIS2-szabályozás az érintett szervezetek elektronikus információs rendszereinek auditját kezeli. A CRA-ban a kulcsfogalom a termék megfelelőségértékelése, amelyet a termék kategóriájától és az alkalmazott harmonizált szabványoktól függően a gyártó belső ellenőrzéssel vagy bejelentett szervezet bevonásával végez.

A CRA-megfelelőségértékelés folyamata:

1. Hatály- és kategóriadöntés. Azonosítsd a terméket, gazdasági szereplőt, kivételeket, fontos/kritikus besorolást és a választott modult.
2. Kiberbiztonsági kockázatértékelés. A termék rendeltetésszerű és előrelátható használatára, teljes életciklusára készüljön.
3. Követelmény–bizonyíték mátrix. Az I. melléklet minden releváns követelményéhez rendelj megvalósítást, tesztet és dokumentumot.
4. Termékellenőrzés. Kód-, konfiguráció-, architektúra- és sebezhetőségi vizsgálat; a kijavítatlan problémák kockázati elfogadása.
5. Külső szervezet bevonása, ha szükséges. Fontos II. osztály és egyes más utak esetén kötelező; fontos I. osztálynál a szabványhasználattól függhet.
6. Műszaki dokumentáció és nyilatkozat. A döntések, bizonyítékok, SBOM, támogatási információ és használati utasítás összeállítása; EU-megfelelőségi nyilatkozat kiadása.
7. CE-jelölés és piacra bocsátás. Csak a sikeres eljárás után.
8. Folyamatos megfelelés. Sérülékenységkezelés, frissítés, bejelentés és változásértékelés a támogatási időszakban.

A harmonizált szabványok alkalmazása önkéntes, de megfelelőségi vélelmet adhat az általuk lefedett követelményekre. A szabvány hiánya nem tolja el a jogszabály határidejét. Ilyenkor a gyártónak más, megfelelő műszaki megoldással és erősebb bizonyítással kell igazolnia a követelmény teljesítését.

Ezzel párhuzamosan egy magyar vállalkozás a 2024. évi LXIX. törvény alapján szervezeti kiberbiztonsági kötelezett is lehet. Ott az SZTFH felügyelete, az elektronikus információs rendszerek biztonsági osztályba sorolása és a nyilvántartott auditor által végzett időszakos audit más tárgyat vizsgál: a szervezet irányítását és rendszereinek védelmét, nem egy termék CE-megfelelőségét. Ugyanaz a cég mindkét rendelet hatálya alá kerülhet, de az egyik audit eredménye nem helyettesíti automatikusan a másik megfelelőségi bizonyítékát.

Jelentéstétel 2026. szeptember 11-től

A gyártónak az egységes jelentéstételi platformon keresztül kell bejelentenie az aktívan kihasznált sérülékenységet és a termék biztonságát érintő súlyos incidenst. A jelentés a fő telephely szerinti koordinátor CSIRT-hez és az ENISA-hoz jut el. Magyarországon a koordinátor feladatot az NBSZ NKI látja el.

Az ütemezés rövid:

• Korai figyelmeztetés: a tudomásszerzéstől számított 24 órán belül.
• Részletes értesítés: a tudomásszerzéstől számított 72 órán belül, az addig rendelkezésre álló értékeléssel és korrekciós vagy enyhítő intézkedésekkel.
• Aktívan kihasznált sérülékenységnél végleges jelentés: legkésőbb a korrekciós vagy enyhítő intézkedés rendelkezésre állásától számított 14 napon belül.
• Súlyos incidensnél végleges jelentés: legkésőbb a részletes értesítéstől számított egy hónapon belül.

A folyamatnak hétvégén is működnie kell. Jelölj ki elsődleges és helyettes döntéshozót; legyen jogosultságuk az SRP használatára; legyen angol nyelvű adatlap a termékről; és előre határozd meg, hogyan választod el a megerősített tényt, az előzetes feltételezést és az üzleti titkot. A gyors jelentés nem várhat a gyökérok teljes bizonyítására.

Végrehajtható felkészülési terv 2027 végéig

Azonnal, a jelentéstétel indulásáig: aktiváld az SRP-hozzáférést és a 24/7 eszkalációt; ellenőrizd a security.txt és más bejelentési csatornákat; próbáld el egy aktívan kihasznált sérülékenység 24 és 72 órás jelentését; dokumentáld a tudomásszerzés időpontjának szabályát.

2026 negyedik negyedévében: véglegesítsd a termékportfólió hatály és kockázati kategória szerinti besorolását; jelölj ki minden termékhez felelőst, és határozd meg a támogatási időszakot; készíts GAP-elemzést az I. melléklet követelményei alapján; azonosítsd a külső megfelelőségértékelést igénylő termékeket.

2027 első felében: vezesd be a kötelező kiadás előtti ellenőrzési pontokat; tedd üzembiztossá az SBOM-kezelést és a sérülékenységkezelést; módosítsd a beszállítói szerződéseket; állítsd össze az első teljes műszaki dokumentációkat; köss le megfelelő kapacitást a bejelentett megfelelőségértékelő szervezeteknél.

2027 második felében: végezz próba-megfelelőségértékelést; javítsd a bizonyítékhiányokat; véglegesítsd a nyilatkozatot, jelölést és felhasználói dokumentációt; ellenőrizd az EU-n kívüli gyártók képviselői és importőri láncát; állítsd le vagy módosítsd a nem megfeleltethető termékek 2027. december 11. utáni új forgalomba hozatalát.

Vezetői minimumriport havonta öt adatot mutasson: besorolt termékek aránya; teljes követelmény–bizonyíték lefedettség; lejárt kritikus sérülékenységek; támogatási kötelezettség pénzügyi fedezete; külső értékeléshez szükséges kapacitás és határidő. Ezekből látható, hogy a projekt valóban a piacra lépési kockázatot csökkenti-e.

Források és jogi megjegyzés

• Az Európai Parlament és a Tanács (EU) 2024/2847 rendelete (Cyber Resilience Act): https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• Európai Bizottság, CRA implementation és határidők: https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
• Európai Bizottság, gyártói kötelezettségek: https://digital-strategy.ec.europa.eu/en/policies/cra-manufacturers
• Európai Bizottság, jelentéstételi kötelezettségek: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• Európai Bizottság, CRA FAQ, frissítve 2026. szeptember 4-én: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions
• ENISA, Single Reporting Platform: https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
• NBSZ NKI, magyar CRA-tájékoztató és bejelentési információ: https://nki.gov.hu/figyelmeztetesek/tajekoztatas/tajekoztatas-az-europai-parlament-es-a-tanacs-2024-2847-rendeleterol/
• 2025. évi CXXXV. törvény a CRA magyarországi végrehajtásáról: Magyar Közlöny, 2025. évi 157. szám.
• 2024. évi LXIX. törvény Magyarország kiberbiztonságáról és 418/2024. (XII. 23.) Korm. rendelet.

Ez az anyag általános szakmai tájékoztatás. Egy konkrét termék hatálya, besorolása, átmeneti helyzete és megfelelőségértékelési útja a termék funkcióitól, értékesítési modelljétől, módosításaitól és más alkalmazandó uniós ágazati szabályoktól függ; ezért egyedi jogi és műszaki vizsgálat szükséges.