Mancano poche settimane al 24 giugno 2026: la scadenza critica dei certificati Secure Boot Microsoft originali del 2011. Nella mia esperienza da System Administrator, questa è una delle sfide infrastrutturali più complesse che affronterò questo anno – non perché i sistemi “si rompano all’improvviso”, ma perché la degradazione della sicurezza avviene gradualmente, silenziosamente. I dispositivi continueranno a bootare, continueranno a ricevere aggiornamenti standard, ma perderanno la capacità di ricevere protezioni Secure Boot future, revocation lists (DBX), e mitigazioni per vulnerabilità bootkit scoperte dopo la scadenza.
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à di Hyper-V e VMs, e mitigare i rischi per sistemi legacy che non possono transizionare.
Il Problema: Cosa Scade Veramente il 24 Giugno 2026
Tre certificati specifici sono coinvolti: Microsoft Corporation KEK CA 2011 scade il 24 giugno 2026. Accanto a questi scadono anche Microsoft Corporation UEFI CA 2011 nel giugno 2026, e Microsoft Windows Production PCA 2011 nel ottobre 2026.
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. Tuttavia, questi dispositivi non saranno più 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à bootkit scoperte di recente.
Nel mio laboratorio, questo significa: un server Windows Server 2022 che rimane sui certificati 2011 dopo giugno 2026 continuerà a bootare, ma non riceverà mai gli aggiornamenti DBX che Microsoft distribuirà in autunno per mitigare nuove vulnerabilità bootkit. È una **degradazione progressiva della sicurezza**, non un crash improvviso.
La Mia Enterprise Inventory Strategy: Capire Cosa Abbiamo
Il primo passo – e il più noioso – è sapere esattamente quali sistemi hanno Secure Boot abilitato e quale certificato versione è attualmente nel firmware. Ho sviluppato una procedura PowerShell per scansionare la flotta in modo centralizzato.
Step 1: Verificare lo stato Secure Boot con PowerShell
Su un singolo dispositivo, eseguo:
Get-SecureBootUEFI -Variable db
Questo comando legge direttamente il database UEFI firmware. Cerco la presence di “Windows UEFI CA 2023” e “Microsoft Corporation KEK CA 2023”. Se il risultato contiene SOLO i certificati 2011, il dispositivo è candidato prioritario per l’aggiornamento.
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”).
Step 2: Inventario Centralizzato su Intune
Un nuovo report di stato Secure Boot è 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.
Nel nostro tenant Intune, ho configurato il report di conformità 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à è oro puro quando devo comunicare il rischio al board.
Step 3: Windows Server – Manuale Obbligatorio
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.
Nel mio ambiente, ho i seguenti server che necessitano di attenzione:
- 3x Windows Server 2022 fisici (hypervisor Hyper-V)
- 1x Windows Server 2019 (legacy application server, Extended Security Updates)
- 15x Hyper-V Gen 2 VMs (mix di 2019, 2022, 2025)
- 2x failover cluster nodes
Per ciascuno, non posso contare su Windows Update. Devo forzare manualmente l’aggiornamento tramite registry key o GPO.
OEM Coordination: Il Ruolo Fondamentale dei Firmware Update
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.
Nella mia pratica:
- Dell PowerEdge: 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.
- HP ProLiant: HP ha pubblicato una guida specifica. Alcuni firmware HP hanno un bug dove i certificati KEK non vengono scritti correttamente se il BIOS è vecchio. Sono in contatto con il supporto HP per i miei 3 server G10.
- Lenovo/ThinkSystem: Relativamente tranquillo. Hanno fornito firmware updates che pre-caricano i certificati 2023.
Molti server più recenti costruiti dal 2024, e quasi tutti quelli rilasciati nel 2025, sono già 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.
Il mio consiglio: non fare niente fino a quando non hai confermato il firmware version supportato dal tuo OEM. Un aggiornamento fuori ordine può lasciare un server in uno stato di recovery incomprensibile.
Deployment Method: Registry Key vs. Intune vs. Group Policy
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.
Nel mio ambiente ibrido, sto usando una strategia multilivello:
Per Windows 11 Client (managed via Intune):
Ho abilitato la diagnostica Microsoft (registry key UEFICA2023NotifyAvailable = 0x5944) 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à. Questa opzione è abilitata per impostazione predefinita per i dispositivi pronti per nuovi certificati. Microsoft aggiornerà questi dispositivi per me a meno che non rinunci.
Per Windows Server (managed manually):
Ho creato uno script PowerShell che:
- Verifica se il certificato 2023 è già nel firmware (get-securebootuefi)
- Se assente, imposta la registry key
HKLM:SYSTEMCurrentControlSetControlSecureBootStateUEFICA2023NotifyAvailablea0x5944 - Attende il completamento della task schedulata
Secure-Boot-Update(che gira ogni 12 ore) - Riavvia il server se logga Event ID 1800 (reboot required)
- Verifica il risultato controllando
UEFICA2023Statusregistry key (dovrebbe leggere “updated”)
Se Windows rileva che è 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.
Per Windows Server 2022+ in ambito Hyper-V:
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à.
Nel mio lab Hyper-V, ho imparato questa lezione nel modo più duro: ho aggiornato una VM guest senza aggiornare prima l’host, e la VM si è bloccata nello stato di update. Ora uso un checklist coordinato: host prima, attendi, poi guests.
Risk Mitigation: Cosa Fare se Non Riesco a Transizionare In Tempo
Non tutti i sistemi possono transizionare prima di giugno 2026. Nel mio ambiente, ho alcuni candidati problematici:
Hardware Legacy Senza Supporto OEM
Devo documentare i dispositivi che non possono essere aggiornati. L’hardware più 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.
Nel mio caso, ho 2 vecchi PC Lenovo ThinkCentre mini da 2015 che rimangono in uso per controllo di laboratorio. Non c’è 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.
Legacy BIOS vs. UEFI Secure Boot
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. Fortunatamente, non ho più sistemi legacy BIOS in produzione.
BitLocker Complication
Se temporaneamente disabilito Secure Boot per bypassare il problema del certificato, BitLocker entrerà in modalità di ripristino al prossimo avvio – presentando la chiave di ripristino a 48 cifre. In grandi flotte, inserire manualmente le chiavi di ripristino per centinaia di dispositivi è un incubo dell’helpdesk. L’aggiornamento preventivo evita questo del tutto.
Ho una politica: non disabilitare mai Secure Boot come workaround. Invece, test prima su un subset di sistemi, identifica il problema (firmware, BIOS, driver), risolvi, poi procedi.
Timeline di Distribuzione: Il Mio Piano di Rollout
Nel mio ambiente, sto seguendo questa strategia fasata:
- Maggio 2026 (NOW – prossime 3 settimane): Completamento dell’inventario. Identificazione dei sistemi problematici. Contatto con OEM per firmware updates. Piloting su rappresentanza piccolo di sistemi per ciascun produttore.
- Inizio Giugno 2026: Rollout graduale su Windows 11 clients tramite Intune. Aggiornamento manuale di Windows Server durante finestre di manutenzione (uno per settimana per mitigare rischio).
- Mid-Giugno 2026: Validazione di Hyper-V hosts + guests. Testing di failover cluster. Backup pre-aggiornamento di tutti i sistemi critici.
- Fine Giugno 2026: Completamento dei sistemi residui. Documentazione di qualsiasi eccezione o dispositivo non transitioning.
Monitoring e Troubleshooting: Event Viewer è il Tuo Amico
Se Event Viewer Windows Logs for System registra un Event ID 1795, significa che c’è stato un errore quando Windows ha tentato di passare i certificati al firmware. Devo controllare con l’OEM per vedere se è disponibile un aggiornamento firmware per il dispositivo per risolvere questo problema.
Nel mio monitoraggio, sto tracciando:
- Event ID 1808: Evento informativo che indica che il dispositivo ha i certificati Secure Boot 2023 richiesti applicati al firmware del dispositivo.
- Event ID 1800: Reboot richiesto per completare l’aggiornamento boot manager.
- Event ID 1795: Errore firmware – necessaria azione OEM.
- Registry Key UEFICA2023Error: Se esiste, significa che c’è un errore in sospeso.
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”.
FAQ
Se ignoro la scadenza di giugno 2026, il mio PC semplicemente non si avvierà il giorno dopo?
No, questo è un malinteso comune. La frase “inizia a giugno” ha importanza. Non è un countdown cinematico in cui ogni PC non patchato diventa inutile a mezzanotte del 1° giugno 2026. La guida stessa di Microsoft è più misurata: i dispositivi interessati possono continuare a bootare e possono continuare a ricevere aggiornamenti standard di Windows, ma possono perdere la capacità di ricevere protezioni Secure Boot future per i componenti di early boot. Questa distinzione è importante perché separa il degrado della sicurezza dal fallimento istantaneo.
Windows Server riceverà gli aggiornamenti automaticamente come Windows 11?
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. Devi distribuire manualmente su ogni server.
Posso testare l’aggiornamento su una piccola flotta prima del rollout completo?
Assolutamente. Microsoft consiglia di testare almeno quattro dispositivi per ciascuna combinazione univoca di produttore/modello/firmware. Nel mio ambiente, ho scelto 2 rappresentanti per ogni OEM (Dell, HP, Lenovo) e 1 per architetture virtuali (Hyper-V Gen 2).
E se il mio server Hyper-V non si avvia dopo l’aggiornamento?
La causa più comune è 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. Assicurati di aggiornare l’host PRIMA della guest.
Cosa succede ai miei sistemi legacy che non hanno un firmware update disponibile dall’OEM?
I dispositivi che non sono transitati ai certificati di firma 2023 e ai nuovi materiali chiave perderanno gradualmente la capacità 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. La mia strategia è 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.
Conclusione: Il Conteggio Alla Rovescia è Reale
Abbiamo meno di un mese prima del 24 giugno 2026. Nel mio ruolo di System Administrator, questa non è una patch “Patch Tuesday” ordinaria – è 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.
La buona notizia: Molti OEM hanno pre-provvisionato certificati aggiornati su nuovi dispositivi e molti PC più recenti costruiti dal 2024, e quasi tutti i dispositivi spediti nel 2025, includono già i certificati e non richiedono alcuna azione dai clienti.
La difficoltà: Windows Server richiede azione manuale, Hyper-V ha bug di coordin inediti, e l’hardware legacy senza supporto OEM rimarrà in uno stato di sicurezza degradato.
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. Non aspettare fino al 23 giugno – i helpdesk saranno in chaos.
Che cosa stai facendo nel tuo ambiente? Hai già iniziato il transition? Lascia un commento qui sotto – mi piacerebbe sentire come altri amministratori stanno affrontando questa scadenza.