Secure Boot, scadenza certificati Microsoft: come capire le date critiche e verificare lo stato del PC

La sostituzione dei certificati Secure Boot Microsoft 2011 con le nuove CA 2023 non è un semplice aggiornamento di Windows. È un passaggio molto più profondo, che riguarda la catena di fiducia dell’intero processo di avvio del PC: firmware UEFI, database delle chiavi, boot manager, revoche, aggiornamenti OEM, strumenti di gestione enterprise e stato reale dei dispositivi.

Il tema è diventato urgente perché i certificati storici usati da Secure Boot, introdotti nel 2011, arrivano a scadenza nel 2026. Non si tratta di una singola data, ma di una sequenza di scadenze che interessa componenti diversi della catena di avvio.

La Microsoft Corporation KEK CA 2011, usata per firmare gli aggiornamenti ai database Secure Boot, è scaduta il 24 giugno 2026; Microsoft UEFI CA 2011 è in scadenza il 27 giugno 2026; Microsoft Windows Production PCA 2011, utilizzata per firmare il boot loader di Windows, arriva invece alla scadenza del 19 ottobre 2026.

Il 2026 è l’anno in cui le piattaforme UEFI devono dimostrare di essere davvero aggiornabili, gestibili e coerenti con il modello di sicurezza che Secure Boot promette da oltre un decennio.

Perché Secure Boot dipende da più certificati

La funzione di Secure Boot consiste nell’impedire che, durante le prime fasi dell’avvio, venga eseguito codice non autorizzato. Per riuscirci, il firmware UEFI mantiene una serie di database crittografici che stabiliscono quali componenti sono attendibili, quali firme sono valide e quali elementi devono essere revocati.

Al centro del meccanismo ci sono variabili UEFI come PK, KEK, DB e DBX. La Platform Key, o PK, rappresenta il livello più alto di controllo sulla piattaforma. La Key Exchange Key, o KEK, consente di autorizzare gli aggiornamenti ai database. Il database DB contiene firme e certificati autorizzati. Il database DBX contiene invece elementi revocati, quindi componenti che non devono più essere considerati attendibili.

Quando Microsoft parla di aggiornamento dei certificati Secure Boot 2023 (nell’articolo abbiamo già spiegato come verificare se l’aggiornamento fosse già avvenuto), si riferisce al processo che riguarda l’inserimento delle nuove CA nei database UEFI, l’aggiornamento della KEK, l’adozione di boot manager firmati con la nuova catena e, in alcuni casi, la gestione di revoche e criteri di compatibilità aggiuntivi.

È per questo che la questione non può essere liquidata con un semplice “installare gli aggiornamenti di Windows”. Windows può predisporre il processo, ma il firmware deve accettarlo, conservarlo e applicarlo correttamente.

La sequenza delle scadenze: perché giugno e ottobre 2026

La prima data da osservare è il 24 giugno 2026, quando scade Microsoft Corporation KEK CA 2011. La KEK ha un ruolo particolarmente delicato perché firma gli aggiornamenti ai database DB e DBX: è una delle chiavi che permettono di modificare in modo attendibile l’elenco di ciò che il firmware considera autorizzato o revocato.

Subito dopo entra in gioco la scadenza di Microsoft UEFI CA 2011, usata storicamente per autorizzare componenti UEFI di terze parti, inclusi bootloader e Option ROM in diversi scenari. Infine, il 19 ottobre 2026, scade Microsoft Windows Production PCA 2011, certificato centrale per la firma del boot loader di Windows.

Queste scadenze non implicano necessariamente che un PC smetta di avviarsi all’istante: la scadenza di un certificato non equivale automaticamente a un blocco globale dei sistemi. Il rischio principale è un altro: le macchine che restano legate alla vecchia catena 2011 possono trovarsi in una condizione di sicurezza degradata, meno adatta a ricevere futuri aggiornamenti della catena di avvio, revoche o componenti firmati con le CA più recenti.

Il passaggio alle CA 2023 per Secure Boot

