I certificati Secure Boot 2011 di Microsoft sono scaduti: la KEK CA 2011 il 24 giugno 2026, la UEFI CA 2011 il 27 giugno e la Windows Production PCA 2011, quella che firma il boot manager di Windows, il 19 ottobre 2026. I PC e i server che non hanno ancora i certificati 2023 continuano ad avviarsi e a installare gli aggiornamenti mensili di Windows. Quello che perdono è la possibilità di ricevere nuove protezioni per la fase di avvio: aggiornamenti del boot manager, dei database DB e DBX e delle revoche.
Non è un'emergenza da fermo macchina, ma un debito di sicurezza che cresce ogni mese. E l'aggiornamento si può fare anche adesso, a certificati scaduti. In questa guida vediamo cosa è cambiato, come verificare lo stato di un sistema, come censire un parco aziendale e in che ordine lavorare.
I tre certificati scaduti e i loro sostituti
Sono tre certificati, ognuno con un ruolo diverso nella catena di fiducia di Secure Boot. La tabella riporta date e sostituti indicati da Microsoft.
| Certificato 2011 | Scadenza | Dove si trova | A cosa serve | Sostituito 2023 |
|---|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | 24/06/2026 | KEK | Autorizza gli aggiornamenti di DB e DBX | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | 27/06/2026 | DB | Firma bootloader e applicazioni EFI di terze parti e le option ROM | Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | 19/10/2026 | DB | Firma il boot manager di Windows | Windows UEFI CA 2023 |
La UEFI CA 2011 viene sostituita da due certificati: uno per i bootloader di terze parti, uno per le option ROM delle schede di rete, video e storage. Così un sistema può fidarsi delle option ROM senza fidarsi di qualunque bootloader esterno.
La KEK è il pezzo più delicato. Senza la KEK 2023, Windows non può più scrivere aggiornamenti firmati nei database DB e DBX, e quindi nemmeno le revoche future.
Cosa rischia davvero un parco non aggiornato
Il rischio è una perdita progressiva di protezione all'avvio, non il blocco dei PC. Secondo Microsoft i dispositivi senza certificati 2023 continuano ad avviarsi e a ricevere gli aggiornamenti standard, ma non ricevono più le nuove protezioni per la fase di boot: aggiornamenti del Windows Boot Manager, dei database Secure Boot, delle liste di revoca e le mitigazioni per vulnerabilità di avvio scoperte in futuro.
Nel tempo questo indebolisce la difesa contro i bootkit, il malware che si carica prima del sistema operativo. Microsoft cita anche effetti sugli scenari che si appoggiano a Secure Boot, come l'irrobustimento di BitLocker e i bootloader di terze parti.
Il rischio operativo, quello che può fermare una macchina, sta in un aggiornamento fatto male più che nella scadenza. Su firmware vecchi o non compatibili Microsoft segnala errori di validazione, richieste ripetute della chiave di ripristino BitLocker e blocchi all'avvio. Per questo l'aggiornamento va pilotato, non lanciato su tutto il parco in un colpo solo.
Come verificare lo stato su un singolo sistema
Su un singolo host bastano pochi controlli da PowerShell avviato come amministratore: Secure Boot attivo, certificati 2023 presenti in DB e KEK, stato dell'aggiornamento nel registro.
# Secure Boot attivo? (True = attivo)
Confirm-SecureBootUEFI
# Windows UEFI CA 2023 presente nel DB? (True = presente)
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
# KEK 2023 presente? (True = presente)
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
# Stato dell'aggiornamento ed eventuale codice di errore
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' | Select-Object UEFICA2023Status, UEFICA2023ErrorUEFICA2023Status vale NotStarted, InProgress o Updated. Updated significa che sono stati applicati tutti i certificati e il boot manager firmato 2023. Se UEFICA2023Error è diverso da zero, il processo si è fermato e la causa si trova negli eventi.
Gli eventi si leggono nel registro System, origine TPM-WMI. Quelli da conoscere sono pochi.
| Evento | Significato | Cosa fare |
|---|---|---|
| 1808 | Certificati e boot manager 2023 applicati: il sistema è aggiornato | Niente |
| 1801 | Certificati non ancora applicati al firmware | Verificare che l'aggiornamento sia stato avviato |
| 1800 | Serve un riavvio prima di proseguire | Riavviare |
| 1803 | Non esiste una KEK firmata con la Platform Key di questo dispositivo | Sentire il produttore dell'hardware o dell'hypervisor |
| 1795 | Il firmware ha restituito un errore | Cercare un aggiornamento firmware |
| 1802 | Aggiornamento bloccato per un problema firmware noto | Attendere il firmware corretto del produttore |
| 1032 | Con la configurazione attuale BitLocker andrebbe in ripristino | Sospendere BitLocker per due riavvii |
Come censire un parco aziendale
Oltre qualche decina di macchine il controllo a mano non regge: serve uno script che legga gli stessi valori su tutti i sistemi e restituisca un output strutturato. Microsoft pubblica uno script di inventario di esempio che raccoglie stato del registro, eventi, produttore, modello e versione del firmware.
Lo script si distribuisce con lo strumento che si usa già: Run Scripts di Configuration Manager, script o remediation di Intune, oppure una piattaforma di patch management che esegue script sugli endpoint, come Action1. L'output va raccolto in un unico punto e diviso per stato.
| Stato | Cosa significa | Prossima azione |
|---|---|---|
| Updated | DB, KEK e boot manager aggiornati | Nessuna sul sistema; restano da aggiornare i supporti di avvio |
| InProgress | Processo avviato e non concluso: spesso manca un riavvio o il firmware ha rifiutato un passaggio | Leggere UEFICA2023Error e gli eventi 1800, 1795, 1803 |
| NotStarted | Il sistema non è ancora stato indirizzato all'aggiornamento | Inserirlo in un gruppo pilota o in un'ondata |
| Valore assente | La chiave di stato non esiste | Verificare che Secure Boot sia attivo e il livello di aggiornamento: le chiavi di stato arrivano con gli aggiornamenti da novembre 2025 |
Conviene raggruppare anche per produttore, modello e firmware: è la stessa logica che Microsoft usa per decidere su quali dispositivi applicare l'aggiornamento in automatico. Prima di estendere, Microsoft suggerisce di provare almeno quattro dispositivi per ogni combinazione.
Come si avvia l'aggiornamento
L'aggiornamento parte impostando a 0x5944 il valore AvailableUpdates in HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot. Un'attività pianificata, che gira ogni 12 ore, applica in sequenza la Windows UEFI CA 2023, le due CA per terze parti se il DB contiene la UEFI CA 2011, la KEK 2023 e infine il boot manager firmato 2023. Con Intune si usa la policy EnableSecurebootCertificateUpdates del CSP SecureBoot con valore 22852, che corrisponde a 0x5944. Microsoft raccomanda di non mescolare metodi diversi sullo stesso dispositivo e di mettere in conto circa 48 ore e uno o più riavvii.
Per provare su una macchina singola:
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Quando AvailableUpdates diventa 0x4100 si riavvia e si rilancia l'attività. A processo concluso il valore scende a 0x4000.
Più di qualche decina di sistemi da verificare?
Impostiamo il censimento con lo strumento che usate già, Configuration Manager, Intune o Action1, e vi restituiamo i sistemi divisi per stato con l'azione per ciascun gruppo.
Richiedi una call di 30 minuti, gratuita e senza impegno.
Richiedi la callI casi che si bloccano
Nella pratica i sistemi fermi a InProgress o NotStarted ricadono di solito in una di queste quattro situazioni.
Firmware OEM vecchio
Il firmware rifiuta la scrittura (evento 1795) oppure il modello ricade in un problema noto (evento 1802). Serve l'aggiornamento del BIOS/UEFI del produttore. Il firmware aggiornato conta anche per un altro motivo: aggiorna i valori predefiniti di Secure Boot. Se qualcuno ripristina le impostazioni di fabbrica e i predefiniti non contengono la Windows UEFI CA 2023, una macchina che usa già il boot manager 2023 non si avvia più. Per i dispositivi non più supportati dal produttore, Microsoft arriva a suggerire la sostituzione.
Macchine virtuali
La KEK si può aggiornare solo con una versione firmata dalla Platform Key (PK) del dispositivo, e in una VM la PK è quella del produttore dell'hypervisor. Se Windows non trova una KEK firmata per quella PK registra l'evento 1803 e si ferma. Per VMware le indicazioni sono negli articoli Broadcom KB 423893 e KB 423919, quest'ultimo sull'aggiornamento manuale della PK nelle VM. Più in generale, Microsoft indica due strade per le VM: il fornitore della piattaforma può includere i nuovi certificati nel firmware virtuale delle macchine nuove, mentre sulle VM esistenti l'aggiornamento passa da Windows, se il firmware virtuale lo supporta.
Sistemi senza cumulativo recente
I certificati 2023 sono inclusi negli aggiornamenti cumulativi da maggio 2025, anche se non vengono applicati in automatico; le chiavi di stato arrivano con gli aggiornamenti da novembre 2025. Un sistema fermo a un cumulativo più vecchio non ha né i certificati né il modo di segnalare lo stato. Solo le versioni di Windows ancora in supporto ricevono i nuovi certificati.
Dual boot con Linux
Il bootloader di Linux (shim) si appoggia alla Microsoft UEFI CA: prima di intervenire su DB e DBX va verificata con la propria distribuzione la disponibilità di uno shim firmato con la CA 2023.
Se i sistemi bloccati sono pochi ma critici, come server, VM o modelli fuori supporto, conviene un intervento mirato: è il caso tipico dell'assistenza sistemistica.
L'ordine di lavoro consigliato
L'ordine conta più della velocità. È lo stesso principio che indica Microsoft: prima si aggiornano certificati e componenti di avvio, solo dopo si applicano le revoche.
- Censire: quali sistemi hanno Secure Boot attivo, in che stato sono, con quale firmware.
- Portare tutti all'ultimo aggiornamento cumulativo e, dove serve, all'ultimo firmware del produttore.
- Completare DB, KEK e boot manager, prima su gruppi pilota e poi per ondate.
- Aggiornare i supporti di avvio: chiavette di ripristino, immagini WinPE, boot image di PXE e di Configuration Manager.
- Solo alla fine, con il parco a Updated, valutare la revoca della Windows Production PCA 2011 nel DBX.
Cosa non fare: togliere la PCA 2011 dal DB o applicare la revoca nel DBX prima di aver aggiornato supporti e parco. Con la PCA 2011 nel DBX il firmware non si fida più di nessuna applicazione di avvio firmata con quel certificato, compresi supporti di ripristino e avvio PXE. Windows rifiuta la revoca se la Windows UEFI CA 2023 non è nel DB o se il boot manager in uso è ancora quello 2011 (eventi 1797 e 1798), ma non può controllare le chiavette e i server di avvio che stanno fuori dalla macchina.
Dall'esperienza sul campo
In un'azienda reale il quadro è più frammentato di quanto suggeriscano le guide. In un rollout che abbiamo seguito con Configuration Manager in un'azienda con oltre 500 postazioni e server, il censimento del 26 agosto 2026 sui sistemi che avevano risposto dava 86 Updated, 90 InProgress, 150 NotStarted, 176 senza valore di stato e 9 senza output.
I 176 sistemi senza stato sono stati il primo filone di lavoro: prima di parlare di certificati andava verificato il livello di aggiornamento. Tra gli InProgress c'era una VM VMware ferma con l'evento 1803 e la KEK 2023 mancante, il caso della PK dell'hypervisor descritto sopra. La revoca nel DBX, per scelta, non è stata applicata su nessun sistema: è la fase che chiude il progetto, non quella che lo apre.
Quando chiedere aiuto
Con un parco piccolo e omogeneo, Windows Update e le indicazioni Microsoft di solito bastano. Con modelli diversi, firmware datati, macchine virtuali o server critici conviene trattare l'aggiornamento come un progetto di patch management: censimento, gruppi pilota, ondate, verifica. Nexsys lo affronta così nel suo servizio di patch management per aziende. Il primo passo è una call di 30 minuti, gratuita e senza impegno, da richiedere dal modulo qui sotto.
Fonti
- Microsoft Support, Windows Secure Boot certificate expiration and CA updates (KB5062710)
- Microsoft Support, Secure Boot Certificate updates: Guidance for IT professionals and organizations (KB5062713)
- Microsoft Support, Registry key updates for Secure Boot: Windows devices with IT-managed updates (KB5068202)
- Microsoft Support, Secure Boot DB and DBX variable update events (KB5016061)
- Microsoft Support, Frequently asked questions about the Secure Boot update process (KB5068008)
- Microsoft Support, How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 (KB5025885), per le revoche e l'aggiornamento dei supporti di installazione
- Microsoft Learn, Aggiornare i certificati di avvio protetto per i dispositivi Windows
- Microsoft Learn, Provider di servizi di configurazione dei criteri di avvio sicuro (Policy CSP SecureBoot)
- Microsoft Learn, Gestire gli aggiornamenti di avvio protetto (Azure Local), per i comandi di verifica di DB e KEK
- Broadcom, Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines (KB 423893) e Manual Update of the Secure Boot Platform Key in Virtual Machines (KB 423919)