ISO 15118-certifikatets livscyklusstyring i 2026: Fra TLS-haster til CRA-overholdelse

TL;DR (Resumé af handlinger)

• TLS-cutover er en hård grænse (ikke et forslag): Fra 24. februar 2026, DigiCert vil stop med at acceptere offentlige TLS-certifikatanmodninger med gyldighed mere end 199 dage, og certifikater udstedt fra denne dato har en Maksimal gyldighed på 199 dageDette er den praktiske overgang for mange operatører – fornyelseshastigheden øges øjeblikkeligt.
• Køreplanen på 200→100→47 dage er allerede defineret: CA/Browser Forum-grundkravene fastsætter en gradvis reduktion: 200 dage fra 15. marts 2026, 100 dage fra 15. marts 2027, og 47 dage fra 15. marts 2029.
• CRA tilføjer et compliance-ur: Regler for kreditvurderingsbureauets indberetning kræver tidlig varsling inden for 24 timer, fuld underretning inden for 72 timerog definerede endelige rapporteringsvinduer for aktivt udnyttede sårbarheder og alvorlige hændelser.
• Den største skjulte risiko er ikke udløb: Den systemiske fejltilstand er tillidsankerdrift—ændringer af roots/intermediates/cross-signing er ikke synkroniserede på tværs af EVSE, lokale controllere og backend-valideringsstier.
• Første investering for at beskytte oppetiden: Systemstyret automatisering (ACME + lager + trinvis udrulning) plus kantkontinuitet (lokal validering/caching, bevislogfiler og tidssynkroniseringsstyring).

Introduktion: 2026 gør Plug & Charge til et operationelt system

I 2026 stopper Plug & Charge (P&C) med at være en "indstil-og-glem"-funktion og bliver en kontinuerligt operativsystem.
ISO 15118-tillidsplanet (PKI + TLS + tilbagekaldelse + opdateringer) er nu styret af tidslinjer, der ikke tolererer manuelle arbejdsgange.

For at forstå systemgrænsen – hvad ISO 15118 er ansvarlig for vs. hvad OCPP er ansvarlig for – start med vores ledsagende artikel:
ISO 15118 vs. OCPP-implementeringsrealitet i 2026.

Det umiddelbare pres er TLS livscykluskomprimeringOperationelt kan man ikke "vente til marts".
DigiCert vil stop med at acceptere offentlige TLS-anmodninger, der overstiger 199 dage starter 24. februar 2026,
og certifikater udstedt fra den dag og fremefter vil have en Maksimal gyldighed på 199 dage.
DigiCert understreger også en kritisk operationel detalje: den maksimalt tilladte gyldighed styres af udstedelsesdato, ikke når ordren afgives.

Samtidig indfører EU's lov om cybermodstandsdygtighed (CRA) et andet ur: rapporteringsregler kræver
24-timers tidlig varsling og 72-timers notifikation for aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker produkter med digitale elementer.

Denne vejledning fokuserer på arkitektur og risikostyring for drift af ISO 15118-certifikater under disse begrænsninger.

Milepæle og nødvendige handlinger for 2024-2026 (tekst Gantt)

Operationel bemærkning: Den 24. februar 2026 er ofte det virkelige skillepunkt, fordi udstedelsesadfærden ændrer sig for større CA'er.

Politikbemærkning: De fasede levetidsreduktioner er defineret i basiskravene (200/100/47 dage).

Livscykluslandskabet: Klargøring → Drift → Fornyelse → Tilbagekaldelse

Livscykluskort (hvad du skal kunne betjene)

