---
title: "CRA-bejelentési kötelezettségek: a termékútlevél, a biztonsági bejelentés és a frissítési előzmények egyértelmű elkülönítése — qr3.app Blog"
description: "2026. szeptember 11-től CRA-bejelentési kötelezettségek alkalmazandók. Így különítik el a gyártók a termékútlevelet, a bizalmas bejelentést és a frissítési előzményeket."
canonical: "https://qr3.app/hu/blog/cra-reporting-product-data-separation/"
lang: "hu"
robots: "index,follow,max-image-preview:large,max-snippet:-1"
---

# CRA-bejelentési kötelezettségek: a termékútlevél, a biztonsági bejelentés és a frissítési előzmények egyértelmű elkülönítése — qr3.app Blog

> 2026. szeptember 11-től CRA-bejelentési kötelezettségek alkalmazandók. Így különítik el a gyártók a termékútlevelet, a bizalmas bejelentést és a frissítési előzményeket.

Canonical: <https://qr3.app/hu/blog/cra-reporting-product-data-separation/>

[← Blog](/hu/blog/) [DPP Practice](/hu/blog/category/dpp-practice/)

2026. augusztus 2. 6 perc olvasás [DPP Practice](/hu/blog/category/dpp-practice/) [cyber-resilience-act](/hu/blog/tag/cyber-resilience-act/)[sicherheitsmeldungen](/hu/blog/tag/sicherheitsmeldungen/)[produktdaten](/hu/blog/tag/produktdaten/)[digitaler-produktpass](/hu/blog/tag/digitaler-produktpass/)[security-updates](/hu/blog/tag/security-updates/)

# CRA-bejelentési kötelezettségek: a termékútlevél, a biztonsági bejelentés és a frissítési előzmények egyértelmű elkülönítése

2026. szeptember 11-től CRA-bejelentési kötelezettségek alkalmazandók. Így különítik el a gyártók a termékútlevelet, a bizalmas bejelentést és a frissítési előzményeket.

szerző: **QR3 Redaktion**

![CRA-bejelentési kötelezettségek: a termékútlevél, a biztonsági bejelentés és a frissítési előzmények egyértelmű elkülönítése](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/cra-reporting-product-data-separation/hero.png)

szeptember 11-én kezdődik a digitális elemeket tartalmazó termékek gyártóinak egyik legkorábbi operatív kötelezettsége a Cyber Resilience Act (CRA) alapján: az aktívan kihasznált sebezhetőségeket és a súlyos biztonsági incidenseket az új központi bejelentési platformon kell bejelenteni. Ez több egy új megfelelési határidőnél. Néhány órán belül össze kell vezetni a termékazonosítást, az érintett piacokat, a műszaki értékelést és az intézkedéseket.

Egy digitális termékútlevél vagy QR-kóddal összekapcsolt termékoldal segíthet az eszköz egyértelmű hozzárendelésében, valamint abban, hogy a felhasználókat később értesítsék egy frissítésről. Ez azonban sem nem a jogszabály szerinti bejelentési csatorna, sem nem a bizalmas exploitadatok megfelelő tárolási helye. A gyártóknak ezért már most el kell különíteniük három adatútvonalat: a hatósági bejelentést, a nyilvános termékinformációt és a belső frissítési előzményeket.

## Az új aktualitás: a július 27-i és 31-i iránymutatások

Az Európai Bizottság közzétette [első átfogó CRA-iránymutatását 2026. július 27-én](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation). Többek között a bejelentési kötelezettségekkel, a kockázatértékeléssel, a támogatási időszakokkal és a lényeges változtatásokkal foglalkozik. Az iránymutatás nem kötelező erejű, de 67 példával pontosítja, hogyan alkalmazhatják a vállalatok a rendeletet a gyakorlatban.

Négy nappal később, július 31-én az ENISA frissítette a [Single Reporting Platformra vonatkozó információit](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp). Itt már megtalálható a tervezett folyamat, a tervezett beviteli mezők és a regisztrációra vonatkozó útmutatás. A platformnak 2026. szeptember 11-ig működőképessé kell válnia; a Bizottság tájékoztatása szerint a funkcionális és biztonsági tesztek már zajlanak.

