Cyber Resilience Act (CRA) 2026–2027: amit már tudunk, ami még hiányzik, és hogyan lehet a terméket a gyakorlatban felkészíteni – még a harmonizált szabványok megjelenése előtt

Amit ma biztosan tudunk (és miért nem „2027-es téma”)

A Cyber Resilience Act könnyen tűnhet egy újabb „brüsszeli” dokumentumnak, amit majd ráérünk később elővenni. Ez természetes reakció, különösen akkor, ha a cég projektciklusokban él: prototípus, bevezetés, sorozatgyártás, szerviz. A szabályozások gyakran „záró követelményként” érkeznek — olyasmi, amit a végén pipálunk ki. A CRA ezt a logikát megváltoztatja, mert nem kizárólag arról szól, ami a termékben az értékesítés napján látható. Arról szól, hogy a gyártó képes-e időben fenntartani a termék biztonságát, és bizonyítani tudja-e, hogy ezt tudatosan tette, nem pedig véletlenül.

A legfontosabb tény egyszerű, de stratégiai következményei vannak: a CRA termékszabályozás, az EU piacának működési logikájába ágyazva (ideértve a CE-jelölést is). Az Európai Bizottság kifejezetten leírja, hogy a termékeknek CE-jelölést kell viselniük a CRA-nak való megfelelés jelzéseként, és a végrehajtás a piacfelügyeleti hatóságok feladata. Ez tehát nem egy „IT-szabvány”, amit belső fejlesztési programként lehet kezelni. Olyan keretrendszer, amely a forgalmazhatóságra hat.

Dátumok, amelyek rendet tesznek a gondolkodásban

Már magában a (EU) 2024/2847 rendelet szövegében is látszik a fokozatos alkalmazás. A CRA-t 2027. december 11-től kell alkalmazni, de egyértelmű kivételekkel. A 14. cikk (jelentéstétel) 2026. szeptember 11-től alkalmazandó, a megfelelőségértékelő szervezetek bejelentéséről szóló fejezet (Chapter IV) pedig 2026. június 11-től. Ezt a három dátumot érdemes „mérföldkőként” kezelni, mert három különböző felkészültségi típust jelölnek: működésit, intézményit és termékszintűt.

A Bizottság ezt még egyszerűbben kommunikálja: a CRA 2024. december 10-én lépett hatályba, a lényegi kötelezettségek 2027. december 11-től, a jelentéstétel pedig 2026. szeptember 11-től érvényes. Ha valaki a cégnél azt mondja, „van időnk 2027-ig”, többnyire a tervezési követelményekre és a megfelelőségértékelésre gondol. A jelentéstétel azonban korábban indul, és olyan eseményekre vonatkozik, amelyek nem igazodnak az ütemtervhez.

Jelentéstétel: kötelezettség, amely folyamatot kényszerít ki (nem dokumentumot)

A jelentéstételi követelmény jó lakmuszpapír, mert megmutatja, hogyan érti a CRA a „termék kiberbiztonságát”. Ez nem szándéknyilatkozat és nem „szabályzat”. Olyan folyamat, amelynek stresszhelyzetben kell működnie: amikor aktívan kihasznált sérülékenység vagy súlyos incidens jelenik meg.

A Bizottság ezt egyértelműen leírja: a gyártónak be kell jelentenie az aktívan kihasznált sérülékenységeket és a termék biztonságát érintő súlyos incidenseket. Elvárt az „early warning” 24 órán belül attól számítva, hogy tudomást szereztek róla, a teljes bejelentés 72 órán belül, a zárójelentés pedig: az aktívan kihasznált sérülékenységek esetén legkésőbb 14 nappal a javító intézkedés elérhetővé válása után, illetve súlyos incidensek esetén egy hónapon belül.

A gyakorlatban ez azt jelenti, hogy a szervezetnek többre van szüksége egy ellenőrzőlistánál. Olyan mechanizmus kell, amely három kérdésre ad választ: honnan fogjuk megtudni, hogy a probléma létezik; ki minősíti, hogy ez már „aktívan kihasznált” vagy „súlyos”; és hogyan szervezzük meg az információáramlást és a javítást olyan határidővel, amely nem hagy teret az improvizációnak.

Ha a képzéseken káosz alakul ki, az gyakran azért van, mert a CRA az IT és a termék közötti résbe érkezik. Az IT számára az „incidens” sokszor az infrastruktúrában bekövetkező esemény. A gyártó számára az „incidens” olyan esemény, amely a vevőnél lévő terméket érinti: a verziót, a konfigurációt, a bevezetés módját. A CRA kikényszeríti e világok összekapcsolását egyetlen felelősséggé.

