ISO 15118 tanúsítvány életciklus-kezelése 2026-ban: a TLS sürgősségétől a CRA-megfelelőségig

TL;DR (Vezetői intézkedés összefoglalása)

• A TLS átváltás egy kemény határ (nem javaslat): Tól 2026. február 24.A DigiCert fogja ne fogadj el érvényes nyilvános TLS-tanúsítványkérelmek több mint 199 nap, és az ettől a dátumtól kezdve kiállított tanúsítványok rendelkeznek 199 napos maximális érvényességi időEz a gyakorlati átállási lehetőség sok üzemeltető számára – a megújulási sebesség azonnal megnő.
• A 200→100→47 napos ütemterv már meg van határozva: A CA/Browser Forum alapkövetelményei fokozatos csökkentést határoztak meg: 200 nap 2026. március 15-től, 100 nap 2027. március 15-től, és 47 nap 2029. március 15-től.
• A CRA megfelelőségi órát ad hozzá: A hitelminősítő intézetek jelentéstételi szabályai előírják korai figyelmeztetés 24 órán belül, teljes körű értesítés 72 órán belül, és meghatározta a végső jelentési ablakokat az aktívan kihasznált sebezhetőségek és súlyos incidensek esetében.
• A legnagyobb rejtett kockázat nem a lejárat: A szisztémás hibamód a következő: bizalomhorgony sodródás—a roots/intermediates/cross-signing változások nincsenek szinkronban az EVSE, a helyi vezérlők és a háttérbeli érvényesítési útvonalak között.
• Első befektetés az üzemidő megőrzése érdekében: Rendszervezérelt automatizálás (ACME + készletgazdálkodás + szakaszos bevezetés) plusz élfolytonosság (helyi validáció/gyorsítótár, bizonyítéknaplók és időszinkronizálási irányítás).

Bevezetés: 2026-ban a Plug & Charge működőképes rendszerré vált

2026-ban a Plug & Charge (P&C) már nem csak egy „beállítom és elfelejtem” funkció, hanem egy folyamatos operációs rendszer.
Az ISO 15118 megbízhatósági síkot (PKI + TLS + visszavonás + frissítések) mostantól olyan idővonalak szabályozzák, amelyek nem tolerálják a manuális munkafolyamatokat.

A rendszerhatárok megértéséhez – miért felelős az ISO 15118 szabvány az OCPP szabványhoz képest – kezdjük a kapcsolódó cikkünkkel:
ISO 15118 vs. OCPP telepítési valóság 2026-ban.

A közvetlen nyomás a TLS életciklus-tömörítésMűködési szempontból nem lehet „márciusig várni”.
A DigiCert fogja ne fogadj el nyilvános TLS-kérések, amelyek meghaladják a 199 nap kezdő 2026. február 24.,
és az ettől a naptól kezdve kiállított tanúsítványok 199 napos maximális érvényességi idő.
A DigiCert egy kritikus működési részletet is kiemel: a maximálisan megengedett érvényességet a kibocsátás dátuma, nem a rendelés leadásakor.

Ugyanakkor az EU kiberbiztonsági ellenálló képességről szóló törvénye (CRA) bevezet egy második órát: a jelentéstételi szabályok előírják
24 órás korai figyelmeztetés és 72 órás értesítés az aktívan kihasznált sebezhetőségek és a digitális elemeket tartalmazó termékeket érintő súlyos incidensek esetén.

Ez az útmutató az ISO 15118 tanúsítványok ezen korlátozások melletti működtetésének architektúrájára és kockázatkezelési mechanizmusaira összpontosít.

2024–2026 mérföldkövek és szükséges intézkedések (szöveges Gantt)

Működési megjegyzés: 2026. február 24. gyakran az igazi átállási pont, mivel a kibocsátási viselkedés ezután megváltozik a főbb CA-k esetében.

Szabályzati megjegyzés: A szakaszos élettartam-csökkentéseket az Alapkövetelmények (200/100/47 nap) határozzák meg.

Az életciklus-tájkép: Kiépítés → Működés → Megújítás → Visszavonás

Életciklus térkép (amit működtetni kell tudni)