Az időbeli ütemezés fontos: a CRA fő kötelezettségei alapvetően 2027. december 11-től alkalmazandók. A bejelentési kötelezettségeket tartalmazó 14. cikk azonban már 2026. szeptember 11-től hatályos. Ezt egyaránt megerősíti a [2024/2847/EU rendelet 71. cikke](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847), valamint a Bizottság CRA-bejelentési eljárásról szóló, július 31-én frissített [áttekintése](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting).

## Három adatterület egy túlterhelt termékútlevél helyett

A CRA-bejelentés és a nyilvános termékoldal eltérő célokat szolgál. Ha mindkettőt egyetlen adatkészletben képezik le, fennáll annak a veszélye, hogy az incidenscsapat számára túl kevés információ áll rendelkezésre, vagy túl sok érzékeny részlet kerül a nyilvános webre.

### 1. Bizalmas bejelentés az SRP, a CSIRT és az ENISA részére

A Single Reporting Platform a jogszabály szerinti belépési csatorna. Két eseménytípust kell bejelenteni: az aktívan kihasznált sebezhetőséget, amelynél megbízható bizonyítékok állnak rendelkezésre a jogosulatlan kihasználásra, valamint a súlyos incidenst, amely az adatok vagy funkciók rendelkezésre állását, hitelességét, integritását vagy bizalmasságát érinti.

A bejelentés nem csupán a termék megnevezését tartalmazza. Az ENISA többek között az érintett tagállamokat, az első értékelést, a már megtett ellenintézkedéseket, a lehetséges felhasználói intézkedéseket és az információ érzékenységét is felsorolja mezőként. A későbbi szakaszok a súlyossági fokot, a hatásokat, a támadóra vonatkozó információkat és a biztonsági frissítés műszaki részleteit is tartalmazhatják. Az ilyen információk nem valók automatikusan egy szabadon elérhető DPP-oldalra.

### 2. Nyilvános termék- és biztonsági információ

A nyilvános adatútvonal más kérdésekre ad választ: Melyik termékkel és verzióval rendelkezem? Továbbra is támogatott? Elérhető biztonsági frissítés? Mit kell konkrétan tennem felhasználóként? Erre alkalmas lehet egy QR-kód vagy más adathordozó mögött elérhető stabil termékoldal.

A nyilvános oldal csak jóváhagyott információkat jelenítsen meg: az érintett modell- és verziótartományokat, az elérhető biztonságos verziót, a telepítési útmutatót, a támogatási elérhetőséget és a közzététel időpontját. Az exploit részletei, a belső észlelési szabályok, a javítatlan támadási utak és a személyes incidensadatok a védett eljárásban maradnak. A nyilvános figyelmeztetésről nem a QR-kód dönt: a CRA 17. cikke alapján a koordináló CSIRT tájékoztathatja a nyilvánosságot, illetve erre kérheti a gyártót, ha ez a megelőzéshez vagy a visszaszorításhoz szükséges.

### 3. Belső frissítési és bizonyítéktörténet

A harmadik útvonal a nyomon követhető munkadokumentáció. Összekapcsolja a termékazonosítót, a hardver- és szoftververziót, a szoftverjegyzéket, a tudomásszerzés időpontját, a triázsdöntéseket, a bejelentési szinteket, a javítás jóváhagyását és a nyilvános közlést. Ennek az előzménynek verzióznia kell a módosításokat, nem pedig csendben felülírnia a korábbi értékeléseket.

