Gestione del ciclo di vita del certificato ISO 15118 nel 2026: dall'urgenza TLS alla conformità CRA

TL;DR (Riepilogo delle azioni esecutive)

• Il cutover TLS è un limite rigido (non un suggerimento): Da 24 febbraio 2026, DigiCert lo farà smettere di accettare richieste di certificati TLS pubblici con validità maggiore di 199 giorni, e i certificati rilasciati da quella data hanno un Validità massima di 199 giorniPer molti operatori si tratta della soluzione pratica: la velocità di rinnovo aumenta immediatamente.
• La roadmap 200→100→47 giorni è già definita: I requisiti di base del CA/Browser Forum stabiliscono una riduzione graduale: 200 giorni dal 15 marzo 2026, 100 giorni dal 15 marzo 2027, E 47 giorni dal 15 marzo 2029.
• CRA aggiunge un orologio di conformità: Le regole di segnalazione CRA richiedono allerta precoce entro 24 ore, notifica completa entro 72 oree ha definito le finestre di reporting finale per le vulnerabilità attivamente sfruttate e gli incidenti gravi.
• Il rischio nascosto principale non è la scadenza: La modalità di guasto sistemico è deriva dell'ancora di fiducia—modifiche root/intermedi/firma incrociata non sincronizzate tra EVSE, controller locali e percorsi di convalida backend.
• Primo investimento per proteggere i tempi di attività: Automazione guidata dal sistema (ACME + inventario + implementazione graduale) più continuità del bordo (validazione/memorizzazione nella cache locale, registri delle prove e governance della sincronizzazione temporale).

Introduzione: il 2026 trasforma Plug & Charge in un sistema operativo

Nel 2026, Plug & Charge (P&C) smetterà di essere una funzionalità "imposta e dimentica" e diventerà un sistema operativo continuo.
Il piano di trust ISO 15118 (PKI + TLS + revoca + aggiornamenti) è ora regolato da tempistiche che non tollerano flussi di lavoro manuali.

Per comprendere il confine del sistema, ovvero di cosa è responsabile ISO 15118 e di cosa è responsabile OCPP, iniziamo con il nostro articolo di accompagnamento:
Realtà di implementazione ISO 15118 vs OCPP nel 2026.

La pressione immediata è Compressione del ciclo di vita TLSDal punto di vista operativo, non si può “aspettare fino a marzo”.
DigiCert sarà smettere di accettare richieste TLS pubbliche superiori 199 giorni di partenza 24 febbraio 2026,
e i certificati rilasciati da quel giorno in poi avranno un Validità massima di 199 giorni.
DigiCert sottolinea inoltre un dettaglio operativo critico: la validità massima consentita è regolata dal data di emissione, non quando viene effettuato l'ordine.

Allo stesso tempo, l’EU Cyber Resilience Act (CRA) introduce un secondo orologio: le regole di segnalazione richiedono
allerta precoce 24 ore su 24 E Notifica di 72 ore per vulnerabilità attivamente sfruttate e incidenti gravi che hanno un impatto sui prodotti con elementi digitali.

Questa guida si concentra sull'architettura e sui controlli dei rischi per l'esecuzione dei certificati ISO 15118 in base a questi vincoli.

Traguardi e azioni richieste per il 2024-2026 (Gantt di testo)

Nota operativa: Il 24 febbraio 2026 è spesso il vero punto di svolta, perché in quel momento cambia il comportamento di emissione per le principali CA.

Nota politica: Le riduzioni graduali della durata di vita sono definite nei requisiti di base (200/100/47 giorni).

Il panorama del ciclo di vita: provisioning → funzionamento → rinnovo → revoca

Mappa del ciclo di vita (cosa devi essere in grado di gestire)