1. OEM-kiépítés: Generált/befecskendezett kulcsok; a bizalom gyökere létrejött (HSM/biztonságos elem).
2. Szerződéskötés: Felhasználói szerződésekhez kötött szerződéses tanúsítványok (ökoszisztéma-függő).
3. EVSE üzembe helyezése: Megbízhatósági tároló alapértékek, szabályzatok és időszinkronizációs alapértékek létrehozása.
4. Működési validáció: TLS kézfogások, láncépítés, visszavonás-ellenőrzés, szabályzat betartatása.
5. Megújítás / újbóli kiadás: Automatizálás + fokozatos bevezetés + visszagörgetés.
6. Visszavonás / incidensre adott válasz: Kompromittálás/rossz kibocsátás/kihasználás → visszavonás/rotáció/helyreállítás.
7. Felépülés és megbékélés: A szolgáltatás visszaállítása az auditálhatóság és a számlázási integritás megőrzése mellett.

Alulbecsült kudarcpont: Trust Anchor Drift

A több OEM-t tartalmazó környezetekben a legtöbb „rejtélyes P&C-hiba” nem egyetlen lejárt tanúsítványra vezethető vissza – hanem…
elérési út érvényesítési hibák a bizalmi horgony eltolódása okozza:

• Új gyökerek/köztesek jelennek meg (többgyökerű valóság).
• Keresztbe adás A változások megváltoztatják a megvalósítható láncokat.
• A háttérbeli megbízhatósági tárolók gyorsabban frissülnek, mint az EVSE/helyi vezérlők.
• A visszavonási műtermékek a szélén elavulnak.

A bizalmi horgonyok frissítéseit biztonságkritikus változtatási folyamatként kezelje:

• Verzióval ellátott bizalmi tárolók
• Kanári bevezetés
• Visszavonási tervek
• Telemetria érvényesítési hibák esetén kibocsátó/sorozatszám/elérési út szerint
• Egy explicit tulajdonos a „ki mit és mikor frissít” beállításhoz

Keresztjelzési és útépítési hibák (2026-os valóság): Többgyökerű ISO 15118 ökoszisztémákban,
A Plug & Charge gyakran nem azért hibázik, mert egy tanúsítvány érvénytelen, hanem azért, mert az EVSE nem tud érvényes tanúsítványt létrehozni.
tanúsítvány elérési útja kereszt-aláírási változások után (új közbenső szolgáltatók, áthidaló hitelesítésszolgáltatók, újra kiadott láncok).
Ahogy egyre több OEM és PKI-tartomány csatlakozik, az elérési utak bonyolultsága növekszik. Ha a peremhálózati megbízhatóság tárolja (EVSE/helyi vezérlők) a...
A háttérbeli frissítések elmaradása miatt a TLS kézfogások akkor is sikertelenek lehetnek, ha a háttérbeli tanúsítványok önmagukban „érvényesnek” tűnnek.

1. ábra (Ajánlott vizualizáció): Útvonal-érvényesítés a Multi-Root ISO 15118 szabványban

(V2G Root / OEM Root / Szerződéses Root, köztes termékek és kereszt-előjeles hidak megjelenítése.)
Jelölje ki, hol szakítja meg az újonnan aláírt köztes azonosító az útvonalépítést az EVSE-n, ha a megbízható tárolók nem frissülnek szinkronban.

Fő üzenet: A legtöbb, a „PKI”-ra fogott P&C-kiesés valójában elérési út érvényesítési hibák a kereszt-aláírási sodródás és a szinkronizálatlan bizalmi tárolók által vezérelve.

ACME és automatizálás: Ember által vezetett vs. rendszer által vezetett 199/200 napos élettartam alatt

Miért válik a manuális megújítás determinisztikus kiesésgenerátorrá?

A rövid élettartamok folyamatos megújításokat tesznek lehetővé. A DigiCert lépése a következőre: 199 nap 2026. február 24-től
azonnal működőképessé teszi ezt számos flotta számára. A tágabb iparági ütemterv pedig már meg van határozva:
200 nap (2026. március 15-től), majd 100 nap, akkor 47 nap.

Bármely flotta esetében a megújítási események a következőképpen skálázódnak:

Megújítási események évente ≈ N × (365 / L)

Ahol É a TLS végpontok száma és L a tanúsítvány élettartama (nap).
Mint L csökken, az ember által vezetett megújulás matematikailag összeegyeztethetetlenné válik az üzemidő-célokkal.

Forgatókönyv (Panel szintű méretezés)

Egy CPO számára, amely működik 5000 végpontegy 199 napos élettartam a következőket jelenti:

Megújítási események/év ≈ 5000 × (365 / 199) ≈ 9171

