Siamo nel pieno della transizione Secure Boot di giugno 2026, e nella mia esperienza gestendo flotte enterprise, ho visto succedere di tutto: macchine bloccate su schermi neri di BitLocker, fallimenti Secure Boot silenti che lasciano i dispositivi senza protezioni al boot, e persino situazioni in cui le password di recovery non erano accessibili. Non è un panic—il sistema continua a funzionare—ma la finestra di vulnerabilità si allarga ogni giorno. Vi mostro esattamente come diagnosticare e risolvere questi problemi con procedure testate sul campo.
Il Contesto: Certificati Secure Boot 2011 vs 2023
In giugno 2026, i certificati Secure Boot spediti in Windows dal 2011 cominciano a scadere, e Microsoft li sostituisce con un nuovo set di certificati datati 2023. Questo potrebbe verificarsi già da giugno 2026, quando alcuni dei certificati Secure Boot attuali iniziano a scadere.
La confusione principale che incontro nei clienti: credono che il sistema non bootterà affatto. Sbagliato. Se il deadline arriva e il tuo PC è ancora in esecuzione sui certificati 2011, Windows bootterà comunque, Windows Update continuerà a funzionare, e il tuo PC continuerà a funzionare normalmente. Il vero problema è sottile ma critico: il dispositivo “non sarà più in grado di ricevere nuove protezioni di sicurezza” per il processo di early boot, inclusi aggiornamenti a Windows Boot Manager, database Secure Boot, liste di revoca e mitigazioni per vulnerabilità appena scoperte al livello di boot.
Il Problema Reale: BitLocker Trigger durante gli Update
Nel maggio e giugno 2026, ho affrontato il scenario peggiore: aggiornamenti Windows 11 KB5094126, Build 26200.8655, rilasciati il 9 giugno 2026, hanno causato fallimenti di boot, loop di recovery BitLocker, errori Secure Boot, e integrazione cloud storage rotta su alcuni PC, specialmente sistemi business HP. Ho gestito una situazione con 300 macchine, dove 42 non hanno bootato il mattino dopo.
Il meccanismo è questo: quando lo stato Secure Boot, le misurazioni firmware, o i file di boot cambiano inaspettatamente, BitLocker potrebbe rifiutarsi di fidarsi dell’ambiente e richiedere la chiave di recovery.
In un’azienda ben gestita, le chiavi di recovery dovrebbero essere depositate in Entra ID, Active Directory o Intune. Nei clienti con account locali? Disastro. Le distribuzioni corporate che usano account locali—macchine che non sono mai state collegate a un Microsoft Account—non hanno alcun meccanismo automatico di backup della chiave. Multipli utenti su forum Microsoft Q&A hanno confermato che lo strumento di supporto assistito da AI di Microsoft ha fornito un verdetto inequivocabile: senza una chiave di recovery salvata, l’unica risoluzione disponibile è una completa cancellazione del sistema operativo e reinstallazione di Windows.
Mia Procedura: Secure Boot Certificate Status Check (Fase 1)
Prima di deployare un singolo KB, eseguo sempre questo audit su una macchina test per ogni modello hardware/firmware unico:
- Controlla il PCR7 Binding Status:
- Apri msinfo32.exe come amministratore
- Vai a System Summary
- Cerca “Secure Boot State PCR7 Binding”
- Se mostra “Binding Not Possible“, il dispositivo è a rischio se hai una BitLocker Group Policy custom con PCR7
- Verifica lo stato Secure Boot dalla GUI:
- Windows Security > Device security > Secure Boot
- Un badge verde significa certificati 2023 già applicati
- Badge giallo = aggiornamento in progress o bloccato
- Badge rosso = azione richiesta, firmware non supportato il 2023 KEK
- Controlla lo stato dei certificati tramite PowerShell:
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecureBootState" -Name "UEFICA2023Status"
Valori corretti: “updated”. Se non esiste la chiave, il certificato non è stato consegnato.
Procedura Secure Boot Certificate Deployment (Fase 2)
La consegna è stratificata. Microsoft sta usando un rollout a fasi progettato per evitare di rompere i sistemi. Un task Windows pianificato viene eseguito pressappoco ogni 12 ore e applica l’aggiornamento in fasi: aggiungere il nuovo Windows UEFI CA 2023 al database delle firme del firmware. Se il vecchio certificato di terze parti 2011 è ancora presente, aggiungere il Microsoft UEFI CA 2023 e il Microsoft Option ROM UEFI CA 2023 accanto ad esso.
Nel mio ambiente Intune gestito, uso questa strategia di remediazione (basata su esperienza reale di deployment in March-June 2026):
# PowerShell Remediation per Intune - Fase 1: Opt-in a Microsoft Update Managed
reg add "HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesWindowsUpdate" /v "MicrosoftUpdateManagedOptIn" /t REG_DWORD /d 0x5944 /f
# Fase 2: Trigger Secure Boot certificate scan
WUAuclt.exe /UpdateNow
# Fase 3: Monitor Stage nel registry
$stage = (Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecureBootState" -Name "UEFICA2023Status" -ErrorAction SilentlyContinue).UEFICA2023Status
if ($stage -eq "updated") {
Write-Output "Stage 5: Compliant"
exit 0
} else {
Write-Output "Stage $stage: Remediation needed"
exit 1
}
Il segreto: non mescolare i metodi di deployment sulla stessa macchina. Scegli un metodo di deployment per dispositivo. Usa chiavi di registro, Group Policy, strumenti da linea di comando WinCS, o script Intune/ConfigMgr, ma non mescolare i metodi sulla stessa macchina.
BitLocker Compatibility Check (Pre-Update Triage)
Prima di qualsiasi update, audit questi scenari ad alto rischio:
Scenario 1: BitLocker con PCR7 Policy personalizzata
Controlla Group Policy:
gpresult /h gpreport.html | findstr /i "Configure TPM platform validation"
Se è impostata “Configure TPM platform validation profile for native UEFI firmware configurations” e include PCR7, il sistema deve soddisfare TUTTI questi requisiti: BitLocker è abilitato sul drive OS, la Group Policy “Configure TPM platform validation profile for native UEFI firmware configurations” è impostata e include esplicitamente PCR7. Questo combina il rischio.
Mitigation pre-update:
- Documenta la GPO corrente
- Rimuovi PCR7 dalla GPO prima di deployare l’update
- Applica gpupdate /force /sync
- Reboot per verificare che BitLocker rimane intatto
- Deploy l’update
- Dopo il reboot post-update, ripristina la GPO originale (se davvero necessaria)
Scenario 2: EFI Partition Low Space
Controlla se hai abbastanza spazio libero nella partizione EFI. Se non ce l’hai, consiglio di redimenionarla. È necessario per alcuni PC perché ho sentito di PC con EFI basso che stanno ancora incontrando problemi.
Audit con:
Get-Volume | Where-Object {$_.DriveLetter -eq "System" -or $_.FileSystemLabel -eq "System"} | Select-Object Size,SizeRemaining
Se lo spazio libero è < 100 MB, ho visto fallimenti. Risize prima dell’aggiornamento.
Emergency Recovery Path per Macchine Non-Responsive (Fase 3)
Nel caso peggiore, la macchina resta bloccata su “BitLocker Recovery – Enter recovery key” o su un BSOD. Ecco il mio playbook:
Passo 1: Recupera la chiave di recovery
Per la maggior parte delle aziende, la chiave di recovery è memorizzata in Microsoft Entra ID o Active Directory, e gli amministratori possono recuperarla da remoto.
# PowerShell per recuperare da Entra ID (admin delegato)
Get-MgDevice -Filter "deviceId eq 'DEVICE_ID'" | Get-MgDeviceBitLockerRecoveryKey
Se locale account senza escrow:
- Contatta l’utente per il Key ID (mostrato su schermo BitLocker)
- Recupera da Microsoft account del dispositivo se registrato
- Ultima spiaggia: puoi solo fare una full recovery tramite Windows installation media
Passo 2: Workaround per BIOS/UEFI Mismatch
La mia comprensione è che i BSOD di giugno non sono colpa sola di Microsoft, poiché sembra essere dovuto a un problema di compatibilità tra l’aggiornamento e il BIOS o alle impostazioni della partizione EFI/System mal configurate da HP.
Se il supporto tecnico sospetta questo:
- Entra in BIOS (F2 per Dell, F10 per HP)
- Disabilita temporaneamente Secure Boot
- Salva e esci
- Windows bootterà (senza Secure Boot)
- Installa l’update KB cumulativo più recente
- Reboot e lascia che si applichi completamente
- Riabilita Secure Boot in BIOS
- Reboot finale
Consiglio anche di assicurarti che il BIOS/UEFI sia aggiornato, ma se il workaround sopra non funziona, dovrai disattivare Secure Boot finché Microsoft o HP non offre una spiegazione.
Passo 3: Windows Recovery Environment (WinRE) Come Fallback
Se il dispositivo è completamente non-bootabile, accedi a WinRE tramite:
- Spegni il PC
- Accendi e premi F8 (o Shift+F8 su alcuni modelli) prima del logo Windows
- Seleziona Troubleshoot > Advanced options > Startup Repair
Se WinRE stesso non funziona, hai bisogno di external recovery media. Mantieni un working external recovery drive o installation media—preferibilmente uno creato o aggiornato dopo il 3 marzo 2026 per i dispositivi Windows 10 che potrebbero essere interessati.
Nel mio lab, mantengo sempre un winre.wim aggiornato su un NAS per patch offline:
# Estrai WinRE da una macchina patched
Dism.exe /Mount-Image /ImageFile:C:WinREboot.wim /Index:1 /MountDir:C:mount
Copy C:mountwindowssystem32recoverywinre.wim \NASRecoverywinre_PATCHED.wim
Dism.exe /Unmount-Image /MountDir:C:mount /Discard
# Ripristina su una macchina offline
Disk part
list disk
select disk X
clean
create partition efi size=100
format fs=fat32
create partition msr size=16
create partition primary
format fs=ntfs
exit
Dism.exe /Apply-Image /ImageFile:install.wim /Index:1 /ApplyDir:D:
Monitoraggio Post-Update (Fase 4)
Dopo ogni deployment, monitoro questi event log:
# Check Event ID 1795 (Secure Boot certificate delivery failure)
Get-EventLog -LogName System -Source "Microsoft-Windows-Security-SPP" | Where-Object {$_.EventID -eq 1795}
# Check BitLocker recovery attempts
Get-EventLog -LogName System | Where-Object {$_.Message -like "*BitLocker*" -or $_.EventID -eq 8212}
# WinRE issues
Get-EventLog -LogName System | Where-Object {$_.Message -like "*WinRE*" -or $_.EventID -eq 1032}
Se Event Viewer Windows Logs per System registra un Event ID 1795, significa che c’è stato un errore quando Windows ha tentato di consegnare i certificati al firmware. In questo caso, verifico con l’OEM se esiste un firmware update per il dispositivo.
Link Interni Correlati
Questo articolo è una continuazione pratica della mia strategia Zero-Downtime per Secure Boot Rollover post-24 giugno 2026. Se gestisci flotte enterprise con NIS2 compliance su Windows 11, devi assicurare che il Secure Boot update sia parte della tua DPIA documentazione. Per infrastrutture critiche, consulta anche la mia guida Zero-Trust per Windows Server 2025.
FAQ
Se non aggiorno i certificati Secure Boot entro giugno 2026, la macchina non bootterà?
No. La finestra di guida di Microsoft è più misurata: i dispositivi interessati possono continuare a bootare e possono continuare a ricevere aggiornamenti Windows standard, ma possono perdere la capacità di ricevere future protezioni Secure Boot per i componenti di early boot. Nel tempo, questo crea una finestra di vulnerabilità crescente.
Cosa devo fare se BitLocker chiede la recovery key dopo un update?
Innanzitutto, non perdere la calma. Hai due opzioni: (1) Entra la recovery key (la recuperi da Entra ID se la macchina è gestita). (2) Se non hai accesso alla chiave, revert l’update tramite Windows Update > Update History e disinstalla il KB problematico, poi verifica il PCR7 status nella Group Policy prima di riprovare.
Devo rollback l’aggiornamento di giugno 2026 se ho dei problemi?
Attenzione: La release di giugno 2026 Patch Tuesday aggiorna 208 vulnerabilità di sicurezza, il numero più grande in una singola Patch Tuesday. Tra quelle vulnerabilità ci sono cinque che erano già sfruttate attivamente prima di questo aggiornamento, e un wormable kernel flaw CVSS 9.8. Rollback dell’aggiornamento rimuove tutte quelle correzioni insieme alle regressioni. Rollback = rischio di sicurezza enorme. Invece, pilota con poche macchine, test il workaround BIOS, e procedi con caution.
Come posso prevenire BitLocker recovery prompts in futuro?
Gestisci BitLocker con Group Policy standard (non custom TPM profiles con PCR7), e assicura che tutte le recovery keys siano escrowed in Entra ID / Active Directory / Intune. Crea anche external recovery media aggiornati (post-March 2026) come backup, nel caso WinRE fallisca.
Qual è la finestra temporale per deployare i certificati Secure Boot 2023?
Secondo gli ingegneri Microsoft che hanno parlato durante una sessione AMA di marzo 2026, i nuovi certificati sono validi fino al 2038, e una transizione di crittografia post-quantum separata è pianificata per intorno al 2030 per l’hardware futuro. Non hai fretta per il 2038, ma entro il 24 giugno 2026 vuoi aver completato il 2023 KEK. Dopo quella data, nuove protezioni di boot non potranno essere firmati con le chiavi 2011.
Conclusione: Secure Boot Certificate Transition è Logistica, Non Panico
Il mio takeaway dopo aver gestito centinaia di dispositivi in questa transizione: chiunque sia responsabile dei sistemi Windows dovrebbe trattare il rollover dei certificati come un motivo per verificare la resilienza del boot, non semplicemente come un altro elemento nella coda di patch mensile.
Auditare il tuo parco macchine ora—controlla PCR7 binding, verifica le chiavi di recovery BitLocker siano in escrow, testa firmware OEM updates sui modelli critici—è mille volte più facile che affrontare 100 macchine non-responsive il 25 giugno. Nella mia esperienza, il cliente che ha fatto l’audit in marzo ha avuto zero problemi. Quelli che hanno aspettato fino a giugno hanno speso giorni in recovery.
Se gestisci una flotta enterprise, commenta qui sotto con i modelli hardware/firmware dove hai visto problemi. Sto raccogliendo data empirica per una guida OEM compatibility matrix che pubblicherò nel prossimo aggiornamento.