La scadenza del 24 giugno 2026 per il certificato Microsoft Corporation KEK CA 2011 non è 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 è stata la data limite in sé, ma quello che è arrivato dopo: coordinare OEM che offrono update tardivi, gestire sistemi in air-gap, troubleshootare Hyper-V template obsoleti, e soprattutto mantenere la continuità operativa senza ricadere su soluzioni “disabilita Secure Boot” che creano altre vulnerabilità.
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 è una semplice Windows Update: è 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ù revocation updates DBX, esponendo la tua infrastruttura a exploit come BlackLotus indefinitamente.
La Situazione Reale Post-24 Giugno 2026: Cosa Non Vi Raccontano
Quando il KEK CA 2011 è scaduto, ho osservato tre comportamenti distinti nei device aziendali:
- Device “silenziosamente all’indietro”: 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.
- Device con firmware OEM bloccato: 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ò completare la transizione.
- Device di transizione corretta: Sistemi che hanno ricevuto firmware OEM aggiornato + Windows Update, e ora supportano sia i certificati 2011 (legacy) che 2023 (moderni) nel firmware.
Il problema critico è 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. Questo non è una vulnerabilità teorica: è una apertura permanente verso attacchi pre-OS come Kernel-mode rootkit via bootkit inoculato prima che Secure Boot possa verificarlo.
Step-by-Step: La Mia Procedura Zero-Downtime per Enterprise
Fase 1: Asset Inventory e Firmware Readiness (Settimane 1-2)
Non basta dire “tutti i device hanno Secure Boot abilitato”. Devi sapere:
- Quale certificato è attualmente nel firmware di ogni device (2011, 2023, o dual)
- Quale versione firmware ha ogni device
- Se l’OEM ha rilasciato firmware update con supporto 2023 per quel modello
- Se il firmware è supportato o end-of-service
Io ho usato PowerShell per scannerizzare il registro su tutti i device (tramite Intune Report o Configuration Manager):
$RegistryPath = "HKLM:SYSTEMCurrentControlSetControlSecureBootServicing"
$Status = Get-ItemProperty -Path $RegistryPath -Name UEFICA2023Status -ErrorAction SilentlyContinue
$Error = Get-ItemProperty -Path $RegistryPath -Name UEFICA2023Error -ErrorAction SilentlyContinue
[PSCustomObject]@{
ComputerName = $env:COMPUTERNAME
SecureBootStatus = $Status.UEFICA2023Status
HasError = $Error.UEFICA2023Error
Timestamp = Get-Date
}
Questo ti mostra il valore UEFICA2023Status che può essere:
- “Not Started” – Device non ha ancora tentato l’update
- “In Progress” – Update in corso (attendi, non riavviare)
- “Updated” – Certificati 2023 sono installati nel firmware
Se vedi UEFICA2023Error, significa che c’è stato un errore quando Windows ha tentato di passare i certificati al firmware: verifica con l’OEM se c’è un update firmware disponibile per il device.
Fase 2: OEM Firmware Coordination (Settimane 2-6)
Questo è dove la maggior parte dei problemi emergono. Nel mio ambiente:
- Dell PowerEdge: Generazioni 14-16 ricevono firmware fino a fine 2025. Generazioni 12-13 = end-of-service, nessun update.
- HP ProBook/EliteBook: Support varia per serie; devo verificare caso per caso su hp.com/support
- Lenovo ThinkPad: Psych Lenovo rilascia firmware update per modelli 2019+, ma 2017-2018 è borderline.
Per device end-of-service (Dell PowerEdge 12-13 gen, HP forti del 2016), l’unica strada è accettare il rischio e abilitare un’eccezione di compliance, oppure pianificare la sostituzione hardware. Non existe un compromesso di sicurezza accettabile qui.
Ho creato una matrice di rischio:
- Tier 1 (Verde): Device con firmware OEM aggiornato + certificati 2023 già presenti. Zero rischio. Nessun’azione.
- Tier 2 (Giallo): Device con firmware vecchio ma OEM supporta ancora il modello. Piano: firmware update + Windows Update coordinati.
- Tier 3 (Rosso): End-of-service, nessun firmware disponibile. Piano: replacement hardware o eccezione scritta con mitigazioni compensative (air-gap, isolamento rete, monitoraggio EDR intensivo).
Fase 3: Staged Deployment di Windows + Firmware Updates (Settimane 4-12)
Questo è 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ù device di esempio.
Il mio approccio (che ho usato con successo):
- Pilot Wave 1: 4-5 device per ogni combinazione OEM/Modello/Firmware. Monitoraggio quotidiano per 2 settimane post-update.
- Verifico Event ID 1808 (indicatore di certificati applicati con successo)
- Monitoraggio BitLocker – a volte le transizioni di fiducia del firmware possono triggerare BitLocker recovery (ho visto questo accadere 2-3 volte)
- Test boot da media recovery per assicurarsi che WinPE e imaging tools funzionino ancora
- Firmware OEM First: Non applicare Windows Update finché il firmware non è aggiornato. Se il firmware è vecchio, il firmware potrebbe non accettare i certificati 2023 anche se Windows Update li invia. L’ordine conta: Firmware → Windows Update.
- Registry Key Control: Usa il registry key HKLM:SYSTEMCurrentControlSetControlSecureBootServicing per controllare manualmente il deployment via Group Policy o Intune, non fare affidamento automatico su Windows Update.
- Imposta MicrosoftUpdateManagedOptIn = 1 solo dopo il firmware update è verificato come riuscito
- Usa HighConfidenceOptOut = 0 per device che rientrano nella categoria Microsoft “high-confidence” (apparecchi recenti con firmware moderno)
- Monitoraggio post-update: Aspetta 1-2 cicli di refresh della scheduled task (ogni 12 ore) prima di procedere al prossimo wave.
- La scheduled task MicrosoftWindowsPISecure-Boot-Update tenta l’update ogni 12 ore
- La scheduled task Secure-Boot-Update è 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 è impostato su un valore non zero
Firmware Compatibility Troubleshooting: I Problemi Che Ho Incontrato
Problema 1: Event ID 1795 – Firmware Write-Protected o Incompatibile
Situazione: Device mostra Event ID 1795 in Event Viewer (System log).
Causa: Se Event Viewer Windows Logs registra Event ID 1795, significa che c’è stato un errore quando Windows ha tentato di passare i certificati al firmware. Verifica con l’OEM se c’è un firmware update disponibile per il device.
Soluzione (dalla mia esperienza):
- Verifica che Secure Boot sia abilitato nel firmware (UEFI setup)
- Scarica il firmware OEM più recente (sì, ancora prima di Windows Update)
- Applica il firmware update (in genere è un .exe per Windows, o una procedura BIOS manual boot)
- Forza il retry della scheduled task manualmente:
schtasks.exe /Run /TN "MicrosoftWindowsPISecure-Boot-Update" /I - Attendi 2-3 cicli (24-36 ore) e ri-controlla il registry per verificare che UEFICA2023Status sia “Updated”
Problema 2: Hyper-V Virtual Machine e EDK2-OVMF Template Obsoleti
Situazione: VMs Hyper-V create da template datati non hanno i certificati 2023.
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.
Soluzione (ho testato questo):
- Aggiorna EDK2-OVMF sull’host Hyper-V: 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.
- VM Hyper-V esistenti: Se una VM è già creata con firmware vecchio, Windows Update dentro la VM può comunque installare i certificati 2023, ma solo se sia l’host che il guest hanno l’update di marzo 2026+. 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.
- VM nuove: Assicurati di creare nuove VMs dopo che l’host ha ricevuto l’update. Erediteranno automaticamente il firmware con certificati 2023.
Problema 3: Air-Gapped Systems Senza Windows Update
Situazione: Device in ambienti air-gap, staccati da internet, non ricevono Windows Update.
Causa: Senza Windows Update, il device non riceve i certificati 2023, né il firmware OEM update può raggiungerlo.
Soluzione (manuale, ma testata):
- Scarica offline l’update di Windows: Ottieni il .cab file specifico per il tuo Windows release dai Microsoft Update servers (tramite WSUS offline o direct download).
- Applica manualmente via PowerShell Remoting (se disponibile) o tramite media USB:
Add-WindowsPackage -Online -PackagePath C:pathtosecure-boot-update.cab - Firmware update separato: Se il device ha anche bisogno di firmware update OEM, applica quello tramite media USB o recovery environment.
Questa operazione è molto delicata: se interrompi un firmware update, il device potrebbe non bootare. Assicurati di una finestra di manutenzione, power backup, e recovery media disponibile.
OEM Coordination Strategy per Enterprise
Se gestisci una flotta di migliaia di device da più OEM, ecco come coordinare:
- Crea una tabella di supporto OEM:
OEM Modello Generazione Firmware Disponibile? Data rilascio Status Note Dell PowerEdge 16 (2U) Gen 16 Sì Dec 2025 Verified Tier 1 – Deploy immediately Dell PowerEdge 12 Gen 12 No End of Service Exception Tier 3 – Replacement planned HP ProBook 450 G8 Gen 8 Sì May 2026 Pilot Tier 2 – Testing in progress - Contatta gli OEM direttamente per Tier 3: Scrivi a Dell, HP, Lenovo support con specifiche di device (serial number range, asset tag) per confermare se supporto è disponibile. Molti OEM hanno canali enterprise per supporto firmware bulk.
- Usa WSUS / Windows Update for Business per coordinamento centralizzato: 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.
Esempio di Group Policy:
Computer Configuration → Administrative Templates → System → Windows Update → "Certificate Deployment via Controlled Feature Rollout"Impostazione su “Enabled” ti permette di usare ConfigMgr o Intune per un rollout controllato.
Verifica Post-Rollover: Come Confermare il Successo
Non è sufficiente dire “Secure Boot è abilitato”. Devi verificare che i certificati 2023 siano effettivamente nel firmware.
Check 1: Registry Status
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecureBootServicing" | Select UEFICA2023Status, UEFICA2023Error
Aspetta “Updated”. Se vedi “Not Started” o “In Progress”, il device non ha completato ancora.
Check 2: Event Log – Event ID 1808
Get-WinEvent -FilterHashtable @{LogName="System"; ID=1808} | Select TimeCreated, Message | Sort TimeCreated -Descending | Select -First 5
L’evento informativo 1808 nel System Event Log indica che il device ha i certificati Secure Boot 2023 richiesti applicati nel firmware del device.
Check 3: Windows Security App (GUI Visual)
Naviga in Windows Security → Device Security → Secure Boot. Dovrebbe mostrare un checkmark verde con “Fully updated” se i certificati 2023 sono presenti.
Se mostra yellow warning o red alert, il device ha bisogno ancora di azione.
Problemi Specifici Post-24 Giugno: Cosa Continuare a Monitorare
Frozen DBX State
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:
- Nessun nuovo bootkit può essere revocato nel DBX
- Nessun nuovo boot component compromise può essere blacklisted a livello firmware
- Attacchi pre-OS (come quelli di BlackLotus) rimangono non rilevati se il loro bootkit hash non era già nel DBX
Questa è una vulnerabilità permanente finché il device non riceve il firmware/certificato update.
Linux Boot Compatibility
Se ami Ubuntu Server, RHEL, Rocky, o Linux in generale: Una volta che la chiave 2011 scade, qualsiasi nuovo binary shim sarà 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.
Se gestisci server Linux: verifica con il tuo OS vendor (Red Hat ha già rilasciato shim aggiornato per RHEL 8/9/10) che il boot loader sia compatibile con la tua attuale Secure Boot setup.
Third-Party Boot Utilities e Recovery Media
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.
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.
FAQ
Il mio PC bootà ancora dopo il 24 giugno 2026 anche se non ho i certificati 2023?
Sì, il PC continuerà a bootare e Windows funzionerà 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à stata sostituita. Se quella sostituzione non accade in modo pulito, la modalità di guasto è ritardata, sottile e rilevante per la sicurezza, piuttosto che drammatica.
Cosa accade se disabilito Secure Boot per evitare il problema?
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à e tooling di sicurezza. La soluzione giusta è aggiornare, non disabilitare.
Quanto tempo impiega Windows Update a installare i certificati 2023?
Varia, ma una scheduled task permette a Windows di tentare questi aggiornamenti quando il sistema è in uno stato dove le variabili del firmware possono essere modificate. La pianificazione ricorrente di 12 ore fornisce opportunità aggiuntive per ritentare gli aggiornamenti se un tentativo precedente è fallito o se il device è rimasto acceso senza riavviarsi. Questo design aiuta a garantire il progresso in avanti senza richiedere intervento manuale. In media: 2-7 giorni con reboot naturali inclusi.
Come faccio a forzare l’update immediato senza aspettare Windows Update?
Puoi triggerare manualmente la scheduled task:
schtasks.exe /Run /TN "MicrosoftWindowsPISecure-Boot-Update" /I
Poi controlla il registry ogni 12 ore per il cambio di stato UEFICA2023Status.
Se l’OEM non ha rilasciato firmware con certificati 2023, cosa faccio?
Se il device è end-of-service e l’OEM non rilascia firmware: hai tre opzioni:
- Accettare il rischio residuo (device bootabile, ma congelato su DBX pre-giugno 2026)
- Pianificare la sostituzione hardware per quel device
- Implementare compensative controls (EDR aggressivo, network segmentation, air-gap parziale)
Non c’è una soluzione tecnica pura. La decisione è di risk management e compliance.