Ebben a léptékben még egy 1% emberi hibaszázalék nagyjából annyit tesz ki, mint
92 tanúsítványhoz kapcsolódó leállás évente– a csúcsforgalmi időszakra gyakorolt hatás figyelembevétele előtt,
SLA-büntetések, vagy kaszkád jellegű hibák egy hubon keresztül.

ACME a töltőhálózatokban: mit kellene automatizálnia

Az ACME (Automated Certificate Management Environment) a megújításokat szabályzatvezérelt műveletekké alakítja a következőkhöz:

• EVSE ↔ háttérbeli TLS
• Helyi vezérlő / Edge Proxy TLS
• Helyi átjárók és hub vezérlők

Rendszervezérelt munkafolyamat (architektúra minta)

1. Leltár minden végpont (kibocsátó, sorozatszám, lánc, lejárat, utolsó rotáció).
2. Megújítási szabályzat (fix küszöbértéknél megújítható, nem pedig „lejárathoz közeli időpontban”).
3. Hardveres támogatású kulcsok ahol lehetséges; kerülje a privát kulcsok exportálását.
4. Fokozatos bevezetés állapotfelméréssel (kézfogás + engedélyezés + munkamenet indítása).
5. Automatikus visszagörgetés a megnövekedett meghibásodási arányokról.
6. Bizonyítéknaplók minden kiadáshoz/telepítéshez (megfelelőségi szintű nyomon követhetőség).

Ember által vezetett vs. rendszer által vezetett

• Ember által vezetett: Jegyek, táblázatok, késői megújítások, kétértelmű tulajdonjog, kockázatos vészhelyzeti változtatások.
• Rendszervezérelt: Determinisztikus szabályzatok, automatizált kiadás, ellenőrzött bevezetés, folyamatos telemetria, auditálható bizonyítékok.

Visszavonási ellenőrzések: a „P&C Killer” (CRL vs. OCSP, gyenge hálózatok és védhető szabályzatok)

Miért buknak meg az OCSP/CRL a szervizekben és a telephelyeken?

• Gyenge/szakaszos LTE/5G
• Korlátozott kilépés (tűzfalak/hitelesítési portálok)
• Késés-érzékeny validációs lépések
• Külső függőségek (OCSP válaszadók, CRL terjesztési pontok)

Eredmény: Az EVSE elindíthat egy munkamenetet, de nem fejeződik be visszavonási érvényesítés megbízhatóan.

CRL vs. OCSP: gyakorlati kompromisszumok

• CRL: nagyobb mennyiségű letöltés, de gyorsítótárazható és ütemezetten frissíthető (jó a peremhálózati folytonosság szempontjából).
• OCSP: kérésenként könnyű, de gyakran élő elérhetőséget igényel a leggyengébb élen.

2026-ban a helyes testtartás rétegzett:

• Ütemezett CRL gyorsítótárazás a rugalmasság érdekében
• OCSP, ahol a kapcsolat megbízható
• Kifejezett szabályzat a leromlott körülményekre vonatkozóan

Miért egyre nehezebb megvédeni a „puha csődöt”?

Történelmileg a „soft-fail” (munkamenet engedélyezése, ha a visszavonási ellenőrzések időtúllépést okoznak) megőrizte a rendelkezésre állást.
2026-ban a soft-fail nehezebben igazolható, mert:

• Rövidebb élettartam (kisebb tolerancia az elavult feltételezésekkel szemben)
• A CRA jelentési órája szigorúbb incidensfegyelmet és bizonyítékgyűjtést ír elő

A védhető tervhez explicit, dokumentált szabályzat szükséges:

• Hard-fail nyilvános/magas kockázatú környezetekbe
• Kegyelem-bizonyítékokkal zárt flottákhoz (korlátozott ablak + kompenzáló vezérlők)
• Bizonyítékok naplózása minden megalázó döntésért

Architekturális mérséklések (minták, nem termékígéretek)

1. minta: Edge előellenőrzés + gyorsítótárazás

• Gyorsítótár CRL-ek meghatározott frissességi ablakokkal
• Gyorsítótár-köztes rendszerek és validált láncok
• Előzetes lehívás „jó internetkapcsolat” esetén

2. minta: OCSP tűzés (ahol megvalósítható)

Az OCSP tűzés a visszavonásbiztos kézbesítést a leggyengébb élről elmozdítja, csökkentve ezzel az élő függőséget a CA infrastruktúrától a munkamenet létrehozása során.

