Secure Boot 2026 - Aggiornamento dei certificati UEFI e piano di adozione in azienda

Transcript

1. Windows Secure Boot UEFI certificate expiration Come gestire l’update in azienda
2. About me • Simone Termine • Endpoint Cloud Solution Architect • Contributor @ ICT Power • Author @ EndpointNinja.com • LinkedIn: /simonetermine
3. 01 – Secure Boot 101 02 – Scadenza certificati Secure Boot 03 – Gestire l’aggiornamento in azienda 04 – Monitoraggio 06 – Troubleshooting 07 – FAQ 08 – Riepilogo Agenda
4. Secure Boot 101
5. Cos’è Secure Boot UEFI Firmware (PK/KEK/DB/DBX) Boot Manager (bootmgfw.efi) OS Loader / Kernel + driver early-boot Verifica firma Verifica trust In breve: • È una funzionalità UEFI • Blocca bootkit/rootkit verificando la firma del codice di avvio • Si basa su liste nel firmware → DB (trust) e DBX (revoche) Perché ci interessa nel 2026? • La chain di trust va mantenuta aggiornabile • Senza update CA 2023 aumenta il rischio di postura di boot degradata • Meno capacità di applicare nuove mitigazioni (DBX) in early-boot
6. UEFI trust stores PK (Platform Key – OEM/owner) KEK (Key Exchange Key – abilita update DB/DBX) DB Allowed signatures (trust) DBX Revoche (deny list) • PK: radice di trust (chi può amministrare Secure Boot) • KEK: abilita e autorizza gli aggiornamenti dei database • DB: firme/certificati consentiti all’avvio • DBX: revoche per componenti vulnerabili • Nel 2026 scade parte della chain 2011, serve transizione alla chain 2023 per mantenere aggiornabilità del boot
7. DB e DBX - Active vs Default DEFAULT (factory/OEM) ACTIVE (runtime/aggiornato) Set chiavi/database di fabbrica. Può tornare in uso dopo reset/repair. Set effettivamente usato. Evolve con update Windows/firmware. Trigger tipici che possono esporre problemi: • reset UEFI/clear keys • sostituzione motherboard • modifiche al boot path (bootmgfw.efi) • recovery media personalizzati Messaggio chiave: aggiornare firmware OEM che possono includere le correzioni anche per Default DB/DBX
8. Scadenza certificati UEFI Secure Boot
9. Quali certificati stanno scadendo? Chain 2011 (storica) Chain 2023 (nuova) Nota Microsoft Corporation KEK CA 2011 Microsoft Corporation KEK CA 2023 Aggiorna la capacità di aggiornare DB/DBX Microsoft Windows Production PCA 2011 Windows UEFI CA 2023 Firma boot loader Windows Microsoft Corporation UEFI CA 2011 Microsoft UEFI CA 2023 (+ Option ROM UEFI CA 2023) Non presente su tutti i device Nel 2026 iniziano le scadenze della chain 2011 (finestra: giugno → ottobre). Obiettivo: portare i device a includere le CA 2023 nei trust store UEFI, così da mantenere aggiornabilità (DB/DBX) anche dopo le scadenze.
10. Impatti Oggi • Device si avvia normalmente • DB/DBX aggiornabili • Mitigazioni boot applicabili Dopo scadenza • Boot potrebbe continuare • Update trust chain meno affidabili • Maggiore esposizione a regressioni Nel tempo • Postura di boot degradata • Revoche DBX possono non applicarsi • Mitigazioni future più difficili Messaggio chiave: non è un brick day → è un rischio di perdita progressiva di aggiornabilità e sicurezza del boot
11. Sistemi coinvolti Mappa del perimetro: non è solo Windows. Il rollout tocca firmware UEFI, processo di reboot e casi speciali (BitLocker, dual-boot, custom keys). Client Windows 10/11 Laptop e desktop con Secure Boot attivo. Priorità: parco standard e dispositivi usati ogni giorno. Windows Server Server UEFI/Secure Boot (dove presente). Valutare finestre di reboot e change control. VM/VDI/AVD VM Gen2 con Secure Boot (Hyper-V/Azure). Verificare immagini, template e golden image. Firmware/OEM BIOS/UEFI, reset keys, update firmware. È il layer che può causare regressioni “DEFAULT vs ACTIVE”. BitLocker/Recovery Possibili blocchi o richieste di recovery. Serve runbook per sospensione controllata. Casi speciali Dual-boot, PK/KEK custom, media di recovery. Richiedono assessment dedicato prima del rollout. Pilota subito Client + VM standard Valida con attenzione Server / BitLocker Assessment dedicato Dual-boot / custom keys
12. Cosa succede se non aggiorno alla nuova chain CA 2023? Device (Secure Boot ON) Chain 2011 non aggiornata Trigger: reset keys/ update/repair BIOS Effetto possibile: • Ritorno a DEFAULT DB/DBX • DEFAULT ancora su chain 2011 • Regressione della postura di boot Scenario: serve nuova revoca (DBX) o mitigazione Rischio: • Update DBX non applicabile • Hardening incompleto • Maggiore finestra per bootkit Azione → pianifica un pilota e aggiorna alla chain CA 2023 prima delle scadenze 2026. Criterio di DONE: UEFICA2023Status = Updated + evento 1808.
13. Gestire l’aggiornamento dei certificati in azienda
14. Microsoft-managed vs IT-managed Scelta di governance: stesso obiettivo tecnico, modello operativo diverso. La decisione dipende da standardizzazione, change control e capacità di monitoring. CRITERIO MICROSOFT-MANAGED IT-MANAGED Controllo Più automatico. Controllo per eccezioni e outlier. Massimo controllo su pilot, wave e timing. Prerequisiti Opt-in + diagnostica (se usi approccio assistito). Standardizzazione più alta. Runbook IT, gruppi pilot, reboot planning, processo change e comunicazione utenti. Effort operativo Minore effort iniziale. Focus su monitoring e remediation puntuale. *Più effort iniziale, ma flusso più prevedibile e auditable. Velocità Più rapido su tenant omogenei. Più graduale, ideale per wave controllate. Quando usarlo Tenant moderni e cloud-managed, con buon livello di baseline e patching. Ambienti regolati, co-managed o con change-control rigido. Attenzioni Gestire eccezioni firmware/OEM e casi speciali (custom keys, dual-boot). Serve disciplina operativa: KPI, reboot e runbook per blocchi ricorrenti. Suggerimento: scegli il modello in base al livello di governance richiesto, non solo in base alla facilità tecnica.
15. Microsoft-managed: WU vs CFR Windows Update - LCUs (High-confidence buckets) • Microsoft include automaticamente i device “high-confidence” nelle CU mensili • Non richiede abilitare Diagnostic data (usa dati già condivisi per costruire i bucket) • Bucket basati su attributi hardware/firmware (OEM, motherboard, versione firmware, ecc.) • Abilitato di default per i device high-confidence CFR (Controlled Feature Rollout) • Richiede Diagnostic data + segnale di opt-in CFR sul device • Microsoft gestisce il processo di deploy sui device partecipanti • Limitazioni: versioni non supportate o telemetria non utilizzabile • È un assist e non sostituisce il piano IT-managed (pilot, wave, remediation)
16. Demo - Avviare l’aggiornamento con Microsoft Intune
18. Demo - Avviare l’aggiornamento tramite Group Policy
20. Monitoraggio
21. Verificare stato – eventi – KPI Usa un modello a 3 livelli: segnali tecnici (registry/eventi) → stato device → KPI per wave. Il valore non è il singolo log, ma il trend di rollout. 1. Trigger Policy Intune / GPO / Registry / Script 2. Segnali UEFICA2023Status UEFICA2023Error TPM-WMI 1808/1801 3. Stato device Updated / InProgress / Error / Blocked 4. KPI / Wave % Updated Trend Top root cause % Updated Indicatore principale di avanzamento per wave. % InProgress Misura backlog + dipendenza da reboot. % Error Root cause prioritari da chiudere. Tempo medio a DONE Aiuta a stimare la wave successiva. Criterio di DONE (device) UEFICA2023Status = Updated + UEFICA2023Error = 0 + evento TPM-WMI 1808 (success).
22. Monitoring in Microsoft Intune Dove monitorare (Intune) • Reports → Windows Autopatch → Windows Quality Updates → Reports → Secure Boot status Suggerimento: create una Intune Remnediation che legge • HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing • UEFICA2023Status - UEFICA2023Error - AvailableUpdates • Event IDs TPM-WMI (1808 / 1801) Intune policy assignment Device executes task Secure-Boot-Update Signals collected (Registry + Event log) Report and dashboard (KPI per wave)
23. Monitoring in Microsoft Intune – Secure Boot status
24. Monitoring in Microsoft Intune – Secure Boot status
25. Monitoring in Microsoft Intune – Secure Boot status
26. Monitoring in Microsoft Intune – Creazione Intune remediation
27. Monitoring in Microsoft Intune – Monitor Intune remediation
28. Monitoring su sistemi on-prem Stesso concetto: raccogliere segnali locali (registry + eventi) e costruire reporting per wave. SCCM / MECM • Configuration Item + Baseline • Collection per wave • Compliance report GPO + Script • Scheduled task / startup script • Scrittura registry trigger • Log/exit code per stato Event Forwarding • TPM-WMI - System events • Filtro 1808/1801 • Dashboard centralizzato PowerShell report • Export valori UEFICA2023* • CSV/Log Analytics • KPI e trend PS quick check: Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing | select UEFICA2023Status,UEFICA2023Error,AvailableUpdates
29. Troubleshooting
30. Verifica impostazioni client
31. Fix errori
32. CA 2023 aggiornata
33. Chiavi di registro
34. Chiavi di registro
35. Task Scheduler
36. Event Viewer
37. Novità Febbraio 2026
38. Registro delle modifiche - Overview Data Cosa è cambiato Impatto → Azione 20 Feb 2026 Aggiunte 3 nuove registry keys: UEFICA2023ErrorEvent, BucketHash, ConfidenceLevel. Aggiorna script/report: correlazione errori e bucket; migliora KPI e triage. 24 Feb 2026 Aggiornata la guidance: contenuti su sample inventory script e sample output. Se usi lo script Microsoft, verifica che sia la versione più recente. 22 Feb 2026 Aggiornato il Sample Secure Boot Inventory Data Collection script. Rigenera pacchetto Intune remediation / GPO collection con la versione aggiornata. 26 Gen 2026 Chiarito che solo l’assist CFR richiede diagnostic data. Rivedi comunicazione interna: WU/high-confidence non richiede abilitare diag data. Microsoft aggiorna frequentemente guidance, script e chiavi di registro. Tenere un registro delle modifiche aiuta a mantenere script di monitoring e runbook sempre allineati.
39. Registro delle modifiche – Chiavi di registro Il 20 Febbraio 2026 Microsoft ha aggiornato la documentazione aggiungendo 3 nuove chiavi di registro utili per troubleshooting e rollout analytics. Chiave Tipo A cosa serve UEFICA2023ErrorEvent REG_DWORD Event ID correlato a UEFICA2023Error: indica quale evento Secure Boot è stato registrato per spiegare il motivo del fallimento. BucketHash REG_SZ Identifica il “deployment bucket” assegnato al device per rollout a fasi. È lo stesso bucket hash presente negli eventi device-specific, utile per correlare registry ed Event Log. ConfidenceLevel REG_SZ Indica la “confidence” associata al bucket (es. high-confidence / needs more data / ecc.). Serve per capire come Microsoft sta classificando il device nel rollout e per leggere i dettagli degli eventi.
40. FAQ
41. FAQ – scenari e rischi I pc smettono di avviarsi nel 2026? In genere no. Il rischio principale è perdere aggiornabilità del trust chain e delle future revoche/mitigazioni early-boot. È un tema solo Windows 11? No. Riguarda device Windows con Secure Boot attivo (Windows 10/11 e scenari server/VM UEFI supportati). Se oggi è tutto ok, posso ignorarlo? No. Oggi può funzionare, ma reset UEFI, firmware update o nuove revoche DBX possono esporre il problema più avanti. È un ‘patch Tuesday’ normale? No. Coinvolge anche variabili UEFI/firmware e il boot path. Va trattato come rollout con pilot e KPI. Quali ambienti sono più esposti? Parco eterogeneo, firmware datati, dual-boot, custom keys e sistemi che riavviano poco (server/VDI persistenti). Secure Boot OFF è coinvolto? Non direttamente. Però è il momento giusto per verificare baseline e decidere se standardizzare Secure Boot dove possibile. FAQ: cosa succede, quanto è urgente e dove sono i rischi reali.
42. FAQ – rollout e operatività Serve un reboot? Spesso sì. Pianificalo nel pilot e misuralo: molti device restano in InProgress finché non riavviano. BitLocker può bloccare il rollout? Sì, in alcuni casi. Prevedi runbook per sospensione temporanea e verifica degli eventi TPM-WMI. Intune o GPO? Entrambi validi. Intune è più lineare su ambienti cloud-managed; GPO/ConfigMgr resta ottimo in on-prem o co-managed. Come verifico rapidamente un device? Registry (UEFICA2023Status/Error) + Event Viewer (1808 success / 1801 error) = quick check affidabile. Cosa faccio se vedo errori OEM/firmware? Aggiorna BIOS/UEFI, ritesta nel pilota e documenta il modello come eccezione o prerequisito. Quando dichiaro ‘DONE’ una wave? Quando raggiungi soglia target di % Updated, errori gestiti e runbook validati sui casi speciali. Domande operative da endpoint team: Intune/GPO, reboot, BitLocker, troubleshooting e criterio di completamento.
43. Riepilogo
44. Riepilogo operativo (checklist) Checklist essenziale • Fase 1 → Inventario e preparazione dell’ambiente • Fase 2 → Monitoraggio e controllo dello stato Secure Boot • Fase 3 → Applicare aggiornamenti firmware OEM prima degli update Microsoft • Fase 4 → Pianificare pilota e rollout (possibilmente per wave) • Fase 5 → Troubleshooting KPI: % Updated · % InProgress · % Error · tempo medio a Updated · top root cause
45. Riferimenti Microsoft (QR) Guidance (CA updates) Panoramica, prerequisiti e pianificazione rollout. Intune method Come avviare l’update tramite Intune (IT-managed). Events & Troubleshooting Eventi TPM-WMI (1808/1801) e casistiche di blocco. Inventory script Script Microsoft per inventory/detection dello stato Secure Boot. AMA Secure Boot – Feb 2026 Q&A Microsoft (5 Feb 2026): chiarimenti e novità. AMA Secure Boot – Dec 2025 Q&A Microsoft (10 Dic 2025): contesto e prime indicazioni.
46. Riferimenti ICT Power (QR) Articolo: Aggiornamento certificati Secure Boot con Microsoft Intune Contesto, rischi e percorso pratico con MSIntune. Articolo: Aggiornamento certificati Secure Boot con Group Policy e SCCM Approccio on-prem, policy e compliance con GPO e SCCM. LinkedIn Collegati per follow-up.
47. Q&A