Microsoft risponde alle domande chiave mentre si avvicina la scadenza di Secure Boot
Con l'avvicinarsi della scadenza del 24 giugno 2026 per il certificato originale Microsoft Secure Boot KEK, Microsoft ha condotto la sua seconda sessione live di “Chiedi tutto a Microsoft” (AMA) il 4 giugno per affrontare le preoccupazioni rimanenti degli amministratori IT e dei clienti aziendali. Questa sessione ha fornito approfondimenti sugli aggiornamenti di Secure Boot, affrontando distribuzioni aziendali, compatibilità con macchine virtuali, scenari di avvio PXE e altro ancora.
Cosa cambia il 24 giugno 2026?
La domanda più pressante era se il 24 giugno rappresentasse una scadenza rigida per il certificato Secure Boot KEK CA 2011. Secondo Scott Shell, la data di scadenza non è una scadenza rigida che interrompe tutte le funzionalità. La scadenza della chiave KEK non influisce immediatamente sul processo di distribuzione manuale basato su registro o sui payload di aggiornamento esistenti, che continueranno a funzionare come prima.
Tuttavia, dopo il 24 giugno, Microsoft perderà la capacità di firmare nuovi payload DBX, che sono fondamentali per revocare i bootloader compromessi. I dispositivi senza il certificato KEK aggiornato potrebbero perdere future revoche, diventando potenzialmente meno sicuri nel tempo. Tuttavia, il certificato DB rimane valido fino a ottobre, consentendo a Microsoft di firmare ulteriori gestori di avvio durante questo periodo intermedio.
L'aggiornamento di giugno espande la copertura ad alta fiducia
L'aggiornamento Patch Tuesday di giugno classificherà la grande maggioranza dei dispositivi mainstream come ad alta fiducia basandosi sui dati diagnostici di Microsoft. Kevin Sullivan ha chiarito che la classificazione dei dispositivi si estende oltre il produttore e i nomi dei modelli per includere la versione e la data del firmware. Ciò significa che anche modelli identici potrebbero essere classificati in modo diverso a seconda del loro firmware.
Per assistere gli amministratori IT, il report di monitoraggio di Intune fornisce una vista dettagliata dello stato dei dispositivi, inclusa la classificazione ad alta fiducia, lo stato di applicazione degli aggiornamenti e i dispositivi che richiedono intervento manuale. Il report è integrato da uno script di correzione PowerShell per maggiore flessibilità.
Affrontare i dispositivi “temporaneamente in pausa”
Alcuni clienti aziendali hanno segnalato dispositivi bloccati in uno stato di “temporaneamente in pausa”. Microsoft ha spiegato che ciò accade quando problemi di compatibilità a livello di firmware rendono rischiosi gli aggiornamenti. In tali casi, è necessario un aggiornamento del firmware OEM per risolvere il problema. Una volta aggiornato il firmware, il dispositivo passa a un nuovo gruppo di classificazione.
Gli amministratori dovrebbero utilizzare i dati live di Intune o il file CSV di GitHub per monitorare accuratamente lo stato dei dispositivi, poiché i gruppi in pausa non si aggiornano retroattivamente. La pagina di destinazione di Secure Boot di Microsoft include collegamenti alle pagine di supporto OEM per individuare gli aggiornamenti del firmware.
Linee guida per distribuzioni manuali
Per i dispositivi non inclusi nel gruppo ad alta fiducia, Microsoft ha sconsigliato di attendere la classificazione automatica. Gli amministratori dovrebbero avviare distribuzioni manuali impostando valori di registro o utilizzando le impostazioni delle policy di Intune. Il flusso di lavoro consigliato include:
- Scaricare il report di monitoraggio di Intune per identificare i dispositivi non aggiornati.
- Testare il processo di aggiornamento su dispositivi rappresentativi per ogni modello o variante di firmware.
- Espandere gradualmente la distribuzione dopo test di successo.
Microsoft ha sottolineato che gli aggiornamenti manuali contribuiscono ai dati di telemetria, migliorando il sistema per altre organizzazioni con dispositivi simili.
Dispositivi con Secure Boot disabilitato
Per i dispositivi con Secure Boot disattivato, gli aggiornamenti ai certificati non possono essere applicati. Se Secure Boot viene successivamente riattivato, le discrepanze tra i database di fiducia del firmware e le firme del gestore di avvio possono causare errori di avvio. Il recupero da ciò richiede l'installazione manuale del certificato 2023 nel firmware.
Le macchine virtuali Azure Gen 2 con avvio sicuro o avvio affidabile abilitato dispongono già del certificato 2023, mentre le macchine virtuali Gen 1 non sono compatibili con Secure Boot.
Criteri di classificazione ad alta fiducia
I dispositivi più vecchi spesso raggiungono la classificazione ad alta fiducia più rapidamente rispetto ai modelli più recenti, poiché le loro popolazioni più piccole consentono una validazione statistica più veloce. Per i modelli più recenti ampiamente distribuiti, l'aggiornamento di giugno dovrebbe espandere significativamente il gruppo ad alta fiducia.
Gli ambienti PXE Boot richiedono una gestione attenta
Per gli ambienti PXE Boot, i dispositivi con il certificato 2011 continueranno ad avviarsi finché il certificato non viene revocato nell'elenco DBX. Tuttavia, il passaggio ai bootloader firmati con il certificato 2023 richiede che tutti i dispositivi nell'ambiente riconoscano il nuovo certificato. Durante la transizione, è consigliabile mantenere supporti di avvio firmati da entrambi i certificati.
Windows 10 e versioni precedenti del sistema operativo
Il meccanismo di aggiornamento di Secure Boot è identico su Windows 10 (sotto ESU), Windows 11 e versioni precedenti del server. Tuttavia, i dispositivi più vecchi potrebbero mancare di dati di telemetria, rendendo necessari aggiornamenti manuali.
Strumenti diagnostici e risorse
I log degli eventi, in particolare il log degli eventi TPM-WMI, sono fondamentali per diagnosticare i problemi di Secure Boot. Gli indicatori chiave includono:
- Errore 1803 per chiavi piattaforma non valide o non firmate.
- Verifica dei certificati KEK e DB per le versioni 2023.
La risorsa centrale di Microsoft, aka.ms/GetSecureBoot, fornisce un playbook completo, script diagnostici e collegamenti al firmware OEM. Gli amministratori sono incoraggiati a seguire il consiglio di Microsoft “testarne uno prima” per garantire aggiornamenti senza problemi.
In sintesi, il rollout graduale e gli strumenti diagnostici di Microsoft sono progettati per ridurre al minimo le interruzioni garantendo la conformità a Secure Boot. Si incoraggiano gli amministratori IT ad agire prontamente per evitare potenziali rischi alla sicurezza con l'avvicinarsi della scadenza del KEK.