Megvalósítási megjegyzés (beágyazott valóság): EVSE környezetekben ellenőrizze a tűzéssel kapcsolatos bővítmény támogatását
a beágyazott TLS-veremben és a build konfigurációban (pl. mbedTLS, wolfSSL), és validálja a viselkedést a korábbi hardvereken,
mivel a jellemzők teljessége és a memória/RTOS korlátok eltérőek.

3. minta: Többgyökérű megbízhatósági irányítás

• Egységes megbízhatósági tároló frissítési csatorna több OEM-horgonyhoz
• Canary frissítések + visszavonás, ha az útvonalépítési hibák megnőnek

4. minta: Időszinkronizálás irányítása (nem alku tárgya)

• NTP-szabályzat (vagy adott esetben PTP)
• Sodródás-monitorozás és riasztási küszöbértékek
• Meghatározott viselkedés, ha az órák nem megbízhatóak

Offline folytonosság: a Plug & Charge funkció használható marad a felhőalapú peremhálózati kapcsolat megszakadása esetén is

Mi az offline folytonosság (és mi nem)?

Az offline folytonosság nem a „PKI megkerülését” jelenti. Ez egy szabályozott degradáció, amely megőrzi:

• Kulcsok és bizalmi tárolók integritása
• Számlázási és incidensekre adott válasz auditálhatósága
• Explicit korlátozások arra vonatkozóan, hogy mi validálható helyben (és mennyi ideig)

Helyi vezérlők / Edge proxyk, mint rendelkezésre állási primitívek

• Helyi megbízható gyorsítótárak (horgonyok/köztes elemek/CRL-ek) karbantartása
• Korlátozott helyi jogosultságkezelési szabályzatok érvényesítése
• Puffermérés/naplók későbbi egyeztetéshez
• Csökkentse a WAN robbanási sugarát azáltal, hogy helyi végpontként működik az EVSE számára

2. ábra (Ajánlott vizualizáció): Edge Proxy, mint megbízható gyorsítótár gyenge hálózati helyeken

(EVSE-k csatlakozása helyszíni Edge Proxyhoz/helyi vezérlőhöz. A proxy gyorsítótárban tárolt megbízhatósági horgonyokat/köztes elemeket tart fenn,
ütemezett CRL frissítés, időszinkronizálás-figyelés és bizonyítéknaplók; puffereli az eseményeket a felhőalapú CSMS/PKI-be, ha a kimenő kapcsolat instabil.)

Fő üzenet: A peremhálózati proxyk csökkentik a külső OCSP/CRL végpontoktól való élő függőséget, és lehetővé teszik a szabályozott offline folytonosságot a PKI megkerülése nélkül.

CRA és VMP: 2026 szeptemberétől kezdődő jelentéstételi határidőktől auditálható működési modell felé

CRA jelentéstételi szabályok: 24/72 órás rendszerhez igazodó tervezés

A hitelminősítő intézetek jelentéstételi szabályai előírják a gyártók számára, hogy értesítsék az aktívan kihasznált sebezhetőségekről és a súlyos, a hitelminősítést befolyásoló eseményekről.
a digitális elemeket tartalmazó termékek biztonságáról:

• Korai figyelmeztetés 24 órán belül a tudatosulás
• Teljes körű értesítés 72 órán belül
• Zárójelentés meghatározott időablakokon belül (az incidensosztálytól függően)

Tömeges visszavonás vagy bizalmi pont kompromittálódása által okozott nagymértékű Plug & Charge zavar jogosult lehet
súlyos incidensként, a hatástól és a kiaknázási bizonyítékoktól függően.

Sebezhetőségkezelési folyamat (VMP): minimálisan megvalósítható képességek

