ISO 15118 -sertifikaatin elinkaaren hallinta vuonna 2026: TLS-kiireellisyydestä CRA-vaatimustenmukaisuuteen

TL;DR (Toiminnan yhteenveto)

• TLS-katkaisu on kova raja (ei ehdotus): Alkaen 24. helmikuuta 2026DigiCert tulee lopeta hyväksyminen julkiset TLS-varmennepyynnöt voimassaololla yli 199 päivää, ja kyseisestä päivästä lähtien myönnetyillä todistuksilla on Enimmäisvoimassaoloaika 199 päivääTämä on käytännöllinen vaihto monille operaattoreille – uudistumisnopeus kasvaa välittömästi.
• 200→100→47 päivän tiekartta on jo määritelty: CA/Browser Forumin perusvaatimukset asettavat vaiheittaisen vähennyksen: 200 päivää 15. maaliskuuta 2026 alkaen, 100 päivää 15. maaliskuuta 2027 alkaenja 47 päivää 15. maaliskuuta 2029 alkaen.
• CRA lisää vaatimustenmukaisuuskellon: Luottoluokituslaitosten raportointisäännöt edellyttävät ennakkovaroitus 24 tunnin sisällä, täydellinen ilmoitus 72 tunnin kuluessaja määritteli lopulliset raportointiajat aktiivisesti hyödynnetyille haavoittuvuuksille ja vakaville vaaratilanteille.
• Suurin piilevä riski ei ole vanheneminen: Systeeminen vikatila on luottamusankkurin ajelehtiminen—juuritason/välitason/ristiinallekirjoituksen muutokset eivät ole synkronoituja EVSE:n, paikallisten ohjainten ja taustajärjestelmän validointipolkujen välillä.
• Ensimmäinen investointi käyttöajan suojaamiseksi: Järjestelmäjohtoinen automaatio (ACME + varastonhallinta + vaiheittainen käyttöönotto) sekä reunan jatkuvuus (paikallinen validointi/välimuisti, todistelokit ja aikasynkronoinnin hallinta).

Johdanto: Vuonna 2026 Plug & Charge -järjestelmästä tuli toimiva järjestelmä

Vuonna 2026 Plug & Charge (P&C) -toiminnosta tulee "aseta ja unohda" -ominaisuus. jatkuva käyttöjärjestelmä.
ISO 15118 -luottamustasoa (PKI + TLS + peruutus + päivitykset) säätelevät nyt aikajanat, jotka eivät siedä manuaalisia työnkulkuja.

Ymmärtääksesi järjestelmän rajat – mistä ISO 15118 vastaa vs. mistä OCPP on vastuussa – aloita oheiskappaleestamme:
ISO 15118 vs. OCPP:n käyttöönoton todellisuus vuonna 2026.

Välitön paine on TLS-elinkaaren pakkausOperatiivisesti et voi "odottaa maaliskuuhun".
DigiCert tulee lopeta hyväksyminen julkiset TLS-pyynnöt ylittävät 199 päivää alkaen 24. helmikuuta 2026,
ja siitä päivästä eteenpäin myönnetyillä todistuksilla on Enimmäisvoimassaoloaika 199 päivää.
DigiCert korostaa myös kriittistä operatiivista yksityiskohtaa: sallittua enimmäisvoimassaoloaikaa säätelee liikkeeseenlaskupäivä, ei tilauksen tekohetkellä.

Samaan aikaan EU:n kyberturvallisuusasetus (CRA) ottaa käyttöön toisen kellon: raportointisäännöt edellyttävät
24 tunnin ennakkovaroitus ja 72 tunnin ilmoitus aktiivisesti hyödynnettyjen haavoittuvuuksien ja vakavien häiriöiden varalta, jotka vaikuttavat digitaalisia elementtejä sisältäviin tuotteisiin.

Tämä opas keskittyy ISO 15118 -sertifikaattien arkkitehtuuriin ja riskienhallintaan näiden rajoitusten alaisena.

Vuosien 2024–2026 välitavoitteet ja vaaditut toimenpiteet (tekstikaavio)