Mit fed le a CRA: a termék mint hálózati kapcsolat, nem „az asztalon álló eszköz”

A gyakorlatban a gépek kockázatértékelése során azt tanultuk, hogy a kockázat nem magának a gépnek a tulajdonsága — az ember–gép kapcsolatban jön létre. A CRA-ban hasonló nézőpontváltás történik: a biztonság nem „a készülékben” létezik, hanem a termék digitális környezetével való kapcsolatban, a használat módjában és abban, hogy a gyártó képes-e reagálni.

A Bizottság a CRA összefoglalásakor felhívja a figyelmet a „digitális elemeket tartalmazó termékek” definíciójára, valamint arra, hogy a jelentéstételi kötelezettségek minden ilyen, az EU piacán elérhetővé tett termékre vonatkoznak — azokra is, amelyeket 2027. december 11. előtt vezettek be. Ez kulcsfontosságú pontosítás, mert eloszlat egy gyakori mítoszt: „a régi termékeknél ez nem számít”. A jelentéstétel — igenis számít.

Ami még hiányzik (harmonizált szabványok), és miért nem szabad, hogy ez megbénítson

W CRA-ról szóló beszélgetésekben gyakran előkerül a mondat: „még nincsenek harmonizált szabványok, ezért nem lehet lépni”. Ez logikusnak hangzik, de van benne egy rejtett csapda. A harmonizált szabványok olyan eszközök, amelyek megkönnyítik a megfelelőség igazolását (megfelelőségi vélelem), de nem az egyetlen út a termék tényleges biztonságának megteremtéséhez. És nem is feltétele annak, hogy helyesen el lehessen kezdeni a tervezést.

A Bizottság kifejezetten a „CRA Standardisation” oldalon viszi a szabványosítás témáját, és tájékoztat arról, hogy elfogadta a standardisation request M/606 dokumentumot, amely 41 szabványból álló csomagot foglal magában a CRA támogatására — horizontális és vertikális (termékspecifikus) szabványokat egyaránt. Ez azért fontos, mert megmutatja, hogy az EU érti a piaci problémát: szabványok nélkül a vállalatok mind saját módszerrel fogják felépíteni a megfelelőséget, és a piacfelügyeletnek is nehezebb dolga lesz.

Horizontális és vertikális szabványok: mit jelent ez a gyártónak

Egyszerűsítve:

• a horizontális szabványok azt írják le, „hogyan” kell felépíteni és fenntartani a termék biztonságát kategóriától függetlenül (folyamatok, módszerek, kockázatalapú megközelítés),
• a vertikális szabványok a konkrét termékosztályokra vonatkozó követelményeket pontosítják (ott, ahol a kockázatok és az architektúrák tipikusak).

Ennek a megkülönböztetésnek gyakorlati következményei vannak. Ha ipari terméket készítesz, ahol a környezet egy része „OT”, és az életciklus hosszú, akkor olyan szabványokra lesz szükséged, amelyeket nem egy SaaS-alkalmazásra írtak. Pontosan ezért van jelentősége a vertikális szabványoknak: segítenek az általános elvektől eljutni oda, hogy a valós architektúrákban mit kell ténylegesen ellenőrizni.

Ütemezés: a szabványok szakaszosan érkeznek, nem „egy csomagban 2027 előtt”

A Bizottság a CRA bevezetéséről szóló anyagaiban bemutatja, hogy a CRA-t fokozatosan vezetik be, és a szabványok időben támogatják ezt a folyamatot. A ma biztos tények szintjén: van formálisan elfogadott rendeletünk, és elindult a szabványosítási mechanizmus (M/606).

A gyakorlat szempontjából a legfontosabb egy mondat megértése: még ha egy szabványt ki is dolgoznak a szabványügyi szervezetek, a jogi értelemben vett „megfelelőségi vélelem” csak akkor jelenik meg, amikor a szabványra való hivatkozást harmonizált szabványként közzéteszik az EU Hivatalos Lapjában. Ez az uniós harmonizációs megközelítés közös mechanikája: a szabványok hidat képeznek a jog és a mérnöki gyakorlat között, de ezt a hidat az EU-nak formálisan „el kell ismernie”.

Gyártói nézőpontból ez azt jelenti, hogy a 2026–2027-es évek olyan időszak lesznek, amikor egyes cégek a megfelelőség igazolására saját módszereikre (kockázatalapú megközelítés + bizonyítékok) támaszkodnak, mások pedig már az éppen megjelenő szabványokhoz térképezik fel a működésüket. És ez teljesen természetes.

„Nincs szabvány” nem azt jelenti, hogy „nincs kötelezettség” — hanem azt, hogy nagyobb a bizonyítékok súlya

