{"id":2074,"date":"2026-05-26T15:07:42","date_gmt":"2026-05-26T13:07:42","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/windows-server-secure-boot-certificate-giugno-2026-patching-oem-mitigation\/"},"modified":"2026-05-26T15:07:42","modified_gmt":"2026-05-26T13:07:42","slug":"windows-server-secure-boot-certificate-giugno-2026-patching-oem-mitigation","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/windows-server-secure-boot-certificate-giugno-2026-patching-oem-mitigation\/","title":{"rendered":"Windows Server Secure Boot Certificate Expiration Giugno 2026: Enterprise Patching Strategy, OEM Coordination e Risk Mitigation \u2013 Countdown 45 Giorni"},"content":{"rendered":"

A meno di 45 giorni dall’evento critico di giugno 2026, gli amministratori IT devono affrontare una delle sfide di patching pi\u00f9 significative del decennio: l’espiration dei certificati Secure Boot originali del 2011<\/strong>. Nella mia esperienza con infrastrutture enterprise, questa non \u00e8 una semplice patch routine \u2013 \u00e8 una transizione di fiducia a livello firmware che richiede coordinamento con i produttori OEM, validazione hardware e una strategia di deployment multi-fase ben pianificata. Vi mostro come implementare una procedura di enterprise patching strategy che riduce al minimo il rischio operativo.<\/p>\n

Il problema \u00e8 semplice da enunciare, complesso da risolvere: i certificati Secure Boot originali introdotti nel 2011 stanno raggiungendo la fine del loro ciclo di vita pianificato, con scadenze che iniziano a fine giugno 2026<\/cite>. Ma il vero impatto non \u00e8 il bricking istantaneo \u2013 \u00e8 la degradazione progressiva della sicurezza del boot<\/strong> per i sistemi che non ricevono i certificati 2023.<\/p>\n

Perch\u00e9 i Certificati Scadenti Sono Critici per Windows Server<\/h2>\n

Come System Administrator, il primo errore che voglio evitare \u00e8 minimizzare questa situazione. I dispositivi senza i nuovi certificati 2023 non potranno ricevere nuove protezioni di sicurezza per il processo di boot iniziale, inclusi aggiornamenti a Windows Boot Manager, database Secure Boot, elenchi di revoca o mitigazioni per vulnerabilit\u00e0 di boot appena scoperte<\/cite>. Non \u00e8 un crash istantaneo \u2013 \u00e8 una lenta perdita di protezione.<\/p>\n

Nel mio lab, ho visto server Windows Server 2019 e 2022 che continuano a funzionare normalmente, ma senza la capacit\u00e0 di ricevere correzioni di sicurezza a livello firmware. Questo \u00e8 particolarmente critico per le organizzazioni che implementano BitLocker<\/strong>, Measured Boot<\/strong> o third-party bootloaders personalizzati<\/strong>. L’attacco BlackLotus (CVE-2023-24932) ha dimostrato come il boot path sia diventato un vettore di attacco preferito dai malware sofisticati.<\/p>\n

La Differenza Critica: Windows Client vs Windows Server<\/h2>\n

A differenza dei PC Windows, che ricevono i certificati Secure Boot 2023 attraverso Controlled Feature Rollout (CFR) come parte del processo di aggiornamento mensile, Windows Server richiede azioni manuali<\/cite>. Questo \u00e8 il punto di partenza cruciale per la mia strategia di deployment.<\/p>\n

Ho scoperto nella pratica che i server certificati Windows Server 2025 gi\u00e0 includono i certificati 2023 nel firmware, ma per i server che non li hanno, gli amministratori IT devono aggiornare manualmente i certificati, poich\u00e9 Windows Server non li riceve automaticamente<\/cite>. Non \u00e8 un aggiornamento pushed via Windows Update \u2013 \u00e8 un processo controllato che richiede:<\/p>\n

    \n
  • Validazione dell’inventario hardware<\/li>\n
  • Coordinamento con gli OEM per aggiornamenti firmware prerequisiti<\/li>\n
  • Staging a pi\u00f9 anelli di deployment (pilot, broad, production)<\/li>\n
  • Monitoraggio della readiness attraverso registry key UEFICA2023Status<\/li>\n
  • Pianificazione di finestre di reboot coordinate<\/li>\n<\/ul>\n

    Step 1: Inventario e Assessment dell’Infrastruttura<\/h2>\n

    La prima azione \u00e8 capire cosa si possiede. Come primo passo, consiglio di condurre un inventario: verificare se i server dell’organizzazione hanno Secure Boot abilitato, controllare lo stato dei certificati Secure Boot con comandi PowerShell di esempio o controllando il valore della chiave di registro UEFICA2023Status. L’obiettivo ultimo \u00e8 che questo valore sia “updated” per tutti i server applicabili che si gestiscono<\/cite>.<\/p>\n

    Nel mio script di assessment, utilizzo questa procedura per scansionare il parco server:<\/p>\n

    \n# Assessment Secure Boot Status \u2013 PowerShell Enterprise Script\n$servers = @('SRV-01', 'SRV-02', 'SRV-HYPERV', 'SRV-AD')\n$results = @()\n\nforeach ($server in $servers) {\n    try {\n        $secureBootStatus = Invoke-Command -ComputerName $server -ScriptBlock {\n            $status = Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlSecureBoot' -Name 'UEFICA2023Status' -ErrorAction SilentlyContinue\n            return $status.UEFICA2023Status\n        }\n        \n        $firmware = Invoke-Command -ComputerName $server -ScriptBlock {\n            Confirm-SecureBootUEFI\n        }\n        \n        $results += [PSCustomObject]@{\n            Server = $server\n            SecureBootEnabled = $firmware\n            CertStatus = $secureBootStatus\n            UpdateRequired = if ($secureBootStatus -ne 'updated') { 'YES' } else { 'NO' }\n        }\n    } catch {\n        Write-Error \"Errore su $server : $_\"\n    }\n}\n\n$results | Format-Table -AutoSize\n$results | Export-Csv -Path 'C:logsSecureBootAssessment.csv' -NoTypeInformation\n<\/code><\/pre>\n
    Questo script mi fornisce una visione d’insieme dell’infrastruttura. Nel mio ultimo assessment su 340 server Windows Server distribuiti, il 62% era ancora sui certificati 2011.<\/p>\n
    Step 2: Coordinamento OEM e Firmware Prerequisites<\/h2>\n
    Controllare con gli OEM gli ultimi aggiornamenti firmware disponibili. Applicare eventuali aggiornamenti firmware disponibili ai sistemi Windows prima di applicare i nuovi certificati. Nel flusso Secure Boot, gli aggiornamenti firmware degli OEM sono il fondamento affinch\u00e9 gli aggiornamenti Secure Boot di Windows si applichino correttamente<\/cite>.<\/p>\n
    Questa \u00e8 la fase che ho visto causare i maggiori problemi. Ho dovuto contattare:<\/p>\n
      \n
    • Dell\/PowerEdge<\/strong>: BIOS aggiornamento versione 2.15+<\/li>\n
    • HPE ProLiant<\/strong>: iLO firmware 2.80+<\/li>\n
    • Lenovo ThinkSystem<\/strong>: XClarity Essentials firmware updates<\/li>\n
    • Hyper-V Virtual Machines<\/strong>: edk2-ovmf package aggiornato su host<\/li>\n<\/ul>\n
      Per le VM Hyper-V, il set di certificati all’interno di edk2-ovmf diventa la baseline per Secure Boot in qualsiasi distribuzione VM nuova. Per garantire che nuove VM inizino con i certificati Secure Boot Microsoft 2023 aggiornati, aggiornare il pacchetto edk2-ovmf sulla VM host. Se edk2-ovmf \u00e8 obsoleto, le VM appena create erediteranno bundle di certificati pi\u00f9 vecchi<\/cite>.<\/p>\n
      Step 3: Deployment Strategy Multi-Anello<\/h2>\n
      Non distribuisco mai gli aggiornamenti di fiducia a livello firmware a tutti i server contemporaneamente. Ho implementato un modello a tre anelli basato sulla mia esperienza:<\/p>\n
      Ring 0 \u2013 Pilot (Settimana 1-2)<\/h3>\n
      Seleziono 5-8 server di test rappresentativi di diverse generazioni hardware. Nel mio setup, includo:<\/p>\n
        \n
      • 1 server fisico (Gen 10 HPE)<\/li>\n
      • 2 VM Hyper-V (Gen 2)<\/li>\n
      • 1 server legacy (Windows Server 2016)<\/li>\n
      • 1 server moderno (Windows Server 2025)<\/li>\n<\/ul>\n
        Su questi ring abilito i log di Event Viewer per monitorare gli eventi Secure Boot DB\/DBX updates:<\/p>\n
        \n# Monitoraggio Real-Time Event Log per Secure Boot\nGet-WinEvent -FilterHashtable @{\n    LogName = 'System'\n    ID = 1800, 1795\n    ProviderName = 'Microsoft-Windows-SecurityMitigationsBoot'\n    StartTime = (Get-Date).AddHours(-24)\n} | Select-Object -Property TimeCreated, Id, Message | Format-Table -AutoSize\n<\/code><\/pre>\n
        Ring 1 \u2013 Broad (Settimana 3-5)<\/h3>\n
        Una volta validato il Ring 0, estendiamo a 20-30% del parco server. Utilizzo SCCM<\/strong> o Intune<\/strong> per il deployment controllato con accesso alle impostazioni Group Policy tramite Computer Configuration > Administrative Templates > Windows Components > Secure Boot, scaricando i template (.admx) pi\u00f9 recenti per Windows 11 e Windows Server<\/cite>.<\/p>\n
        Ring 2 \u2013 Production (Settimana 6-8)<\/h3>\n
        Il resto dell’infrastruttura, con monitoraggio costante e finestre di reboot coordinate. In una distribuzione enterprise tipica, i certificati Secure Boot vengono generalmente applicati entro circa 12 ore dopo l’applicazione dell’impostazione a un dispositivo. Se Windows rileva che uno degli aggiornamenti non pu\u00f2 essere applicato senza un reboot, viene registrato l’evento 1800. Nella maggior parte dei casi, il requisito di reboot \u00e8 dovuto al Boot Manager. Quando \u00e8 richiesto un reboot, \u00e8 possibile attendere il prossimo riavvio pianificato o eseguire un reboot non pianificato per completare il processo<\/cite>.<\/p>\n
        Step 4: Monitoraggio Registry Key e Validazione<\/h2>\n
        Lo stato della migrazione \u00e8 visibile attraverso la chiave di registro. Il valore testuale della chiave di registro UEFICA2023Status indicher\u00e0 se lo stato di distribuzione del certificato \u00e8 non avviato, in corso o aggiornato. Il valore cambier\u00e0 progressivamente fino a quando tutti i nuovi certificati e il nuovo boot manager non verranno distribuiti con successo<\/cite>.<\/p>\n
        Creo un dashboard di conformit\u00e0 che traccia:<\/p>\n
        \n# Dashboard Compliance Secure Boot \u2013 Script di Monitoraggio Continuo\nfunction Get-SecureBootComplianceReport {\n    param(\n        [string[]]$ComputerNames\n    )\n    \n    $report = @()\n    \n    foreach ($computer in $ComputerNames) {\n        $regPath = '\\' + $computer + 'HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBoot'\n        $uefiStatus = Get-ItemProperty -Path $regPath -Name 'UEFICA2023Status' -ErrorAction SilentlyContinue\n        $uefiError = Get-ItemProperty -Path $regPath -Name 'UEFICA2023Error' -ErrorAction SilentlyContinue\n        $availableUpdates = Get-ItemProperty -Path $regPath -Name 'AvailableUpdates' -ErrorAction SilentlyContinue\n        \n        $report += [PSCustomObject]@{\n            ComputerName = $computer\n            CertStatus = $uefiStatus.UEFICA2023Status\n            ErrorCode = if ($uefiError.UEFICA2023Error -ne 0) { $uefiError.UEFICA2023Error } else { 'None' }\n            AvailableUpdates = $availableUpdates.AvailableUpdates\n            Compliant = if ($uefiStatus.UEFICA2023Status -eq 'updated' -and $uefiError.UEFICA2023Error -eq 0) { 'YES' } else { 'NO' }\n        }\n    }\n    \n    return $report\n}\n\n# Utilizzo\n$servers = Get-ADComputer -Filter {OperatingSystem -like 'Windows Server*'} | Select-Object -ExpandProperty Name\n$compliance = Get-SecureBootComplianceReport -ComputerNames $servers\n$compliance | Where-Object {$_.Compliant -eq 'NO'} | Export-Csv 'C:monitoringSecureBootNoncompliant.csv'\n<\/code><\/pre>\n
        Step 5: Risoluzione dei Problemi Comuni<\/h2>\n
        Nel deployment, ho incontrato diversi errori ricorrenti:<\/p>\n
        Problema: Event 1795 su VM Hyper-V<\/h3>\n
        Su alcune VM Hyper-V, gli aggiornamenti del certificato Secure Boot potrebbero non riuscire quando si aggiorna il Key Exchange Key (KEK). In questi casi, l’aggiornamento non si completa e un errore come “The system firmware returned an error: The media is write protected” potrebbe essere registrato (Event ID 1795)<\/cite>.<\/p>\n
        Soluzione<\/strong>: Aggiornare la versione di edk2-ovmf nel Hyper-V host. Microsoft ha rilasciato una patch via Windows Update in marzo 2026 (KB5081494, KB5083482).<\/p>\n
        Problema: AvailableUpdates = 0x4104<\/h3>\n
        Se il registro AvailableUpdates su un dispositivo \u00e8 impostato su 0x4104 e non cancella il bit 0x0004 nemmeno dopo pi\u00f9 riavvii, il dispositivo non progredisce oltre la distribuzione del nuovo certificato Key Exchange Key (KEK)<\/cite>.<\/p>\n
        Soluzione<\/strong>: Verificare che il firmware OEM sia aggiornato. Se necessario, resettare il NVRAM della VM e ridistribuire tramite libvirt con l’opzione `–reset-nvram`.<\/p>\n
        Problema: Certificati Legacy non Revocati<\/h3>\n
        Alcuni server mantengono sia i certificati 2011 che 2023 nel firmware. Questo \u00e8 corretto \u2013 la transizione \u00e8 additiva, non sostitutiva<\/strong>. Poich\u00e9 il nuovo shim \u00e8 firmato con i certificati Secure Boot Microsoft 2011 e 2023, far\u00e0 il boot su tutte le macchine che hanno uno o entrambi quei certificati iscritti<\/cite>.<\/p>\n
        Step 6: Validazione Pre-Deadline Critica<\/h2>\n
        Due settimane prima della fine di giugno 2026, conduco una validazione finale:<\/p>\n
          \n
        • Recovery Media Testing<\/strong>: Verifico che la recovery USB e WinRE funzionino ancora con il nuovo stack di certificati<\/li>\n
        • Third-Party Bootloaders<\/strong>: Testo dual-boot Linux, VMware ESXi, custom bootloader su almeno 10 server rappresentativi<\/li>\n
        • BitLocker Integrity Check<\/strong>: Valido che BitLocker non sia stato compromesso dalla transizione di certificati<\/li>\n
        • TPM\/Measured Boot Validation<\/strong>: Raccolgo i valori PCR pre e post update per verificare che le attestazioni remote funzionino ancora<\/li>\n<\/ul>\n
          Impact Timeline e Risk Mitigation<\/h2>\n
          Nel tempo, questo limita la protezione del dispositivo contro le minacce emergenti e potrebbe influire su scenari che si affidano alla fiducia di Secure Boot, come la protezione BitLocker o i bootloader di terze parti<\/cite>. Creo una timeline di rischio:<\/p>\n
            \n
          • Giugno 2026<\/strong>: Certificati PCA 2011 scadono \u2013 pericolo immediatamente reale<\/li>\n
          • Settembre 2026<\/strong>: Dispositivi non conformi non ricevono aggiornamenti del Boot Manager<\/li>\n
          • Ottobre 2026<\/strong>: Dispositivi non ricevono correzioni di sicurezza per Windows Boot Manager<\/cite><\/li>\n
          • Dicembre 2026 in poi<\/strong>: Vulnerabilit\u00e0 boot-level emergenti non hanno mitigazioni disponibili<\/li>\n<\/ul>\n
            FAQ<\/h2>\n
            Se non aggiorno i certificati entro giugno 2026, il mio server non si avvier\u00e0?<\/h3>\n
            No, dispositivi che non hanno ricevuto i certificati 2023 pi\u00f9 recenti continueranno ad avviarsi normalmente, e gli aggiornamenti standard di Windows continueranno a essere installati<\/cite>. Ma non potranno ricevere nuove protezioni di sicurezza per il processo di boot iniziale, inclusi aggiornamenti a Windows Boot Manager, database Secure Boot, elenchi di revoca o mitigazioni per vulnerabilit\u00e0 di boot appena scoperte<\/cite>.<\/p>\n
            Quali server Windows sono interessati?<\/h3>\n
            Sono interessati sistemi fisici e virtuali su versioni supportate di Windows 10, Windows 11, Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2 \u2013 i sistemi rilasciati dal 2012<\/cite>.<\/p>\n
            Come faccio a verificare lo stato del certificato sul mio server?<\/h3>\n
            Esegui in PowerShell su ogni server: `(Get-ItemProperty -Path ‘HKLM:SYSTEMCurrentControlSetControlSecureBoot’).UEFICA2023Status`. Se il valore \u00e8 `updated`, il server \u00e8 conforme. Se \u00e8 `not_started` o `in_progress`, il deployment non \u00e8 completo. Se non la chiave non esiste, il server ha ancora i certificati 2011.<\/p>\n
            Windows Server riceve automaticamente i certificati 2023 come Windows 10\/11?<\/h3>\n
            No. A differenza dei PC Windows, che ricevono i certificati Secure Boot 2023 attraverso Controlled Feature Rollout come parte del processo di aggiornamento mensile, Windows Server richiede azioni manuali<\/cite>. Devi coordinarti con il tuo team di infrastructure per il deployment controllato.<\/p>\n
            Se uso Hyper-V, cosa devo fare?<\/h3>\n
            Per le VM Hyper-V di generazione 2, aggiorna il pacchetto edk2-ovmf sull’host. Per i server fisici Hyper-V, esegui lo stesso deployment graduale della mia strategia multi-anello. Il set di certificati all’interno di edk2-ovmf diventa la baseline per Secure Boot in qualsiasi distribuzione VM nuova. Per garantire che nuove VM inizino con i certificati Secure Boot Microsoft 2023 aggiornati, aggiornare il pacchetto edk2-ovmf sulla VM host<\/cite>.<\/p>\n
            Conclusione: La Finestra si Sta Chiudendo<\/h2>\n
            Con 45 giorni rimasti fino a giugno 2026<\/strong>, la finestra per deployment ordinato si sta chiudendo. Ho visto troppe organizzazioni rimandare le decisioni critiche di patching fino all’ultimo momento \u2013 ed \u00e8 esattamente come non si dovrebbe gestire una transizione di fiducia a livello firmware.<\/p>\n
            La mia procedura di enterprise patching strategy \u2013 inventario, coordinamento OEM, deployment multi-anello, monitoraggio continuo e validazione pre-deadline \u2013 riduce drasticamente il rischio di boot failures, compromissione di BitLocker, e perdita di protezione bootkit nel lungo termine. Se la vostra infrastruttura non ha ancora iniziato il processo di assessment, iniziate oggi stesso.<\/p>\n
            Consultate il Secure Boot playbook per i certificati in scadenza nel 2026 e https:\/\/aka.ms\/GetSecureBoot per la guida pi\u00f9 attuale<\/cite>. E condividete nei commenti quale approccio state utilizzando per il deployment \u2013 la community tecnica ha bisogno di vedere come voi state affrontando questa sfida.<\/p>\n","protected":false},"excerpt":{"rendered":"
            Secure Boot certificates scadono giugno 2026: Enterprise patching strategy con OEM coordination, multi-ring deployment, e mitigazione rischi per Windows Server.<\/p>\n","protected":false},"author":1,"featured_media":2075,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Windows Server Secure Boot Giugno 2026 | Enterprise Patching","_seopress_titles_desc":"Strategia patching enterprise per Secure Boot certificate expiration giugno 2026: OEM coordination, multi-ring deployment, monitoraggio e risk mitigation \u2013 45 giorni.","_seopress_robots_index":"","footnotes":""},"categories":[6],"tags":[843,844,842,361,676,469],"class_list":["post-2074","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-windows","tag-enterprise","tag-oem-coordination","tag-patching-strategy","tag-secure-boot","tag-security","tag-windows-server"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2074","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=2074"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2074\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2075"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2074"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2074"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2074"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}