Käyttöhuomautus: 24. helmikuuta 2026 on usein todellinen rajapäivä, koska liikkeeseenlaskukäyttäytyminen muuttuu silloin tärkeimmillä CA:illa.

Käytäntöhuomautus: Vaiheittaiset elinkaaren lyhennykset on määritelty perusvaatimuksissa (200/100/47 päivää).

Elinkaarikaavio: Käyttöönotto → Käyttö → Uudistaminen → Peruutus

Elinkaarikartta (mitä sinun on kyettävä käyttämään)

1. OEM-laitteiden käyttöönotto: Avaimet luotu/injektoitu; luottamuksen juuri luotu (HSM/suojattu elementti).
2. Sopimukseen ilmoittautuminen: Käyttäjäsopimuksiin sidotut sopimustodistukset (ekosysteemistä riippuvat).
3. EVSE:n käyttöönotto: Luotettavuussäilön perustasot, käytännöt ja aikasynkronoinnin perustasot on määritelty.
4. Toiminnan validointi: TLS-kättelyt, ketjun rakentaminen, peruutustarkistus, käytäntöjen valvonta.
5. Uusiminen / uudelleenmyöntäminen: Automaatio + vaiheittainen käyttöönotto + peruutus.
6. Peruutus / tapaukseen vastaaminen: Vaarantaminen/väärinkäyttö/hyväksyminen → peruuttaminen/kiertäminen/palauttaminen.
7. Toipuminen ja sovinto: Palauta palvelu säilyttäen samalla auditoitavuuden ja laskutuksen eheyden.

Aliarvioitu epäonnistumispiste: Luottamusankkurin ajautuminen

Useimmat "mystiset P&C-viat" usean OEM-laitteen ympäristöissä eivät johdu yhdestä vanhentuneesta sertifikaatista – ne ovat
polun validointivirheet luottamusankkurin ajautumisen aiheuttama:

• Uusia juuria/välimuotoja ilmaantuu (monijuurinen todellisuus).
• Ristiviittaus muutokset muuttavat mahdollisia ketjuja.
• Backend-luottamustallennustilat päivittyvät nopeammin kuin EVSE/paikalliset ohjaimet.
• Peruutusartefaktit vanhenevat reunalla.

Käsittele luottamusankkureiden päivityksiä turvallisuuskriittisinä muutosprosesseina:

• Versioidut luottamusvarastot
• Canary-julkaisut
• Palautussuunnitelmat
• Telemetria validointivirheistä myöntäjän/sarjanumeron/polun mukaan
• Selkeä omistaja "kuka päivittää mitä ja milloin" -asetukselle

Ristiviittausten ja polkujen rakentamisen epäonnistumiset (vuoden 2026 todellisuus): Monijuurisissa ISO 15118 -ekosysteemeissä
Plug & Charge -toiminto epäonnistuu usein virheellisen varmenteen sijaan siksi, että EVSE ei pysty rakentamaan kelvollista varmennetta.
varmennepolku ristiinallekirjoitusmuutosten jälkeen (uudet välittäjät, silta-CA:t, uudelleenjulkaistut ketjut).
Kun useampia laitevalmistajia ja PKI-verkkotunnuksia liittyy mukaan, polun monimutkaisuus kasvaa. Jos reunaluottamus tallentaa (EVSE/paikalliset ohjaimet)
viiveellä taustajärjestelmän päivitysten jälkeen, TLS-kättelyt voivat epäonnistua, vaikka taustajärjestelmän varmenteet näyttäisivät erikseen "kelvollisilta".

Kuva 1 (Suositeltu visualisointi): Polun validointi monijuurisessa ISO 15118 -standardissa

