Siamo a metà giugno 2026, e ho ricevuto tre telefonate urgenti dai miei clienti enterprise: “Dario, le certificazioni Secure Boot scadono, cosa succede al nostro parco macchine?” La risposta che do a ognuno di loro non è una, ma tre risposte diverse. Perché il deadline di giugno 2026 non è un cliff edge semplice come sembra.
Nel mio laboratorio di test ho visto sistemi che continuavano a bootare normalmente, eppure avevano già perso la capacità di ricevere aggiornamenti di sicurezza a livello firmware. E questo è il vero pericolo: non è un crash istantaneo, è una deriva graduale verso uno stato di sicurezza degradato. 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.
La Scadenza Multipla: KEK, UEFI CA, PCA 2011
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. Quando ho letto per la prima volta questo comunicato di Microsoft, il mio primo istinto è stato errato: pensavo fosse un’unica scadenza, ma sono tre certificati diversi con tre ruoli diversi.
Lasciatemi scomporre cosa significa per un amministratore IT:
- KEK (Key Exchange Key) – 24 giugno 2026: è il certificato che autorizza gli aggiornamenti ai database Secure Boot. Senza questa, non potete più dire al firmware “fidati di questo nuovo certificato.” Il KEK autorizza gli aggiornamenti ai database Secure Boot, che contengono firme consentite e firme revocate.
- UEFI CA 2011 – 27 giugno 2026: 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.
- Windows Production PCA 2011 – 19 ottobre 2026: firma i componenti del bootloader Windows stesso. Il timeline allargato qui è intenzionale da Microsoft.
Nel mio ambiente, ho scoperto che la vera complicazione non è il deadline, ma il fatto che ogni categoria di sistema risponde diversamente alla transizione.
Cosa Succede Davvero al 24 Giugno 2026?
Questo è il punto cruciale dove la comunicazione di Microsoft ha creato confusione. Voglio essere cristallino:
Il dispositivo continuerà a fare il boot normalmente dopo la scadenza, ma entrerà in uno stato di sicurezza degradato dove non è possibile applicare nuove protezioni a livello di boot.
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à più 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à a livello di boot scoperte di recente.
Il vero rischio è questo: fra un mese una nuova vulnerabilità di bootkit esce, Microsoft pubblica una revoca tramite DBX (il database di firme revocate), ma il vostro sistema non può più riceverla perché il KEK è scaduto. Voi continuate a fare il boot, ma siete permanentemente esposti.
La Transizione: Come Ho Pianificato Nei Miei Ambienti Enterprise
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.
Fase 1: Inventario e Classificazione (Febbraio-Marzo 2026)
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:
- Verificare se le nuove certificazioni 2023 sono già presenti (perché le macchine fabbricate dopo 2024 arrivano già con i 2023 CA preinstallati)
- Identificare quali vecchi certificati 2011 sono ancora attivi
- Registrare la versione BIOS/UEFI del firmware per sapere se avrà bisogno di un aggiornamento manuale
- Segnalare il modello e produttore per coordinamento con gli OEM
Ho usato una query WMI di base per controllare il KEK:
Get-WmiObject -Namespace rootcimv2SecurityMicrosoftTpm -ClassName Win32_TpmE poi ho incrociato i dati con i certificati UEFI usando:
Get-SecureBootPolicy | Select-Object KEK, DBNel mio inventario ho scoperto:
- 70% dei sistemi: riceveranno l’aggiornamento tramite Windows Update senza intervento
- 20% dei sistemi: dispongono di firmware vecchio che richiede un BIOS update da parte dell’OEM
- 10% dei sistemi: sono virtual machine Hyper-V, dual-boot Linux, o sistemi air-gapped che necessitano di un piano custom
Fase 2: Distribuzione Automatica (Aprile-Maggio 2026)
Microsoft sta distribuendo i nuovi certificati tramite gli aggiornamenti mensili di Windows a partire da febbraio 2026. Nel mio ambiente ho forzato la distribuzione tramite Windows Update for Business in questo modo:
- Ho abilitato una Group Policy su tutto il dominio per forzare Windows Update con scadenza rigida
- Ho schedulato un reboot pianificato fuori dalle ore di lavoro per evitare disruption ai miei team e clienti
- Ho monitorato gli Event Viewer su tutti gli host per i 6 event ID specifici della transizione Secure Boot (104x, 1799, 1808)
Il processo completo richiede circa 48 ore e uno o più riavvii per completarsi. Nel mio caso, ho suddiviso il rollout in tre ondate da due settimane, così se la prima ondata mostrava problemi potevo correggere il piano prima della seconda.
Fase 3: OEM Coordination e BIOS Update (Marzo-Maggio 2026)
Questa è stata la parte più 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.
Alcuni sistemi, in particolare quelli più vecchi, potrebbero richiedere aggiornamenti del firmware OEM.
Ho stabilito una procedura standard con Dell, HP, e Lenovo:
- Ho scaricato gli ultimi BIOS/UEFI per ogni modello dal sito OEM
- Ho testato il BIOS update su una macchina rappresentativa in laboratorio (importante: con BitLocker sospeso)
- Ho creato una flash USB bootable con il firmware OEM
- Ho documentato i passi per il team di desktop support
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. Nel mio caso, ho sospeso temporaneamente l’aggiornamento Secure Boot via Windows su quei sistemi finché il BIOS non era stato aggiornato dall’OEM.
Fase 4: Zero-Downtime Deployment su Server e Virtual Machine
Qui è dove ho visto la vera complessità. I miei datacenter enterprise non potevano permettersi un reboot di 30 minuti durante il giorno lavorativo. Ho usato questa strategia:
Per server fisici mission-critical:
- Ho schedulato il reboot durante la finestra di manutenzione settimanale (domenica 02:00 UTC)
- Ho usato WSUS per forzare il timing esatto e il reboot, evitando sorprese
- Ho standby un secondo server identico in caso di rollback
- Ho monitorato BitLocker durante il reboot (fondamentale: BitLocker potrebbe richiedere una recovery key se il boot si interrompe male)
Per Virtual Machine Hyper-V:
Qui ho scoperto una complicazione imprevista. Le macchine virtuali Azure di generazione 2 configurate con Secure Launch o Trusted Launch dovrebbero già includere la configurazione del certificato 2023 più recente. Le macchine virtuali di generazione 1 non supportano Secure Boot e quindi non sono interessate dalla transizione dei certificati. Nel mio caso, avevo VM Gen 2 su Hyper-V on-premises. Ho verificato che ogni VM aveva già il firmware abilitato per ricevere i certificati 2023, e il reboot è stato pulito.
Per ambienti dual-boot Windows/Linux:
Qui è dove la transizione ha impattato più duramente. Red Hat ha rilasciato nuovi shim, firmati con più certificati, per tutti i flussi RHEL 9 e RHEL 10 supportati. 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.
La Mia Checklist Operativa per Amministratori
Immediatamente (entro questa settimana):
- Inventariare tutti i sistemi e verificare chi ha i certificati 2023 già installati
- Scaricare gli ultimi BIOS/UEFI da tutti gli OEM per i modelli che lo richiedono
- Testare in laboratorio la transizione su una macchina rappresentativa per ogni categoria di hardware
- Comunicare ai team di supporto il timeline e i possibili impatti
Entro due settimane:
- Rilasciare la prima ondata di Windows Update Secure Boot per il 30% di sistemi “facili”
- Coordinare con gli OEM sugli aggiornamenti BIOS per il 20% di sistemi “difficili”
- Per dual-boot, aggiornare prima i shim Linux, poi il certificato Secure Boot Windows
Entro tre settimane:
- Completare la transizione sul 100% dei sistemi non mission-critical
- Pianificare le finestre di reboot per i server mission-critical (fuori da orari lavorativi)
A fine maggio 2026 (una settimana prima del deadline):
- Eseguire un PowerShell audit finale per verificare che il 98%+ dei sistemi abbia i certificati 2023
- Documentare i 2% di sistemi “rimasti indietro” (potrebbero essere server air-gapped, macchine offline da mesi, etc.)
- Se qualche sistema mission-critical rimane indietro, pianificare un intervento manuale urgente prima del 24 giugno
I Problemi Che Ho Incontrato (E Come Li Ho Risolti)
Problema 1: BitLocker e Secure Boot Conflicts
Un nostro HP ProBook con BitLocker abilitato ha dato problemi durante la transizione. Il sistema si è bloccato a metà del processo perché BitLocker non sapeva come fidarsi dei certificati temporaneamente sospesi. Ho risolto sospendendo BitLocker prima di avviare l’aggiornamento:
Suspend-BitLocker -MountPoint C: -RebootCount 3Questo 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.
Problema 2: VM Hyper-V Che Non Ricevevano Gli Aggiornamenti</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.
Problema 3: Event Viewer Event ID Confusi
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.
FAQ
Se perdo la scadenza del 24 giugno, il mio PC smetterà di accendersi?
No. Se il deadline arriva e il PC sta ancora usando i certificati 2011, Windows farà comunque il boot, Windows Update continuerà a funzionare, e il PC continuerà a funzionare normalmente. Quello che cambia è la capacità di ricevere protezioni di sicurezza future. Non è un crash, è una deriva verso la vulnerabilità.
I certificati 2023 non scadranno di nuovo fra pochi anni?
I nuovi certificati sono validi fino al 2038, e una transizione separata per la crittografia post-quantistica è pianificata per intorno al 2030 per l’hardware futuro. Quindi avete almeno 12 anni, non 15 giorni come con i certificati 2011.
Che succede se ho un sistema Linux in dual-boot?
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 è 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. Coordinatevi con il vostro team Linux per aggiornare lo shim contemporaneamente.
Devo aggiornare il BIOS del mio PC?
La maggior parte dei PC moderni riceveranno i certificati tramite Windows Update. Se il vostro BIOS è stato aggiornato entro gli ultimi 2 anni, probabilmente no. I PC con BIOS più 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’è un “Secure Boot CA 2023 update” disponibile.
Posso ritardare questo aggiornamento a luglio?
Tecnicamente sì, il sistema continuerà a funzionare. Ma ogni giorno dopo il 24 giugno siete esposti a una vulnerabilità di bootkit che non può più essere rievocata. Se siete in un ambiente altamente regolamentato (finanza, sanità, governo), una non-compliant a una scadenza ufficiale di Microsoft è un red flag per gli auditor. Nel mio consiglio, non fate.
Conclusione: La Migrazione Che Nessuno Vede
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.
La scadenza di giugno 2026 non è il momento in cui i PC “smettono di funzionare.” È il momento in cui la fondazione di fiducia del vostro boot cambia, e se non siete pronti, vi ritrovate con una macchina che funziona ma che non può più ricevere protezioni future contro le minacce che verranno.
Nel mio ambiente enterprise, la transizione è 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 è semplice: una finestra di 10 secondi di reboot è infinitamente migliore di una vulnerabilità permanente perché si è perso un deadline.
Se gestite un parco macchine di qualsiasi dimensione, il momento di agire è adesso. Se avete domande sulla vostra situazione specifica—VM Hyper-V, dual-boot, air-gap, whatever—lasciate un commento qui sotto. Ho documentato quasi ogni scenario nei miei test, e felicissimo di condividere.