Microsoft Secure Boot si avvicina a uno degli eventi di lifecycle più rilevanti dell’ultimo decennio. I certificati Microsoft che ancorano la catena di trust UEFI fin dai tempi di Windows 8 e Windows Server 2012 iniziano a scadere a giugno 2026, con la rotazione che si estende fino a ottobre 2026. I dispositivi che non completano la transizione alla famiglia di certificati 2023 prima della scadenza continuano a fare boot, ma perdono la possibilità di ricevere aggiornamenti di sicurezza per l’ambiente di pre-boot — un rischio di sicurezza e di serviceability destinato a crescere nel tempo.
In questo articolo inquadriamo la transizione come un evento di lifecycle della piattaforma, paragonabile per impatto operativo a una deprecation di algoritmo crittografico. L’approccio consigliato è un rollout controllato a ondate — inventory, pilota, deployment esteso — con la verifica della readiness firmware per ogni modello hardware, e con particolare attenzione a Windows Server, dove l’aggiornamento non viene distribuito in automatico.
Perché i certificati Secure Boot sono importanti
Secure Boot è la funzionalità UEFI che garantisce l’esecuzione esclusiva di software fidato durante la sequenza di boot. Verifica le firme digitali dei componenti di pre-boot — moduli firmware, boot loader, applicazioni EFI — confrontandole con i certificati conservati nelle variabili firmware. La catena di trust è governata da quattro store: il Platform Key (PK), il Key Exchange Key (KEK), l’Allowed Signature Database (DB) e il Revoked Signature Database (DBX).
Il KEK autorizza gli aggiornamenti a DB e DBX. Il DB definisce ciò di cui ci si fida durante il boot. Il DBX registra ciò che è stato revocato — tipicamente componenti rivelatisi vulnerabili, come i boot loader coinvolti nel bootkit UEFI BlackLotus (CVE-2023-24932). Mantenere questi store aggiornati è essenziale sia per preservare la catena di trust, sia per ricevere le future entry di revoca man mano che vengono divulgate nuove vulnerabilità di livello boot.
Cosa scade e quando
Tre certificati Microsoft del 2011 iniziano a scadere tra giugno e ottobre 2026, sostituiti dalla famiglia di certificati 2023. La mappatura è lineare, con una sola asimmetria importante — il CA UEFI third-party del 2011 viene scisso in due successori 2023 distinti, separando la firma dei boot loader da quella delle option ROM per un controllo del trust più granulare.
- Microsoft Corporation KEK CA 2011 (store KEK) → Microsoft Corporation KEK 2K CA 2023
- Microsoft Windows Production PCA 2011 (store DB) → Windows UEFI CA 2023, usato per firmare il Windows Boot Manager
- Microsoft Corporation UEFI CA 2011 (store DB) → Microsoft UEFI CA 2023 (boot loader) e Microsoft Option ROM UEFI CA 2023 (option ROM), applicati solo sui dispositivi che originariamente includevano il CA UEFI third-party del 2011
I dispositivi prodotti dal 2024 in avanti tipicamente vengono spediti con i certificati 2023 già provisionati nel firmware. Lo sforzo di remediation si concentra quindi sulla coda lunga di sistemi costruiti tra il 2012 e il 2023 — sia hardware fisico sia macchine virtuali.
Il profilo di rischio dopo la scadenza
Quando i certificati 2011 scadono, i dispositivi che non hanno completato la rotazione continuano ad avviarsi e a operare normalmente. Gli aggiornamenti standard di Windows continuano a installarsi. Ciò che smette di funzionare è la possibilità di servicing dell’ambiente di pre-boot: niente nuove revoche DBX, niente aggiornamenti dei database Secure Boot, niente fix di sicurezza per il Windows Boot Manager, niente mitigazioni per le vulnerabilità di livello boot divulgate in seguito. Nel tempo, questo lascia la piattaforma esposta a tecniche di tipo bootkit e rootkit, che operano prima che le protezioni di livello sistema operativo entrino in funzione.
Sul piano operativo, la rotazione non è un cambio puramente lato sistema operativo. Il comportamento del firmware è il fattore vincolante, e le implementazioni OEM differiscono in modo sostanziale. Tra le insidie più comuni:
- Firmware che non accetta gli aggiornamenti delle variabili Secure Boot senza un BIOS update OEM
- Azioni di restore defaults nel firmware che sovrascrivono le variabili attive aggiornate da Windows, bloccando il boot successivo
- Prompt di recovery di BitLocker innescati dai cambiamenti nelle misurazioni TPM durante la transizione
- Macchine virtuali Hyper-V Generation 1, che non usano UEFI e non possono partecipare a Secure Boot
- VM Hyper-V Generation 2 create prima del 2023, che possono restare bloccate nello stato InProgress perché il loro firmware virtuale è stato provisionato con un trust anchor più vecchio
- Scenari di dual-boot o con boot loader di terze parti, dove i componenti non-Windows devono restare fidati anche con i nuovi database
Come Microsoft distribuisce l’aggiornamento
Il meccanismo di distribuzione è significativamente diverso tra Windows client e Windows Server, e questa distinzione è centrale per pianificare il rollout.
Su Windows 11 e sulle build supportate di Windows 10, i nuovi certificati vengono distribuiti tramite Controlled Feature Rollout (CFR) come parte degli aggiornamenti cumulativi mensili. Microsoft seleziona prima i dispositivi identificati come high-confidence — sulla base di hardware identity, versione firmware e segnali di successo precedenti — ed estende progressivamente la copertura. Sul dispositivo, un’attività pianificata chiamata Secure-Boot-Update, collocata sotto \Microsoft\Windows\PI\ in Task Scheduler, viene eseguita ogni 12 ore e applica gli stage del certificato in ordine: Windows UEFI CA 2023 nel DB, poi Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023 nel DB se il dispositivo conteneva il CA third-party del 2011, poi Microsoft Corporation KEK 2K CA 2023 nel KEK, e infine il Windows Boot Manager firmato 2023 — che richiede un riavvio per essere applicato.
Su Windows Server, lo stesso meccanismo è disponibile, ma il rollout non è automatico. Gli amministratori IT devono validare la readiness per ogni piattaforma e attivare il deployment manualmente con uno dei metodi supportati. I sistemi Windows Server 2025 spediti con i certificati 2023 già nel firmware sono l’eccezione — il resto richiede un’azione esplicita, incluse tutte le VM Hyper-V Generation 2 e i server fisici con Secure Boot abilitato.
Metodi di deployment per ambienti IT-managed
Microsoft documenta tre metodi IT-controlled che attivano la stessa attività pianificata. Vale la pena scegliere quello che si allinea al modello di gestione già in uso; non mescolare metodi diversi sullo stesso parco macchine senza una ragione chiara.
- Registry — impostare HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates a 0x5944 per distribuire tutti i certificati richiesti e aggiornare il boot manager alla versione firmata Windows UEFI CA 2023. È il valore consigliato per una transizione completa. Il valore 0x40 documentato nel KB5036210 distribuisce solo Windows UEFI CA 2023 nel DB ed è adatto a un approccio per fasi
- Group Policy — navigare in Computer Configuration > Administrative Templates > Windows Components > Secure Boot e abilitare l’impostazione Enable Secure Boot certificate deployment. È l’equivalente del path di registry, applicato via GPO
- Windows Configuration System (WinCS) — un modulo PowerShell e un eseguibile da riga di comando disponibili sui client domain-joined Windows 11 25H2, 24H2 e 23H2, pensati per interrogare e applicare le configurazioni Secure Boot localmente. È il path che Microsoft raccomanda per i rollout di scala più ampia su parchi macchine moderni
Microsoft Intune supporta la configurazione di Secure Boot tramite policy MDM, con una limitazione nota sulle edizioni Pro di Windows 10 e Windows 11 risolta dall’aggiornamento del servizio di licensing Intune del 27 gennaio 2026. I dispositivi ricevono il comportamento corretto attraverso il rinnovo automatico mensile della licenza.
Monitoring e validazione
Lo stato del deployment passa attraverso due segnali: l’event log di sistema di Windows e la chiave di registry di servicing. Entrambi vanno baselinati prima di avviare qualsiasi ondata di rollout.
Nell’event log di sistema, gli Event ID rilevanti vengono emessi dalla source TPM-WMI. I più importanti da monitorare:
- 1800 — è richiesto un riavvio prima che l’aggiornamento del boot manager possa completarsi
- 1801 — problema di staging; alcuni certificati o il boot manager firmato 2023 non sono ancora stati applicati. Spesso transitorio, si risolve dopo la successiva esecuzione dell’attività pianificata e un reboot
- 1795 e 1796 — errori a livello firmware, tipicamente “the system firmware returned an error: the media is write protected”. Indicano che il firmware OEM non accetta l’aggiornamento delle variabili
- 1803 — KEK firmato dal PK OEM mancante. Stop bloccante, escalation al vendor OEM o all’hypervisor
- 1808 — completamento riuscito dell’aggiornamento dei CA Secure Boot
Lo stato di servicing è esposto sotto HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. I valori UEFICA2023Status, UEFICA2023Error e UEFICA2023ErrorEvent descrivono l’avanzamento e l’eventuale codice di errore. Un valore UEFICA2023Error uguale a 0x0 indica un aggiornamento pulito.
Per gli ambienti client che eseguono Windows 11, l’app Sicurezza di Windows espone questo stato visivamente a partire da aprile 2026. Sotto Sicurezza dispositivo > Avvio protetto, un badge verde, giallo o rosso riflette la condizione corrente, con una progressiva estensione di guida e notifiche di sistema in arrivo da maggio 2026 in avanti. Pensato per l’utente finale sui dispositivi personali, è anche un sanity check utile sugli endpoint gestiti.
Da PowerShell, le one-liner di verifica più pratiche sono:
Confirm-SecureBootUEFI
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing |
Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEvent
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Microsoft UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Microsoft Option ROM UEFI CA 2023'
Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' |
Select-Object TaskName, State, Enabled
Hyper-V, VMware e workload cloud
Gli ambienti virtualizzati meritano un’attenzione specifica perché la catena di trust attraversa il confine tra host e guest, e perché le VM longeve portano con sé uno stato firmware ereditato dall’epoca in cui sono state create.
Su Hyper-V, solo le VM Generation 2 usano UEFI e quindi Secure Boot — le Generation 1 sono fuori scope e non partecipano all’aggiornamento. Le VM Generation 2 ricevono gli aggiornamenti dei certificati attraverso l’installazione Windows guest, esattamente come un server fisico. Un problema noto che riguarda l’aggiornamento del KEK sulle VM Hyper-V si manifesta come Event ID 1795 con il messaggio media is write protected; il fix va distribuito sia su host sia su guest, ed è incluso negli aggiornamenti Windows rilasciati dal 10 marzo 2026 in poi, con l’eccezione degli host Windows Server 2025, che richiedono la cumulative del 14 aprile 2026 o successive. Le VM ospitate su Azure ricevono la risoluzione attraverso il security update 2603 sul guest.
Le VM create prima dell’era firmware 2023 sono una classe di problema separata. La guidance Microsoft è chiara: una VM Generation 2 esistente con un trust anchor più vecchio non può acquisire i nuovi CA Secure Boot in place, indipendentemente dagli aggiornamenti cumulativi. Il path consigliato è creare una nuova VM Generation 2 con le impostazioni correnti, migrare il workload e dismettere quella legacy. È coerente con il principio più ampio per cui, sulle VM più vecchie, il fattore vincolante è lo stato del firmware virtuale, non lo stato di servicing di Windows.
Su VMware, l’aggiornamento del certificato viene distribuito come un firmware update virtuale lato hypervisor, non attraverso il guest. Errori persistenti su KEK o PK sulle VM VMware si riconducono quasi sempre allo stato dell’NVRAM di macchine virtuali create anni fa, dove la ownership del Platform Key o la persistenza delle variabili è compromessa. Il fix pragmatico in quei casi è ricostruire la VM su una versione corrente di ESXi con Secure Boot abilitato in fase di creazione, piuttosto che tentare un’enrollment manuale del PK — operazione che cambia la ownership della piattaforma e che, come effetto collaterale, innesca frequentemente la recovery di BitLocker.
Salvaguardie operative
La rotazione dei certificati tocca le variabili firmware, il Windows Boot Manager e le protezioni TPM-bound. Va trattata come un cambiamento a impatto produttivo, con le opportune cautele.
- Sospendere BitLocker prima di forzare passaggi che toccano il firmware sui sistemi critici, usando Suspend-BitLocker -MountPoint C: -RebootCount 3, e verificare prima la disponibilità della chiave di recovery
- Applicare per primi gli aggiornamenti firmware OEM; sono la base che permette ai nuovi certificati di essere accettati
- Evitare le azioni di restore defaults o di reset Secure Boot keys nel firmware dopo che la rotazione è completata — rimuovono i trust anchor 2023 e bloccano il boot successivo. In caso accada, usare le utility di recovery fornite dall’OEM
- Verificare che il recovery media (WinPE, partizioni di recovery OEM) sia firmato sotto la catena 2023 o sia in fase di refresh da parte del vendor; le immagini di recovery più vecchie possono prima o poi non riuscire più a fare boot sui sistemi migrati al trust 2023
- Procedere a ondate: pilota su un set rappresentativo che copra ogni modello hardware, revisione firmware, hypervisor ed edizione, poi estendere
Conclusioni
La transizione dei certificati Secure Boot del 2026 è un evento di lifecycle prevedibile e ben documentato, e gli strumenti che Microsoft ha rilasciato tra gennaio e aprile 2026 sono sufficienti per portarla a termine sulla maggior parte dei parchi macchine. Il rischio non è la complessità tecnica — è l’inerzia. I dispositivi lasciati sui trust anchor 2011 continueranno a fare boot, e questo rende facile rimandare il problema, fino a quando una revoca DBX o una nuova vulnerabilità di livello boot non rendono visibile il costo dell’attesa.
La disciplina che fa la differenza è la stessa che vale per qualsiasi deprecation crittografica: inventory prima della scadenza, validazione per classe di piattaforma, deploy a ondate e monitoring con gli indicatori che la piattaforma effettivamente espone. Trattiamo Windows Server come una linea di lavoro separata da Windows client, perché il modello di distribuzione è diverso. E trattiamo le VM più vecchie come candidati al rebuild piuttosto che alla remediation, perché il rapporto costi-benefici di forzare aggiornamenti di variabili su firmware virtuali ormai datati raramente premia il path della patch.