1. OEM-klargøring: Nøgler genereret/injiceret; tillidsrod etableret (HSM/sikkert element).
2. Kontrakttilmelding: Kontraktcertifikater bundet til brugerkontrakter (økosystemafhængige).
3. Idriftsættelse af EVSE: Der er etableret basislinjer for tillidslager, politikker og tidssynkroniseringsbasislinjer.
4. Operationel validering: TLS-handshakes, kædeopbygning, kontrol af tilbagekaldelser, håndhævelse af politikker.
5. Fornyelse / genudstedelse: Automatisering + gradvis udrulning + tilbagerulning.
6. Tilbagekaldelse / reaktion på hændelse: Kompromis/misbrug af udstedelse/udnyttelse → tilbagekald/roter/inddriv.
7. Genopretning og forsoning: Gendan tjenesten, samtidig med at revisionsbarhed og faktureringsintegritet bevares.

Det undervurderede fejlpunkt: Tillidsankerdrift

De fleste "mystiske P&C-fejl" i multi-OEM-miljøer er ikke et enkelt udløbet certifikat – de er
fejl i validering af stier forårsaget af drift af tillidsanker:

• Nye rødder/mellemprodukter opstår (multirodsvirkelighed).
• Krydssignering ændringer ændrer gennemførlige kæder.
• Backend-trustlagre opdateres hurtigere end EVSE/lokale controllere.
• Tilbagekaldelsesartefakter bliver forældede i kanten.

Behandl opdateringer af tillidsankre som en sikkerhedskritisk ændringsproces:

• Versionsbaserede tillidsbutikker
• Canary-udrulninger
• Tilbagerulningsplaner
• Telemetri ved valideringsfejl efter udsteder/serienummer/sti
• En eksplicit ejer af "hvem opdaterer hvad, hvornår"