Le nuove CA Microsoft 2023 sostituiscono le CA 2011 nei rispettivi ruoli. Microsoft Corporation KEK 2K CA 2023 prende il posto della vecchia KEK. Windows UEFI CA 2023 diventa il riferimento per il boot loader Windows firmato con la nuova catena. Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023 servono invece a coprire gli scenari più ampi legati a componenti UEFI, driver e Option ROM.

Non esiste, tuttavia, un unico passaggio che porti magicamente tutti i dispositivi dai certificati “2011” ai certificati “2023”. Come abbiamo raccontato in altri nostri articoli, il processo può attraversare stati intermedi: nuove CA presenti nel DB, KEK aggiornata, boot manager non ancora sostituito, riavvii, attività pianificate in attesa, stato UEFICA2023 ancora “in progress“, oppure errori registrati nelle chiavi diagnostiche.

Windows Update non sempre basta

Per molti utenti consumer con PC recenti, il passaggio dovrebbe avvenire senza interventi manuali. I dispositivi moderni, soprattutto quelli prodotti a partire dal periodo in cui i certificati 2023 sono già stati integrati nelle catene OEM, dovrebbero essere in una posizione migliore. Ma negli ambienti aziendali il quadro è più complesso.

Le aziende gestiscono flotte eterogenee: notebook acquistati in anni diversi, workstation, desktop compatti, server fisici, macchine virtuali, dispositivi remoti, sistemi fuori garanzia ma ancora operativi, hardware ereditato da acquisizioni o sedi periferiche. In questo contesto, il fatto che Windows Update distribuisca le componenti necessarie non garantisce che tutti i dispositivi completino il processo.

Il firmware rimane decisivo. Se il BIOS UEFI non supporta correttamente l’inserimento delle nuove CA, se il produttore non ha distribuito un aggiornamento, se il database predefinito del firmware resta fermo alle vecchie chiavi, o se un’opzione necessaria è disattivata, Windows Update non può risolvere la situazione.

Secure Boot Health Checker: uno strumento per leggere in modo chiaro lo stato reale dell’avvio protetto

Come evidente dalla lettura degli articoli che abbiamo sin qui pubblicato, sono tante le chiavi del registro di sistema e gli eventi legati alla gestione della funzionalità Secure Boot da parte di Windows. Anche la documentazione Microsoft è densa di elementi da verificare e sui quali è possibile intervenire.

Secure Boot Health Checker è un nostro script PowerShell che prova a fare un po’ d’ordine.

Lo stato di Secure Boot non è accertabile guardando un unico punto del sistema perché le informazioni sono distribuite tra msinfo32, PowerShell, TPM, BitLocker, Registro di sistema, firmware UEFI e Visualizzatore eventi (Windows+R, eventvwr.msc). Un utente può vedere Secure Boot disattivato in Windows, PCR7 non associabile, eventi TPM-WMI come 1796 o 1801, chiavi di registro relative a UEFICA2023Status e WindowsUEFICA2023Capable, senza avere subito una lettura chiara del problema.

Secure Boot Health Checker prova a raccogliere questi segnali in un’unica interfaccia, distinguendo ciò che è davvero critico da ciò che è solo informativo.

Lo script verifica se il sistema si sta sta avviando in modalità UEFI o Legacy, se Secure Boot è effettivamente attivo, se il chip TPM è presente e conforme alle specifiche 2.0, se PCR7 può essere associato, se BitLocker può interferire con modifiche al firmware e se il percorso di aggiornamento ai certificati Microsoft UEFI CA 2023 mostra errori o stati incompleti.

L’obiettivo non è modificare automaticamente la configurazione del PC, ma offrire una diagnosi leggibile, prudente e centralizzata, con spiegazioni e suggerimenti operativi per capire dove intervenire: BIOS/UEFI, CSM, chiavi Secure Boot, aggiornamento firmware, BitLocker o aggiornamenti Windows.

CSM, cioè Compatibility Support Module, è la modalità di compatibilità che permette a un firmware UEFI di avviare sistemi in stile vecchio BIOS/Legacy; con Secure Boot non è compatibile perché l’avvio protetto richiede una catena di avvio UEFI pura, controllata tramite firme e chiavi attendibili.

Avvio e funzionamento dello script

