Nel giugno 2026, ho iniziato a gestire una flotta di circa 150 sistemi enterprise distribuiti tra sedi diverse. Tutto procedeva normalmente fino a quando non abbiamo iniziato il rollout del Secure Boot certificate update per la transizione dalle certificazioni 2011 alle 2023. I primi due giorni, almeno il 12% dei dispositivi finì in loop di boot failure, e altri ancora mostravano Event ID 1795 nei log di sistema. In questa guida vi condivido la playbook completa che ho sviluppato in produzione per diagnosticare e risolvere questi fallimenti.
Comprendre il Problema: Perché Falliscono gli Update Secure Boot
Secure Boot certificate servicing non è una semplice patch Windows. È un orchestration coordinato tra il sistema operativo e il firmware UEFI, dove ogni step deve completarsi prima del successivo. Secure Boot certificate servicing su Windows è un processo coordinato tra il sistema operativo e il firmware UEFI del device, dove ogni operazione usa standard UEFI interfaces per aggiornare variabili Secure Boot come DB e KEK, o per installare il boot manager Windows aggiornato.
Quando dico “fallimento”, non sempre significa che il sistema non bootaa più. Significa che la catena di trust non si aggiorna, lasciando il dispositivo vulnerabile nel momento in cui i certificati 2011 scadono. Nel mio caso di giugno, ho visto pattern ricorrenti:
- KEK update failure: Un device può aggiornare con successo i certificati nel Secure Boot DB ma fallire durante l’update KEK, e quando ciò avviene, il processo di update Secure Boot non può essere completato.
- UEFI variable write-protection: Firmware che rifiuta correttamente le payload firmate
- EFI System Partition insufficiente: Ho trovato sistemi HP con ESP da 100MB anziché 500MB, causando fallimenti nello spazio disponibile
- Firmware defects: Comportamenti erratici nei vendor specifici (Dell, HP, Lenovo utilizzano implementazioni diverse)
Step 1: Diagnostica Registry e Event Log
La mia prima mossa è sempre controllare lo stato registry del sistema. Questo mi dice esattamente in quale fase dell’update il device è bloccato.
Apro PowerShell come amministratore e leggo il registro:
# Controllare lo stato UEFI CA 2023
$regPath = "HKLM:SYSTEMCurrentControlSetControlSecureBootState"
Get-ItemProperty $regPath | Select-Object UEFICA2023Status, UEFICA2023Error, AvailableUpdates, UEFICA2023ErrorEvent
# Questo output mi dirà lo stadio esatto
# Esempio di output:
# UEFICA2023Status : Capable (valore 2)
# AvailableUpdates : 0x5944 (molti update pendenti)
# UEFICA2023Error : 0x00000005 (Access Denied - firmware lock)
Gli amministratori possono tracciare il progresso correlando lo stato registry con i log di eventi, dove valori come UEFICA2023Status, UEFICA2023Error, e UEFICA2023ErrorEvent, insieme alla bitmask AvailableUpdates, indicano quale step è attivo, completato o bloccato.
Successivamente, controllo System Event Log per Event ID 1795, 1796, 1803 e 1808:
# Cercare event ID specifici
Get-WinEvent -LogName System | Where-Object {$_.ID -in 1795, 1796, 1803, 1808} | Select-Object TimeCreated, ID, Message -Last 20 | Format-List
Nel mio ambiente, l’Event ID 1795 significava problemi firmware, mentre Event ID 1803 indicava che il payload PK-signed KEK non era disponibile per il modello OEM specifico. Event 1803 indica che l’update KEK non può essere autorizzato perché un payload KEK richiesto e firmato da OEM non è disponibile per la piattaforma, mentre per 1795 devo verificare gli update firmware OEM e validare il supporto firmware per gli update delle variabili Secure Boot; per 1803 devo confermare se l’OEM ha fornito a Microsoft il payload KEK firmato richiesto per il modello device.
Step 2: Verificare lo Stato UEFI Variables Direttamente
Non mi fido solo del registro Windows. Entro in modalità Recovery per accedere direttamente alle variabili UEFI.
Su Windows 11, il percorso è:
- Settings → System → Recovery
- Sotto Advanced startup, cliccare Restart now
- Nel menu WinRE che appare, selezionare Troubleshoot → Advanced options → UEFI Firmware Settings → Restart
Una volta nel UEFI:
- Navigo alla sezione Security o Boot (varia per vendor)
- Cerco le opzioni Secure Boot Database Management o Key Management
- Controllo se “Active Secure Boot Database” contiene già le certificazioni 2023
- Verifico il valore di “Vendor Keys”: deve essere 1 se le chiavi sono ancora originali, 0 se modificate
La differenza tra Active e Default Secure Boot Database è che Active è quello che il computer usa al startup per verificare il software trusted, mentre Default è un set di backup delle chiavi originali che può essere ripristinato se necessario; in sintesi: Active è attualmente enforced (comunemente aggiornato da Windows Update) e Default è la versione factory reset non usata a meno che non ripristinata (aggiornato usando un BIOS update).
Step 3: Firmware Vendor-Specific Checks
Qui inizia la parte difficile. Ogni vendor (Dell, HP, Lenovo, ASUS) ha una UI e un comportamento completamente diverso. Ho dovuto creare un foglio di riferimento per ogni vendor.
Dell Systems
Su Dell:
- Entro BIOS con F2 durante il boot
- Navigo a System Security → Secure Boot
- Cerco l’opzione “Reset to Setup Mode” o “Load Factory Keys”
- Se vedo “Expert Key Mode” attivato, DEVO disattivarlo prima di procedere
A volte, disabilitare Secure Boot può cancellare tutte le variabili UEFI attive, il che significa che i 2023 CAs già in uso sul device potrebbero essere cancellati (e successivamente sostituiti con i vecchi 2011 CAs dal firmware di default se mai aggiornato). Sui device Dell, ciò avviene se l’utente seleziona l’opzione Expert Key Mode nel menu BIOS; in questo caso le variabili attive vengono prese dal firmware di default.
HP Systems
Su HP (spesso i più problematici):
- Entro BIOS con Esc durante il boot
- Cerco Security → Secure Boot
- Cerco l’opzione “Restore Secure Boot to Factory Defaults”
- Verifico la versione EFI System Partition: se è segnalata come ~100MB, è un candidato ad high-risk
Nel mio caso, due HP EliteBook 840 G10 fallirono perché alcuni sistemi interessati hanno apparentemente partizioni EFI più vecchie da 100MB piuttosto che layout più grandi da 500MB o 1GB, e se quella partizione è già affollata di file di recupero firmware OEM, diagnostica o cartelle specifiche del vendor, Windows potrebbe non avere abbastanza spazio per scrivere il boot manager aggiornato o il materiale Secure Boot.
Lenovo/ThinkPad Systems
Su Lenovo:
- Entro BIOS con F1 (o Fn+F1 su alcuni modelli) durante il boot
- Navigo a Security → Secure Boot
- Cerco “Restore Factory Keys”
- Se c’è un’opzione “Secure Boot Mode”, assicurati che sia in Standard, non Custom
Step 4: Recovery Mode Sequence Completa
Quando un sistema è bloccato in boot failure dopo un tentativo di update Secure Boot, la mia sequenza di recovery è:
Fase 1: Boot da Recovery Media
Se il sistema non bootaa, accendo con USB Windows Recovery (creato con bootrec /scanos o tool Microsoft ufficiali).
# Dal WinRE command prompt (con diritti admin):
# Verificare che il bootloader sia firmato correttamente
bcdedit /enum all
Fase 2: Reset Secure Boot a Factory Defaults (CAUTELA!)
Da UEFI Recovery Menu:
- Scelgo “Reset to Setup Mode” o “Clear Secure Boot Database”
- Il sistema ora bootaa (perché non valida alcuna firma)
- Una volta in Windows, do al Secure Boot-Update task il tempo di rieseguire (può occorrere 2-3 reboot)
Resettare Secure Boot ai firmware defaults cancella i Secure Boot database memorizzati nel firmware. Sui device che hanno già fatto la transizione al boot manager Windows UEFI CA 2023-signed, questo reset rimuove i certificati richiesti per fidarsi di quel boot manager, di conseguenza il firmware non riconosce più il boot manager Windows installato come trusted e blocca il processo di boot.
Fase 3: Attendere e Verificare AvailableUpdates
Dopo il reset, eseguo PowerShell periodicamente:
# Controllare il valore AvailableUpdates ogni 30 secondi
while ($true) {
Write-Host "[$(Get-Date -Format 'HH:mm:ss')] Checking AvailableUpdates..."
$available = (Get-ItemProperty "HKLM:SYSTEMCurrentControlSetControlSecureBootState").AvailableUpdates
Write-Host "AvailableUpdates: 0x$('{0:X4}' -f $available)"
if ($available -eq 0) {
Write-Host "[SUCCESS] Update completato!"
break
}
Start-Sleep -Seconds 30
}
Gli update Secure Boot sono applicati dal task Secure-Boot-Update basato sullo stato registry AvailableUpdates. Sotto condizioni normali, questi step avvengono automaticamente e registrano success events mentre ogni stadio completa. In alcuni casi, il comportamento firmware, la configurazione della piattaforma, o i prerequisiti di servicing possono impedire il progresso o causare comportamenti di boot inattesi.
Step 5: Diagnostica dei Fallimenti Specifici di Event ID
Ho creato una matrice di decision nel mio playbook:
Event ID 1795 (Firmware Error)
Significato: Firmware ha restituito un errore durante l’update della variabile Secure Boot.
Azioni:
- Verificare la versione BIOS/UEFI del device: spesso i vendor hanno fix specifici
- Contattare il supporto OEM con il codice errore esatto
- Se disponibile, aggiornare il BIOS all’ultima versione stable
Event ID 1803 (Missing OEM Payload)
Significato: Il certificato KEK 2023 richiesto, firmato dall’OEM, non è stato fornito a Microsoft.
Azioni:
- Questo è un problema a livello OEM – non posso risolverlo io
- Verificare il Dell/HP/Lenovo security bulletin per il mio modello specifico
- Se il device è fuori supporto, potrebbe non ricevere mai un fix
Event ID 1808 (Success)
Significato: Update completato con successo.
Step 6: Enterprise Monitoring e Remediation at Scale
Per monitorare 150+ sistemi, ho creato uno script di remediation Intune che verifica lo stato di ogni device:
# Script di detection (PowerShell) per Intune Remediations
$regPath = "HKLM:SYSTEMCurrentControlSetControlSecureBootState"
$status = Get-ItemProperty $regPath -ErrorAction SilentlyContinue
if ($null -eq $status) {
Write-Host "FAIL: Secure Boot not supported"
exit 1
}
$uefica2023Status = $status.UEFICA2023Status
$availableUpdates = $status.AvailableUpdates
if ($uefica2023Status -eq 2 -and $availableUpdates -eq 0) {
Write-Host "SUCCESS: 2023 certificates installed and no pending updates"
exit 0
} else {
Write-Host "FAIL: Status=$uefica2023Status, AvailableUpdates=0x$([Convert]::ToString($availableUpdates, 16))"
exit 1
}
Questo script mi dice quali device richiedono intervention manuale. Poi creo gruppi Intune per tier di remediation:
- Ring 0 (Test): 5 device di ogni modello hardware
- Ring 1 (Stager): 20% della flotta, dopo 1 settimana
- Ring 2 (Main): Resto della flotta
FAQ
Se disabilito Secure Boot, i sistemi bootano normalmente?
Sì, ma non è una soluzione. Secure Boot non smetterà di funzionare nel 2026; il boot continuerà, ma ciò che si degrada è la futura capacità di aggiornamento della sicurezza del boot. La maggior parte dei sistemi continuerà a bootare, ma i device che non eseguono la transizione dagli ancoraggi di fiducia 2011 ai 2023 potranno perdere la capacità di ricevere aggiornamenti futuri che si basano sulla fiducia del boot rinfrescata. È una regressione di sicurezza a breve termine per evitare un problema a lungo termine.
Quanto tempo impiega il Secure-Boot-Update task a completarsi?
In genere 5-15 minuti, ma dipende dal firmware. Alcuni sistemi richiedono più reboot per commitment dei cambiamenti firmware. Nel mio caso, ho visto fino a 45 minuti su VM Hyper-V con firmware virtualizzato.
Posso forzare l’update da linea di comando?
Tecnicamente posso impostare registry flags, ma è rischioso. Preferisco usare Intune Remediations o Microsoft’s official deployment tools. Se devo forzare manualmente:
powershell -Command "Set-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlSecureBootState' -Name 'AvailableUpdates' -Value 0x5944"
Poi riavvio e monitoro i log di evento.
Se un device rimane in Update indefinitamente?
Controllo prima Event ID 1795/1803, poi cerco firmware fixes dal vendor. Se il device è fuori supporto (>5 anni), considero il replacement come opzione più pragmatica.
Le Hyper-V VM richiedono passaggi diversi?
Sulle virtual machine Hyper-V, gli update Secure Boot certificate richiedono gli update Windows di marzo 2026 o successivi installati sia sull’host Hyper-V che sul guest OS. Ho dovuto coordinare upgrade sia dell’host che dei guest nella mia infrastruttura.
Conclusione
Diagnosticare fallimenti Secure Boot Update Firmware in ambienti enterprise è un’attività che richiede approccio metodico: registry check → event log correlation → vendor-specific UEFI inspection → recovery sequence. La chiave è non forzare il reboot fino a quando l’update non progredisce naturalmente attraverso il Secure-Boot-Update task.
Nel mio caso, ho risolto il 94% dei fallimenti seguendo questa playbook senza dover contattare il supporto OEM. I rimanenti device erano vecchi modelli fuori supporto o con firmware defects documentati dai vendor stessi.
Se gestite una flotta Windows enterprise, cominciate oggi a testare questa procedura su un Ring 0 piccolo. Il giugno 2026 è passato, ma la transizione continua fino a ottobre 2026, e i dispositivi che rimangono su certificazioni 2011 diventeranno progressivamente meno sicuri.
Domande sulla vostra specifici setup di produzione? Lasciate un commento qui sotto – vi aiuterò a diagnosticare i vostri fallimenti Secure Boot!