Il contesto: perché i certificati Secure Boot stanno scadendo
Giugno 2026 non è solo una data sul calendario: è una scadenza critica per qualsiasi amministratore di sistema che gestisce parchi macchine Windows in ambienti enterprise. I certificati Secure Boot installati nella maggior parte dei dispositivi durante l’era di Windows 8 — quelli che fondano la catena di fiducia UEFI — inizieranno a scadere a partire da questo mese. La conseguenza più immediata: i dispositivi non aggiornati perderanno la capacità di ricevere nuove protezioni per il processo di avvio, inclusi aggiornamenti al Windows Boot Manager, alle revocation list DBX e alle patch per vulnerabilità di boot-level scoperte in futuro.
Microsoft ha risposto a questa urgenza con il Patch Tuesday di maggio 2026, introducendo l’aggiornamento cumulativo KB5089549 per Windows 11 (versioni 24H2 e 25H2). Oltre alle consuete correzioni di sicurezza, questa release porta con sé qualcosa di inedito: una nuova cartella C:\Windows\SecureBoot\ExampleRolloutScripts contenente sette script PowerShell pensati per automatizzare l’intera migrazione dei certificati Secure Boot nelle reti enterprise.
Cosa trovi nella cartella C:\Windows\SecureBoot
La cartella non contiene i certificati stessi, ma una suite di script PowerShell modulari, ben commentati e accompagnati da un file README.md e un CHANGELOG.txt. Microsoft la posiziona deliberatamente sotto C:\Windows — un segnale preciso: la gestione del Secure Boot diventa un’attività di manutenzione ordinaria del sistema operativo, non più un compito relegato a tool OEM o procedure manuali nei menu BIOS.
Gli script sono progettati per operare su flotte di macchine tramite Intune, WSUS o Configuration Manager. Vediamoli uno per uno.
1. Detect-SecureBootCertUpdateStatus.ps1
Questo script viene eseguito su ogni endpoint, tipicamente via Group Policy o come scheduled task distribuito. Raccoglie lo stato di Secure Boot, i valori di registro che tracciano l’avanzamento della migrazione certificati, i dettagli OEM e firmware, e gli entry rilevanti dell’Event Log. L’output è un file JSON scritto su un path di rete condiviso (e su un path locale di fallback), che serve come base dati per gli script successivi.
# Esempio di utilizzo base
.\Detect-SecureBootCertUpdateStatus.ps1 -OutputPath "\\server\SecureBootData"
2. Aggregate-SecureBootData.ps1
Consolida i file JSON prodotti dallo script di rilevamento in un unico report aggregato. Utile per costruire dashboard di stato, identificare dispositivi con certificati non aggiornati e pianificare le wave di deployment. Può essere eseguito dal management server con accesso alla condivisione di rete centralizzata.
3. Deploy-GPO-SecureBootCollection.ps1
Automatizza la creazione di una Group Policy Object che distribuisce lo script di raccolta dati (Detect-SecureBootCertUpdateStatus.ps1) come scheduled task su tutti i target dell’OU specificata. Riduce drasticamente il lavoro manuale nella fase di inventory.
4. Start-SecureBootRolloutOrchestrator.ps1
È il cuore della suite. Legge i dati aggregati, determina quali dispositivi sono pronti per l’aggiornamento, crea security group AD e una GPO dedicata, quindi avvia il deployment progressivo a wave esponenziali: prima 1 dispositivo, poi 2, poi 4 e così via. Se una wave registra errori firmware, il rollout si blocca automaticamente, impedendo la propagazione del problema al resto della flotta.
# Avvio orchestrato con 5% di dispositivi nel primo ring
.\Start-SecureBootRolloutOrchestrator.ps1 `
-DataPath "\\server\SecureBootData" `
-RingSize 0.05 `
-DomainController "dc01.contoso.com"
5. Deploy-OrchestratorTask.ps1
Il processo di orchestrazione può durare settimane in ambienti di grandi dimensioni. Invece di mantenere aperta una sessione PowerShell su un management server, questo script installa l’orchestratore come Windows Scheduled Task, garantendo continuità anche in caso di riavvii o disconnessioni.
6. Get-SecureBootRolloutStatus.ps1
Permette di visualizzare lo stato corrente del rollout: quanti dispositivi sono stati aggiornati, quanti sono in attesa, quanti hanno riscontrato errori. Indispensabile per il monitoraggio durante fasi di deployment attive.
7. Enable-SecureBootUpdateTask.ps1
Script di remediation: se il task automatico di aggiornamento Secure Boot è stato disabilitato, eliminato o modificato (ad esempio da una policy di Configuration Manager), questo script lo ripristina allo stato predefinito, rimettendo in moto i dispositivi che non stanno progredendo.
Considerazioni pratiche prima di eseguire gli script
Microsoft descrive questi script come sample — implementazioni di riferimento, non soluzioni turnkey pronte per il produzione senza revisione. Prima di distribuirli, è necessario tenere a mente alcune criticità.
Esecuzione policy e script non firmati. Gli script sono unsigned. Prima di eseguirli, verificare che la execution policy di PowerShell lo permetta, oppure sbloccarli individualmente:
Unblock-File -Path "C:\Windows\SecureBoot\ExampleRolloutScripts\*.ps1"
BitLocker e Credential Guard. Le modifiche allo stato di Secure Boot possono innescare richieste di recovery BitLocker. Gli script includono un pre-check che sospende BitLocker sul volume di sistema prima della migrazione e lo riattiva al termine — ma è sempre buona norma avere le recovery key a portata di mano prima di avviare qualsiasi operazione.
Firmware OEM aggiornato. Prima di applicare la migrazione certificati, verificare che i dispositivi target abbiano il firmware UEFI più recente fornito dall’OEM. Alcuni modelli più datati potrebbero non supportare le variabili UEFI necessarie o potrebbero richiedere un aggiornamento firmware preventivo.
Ambienti di test obbligatori. Il rollout progressivo dell’orchestratore è già un meccanismo di sicurezza, ma Microsoft raccomanda comunque di testare gli script in un ambiente non produttivo con hardware rappresentativo prima di qualsiasi deployment su larga scala.
Integrazione con Intune e il report Autopatch
Per chi utilizza Windows Autopatch, l’Intune admin center ha ricevuto un aggiornamento del report Secure Boot Status che fornisce visibilità device-by-device sullo stato dei certificati in vista della scadenza di giugno. Il report mostra quali dispositivi hanno Secure Boot abilitato, se i certificati sono aggiornati, e se si applica il deployment automatico o manuale. Nuove colonne per trust configuration, confidence level e alert aiutano a prendere decisioni mirate anziché dover fare deployment generalizzati.
Conclusione
L’aggiornamento KB5089549 non è solo un Patch Tuesday ordinario: segna un passaggio importante nel modo in cui Microsoft concepisce la gestione della sicurezza firmware in ambienti enterprise. Collocare script PowerShell di migrazione Secure Boot direttamente in C:\Windows, con logging integrato sull’Event Log sotto il provider Microsoft-Windows-SecureBoot-Scripts e un changelog per le future versioni, è un chiaro segnale: il lifecycle management del Secure Boot diventa parte del normale ciclo di manutenzione dei sistemi Windows, esattamente come la gestione dei certificati TLS.
Per i sysadmin che devono affrontare la scadenza di giugno 2026, il punto di partenza è il portale ufficiale aka.ms/GetSecureBoot, dove Microsoft raccoglie tutta la documentazione aggiornata sulla migrazione. Il tempo di agire è adesso: inventariare i dispositivi, testare gli script in un ambiente controllato e pianificare le wave di deployment prima che la scadenza diventi un’emergenza.
Fonti: Neowin – KB5089549, Microsoft Support – Secure Boot Certificate Expiration, 4sysops – Windows 11 SecureBoot folder