Fejl i krydssignering og stiopbygning (virkelighed i 2026): I ISO 15118-økosystemer med flere rødder,
Plug & Charge fejler ofte ikke fordi et certifikat er ugyldigt, men fordi EVSE'en ikke kan bygge en gyldig
certifikatsti efter ændringer i krydssignering (nye mellemprodukter, bro-CA'er, genudstedte kæder).
Efterhånden som flere OEM'er og PKI-domæner tilslutter sig, øges stikompleksiteten. Hvis edge trust-lagre (EVSE/lokale controllere)
halter bagefter backend-opdateringer, TLS-handshakes kan mislykkes, selv når backend-certifikater isoleret set virker "gyldige".

Figur 1 (anbefalet visuel): Stivalidering i Multi-Root ISO 15118

(Vis V2G-rod / OEM-rod / kontraktrod, mellemliggende og krydstegnsbroer).
Fremhæv hvor et nyligt krydssigneret mellemprodukt afbryder stiopbygning på EVSE, hvis tillidslagre ikke opdateres synkront.

Kernebudskab: De fleste P&C-afbrydelser, der skyldes "PKI", er faktisk fejl i validering af stier drevet af krydssigneringsdrift og usynkroniserede tillidslagre.

ACME & Automation: Menneskestyret vs. systemstyret under 199/200 dages levetid

Hvorfor manuel fornyelse bliver en deterministisk afbrydelsesgenerator

Korte levetider gør fornyelser kontinuerlige. DigiCerts overgang til 199 dage fra 24. februar 2026
gør dette operationelt med det samme for mange flåder. Og den bredere tidslinje for branchen er allerede defineret:
200 dage (fra 15. marts 2026), derefter 100 dage, så 47 dage.

For enhver flåde skaleres fornyelsesbegivenheder som følger:

Fornyelsesbegivenheder pr. år ≈ N × (365 / L)

Hvor N er antallet af TLS-slutpunkter og L er certifikatets levetid (dage).
Som L falder, bliver menneskeskabt fornyelse matematisk uforenelig med oppetidsmål.

Scenarie (størrelsesindstilling på bestyrelsesniveau)

For en CPO, der opererer 5.000 slutpunkter, en levetid på 199 dage indebærer:

Fornyelsesbegivenheder/år ≈ 5000 × (365 / 199) ≈ 9.171

I denne skala, selv en 1% menneskelig fejlrate oversættes til omtrent
92 certifikatdrevne afbrydelser om året—før der tages højde for påvirkningen i myldretiden,
SLA-bøder eller kaskaderende fejl på tværs af en hub.

ACME i ladenetværk: hvad det skal automatisere

ACME (Automated Certificate Management Environment) forvandler fornyelser til politikdrevne operationer for:

• EVSE ↔ backend TLS
• Lokal controller / Edge Proxy TLS
• Site gateways og hub-controllere

Systemstyret arbejdsgang (arkitekturmønster)

1. Inventar hvert slutpunkt (udsteder, serienummer, kæde, udløb, sidste rotation).
2. Forny-før-politik (forny ved en fast grænse, ikke "nær udløb").
3. Hardware-backed nøgler hvor det er muligt; undgå eksport af private nøgler.
4. Gradvis udrulning med sundhedstjek (håndtryk + godkendelse + sessionsstart).
5. Automatisk tilbagerulning på forhøjede fejlrater.
6. Bevislogge for hver udstedelse/implementering (sporbarhed på compliance-niveau).

Menneskestyret vs. systemstyret

• Menneskestyret: Sager, regneark, sene fornyelser, tvetydigt ejerskab, risikable nødændringer.
• Systemstyret: Deterministiske politikker, automatiseret udstedelse, kontrolleret udrulning, kontinuerlig telemetri, reviderbar dokumentation.

Tilbagekaldelseskontroller: "P&C-dræberen" (CRL vs. OCSP, svage netværk og forsvarlige politikker)

Hvorfor OCSP/CRL fejler i garager og depoter

• Svag/intermitterende LTE/5G
• Begrænset udgang (firewalls/captive portals)
• Latensfølsomme valideringstrin
• Eksterne afhængigheder (OCSP-respondenter, CRL-distributionspunkter)

Resultat: EVSE kan starte en session, men fuldføres ikke tilbagekaldelsesvalidering pålideligt.

CRL vs. OCSP: Praktiske afvejninger

• CRL: tungere downloads, men kan caches og opdateres til tiden (godt for kontinuitet i kanten).
• OCSP: letvægts pr. anmodning, men kræver ofte live tilgængelighed på den svageste kant.

I 2026 er den korrekte kropsholdning lagdelt:

• Planlagt CRL-caching for robusthed
• OCSP hvor forbindelsen er pålidelig
• Eksplicit politik for forringede forhold

Hvorfor "soft fail" bliver sværere at forsvare

Historisk set bevarede "soft-fail" (tillad session, hvis tilbagekaldelseskontroller har timeout) tilgængeligheden.
I 2026 bliver det sværere at retfærdiggøre soft fail fordi:

• Levetiden er kortere (mindre tolerance over for forældede antagelser)
• CRA's rapporteringsur kræver stærkere hændelsesdisciplin og bevisspor

Et forsvarligt design kræver en eksplicit, dokumenteret politik:

• Hård fejl til offentlige/højrisikomiljøer
• Nåde-med-bevis for lukkede flåder (begrænset vindue + kompenserende kontroller)
• Bevislogning for hver eneste forringede beslutning

Arkitektoniske afbødninger (mønstre, ikke produktløfter)

Mønster 1: Forhåndsvalidering af kant + caching

• Cache-CRL'er med definerede aktualitetsvinduer
• Cache-mellemprodukter og validerede kæder
• Forhåndshentning i perioder med "god forbindelse"

Mønster 2: OCSP-hæftning (hvor det er muligt)

OCSP-hæftning flytter tilbagekaldelsesbevislevering væk fra den svageste kant – hvilket reducerer live-afhængigheden af CA-infrastruktur under sessionsoprettelse.

Implementeringsnotat (indlejret virkelighed): I EVSE-miljøer skal du bekræfte understøttelse af hæfterelaterede udvidelser.
i din integrerede TLS-stak og build-konfiguration (f.eks. mbedTLS, wolfSSL) og validere adfærd på tværs af ældre hardware,
fordi funktionsfuldstændighed og hukommelses-/RTOS-begrænsninger varierer.

Mønster 3: Multi-root trust governance

• Samlet opdateringskanal for tillidslager til flere OEM-ankre
• Canary-opdateringer + rollback når der opstår en stigning i fejl i stiopbygningen

Mønster 4: Tidssynkroniseringsstyring (ikke til forhandling)

• NTP-politik (eller PTP, hvor det er relevant)
• Driftovervågning og alarmtærskler
• Defineret adfærd, når ure ikke er tillidsfulde

Offline-kontinuitet: holder Plug & Charge brugbar under afbrydelser fra edge til cloud

Hvad offline kontinuitet er (og ikke er)

Offline kontinuitet er ikke at "omgå PKI". Det er kontrolleret nedbrydning, der bevarer:

• Nøglernes integritet og tillidsbutikker
• Revisionsmulighed for fakturering og hændelsesrespons
• Eksplicitte grænser for, hvad der kan valideres lokalt (og hvor længe)

Lokale controllere / Edge Proxies som tilgængelighedsprimitiver

• Vedligehold lokale tillidscacher (ankre/mellemprodukter/CRL'er)
• Håndhæv begrænsede lokale godkendelsespolitikker
• Buffermåling/logfiler til senere afstemning
• Reducer WAN-eksplosionsradius ved at fungere som det lokale slutpunkt for EVSE

Figur 2 (anbefalet visuel): Edge Proxy som en trustcache på websteder med svagt netværk

(Viser EVSE'er, der opretter forbindelse til en on-site Edge Proxy/Local Controller. Proxy'en vedligeholder cachelagrede tillidsankre/mellemprodukter,
planlagt CRL-opdatering, tidssynkroniseret overvågning og bevislogfiler; den bufferer hændelser til cloud-CSMS/PKI, når uplink er ustabilt.)

Kernebudskab: Edge-proxyer reducerer live-afhængigheden af eksterne OCSP/CRL-slutpunkter og muliggør kontrolleret offline-kontinuitet uden at omgå PKI.

CRA & VMP: fra september 2026 rapporteringsfrister til en revisionsbar driftsmodel

Regler for rapportering af kreditvurderingsbureauer: design til 24/72 timer

Regler for rapportering af kreditvurderingsinstitutter kræver, at producenter anmelder aktivt udnyttede sårbarheder og alvorlige hændelser, der har indflydelse
om sikkerheden af produkter med digitale elementer:

• Tidlig advarsel inden for 24 timer at blive bevidst
• Fuld besked inden for 72 timer
• Endelig rapport inden for definerede vinduer (afhængigt af hændelsesklasse)

En omfattende Plug & Charge-forstyrrelse forårsaget af massetilbagekaldelse eller et kompromitteret trust-anker kan kvalificere sig
som en alvorlig hændelse afhængigt af påvirkning og beviser for udnyttelse.

Sårbarhedsstyringsproces (VMP): minimum levedygtige funktioner

1. Flådens sandhed: aktiv + versionsinventar (EVSE-firmware, controller-billeder, trust store-versioner).
2. SBOM-integration (dynamisk): SBOM kortlagt til udrullelige artefakter; kontinuerlig korrelation med sårbarhedsinformation.
3. VEX-drevet eksponeringsstyring: Vedligehold VEX-erklæringer for at skelne mellem "til stede, men ikke udnyttelig" og "udnyttelig i vores implementering", hvilket muliggør troværdig scoping inden for T+24h-vinduet.
4. Hvorfor VEX er vigtig under 24-timers uret: SBOM fortæller dig, hvad der er til stede; VEX hjælper dig med at bestemme, hvad der er udnyttelig, hvilket reducerer falske alarmer og forhindrer operationsteams i at jagte støj, der ikke kan udnyttes.
5. Indtagelse og triage: leverandørrådgivning, CVE'er, interne fund; prioriter udnyttelsesevne + eksponering.
6. T+24h scoping-arbejdsgang: SBOM + VEX + opgørelseskorrelation til identifikation af berørte populationer; indledende inddæmningsbeslutninger; evidensindsamling.
7. T+72h notifikationsworkflow: bekræftet omfang, afbødninger, udrulning/tilbageføringsplan, kommunikationsjournal.
8. Arbejdsgang i den endelige rapport: valideringsevidens + rodårsag + forebyggelsesforbedringer efter tilgængelighed af korrigerende foranstaltninger.
9. Patch-kadenceteknik: Etappevis udrulning, rollback-planer, underskrevne artefakter, verifikationsportale.
10. Håndhævelse af tillidskæden: sikker opstart + sikre firmwareopdateringer; signeringsnøgler beskyttet i HSM/sikre elementer.
11. Evidensbaseret logføring: Cert-hændelser, ændringer i tillidslager, tilbagekaldelsesfejl, tilstand af tidssynkronisering.

Højt alvorsniveau for tillid: Hvis tilbagekaldelsen udløses af en kompromitteret root- eller udstedende nøgle,
behandle det som en tillidshændelse af højeste alvorlighed, der kræver øjeblikkelig inddæmning og flådeomfattende tillidshåndteringshandlinger,
og rapporteringsparathed tilpasset CRA-vurderingsmyndighederne afhængigt af effekt og udnyttelsesbeviser.

CRA-tjekliste til nedtælling af hændelser (operationel skabelon)

T+0 (Detektion / Opmærksomhed)

• Frys bevismateriale: logfiler, certifikathændelser, versioner af tillidslager, status for tidssynkronisering
• Identificér berørte overflader: EVSE-firmware, lokale controllere, backend TLS-slutpunkter
• Kontakt PKI-udbyder/backend-sikkerhedskontakt

T+24h (Tidlig varslingsberedskab)

• Kernemål: Bruge SBOM + VEX + flådebeholdning at bestemme den berørte befolkning og indsende en evidensbaseret tidlig varsling
• Beslut inddæmning: tilbagekald/roter, tilbagerulning af trust-store, isolering af websted
• Udkast til tidlig varslingspakke: omfang, afbødende foranstaltninger i gang, midlertidig holdning

T+72t (Fuld beredskab til notifikationer)

• Bekræft berørte populationer efter region/sted; angiv afhjælpningsplan + udrulningsmetode
• Udarbejd kunde-/operatørkommunikation og eskaleringsrapport

Vindue for endelig rapport

• Indsend endelig rapport i overensstemmelse med CRA-krav (tidspunktet afhænger af hændelsesklasse)
• Beviser for validering efter reparation + erfaringer

Kvantificering af omkostninger og risici (skabeloner, du kan integrere i din flåde)

Manuel fornyelsesmodel for arbejdsomkostninger

Lade:

• N = antal TLS-slutpunkter (EVSE + controllere + gateways + administrerede backend-noder)
• L = cert levetid (dage)
• t = menneskelig tid pr. fornyelse (timer)
• c = fuldt lastet lønomkostninger (USD/time)

Arbejdsomkostning ≈ N × (365 / L) × t × c

Risikomodel for nedbrud (udløb eller mislykket implementering)

Lade:

• P_miss = sandsynlighed for misset/mislykket fornyelse pr. cyklus
• H_ned = forventede nedetid i timer pr. hændelse
• C_time = timebaseret forretningspåvirkning (tabt omsætning, bøder, SLA-kreditter)

Omkostningsafbrydelse ≈ P_miss × H_down × C_time

Beslutningsvejledning: Når online tilbagekaldelseskontroller mislykkes (OCSP/CRL Timeout)

1. Offentlig plads eller lukket flåde/depot?
   • Offentlig → foretrækker Hård fejl (eller strengt kontrolleret nåde kun med beviser + kompenserende kontroller)
   • Flåde/depot → Nåde-med-bevis kan være acceptabelt for begrænsede vinduer
2. Er netværkets pålidelighed forudsigelig?
   • Ja → Online OCSP/CRL + overvågning
   • Nej → Edge-forhåndsvalidering + caching (CRL-opdateringsvinduer, cachelagrede kæder)
3. Kan du reducere onlineafhængighed under sessionen?
   • Hvor det er muligt → vedtag OCSP hæftemønster (tryksikker tættere på kanten)
4. Har I bevislogning + tidssynkroniseringsstyring?
   • Hvis ikke → reparer disse først; degraderede politikker er svære at forsvare uden dem

Praktisk ansvarsmatrix (grænser, der forhindrer strømafbrydelser)

Ordliste

• PKI: Offentlig nøgleinfrastruktur (udstedelse, validering, tillidsankre, tilbagekaldelse)
• ACME: Automatiseret certifikatstyringsmiljø (automatiseret udstedelse/fornyelse)
• OCSP / CRL: Online certifikatstatusprotokol / certifikattilbagekaldelsesliste
• OCSP-hæftning: Serveren fremviser bevis for tilbagekaldelse for at reducere afhængighed af live OCSP
• Tillidsankre: Rod-/mellemliggende certifikater, som dine validatorer har tillid til
• SBOM: Software-materialeliste (komponentfortegnelse til vurdering af sårbarheder)
• VEX: Sårbarhed Udnyttelsesevne eXchange (statusudsagn om udnyttelsesevne)
• TLS 1.3: Moderne TLS-profil; handshake + certifikatvalidering forbliver latenstidsfølsom
• VMP: Sårbarhedshåndteringsproces (indtagelse, triage, patching, rapportering, bevismateriale)

Fremadrettet risiko: Kryptoagilitet og PQC-beredskab

Mens 2026 er domineret af korte TLS-levetider og rapportering fra CRA'er, bør opladningsinfrastrukturer begynde at evalueres
krypto-agilitetMed langtidsholdbare aktiver (køretøjer og opladere) bør arkitekturer undgå hardware-låsning ved at sikre
HSM/sikre elementer og indlejrede stakke kan understøtte fremtidige algoritme- og certifikatprofilopdateringer uden at kræve en hardwareopdatering.

Ofte stillede spørgsmål

Kan Plug & Charge fungere offline?

Delvist — efter design. Offline P&C er kontrolleret nedbrydning ved hjælp af lokal tillids-caching (ankre/mellemprodukter/CRL'er hvor det er muligt),
eksplicitte grace-politikker og bufferede revisionslogfiler til afstemning. Den bør ikke omgå PKI; den bør reducere afhængigheden af live cloud.
samtidig med at integritet og revisionsbarhed bevares.

Hvor ofte skal vi forny certifikater med en levetid på under 199/200 dage?

Planlæg flere fornyelsescyklusser pr. år pr. slutpunkt. For mange operatører starter den operationelle overgang
24. februar 2026 fordi DigiCert vil udstede offentlige TLS-certifikater med et maksimum 199-dages gyldighed fra den dato.
På det bredere økosystemniveau definerer basiskravene en gradvis reduktion til 200/100/47 dage.

Hvad udløser CRA-indberetningsforpligtelser?

Regler for kreditvurderingsbureauets indberetning kræver 24-timers tidlig varsling og 72-timers notifikation for aktivt udnyttede sårbarheder og alvorlige hændelser,
plus endelige rapporteringsvinduer. En omfattende forstyrrelse af P&C-tillidsforholdet (f.eks. ondsindet tilbagekaldelse eller valideringskompromittering) kan være kvalificeret afhængigt af
baseret på beviser for virkning og udnyttelse; en CRA-klar VMP bør understøtte SBOM + VEX + flådebeholdning scoping inden for de første 24 timer.