Egy IoT-eszköz gyártását hagyományosan hardverprojektként kezeljük. Elektronika, ház, tápellátás, EMC, firmware, gyártásteszt, dokumentáció, majd értékesítés.

A hálózatba kapcsolt termék azonban az átadás után sem marad változatlan. Új sérülékenységek jelennek meg a saját kódban, a használt könyvtárakban, az operációs rendszerben vagy a kommunikációs komponensekben. Megváltozhat a fenyegetési környezet, miközben a termék évekig ugyanazon a telephelyen működik.

Az Európai Unió Cyber Resilience Act rendelete ezt az életciklus-kockázatot teszi gyártói feladattá.

Hol tartunk 2026 szeptemberében?

A CRA, vagyis az (EU) 2024/2847 rendelet 2024. december 10-én lépett hatályba.

A fő termékkövetelményeket 2027. december 11-től kell alkalmazni. A jelentési kötelezettségek azonban már 2026. szeptember 11-től hatályosak. Ez azt jelenti, hogy a felkészülés nem egy távoli, 2027 végén kezdődő projekt.

A rendelet digitális elemeket tartalmazó hardver- és szoftvertermékekre terjed ki, a pontos hatályt, termékkategóriát és megfelelőségértékelési utat pedig minden gyártónak a saját termékére kell meghatároznia.

Egy ipari IoT gateway, hálózati kommunikációra képes mérő, intelligens vezérlő vagy kapcsolódó szoftver jó eséllyel olyan termékvilágba tartozik, amelyet a CRA miatt tudatosan felül kell vizsgálni.

A security by design innentől nem szlogen

A rendelet kötelező kiberbiztonsági követelményeket ír elő a tervezés, fejlesztés, gyártás és fenntartás során. A biztonságot ezért nem lehet a projekt végén egy behatolásteszttel „rátenni” a kész termékre.

Már az architektúránál dönteni kell többek között:

  • milyen szolgáltatások érhetők el alapértelmezetten;
  • hogyan történik az eszköz egyedi azonosítása;
  • vannak-e gyári, közös vagy könnyen kitalálható hitelesítő adatok;
  • hogyan védett az adat átvitel közben és tároláskor;
  • hogyan korlátozható a hozzáférés;
  • hogyan naplózhatók a biztonsági események;
  • mi történik hibás vagy manipulált bemenet esetén;
  • hogyan állítható helyre biztonságos állapot.

A legkisebb támadási felület elve azt jelenti, hogy ami nem szükséges a termék működéséhez, az ne legyen alapértelmezetten elérhető.

A frissíthetőség termékfunkció

Egy hálózatba kapcsolt eszközt nem elég úgy megtervezni, hogy az értékesítés napján biztonságosnak tűnjön. Biztonságosan frissíthetőnek is kell lennie.

Ehhez szükséges lehet:

  • digitálisan aláírt, integritás-ellenőrzött firmware;
  • biztonságos frissítési csatorna;
  • verzió- és kompatibilitáskezelés;
  • hibás frissítés utáni visszaállítás;
  • tömeges, de kontrollált eszközmenedzsment;
  • frissítési napló és telepítési státusz;
  • a támogatási időszak egyértelmű közlése.

Az OTA-frissítés önmagában nem jelent biztonságot. Ha nincs aláírás-ellenőrzés, jogosultságkezelés, rollback vagy telepítési bizonyíték, akkor maga a frissítési mechanizmus válhat támadási felületté.

Sérülékenységkezelés a teljes támogatási időszakban

A CRA egyik lényeges változása, hogy a termékbiztonságot folyamatként kezeli. A gyártónak képesnek kell lennie sérülékenységek fogadására, értékelésére, javítására és kommunikálására.

Ehhez cégen belül is működő rend szükséges:

  • ki fogadja a biztonsági bejelentést;
  • hogyan történik a súlyosság és érintettség értékelése;
  • mely termékverziók érintettek;
  • milyen komponens okozza a problémát;
  • hogyan készül és tesztelődik a javítás;
  • hogyan jut el az ügyfelekhez;
  • hogyan dokumentálható a lezárás.