(Näytä V2G-juuri / OEM-juuri / sopimusjuuri, välituotteet ja ristimerkkisillat.
Korosta kohta, jossa juuri ristiin allekirjoitettu välituote katkaisee polun rakentamisen EVSE:ssä, jos luottamussäilöjä ei päivitetä synkronoidusti.

Ydinviesti: Useimmat PKI:n syyksi syytetyt sähkö- ja johtokatkokset ovat itse asiassa polun validointivirheet ristiallekirjoitusten ajautumisen ja synkronoimattomien luottamussäilöjen vuoksi.

ACME ja automaatio: Ihmisjohtoinen vs. järjestelmäjohtoinen 199/200 päivän elinkaaren aikana

Miksi manuaalisesta uusimisesta tulee deterministinen katkosten aiheuttaja

Lyhyet käyttöiät tekevät uusimisista jatkuvia. DigiCert siirtyy 199 päivää 24. helmikuuta 2026 alkaen
tekee tämän välittömästi toimintakuntoiseksi monille laivastoille. Ja laajempi alan aikataulu on jo määritelty:
200 päivää (15. maaliskuuta 2026 alkaen) sitten 100 päivää, sitten 47 päivää.

Minkä tahansa laivaston uusintatapahtumat skaalautuvat seuraavasti:

Uusimiskertoja vuodessa ≈ N × (365 / L)

Jossa N on TLS-päätepisteiden lukumäärä ja L on varmenteen voimassaoloaika (päivinä).
Kuten L pienenee, ihmisen johtamasta uudistamisesta tulee matemaattisesti yhteensopimatonta käyttöaikatavoitteiden kanssa.

Skenaario (hallitustason kokomääritys)

CPO:lle, joka toimii 5 000 päätepistettä199 päivän elinikä tarkoittaa:

Uusimiskertoja/vuosi ≈ 5000 × (365 / 199) ≈ 9 171

Tässä mittakaavassa, jopa 1%:n inhimillinen virheprosentti tarkoittaa suunnilleen
92 varmenteeseen liittyvää käyttökatkosta vuodessa—ennen ruuhka-ajan vaikutuksen huomioon ottamista,
SLA-rangaistukset tai kaskadoituvat viat keskittimen yli.

ACME latausverkoissa: mitä sen tulisi automatisoida

ACME (Automated Certificate Management Environment) muuttaa uusimiset käytäntöpohjaisiksi toimiksi seuraavissa tilanteissa:

• EVSE ↔ taustajärjestelmän TLS
• Paikallinen ohjain / Edge Proxy TLS
• Sivuston yhdyskäytävät ja keskittimen ohjaimet

Järjestelmäjohtoinen työnkulku (arkkitehtuurimalli)

1. Varasto jokainen päätepiste (liikkeeseenlaskija, sarjanumero, ketjunumero, voimassaoloaika, viimeisin rotaatio).
2. Uusimiskäytäntö ennen (uusi kiinteällä kynnysarvolla, ei "lähellä vanhenemista").
3. Laitteistopohjaiset avaimet Vältä yksityisten avainten vientiä aina kun se on mahdollista.
4. Vaiheittainen käyttöönotto terveystarkastuksin (kättely + valtuutus + istunnon aloitus).
5. Automaattinen palautus kohonneista epäonnistumisasteista.
6. Todistelokit jokaista julkaisua/käyttöönottoa varten (vaatimustenmukaisuustason jäljitettävyys).

Ihmisjohtoinen vs. järjestelmäjohtoinen

• Ihmisen johtamat: Tiketit, laskentataulukot, myöhäiset uusimiset, epäselvä omistajuus, riskialttiit hätämuutokset.
• Järjestelmälähtöinen: Deterministiset käytännöt, automatisoitu myöntäminen, hallittu käyttöönotto, jatkuva telemetria, auditoitava evidenssi.

Peruutustarkistukset: "P&C-tappaja" (CRL vs. OCSP, heikot verkot ja puolustettavat käytännöt)

Miksi OCSP/CRL epäonnistuu korjaamoilla ja varikoilla

• Heikko/ajoittainen LTE/5G
• Rajoitettu uloskäynti (palomuurit/captive portal -suojatut palvelimet)
• Latenssiherkät validointivaiheet
• Ulkoiset riippuvuudet (OCSP-vastaajat, CRL-jakelupisteet)

Tulos: EVSE voi aloittaa istunnon, mutta ei suorita sitä loppuun peruutuksen validointi luotettavasti.

CRL vs. OCSP: käytännön kompromissit

• Sulkuluettelo: raskaampia latauksia, mutta välimuistiin tallennettava ja aikataulun mukaisesti päivitettävä (hyvä reunayhteyksien jatkuvuuden kannalta).
• OCSP: kevyt pyyntöä kohden, mutta vaatii usein reaaliaikaista tavoitettavuutta heikoimmalla reunalla.

Vuonna 2026 oikea ryhti on kerrostettu:

• Ajoitettu CRL-välimuisti sietokyvyn parantamiseksi
• OCSP, jossa yhteys on luotettava
• Selkeä käytäntö heikentyneissä olosuhteissa

Miksi "pehmeän epäonnistumisen" puolustaminen on yhä vaikeampaa

Historiallisesti käytettävyys säilytettiin "soft-fail"-periaatteella (istunnon salliminen, jos peruutustarkistukset aikakatkaistaan).
Vuonna 2026 pehmeää kaatumista on vaikeampi perustella, koska:

• Elinajat ovat lyhyempiä (vähemmän toleranssia vanhentuneille oletuksille)
• CRA:n raportointikello pakottaa tiukempaan tapauskuriin ja todisteiden seurantaan

Puolustava suunnittelu edellyttää selkeää, dokumentoitua toimintatapaa:

• Kova vika julkisiin/korkean riskin ympäristöihin
• Armo todisteineen suljetuille ajoneuvokannoille (rajoitettu käyttöaika + korvaavat säätimet)
• Todisteiden kirjaaminen jokaisesta heikentyneestä päätöksestä

Arkkitehtuuriset lievennykset (mallit, ei tuotelupaukset)

Kuvio 1: Reunan esivalidointi + välimuisti

• Välimuistin CRL-luettelot, joissa on määritellyt tuoreusikkunat
• Välimuistin välivaiheet ja validoidut ketjut
• Esilataus "hyvän internetyhteyden" aikana

Kuvio 2: OCSP-nidonta (jos mahdollista)

OCSP-nidonta siirtää peruutussuojatun toimituksen pois heikoimmalta reunalta, mikä vähentää reaaliaikaista riippuvuutta varmentajainfrastruktuurista istunnon muodostamisen aikana.

Toteutushuomautus (upotettu todellisuus): EVSE-ympäristöissä varmista nidontaan liittyvän laajennuksen tuki
upotetussa TLS-pinossa ja koontikokoonpanossa (esim. mbedTLS, wolfSSL) ja validoi toiminta vanhoissa laitteistoissa,
koska ominaisuuksien täydellisyys ja muisti-/RTOS-rajoitukset vaihtelevat.

Kuvio 3: Monijuuritason luottamuksen hallinta

• Yhtenäinen luottamuskaupan päivityskanava useille OEM-ankkureille
• Canary-päivitykset + peruutus, kun polunrakennusvirheet lisääntyvät

Kuvio 4: Aikasynkronoinnin hallinta (ei-neuvoteltavissa)

• NTP-käytäntö (tai PTP tarvittaessa)
• Ajelehtimisen seuranta ja hälytyskynnykset
• Määritelty toimintatapa, kun kelloihin ei luoteta

Offline-jatkuvuus: Plug & Charge -ominaisuuden käyttökelpoisuus reunasta pilveen -katkosten aikana

Mitä offline-jatkuvuus on (ja mitä se ei ole)

Offline-jatkuvuus ei ole "PKI:n ohittamista". Se on hallittua heikentämistä, joka säilyttää:

• Avainten ja luottamussäilöjen eheys
• Laskutuksen ja tapauksiin reagoinnin auditoitavuus
• Selkeät rajoitukset sille, mitä voidaan validoida paikallisesti (ja kuinka kauan)

Paikalliset ohjaimet / Edge-välityspalvelimet saatavuusprimitiiveinä

• Ylläpidä paikallisia luotettavia välimuistitiedostoja (ankkureita/välikappaleita/CRL-luetteloita)
• Rajoitettujen paikallisten valtuutuskäytäntöjen noudattaminen
• Puskurimittaus/lokit myöhempää täsmäytystä varten
• Pienennä WAN-laajennussädettä toimimalla EVSE:n paikallisena päätepisteenä

Kuva 2 (Suositeltu visualisointi): Edge Proxy luotettuna välimuistina heikon verkon sivustoissa

(Näytä EVSE:t, jotka muodostavat yhteyden paikalliseen Edge Proxyyn/paikalliseen ohjaimeen. Välityspalvelin ylläpitää välimuistissa olevia luottamusankkureita/välipisteitä,
ajoitettu CRL-päivitys, aikasynkronoinnin valvonta ja todistelokit; se puskuroi tapahtumia pilvipohjaiseen CSMS/PKI-järjestelmään, kun nouseva linkki on epävakaa.)

Ydinviesti: Edge-välityspalvelimet vähentävät reaaliaikaista riippuvuutta ulkoisista OCSP/CRL-päätepisteistä ja mahdollistavat hallitun offline-jatkuvuuden ohittamatta PKI:tä.

CRA ja VMP: syyskuusta 2026 raportointiajoista lähtien auditoitavaan toimintamalliin

Luottotietorekisterien raportointisäännöt: suunnittelu 24/72 tunnin kellojärjestelmän mukaan

Luottotietorekisterien raportointisäännöt edellyttävät valmistajilta, että ne ilmoittavat aktiivisesti hyödynnetyistä haavoittuvuuksista ja vakavista vaaratilanteista, joilla on vaikutusta
digitaalisia elementtejä sisältävien tuotteiden turvallisuudesta:

• Ennakkovaroitus 24 tunnin sisällä tietoiseksi tulemisesta
• Täydellinen ilmoitus 72 tunnin kuluessa
• Loppuraportti määriteltyjen ikkunoiden sisällä (tapahtumaluokasta riippuen)

Laajamittainen Plug & Charge -häiriö, jonka aiheuttaa joukkosulku tai luottamusankkurin vaarantuminen voi saada kelpoisuuden
vakavana onnettomuutena riippuen vaikutuksista ja hyväksikäyttöä koskevista todisteista.

Haavoittuvuuksien hallintaprosessi (VMP): vähimmäiskyvyt

1. Laivaston totuus: resurssi- ja versioluettelo (EVSE-laiteohjelmisto, ohjaimen levykuvat, luotettujen tallennuspaikkojen versiot).
2. SBOM-integraatio (dynaaminen): SBOM on yhdistetty käyttöönotettaviin artefakteihin; jatkuva korrelaatio haavoittuvuustietojen kanssa.
3. VEX-pohjainen altistumisen hallinta: Säilytä VEX-lausekkeet erottaaksesi "läsnä, mutta ei hyödynnettävissä" ja "hyödynnettävissä käyttöönotossamme", mikä mahdollistaa uskottavan laajuuden määrittämisen T+24h-ikkunassa.
4. Miksi VEX:llä on merkitystä 24-tuntisessa kellossa: SBOM kertoo, mitä on läsnä; VEX auttaa sinua määrittämään, mikä on hyödynnettävä, mikä vähentää vääriä hälytyksiä ja estää operatiivisia tiimejä jahtaamasta hyödynnettävää kohinaa.
5. Sisäänkirjaus ja triage: toimittajille annetut tiedotteet, CVE-tapaukset, sisäiset havainnot; priorisoi hyödynnettävyys + altistuminen.
6. T+24h laajuusmäärityksen työnkulku: SBOM + VEX + inventaariokorrelaatio vaikutusalueen populaatioiden tunnistamiseksi; alustavat eristämispäätökset; todisteiden keruu.
7. T+72h-ilmoitusten työnkulku: vahvistettu laajuus, lieventävät toimenpiteet, käyttöönotto-/palautussuunnitelma, viestintätiedot.
8. Loppuraportin työnkulku: validointinäyttö + perussyy + ennaltaehkäisyn parannukset korjaavien toimenpiteiden saatavuuden jälkeen.
9. Patch-poljinnopeuden säätö: vaiheittainen käyttöönotto, peruutussuunnitelmat, allekirjoitetut esineet, vahvistusportit.
10. Luottamusketjun valvonta: suojattu käynnistys + suojatut laiteohjelmistopäivitykset; HSM/suojatuissa elementeissä suojatut allekirjoitusavaimet.
11. Todisteisiin perustuva hakkuu: varmennetapahtumat, luottamussäilön muutokset, peruutusvirheet, aikasynkronoinnin tila.

Vakavan riskin luottamusskenaario: Jos peruuttamisen laukaisee vaarantunut juuri- tai myöntäjäavain,
käsittele sitä erittäin vakavana luottamusongelmana, joka vaatii välitöntä eristämistä ja koko laivaston kattavia luottamusvarastojen toimenpiteitä,
ja luottoluokituslaitosten kanssa yhdenmukaistettu raportointivalmius vaikutus- ja hyödyntämisnäyttöön perustuen.

CRA-tapahtumien vasteen lähtölaskurin tarkistuslista (toimintamalli)

T+0 (Havaitseminen / Tietoisuus)

• Jäädytä todisteet: lokit, varmennetapahtumat, luotettujen säilöjen versiot, aikasynkronoinnin tila
• Tunnista vaikuttuneiden pintojen tunnistetiedot: EVSE-laiteohjelmisto, paikalliset ohjaimet, taustajärjestelmän TLS-päätepisteet
• Ota yhteyttä PKI-palveluntarjoajaan / taustajärjestelmän tietoturvan yhteyshenkilöön

T+24h (Ennakkovaroitusvalmius)

• Keskeinen tavoite: Käyttää SBOM + VEX + kalustoluettelo määrittääkseen kohdepopulaation ja toimittaakseen näyttöön perustuvan varhaisvaroituksen
• Päätä suojaustoiminnosta: peruutus/kierto, luotettujen tallennusoikeuksien peruutus, sivuston eristäminen
• Luonnos varhaisvaroituspaketista: laajuus, käynnissä olevat lieventämistoimet, väliaikainen tilanne

T+72h (täysi ilmoitusvalmius)

• Vahvista alueellisesti/kohteellisesti kohdennetut väestöryhmät; esitä korjaussuunnitelma ja toteutusmenetelmä
• Asiakkaan/operaattorin välisen viestinnän ja eskalointiraportin laatiminen

Loppuraportointiaika

• Toimita loppuraportti CRA:n vaatimusten mukaisesti (aikataulu riippuu tapahtumaluokasta)
• Korjauksen jälkeinen validointinäyttö + opitut asiat

Kustannus- ja riskien kvantifiointi (mallit, joita voit liittää kalustoosi)

Manuaalisen uusimisen työvoimakustannusmalli

Olkoon:

• N = TLS-päätepisteiden lukumäärä (EVSE + ohjaimet + yhdyskäytävät + hallitut taustapään solmut)
• L = sertifikaatin voimassaoloaika (päivinä)
• t = ihmisen aika uusiutumista kohden (tuntia)
• c = täysin kuormitettu työvoimakustannus (USD/tunti)

Työkustannukset ≈ N × (365 / L) × t × c

Katkosriskimalli (vanheneminen tai epäonnistunut käyttöönotto)

Olkoon:

• P_miss = epäonnistuneen/väliin jääneen uusimisen todennäköisyys sykliä kohden
• H_down = odotettavissa oleva seisokkiaika tunteina tapausta kohden
• C_tunti = tuntikohtainen vaikutus liiketoimintaan (menetetyt tulot, sakot, palvelutasosopimusten hyvitykset)

Katkoksen_kustannukset ≈ P_miss × H_down × C_hour

Päätösopas: Kun online-sulkutarkistukset epäonnistuvat (OCSP/CRL-aikakatkaisu)

1. Julkinen paikka vai suljettu kalusto/varikko?
   • Julkinen → mieluummin Kova vika (tai tiukasti kontrolloitua armoa vain todisteiden ja kompensoivien kontrollien avulla)
   • Laivasto/varikko → Armo todisteineen voi olla hyväksyttävä rajoitetuille ikkunoille
2. Onko verkon luotettavuus ennustettavissa?
   • Kyllä → Online-OCSP/CRL + seuranta
   • Ei → Reunan esivalidointi + välimuisti (CRL-päivitysikkunat, välimuistissa olevat ketjut)
3. Voitko vähentää nettiriippuvuutta istunnon aikana?
   • Jos mahdollista → ota käyttöön OCSP-nidontakuvio (työnnä todiste lähemmäs reunaa)
4. Onko teillä todisteiden kirjaustoimintoja + ajan synkronoinnin hallintaa?
   • Jos ei → korjaa nämä ensin; heikentyneen tilan käytäntöjä on vaikea puolustaa ilman niitä

Käytännön vastuumatriisi (katkoksia estävät rajat)

Sanasto

• PKI: Julkisen avaimen infrastruktuuri (myöntäminen, validointi, luotettavuusankkurit, peruuttaminen)
• ACME: Automatisoitu varmenteiden hallintaympäristö (automaattinen myöntäminen/uusimineen)
• OCSP / CRL: Online-sertifikaattien tilaprotokolla / sertifikaattien peruutusluettelo
• OCSP-nidonta: Palvelin tarjoaa peruutussuojan vähentääkseen reaaliaikaista OCSP-riippuvuutta
• Luottamusankkurit: Juuri-/välisertifikaatit, joihin validoijasi luottavat
• SBOM: Ohjelmiston materiaaliluettelo (komponenttiluettelo haavoittuvuuksien laajuuden määrittämiseksi)
• VEX: Haavoittuvuuksien hyödynnettävyystietojen vaihto (hyödynnettävyystilalausunnot)
• TLS 1.3: Moderni TLS-profiili; kättely + varmenteen validointi pysyvät viiveherkkinä
• VMP: Haavoittuvuuksien hallintaprosessi (tietojen vastaanotto, luokittelu, korjauspäivitykset, raportointi, todisteet)

Tulevaisuuteen suuntautuva riski: Kryptoketteryys ja PQC-valmius

Vaikka vuotta 2026 hallitsevat lyhyet TLS-käyttöajat ja CRA-raportointi, latausinfrastruktuurien tulisi alkaa arvioida
kryptoketteryysPitkäikäisten omaisuuserien (ajoneuvojen ja latausasemien) kohdalla arkkitehtuurien tulisi välttää laitteistoriippuvuutta varmistamalla
HSM/suojatut elementit ja sulautetut pinot voivat tukea tulevia algoritmi- ja varmenneprofiilipäivityksiä ilman laitteistopäivitystä.

Usein kysytyt kysymykset

Voiko Plug & Charge -toimintoa käyttää offline-tilassa?

Osittain – rakenteensa puolesta. Offline-suojaus ja -yhteensopivuus (P&C) on hallittua heikkenemistä paikallisen luottamusvälimuistin avulla (ankkurit/välitasot/CRL:t, jos mahdollista).
eksplisiittiset lisäaikakäytännöt ja puskuroidut lokitiedot täsmäytystä varten. Sen ei tulisi ohittaa PKI:tä; sen tulisi vähentää reaaliaikaista pilviriippuvuutta
säilyttäen samalla eheyden ja auditoitavuuden.

Kuinka usein meidän on uusittava sertifikaatit, joiden voimassaoloaika on 199/200 päivää?

Suunnittele useita uudistusjaksoja vuodessa päätepistettä kohden. Monille operaattoreille toiminnan vaihto alkaa
24. helmikuuta 2026 koska DigiCert myöntää julkisia TLS-varmenteita, joiden enimmäismäärä on 199 päivän voimassa kyseisestä päivästä alkaen.
Laajemmalla ekosysteemitasolla perustason vaatimukset määrittelevät vaiheittaisen vähennyksen 200/100/47 päivää.

Mikä laukaisee luottoluokituslaitosten raportointivelvollisuuden?

Luottoluokituslaitosten raportointisäännöt edellyttävät 24 tunnin ennakkovaroitus ja 72 tunnin ilmoitus aktiivisesti hyödynnettyjen haavoittuvuuksien ja vakavien häiriöiden osalta
sekä lopulliset raportointiajat. Laajamittainen P&C-luottamuksen häiriö (esim. ilkivaltainen peruutus tai validoinnin vaarantuminen) voi täyttää kriteerit riippuen
vaikutus- ja hyödyntämisnäyttöön perustuen; CRA-valmiin VMP:n tulisi tukea SBOM + VEX + kalustoluettelo kartoitus ensimmäisten 24 tunnin aikana.