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
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
(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
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.
• 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
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
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.
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.
• 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)
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).
→ 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.
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.
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.
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.
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
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.
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.
memiug
junki
ming_ayami
bitkey
wyamazak_devrel
tomoki10
yutaokafuji
sgwrmctk
brainpadpr
sonic
sonoda_mj
thousanda
masaruogura
aleyda
notwaldorf
tammyeverts
honnibal
katarinadahlin
lauravandoore
jct
sstephenson
tamaranovitovic
auna
marktimemedia
techseoconnect