Itt jelenik meg egy lényeges következmény: ha nincsenek olyan szabványok, amelyek a megfelelőség igazolásának legegyszerűbb útját adják, felértékelődik az, ami az auditgyakorlatban mindig döntő: a következetes döntési nyomvonal.

Milyen kockázatokat értékeltünk? Milyen forgatókönyveket tekintettünk reálisnak? Hogyan választottuk ki a védelmi intézkedéseket? Hogyan kezeljük a sérülékenységeket? Meddig támogatjuk a terméket? Hogyan tájékoztatjuk az ügyfelet? A CRA nem azt várja el, hogy a gyártó „megjósolja a jövőbeli EN-szabványokat”. Azt várja el, hogy a gyártó be tudja mutatni: a döntései nem esetlegesek voltak, hanem kockázatalapon és a technika állása szerint születtek.

Hogyan készítsük fel a terméket a CRA-ra a gyakorlatban (útiterv gyártóknak és integrátoroknak)

A CRA legnagyobb értéke az, hogy érettséget kényszerít ki: a kiberbiztonság megszűnik a termékhez utólag hozzáadott kiegészítő lenni, és a termék saját tulajdonságává válik. Csakhogy az érettség nem nyilatkozatokból születik. Olyan folyamatból születik, amely elég precíz ahhoz, hogy a gyakorlatban működjön, és elég egyszerű ahhoz, hogy a mérnökség ne kezdje megkerülni.

A gépek kockázatértékelésében a legjobb tervezési döntések akkor születnek, amikor abbahagyjuk azt a kérdést, hogy „milyen veszélyei vannak a gépnek”, és inkább azt kérdezzük: „milyen feladatokban és állapotokban van kitéve az ember”. A CRA-ban hasonló a logika: nem azt kérdezzük, hogy „milyen sérülékenységei vannak a terméknek”, hanem azt, hogy „milyen körülmények között válik a termék sebezhetővé, és mit tud ilyenkor tenni a gyártó”. Ez az eltolódás rendet tesz a munkában.

1. lépés: Határozd meg a terméket rendszerként (ne csak eszközként)

Kezdd azzal, hogy meghatározod, a te esetedben mi számít „digitális elemeket tartalmazó terméknek”. Nem csak a hardver és a firmware, hanem az is, ami gyakran kimarad, mert nem fér bele a dobozba: komponensek, könyvtárak, frissítési mechanizmusok, szolgáltatások, amelyek nélkül a termék nem látja el a funkcióját. A CRA-ban ez azért fontos, mert a gyártó felelőssége arra terjed ki, ami termékként kerül a piacra — nem csak arra, amit a gépészeti részleg előállított.

Ez az első pont, ahol az integrátoroknak is őszintének kell lenniük magukhoz: ha komponenseket integrálsz és úgy konfigurálod őket, hogy az az ügyfél szemében „végterméket” hoz létre, akkor nem pusztán „bevezetést végző” szereplő vagy. A kockázat és a felelősség társszerzője is vagy.

2. lépés: Készíts CRA-kockázatértékelést úgy, hogy döntéstámogató eszköz legyen

Nem a diákon szereplő „mátrixról” van szó. Hanem olyan kockázatértékelésről, amely tervezési döntésekhez vezet, és megismételhető.

A gyakorlatban a CRA-hoz vezető jó megközelítés egy egyszerű kérdéssel indul: melyek a valós visszaélési forgatókönyvek az ügyfél környezetében, nem csak a laborban? Kinek van szerviz-hozzáférése? Milyen a hálózat? Milyen gyakran frissítünk? Milyen következményei vannak egy leállásnak? Az iparban ezek a kérdések kellemetlenebbek, mint az IT-ban, mert a válaszok gyakran így hangzanak: „nem tudunk hetente frissíteni” vagy „nincs telemetriánk”. És éppen ezért kell feltenni őket. A CRA jogszabály, de a hatása a tervezésben jelenik meg.

3. lépés: A „vulnerability handling”-et gyártási folyamatként építsd fel, ne válságreakcióként

A Bizottság által leírt jelentési követelmények (24h/72h/14 nap/hónap) könyörtelenek egy olyan szervezettel szemben, amelynek nincs folyamata. Ha 2026. szeptember 11-re készen akarsz állni, a „vulnerability handling”-et a termék életciklusának részeként kell kezelned, nem pedig „a security csapat feladataként”.

Ez a következőket jelenti:

• egyetlen csatorna a bejelentések fogadására (CVD policy + elérhetőség),
• triage, amelynek van felelőse és kritériumrendszere,
• biztonsági frissítések előállításának és szállításának mechanizmusa,
• olyan ügyfélkommunikációs modell, amely nem rögtönzés,
• jelentéstételi készenlét (ki jelent, milyen adatokkal, milyen gyorsan).