Secure Boot Health Checker (download) è uno script PowerShell con interfaccia grafica pensato per verificare in modo più chiaro lo stato dell’avvio protetto su Windows 11.

Per utilizzarlo, è sufficiente aprire una finestra PowerShell con i diritti di amministratore quindi digitare quanto segue nella cartella contenente lo script:

powershell.exe -STA -ExecutionPolicy Bypass -File .\Check-SecureBoot.ps1

Lo script raccoglie tutti i dati correlati con lo stato di Secure Boot in un’unica finestra e li traduce in una diagnosi leggibile, evidenziando con stati come OK, ATTENZIONE ed ERRORE ciò che funziona, ciò che va verificato e ciò che può impedire una configurazione corretta.

Quali informazioni raccogliere e analizzare

Lo script serve soprattutto quando Windows mostra segnali contraddittori o difficili da interpretare. Per esempio, può capitare che nel BIOS Secure Boot sembri configurato, ma in Windows Confirm-SecureBootUEFI restituisca ancora False; oppure che msinfo32 mostri Configurazione PCR7: Impossibile effettuare l’associazione; oppure ancora che nel registro eventi compaiano errori come 1796, legati al mancato aggiornamento di variabili Secure Boot nel firmware. In questi casi non basta sapere se Secure Boot è attivato nel BIOS: bisogna capire se Windows sta avviando in modalità UEFI, se CSM è ancora attivo, se le chiavi Secure Boot sono installate correttamente, se il TPM è pronto e se BitLocker può essere coinvolto.

Dal punto di vista pratico, Secure Boot Health Checker (download) esegue controlli in sola lettura. Non attiva Secure Boot, non cancella il TPM, non modifica BitLocker e non cambia le chiavi UEFI. Lo script interroga Windows e presenta i risultati in più schede.

Nella sezione di sintesi mostra i dati principali: modalità BIOS, stato Secure Boot, stato PCR7, versione TPM, stato BitLocker e principali valori relativi agli aggiornamenti Secure Boot/UEFI CA 2023. Nella scheda dei dettagli mostra ogni controllo con una spiegazione e un’azione consigliata. Cliccando su Eventi, si accede alla raccolta degli eventi TPM-WMI più rilevanti Nei consigli, lo script produce una lettura complessiva della situazione, indicando i passaggi più prudenti da seguire.

Certo, possiamo integrare il paragrafo rendendolo più completo e meno “Windows-centrico”, con un riferimento alla compatibilità Linux e a **shim**.

Perché disattivare Secure Boot non è una soluzione

Davanti a errori di aggiornamento, firmware non allineati o messaggi poco chiari in Windows, la tentazione può essere quella di disattivare Secure Boot e considerare risolto il problema. È però una scorciatoia pericolosa.

Secure Boot non è un semplice requisito formale di Windows 11, ma uno dei controlli che proteggono le prime fasi dell’avvio, cioè il momento in cui bootkit e componenti non autorizzati possono ottenere un vantaggio particolarmente difficile da rilevare e correggere dopo il caricamento del sistema operativo.

Disattivare la protezione può aggirare temporaneamente un’incompatibilità, ma lascia irrisolta la causa reale: firmware da aggiornare, chiavi non corrette, database UEFI non allineati, CSM ancora attivo, TPM non pronto o catena di certificazione rimasta ferma alle vecchie CA.

Va inoltre superata l’idea, ancora piuttosto diffusa, che Secure Boot sia incompatibile per definizione con Linux o con scenari diversi da Windows. Per anni il tema è stato oggetto di discussioni accese, soprattutto perché il modello Secure Boot ha concentrato una parte importante della catena di fiducia intorno alle CA Microsoft e alla loro accettazione nei firmware UEFI.

Da allora, però, molte distribuzioni Linux hanno adottato un approccio più maturo: bootloader firmati, integrazione di shim, gestione della Machine Owner Key, procedure documentate per l’avvio protetto e maggiore attenzione alla compatibilità con il firmware. Anche diversi strumenti di terze parti si sono adeguati, adottando firme, catene di avvio compatibili e modalità operative in linea con il modello Secure Boot.