1. A flotta igazsága: eszköz + verzió leltár (EVSE firmware, vezérlőképek, megbízható tároló verziók).
2. SBOM integráció (dinamikus): Az SBOM telepíthető műtermékekhez van rendelve; folyamatos korreláció a sebezhetőségi információkkal.
3. VEX-vezérelt expozíciókezelés: Tartsa karban a VEX utasításokat a „jelenlegi, de nem kihasználható” és a „kihasználható a telepítésünkben” állapotok megkülönböztetésére, lehetővé téve a hiteles hatókör-meghatározást a T+24 órás időablakon belül.
4. Miért fontos a VEX a 24 órás rendszerben: Az SBOM megmondja, mi van jelen; a VEX segít meghatározni, hogy mi az kitermelhető, csökkentve a téves riasztásokat és megakadályozva, hogy az operatív csapatok a nem kihasználható zajokat üldözzék.
5. Felvétel és triázs: beszállítói figyelmeztetések, CVE-k, belső megállapítások; a kihasználhatóság és a kitettség prioritása.
6. T+24 órás hatókör-felmérési munkafolyamat: SBOM + VEX + leltárösszegzés az érintett populációk azonosításához; kezdeti elszigetelési döntések; bizonyítékok összegyűjtése.
7. T+72h értesítési munkafolyamat: megerősített hatókör, enyhítések, bevezetési/visszaállítási terv, kommunikációs rekord.
8. Zárójelentés munkafolyamata: validációs bizonyíték + kiváltó ok + megelőző fejlesztések a korrekciós intézkedés elérhetősége után.
9. Patch kadencia mérnökség: szakaszos bevezetés, visszagörgetési tervek, aláírt összetevők, ellenőrző kapuk.
10. A bizalmi lánc érvényesítése: biztonságos rendszerindítás + biztonságos firmware-frissítések; HSM/biztonságos elemekben védett aláírási kulcsok.
11. Bizonyítékokon alapuló naplózás: tanúsítványesemények, megbízhatósági tároló változásai, visszavonási hibák, időszinkronizálás állapota.

Magas súlyosságú bizalmi forgatókönyv: Ha a visszavonást egy feltört gyökér- vagy kibocsátókulcs váltja ki,
kezelje azt súlyos bizalmi incidensként, amely azonnali elszigetelést és a flotta egészére kiterjedő bizalmi adattárolási intézkedéseket igényel,
és a CRA-kkal összehangolt jelentéstételi készség a hatás- és hasznosítási bizonyítékok alapján.

CRA incidensre adott válasz visszaszámláló ellenőrzőlista (működési sablon)

T+0 (Észlelés / Tudatosság)

• Bizonyítékok befagyasztása: naplók, tanúsítványesemények, megbízható tároló verziók, időszinkronizálás állapota
• Érintett felületek azonosítása: EVSE firmware, helyi vezérlők, háttérbeli TLS végpontok
• PKI-szolgáltató / háttérbiztonsági kapcsolattartó megkeresése

T+24h (Korai figyelmeztető készültség)

• Fő célkitűzés: Használat SBOM + VEX + flottakészlet az érintett populáció meghatározása és bizonyítékokkal alátámasztott korai figyelmeztetés benyújtása
• Elkülönítés eldöntése: visszavonás/rotáció, megbízható tárolás visszagörgetése, webhely elkülönítése
• Korai figyelmeztető csomag tervezete: hatókör, folyamatban lévő enyhítések, ideiglenes helyzet

T+72h (Teljes körű értesítési készenlét)

• Érintett populációk régiónként/helyszínenkénti megerősítése; kármentesítési terv + megvalósítási módszer megadása
• Ügyfél/üzemeltető kommunikációs és eszkalációs nyilvántartás készítése

Zárójelentési időszak

• A CRA követelményeinek megfelelő zárójelentés benyújtása (az időzítés az incidens osztályától függ)
• Javítás utáni validációs bizonyítékok + tanulságok

Költség- és kockázatszámítás (Sablonok, amelyeket beilleszthet a flottájába)

Kézi megújítási munkaköltség-modell

Legyen:

• É = TLS végpontok száma (EVSE + vezérlők + átjárók + felügyelt háttércsomópontok)
• L = tanúsítvány élettartama (nap)
• t = emberi idő megújulásonként (óra)
• c = teljes terhelésű munkaköltség (USD/óra)

Költség_munka ≈ N × (365 / L) × t × c

Kimaradási kockázati modell (lejárat vagy sikertelen telepítés)

Legyen:

• P_kisasszony = a ciklusonkénti elmulasztott/sikertelen megújítás valószínűsége
• H_down = várható állásidő órákban incidensenként
• C_óra = óránkénti üzleti hatás (kiesett bevétel, büntetések, SLA-jóváírások)

Költség_kimaradás ≈ P_kiesés × H_leállás × C_óra

Döntési útmutató: Online visszavonási ellenőrzések sikertelensége esetén (OCSP/CRL időtúllépés)

1. Nyilvános telephely vagy zárt flotta/telephely?
   • Nyilvános → előnyben részesítés Hard-fail (vagy szigorúan ellenőrzött kegyelem, csak bizonyítékokkal + kompenzáló kontrollokkal)
   • Flotta/telephely → Kegyelem-bizonyítékokkal korlátozott ablakok esetén elfogadható lehet