Mindez „szervezési” munkának hangzik. A valóságban termékmunka, mert verziókról, kompatibilitásról, a frissítési architektúráról és a támogatási stratégiáról szól.

4. lépés: A támogatási időszakot üzleti döntésként válaszd meg, ne minimális követelményként

Ha a termékeid az iparban 10–15 évig működnek, akkor a támogatási időszak stratégiai kérdés. A CRA kikényszeríti, hogy a támogatás ne legyen fedezet nélküli ígéret. Ez azt jelenti, hogy a támogatási időszaknak elemzésből kell következnie: meddig lesz használatban a termék, hogyan néz ki a komponensek ellátási lánca, meddig leszel képes javításokat szállítani. A gyakorlatban a támogatási időszak elkezdi „magával húzni” az egész ökoszisztémát: beszállítói szerződéseket, a build environment elérhetőségét, a toolchain-ek fenntartását, sőt még azt is, hogy a termék rendelkezzen-e távoli funkciókkal, vagy legyen leválasztva.

Ha a támogatási időszakot formalitásként kezeled, legkésőbb 2027-ben konfliktusba futsz: az ügyfél támogatást vár, te pedig már nem rendelkezel sem erőforrással, sem függőségekkel ahhoz, hogy ezt biztosítsd. A CRA nem hozza létre ezt a problémát — csak láthatóvá teszi.

5. lépés: Tedd rendbe az ellátási láncot: a beszállítókkal folytatott egyeztetés a megfelelőség része

A CRA-ban nincs „varázslat”, amitől a külső komponensek biztonságossá válnak. Ha az eszközöd könyvtárakra, kommunikációs modulokra, operációs rendszerre, SDK-ra vagy hardverkomponensekre épül, akkor a kockázatod közvetlenül a beszállító gyakorlatainak minőségétől függ.

Ezért már most érdemes bevezetni a párbeszédet olyan témákról, amelyek nem marketingnek hangzanak, hanem mérnöki kérdéseknek:

• képes-e a beszállító a sérülékenységekről kiszámítható módon tájékoztatni,
• mennyi a reakcióideje,
• van-e javításközzétételi folyamata,
• képes-e a komponenst olyan időtartamon át fenntartani, amely összhangban van a te támogatási időszakoddal.

Itt érinti igazán a CRA az üzletet: egy beszállító, aki nem tudja kezelni a sérülékenységeket, nem „olcsóbb”. Szabályozási kockázat.

6. lépés: A dokumentációt egységes nyomvonalként építsd fel: jog → kockázat → döntés → bizonyíték

A megfelelőségi auditokban mindig a következetesség nyer. Ha a kockázatértékelésből az következik, hogy egy adott interfész kritikus, de a dokumentáció nem írja le, hogyan véded; ha azt állítod, hogy a frissítések biztonságosak, de nem tudod megmutatni, hogyan biztosítod a csomagok integritását; ha azt mondod, hogy van sérülékenységkezelési folyamatod, de nem tudod bemutatni, hogyan osztályozod a bejelentéseket — az nem „papírhiány”. Az annak a bizonyítéka, hogy nincs igazolva: a folyamat működik.

A CRA-ban, harmonizált szabványok hiányában, ez a nyomvonal különösen fontos. Mert ez lesz az alapja a piacfelügyeleti hatósággal, a nagyvállalati ügyféllel, és bizonyos termékkategóriákban a megfelelőségértékelő szervezettel folytatott egyeztetésnek is. És ami ugyanilyen fontos: ez adja a belső stabilitás alapját. A csapat tudja, miért csinálunk valamit, nem csak azt, hogy „muszáj”.

Befejezés: a CRA mint új tervezési követelmény, nem „compliance projekt”

Ha egyetlen gondolatot kellene hátrahagynom, ami összefogja a három részt: a CRA nem olyan probléma, amit a végén kell megoldani. Olyan keret, amely megváltoztatja a termékről való gondolkodást. Ahogy az ISO 12100 arra tanít, hogy a kockázat az ember–gép kapcsolatban keletkezik, úgy a CRA arra tanít, hogy a kiberbiztonság a termék–környezet–gyártói életciklus kapcsolatában jön létre.

A harmonizált szabványok meg fognak érkezni, és bizonyos útvonalakat egyszerűsítenek. De a hiányuk nem ok a tétlenségre. Inkább ok arra, hogy arra fókuszálj, amit a CRA mindig értékel: a döntésekre, a bizonyítékokra és a valós működőképességre — nem a prezentációra.