Secure Boot: la scadenza dei certificati del 2026 e cosa fare prima
A fine giugno 2026 alcuni dei certificati che reggono Secure Boot, il meccanismo che protegge l’avvio dei PC Windows, raggiungono la scadenza dopo quindici anni di servizio. Non è un dettaglio da amministratori di sistema: riguarda gran parte del parco macchine Windows e tocca il livello più delicato della sicurezza, quello che si gioca prima ancora che il sistema operativo si avvii. Il Patch Tuesday del 9 giugno è l’ultima finestra mensile ordinaria prima della scadenza, e questo lo rende un appuntamento da non mancare. Vediamo cosa scade davvero, cosa succede a chi non si prepara e quali passi compiere subito.
Che cos’è Secure Boot e cosa scade
Secure Boot è una funzione dello standard UEFI (Unified Extensible Firmware Interface, il firmware che ha sostituito il vecchio BIOS) che verifica, all’accensione, la firma digitale dei componenti caricati durante l’avvio. Se la firma non corrisponde a un’autorità di certificazione (CA, Certificate Authority) considerata attendibile dal firmware, il componente non viene eseguito. È la barriera pensata per fermare i bootkit, i malware che si annidano nelle prime fasi di avvio per ottenere il controllo della macchina prima delle difese tradizionali, come l’archivio di ICT Security Magazine documenta da tempo analizzando casi storici di bootkit.
La catena di fiducia si appoggia a certificati emessi da Microsoft nel 2011 e preinstallati nel firmware della maggior parte dei dispositivi. Secondo la documentazione Microsoft, tre certificati arrivano a fine validità nel 2026: il Microsoft Corporation KEK CA 2011, che gestisce la chiave di scambio (KEK, Key Exchange Key) usata per aggiornare i database di Secure Boot, scade il 24 giugno 2026; il Microsoft Corporation UEFI CA 2011, che firma componenti di terze parti e option ROM, scade il 27 giugno 2026; il Microsoft Windows Production PCA 2011, che firma il Windows Boot Manager vero e proprio, scade più avanti, il 19 ottobre 2026.
Cosa succede dopo la scadenza
Qui occorre evitare l’allarmismo, ma anche la sottovalutazione. I dispositivi che alla scadenza non avranno ricevuto i nuovi certificati continueranno ad accendersi, a funzionare e a ricevere i normali aggiornamenti di Windows. Non si tratta quindi di un blocco improvviso. Il problema è un altro e più sottile: quelle macchine smetteranno di poter ricevere i nuovi aggiornamenti relativi all’avvio sicuro. Niente più aggiornamenti del Windows Boot Manager, niente aggiornamenti dei database di Secure Boot, niente nuove voci nella lista di revoca (DBX) e, soprattutto, nessuna mitigazione per le vulnerabilità di avvio scoperte in futuro.
In pratica, un parco macchine fermo ai certificati del 2011 resta esposto alla prossima generazione di minacce a livello boot. La memoria di attacchi come BlackLotus, capace di aggirare Secure Boot, mostra perché la capacità di distribuire rapidamente nuove revoche e contromisure sia un presidio di sicurezza vivo e non un dettaglio formale. La conformità che funziona è quella che resta aggiornabile nel tempo, non quella congelata a una data.
La differenza tra utente domestico e organizzazione, qui, è sostanziale. Sul singolo PC consumer l’aggiornamento avviene in modo trasparente, purché il dispositivo riceva regolarmente gli aggiornamenti di Windows. In azienda il quadro è più complesso: il rischio non è il blocco operativo immediato, ma l’accumulo silenzioso di un debito di sicurezza che si manifesta solo quando emerge la prossima vulnerabilità di avvio e ci si accorge che le mitigazioni non possono più essere applicate. È il tipo di esposizione che non compare nei cruscotti di disponibilità dei sistemi e che per questo viene scoperta tardi, spesso durante un incidente o un audit. Tracciare lo stato dei certificati diventa quindi un indicatore di postura da inserire nei controlli periodici, accanto al normale patch management.
I nuovi certificati del 2023
La soluzione passa dall’adozione della nuova famiglia di certificati emessi nel 2023, che sono quattro. Il Windows UEFI CA 2023 sostituisce il certificato dei componenti di avvio Windows; il Microsoft Corporation KEK 2K CA 2023 è la nuova chiave di scambio. Il vecchio Microsoft Corporation UEFI CA 2011 viene invece rimpiazzato non da uno ma da due certificati distinti, pensati per un controllo più granulare della fiducia: il Microsoft UEFI CA 2023, che firma i boot loader di terze parti e le applicazioni EFI (incluso lo shim usato da molte distribuzioni Linux), e il Microsoft Option ROM UEFI CA 2023, dedicato alle option ROM dei componenti hardware di terze parti. Perché il passaggio sia completo, i nuovi certificati devono essere inseriti sia nel database delle firme (DB) sia nella KEK del firmware. Molti PC prodotti a partire dal 2024 li hanno già di fabbrica; il problema riguarda soprattutto il parco installato negli anni precedenti.
Il meccanismo di transizione è graduale e a incastro, e Microsoft lo descrive nella sua guida per le organizzazioni: prima si aggiunge il nuovo certificato a DB e KEK, così che il dispositivo possa fidarsi dei nuovi boot manager; poi si distribuisce un boot manager firmato con la nuova CA; quindi, per chi vuole l’applicazione piena, si aggiunge il vecchio certificato 2011 alla lista di revoca DBX; infine si applica un aggiornamento del Secure Version Number per impedire il ritorno a versioni precedenti.
Perché il 9 giugno è lo spartiacque
Il Patch Tuesday di giugno 2026 cade il 9 giugno. Essendo l’ultimo rilascio cumulativo mensile ordinario prima della scadenza di fine mese, diventa il punto di controllo naturale per verificare che la transizione ai certificati 2023 sia effettivamente avvenuta. Microsoft ha del resto avviato la distribuzione delle componenti di servizio già nelle settimane precedenti, includendo aggiornamenti dinamici dedicati alla migrazione. Chi gestisce flotte di dispositivi dovrebbe trattare questa data come la soglia entro cui completare le verifiche, senza confidare che basti l’ultimo minuto: il rollout dei certificati è progressivo e va monitorato, non dato per scontato. Il tema si lega alla più ampia questione della tempestività degli aggiornamenti, già emersa con forza nella crisi della patch management di inizio 2026.
Come ricevere e verificare l’aggiornamento
Per la maggior parte dei dispositivi la via più semplice è lasciare che sia Microsoft a gestire gli aggiornamenti relativi a Secure Boot tramite Windows Update. Il meccanismo prevede due modalità. Per impostazione predefinita è attiva l’opzione HighConfidenceOptOut, che aggiorna automaticamente, attraverso gli aggiornamenti cumulativi, i dispositivi giudicati a “elevata confidenza”, cioè quelli per cui Microsoft ritiene l’operazione sicura: è la strada che copre la maggior parte dei PC, soprattutto consumer, senza alcun intervento manuale. Per gli altri dispositivi esiste un’adesione esplicita, disattivata di default, segnalata da una chiave di registro dedicata (un valore DWORD denominato MicrosoftUpdateManagedOptIn) che autorizza l’aggiornamento dei certificati preservando il profilo di sicurezza del dispositivo. In entrambi i casi il dispositivo deve poter inviare dati diagnostici a Microsoft, configurabili via Criteri di gruppo o tramite mobile device management (MDM); sul livello esattamente richiesto la documentazione Microsoft non è del tutto univoca (la tabella delle chiavi cita il livello “obbligatorio”, un altro passaggio parla di livello “facoltativo”), per cui conviene allinearsi di volta in volta alle indicazioni della guida ufficiale.
La verifica è altrettanto importante della distribuzione. Lo stato si controlla nell’app Sicurezza di Windows, che mostra l’avanzamento dell’aggiornamento dei certificati Secure Boot, oppure da riga di comando interrogando il valore UEFICA2023Status, che Microsoft colloca nel sottopercorso Servicing della chiave di Secure Boot e che può assumere tre valori documentati: NotStarted, InProgress e Updated, dove quest’ultimo indica il completamento con successo. La chiave di adesione MicrosoftUpdateManagedOptIn risiede invece nel ramo Control di Secure Boot: è bene non confondere i due percorsi. Per le flotte aziendali Microsoft fornisce inoltre script di inventario in PowerShell, utili a fotografare lo stato dei dispositivi prima e dopo il rollout.
I nodi critici: hardware datato, Linux e ambienti gestiti
Non tutto è indolore. Alcuni dispositivi più vecchi montano firmware che potrebbe non accettare correttamente i nuovi certificati, per limiti o difetti dell’implementazione UEFI: per questi casi la strada passa dagli aggiornamenti firmware dei produttori, e i principali OEM (Dell, HP, Lenovo e altri) hanno pubblicato guide dedicate. Non si può escludere che una parte del parco più datato non riceva mai la correzione per via software e richieda interventi manuali o la sostituzione.
Attenzione anche agli scenari dual boot e ai sistemi non Windows: il Microsoft Corporation UEFI CA 2011 in scadenza è quello che firma, tra l’altro, lo shim usato da molte distribuzioni Linux, motivo per cui anche gli amministratori di ambienti misti e i fornitori di soluzioni di backup e recovery basate su supporti avviabili devono aggiornare i propri media alla nuova CA 2023. Negli ambienti gestiti, infine, vanno considerati i server e le macchine virtuali con Secure Boot abilitato, per i quali Microsoft ha rilasciato indicazioni specifiche. Chi distribuisce gli aggiornamenti tramite strumenti di gestione centralizzata farebbe bene a validare il processo su un gruppo pilota rappresentativo dei diversi modelli di hardware in uso, prima di estenderlo a tutta la flotta: è il modo più efficace per intercettare in anticipo i firmware problematici, evitando di scoprirli su larga scala a ridosso della scadenza.
Cosa fare adesso
La priorità di breve termine si riassume in pochi passi. Primo, fare l’inventario: stabilire quanti e quali dispositivi sono ancora fermi ai certificati 2011, usando l’app Sicurezza di Windows o gli script PowerShell, e quanti riportano già lo stato “updated”. Secondo, decidere il modello di distribuzione: per la maggior parte delle organizzazioni conviene affidarsi al flusso gestito da Microsoft, verificando i prerequisiti di dati diagnostici e l’adesione tramite la chiave di registro; chi gestisce in autonomia gli aggiornamenti deve pianificare il rollout interlacciato di DB, KEK e boot manager. Terzo, non dimenticare i casi particolari: firmware datati, supporti di avvio di terze parti, sistemi Linux in dual boot, server e macchine virtuali. Quarto, usare il Patch Tuesday del 9 giugno come scadenza interna di verifica, lasciando un margine prima delle date di fine giugno.
Il messaggio di fondo è coerente con quanto vale per ogni presidio di sicurezza: la protezione che conta non è quella attivata una volta e dimenticata, ma quella che resta aggiornabile. Secure Boot ha fatto il suo lavoro per quindici anni; rinnovarne le fondamenta per tempo è la condizione per continuare a fidarsene nei prossimi quindici.
