Se amministrate infrastrutture enterprise con centinaia o migliaia di dispositivi Windows, il conto alla rovescia è iniziato: i certificati Microsoft Corporation KEK CA 2011 e Microsoft UEFI CA 2011 scadono a giugno 2026, seguiti dal Microsoft Windows Production PCA 2011 a ottobre 2026. Non si tratta di un semplice rinnovo: è una migrazione completa verso la nuova catena di certificati 2023 che richiede pianificazione, testing e deployment coordinato su physical server, workstation, VM Hyper-V e ambienti VMware.
Nella mia esperienza di system administrator, ho visto troppi colleghi trattare questa scadenza come un “problema di Windows Update”. In realtà, per ambienti enterprise con update gestiti tramite WSUS, SCCM o Intune, l’aggiornamento non è automatico: richiede intervento manuale tramite registry key, Group Policy o profili Intune. Chi non agisce in tempo rischia dispositivi che non possono più ricevere aggiornamenti di sicurezza per il boot manager, non si fidano di software di terze parti firmato con le nuove chiavi e restano esposti a vulnerabilità come il bootkit BlackLotus (CVE-2023-24932).
In questo articolo vi guido passo dopo passo nella migration strategy che sto applicando sulle infrastrutture che gestisco: dall’inventario iniziale al deployment via Intune e Group Policy, fino alla gestione di macchine virtuali e ambienti Linux. Se avete già letto il mio articolo introduttivo sulla scadenza dei certificati Secure Boot, qui entriamo nel vivo operativo della migrazione.
Cosa Scade e Perché Serve una Migration Strategy
La catena di certificati Secure Boot attuale si basa su tre certificati emessi nel 2011 che Microsoft sta sostituendo con equivalenti 2023:
- Microsoft Corporation KEK CA 2011 → KEK CA 2023 (scadenza giugno 2026)
- Microsoft Corporation UEFI CA 2011 → UEFI CA 2023 (scadenza giugno 2026)
- Microsoft Windows Production PCA 2011 → Windows UEFI CA 2023 (scadenza ottobre 2026)
Una novità importante della nuova catena è la separazione tra firma del boot loader e firma delle Option ROM: la UEFI CA 2023 ora distingue questi due ruoli, consentendo un controllo più granulare sulla trust chain del sistema. Questo è particolarmente rilevante per ambienti enterprise con hardware eterogeneo e schede di espansione PCIe con firmware firmato.
I dispositivi prodotti dal 2024 in poi tipicamente includono già i certificati 2023 nel firmware UEFI. Il problema riguarda il parco macchine esistente — e nelle aziende, parliamo spesso di dispositivi acquistati tra il 2018 e il 2023 che sono ancora perfettamente funzionanti ma hanno solo i certificati 2011 nel Secure Boot DB.
Fase 1: Inventario e Assessment del Parco Macchine
Prima di toccare qualsiasi configurazione, serve un inventario preciso. Ho imparato a mie spese che partire con il deployment senza sapere esattamente cosa c’è in campo porta a brutte sorprese — soprattutto con firmware UEFI datati che possono reagire male all’aggiornamento del DB.
Verificare lo Stato dei Certificati su un Singolo Dispositivo
Su ogni macchina Windows potete verificare i certificati Secure Boot correnti con PowerShell:
# Verifica certificati nel DB Secure Boot
Get-SecureBootUEFI -Name db | Format-List
# Verifica la KEK
Get-SecureBootUEFI -Name KEK | Format-List
# Controlla se il certificato 2023 è già presente
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match '2023'Se il comando restituisce True, il dispositivo ha già ricevuto l’aggiornamento. In caso contrario, rientra nel perimetro della migrazione.
Inventario su Scala con Intune o SCCM
Per ambienti con Microsoft Intune, potete usare le Device compliance policies per identificare i dispositivi che necessitano dell’aggiornamento. Con SCCM/MECM, una Configuration Baseline con script PowerShell che interroga il DB Secure Boot vi dà visibilità completa sul parco macchine.
Il mio consiglio è creare tre gruppi:
- Già aggiornati — certificati 2023 presenti, nessuna azione necessaria
- Da aggiornare — certificati 2011 soli, firmware UEFI compatibile
- Problematici — firmware UEFI datato che potrebbe richiedere aggiornamento preventivo dal vendor
Fase 2: Deployment dei Certificati 2023 via Registry Key
Il metodo più diretto per forzare l’aggiornamento dei certificati Secure Boot su dispositivi enterprise con update gestiti è la registry key AvailableUpdates. Microsoft ha predisposto un valore specifico che attiva l’intera catena di aggiornamento.
Il Valore Magico: 0x5944
La chiave di registro si trova in:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBootImpostando il valore DWORD AvailableUpdates a 0x5944 (22852 in decimale), Windows procede con:
- Installazione dei certificati KEK CA 2023 e UEFI CA 2023 nel database Secure Boot
- Aggiornamento del boot manager alla versione firmata con Windows UEFI CA 2023
- Aggiornamento della Forbidden Signature Database (DBX) per revocare i vecchi boot manager vulnerabili
Attenzione: dopo aver impostato il valore, servono almeno 48 ore e uno o più riavvii perché l’aggiornamento si completi. Non è un’operazione istantanea — il sistema esegue le modifiche al firmware UEFI durante la fase di boot, e alcune operazioni richiedono riavvii multipli.
Deployment Manuale via Script
Per un deployment controllato, uso questo script PowerShell che potete distribuire via GPO logon script o task schedulata:
# Imposta il registry value per il deployment certificati 2023
$path = 'HKLM:SYSTEMCurrentControlSetControlSecureBoot'
if (Test-Path $path) {
Set-ItemProperty -Path $path -Name 'AvailableUpdates' -Value 0x5944 -Type DWord
Write-Output "Secure Boot certificate update scheduled on $(hostname)"
} else {
Write-Warning "SecureBoot registry path not found on $(hostname)"
}Fase 3: Deployment su Scala con Group Policy e Intune
Metodo Group Policy
Microsoft ha introdotto il setting “Enable Secure Boot certificate deployment” nelle Group Policy amministrative. Per usarlo:
- Assicuratevi di avere gli Administrative Templates aggiornati (ADMX marzo 2026 o successivi)
- Navigate a
Computer Configuration → Administrative Templates → System → Secure Boot - Abilitate il criterio Enable Secure Boot certificate deployment
- Linkate la GPO alle OU contenenti i dispositivi target
Il vantaggio della GPO è la possibilità di fare un rollout graduale: prima su una OU di test, poi progressivamente su tutto il dominio.
Metodo Microsoft Intune
Per ambienti cloud-managed con Intune, il deployment è altrettanto diretto. Una nota importante: il servizio di licensing Intune è stato aggiornato il 27 gennaio 2026 per consentire il deployment delle configurazioni Secure Boot anche su edizioni Pro di Windows 10 e 11. Se i dispositivi hanno ricevuto la licenza Intune prima di quella data, potrebbe essere necessario un rinnovo della licenza.
Il profilo Intune si configura tramite Endpoint Security → Device configuration, utilizzando un profilo personalizzato con OMA-URI che imposta lo stesso valore di registro 0x5944. In alternativa, potete usare la Windows Configuration System (WinCS) CLI per deployment scriptati.
Fase 4: Macchine Virtuali — Hyper-V e VMware
Le macchine virtuali meritano un’attenzione particolare perché il meccanismo di aggiornamento varia significativamente tra gli hypervisor. Nella mia esperienza gestendo ambienti misti, questa è la fase che più facilmente viene dimenticata — con conseguenze che emergono solo quando è troppo tardi.
Hyper-V
Le VM Hyper-V si comportano come server fisici: l’aggiornamento passa attraverso il sistema operativo guest. Questo significa che potete usare gli stessi metodi descritti sopra (registry key, GPO, Intune) direttamente dentro la VM. Per VM Windows Server, la procedura è identica a quella dei server fisici — come descritto nel mio articolo sull’aggiornamento di marzo 2026, l’update KB5077241 ha già iniziato il rollout dei certificati 2023.
VMware vSphere
Qui la situazione è diversa e più complessa. Su VMware, l’aggiornamento dei certificati Secure Boot avviene lato hypervisor attraverso un aggiornamento del firmware, non dal guest OS. Questo significa che:
- Dovete aggiornare i file firmware OVMF/UEFI sull’host ESXi
- Per VM esistenti potrebbe essere necessario un aggiornamento manuale del Platform Key
- Per nuove VM, basta che l’host abbia il firmware aggiornato — erediteranno automaticamente i certificati 2023
Broadcom ha pubblicato una guida specifica per l’aggiornamento manuale del Platform Key nelle VM VMware — se gestite ambienti vSphere, vi consiglio di consultarla e pianificare l’intervento con anticipo.
Fase 5: Ambienti Linux e RHEL
Se nella vostra infrastruttura avete macchine Linux con Secure Boot abilitato (cosa sempre più comune con RHEL, Ubuntu Server e SUSE in ambienti enterprise), la migrazione dei certificati vi riguarda direttamente. Come ho spiegato nel mio articolo sulla sicurezza con AI agents, la supply chain del boot è uno dei vettori più critici.
Per RHEL, Red Hat ha pubblicato una guida specifica. Il punto chiave è aggiornare il pacchetto edk2-ovmf sull’hypervisor o sistema host:
# Aggiorna il pacchetto firmware OVMF con i certificati 2023
sudo dnf update edk2-ovmf
# Verifica che il pacchetto aggiornato includa i certificati 2023
rpm -q edk2-ovmfLe build più recenti di edk2-ovmf includono sia i certificati 2011 che 2023, garantendo compatibilità con shim firmati con entrambe le chiavi. Questo vi permette di aggiornare immediatamente senza rischi di incompatibilità.
Per VM Linux su VMware, ricordate che il workflow automatico di Microsoft non si applica: dovete usare i meccanismi di aggiornamento Secure Boot supportati da VMware specificamente per guest Linux.
Timeline e Checklist per IT Manager
Basandomi sulla mia esperienza con deployment su larga scala, ecco la timeline che consiglio per arrivare preparati a giugno 2026:
Marzo-Aprile 2026: Preparazione
- Completare l’inventario del parco macchine
- Aggiornare il firmware UEFI sui dispositivi con versioni datate (consultare il vendor)
- Verificare la compatibilità degli ADMX template per la GPO
- Testare il deployment su un gruppo pilota di 10-20 dispositivi
- Aggiornare gli host VMware/Hyper-V
Aprile-Maggio 2026: Rollout Progressivo
- Deployment via GPO/Intune sul primo 25% del parco macchine
- Monitorare per 48-72 ore, verificare che i riavvii completino l’aggiornamento
- Estendere al 50%, poi al 75%, infine al 100%
- Gestire le eccezioni (dispositivi problematici, firmware incompatibili)
Maggio-Giugno 2026: Verifica e Hardening
- Audit finale: tutti i dispositivi devono avere i certificati 2023 nel DB
- Verificare le VM Hyper-V e VMware
- Aggiornare il pacchetto
edk2-ovmfsugli host Linux - Documentare le eccezioni e pianificare la sostituzione dei dispositivi non aggiornabili
Errori Comuni da Evitare
All’inizio del mio primo deployment pilota, ho commesso un errore che voglio risparmiarvi: ho impostato il registry value e riavviato una sola volta, poi ho verificato — e i certificati 2023 non c’erano ancora. Il motivo è semplice: il processo richiede più riavvii e fino a 48 ore. Non forzate e non panicatevi se dopo il primo reboot non vedete cambiamenti.
Altri errori che ho visto fare:
- Dimenticare le VM — le macchine virtuali sono dispositivi a tutti gli effetti e necessitano dello stesso aggiornamento
- Non aggiornare il firmware UEFI prima — su hardware del 2018-2019 con firmware mai aggiornato, l’update del DB Secure Boot può fallire silenziosamente
- Ignorare il licensing Intune — dispositivi con licenza pre-27 gennaio 2026 potrebbero non ricevere il profilo
- Non testare il recovery — in caso di problemi post-update, dovete sapere come accedere al BIOS e gestire il Secure Boot manualmente. Avere un piano di disaster recovery è fondamentale
Connessione con la Sicurezza dell’Infrastruttura
Questa migrazione non è solo un adempimento tecnico: è una misura di sicurezza critica. I certificati 2023 sono stati introdotti anche per mitigare definitivamente la vulnerabilità BlackLotus (CVE-2023-24932), un bootkit UEFI che ha dimostrato come un attaccante potesse bypassare Secure Boot su sistemi con i vecchi certificati 2011.
Se gestite infrastrutture enterprise, questa migrazione si inserisce nel quadro più ampio della compliance — penso alla direttiva NIS2 e al Cyber Resilience Act che richiedono alle organizzazioni di mantenere aggiornata la catena di trust dei propri sistemi.
Inoltre, se state pianificando la vostra strategia hybrid multi-cloud, considerate che anche le istanze cloud con Secure Boot abilitato (come le Shielded VMs su Azure) necessitano dello stesso aggiornamento. Microsoft ha annunciato una soluzione specifica per Azure nella release 2603 di marzo 2026.
FAQ
Cosa succede se non aggiorno i certificati Secure Boot prima di giugno 2026?
I dispositivi non aggiornati non potranno più ricevere aggiornamenti di sicurezza per il boot manager Windows, non si fideranno di software firmato con le nuove chiavi 2023 e resteranno vulnerabili a exploit come BlackLotus. Il boot di Windows continuerà a funzionare fino a ottobre 2026, quando scade anche il Production PCA 2011, ma senza protezione aggiornata.
Il deployment del registry value 0x5944 può causare problemi di boot?
Su hardware con firmware UEFI aggiornato, il rischio è minimo. Tuttavia, su dispositivi con firmware molto datato (pre-2020 mai aggiornato), possono verificarsi problemi. Per questo consiglio sempre di aggiornare il firmware UEFI dal vendor prima di procedere, e di testare su un gruppo pilota. In caso di problemi, è possibile accedere al setup UEFI e ripristinare le impostazioni Secure Boot ai valori di fabbrica.
Le macchine Linux con Secure Boot sono interessate dalla scadenza?
Sì. Le distribuzioni Linux enterprise come RHEL, Ubuntu e SUSE usano shim firmati da Microsoft per il boot con Secure Boot abilitato. Aggiornando il pacchetto edk2-ovmf sugli host e il bootloader shim sulle VM, si garantisce la compatibilità con i nuovi certificati 2023. Red Hat ha pubblicato una guida dettagliata per ambienti RHEL.
Posso distribuire l’aggiornamento tramite WSUS?
L’aggiornamento dei certificati Secure Boot viene distribuito anche tramite Windows Update e WSUS, ma per dispositivi con update gestiti centralmente (dove gli aggiornamenti automatici sono limitati), il metodo più affidabile resta l’impostazione manuale del registry value 0x5944 o il deployment via Group Policy/Intune. WSUS distribuisce l’update come aggiornamento opzionale che richiede approvazione esplicita.
Quanto tempo richiede il deployment completo su un parco di 500+ dispositivi?
Nella mia esperienza, pianificate almeno 4-6 settimane per un deployment completo: 1 settimana per l’inventario e il pilota, 2-3 settimane per il rollout progressivo (considerando i 48 ore + riavvii per dispositivo) e 1-2 settimane per gestire eccezioni e verifiche finali. Non cercate di fare tutto in una settimana — il processo fisico di aggiornamento del firmware UEFI ha i suoi tempi.
Conclusione
La scadenza dei certificati Secure Boot a giugno 2026 è una di quelle deadline che non si possono rimandare. A differenza di molti aggiornamenti software, questa migrazione tocca il firmware UEFI — il livello più basso e critico della catena di boot — e richiede tempo, pianificazione e testing.
Il mio consiglio è iniziare subito con l’inventario e il gruppo pilota. Con la registry key 0x5944, Group Policy e Intune avete tutti gli strumenti per gestire il deployment su scala enterprise. Non dimenticate le VM (sia Hyper-V che VMware) e gli ambienti Linux, che richiedono procedure specifiche.
Se avete dubbi sulla procedura o volete condividere la vostra esperienza con la migrazione dei certificati Secure Boot 2023 nella vostra azienda, lasciate un commento — è sempre utile confrontarsi con chi sta affrontando la stessa sfida.