2. Előre látható-e a hálózat megbízhatósága?
   • Igen → Online OCSP/CRL + monitorozás
   • Nem → Edge előellenőrzés + gyorsítótárazás (CRL frissítési ablakok, gyorsítótárban tárolt láncok)
3. Csökkenthető az online függőség a munkamenetek alatt?
   • Ahol lehetséges → fogadj el OCSP tűzési minta (tolja közelebb a széléhez a védőréteget)
4. Van bizonyítéknaplózásuk + időszinkronizálási irányításuk?
   • Ha nem → először ezeket javítsd ki; a leromlott módú szabályzatokat nehéz megvédeni nélkülük

Gyakorlati felelősségi mátrix (a kimaradások megelőzésére szolgáló határok)

Szójegyzék

• PKI: Nyilvános kulcsú infrastruktúra (kibocsátás, validálás, bizalmi horgonyok, visszavonás)
• CSÚCSPONT: Automatizált tanúsítványkezelő környezet (automatizált kibocsátás/megújítás)
• OCSP / CRL: Online tanúsítványállapot-protokoll / Tanúsítvány-visszavonási lista
• OCSP tűzés: A szerver visszavonási bizonyítékot kínál az élő OCSP-függőség csökkentése érdekében.
• Bizalmi horgonyok: A validátorok által megbízható gyökér-/köztes tanúsítványok
• SBOM: Szoftver anyagjegyzéke (komponensleltár a sebezhetőségek hatókörének meghatározásához)
• BOSSZANT: Sebezhetőségi Kihasználhatósági eXchange (kihasználhatósági állapotjelentések)
• TLS 1.3: Modern TLS profil; a kézfogás + a tanúsítványérvényesítés továbbra is késleltetés-érzékeny
• VMP: Sebezhetőségkezelési folyamat (felvétel, prioritási sorrend, javítás, jelentéstétel, bizonyítékok)

Előretekintő kockázat: Kriptoagilitás és PQC-felkészültség

Míg 2026-ot a rövid TLS-élettartamok és a CRA-jelentések uralják, a töltőinfrastruktúráknak el kell kezdeniük az értékelést
kriptoagilitásHosszú élettartamú eszközök (járművek és töltők) esetében az architektúráknak el kell kerülniük a hardverfüggőséget azáltal, hogy biztosítják a következőket:
A HSM/biztonságos elemek és a beágyazott csomagok hardverfrissítés nélkül is támogatni tudják a jövőbeli algoritmus- és tanúsítványprofil-frissítéseket.

GYIK

Működhet offline is a Plug & Charge?

Részben – tervezési okokból. Az offline P&C (Programozás és Biztonság) szabályozott degradációt eredményez helyi bizalmi gyorsítótár használatával (horgonyok/köztes elemek/CRL-ek, ahol lehetséges).
explicit türelmi szabályzatok és pufferelt auditnaplók az egyeztetéshez. Nem kerülheti meg a PKI-t; csökkentenie kell az élő felhőfüggőséget
miközben megőrzi az integritást és az auditálhatóságot.

Milyen gyakran kell megújítanunk a 199/200 napos élettartamú tanúsítványokat?

Tervezzen évente több megújítási ciklust végpontonként. Sok üzemeltető számára az üzembe helyezési időszak a következő időpontban kezdődik:
2026. február 24. mivel a DigiCert maximálisan nyilvános TLS-tanúsítványokat fog kibocsátani 199 napos érvényessége ettől a dátumtól.
A tágabb ökoszisztéma szintjén az alapkövetelmények fokozatos csökkentést határoznak meg a 200/100/47 nap.

Mi okozza a hitelminősítő intézetek jelentéstételi kötelezettségét?

A hitelminősítő intézetek jelentéstételi szabályai előírják 24 órás korai figyelmeztetés és 72 órás értesítés aktívan kihasznált sebezhetőségek és súlyos incidensek esetén,
plusz a végső jelentési időszakok. A nagymértékű P&C bizalom megzavarása (pl. rosszindulatú visszavonás vagy érvényesítési kompromittálás) a jogosultság függvényében minősülhet.
hatás- és hasznosítási bizonyítékokon alapul; egy CRA-kész VMP-nek támogatnia kell SBOM + VEX + flottakészlet az első 24 órán belüli hatókör-felmérés.