Secure Boot e la scadenza dei certificati Microsoft del 2011 sono diventati uno dei nodi più delicati per chi gestisce computer Windows nel 2026, perché non si parla di un banale aggiornamento ma di una sostituzione che tocca la catena di fiducia dell’intero avvio del PC. Firmware UEFI, database delle chiavi, boot manager, revoche, aggiornamenti dei produttori e strumenti aziendali finiscono tutti nello stesso ingranaggio. E il momento è arrivato perché i certificati storici, nati nel 2011, arrivano al capolinea proprio quest’anno.
Non si tratta di una data sola. È una sequenza di scadenze che colpisce pezzi diversi della catena di avvio. La Microsoft Corporation KEK CA 2011, quella che firma gli aggiornamenti ai database, è scaduta il 24 giugno 2026. Microsoft UEFI CA 2011 chiude i battenti il 27 giugno 2026. E Microsoft Windows Production PCA 2011, usata per firmare il boot loader di Windows, arriva alla scadenza il 19 ottobre 2026. In pratica il 2026 è l’anno in cui le piattaforme UEFI devono dimostrare di essere davvero aggiornabili e coerenti con quello che Secure Boot promette da oltre dieci anni.
Perché Secure Boot dipende da più certificati
La funzione serve a impedire che, nelle primissime fasi dell’accensione, parta codice non autorizzato. Per riuscirci il firmware UEFI tiene una serie di database crittografici che stabiliscono cosa è attendibile, quali firme valgono e cosa va revocato. Al centro ci sono variabili come PK, KEK, DB e DBX. La Platform Key è il livello più alto di controllo. La Key Exchange Key autorizza gli aggiornamenti ai database. Il DB raccoglie firme e certificati validi, mentre il DBX contiene gli elementi revocati, quelli che non vanno più considerati affidabili.
Quando si parla di aggiornamento ai certificati Secure Boot 2023, si intende l’inserimento delle nuove CA nei database UEFI, l’aggiornamento della KEK, l’adozione di boot manager firmati con la nuova catena e, in certi casi, la gestione di revoche e criteri di compatibilità. Ecco perché la faccenda non si liquida con un semplice “installa gli aggiornamenti”. Windows può preparare il terreno, ma è il firmware che deve accettare il processo, conservarlo e applicarlo bene.
La sequenza delle scadenze e il passaggio alle CA 2023
La prima data da tenere d’occhio è il 24 giugno 2026, con la scadenza della KEK CA 2011. Ha un ruolo delicato perché firma gli aggiornamenti ai database DB e DBX. Subito dopo tocca a Microsoft UEFI CA 2011, che storicamente autorizzava componenti UEFI di terze parti, bootloader e Option ROM. Infine, il 19 ottobre 2026, scade la Windows Production PCA 2011. Queste scadenze non vogliono dire che il computer smetta di avviarsi all’istante. Il rischio vero è un altro: le macchine ancorate alla vecchia catena 2011 si ritrovano in una condizione di sicurezza degradata, meno pronta a ricevere futuri aggiornamenti, revoche o componenti firmati con le CA più recenti.
Le nuove CA Microsoft 2023 prendono il posto delle vecchie nei rispettivi ruoli. La Corporation KEK 2K CA 2023 sostituisce la vecchia KEK, la Windows UEFI CA 2023 diventa il riferimento per il boot loader, mentre Microsoft UEFI CA 2023 e Option ROM UEFI CA 2023 coprono gli scenari più ampi. Non esiste però un passaggio unico che sposti per magia tutti i dispositivi. Il processo attraversa stati intermedi: nuove CA nel DB, KEK aggiornata, boot manager non ancora sostituito, riavvii in attesa, lo stato UEFICA2023 ancora “in progress” o errori registrati nelle chiavi diagnostiche.
Quando Windows Update non basta
Per molti utenti con PC recenti il passaggio dovrebbe avvenire da solo. I dispositivi moderni, soprattutto quelli usciti quando i certificati 2023 erano già integrati nelle catene dei produttori, partono avvantaggiati. Negli ambienti aziendali, invece, il quadro si complica. Le aziende gestiscono parchi macchine eterogenei: notebook di anni diversi, workstation, desktop, server fisici, macchine virtuali, dispositivi remoti, hardware fuori garanzia ma ancora vivo, roba ereditata da acquisizioni o sedi periferiche. Il fatto che Windows Update distribuisca le componenti non garantisce che tutti completino il processo.
Il firmware resta decisivo. Se il BIOS UEFI non supporta bene l’inserimento delle nuove CA, se il produttore non ha rilasciato un aggiornamento, se il database predefinito resta fermo alle vecchie chiavi o se un’opzione necessaria è disattivata, Windows Update non può farci nulla. Per questo lo stato reale dell’avvio protetto non si legge da un solo punto: le informazioni sono sparse tra msinfo32, PowerShell, TPM, BitLocker, registro di sistema, firmware UEFI e Visualizzatore eventi. Si possono vedere Secure Boot disattivato in Windows, PCR7 non associabile, eventi come 1796 o 1801, chiavi di registro relative a UEFICA2023Status, senza capirci granché al primo colpo.
Perché disattivare Secure Boot non è la soluzione
Davanti a errori di aggiornamento o messaggi poco chiari, la tentazione è spegnere tutto e dirsi che il problema è risolto. È una scorciatoia pericolosa. Secure Boot non è un requisito formale di Windows 11, ma uno dei controlli che proteggono le prime fasi dell’avvio, il momento in cui bootkit e componenti non autorizzati possono prendere un vantaggio difficilissimo da scovare dopo. Disattivare la protezione aggira l’incompatibilità sul momento, ma lascia in piedi la causa vera: firmware da aggiornare, chiavi sbagliate, database UEFI non allineati, CSM ancora attivo, TPM non pronto o catena rimasta ferma alle vecchie CA.
Va archiviata anche l’idea, ancora diffusa, che Secure Boot sia incompatibile per definizione con Linux. Per anni il tema ha acceso parecchie discussioni, soprattutto perché il modello concentrava buona parte della catena di fiducia attorno alle CA Microsoft e alla loro accettazione nei firmware. Da allora molte distribuzioni hanno scelto un approccio più maturo: bootloader firmati, integrazione di shim, gestione della Machine Owner Key, procedure documentate per l’avvio protetto. Anche diversi strumenti di terze parti si sono adeguati, adottando firme e catene compatibili con il modello Secure Boot.