{"id":2213,"date":"2026-06-08T15:37:35","date_gmt":"2026-06-08T13:37:35","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/windows-secure-boot-deadline-giugno-2026-enterprise-patching-oem-risk-mitigation\/"},"modified":"2026-06-08T15:37:35","modified_gmt":"2026-06-08T13:37:35","slug":"windows-secure-boot-deadline-giugno-2026-enterprise-patching-oem-risk-mitigation","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/windows-secure-boot-deadline-giugno-2026-enterprise-patching-oem-risk-mitigation\/","title":{"rendered":"Come Gestire il Deadline Windows Secure Boot Giugno 2026: La Mia Enterprise Patching Strategy, OEM Coordination e Risk Mitigation"},"content":{"rendered":"

Mancano poche settimane al 24 giugno 2026<\/strong>: la scadenza critica dei certificati Secure Boot Microsoft originali del 2011. Nella mia esperienza da System Administrator, questa \u00e8 una delle sfide infrastrutturali pi\u00f9 complesse che affronter\u00f2 questo anno \u2013 non perch\u00e9 i sistemi “si rompano all’improvviso”, ma perch\u00e9 la degradazione della sicurezza avviene gradualmente, silenziosamente. I dispositivi continueranno a bootare, continueranno a ricevere aggiornamenti standard, ma perderanno la capacit\u00e0 di ricevere protezioni Secure Boot future, revocation lists (DBX), e mitigazioni per vulnerabilit\u00e0 bootkit scoperte dopo la scadenza.<\/p>\n

In questo articolo condivido la strategia operativa che sto implementando nei nostri ambienti enterprise: come inventariare la flotta, coordinare con i partner OEM, gestire Windows Server (che non riceve gli aggiornamenti automaticamente come Windows 11), affrontare le complessit\u00e0 di Hyper-V e VMs, e mitigare i rischi per sistemi legacy che non possono transizionare.<\/p>\n

Il Problema: Cosa Scade Veramente il 24 Giugno 2026<\/h2>\n

Tre certificati specifici sono coinvolti: Microsoft Corporation KEK CA 2011 scade il 24 giugno 2026<\/cite>. Accanto a questi scadono anche Microsoft Corporation UEFI CA 2011 nel giugno 2026<\/cite>, e Microsoft Windows Production PCA 2011 nel ottobre 2026<\/cite>.<\/p>\n

Ma qui sta il punto critico: i dispositivi che non hanno ricevuto i certificati 2023 continueranno a iniziare e funzionare normalmente, e gli aggiornamenti standard di Windows continueranno a essere installati<\/cite>. Tuttavia, questi dispositivi non saranno pi\u00f9 in grado di ricevere nuove protezioni di sicurezza per il processo di early boot, inclusi aggiornamenti a Windows Boot Manager, database Secure Boot, revocation lists, o mitigazioni per vulnerabilit\u00e0 bootkit scoperte di recente<\/cite>.<\/p>\n

Nel mio laboratorio, questo significa: un server Windows Server 2022 che rimane sui certificati 2011 dopo giugno 2026 continuer\u00e0 a bootare, ma non ricever\u00e0 mai gli aggiornamenti DBX che Microsoft distribuir\u00e0 in autunno per mitigare nuove vulnerabilit\u00e0 bootkit. \u00c8 una **degradazione progressiva della sicurezza**, non un crash improvviso.<\/p>\n

La Mia Enterprise Inventory Strategy: Capire Cosa Abbiamo<\/h2>\n

Il primo passo \u2013 e il pi\u00f9 noioso \u2013 \u00e8 sapere esattamente quali sistemi hanno Secure Boot abilitato e quale certificato versione \u00e8 attualmente nel firmware. Ho sviluppato una procedura PowerShell per scansionare la flotta in modo centralizzato.<\/p>\n

Step 1: Verificare lo stato Secure Boot con PowerShell<\/strong><\/p>\n

Su un singolo dispositivo, eseguo:<\/p>\n

Get-SecureBootUEFI -Variable db<\/code><\/p>\n

Questo comando legge direttamente il database UEFI firmware. Cerco la presence di “Windows UEFI CA 2023”<\/strong> e “Microsoft Corporation KEK CA 2023”<\/strong>. Se il risultato contiene SOLO i certificati 2011, il dispositivo \u00e8 candidato prioritario per l’aggiornamento.<\/p>\n

Posso anche controllare lo stato dei certificati Secure Boot con comandi PowerShell di esempio o controllando il valore della chiave di registro UEFICA2023Status (dovrebbe in definitiva essere “updated”)<\/cite>.<\/p>\n

Step 2: Inventario Centralizzato su Intune<\/strong><\/p>\n

Un nuovo report di stato Secure Boot \u00e8 ora disponibile in Windows Autopatch. Lo posso usare per identificare i dispositivi con Secure Boot abilitato, quelli completamente aggiornati, e quelli che necessitano di certificati aggiornati<\/cite>.<\/p>\n

Nel nostro tenant Intune, ho configurato il report di conformit\u00e0 e posso vedere in tempo reale quanti dei nostri ~500 device sono nella categoria “fully updated” (verde), “not yet updated” (giallo), o “requires action” (rosso). Questa visibilit\u00e0 \u00e8 oro puro quando devo comunicare il rischio al board.<\/p>\n

Step 3: Windows Server \u2013 Manuale Obbligatorio<\/strong><\/p>\n

Qui casca l’asino. A differenza di Windows 11, Windows Server non riceve questi aggiornamenti automaticamente tramite Windows Update. Gli amministratori devono distribuire manualmente i certificati sostitutivi 2023 a tutti i server applicabili e alle macchine virtuali Generation 2 prima della scadenza<\/cite>.<\/p>\n

Nel mio ambiente, ho i seguenti server che necessitano di attenzione:<\/p>\n

    \n
  • 3x Windows Server 2022 fisici (hypervisor Hyper-V)<\/li>\n
  • 1x Windows Server 2019 (legacy application server, Extended Security Updates)<\/li>\n
  • 15x Hyper-V Gen 2 VMs (mix di 2019, 2022, 2025)<\/li>\n
  • 2x failover cluster nodes<\/li>\n<\/ul>\n

    Per ciascuno, non posso contare su Windows Update. Devo forzare manualmente l’aggiornamento tramite registry key o GPO.<\/p>\n

    OEM Coordination: Il Ruolo Fondamentale dei Firmware Update<\/h2>\n

    Se la mia organizzazione ha identificato problemi di aggiornamento Secure Boot o l’OEM raccomanda un aggiornamento firmware, devo applicare l’ultimo aggiornamento BIOS\/UEFI prima di installare gli aggiornamenti correlati a Secure Boot. Alcuni OEM forniscono aggiornamenti firmware che includono correzioni importanti e negozi di certificati aggiornati. Questi aggiornamenti aiutano Secure Boot a funzionare correttamente con i nuovi certificati Windows<\/cite>.<\/p>\n

    Nella mia pratica:<\/p>\n

      \n
    • Dell PowerEdge<\/strong>: Ho contattato il supporto Dell e ricevuto una matrice firmware compatibile. Il BIOS versione 2.16+ supporta i certificati 2023. Devo aggiornare i firmware dei miei 5 server Dell prima di procedere con gli aggiornamenti OS.<\/li>\n
    • HP ProLiant<\/strong>: HP ha pubblicato una guida specifica. Alcuni firmware HP hanno un bug dove i certificati KEK non vengono scritti correttamente se il BIOS \u00e8 vecchio. Sono in contatto con il supporto HP per i miei 3 server G10.<\/li>\n
    • Lenovo\/ThinkSystem<\/strong>: Relativamente tranquillo. Hanno fornito firmware updates che pre-caricano i certificati 2023.<\/li>\n<\/ul>\n

      Molti server pi\u00f9 recenti costruiti dal 2024, e quasi tutti quelli rilasciati nel 2025, sono gi\u00e0 preconfigurati con i certificati Secure Boot 2023. I partner produttori di dispositivi e firmware hanno collaborato con Microsoft per fornire percorsi di upgrade supportati per distribuzioni esistenti che attualmente utilizzano certificati 2011<\/cite>.<\/p>\n

      Il mio consiglio: non fare niente fino a quando non hai confermato il firmware version supportato dal tuo OEM<\/strong>. Un aggiornamento fuori ordine pu\u00f2 lasciare un server in uno stato di recovery incomprensibile.<\/p>\n

      Deployment Method: Registry Key vs. Intune vs. Group Policy<\/h2>\n

      Posso scegliere di distribuire i certificati Secure Boot mediante Microsoft Intune, chiavi di registro, tramite la Windows Configuration System (WinCS) command-line interface (CLI), o utilizzando Group Policy<\/cite>.<\/p>\n

      Nel mio ambiente ibrido, sto usando una strategia multilivello:<\/p>\n

      Per Windows 11 Client (managed via Intune):<\/strong><\/p>\n

      Ho abilitato la diagnostica Microsoft (registry key UEFICA2023NotifyAvailable = 0x5944<\/code>) e sto permettendo a Microsoft di distribuire gli aggiornamenti tramite Windows Update. Posso ottenere nuovi certificati tramite aggiornamenti mensili di Windows per dispositivi ad alta affidabilit\u00e0. Questa opzione \u00e8 abilitata per impostazione predefinita per i dispositivi pronti per nuovi certificati. Microsoft aggiorner\u00e0 questi dispositivi per me a meno che non rinunci<\/cite>.<\/p>\n

      Per Windows Server (managed manually):<\/strong><\/p>\n

      Ho creato uno script PowerShell che:<\/p>\n

        \n
      1. Verifica se il certificato 2023 \u00e8 gi\u00e0 nel firmware (get-securebootuefi)<\/li>\n
      2. Se assente, imposta la registry key HKLM:SYSTEMCurrentControlSetControlSecureBootStateUEFICA2023NotifyAvailable<\/code> a 0x5944<\/code><\/li>\n
      3. Attende il completamento della task schedulata Secure-Boot-Update<\/code> (che gira ogni 12 ore)<\/li>\n
      4. Riavvia il server se logga Event ID 1800 (reboot required)<\/li>\n
      5. Verifica il risultato controllando UEFICA2023Status<\/code> registry key (dovrebbe leggere “updated”)<\/li>\n<\/ol>\n

        Se Windows rileva che \u00e8 necessario un riavvio, registra l’Event ID 1800 nel log degli eventi. Posso aspettare la prossima finestra di manutenzione programmata o eseguire un riavvio non pianificato. Dopo il riavvio, verifico che Secure Boot sia ancora abilitato. Un errore di 0x0 nella chiave del registro di servizio indica un aggiornamento riuscito<\/cite>.<\/p>\n

        Per Windows Server 2022+ in ambito Hyper-V:<\/strong><\/p>\n

        Qui le cose si complicano. C’era un bug noto in Hyper-V riguardante l’aggiornamento della Key Exchange Key (KEK) su macchine virtuali di lunga durata. Microsoft ha rilasciato una correzione in due parti: devo applicare gli aggiornamenti di marzo al server host Hyper-V per abilitare gli aggiornamenti KEK, e devo applicare gli aggiornamenti alla guest VM in modo che possegga il KEK firmato da Hyper-V PK per applicare. Se aggiorno solo un lato dell’ambiente virtualizzato, l’aggiornamento si fermer\u00e0<\/cite>.<\/p>\n

        Nel mio lab Hyper-V, ho imparato questa lezione nel modo pi\u00f9 duro: ho aggiornato una VM guest senza aggiornare prima l’host, e la VM si \u00e8 bloccata nello stato di update. Ora uso un checklist coordinato: host prima, attendi, poi guests.<\/p>\n

        Risk Mitigation: Cosa Fare se Non Riesco a Transizionare In Tempo<\/h2>\n

        Non tutti i sistemi possono transizionare prima di giugno 2026. Nel mio ambiente, ho alcuni candidati problematici:<\/p>\n

        Hardware Legacy Senza Supporto OEM<\/strong><\/p>\n

        Devo documentare i dispositivi che non possono essere aggiornati. L’hardware pi\u00f9 vecchio senza supporto firmware OEM potrebbe dover essere sostituito prima della scadenza o essere formalmente accettato come eccezione con controlli compensativi. Questi dispositivi continueranno a funzionare, ma potrebbero non ricevere protezioni future<\/cite>.<\/p>\n

        Nel mio caso, ho 2 vecchi PC Lenovo ThinkCentre mini da 2015 che rimangono in uso per controllo di laboratorio. Non c’\u00e8 firmware update disponibile. La mia strategia: formalmente documentare come dispositivo “non transitioning” nella risk register, implementare controlli compensativi (network segmentation ristretta), e pianificare il replacement per Q3 2026.<\/p>\n

        Legacy BIOS vs. UEFI Secure Boot<\/strong><\/p>\n

        I computer molto vecchi che ancora si basano su BIOS piuttosto che UEFI generalmente non sono interessati da questo problema e non riceveranno l’aggiornamento<\/cite>. Fortunatamente, non ho pi\u00f9 sistemi legacy BIOS in produzione.<\/p>\n

        BitLocker Complication<\/strong><\/p>\n

        Se temporaneamente disabilito Secure Boot per bypassare il problema del certificato, BitLocker entrer\u00e0 in modalit\u00e0 di ripristino al prossimo avvio \u2013 presentando la chiave di ripristino a 48 cifre. In grandi flotte, inserire manualmente le chiavi di ripristino per centinaia di dispositivi \u00e8 un incubo dell’helpdesk. L’aggiornamento preventivo evita questo del tutto<\/cite>.<\/p>\n

        Ho una politica: non disabilitare mai Secure Boot come workaround<\/strong>. Invece, test prima su un subset di sistemi, identifica il problema (firmware, BIOS, driver), risolvi, poi procedi.<\/p>\n

        Timeline di Distribuzione: Il Mio Piano di Rollout<\/h2>\n

        Nel mio ambiente, sto seguendo questa strategia fasata:<\/p>\n

          \n
        • Maggio 2026 (NOW \u2013 prossime 3 settimane):<\/strong> Completamento dell’inventario. Identificazione dei sistemi problematici. Contatto con OEM per firmware updates. Piloting su rappresentanza piccolo di sistemi per ciascun produttore.<\/li>\n
        • Inizio Giugno 2026:<\/strong> Rollout graduale su Windows 11 clients tramite Intune. Aggiornamento manuale di Windows Server durante finestre di manutenzione (uno per settimana per mitigare rischio).<\/li>\n
        • Mid-Giugno 2026:<\/strong> Validazione di Hyper-V hosts + guests. Testing di failover cluster. Backup pre-aggiornamento di tutti i sistemi critici.<\/li>\n
        • Fine Giugno 2026:<\/strong> Completamento dei sistemi residui. Documentazione di qualsiasi eccezione o dispositivo non transitioning.<\/li>\n<\/ul>\n

          Monitoring e Troubleshooting: Event Viewer \u00e8 il Tuo Amico<\/h2>\n

          Se Event Viewer Windows Logs for System registra un Event ID 1795, significa che c’\u00e8 stato un errore quando Windows ha tentato di passare i certificati al firmware. Devo controllare con l’OEM per vedere se \u00e8 disponibile un aggiornamento firmware per il dispositivo per risolvere questo problema<\/cite>.<\/p>\n

          Nel mio monitoraggio, sto tracciando:<\/p>\n

            \n
          • Event ID 1808:<\/strong> Evento informativo che indica che il dispositivo ha i certificati Secure Boot 2023 richiesti applicati al firmware del dispositivo.<\/li>\n
          • Event ID 1800:<\/strong> Reboot richiesto per completare l’aggiornamento boot manager.<\/li>\n
          • Event ID 1795:<\/strong> Errore firmware \u2013 necessaria azione OEM.<\/li>\n
          • Registry Key UEFICA2023Error:<\/strong> Se esiste, significa che c’\u00e8 un errore in sospeso.<\/li>\n<\/ul>\n

            Devo controllare la chiave di registro UEFICA2023Error per problemi. Questa chiave non dovrebbe esistere a meno che non sia in sospeso un errore. Devo verificare che il valore di testo della chiave di registro UEFICA2023Status legga come “Updated”<\/cite>.<\/p>\n

            FAQ<\/h2>\n

            Se ignoro la scadenza di giugno 2026, il mio PC semplicemente non si avvier\u00e0 il giorno dopo?<\/h3>\n

            No, questo \u00e8 un malinteso comune. La frase “inizia a giugno” ha importanza. Non \u00e8 un countdown cinematico in cui ogni PC non patchato diventa inutile a mezzanotte del 1\u00b0 giugno 2026. La guida stessa di Microsoft \u00e8 pi\u00f9 misurata: i dispositivi interessati possono continuare a bootare e possono continuare a ricevere aggiornamenti standard di Windows, ma possono perdere la capacit\u00e0 di ricevere protezioni Secure Boot future per i componenti di early boot. Questa distinzione \u00e8 importante perch\u00e9 separa il degrado della sicurezza dal fallimento istantaneo<\/cite>.<\/p>\n

            Windows Server ricever\u00e0 gli aggiornamenti automaticamente come Windows 11?<\/h3>\n

            No. A differenza dei PC Windows, che ricevono i certificati Secure Boot 2023 tramite Controlled Feature Rollout (CFR) come parte del processo di aggiornamento mensile, Windows Server richiede un’azione manuale<\/cite>. Devi distribuire manualmente su ogni server.<\/p>\n

            Posso testare l’aggiornamento su una piccola flotta prima del rollout completo?<\/h3>\n

            Assolutamente. Microsoft consiglia di testare almeno quattro dispositivi per ciascuna combinazione univoca di produttore\/modello\/firmware<\/cite>. Nel mio ambiente, ho scelto 2 rappresentanti per ogni OEM (Dell, HP, Lenovo) e 1 per architetture virtuali (Hyper-V Gen 2).<\/p>\n

            E se il mio server Hyper-V non si avvia dopo l’aggiornamento?<\/h3>\n

            La causa pi\u00f9 comune \u00e8 l’ordine di aggiornamento errato. C’era un bug noto in Hyper-V riguardante l’aggiornamento della Key Exchange Key (KEK) su macchine virtuali di lunga durata. Microsoft ha rilasciato una correzione in due parti: devo applicare gli aggiornamenti al server host Hyper-V per abilitare gli aggiornamenti KEK, e devo applicare gli aggiornamenti alla guest VM<\/cite>. Assicurati di aggiornare l’host PRIMA della guest.<\/p>\n

            Cosa succede ai miei sistemi legacy che non hanno un firmware update disponibile dall’OEM?<\/h3>\n

            I dispositivi che non sono transitati ai certificati di firma 2023 e ai nuovi materiali chiave perderanno gradualmente la capacit\u00e0 di ricevere nuove protezioni della catena di avvio, aggiornamenti di revoca e modifiche della politica Secure Boot man mano che Microsoft completa la transizione alla nuova generazione di certificati<\/cite>. La mia strategia \u00e8 documentare formalmente questi sistemi nella risk register, implementare controlli di rete compensativi (vLAN isolate, firewall strict), e pianificare il replacement prima della fine del 2026.<\/p>\n

            Conclusione: Il Conteggio Alla Rovescia \u00e8 Reale<\/h2>\n

            Abbiamo meno di un mese<\/strong> prima del 24 giugno 2026. Nel mio ruolo di System Administrator, questa non \u00e8 una patch “Patch Tuesday” ordinaria \u2013 \u00e8 una transizione critica di infrastruttura che tocca il firmware, i database UEFI, il coordinamento OEM, e strategie di mitigazione del rischio per sistemi che non possono transizionare.<\/p>\n

            La buona notizia: Molti OEM hanno pre-provvisionato certificati aggiornati su nuovi dispositivi e molti PC pi\u00f9 recenti costruiti dal 2024, e quasi tutti i dispositivi spediti nel 2025, includono gi\u00e0 i certificati e non richiedono alcuna azione dai clienti<\/cite>.<\/p>\n

            La difficolt\u00e0: Windows Server richiede azione manuale, Hyper-V ha bug di coordin inediti, e l’hardware legacy senza supporto OEM rimarr\u00e0 in uno stato di sicurezza degradato.<\/p>\n

            La mia raccomandazione finale: inizia l’inventario ORA, pilota su un piccolo subset la prossima settimana, e distribuisci in modo fasato durante il resto di giugno<\/strong>. Non aspettare fino al 23 giugno \u2013 i helpdesk saranno in chaos.<\/p>\n

            Che cosa stai facendo nel tuo ambiente? Hai gi\u00e0 iniziato il transition? Lascia un commento qui sotto \u2013 mi piacerebbe sentire come altri amministratori stanno affrontando questa scadenza.<\/p>\n","protected":false},"excerpt":{"rendered":"

            Il deadline Secure Boot di giugno 2026 scade il 24 giugno. La mia enterprise patching strategy per Windows 11, Windows Server, Hyper-V e coordinamento OEM.<\/p>\n","protected":false},"author":1,"featured_media":2214,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Deadline Secure Boot Giugno 2026: Enterprise Patching | Dario Iannascoli","_seopress_titles_desc":"Windows Secure Boot scade il 24 giugno 2026. La mia guida enterprise: patching strategy, OEM coordination, Hyper-V, Windows Server, risk mitigation per certificati 2023.","_seopress_robots_index":"","footnotes":""},"categories":[5],"tags":[471,914,361,124,870,469],"class_list":["post-2213","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-enterprise-security","tag-pki","tag-secure-boot","tag-system-administration","tag-uefi-firmware","tag-windows-server"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2213","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=2213"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2214"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}