Egy e-mail cím önmagában nem sérülékenységkezelési folyamat.

Tudni kell, mi van a firmware-ben

A modern firmware és szoftver ritkán készül teljesen saját kódból. Nyílt forrású könyvtárak, operációs rendszerkomponensek, hálózati stackek és gyártói SDK-k épülnek egymásra.

Ha egy ezek közül sérülékennyé válik, a gyártónak tudnia kell, mely termékek és verziók érintettek. Ehhez rendezett függőség- és komponensnyilvántartás szükséges. A szoftver-összetevők jegyzéke, azaz SBOM ebben fontos eszköz lehet.

Az SBOM azonban csak leltár. Értéket akkor ad, ha összekapcsolódik a verziókezeléssel, a sérülékenységi információkkal, az érintett eszközállománnyal és a frissítési folyamattal.

A jelentési kötelezettséghez észlelési képesség kell

2026. szeptember 11-től a gyártókra jelentési kötelezettség vonatkozik bizonyos aktívan kihasznált sérülékenységek és súlyos biztonsági események esetén. A részletes eljárást és az aktuális hatósági útmutatást a gyártónak a saját szerepe és terméke szerint kell követnie.

Gyakorlati szempontból azonban egy dolog biztos: nem lehet határidőben jelenteni azt, amit a szervezet nem képes észlelni, belsőleg eszkalálni és a termékverziókhoz kapcsolni.

Ezért a jelentési folyamat előfeltétele:

  • termék- és verziónyilvántartás;
  • biztonsági kapcsolattartó;
  • incidensosztályozás;
  • döntési és jóváhagyási rend;
  • ügyfélkommunikáció;
  • bizonyítható eseménynapló.

A CE-jelölés mögött fejlesztési bizonyíték lesz

A CRA szerint a megfelelő termékek CE-jelölése azt is jelzi majd, hogy a kiberbiztonsági követelményeknek megfelelnek. A termék kockázati besorolásától függően eltérő megfelelőségértékelési eljárásra lehet szükség, bizonyos kategóriáknál bejelentett szervezet (notified body) bevonásával.

Ez dokumentált fejlesztési folyamatot kíván. Meg kell őrizni a kockázatértékelést, az architekturális döntéseket, a tesztek eredményeit, a komponensinformációkat, a sérülékenységkezelést és a kiadási bizonyítékokat.

Utólag nagyon nehéz hitelesen rekonstruálni, miért született egy biztonsági döntés évekkel korábban. A dokumentációt ezért a fejlesztéssel együtt kell építeni.

Mit jelent ez egy OrigSmart-típusú fejlesztésben?

Az OrigSmart hardver-, gateway- és platformképességei miatt a biztonság nem állhat meg az eszköz burkolatánál. A teljes rendszeréletciklust együtt kell kezelni:

  • egyedi hardver és firmware;
  • terepi kommunikáció;
  • eszközazonosság és konfiguráció;
  • biztonságos frissítés;
  • platformoldali jogosultság;
  • eseménynapló és monitoring;
  • incidens- és sérülékenységkezelés;
  • ügyféloldali üzemeltetési folyamat.

Ez a teljes értéklánc egyszerre jelent felelősséget és versenyelőnyt. Az a gyártó és integrátor, amely már a termék tervezésénél összekapcsolja a hardvert, a szoftvert, az üzemeltetést és a bizonyítható biztonsági folyamatokat, nem 2027 végén fog kapkodva megfelelőségi dokumentumokat gyártani.

A CRA lényege nem az, hogy több papír kerüljön az IoT-eszköz mellé. Hanem hogy a digitális termék a teljes támogatott életciklusa alatt kezelhető kiberbiztonsági kockázat maradjon.

Beszéljük át az Ön projektjét

Források

Megjegyzés: a cikk általános szakmai tájékoztatás, nem jogi vagy megfelelőségi tanácsadás.