Egy DPP-üzemeltetés számára ez a különbség központi jelentőségű: a nyilvános nézet az aktuálisan jóváhagyott állapotot mutatja, a belső előzmény pedig bizonyítja, hogyan jött létre. Aki már eseményalapon kezeli a termékadatokat, ugyanazt az elvet alkalmazhatja, mint a [DPP-frissítéseknél és webhookoknál](https://qr3.app/de/blog/dpp-webhooks-automation/): egy esemény további folyamatokat indít el, de minden fogadó csak a szerepéhez kijelölt mezőket kapja meg.

## A CRA-óra a tudomásszerzéssel indul

A 14. cikk lépcsőzetes határidőkkel dolgozik. Aktívan kihasznált sebezhetőség esetén indokolatlan késedelem nélkül, legkésőbb a tudomásszerzéstől számított 24 órán belül korai figyelmeztetés szükséges. Ezt 72 órán belül részletesebb sebezhetőségi bejelentés követi. A zárójelentésnek legkésőbb 14 nappal azután kell rendelkezésre állnia, hogy egy korrekciós vagy kockázatcsökkentő intézkedés elérhetővé vált.

Súlyos biztonsági incidens esetén szintén 24 óra áll rendelkezésre a korai figyelmeztetésre, és 72 óra az incidens bejelentésére. A zárójelentés a 72 órás bejelentést követő egy hónapon belül készül el. A határidők tehát nem egy CVE közzétételétől és nem a következő rendes kiadástól, hanem attól az időponttól futnak, amikor a gyártó tudomást szerzett az esetről.

A gyakorlatban egyértelmű folyamat javasolt:

1. A támogatástól, monitorozásból, kutatásból vagy az ellátási láncból érkező bejelentés rögzítése időbélyeggel.

2. A termék és a verzió feloldása stabil belső termékazonosítóra.

3. A kihasználás, illetve az incidens súlyosságának értékelése az illetékes csapat által.

4. A 24 órás adatkészlet előállítása a megerősített minimális adatokból, majd benyújtása az SRP-n keresztül.

5. A műszaki ismeretek kiegészítése a 72 órás szintig az eredeti állapot megőrzésével.

6. A javítás, a felhasználói intézkedés és a nyilvános tájékoztatás külön-külön történő jóváhagyása.

7. A zárójelentés és a belső előzmény összekapcsolása.

Ezt a láncot szeptember előtt gyakorlatként végig kell játszani. Az ENISA rámutat, hogy a szervezetek automatizálhatják belső folyamataikat és adatbázisaikat, a platform azonban induláskor nem kínál majd API-t. Ezért reálisabb egy export- és négyszemközti ellenőrzési folyamat, mint egy ellenőrizetlen közvetlen integráció.

## Egy közös termékazonosító, de elkülönített hozzáférési jogok

Az elkülönítés nem jelenti három egymással össze nem kapcsolt másolat kezelését. Jobb megközelítés egy közös, megváltoztathatatlan termékreferencia szerepköralapú nézetekkel.

Legalább a következő hozzárendeléseknek rendelkezésre kell állniuk:

- belső termékazonosító, valamint modell-, tétel- vagy sorozatazonosító;

- hardver-, firmware- és szoftververzió;

- azok a tagállamok, amelyekben az érintett kivitel elérhető volt;

- a biztonsági értékelés állapota és a tudomásszerzés időpontja;

- hivatkozások a 24 és 72 órás bejelentésre, valamint a zárójelentésre;

- jóváhagyott felhasználói intézkedés és biztonságos célverzió;

- a nyilvános termékoldal közzétételi állapota.

Az engedélyezést mezőszinten kell kialakítani. Az incidenscsapatnak és a CRA-felelősöknek a teljes dokumentációra szükségük van. A támogatásnak és az értékesítésnek jóváhagyott cselekvési útmutatóra van szüksége. A felhasználók csak a nyilvános bejelentést látják. A QR-kód ideális esetben csupán egy stabil termékcímet továbbít; a mögötte álló platform az állapot és a szerepkör alapján dönti el, mely információt szolgáltatja.

## Mit kell a gyártóknak szeptemberig tesztelniük?

Egy hasznos tesztesethez nincs szükség valódi sebezhetőségre. Válasszanak egy hálózatba kapcsolt terméket, egy érintett firmware-verziót és három tagállamot. Szimulálják a tudomásszerzést egy munkanapon, és ellenőrizzék:

- Meg tudja erősíteni a csapat 24 órán belül a terméklefedettséget és a minimális adatokat?

- Egyértelmű, hogy ki férjen hozzá képviselőként az SRP-hez EU Loginen keresztül?

- Kiegészíthetők a 72 órás információk anélkül, hogy bizalmas részletek nyilvánosságra kerülnének?

- A javítás jóváhagyása ellenőrzött felhasználói tájékoztatást eredményez minden szükséges nyelven?

- Stabil marad a nyilvános URL, ha a verzió és az intézkedések változnak?

- Nyomon követhető, hogy ki, mikor és melyik állapotot hagyta jóvá?

Az utóbbi ponthoz következetes, verziózott adatkezelés segít. A qr3 [folyamatos DPP-frissítésről szóló cikke](https://qr3.app/de/blog/howto-20260701/) bemutatja az alapelvet: az identitás változatlan marad, miközben a szakmai adatokat ellenőrzötten vezetik tovább. A CRA-folyamatban ehhez szigorúbb bizalmassági és jóváhagyási réteg társul.

## Összegzés: a termékútlevél elosztó, nem bejelentési hely

Az új iránymutatások működés közben is értelmezhetővé teszik a szeptemberi határidőt. A gyártóknak nem kell bizalmas sebezhetőségi adatbázist építeniük a digitális termékútlevelükbe. Ehelyett megbízható átmenetre van szükségük három egyértelműen elkülönített terület között: hatósági bejelentés, belső bizonyítékok és jóváhagyott felhasználói információ.

Egy közös termékazonosító összetartja ezeket a területeket. A szerepkörök, a jóváhagyások és a verziózás megakadályozza, hogy bizalmas részletek kerüljenek ki, vagy hogy a felhasználók túl későn értesüljenek egy elérhető intézkedésről. A QR-kód továbbra is hasznos, de tudatosan észrevétlen marad: tartósan a megfelelő termékkörnyezethez vezet. A tényleges CRA-megfelelés a mögötte álló folyamatokban jön létre.

## Források

- [Európai Bizottság: Új CRA-iránymutatás, közzétéve 2026. július 27-én](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation)

- [Európai Bizottság: CRA-bejelentési kötelezettségek, frissítve 2026. július 31-én](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)

- [ENISA: Single Reporting Platform és GYIK, frissítve 2026. július 31-én](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)

- [EUR-Lex: 2024/2847/EU rendelet, különösen a 14., 16., 17. és 71. cikk](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847)

## Kapcsolódó cikkek

- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/construction-dpp-bim/hero.png) DPP Practice Építőipari termékútlevél és BIM: így kapcsolódik össze a(z) DPP és az épületadatok Az új építési termékekről szóló rendelet összekapcsolja a Digitális Termékútlevelet a BIM-mel. Mit kell a gyártóknak tudniuk a nyílt adatokról, a szerepekről és a hosszú távú elérhetőségről?](/hu/blog/construction-dpp-bim/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-dpp-v2-nfc-2d-code/hero.png) GS1 Standards A GS1 DPP-szabvány v2 ideiglenes változata: az NFC kiegészíti a 2D-kódot A GS1 DPP-szabvány v2 ideiglenes változata az NFC-t csak a 2D-kód mellett engedi. Mit jelent ez az identitás, a QR/Data Matrix és a tesztelés szempontjából.](/hu/blog/gs1-dpp-v2-nfc-2d-code/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/ppwr-one-data-carrier-dpp/hero.png) QR Code Tech PPWR, QR-kód és DPP: Miért kell elegendőnek lennie egyetlen adathordozónak A PPWR nyílt digitális adathordozókat ír elő a csomagolási információkhoz. Így a csomagolás, a válogatás és a termékútlevél egy stabil belépési ponton kapcsolható össze.](/hu/blog/ppwr-one-data-carrier-dpp/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/toy-dpp-eu-2025-2509/hero.png) Industry News Digitális termékútlevél játékokhoz: amit a gyártóknak 2030-ig elő kell készíteniük Az uniós játékrendelet 2030-tól a DPP-t megfelelőségi igazolássá teszi. Mit készítsenek elő a gyártók a modellekhez, a biztonsághoz, az online kereskedelemhez és a vámhoz.](/hu/blog/toy-dpp-eu-2025-2509/)

[← Minden cikk](/hu/blog/) [Kezdés ingyen](https://app.qr3.app/sign-up)