{"id":2588,"date":"2026-06-29T22:08:18","date_gmt":"2026-06-29T20:08:18","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/secure-boot-rollover-giugno-2026-zero-downtime-oem-coordination-troubleshooting\/"},"modified":"2026-06-29T22:08:18","modified_gmt":"2026-06-29T20:08:18","slug":"secure-boot-rollover-giugno-2026-zero-downtime-oem-coordination-troubleshooting","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/secure-boot-rollover-giugno-2026-zero-downtime-oem-coordination-troubleshooting\/","title":{"rendered":"Windows Secure Boot Certificate Rollover Post-24 Giugno 2026: La Mia Strategia Zero-Downtime per Enterprise, Firmware Compatibility Troubleshooting e OEM Coordination"},"content":{"rendered":"

La scadenza del 24 giugno 2026 per il certificato Microsoft Corporation KEK CA 2011<\/strong> non \u00e8 stata un evento drammatico di blocco di massa, ma ha rivelato esattamente quello che temevo: un’ecosistema PC frammentato dove le aziende si sono trovate con device stranded, firmware obsoleto, e processi di deployment disomogenei. Nella mia esperienza di amministratore enterprise, la vera sfida non \u00e8 stata la data limite in s\u00e9, ma quello che \u00e8 arrivato dopo<\/em>: coordinare OEM che offrono update tardivi, gestire sistemi in air-gap, troubleshootare Hyper-V template obsoleti, e soprattutto mantenere la continuit\u00e0 operativa senza ricadere su soluzioni “disabilita Secure Boot” che creano altre vulnerabilit\u00e0.<\/p>\n

In questo articolo, voglio condividere la strategia operativa che ho sviluppato per navigare questo rollover con zero downtime, i problemi di firmware compatibility che ho effettivamente incontrato durante la transizione, e come coordinare gli OEM (Dell, HP, Lenovo) in un contesto enterprise con asset inventory complesso. La transizione dai certificati 2011 ai 2023 non \u00e8 una semplice Windows Update: \u00e8 una migrazione della catena crittografica di fiducia che vive nel firmware, e se non gestita correttamente, puoi ritrovarti con device che bootano ma non ricevono pi\u00f9 revocation updates DBX, esponendo la tua infrastruttura a exploit come BlackLotus indefinitamente.<\/p>\n

La Situazione Reale Post-24 Giugno 2026: Cosa Non Vi Raccontano<\/h2>\n

Quando il KEK CA 2011 \u00e8 scaduto, ho osservato tre comportamenti distinti nei device aziendali:<\/p>\n

    \n
  1. Device “silenziosamente all’indietro”<\/strong>: Device che continuano a bootare normalmente (Windows carica, applicazioni funzionano), ma con Secure Boot in uno stato degradato. Il firmware rifiuta silenziosamente aggiornamenti DBX firmati esclusivamente con il certificato 2023, congelando le revocation list sulla data di scadenza.<\/li>\n
  2. Device con firmware OEM bloccato<\/strong>: Sistemi dove il produttore (specie su hardware end-of-service come Dell PowerEdge 12-13 gen) non ha mai rilasciato firmware con supporto per i certificati 2023, e Windows Update da solo non pu\u00f2 completare la transizione.<\/li>\n
  3. Device di transizione corretta<\/strong>: Sistemi che hanno ricevuto firmware OEM aggiornato + Windows Update, e ora supportano sia i certificati 2011 (legacy) che 2023 (moderni) nel firmware.<\/li>\n<\/ol>\n

    Il problema critico \u00e8 il primo gruppo. Dispositivi che non migrano continueranno a bootare, ma perderanno permanentemente gli aggiornamenti della lista di revoca DBX: nuovi bootkit e varianti di bootloader malicioso non verranno mai aggiunti alla lista nera a livello firmware<\/cite>. Questo non \u00e8 una vulnerabilit\u00e0 teorica: \u00e8 una apertura permanente<\/em> verso attacchi pre-OS come Kernel-mode rootkit via bootkit inoculato prima che Secure Boot possa verificarlo.<\/p>\n

    Step-by-Step: La Mia Procedura Zero-Downtime per Enterprise<\/h2>\n

    Fase 1: Asset Inventory e Firmware Readiness (Settimane 1-2)<\/h3>\n

    Non basta dire “tutti i device hanno Secure Boot abilitato”. Devi sapere:<\/p>\n

      \n
    • Quale certificato \u00e8 attualmente nel firmware<\/em> di ogni device (2011, 2023, o dual)<\/li>\n
    • Quale versione firmware ha ogni device<\/li>\n
    • Se l’OEM ha rilasciato firmware update con supporto 2023 per quel modello<\/li>\n
    • Se il firmware \u00e8 supportato o end-of-service<\/li>\n<\/ul>\n

      Io ho usato PowerShell per scannerizzare il registro su tutti i device (tramite Intune Report o Configuration Manager):<\/p>\n

      $RegistryPath = \"HKLM:SYSTEMCurrentControlSetControlSecureBootServicing\"\n$Status = Get-ItemProperty -Path $RegistryPath -Name UEFICA2023Status -ErrorAction SilentlyContinue\n$Error = Get-ItemProperty -Path $RegistryPath -Name UEFICA2023Error -ErrorAction SilentlyContinue\n\n[PSCustomObject]@{\n    ComputerName = $env:COMPUTERNAME\n    SecureBootStatus = $Status.UEFICA2023Status\n    HasError = $Error.UEFICA2023Error\n    Timestamp = Get-Date\n}\n<\/code><\/pre>\n
      Questo ti mostra il valore UEFICA2023Status<\/strong> che pu\u00f2 essere:<\/p>\n
        \n
      • “Not Started”<\/strong> \u2013 Device non ha ancora tentato l’update<\/li>\n
      • “In Progress”<\/strong> \u2013 Update in corso (attendi, non riavviare)<\/li>\n
      • “Updated”<\/strong> \u2013 Certificati 2023 sono installati nel firmware<\/li>\n<\/ul>\n
        Se vedi UEFICA2023Error<\/strong>, significa che c’\u00e8 stato un errore quando Windows ha tentato di passare i certificati al firmware: verifica con l’OEM se c’\u00e8 un update firmware disponibile per il device<\/cite>.<\/p>\n
        Fase 2: OEM Firmware Coordination (Settimane 2-6)<\/h3>\n
        Questo \u00e8 dove la maggior parte dei problemi emergono. Nel mio ambiente:<\/p>\n
          \n
        • Dell PowerEdge<\/strong>: Generazioni 14-16 ricevono firmware fino a fine 2025. Generazioni 12-13 = end-of-service, nessun update.<\/li>\n
        • HP ProBook\/EliteBook<\/strong>: Support varia per serie; devo verificare caso per caso su hp.com\/support<\/li>\n
        • Lenovo ThinkPad<\/strong>: Psych Lenovo rilascia firmware update per modelli 2019+, ma 2017-2018 \u00e8 borderline.<\/li>\n<\/ul>\n
          Per device end-of-service (Dell PowerEdge 12-13 gen, HP forti del 2016), l’unica strada \u00e8 accettare il rischio e abilitare un’eccezione di compliance<\/strong>, oppure pianificare la sostituzione hardware<\/strong>. Non existe un compromesso di sicurezza accettabile qui.<\/p>\n
          Ho creato una matrice di rischio:<\/p>\n
            \n
          1. Tier 1 (Verde)<\/strong>: Device con firmware OEM aggiornato + certificati 2023 gi\u00e0 presenti. Zero rischio. Nessun’azione.<\/li>\n
          2. Tier 2 (Giallo)<\/strong>: Device con firmware vecchio ma OEM supporta ancora il modello. Piano: firmware update + Windows Update coordinati.<\/li>\n
          3. Tier 3 (Rosso)<\/strong>: End-of-service, nessun firmware disponibile. Piano: replacement hardware o eccezione scritta con mitigazioni compensative (air-gap, isolamento rete, monitoraggio EDR intensivo).<\/li>\n<\/ol>\n
            Fase 3: Staged Deployment di Windows + Firmware Updates (Settimane 4-12)<\/h3>\n
            Questo \u00e8 il vero epicentro della strategia zero-downtime. Microsoft consiglia di testare gli aggiornamenti dei certificati su device rappresentativi (per ogni categoria unica come produttore, modello, versione firmware), consigliando almeno 4 o pi\u00f9 device di esempio<\/cite>.<\/p>\n
            Il mio approccio (che ho usato con successo):<\/p>\n
              \n
            1. Pilot Wave 1<\/strong>: 4-5 device per ogni combinazione OEM\/Modello\/Firmware. Monitoraggio quotidiano per 2 settimane post-update.\n
                \n
              • Verifico Event ID 1808 (indicatore di certificati applicati con successo)<\/li>\n
              • Monitoraggio BitLocker \u2013 a volte le transizioni di fiducia del firmware possono triggerare BitLocker recovery (ho visto questo accadere 2-3 volte)<\/li>\n
              • Test boot da media recovery per assicurarsi che WinPE e imaging tools funzionino ancora<\/li>\n<\/ul>\n<\/li>\n
              • Firmware OEM First<\/strong>: Non applicare Windows Update finch\u00e9 il firmware non \u00e8 aggiornato. Se il firmware \u00e8 vecchio, il firmware potrebbe non accettare i certificati 2023 anche se Windows Update li invia. L’ordine conta: Firmware \u2192 Windows Update<\/strong>.<\/li>\n
              • Registry Key Control<\/strong>: Usa il registry key HKLM:SYSTEMCurrentControlSetControlSecureBootServicing<\/strong> per controllare manualmente il deployment via Group Policy o Intune, non fare affidamento automatico su Windows Update.\n
                  \n
                • Imposta MicrosoftUpdateManagedOptIn = 1<\/strong> solo dopo il firmware update \u00e8 verificato come riuscito<\/li>\n
                • Usa HighConfidenceOptOut = 0<\/strong> per device che rientrano nella categoria Microsoft “high-confidence” (apparecchi recenti con firmware moderno)<\/li>\n<\/ul>\n<\/li>\n
                • Monitoraggio post-update<\/strong>: Aspetta 1-2 cicli di refresh della scheduled task (ogni 12 ore) prima di procedere al prossimo wave.\n
                    \n
                  • La scheduled task MicrosoftWindowsPISecure-Boot-Update<\/strong> tenta l’update ogni 12 ore<\/li>\n
                  • La scheduled task Secure-Boot-Update \u00e8 guidata dal valore del registry AvailableUpdates, una maschera a 32-bit localizzata in HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBoot. Ogni bit rappresenta un’azione di aggiornamento Secure Boot specifica. Il processo inizia quando AvailableUpdates \u00e8 impostato su un valore non zero<\/cite><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
                    Firmware Compatibility Troubleshooting: I Problemi Che Ho Incontrato<\/h2>\n
                    Problema 1: Event ID 1795 \u2013 Firmware Write-Protected o Incompatibile<\/h3>\n
                    Situazione: Device mostra Event ID 1795<\/strong> in Event Viewer (System log).<\/p>\n
                    Causa: Se Event Viewer Windows Logs registra Event ID 1795, significa che c’\u00e8 stato un errore quando Windows ha tentato di passare i certificati al firmware. Verifica con l’OEM se c’\u00e8 un firmware update disponibile per il device<\/cite>.<\/p>\n
                    Soluzione (dalla mia esperienza):<\/p>\n
                      \n
                    1. Verifica che Secure Boot sia abilitato<\/strong> nel firmware (UEFI setup)<\/li>\n
                    2. Scarica il firmware OEM pi\u00f9 recente<\/strong> (s\u00ec, ancora prima di Windows Update)<\/li>\n
                    3. Applica il firmware update (in genere \u00e8 un .exe per Windows, o una procedura BIOS manual boot)<\/li>\n
                    4. Forza il retry della scheduled task manualmente:
                      \nschtasks.exe \/Run \/TN \"MicrosoftWindowsPISecure-Boot-Update\" \/I<\/code>\n<\/li>\n
                    5. Attendi 2-3 cicli (24-36 ore) e ri-controlla il registry per verificare che UEFICA2023Status sia “Updated”<\/li>\n<\/ol>\n
                      Problema 2: Hyper-V Virtual Machine e EDK2-OVMF Template Obsoleti<\/h3>\n
                      Situazione: VMs Hyper-V create da template datati non hanno i certificati 2023.<\/p>\n
                      Causa: Hyper-V, VMware ESXi, KVM\/QEMU con OVMF e Proxmox mantengono il loro firmware UEFI virtuale separatamente dall’host. VM abilitate per Secure Boot portano il loro stato DB, DBX e KEK in firmware OVMF o EDK2-based. Aggiornare l’host non aggiorna il guest. Ogni VM ha bisogno della sua propria transizione di certificato<\/cite>.<\/p>\n
                      Soluzione (ho testato questo):<\/p>\n
                        \n
                      1. Aggiorna EDK2-OVMF sull’host Hyper-V<\/strong>: Assicurati che l’host Hyper-V abbia ricevuto Windows Update di marzo 2026 o successivo. Questo aggiorna il template UEFI virtuale per le nuove VM.<\/li>\n
                      2. VM Hyper-V esistenti<\/strong>: Se una VM \u00e8 gi\u00e0 creata con firmware vecchio, Windows Update dentro la VM<\/em> pu\u00f2 comunque installare i certificati 2023, ma solo se sia l’host che il guest hanno l’update di marzo 2026+<\/em>. Su Hyper-V, gli aggiornamenti dei certificati Secure Boot richiedono l’installazione degli aggiornamenti Windows di marzo 2026 sia sull’host Hyper-V che sul guest OS<\/cite>.<\/li>\n
                      3. VM nuove<\/strong>: Assicurati di creare nuove VMs dopo<\/em> che l’host ha ricevuto l’update. Erediteranno automaticamente il firmware con certificati 2023.<\/li>\n<\/ol>\n
                        Problema 3: Air-Gapped Systems Senza Windows Update<\/h3>\n
                        Situazione: Device in ambienti air-gap, staccati da internet, non ricevono Windows Update.<\/p>\n
                        Causa: Senza Windows Update, il device non riceve i certificati 2023, n\u00e9 il firmware OEM update pu\u00f2 raggiungerlo.<\/p>\n
                        Soluzione (manuale, ma testata):<\/p>\n
                          \n
                        1. Scarica offline l’update di Windows<\/strong>: Ottieni il .cab file specifico per il tuo Windows release dai Microsoft Update servers (tramite WSUS offline o direct download).<\/li>\n
                        2. Applica manualmente via PowerShell Remoting (se disponibile)<\/strong> o tramite media USB<\/strong>:
                          \nAdd-WindowsPackage -Online -PackagePath C:pathtosecure-boot-update.cab<\/code>\n<\/li>\n
                        3. Firmware update separato<\/strong>: Se il device ha anche bisogno di firmware update OEM, applica quello tramite media USB o recovery environment.\n
                          Questa operazione \u00e8 molto delicata<\/em>: se interrompi un firmware update, il device potrebbe non bootare. Assicurati di una finestra di manutenzione, power backup, e recovery media disponibile.<\/li>\n<\/ol>\n
                          OEM Coordination Strategy per Enterprise<\/h2>\n
                          Se gestisci una flotta di migliaia di device da pi\u00f9 OEM, ecco come coordinare:<\/p>\n
                            \n
                          1. Crea una tabella di supporto OEM<\/strong>:
                            \n\n\n\n\n\n
                            OEM<\/th>\nModello<\/th>\nGenerazione<\/th>\nFirmware Disponibile?<\/th>\nData rilascio<\/th>\nStatus<\/th>\nNote<\/th>\n<\/tr>\n
                            Dell<\/td>\nPowerEdge 16 (2U)<\/td>\nGen 16<\/td>\nS\u00ec<\/td>\nDec 2025<\/td>\nVerified<\/td>\nTier 1 \u2013 Deploy immediately<\/td>\n<\/tr>\n
                            Dell<\/td>\nPowerEdge 12<\/td>\nGen 12<\/td>\nNo<\/td>\nEnd of Service<\/td>\nException<\/td>\nTier 3 \u2013 Replacement planned<\/td>\n<\/tr>\n
                            HP<\/td>\nProBook 450 G8<\/td>\nGen 8<\/td>\nS\u00ec<\/td>\nMay 2026<\/td>\nPilot<\/td>\nTier 2 \u2013 Testing in progress<\/td>\n<\/tr>\n<\/table>\n<\/li>\n
                          2. Contatta gli OEM direttamente per Tier 3<\/strong>: Scrivi a Dell, HP, Lenovo support con specifiche di device (serial number range, asset tag) per confermare se supporto \u00e8 disponibile. Molti OEM hanno canali enterprise per supporto firmware bulk.<\/li>\n
                          3. Usa WSUS \/ Windows Update for Business per coordinamento centralizzato<\/strong>: Se gestisci Windows Update tramite WSUS o Windows Update for Business, puoi controllare quando i certificati 2023 vengono installati, rinviare su un modello specifico, o rollout in ondate.\n
                            Esempio di Group Policy:
                            \nComputer Configuration \u2192 Administrative Templates \u2192 System \u2192 Windows Update \u2192 \"Certificate Deployment via Controlled Feature Rollout\"<\/code><\/p>\n
                            Impostazione su “Enabled” ti permette di usare ConfigMgr o Intune per un rollout controllato.<\/li>\n<\/ol>\n
                            Verifica Post-Rollover: Come Confermare il Successo<\/h2>\n
                            Non \u00e8 sufficiente dire “Secure Boot \u00e8 abilitato”. Devi verificare che i certificati 2023 siano effettivamente nel firmware<\/strong>.<\/p>\n
                            Check 1: Registry Status<\/h3>\n
                            Get-ItemProperty -Path \"HKLM:SYSTEMCurrentControlSetControlSecureBootServicing\" | Select UEFICA2023Status, UEFICA2023Error\n<\/code><\/pre>\n
                            Aspetta “Updated”<\/strong>. Se vedi “Not Started”<\/strong> o “In Progress”<\/strong>, il device non ha completato ancora.<\/p>\n
                            Check 2: Event Log \u2013 Event ID 1808<\/h3>\n
                            Get-WinEvent -FilterHashtable @{LogName=\"System\"; ID=1808} | Select TimeCreated, Message | Sort TimeCreated -Descending | Select -First 5\n<\/code><\/pre>\n
                            L’evento informativo 1808 nel System Event Log indica che il device ha i certificati Secure Boot 2023 richiesti applicati nel firmware del device<\/cite>.<\/p>\n
                            Check 3: Windows Security App (GUI Visual)<\/h3>\n
                            Naviga in Windows Security \u2192 Device Security \u2192 Secure Boot<\/strong>. Dovrebbe mostrare un checkmark verde<\/strong> con “Fully updated” se i certificati 2023 sono presenti.<\/p>\n
                            Se mostra yellow warning<\/strong> o red alert<\/strong>, il device ha bisogno ancora di azione.<\/p>\n
                            Problemi Specifici Post-24 Giugno: Cosa Continuare a Monitorare<\/h2>\n
                            Frozen DBX State<\/h3>\n
                            Device che non hanno ricevuto il certificato 2023 KEK rimarranno con la loro lista di revocazione DBX congelata alla data di scadenza (24 giugno 2026). Dopo quella data:<\/p>\n
                              \n
                            • Nessun nuovo bootkit pu\u00f2 essere revocato nel DBX<\/li>\n
                            • Nessun nuovo boot component compromise pu\u00f2 essere blacklisted a livello firmware<\/li>\n
                            • Attacchi pre-OS (come quelli di BlackLotus) rimangono non rilevati se il loro bootkit hash non era gi\u00e0 nel DBX<\/li>\n<\/ul>\n
                              Questa \u00e8 una vulnerabilit\u00e0 permanente<\/strong> finch\u00e9 il device non riceve il firmware\/certificato update.<\/p>\n
                              Linux Boot Compatibility<\/h3>\n
                              Se ami Ubuntu Server, RHEL, Rocky, o Linux in generale: Una volta che la chiave 2011 scade, qualsiasi nuovo binary shim sar\u00e0 firmato solo con la chiave 2023. Questo significa che i media di installazione Linux basati su un nuovo shim firmato con la chiave 2023 non bootaranno su macchine il cui firmware contiene solo i certificati 2011 vecchi, impattando direttamente su installazioni bare-metal, deployment di server e template VM in ambienti enterprise<\/cite>.<\/p>\n
                              Se gestisci server Linux: verifica con il tuo OS vendor (Red Hat ha gi\u00e0 rilasciato shim aggiornato per RHEL 8\/9\/10) che il boot loader sia compatibile con la tua attuale Secure Boot setup.<\/p>\n
                              Third-Party Boot Utilities e Recovery Media<\/h3>\n
                              Se usi strumenti di imaging legacy (Symantec Ghost, Acronis, altri), tool di recovery, o double-boot setups (Windows + Linux, o Windows + WinPE), il rischio dell’azienda si concentra in fleet gestite, device air-gapped, vecchie immagini di deployment, media di recovery, sistemi dual-boot e hardware con supporto firmware obsoleto<\/cite>.<\/p>\n
                              Testa in laboratorio che i tuoi strumenti di recovery funzionino ancora con il nuovo Secure Boot state. Se usi media WinPE, assicurati che l’ultima versione con certificati 2023 sia building sui tuoi deployment media.<\/p>\n
                              FAQ<\/h2>\n
                              Il mio PC boot\u00e0 ancora dopo il 24 giugno 2026 anche se non ho i certificati 2023?<\/h3>\n
                              S\u00ec, il PC continuer\u00e0 a bootare e Windows funzioner\u00e0 normalmente. Ma la macchina potrebbe comunque accendersi e Windows potrebbe ancora caricarsi, e le applicazioni potrebbero comportarsi esattamente come prima. Ma l’infrastruttura di fiducia che permette a Microsoft e agli OEM di mantenere le difese a livello di boot aggiornate sar\u00e0 stata sostituita. Se quella sostituzione non accade in modo pulito, la modalit\u00e0 di guasto \u00e8 ritardata, sottile e rilevante per la sicurezza, piuttosto che drammatica<\/cite>.<\/p>\n
                              Cosa accade se disabilito Secure Boot per evitare il problema?<\/h3>\n
                              Eviterai questo problema specifico, ma crei altri molto peggiori. Disabilitare Secure Boot potrebbe aggirare un sintomo, ma indebolisce la protezione del boot e crea problemi secondari con BitLocker, controlli di conformit\u00e0 e tooling di sicurezza<\/cite>. La soluzione giusta \u00e8 aggiornare, non disabilitare.<\/p>\n
                              Quanto tempo impiega Windows Update a installare i certificati 2023?<\/h3>\n
                              Varia, ma una scheduled task permette a Windows di tentare questi aggiornamenti quando il sistema \u00e8 in uno stato dove le variabili del firmware possono essere modificate. La pianificazione ricorrente di 12 ore fornisce opportunit\u00e0 aggiuntive per ritentare gli aggiornamenti se un tentativo precedente \u00e8 fallito o se il device \u00e8 rimasto acceso senza riavviarsi. Questo design aiuta a garantire il progresso in avanti senza richiedere intervento manuale<\/cite>. In media: 2-7 giorni con reboot naturali inclusi.<\/p>\n
                              Come faccio a forzare l’update immediato senza aspettare Windows Update?<\/h3>\n
                              Puoi triggerare manualmente la scheduled task:
                              \nschtasks.exe \/Run \/TN \"MicrosoftWindowsPISecure-Boot-Update\" \/I<\/code><\/p>\n
                              Poi controlla il registry ogni 12 ore per il cambio di stato UEFICA2023Status.<\/p>\n
                              Se l’OEM non ha rilasciato firmware con certificati 2023, cosa faccio?<\/h3>\n
                              Se il device \u00e8 end-of-service e l’OEM non rilascia firmware: hai tre opzioni:<\/p>\n
                                \n
                              1. Accettare il rischio residuo (device bootabile, ma congelato su DBX pre-giugno 2026)<\/li>\n
                              2. Pianificare la sostituzione hardware per quel device<\/li>\n
                              3. Implementare compensative controls (EDR aggressivo, network segmentation, air-gap parziale)<\/li>\n<\/ol>\n
                                Non c’\u00e8 una soluzione tecnica pura. La decisione \u00e8 di risk management e compliance.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                Strategia zero-downtime per Windows Secure Boot post-24 giugno 2026: firmware compatibility troubleshooting, OEM coordination enterprise, e mitigazione rischi per device stranded.<\/p>\n","protected":false},"author":1,"featured_media":2589,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Secure Boot Rollover Giugno 2026: Zero-Downtime Enterprise | Dario Iannascoli","_seopress_titles_desc":"Guida operativa Windows Secure Boot Certificate rollover post-giugno 2026: strategia zero-downtime, firmware OEM coordination, troubleshooting Event ID 1795, Hyper-V template, air-gap systems.","_seopress_robots_index":"","footnotes":""},"categories":[6],"tags":[998,999,844,361,561,870,82,1000],"class_list":["post-2588","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-windows","tag-certificate-rollover","tag-enterprise-infrastructure","tag-oem-coordination","tag-secure-boot","tag-troubleshooting","tag-uefi-firmware","tag-windows-11","tag-zero-downtime-deployment"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2588","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=2588"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2588\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2589"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2588"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2588"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2588"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}