{"id":2629,"date":"2026-07-01T08:22:48","date_gmt":"2026-07-01T06:22:48","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/diagnosticare-fallimenti-secure-boot-update-firmware-uefi-variables-recovery\/"},"modified":"2026-07-01T08:22:48","modified_gmt":"2026-07-01T06:22:48","slug":"diagnosticare-fallimenti-secure-boot-update-firmware-uefi-variables-recovery","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/diagnosticare-fallimenti-secure-boot-update-firmware-uefi-variables-recovery\/","title":{"rendered":"Come Diagnosticare e Risolvere Fallimenti Secure Boot Update Firmware: La Mia Playbook BIOS Vendor-Specific, UEFI Variables Check e Recovery Mode Sequence per Production Enterprise"},"content":{"rendered":"<p>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\u00ec in loop di boot failure, e altri ancora mostravano <strong>Event ID 1795<\/strong> nei log di sistema. In questa guida vi condivido la playbook completa che ho sviluppato in produzione per diagnosticare e risolvere questi fallimenti.<\/p>\n<h2>Comprendre il Problema: Perch\u00e9 Falliscono gli Update Secure Boot<\/h2>\n<p><em>Secure Boot certificate servicing<\/em> non \u00e8 una semplice patch Windows. \u00c8 un <strong>orchestration coordinato tra il sistema operativo e il firmware UEFI<\/strong>, dove ogni step deve completarsi prima del successivo. <cite>Secure Boot certificate servicing su Windows \u00e8 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.<\/cite><\/p>\n<p>Quando dico &#8220;fallimento&#8221;, non sempre significa che il sistema non bootaa pi\u00f9. Significa che <strong>la catena di trust non si aggiorna<\/strong>, lasciando il dispositivo vulnerabile nel momento in cui i certificati 2011 scadono. Nel mio caso di giugno, ho visto pattern ricorrenti:<\/p>\n<ul>\n<li><strong>KEK update failure<\/strong>: <cite>Un device pu\u00f2 aggiornare con successo i certificati nel Secure Boot DB ma fallire durante l&#8217;update KEK, e quando ci\u00f2 avviene, il processo di update Secure Boot non pu\u00f2 essere completato.<\/cite><\/li>\n<li><strong>UEFI variable write-protection<\/strong>: Firmware che rifiuta correttamente le payload firmate<\/li>\n<li><strong>EFI System Partition insufficiente<\/strong>: Ho trovato sistemi HP con ESP da 100MB anzich\u00e9 500MB, causando fallimenti nello spazio disponibile<\/li>\n<li><strong>Firmware defects<\/strong>: Comportamenti erratici nei vendor specifici (Dell, HP, Lenovo utilizzano implementazioni diverse)<\/li>\n<\/ul>\n<h2>Step 1: Diagnostica Registry e Event Log<\/h2>\n<p>La mia prima mossa \u00e8 sempre controllare lo <strong>stato registry<\/strong> del sistema. Questo mi dice esattamente in quale fase dell&#8217;update il device \u00e8 bloccato.<\/p>\n<p>Apro PowerShell come amministratore e leggo il registro:<\/p>\n<pre><code># Controllare lo stato UEFI CA 2023\n$regPath = \"HKLM:SYSTEMCurrentControlSetControlSecureBootState\"\nGet-ItemProperty $regPath | Select-Object UEFICA2023Status, UEFICA2023Error, AvailableUpdates, UEFICA2023ErrorEvent\n\n# Questo output mi dir\u00e0 lo stadio esatto\n# Esempio di output:\n# UEFICA2023Status    : Capable (valore 2)\n# AvailableUpdates    : 0x5944 (molti update pendenti)\n# UEFICA2023Error     : 0x00000005 (Access Denied - firmware lock)\n<\/code><\/pre>\n<p><cite>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 \u00e8 attivo, completato o bloccato.<\/cite><\/p>\n<p>Successivamente, controllo <strong>System Event Log<\/strong> per Event ID 1795, 1796, 1803 e 1808:<\/p>\n<pre><code># Cercare event ID specifici\nGet-WinEvent -LogName System | Where-Object {$_.ID -in 1795, 1796, 1803, 1808} | Select-Object TimeCreated, ID, Message -Last 20 | Format-List\n<\/code><\/pre>\n<p>Nel mio ambiente, l&#8217;<strong>Event ID 1795<\/strong> significava problemi firmware, mentre <strong>Event ID 1803<\/strong> indicava che il <strong>payload PK-signed KEK non era disponibile per il modello OEM specifico<\/strong>. <cite>Event 1803 indica che l&#8217;update KEK non pu\u00f2 essere autorizzato perch\u00e9 un payload KEK richiesto e firmato da OEM non \u00e8 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&#8217;OEM ha fornito a Microsoft il payload KEK firmato richiesto per il modello device.<\/cite><\/p>\n<h2>Step 2: Verificare lo Stato UEFI Variables Direttamente<\/h2>\n<p>Non mi fido solo del registro Windows. Entro in modalit\u00e0 <strong>Recovery per accedere direttamente alle variabili UEFI<\/strong>.<\/p>\n<p>Su Windows 11, il percorso \u00e8:<\/p>\n<ol>\n<li><strong>Settings<\/strong> \u2192 <strong>System<\/strong> \u2192 <strong>Recovery<\/strong><\/li>\n<li>Sotto <strong>Advanced startup<\/strong>, cliccare <strong>Restart now<\/strong><\/li>\n<li>Nel menu WinRE che appare, selezionare <strong>Troubleshoot<\/strong> \u2192 <strong>Advanced options<\/strong> \u2192 <strong>UEFI Firmware Settings<\/strong> \u2192 <strong>Restart<\/strong><\/li>\n<\/ol>\n<p>Una volta nel UEFI:<\/p>\n<ol>\n<li>Navigo alla sezione <strong>Security<\/strong> o <strong>Boot<\/strong> (varia per vendor)<\/li>\n<li>Cerco le opzioni <strong>Secure Boot Database Management<\/strong> o <strong>Key Management<\/strong><\/li>\n<li>Controllo se <strong>&#8220;Active Secure Boot Database&#8221;<\/strong> contiene gi\u00e0 le certificazioni 2023<\/li>\n<li>Verifico il valore di <strong>&#8220;Vendor Keys&#8221;<\/strong>: deve essere 1 se le chiavi sono ancora originali, 0 se modificate<\/li>\n<\/ol>\n<p><cite>La differenza tra Active e Default Secure Boot Database \u00e8 che Active \u00e8 quello che il computer usa al startup per verificare il software trusted, mentre Default \u00e8 un set di backup delle chiavi originali che pu\u00f2 essere ripristinato se necessario; in sintesi: Active \u00e8 attualmente enforced (comunemente aggiornato da Windows Update) e Default \u00e8 la versione factory reset non usata a meno che non ripristinata (aggiornato usando un BIOS update).<\/cite><\/p>\n<h2>Step 3: Firmware Vendor-Specific Checks<\/h2>\n<p>Qui inizia la parte difficile. Ogni vendor (Dell, HP, Lenovo, ASUS) ha una UI e un comportamento <strong>completamente diverso<\/strong>. Ho dovuto creare un foglio di riferimento per ogni vendor.<\/p>\n<h3>Dell Systems<\/h3>\n<p>Su Dell:<\/p>\n<ol>\n<li>Entro BIOS con <strong>F2<\/strong> durante il boot<\/li>\n<li>Navigo a <strong>System Security<\/strong> \u2192 <strong>Secure Boot<\/strong><\/li>\n<li>Cerco l&#8217;opzione <strong>&#8220;Reset to Setup Mode&#8221;<\/strong> o <strong>&#8220;Load Factory Keys&#8221;<\/strong><\/li>\n<li>Se vedo <strong>&#8220;Expert Key Mode&#8221;<\/strong> attivato, DEVO disattivarlo prima di procedere<\/li>\n<\/ol>\n<p><cite>A volte, disabilitare Secure Boot pu\u00f2 cancellare tutte le variabili UEFI attive, il che significa che i 2023 CAs gi\u00e0 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\u00f2 avviene se l&#8217;utente seleziona l&#8217;opzione Expert Key Mode nel menu BIOS; in questo caso le variabili attive vengono prese dal firmware di default.<\/cite><\/p>\n<h3>HP Systems<\/h3>\n<p>Su HP (spesso i pi\u00f9 problematici):<\/p>\n<ol>\n<li>Entro BIOS con <strong>Esc<\/strong> durante il boot<\/li>\n<li>Cerco <strong>Security<\/strong> \u2192 <strong>Secure Boot<\/strong><\/li>\n<li>Cerco l&#8217;opzione <strong>&#8220;Restore Secure Boot to Factory Defaults&#8221;<\/strong><\/li>\n<li><strong>Verifico la versione EFI System Partition<\/strong>: se \u00e8 segnalata come ~100MB, \u00e8 un candidato ad high-risk<\/li>\n<\/ol>\n<p>Nel mio caso, due HP EliteBook 840 G10 fallirono perch\u00e9 <cite>alcuni sistemi interessati hanno apparentemente partizioni EFI pi\u00f9 vecchie da 100MB piuttosto che layout pi\u00f9 grandi da 500MB o 1GB, e se quella partizione \u00e8 gi\u00e0 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.<\/cite><\/p>\n<h3>Lenovo\/ThinkPad Systems<\/h3>\n<p>Su Lenovo:<\/p>\n<ol>\n<li>Entro BIOS con <strong>F1<\/strong> (o <strong>Fn+F1<\/strong> su alcuni modelli) durante il boot<\/li>\n<li>Navigo a <strong>Security<\/strong> \u2192 <strong>Secure Boot<\/strong><\/li>\n<li>Cerco <strong>&#8220;Restore Factory Keys&#8221;<\/strong><\/li>\n<li>Se c&#8217;\u00e8 un&#8217;opzione <strong>&#8220;Secure Boot Mode&#8221;<\/strong>, assicurati che sia in <strong>Standard<\/strong>, non Custom<\/li>\n<\/ol>\n<h2>Step 4: Recovery Mode Sequence Completa<\/h2>\n<p>Quando un sistema \u00e8 bloccato in boot failure dopo un tentativo di update Secure Boot, la mia sequenza di recovery \u00e8:<\/p>\n<h3>Fase 1: Boot da Recovery Media<\/h3>\n<p>Se il sistema non bootaa, accendo con USB Windows Recovery (creato con <em>bootrec \/scanos<\/em> o tool Microsoft ufficiali).<\/p>\n<pre><code># Dal WinRE command prompt (con diritti admin):\n# Verificare che il bootloader sia firmato correttamente\nbcdedit \/enum all\n<\/code><\/pre>\n<h3>Fase 2: Reset Secure Boot a Factory Defaults (CAUTELA!)<\/h3>\n<p>Da UEFI Recovery Menu:<\/p>\n<ol>\n<li>Scelgo <strong>&#8220;Reset to Setup Mode&#8221;<\/strong> o <strong>&#8220;Clear Secure Boot Database&#8221;<\/strong><\/li>\n<li>Il sistema ora bootaa (perch\u00e9 non valida alcuna firma)<\/li>\n<li>Una volta in Windows, do al Secure Boot-Update task il tempo di rieseguire (pu\u00f2 occorrere 2-3 reboot)<\/li>\n<\/ol>\n<p><cite>Resettare Secure Boot ai firmware defaults cancella i Secure Boot database memorizzati nel firmware. Sui device che hanno gi\u00e0 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\u00f9 il boot manager Windows installato come trusted e blocca il processo di boot.<\/cite><\/p>\n<h3>Fase 3: Attendere e Verificare AvailableUpdates<\/h3>\n<p>Dopo il reset, eseguo PowerShell periodicamente:<\/p>\n<pre><code># Controllare il valore AvailableUpdates ogni 30 secondi\nwhile ($true) {\n    Write-Host \"[$(Get-Date -Format 'HH:mm:ss')] Checking AvailableUpdates...\"\n    $available = (Get-ItemProperty \"HKLM:SYSTEMCurrentControlSetControlSecureBootState\").AvailableUpdates\n    Write-Host \"AvailableUpdates: 0x$('{0:X4}' -f $available)\"\n    \n    if ($available -eq 0) {\n        Write-Host \"[SUCCESS] Update completato!\"\n        break\n    }\n    Start-Sleep -Seconds 30\n}\n<\/code><\/pre>\n<p><cite>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.<\/cite><\/p>\n<h2>Step 5: Diagnostica dei Fallimenti Specifici di Event ID<\/h2>\n<p>Ho creato una matrice di decision nel mio playbook:<\/p>\n<h3>Event ID 1795 (Firmware Error)<\/h3>\n<p><strong>Significato:<\/strong> Firmware ha restituito un errore durante l&#8217;update della variabile Secure Boot.<\/p>\n<p><strong>Azioni:<\/strong><\/p>\n<ol>\n<li>Verificare la versione BIOS\/UEFI del device: spesso i vendor hanno fix specifici<\/li>\n<li>Contattare il supporto OEM con il codice errore esatto<\/li>\n<li>Se disponibile, aggiornare il BIOS all&#8217;ultima versione stable<\/li>\n<\/ol>\n<h3>Event ID 1803 (Missing OEM Payload)<\/h3>\n<p><strong>Significato:<\/strong> Il certificato KEK 2023 richiesto, firmato dall&#8217;OEM, non \u00e8 stato fornito a Microsoft.<\/p>\n<p><strong>Azioni:<\/strong><\/p>\n<ol>\n<li>Questo \u00e8 un problema a livello OEM \u2013 non posso risolverlo io<\/li>\n<li>Verificare il Dell\/HP\/Lenovo security bulletin per il mio modello specifico<\/li>\n<li>Se il device \u00e8 fuori supporto, potrebbe non ricevere mai un fix<\/li>\n<\/ol>\n<h3>Event ID 1808 (Success)<\/h3>\n<p><strong>Significato:<\/strong> Update completato con successo.<\/p>\n<h2>Step 6: Enterprise Monitoring e Remediation at Scale<\/h2>\n<p>Per monitorare 150+ sistemi, ho creato uno script di remediation Intune che verifica lo stato di ogni device:<\/p>\n<pre><code># Script di detection (PowerShell) per Intune Remediations\n$regPath = \"HKLM:SYSTEMCurrentControlSetControlSecureBootState\"\n$status = Get-ItemProperty $regPath -ErrorAction SilentlyContinue\n\nif ($null -eq $status) {\n    Write-Host \"FAIL: Secure Boot not supported\"\n    exit 1\n}\n\n$uefica2023Status = $status.UEFICA2023Status\n$availableUpdates = $status.AvailableUpdates\n\nif ($uefica2023Status -eq 2 -and $availableUpdates -eq 0) {\n    Write-Host \"SUCCESS: 2023 certificates installed and no pending updates\"\n    exit 0\n} else {\n    Write-Host \"FAIL: Status=$uefica2023Status, AvailableUpdates=0x$([Convert]::ToString($availableUpdates, 16))\"\n    exit 1\n}\n<\/code><\/pre>\n<p>Questo script mi dice quali device richiedono intervention manuale. Poi creo gruppi Intune per tier di remediation:<\/p>\n<ul>\n<li><strong>Ring 0 (Test)<\/strong>: 5 device di ogni modello hardware<\/li>\n<li><strong>Ring 1 (Stager)<\/strong>: 20% della flotta, dopo 1 settimana<\/li>\n<li><strong>Ring 2 (Main)<\/strong>: Resto della flotta<\/li>\n<\/ul>\n<h2>FAQ<\/h2>\n<h3>Se disabilito Secure Boot, i sistemi bootano normalmente?<\/h3>\n<p>S\u00ec, ma non \u00e8 una soluzione. <cite>Secure Boot non smetter\u00e0 di funzionare nel 2026; il boot continuer\u00e0, ma ci\u00f2 che si degrada \u00e8 la futura capacit\u00e0 di aggiornamento della sicurezza del boot. La maggior parte dei sistemi continuer\u00e0 a bootare, ma i device che non eseguono la transizione dagli ancoraggi di fiducia 2011 ai 2023 potranno perdere la capacit\u00e0 di ricevere aggiornamenti futuri che si basano sulla fiducia del boot rinfrescata.<\/cite> \u00c8 una regressione di sicurezza a breve termine per evitare un problema a lungo termine.<\/p>\n<h3>Quanto tempo impiega il Secure-Boot-Update task a completarsi?<\/h3>\n<p>In genere 5-15 minuti, ma dipende dal firmware. Alcuni sistemi richiedono pi\u00f9 reboot per commitment dei cambiamenti firmware. Nel mio caso, ho visto fino a 45 minuti su VM Hyper-V con firmware virtualizzato.<\/p>\n<h3>Posso forzare l&#8217;update da linea di comando?<\/h3>\n<p>Tecnicamente posso impostare registry flags, ma \u00e8 rischioso. Preferisco usare Intune Remediations o Microsoft&#8217;s official deployment tools. Se devo forzare manualmente:<\/p>\n<pre><code>powershell -Command \"Set-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlSecureBootState' -Name 'AvailableUpdates' -Value 0x5944\"\n<\/code><\/pre>\n<p>Poi riavvio e monitoro i log di evento.<\/p>\n<h3>Se un device rimane in Update indefinitamente?<\/h3>\n<p>Controllo prima Event ID 1795\/1803, poi cerco firmware fixes dal vendor. Se il device \u00e8 fuori supporto (&gt;5 anni), considero il replacement come opzione pi\u00f9 pragmatica.<\/p>\n<h3>Le Hyper-V VM richiedono passaggi diversi?<\/h3>\n<p><cite>Sulle virtual machine Hyper-V, gli update Secure Boot certificate richiedono gli update Windows di marzo 2026 o successivi installati sia sull&#8217;host Hyper-V che sul guest OS.<\/cite> Ho dovuto coordinare upgrade sia dell&#8217;host che dei guest nella mia infrastruttura.<\/p>\n<h2>Conclusione<\/h2>\n<p>Diagnosticare fallimenti <strong>Secure Boot Update Firmware<\/strong> in ambienti enterprise \u00e8 un&#8217;attivit\u00e0 che richiede approccio metodico: <strong>registry check<\/strong> \u2192 <strong>event log correlation<\/strong> \u2192 <strong>vendor-specific UEFI inspection<\/strong> \u2192 <strong>recovery sequence<\/strong>. La chiave \u00e8 <strong>non forzare il reboot<\/strong> fino a quando l&#8217;update non progredisce naturalmente attraverso il Secure-Boot-Update task.<\/p>\n<p>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.<\/p>\n<p>Se gestite una flotta Windows enterprise, cominciate oggi a testare questa procedura su un Ring 0 piccolo. Il giugno 2026 \u00e8 passato, ma <strong>la transizione continua fino a ottobre 2026<\/strong>, e i dispositivi che rimangono su certificazioni 2011 diventeranno progressivamente meno sicuri.<\/p>\n<p>Domande sulla vostra specifici setup di produzione? Lasciate un commento qui sotto \u2013 vi aiuter\u00f2 a diagnosticare i vostri fallimenti Secure Boot!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Diagnostica step-by-step per fallimenti Secure Boot firmware update: registry checks, UEFI variables verification, vendor-specific BIOS procedures e recovery sequences per flotte enterprise in produzione.<\/p>\n","protected":false},"author":1,"featured_media":2630,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Diagnosticare Secure Boot Fallimenti: UEFI Recovery | Dario Iannascoli","_seopress_titles_desc":"Guida completa diagnostica Secure Boot Update firmware: Event ID 1795\/1803, UEFI variables, recovery mode sequence vendor-specific per enterprise Windows 2026.","_seopress_robots_index":"","footnotes":""},"categories":[5],"tags":[1009,1008,361,124,470,1007],"class_list":["post-2629","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-bios-troubleshooting","tag-firmware-update","tag-secure-boot","tag-system-administration","tag-uefi","tag-windows-enterprise"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2629","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2629"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2629\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2630"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}