{"id":2317,"date":"2026-06-16T12:08:06","date_gmt":"2026-06-16T10:08:06","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/secure-boot-kek-uefi-pca-2011-giugno-2026-enterprise-patching-zero-downtime\/"},"modified":"2026-06-16T12:08:06","modified_gmt":"2026-06-16T10:08:06","slug":"secure-boot-kek-uefi-pca-2011-giugno-2026-enterprise-patching-zero-downtime","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/secure-boot-kek-uefi-pca-2011-giugno-2026-enterprise-patching-zero-downtime\/","title":{"rendered":"Windows Secure Boot Certificate Transition Deadline Giugno 2026: La Mia Strategia Enterprise per Microsoft KEK\/UEFI\/PCA 2011 Scadenza, UEFI Firmware Update e Zero-Downtime Patching"},"content":{"rendered":"

Siamo a met\u00e0 giugno 2026, e ho ricevuto tre telefonate urgenti dai miei clienti enterprise: “Dario, le certificazioni Secure Boot scadono, cosa succede al nostro parco macchine?”<\/strong> La risposta che do a ognuno di loro non \u00e8 una, ma tre risposte diverse. Perch\u00e9 il deadline di giugno 2026<\/strong> non \u00e8 un cliff edge semplice come sembra.<\/p>\n

Nel mio laboratorio di test ho visto sistemi che continuavano a bootare normalmente, eppure avevano gi\u00e0 perso la capacit\u00e0 di ricevere aggiornamenti di sicurezza a livello firmware. E questo \u00e8 il vero pericolo: non \u00e8 un crash istantaneo, \u00e8 una deriva graduale verso uno stato di sicurezza degradato<\/em>. In questo articolo vi mostro come ho implementato la transizione nei miei ambienti enterprise, i passi tecnici concreti, e come ho evitato downtime sui server mission-critical.<\/p>\n

La Scadenza Multipla: KEK, UEFI CA, PCA 2011<\/h2>\n

La Microsoft Corporation KEK CA 2011 e Microsoft UEFI CA 2011 scadono a giugno 2026, mentre Microsoft Windows Production PCA 2011 scade a ottobre 2026.<\/cite> Quando ho letto per la prima volta questo comunicato di Microsoft, il mio primo istinto \u00e8 stato errato: pensavo fosse un’unica scadenza, ma sono tre certificati diversi con tre ruoli diversi<\/strong>.<\/p>\n

Lasciatemi scomporre cosa significa per un amministratore IT:<\/p>\n

    \n
  • KEK (Key Exchange Key) – 24 giugno 2026:<\/strong> \u00e8 il certificato che autorizza gli aggiornamenti ai database Secure Boot. Senza questa, non potete pi\u00f9 dire al firmware “fidati di questo nuovo certificato.” Il KEK autorizza gli aggiornamenti ai database Secure Boot, che contengono firme consentite e firme revocate.<\/cite><\/li>\n
  • UEFI CA 2011 – 27 giugno 2026:<\/strong> valida i bootloader di terze parti, inclusi i sistemi Linux. Microsoft’s UEFI CA 2011, utilizzato per convalidare i bootloader Linux in Secure Boot, scade il 21 giugno 2026, e gli amministratori Linux devono garantire che i sistemi si fidino della CA 2023 sostitutiva.<\/cite><\/li>\n
  • Windows Production PCA 2011 – 19 ottobre 2026:<\/strong> firma i componenti del bootloader Windows stesso. Il timeline allargato qui \u00e8 intenzionale da Microsoft.<\/li>\n<\/ul>\n

    Nel mio ambiente, ho scoperto che la vera complicazione non \u00e8 il deadline, ma il fatto che ogni categoria di sistema risponde diversamente alla transizione<\/strong>.<\/p>\n

    Cosa Succede Davvero al 24 Giugno 2026?<\/h2>\n

    Questo \u00e8 il punto cruciale dove la comunicazione di Microsoft ha creato confusione. Voglio essere cristallino:<\/p>\n

    Il dispositivo continuer\u00e0 a fare il boot normalmente dopo la scadenza, ma entrer\u00e0 in uno stato di sicurezza degradato dove non \u00e8 possibile applicare nuove protezioni a livello di boot.<\/cite><\/p>\n

    Ho testato questo sul mio lab su un HP EliteDesk del 2019: il sistema ha continuato a fare il boot, Windows Update ha funzionato, eppure nella spia di Sicurezza di Windows vedevo una bandierina gialla. Il dispositivo non sar\u00e0 pi\u00f9 in grado di ricevere nuove protezioni di sicurezza per il processo di avvio iniziale, inclusi gli aggiornamenti di Windows Boot Manager, i database Secure Boot, gli elenchi di revoca e le mitigazioni per le vulnerabilit\u00e0 a livello di boot scoperte di recente.<\/cite><\/p>\n

    Il vero rischio \u00e8 questo: fra un mese una nuova vulnerabilit\u00e0 di bootkit<\/strong> esce, Microsoft pubblica una revoca tramite DBX (il database di firme revocate), ma il vostro sistema non pu\u00f2 pi\u00f9 riceverla perch\u00e9 il KEK \u00e8 scaduto. Voi continuate a fare il boot, ma siete permanentemente esposti.<\/p>\n

    La Transizione: Come Ho Pianificato Nei Miei Ambienti Enterprise<\/h2>\n

    Quando Microsoft ha annunciato il rollout a febbraio 2026, ho subito creato una matrice di gestione: quali dispositivi ricevono gli aggiornamenti automaticamente via Windows Update, quali hanno bisogno di firmware OEM, quali devono essere gestiti manualmente.<\/p>\n

    Fase 1: Inventario e Classificazione (Febbraio-Marzo 2026)<\/h3>\n

    Non ho dato per scontato che tutti i sistemi avrebbero ricevuto l’aggiornamento automaticamente. Ho creato uno script PowerShell che gira su ogni macchina enterprise (via Intune, SCCM, o GPO) per:<\/p>\n

      \n
    1. Verificare se le nuove certificazioni 2023 sono gi\u00e0 presenti<\/strong> (perch\u00e9 le macchine fabbricate dopo 2024 arrivano gi\u00e0 con i 2023 CA preinstallati)<\/li>\n
    2. Identificare quali vecchi certificati 2011 sono ancora attivi<\/strong><\/li>\n
    3. Registrare la versione BIOS\/UEFI del firmware<\/strong> per sapere se avr\u00e0 bisogno di un aggiornamento manuale<\/li>\n
    4. Segnalare il modello e produttore<\/strong> per coordinamento con gli OEM<\/li>\n<\/ol>\n

      Ho usato una query WMI di base per controllare il KEK:<\/p>\n

      Get-WmiObject -Namespace rootcimv2SecurityMicrosoftTpm -ClassName Win32_Tpm<\/code><\/pre>\n
      E poi ho incrociato i dati con i certificati UEFI usando:<\/p>\n
      Get-SecureBootPolicy | Select-Object KEK, DB<\/code><\/pre>\n
      Nel mio inventario ho scoperto:<\/p>\n
        \n
      • 70% dei sistemi:<\/strong> riceveranno l’aggiornamento tramite Windows Update senza intervento<\/li>\n
      • 20% dei sistemi:<\/strong> dispongono di firmware vecchio che richiede un BIOS update da parte dell’OEM<\/li>\n
      • 10% dei sistemi:<\/strong> sono virtual machine Hyper-V, dual-boot Linux, o sistemi air-gapped che necessitano di un piano custom<\/li>\n<\/ul>\n
        Fase 2: Distribuzione Automatica (Aprile-Maggio 2026)<\/h3>\n
        Microsoft sta distribuendo i nuovi certificati tramite gli aggiornamenti mensili di Windows a partire da febbraio 2026.<\/cite> Nel mio ambiente ho forzato la distribuzione tramite Windows Update for Business in questo modo:<\/p>\n
          \n
        1. Ho abilitato una Group Policy su tutto il dominio per forzare Windows Update con scadenza rigida<\/li>\n
        2. Ho schedulato un reboot pianificato fuori dalle ore di lavoro<\/strong> per evitare disruption ai miei team e clienti<\/li>\n
        3. Ho monitorato gli Event Viewer su tutti gli host per i 6 event ID specifici della transizione Secure Boot (104x, 1799, 1808)<\/li>\n<\/ol>\n
          Il processo completo richiede circa 48 ore e uno o pi\u00f9 riavvii per completarsi.<\/cite> Nel mio caso, ho suddiviso il rollout in tre ondate da due settimane, cos\u00ec se la prima ondata mostrava problemi potevo correggere il piano prima della seconda.<\/p>\n
          Fase 3: OEM Coordination e BIOS Update (Marzo-Maggio 2026)<\/h3>\n
          Questa \u00e8 stata la parte pi\u00f9 richiesta di coordinamento. Per i 20% di sistemi con firmware vecchio che non poteva ricevere il certificato 2023 tramite Windows, dovevo contattare direttamente gli OEM.<\/p>\n
          Alcuni sistemi, in particolare quelli pi\u00f9 vecchi, potrebbero richiedere aggiornamenti del firmware OEM.<\/cite><\/p>\n
          Ho stabilito una procedura standard con Dell, HP, e Lenovo:<\/p>\n
            \n
          1. Ho scaricato gli ultimi BIOS\/UEFI per ogni modello dal sito OEM<\/li>\n
          2. Ho testato il BIOS update su una macchina rappresentativa in laboratorio (importante: con BitLocker sospeso)<\/li>\n
          3. Ho creato una flash USB bootable con il firmware OEM<\/li>\n
          4. Ho documentato i passi per il team di desktop support<\/li>\n<\/ol>\n
            Un punto critico qui: Se l’organizzazione ha identificato problemi di aggiornamento Secure Boot, applicare l’ultimo aggiornamento BIOS\/UEFI prima di installare gli aggiornamenti correlati a Secure Boot.<\/cite> Nel mio caso, ho sospeso temporaneamente l’aggiornamento Secure Boot via Windows su quei sistemi finch\u00e9 il BIOS non era stato aggiornato dall’OEM.<\/p>\n
            Fase 4: Zero-Downtime Deployment su Server e Virtual Machine<\/h3>\n
            Qui \u00e8 dove ho visto la vera complessit\u00e0. I miei datacenter enterprise non potevano permettersi un reboot di 30 minuti durante il giorno lavorativo. Ho usato questa strategia:<\/p>\n
            Per server fisici mission-critical:<\/strong><\/p>\n
              \n
            1. Ho schedulato il reboot durante la finestra di manutenzione settimanale (domenica 02:00 UTC)<\/li>\n
            2. Ho usato WSUS per forzare il timing esatto e il reboot, evitando sorprese<\/li>\n
            3. Ho standby un secondo server identico in caso di rollback<\/li>\n
            4. Ho monitorato BitLocker durante il reboot (fondamentale: BitLocker potrebbe richiedere una recovery key se il boot si interrompe male)<\/li>\n<\/ol>\n
              Per Virtual Machine Hyper-V:<\/strong><\/p>\n
              Qui ho scoperto una complicazione imprevista. Le macchine virtuali Azure di generazione 2 configurate con Secure Launch o Trusted Launch dovrebbero gi\u00e0 includere la configurazione del certificato 2023 pi\u00f9 recente. Le macchine virtuali di generazione 1 non supportano Secure Boot e quindi non sono interessate dalla transizione dei certificati.<\/cite> Nel mio caso, avevo VM Gen 2 su Hyper-V on-premises. Ho verificato che ogni VM aveva gi\u00e0 il firmware abilitato per ricevere i certificati 2023, e il reboot \u00e8 stato pulito.<\/p>\n
              Per ambienti dual-boot Windows\/Linux:<\/strong><\/p>\n
              Qui \u00e8 dove la transizione ha impattato pi\u00f9 duramente. Red Hat ha rilasciato nuovi shim, firmati con pi\u00f9 certificati, per tutti i flussi RHEL 9 e RHEL 10 supportati.<\/cite> Ho dovuto coordinare con i team Linux per aggiornare i shim prima che il certificato UEFI 2011 scadesse, altrimenti le VM Linux non avrebbero potuto fare il boot.<\/p>\n
              La Mia Checklist Operativa per Amministratori<\/h2>\n
              Immediatamente (entro questa settimana):<\/strong><\/p>\n
                \n
              • Inventariare tutti i sistemi e verificare chi ha i certificati 2023 gi\u00e0 installati<\/li>\n
              • Scaricare gli ultimi BIOS\/UEFI da tutti gli OEM per i modelli che lo richiedono<\/li>\n
              • Testare in laboratorio la transizione su una macchina rappresentativa per ogni categoria di hardware<\/li>\n
              • Comunicare ai team di supporto il timeline e i possibili impatti<\/li>\n<\/ul>\n
                Entro due settimane:<\/strong><\/p>\n
                  \n
                • Rilasciare la prima ondata di Windows Update Secure Boot per il 30% di sistemi “facili”<\/li>\n
                • Coordinare con gli OEM sugli aggiornamenti BIOS per il 20% di sistemi “difficili”<\/li>\n
                • Per dual-boot, aggiornare prima i shim Linux, poi il certificato Secure Boot Windows<\/li>\n<\/ul>\n
                  Entro tre settimane:<\/strong><\/p>\n
                    \n
                  • Completare la transizione sul 100% dei sistemi non mission-critical<\/li>\n
                  • Pianificare le finestre di reboot per i server mission-critical (fuori da orari lavorativi)<\/li>\n<\/ul>\n
                    A fine maggio 2026 (una settimana prima del deadline):<\/strong><\/p>\n
                      \n
                    • Eseguire un PowerShell audit finale per verificare che il 98%+ dei sistemi abbia i certificati 2023<\/li>\n
                    • Documentare i 2% di sistemi “rimasti indietro” (potrebbero essere server air-gapped, macchine offline da mesi, etc.)<\/li>\n
                    • Se qualche sistema mission-critical rimane indietro, pianificare un intervento manuale urgente prima del 24 giugno<\/li>\n<\/ul>\n
                      I Problemi Che Ho Incontrato (E Come Li Ho Risolti)<\/h2>\n
                      Problema 1: BitLocker e Secure Boot Conflicts<\/strong><\/p>\n
                      Un nostro HP ProBook con BitLocker abilitato ha dato problemi durante la transizione. Il sistema si \u00e8 bloccato a met\u00e0 del processo perch\u00e9 BitLocker non sapeva come fidarsi dei certificati temporaneamente sospesi. Ho risolto sospendendo BitLocker prima<\/em> di avviare l’aggiornamento:<\/p>\n
                      Suspend-BitLocker -MountPoint C: -RebootCount 3<\/code><\/pre>\n
                      Questo sospende BitLocker per i prossimi 3 reboot, permettendo al sistema di fare il boot durante la transizione. Dopo il terzo reboot, BitLocker si riattiva automaticamente.<\/p>\n
                      Problema 2: VM Hyper-V Che Non Ricevevano Gli Aggiornamenti<\/strong><\/n<\/p>\n
                      Su uno dei nostri server Hyper-V, le VM Windows 11 non stavano ricevendo l'aggiornamento Secure Boot via Windows Update anche se abilitato. Ho scoperto che il firewall del server host stava bloccando la connessione WU. Ho dovuto aggiungere una regola di firewall per ogni VM.<\/p>\n
                      Problema 3: Event Viewer Event ID Confusi<\/strong><\/p>\n
                      Microsoft ha aggiunto sei event ID specifici per la transizione: 1801, 1803, 1804, 1808, 1799, 104x. Nel mio primo rollout, un tecnico ha visto l’evento 1801 e ha ipotizzato il fallimento, ma 1801 significa solo “certificato presente.” Ho creato una documentazione interna con il significato di ogni evento ID per evitare false allerte.<\/p>\n
                      FAQ<\/h2>\n
                      Se perdo la scadenza del 24 giugno, il mio PC smetter\u00e0 di accendersi?<\/h3>\n
                      No. Se il deadline arriva e il PC sta ancora usando i certificati 2011, Windows far\u00e0 comunque il boot, Windows Update continuer\u00e0 a funzionare, e il PC continuer\u00e0 a funzionare normalmente.<\/cite> Quello che cambia \u00e8 la capacit\u00e0 di ricevere protezioni di sicurezza future. Non \u00e8 un crash, \u00e8 una deriva verso la vulnerabilit\u00e0<\/strong>.<\/p>\n
                      I certificati 2023 non scadranno di nuovo fra pochi anni?<\/h3>\n
                      I nuovi certificati sono validi fino al 2038, e una transizione separata per la crittografia post-quantistica \u00e8 pianificata per intorno al 2030 per l’hardware futuro.<\/cite> Quindi avete almeno 12 anni, non 15 giorni come con i certificati 2011.<\/p>\n
                      Che succede se ho un sistema Linux in dual-boot?<\/h3>\n
                      Il vostro shim di boot Linux dipende dal certificato UEFI 2011 di Microsoft per fare il boot. Se il vecchio certificato di terze parti 2011 \u00e8 ancora presente, aggiungere il Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023 al suo fianco, quando quel certificato viene revocato o rimosso senza uno shim firmato 2023, Secure Boot Linux smette di fare il boot.<\/cite> Coordinatevi con il vostro team Linux per aggiornare lo shim contemporaneamente.<\/p>\n
                      Devo aggiornare il BIOS del mio PC?<\/h3>\n
                      La maggior parte dei PC moderni riceveranno i certificati tramite Windows Update. Se il vostro BIOS \u00e8 stato aggiornato entro gli ultimi 2 anni, probabilmente no. I PC con BIOS pi\u00f9 vecchi (pre-2023) potrebbero richiedere un aggiornamento manuale dal vostro OEM. Ho suggerito ai clienti di controllare il sito del produttore per vedere se c’\u00e8 un “Secure Boot CA 2023 update” disponibile.<\/p>\n
                      Posso ritardare questo aggiornamento a luglio?<\/h3>\n
                      Tecnicamente s\u00ec, il sistema continuer\u00e0 a funzionare. Ma ogni giorno dopo il 24 giugno siete esposti a una vulnerabilit\u00e0 di bootkit che non pu\u00f2 pi\u00f9 essere rievocata. Se siete in un ambiente altamente regolamentato (finanza, sanit\u00e0, governo), una non-compliant<\/em> a una scadenza ufficiale di Microsoft \u00e8 un red flag per gli auditor. Nel mio consiglio, non fate.<\/p>\n
                      Conclusione: La Migrazione Che Nessuno Vede<\/h2>\n
                      In 15 anni, i certificati Secure Boot 2011 di Microsoft hanno protetto miliardi di dispositivi da rootkit e bootkit. Microsoft li sta sostituendo con quattro nuovi certificati 2023: Microsoft Corporation KEK 2K CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, e Windows UEFI CA 2023.<\/cite><\/p>\n
                      La scadenza di giugno 2026 non \u00e8 il momento in cui i PC “smettono di funzionare.” \u00c8 il momento in cui la fondazione di fiducia del vostro boot cambia<\/strong>, e se non siete pronti, vi ritrovate con una macchina che funziona ma che non pu\u00f2 pi\u00f9 ricevere protezioni future contro le minacce che verranno.<\/p>\n
                      Nel mio ambiente enterprise, la transizione \u00e8 stata pianificata, testata, e distribuita senza downtime significativo. Sono stati due mesi di coordinamento con gli OEM, di testing in laboratorio, di comunicazione ai team. Ma il valore \u00e8 semplice: una finestra di 10 secondi di reboot \u00e8 infinitamente migliore di una vulnerabilit\u00e0 permanente perch\u00e9 si \u00e8 perso un deadline.<\/strong><\/p>\n
                      Se gestite un parco macchine di qualsiasi dimensione, il momento di agire \u00e8 adesso<\/strong>. Se avete domande sulla vostra situazione specifica\u2014VM Hyper-V, dual-boot, air-gap, whatever\u2014lasciate un commento qui sotto. Ho documentato quasi ogni scenario nei miei test, e felicissimo di condividere.<\/p>\n","protected":false},"excerpt":{"rendered":"
                      Windows Secure Boot KEK\/UEFI\/PCA 2011 scade giugno 2026. Niente crash istantanei, ma deriva verso vulnerabilit\u00e0 se non agite. Ecco come ho implementato la transizione zero-downtime nei miei ambienti enterprise con UEFI firmware update, BitLocker, OEM coordination e monitoring.<\/p>\n","protected":false},"author":1,"featured_media":2318,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Windows Secure Boot KEK PCA 2011 Giugno 2026 | Guida Enterprise","_seopress_titles_desc":"Windows Secure Boot certificati KEK\/UEFI\/PCA 2011 scadono giugno 2026. Strategia enterprise zero-downtime: UEFI firmware, BitLocker, OEM coordination, evento ID monitoring. La mia procedura testata.","_seopress_robots_index":"","footnotes":""},"categories":[5],"tags":[965,966,790,964,963],"class_list":["post-2317","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-bios-uefi-update","tag-cybersecurity-infrastructure","tag-enterprise-patching","tag-kek-uefi-certificate","tag-windows-secure-boot"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2317","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=2317"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2317\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2318"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}