1. Fornitura OEM: Chiavi generate/iniettate; radice di attendibilità stabilita (HSM/elemento sicuro).
2. Registrazione del contratto: Certificati contrattuali vincolati ai contratti utente (dipendenti dall'ecosistema).
3. Messa in servizio EVSE: Stabilite le linee di base dell'archivio attendibile, le policy e le linee di base della sincronizzazione temporale.
4. Validazione operativa: Strette di mano TLS, creazione di catene, controllo delle revoche, applicazione delle policy.
5. Rinnovo/riemissione: Automazione + implementazione graduale + rollback.
6. Revoca/risposta agli incidenti: Compromesso/emissione errata/sfruttamento → revoca/ruota/recupera.
7. Recupero e riconciliazione: Ripristinare il servizio preservando la verificabilità e l'integrità della fatturazione.

Il punto di fallimento sottovalutato: Trust Anchor Drift

La maggior parte dei "misteriosi guasti P&C" negli ambienti multi-OEM non sono un singolo certificato scaduto, sono
errori di convalida del percorso causato dalla deriva dell'ancora di fiducia:

• Compaiono nuove radici/intermedi (realtà multi-radice).
• Firma incrociata i cambiamenti alterano le catene fattibili.
• Gli archivi di trust back-end si aggiornano più rapidamente rispetto ai controller EVSE/locali.
• Gli artefatti di revoca diventano obsoleti al limite.

Considerare gli aggiornamenti dell'ancora di fiducia come un processo di modifica critico per la sicurezza:

• Archivi di attendibilità con versione
• Lancio di Canary
• Piani di rollback
• Telemetria sui fallimenti di convalida per emittente/seriale/percorso
• Un proprietario esplicito per "chi aggiorna cosa, quando"

Errori nella segnaletica incrociata e nella creazione di percorsi (realtà del 2026): Negli ecosistemi ISO 15118 multi-root,
Il sistema Plug & Charge spesso fallisce non perché un certificato non è valido, ma perché l'EVSE non riesce a creare un certificato valido
percorso del certificato dopo modifiche di firma incrociata (nuovi intermedi, CA bridge, catene riemesse).
Con l'adesione di un numero sempre maggiore di OEM e domini PKI, la complessità del percorso aumenta. Se gli edge trust store (EVSE/controller locali)
ritardo rispetto agli aggiornamenti del backend, gli handshake TLS possono fallire anche quando i certificati del backend appaiono "validi" isolatamente.

Figura 1 (immagine consigliata): convalida del percorso in ISO 15118 multi-root

(Mostra radice V2G / radice OEM / radice contrattuale, intermedi e ponti di segno incrociato.
Evidenzia dove un intermedio appena firmato interrompe la creazione del percorso su EVSE se gli archivi di trust non vengono aggiornati in sincronia.)

Messaggio principale: La maggior parte delle interruzioni P&C attribuite a “PKI” sono in realtà errori di convalida del percorso guidato dalla deriva delle firme incrociate e dagli archivi di fiducia non sincronizzati.

ACME e automazione: guida umana vs. guida di sistema in tempi di vita di 199/200 giorni

Perché il rinnovo manuale diventa un generatore deterministico di interruzioni

La breve durata rende i rinnovi continui. Il passaggio di DigiCert a 199 giorni dal 24 febbraio 2026
Rende questa soluzione immediatamente operativa per molte flotte. E la tempistica più ampia del settore è già definita:
200 giorni (dal 15 marzo 2026), quindi 100 giorni, Poi 47 giorni.

Per qualsiasi flotta, gli eventi di rinnovo sono scalabili come:

Eventi di rinnovo all'anno ≈ N × (365 / L)

Dove N è il numero di endpoint TLS e L è la durata del certificato (giorni).
COME L diminuisce, il rinnovamento guidato dall'uomo diventa matematicamente incompatibile con gli obiettivi di uptime.

Scenario (dimensionamento a livello di consiglio di amministrazione)

Per un CPO operativo 5.000 endpoint, una durata di 199 giorni implica:

Eventi di rinnovo/anno ≈ 5000 × (365 / 199) ≈ 9.171

A questa scala, anche un Tasso di errore umano 1% si traduce approssimativamente in
92 interruzioni causate da certificati all'anno—prima di tenere conto dell'impatto delle ore di punta,
Penalità SLA o guasti a cascata in un hub.

ACME nelle reti di ricarica: cosa dovrebbe automatizzare

ACME (Automated Certificate Management Environment) trasforma i rinnovi in operazioni basate su policy per:

• EVSE ↔ backend TLS
• Controller locale/Proxy Edge TLS
• Gateway del sito e controller dell'hub

Flusso di lavoro guidato dal sistema (modello di architettura)

1. Inventario ogni endpoint (emittente, seriale, catena, scadenza, ultima rotazione).
2. Politica di rinnovo prima (rinnovare a una soglia fissa, non "vicino alla scadenza").
3. Tasti supportati dall'hardware ove possibile, evitare di esportare chiavi private.
4. Implementazione graduale con controlli di integrità (handshake + autorizzazione + avvio della sessione).
5. Ripristino automatico sugli elevati tassi di fallimento.
6. Registri delle prove per ogni emissione/distribuzione (tracciabilità di livello di conformità).

Guidato dall'uomo vs guidato dal sistema

• Gestito dall'uomo: biglietti, fogli di calcolo, rinnovi tardivi, proprietà ambigua, cambiamenti di emergenza rischiosi.
• Guidato dal sistema: politiche deterministiche, emissione automatizzata, distribuzione controllata, telemetria continua, prove verificabili.

Controlli di revoca: il “killer P&C” (CRL vs OCSP, reti deboli e policy difendibili)

Perché gli OCSP/CRL falliscono nei garage e nei depositi

• LTE/5G debole/intermittente
• Uscita limitata (firewall/captive portal)
• Fasi di convalida sensibili alla latenza
• Dipendenze esterne (risponditori OCSP, punti di distribuzione CRL)

Risultato: EVSE può avviare una sessione ma non riesce a completarla convalida della revoca in modo affidabile.

CRL vs OCSP: compromessi pratici

• CRL: download più pesanti, ma memorizzabili nella cache e aggiornabili secondo programma (ottimo per la continuità dei margini).
• OCSP: leggero su richiesta, ma spesso richiede la raggiungibilità in tempo reale sul bordo più debole.

Nel 2026 la postura corretta è stratificata:

• Memorizzazione nella cache CRL pianificata per la resilienza
• OCSP dove la connettività è affidabile
• Politica esplicita per condizioni degradate

Perché il “soft-fail” sta diventando più difficile da difendere

Storicamente, il "soft-fail" (consentire la sessione se i controlli di revoca scadono) preservava la disponibilità.
Nel 2026, il soft-fail diventerà più difficile da giustificare perché:

• La durata della vita è più breve (minore tolleranza per le ipotesi stantie)
• L'orologio di segnalazione della CRA impone una disciplina più severa sugli incidenti e sulle prove

Un progetto difendibile richiede una politica esplicita e documentata:

• Hard-fail per ambienti pubblici/ad alto rischio
• Grazia con prove per flotte chiuse (finestra limitata + controlli di compensazione)
• Registrazione delle prove per ogni decisione degradata

Mitigazioni architettoniche (modelli, non promesse di prodotto)

Modello 1: Pre-validazione Edge + memorizzazione nella cache

• Memorizza CRL nella cache con finestre di aggiornamento definite
• Cache intermedie e catene convalidate
• Pre-fetch durante i periodi di "buona connettività"

Modello 2: Graffatura OCSP (ove possibile)

Lo stapling OCSP sposta la distribuzione della prova di revoca dal punto più debole, riducendo la dipendenza in tempo reale dall'infrastruttura CA durante la creazione della sessione.

Nota di implementazione (realtà incorporata): Negli ambienti EVSE, confermare il supporto dell'estensione correlata alla pinzatura
nel tuo stack TLS incorporato e nella configurazione di build (ad esempio, mbedTLS, wolfSSL) e convalida il comportamento sull'hardware legacy,
perché la completezza delle funzionalità e i vincoli di memoria/RTOS variano.

Modello 3: governance della fiducia multi-radice

• Canale di aggiornamento dell'archivio attendibile unificato per più ancore OEM
• Aggiornamenti Canary + rollback quando si verificano errori di creazione del percorso

Modello 4: Governance della sincronizzazione temporale (non negoziabile)

• Politica NTP (o PTP, ove appropriato)
• Monitoraggio della deriva e soglie di allerta
• Comportamento definito quando gli orologi non sono attendibili

Continuità offline: mantenere Plug & Charge utilizzabile durante le disconnessioni edge-to-cloud

Cos'è (e cosa non è) la continuità offline

La continuità offline non significa "aggirare la PKI". È un degrado controllato che preserva:

• Integrità delle chiavi e degli archivi di fiducia
• Verificabilità per la fatturazione e la risposta agli incidenti
• Limiti espliciti su ciò che può essere convalidato localmente (e per quanto tempo)

Controller locali/proxy edge come primitive di disponibilità

• Mantenere cache di attendibilità locali (ancore/intermedi/CRL)
• Applicare criteri di autorizzazione locale limitati
• Misurazione/registri del buffer per una successiva riconciliazione
• Ridurre il raggio di esplosione WAN agendo come endpoint locale per EVSE

Figura 2 (immagine consigliata): Edge Proxy come cache di attendibilità nei siti di rete deboli

(Mostra gli EVSE che si connettono a un Edge Proxy/Controller locale in loco. Il proxy mantiene gli ancore di fiducia/intermedi memorizzati nella cache,
aggiornamento CRL pianificato, monitoraggio della sincronizzazione temporale e registri delle prove; memorizza gli eventi nel cloud CSMS/PKI quando l'uplink è instabile.)

Messaggio principale: I proxy Edge riducono la dipendenza live dagli endpoint OCSP/CRL esterni e consentono una continuità offline controllata senza bypassare la PKI.

CRA e VMP: dalle scadenze di rendicontazione di settembre 2026 a un modello operativo verificabile

Regole di segnalazione CRA: progettazione per l'orologio 24h/72h

Le regole di segnalazione CRA richiedono ai produttori di notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che hanno un impatto
sulla sicurezza dei prodotti con elementi digitali:

• Allerta precoce entro 24 ore di prendere coscienza
• Notifica completa entro 72 ore
• Rapporto finale entro finestre definite (a seconda della classe dell'incidente)

Un'interruzione su larga scala del sistema Plug & Charge causata da una revoca di massa o da una compromissione dell'ancora di fiducia può qualificarsi
come un incidente grave a seconda dell'impatto e delle prove di sfruttamento.

Processo di gestione delle vulnerabilità (VMP): capacità minime praticabili

1. La verità sulla flotta: inventario delle risorse + versioni (firmware EVSE, immagini del controller, versioni dell'archivio attendibile).
2. Integrazione SBOM (dinamica): SBOM mappato su artefatti distribuibili; correlazione continua con l'intelligence sulle vulnerabilità.
3. Gestione dell'esposizione basata su VEX: Mantenere le dichiarazioni VEX per distinguere "presente ma non sfruttabile" da "sfruttabile nella nostra distribuzione", consentendo una definizione credibile dell'ambito all'interno della finestra T+24h.
4. Perché VEX è importante nel sistema di 24 ore: SBOM ti dice cosa è presente; VEX ti aiuta a determinare cosa è sfruttabile, riducendo i falsi allarmi e impedendo ai team operativi di inseguire rumori non sfruttabili.
5. Accettazione e triage: avvisi ai fornitori, CVE, risultati interni; dare priorità a sfruttabilità + esposizione.
6. Flusso di lavoro di definizione dell'ambito T+24h: Correlazione SBOM + VEX + inventario per identificare le popolazioni colpite; decisioni iniziali di contenimento; acquisizione delle prove.
7. Flusso di lavoro di notifica T+72h: ambito confermato, mitigazioni, piano di implementazione/rollback, record di comunicazione.
8. Flusso di lavoro del rapporto finale: prove di convalida + causa principale + miglioramenti della prevenzione dopo la disponibilità delle misure correttive.
9. Ingegneria della cadenza delle patch: implementazione graduale, piani di rollback, artefatti firmati, gate di verifica.
10. Applicazione della catena di fiducia: avvio sicuro + aggiornamenti firmware sicuri; chiavi di firma protette in elementi HSM/sicuri.
11. Registrazione basata sulle prove: eventi di certificazione, modifiche all'archivio attendibile, errori di revoca, stato di sincronizzazione dell'ora.

Scenario di trust ad alta gravità: Se la revoca viene attivata da una chiave radice o di emissione compromessa,
trattarlo come un incidente di trust di massima gravità che richiede un contenimento immediato, azioni di trust-storage a livello di flotta,
e la predisposizione di reportistica allineata con la CRA in base alle prove di impatto e sfruttamento.

Lista di controllo per il conto alla rovescia della risposta agli incidenti CRA (modello operativo)

T+0 (Rilevamento / Consapevolezza)

• Congela le prove: registri, eventi di certificazione, versioni dell'archivio attendibile, stato di sincronizzazione dell'ora
• Identificare le superfici interessate: firmware EVSE, controller locali, endpoint TLS backend
• Coinvolgere il fornitore PKI/contatto per la sicurezza backend

T+24h (Prontezza di allerta precoce)

• Obiettivo principale: Utilizzo SBOM + VEX + inventario della flotta per determinare la popolazione interessata e inviare un allarme precoce supportato da prove
• Decidere il contenimento: revocare/ruotare, rollback dell'archivio fiduciario, isolamento del sito
• Bozza del pacchetto di allerta precoce: ambito di applicazione, misure di mitigazione in corso, posizione provvisoria

T+72h (Prontezza di notifica completa)

• Confermare le popolazioni colpite per regione/sito; fornire un piano di bonifica + metodo di implementazione
• Produrre comunicazioni con clienti/operatori e record di escalation

Finestra del rapporto finale

• Inviare il rapporto finale allineato ai requisiti CRA (i tempi dipendono dalla classe dell'incidente)
• Prove di convalida post-correzione + lezioni apprese

Quantificazione dei costi e dei rischi (modelli che puoi inserire nella tua flotta)

Modello di costo del lavoro di rinnovo manuale

Permettere:

• N = numero di endpoint TLS (EVSE + controller + gateway + nodi backend gestiti)
• L = durata del certificato (giorni)
• T = tempo umano per rinnovo (ore)
• C = costo del lavoro a pieno carico (USD/ora)

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

Modello di rischio di interruzione (scadenza o mancata distribuzione)

Permettere:

• P_miss = probabilità di mancato/fallito rinnovo per ciclo
• H_giù = ore di inattività previste per incidente
• C_ora = impatto aziendale orario (mancato fatturato, penalità, crediti SLA)

Cost_outage ≈ P_miss × H_down × C_hour

Guida alle decisioni: quando i controlli di revoca online falliscono (timeout OCSP/CRL)

1. Sito pubblico o deposito/flotta chiuso?
   • Pubblico → preferisco Hard-fail (o grazia strettamente controllata solo con prove + controlli compensativi)
   • Flotta/deposito → Grazia con prove potrebbe essere accettabile per finestre limitate
2. L'affidabilità della rete è prevedibile?
   • Sì → OCSP/CRL online + monitoraggio
   • Non → Pre-validazione dei bordi + memorizzazione nella cache (Finestre di aggiornamento CRL, catene memorizzate nella cache)
3. È possibile ridurre la dipendenza online durante la sessione?
   • Dove possibile → adottare Modello di pinzatura OCSP (spingere la prova più vicino al bordo)
4. Disponete di un sistema di registrazione delle prove e di una governance della sincronizzazione temporale?
   • In caso contrario, correggi prima questi problemi; le policy in modalità degradata sono difficili da difendere senza di esse

Matrice di responsabilità pratica (limiti che impediscono interruzioni)

Glossario

• PKI: Infrastruttura a chiave pubblica (emissione, convalida, trust anchor, revoca)
• ACME: Ambiente di gestione automatizzata dei certificati (emissione/rinnovo automatizzato)
• OCSP / CRL: Protocollo sullo stato dei certificati online / Elenco di revoca dei certificati
• Cucitura OCSP: Il server presenta una prova di revoca per ridurre la dipendenza OCSP live
• Ancore di fiducia: Certificati radice/intermedi di cui i tuoi validatori si fidano
• SBOM: Distinta base del software (inventario dei componenti per la definizione dell'ambito della vulnerabilità)
• VEX: Vulnerability Exploitability eXchange (dichiarazioni sullo stato di exploitability)
• TLS 1.3: Profilo TLS moderno; handshake + convalida del certificato rimangono sensibili alla latenza
• VMP: Processo di gestione delle vulnerabilità (accettazione, triage, patching, segnalazione, prove)

Rischio lungimirante: agilità crittografica e prontezza PQC

Mentre il 2026 sarà dominato da brevi durate dei TLS e dalla segnalazione CRA, le infrastrutture di ricarica dovrebbero iniziare a valutare
cripto-agilitàCon risorse di lunga durata (veicoli e caricabatterie), le architetture dovrebbero evitare il blocco dell'hardware garantendo
Gli elementi HSM/sicuri e gli stack incorporati possono supportare futuri aggiornamenti di algoritmi e profili di certificati senza richiedere un aggiornamento dell'hardware.

Domande frequenti

Plug & Charge può funzionare offline?

Parzialmente, per progettazione. Il degrado del P&C offline è controllato tramite caching di trust locale (ancore/intermedi/CRL ove possibile),
Policy di tolleranza esplicite e registri di controllo bufferizzati per la riconciliazione. Non dovrebbe bypassare la PKI; dovrebbe ridurre la dipendenza dal cloud live
preservando al contempo l'integrità e la verificabilità.

Con quale frequenza dobbiamo rinnovare i certificati con una durata di 199/200 giorni?

Pianificare più cicli di rinnovo all'anno per endpoint. Per molti operatori, il passaggio operativo inizia
24 febbraio 2026 perché DigiCert emetterà certificati TLS pubblici con un massimo 199 giorni validità a partire da quella data.
A livello di ecosistema più ampio, i requisiti di base definiscono una riduzione graduale a 200/100/47 giorni.

Cosa fa scattare gli obblighi di segnalazione della CRA?

Le regole di segnalazione CRA richiedono allerta precoce 24 ore su 24 E Notifica di 72 ore per vulnerabilità attivamente sfruttate e incidenti gravi,
più finestre di reporting finali. Un'interruzione della fiducia P&C su larga scala (ad esempio, revoca dannosa o compromissione della convalida) può qualificarsi a seconda
sull'impatto e sulle prove di sfruttamento; un VMP pronto per CRA dovrebbe supportare SBOM + VEX + inventario della flotta analisi entro le prime 24 ore.