• Guide, Sicurezza, Sistemi Operativi
• 19 Gennaio 2026

Dopo circa 15 anni dall’introduzione di Secure Boot nell’ecosistema Windows, alcuni certificati Microsoft “storici” (le CA 2011) inizieranno a scadere a partire da giugno 2026. Per garantire continuità operativa e mantenere elevato il livello di sicurezza del processo di avvio, Microsoft sta distribuendo i nuovi certificati (CA 2023).
In un contesto enterprise, però, è consigliabile pianificare e monitorare la transizione in modo proattivo, evitando di accorgersi del problema solo quando emergono anomalie o interruzioni di servizio.

In questa guida vedremo nel dettaglio:

• Cosa sta succedendo (e perché riguarda tutti)
  
• Cos’è Secure Boot e come funziona (UEFI, PK/KEK/DB/DBX)
• Sistemi coinvolti
  
• Impatti e implicazioni
  
• Cosa succede se non aggiornate
  
• Metodi disponibili per distribuire l’aggiornamento
  
• Come usare Microsoft Intune (Settings catalog) per avviare e gestire l’aggiornamento
  
• Troubleshooting (registro di sistema, event viewer, PowerShell)
  
• Alternative a Microsoft Intune
  
• Riepilogo e checklist operativa
  
• FAQ
  
• Conclusioni
  

Cosa sta succedendo

Windows, insieme all’ecosistema UEFI e Secure Boot, si basa su una catena di trust costruita su chiavi e certificati (PK, KEK, DB/DBX) per stabilire quali componenti sono autorizzati a essere eseguiti prima del caricamento del sistema operativo. Alcuni certificati Microsoft “storici” (la chain 2011) presenti da anni su moltissimi dispositivi stanno arrivando a scadenza nel 2026.

Per garantire continuità e sicurezza del processo di avvio, Microsoft sta introducendo la nuova chain 2023 e ha messo a disposizione meccanismi di distribuzione pensati anche per gli ambienti enterprise in cui gli aggiornamenti sono gestiti direttamente dall’IT.

In breve: se un dispositivo resta ancorato alle CA 2011, a partire da giugno 2026 in poi può perdere la capacità di ricevere correttamente aggiornamenti e correzioni di sicurezza legati al percorso di avvio (boot manager e componenti pre-boot) e potrebbe non considerare attendibili componenti firmati secondo la nuova chain CA 2023.

Cos’è Secure Boot e come funziona

Secure Boot è una funzionalità di sicurezza di UEFI progettata per assicurare che, durante la fase di avvio, vengano eseguiti solo componenti considerati attendibili dal firmware. In pratica, UEFI verifica la firma digitale di elementi come bootloader, applicazioni EFI, driver UEFI e, in alcuni scenari, anche Option ROM. Se la firma non è valida o non rientra tra quelle fidate, l’esecuzione viene bloccata.

Per capire perché l’aggiornamento dei certificati è importante, serve una mini-mappa delle principali variabili/chiavi UEFI coinvolte:

• PK (Platform Key): radice di trust della piattaforma, tipicamente gestita dall’OEM.
• KEK (Key Exchange Key): autorizza gli aggiornamenti ai database di Secure Boot.
• DB (Signature Database): contiene firme/certificati consentiti (trusted).
• DBX (Revoked/Disallowed Signature Database): contiene firme/certificati revocati (da bloccare).

Il punto chiave per noi admin è che i certificati “giusti” devono essere presenti nel posto giusto (variabili UEFI come KEK/DB/DBX). Se la catena di trust non è aggiornata, un dispositivo può smettere di riconoscere come validi i componenti firmati con le nuove CA 2023, con impatti proprio sul percorso di avvio (boot manager e componenti pre-boot).

Ordine gerarchico della trust

Semplificando al massimo:

• La PK controlla chi è autorizzato a modificare il KEK.
• Il KEK (e in certi casi anche la PK) autorizza le modifiche a DB e DBX.

Se tentassimo di aggiornare DB/DBX in un contesto non compatibile, ad esempio in un dispositivo con firmware non aggiornato, prerequisiti mancanti, oppure impossibilità a scrivere correttamente le variabili UEFI, l’operazione può fallire oppure rimanere in uno stato intermedio (“pending”), richiedendo ulteriori passaggi (spesso un riavvio o un update firmware/OEM) per completarsi.

Figura 1: Diagramma gerarchico della sicurezza UEFI

Sistemi coinvolti

In linea generale, l’iniziativa riguarda sia macchine fisiche che virtuali (VM) che eseguono versioni supportate di Windows e hanno Secure Boot abilitato. Microsoft cita esplicitamente come “affected” le piattaforme (dal 2012 in poi) basate su Windows 10, Windows 11 e Windows Server (2012/2012 R2 fino alle release più recenti), includendo anche i rami LTSC.

Detto in modo più operativo, soprattutto se state pianificando una distribuzione gestita dall’IT con chiavi di registro o tooling enterprise, la documentazione Microsoft per l’approccio IT-managed elenca il supporto includendo, tra gli altri:

• Windows 10 (a partire da versione 1607, incluse varianti LTSC 2019/2021)
• Tutte le versioni supportate di Windows 11
• Windows Server 2016/2019/2022/2025
• Windows Server 2012 / 2012 R2
  in ESU (Extended Security Updates)

E i Copilot+ PC?

Microsoft indica come non interessati i Copilot+ PC rilasciati nel 2025. In pratica, rientrano nella fascia di dispositivi più recenti che tipicamente nascono già con la chain aggiornata nel firmware.
Ad ogni modo, per sicurezza e data la delicata natura del topic, se siete in possesso di questo tipo di dispositivi suggerirei comunque di fare qualche check per capire se sia necessario intervenire.

Sistemi operativi non-Windows e dual-boot

Microsoft segnala che l’impatto riguarda anche piattaforme non Windows (ad esempio macOS), ma specifica che è fuori dall’ambito del supporto Microsoft. Per i sistemi Linux in dual-boot con Windows, Microsoft evidenzia che Windows aggiornerà i certificati su cui quel percorso di boot fa affidamento.

Importante: “Windows aggiorna i certificati” non significa “Microsoft supporta Linux”. In scenari dual-boot è sempre buona norma testare in pilot, perché modifiche a DB/DBX possono influire sulla validazione dei bootloader/EFI component non-Windows.

I certificati in scadenza

La tabella seguente riepiloga i certificati Secure Boot Microsoft che scadono nel 2026 e i corrispondenti certificati 2023 introdotti per garantire continuità della catena di trust.

Figura 2: Riepilogo dei certificati Secure Boot in scadenza nel 2026 e delle nuove CA 2023

Sostanzialmente la KEK 2023 va in KEK (autorizza update a DB/DBX), mentre le UEFI/Option ROM CA 2023 vanno in DB (per aggiornare l’insieme di componenti considerati attendibili dal firmware). La separazione UEFI vs Option ROM serve a un controllo più granulare su cosa viene considerato attendibile dal firmware.
Questa tabella (e la nota sulla separazione tra UEFI CA e Option ROM) è riportata anche nella documentazione Microsoft.

Impatti e implicazioni

Vediamo quali sono i principali impatti, e le loro implicazioni, rispetto alla scadenza dei certificati per Secure Boot:

1. Rischio di perdita di aggiornabilità dei componenti di boot
   Microsoft è molto chiara su questo punto. Con l’avvicinarsi della scadenza delle CA “storiche” (chain 2011), i dispositivi che non completano la transizione potrebbero non essere più in grado di ricevere correttamente aggiornamenti e mitigazioni di sicurezza legati al percorso di avvio. L’effetto pratico è una riduzione della postura di sicurezza e possibili implicazioni su audit e compliance.
2. Compatibilità a rischio in scenari specifici (EFI/third-party/option ROM)
   In ambienti che includono dual boot, strumenti di recovery pre-OS, oppure componenti UEFI di terze parti (driver UEFI, applicazioni EFI, Option ROM), una chain di trust ferma alle CA 2011 può causare incompatibilità: il firmware potrebbe non riconoscere come attendibili componenti firmati secondo la nuova chain 2023, oppure applicare controlli/revoche non previsti se la transizione non è gestita correttamente.
3. Superficie d’attacco pre-OS nel tempo
   Il problema di sicurezza non è solo teorico; molte mitigazioni passano dalla possibilità di aggiornare i database DB/DBX e di evolvere la catena di trust man mano che emergono nuove minacce. Restare indietro significa ridurre la capacità di reazione contro attacchi che agiscono prima del caricamento del sistema operativo (dove le tradizionali difese “in-OS” non possono intervenire).

In termini pratici, senza transizione alle CA 2023:

• dopo giugno 2026 potreste perdere la capacità di applicare correttamente aggiornamenti e mitigazioni legate a Secure Boot (inclusi aspetti che impattano anche componenti EFI/terze parti), con possibili effetti su sicurezza e operatività
• entro ottobre 2026 aumenta il rischio di non poter ricevere correttamente fix di sicurezza che coinvolgono il Windows Boot Manager e componenti di boot firmati secondo la chain Windows (PCA → Windows UEFI CA 2023).

Cosa succede se non aggiornate

Un dispositivo non aggiornato potrebbe continuare ad avviarsi e funzionare anche senza completare la transizione alle nuove CA di Secure Boot. Il punto però non è il funzionamento di oggi, bensì è la capacità di rimanere manutenibile e sicuro nel tempo lungo la catena di avvio.

Il rischio principale è che, in futuro, alcune correzioni e mitigazioni legate a Secure Boot (ad esempio nuove firme, nuove revoche o aggiornamenti del Boot Manager) potrebbero non essere applicate correttamente o non essere considerate attendibili dal firmware. Questo si traduce in una perdita di aggiornabilità del percorso di boot. Dunque, il dispositivo potrebbe non riuscire a recepire nel modo previsto gli aggiornamenti che mantengono sicuro e verificabile l’avvio dei vostri dispositivi.

Per questo il nostro suggerimento è quello di non aspettare fino all’ultimo momento e pianificare l’aggiornamento con largo anticipo, evitando di dover intervenire in urgenza su un ambito delicato come firmware/boot. L’approccio che suggeriamo è: pilot su dispositivi rappresentativi e poi rollout a ring, perché l’esito dipende dal firmware e possono esistere incompatibilità su alcune piattaforme. Approfondiremo questo aspetto più avanti nell’articolo.

Importante: Perdita di aggiornabilità significa che, anche se Windows continua ad avviarsi, il device non riuscirebbe più ad accettare/applicare (o il firmware non considera attendibili) futuri aggiornamenti del trust store UEFI e del boot path. In pratica resteremmo bloccati su una chain obsoleta e non più manutenibile come previsto. Oltre alla sicurezza e alla compliance, come sopraccitato, può emergere anche un tema di compatibilità. I componenti UEFI firmati con le nuove CA potrebbero non risultare attendibili su firmware non aggiornati, con possibili comportamenti anomali in specifici scenari (ad esempio problemi di avvio o blocchi).
Questo significa che alcuni firmware potrebbero necessitare di un aggiornamento a versioni più recenti prima di poter procedere con la transizione ai nuovi certificati per Secure Boot.

Metodi disponibili per l’aggiornamento

Passiamo adesso all’atto pratico. Microsoft descrive diversi approcci per distribuire e controllare l’aggiornamento dei certificati Secure Boot, a seconda di come gestite i dispositivi (ma anche server e VM) e gli update:

• Distribuzione “assistita” tramite update (Microsoft-managed/Controlled Feature Rollout, con sufficiente livello di telemetria attivo)
  
• Distribuzione controllata via Registry Keys (utile per i test manuali o troubleshooting)
  
• Group Policy o SCCM (per le infrastrutture più AD-first)
  
• WinCS
  
• Microsoft Intune
  

Importante: scegliete un unico metodo principale per i vostri device (es. Intune, GPO oppure script, ecc..) e usatelo end-to-end. Mescolare più approcci rende più difficile capire chi ha impostato cosa e in che ordine. Inoltre, ricordate che, una volta applicati i certificati al firmware, non possono essere rimossi da Windows; eventuali operazioni di “pulizia” dovranno necessariamente passare dall’interfaccia firmware.

Come usare Microsoft Intune (Settings catalog) per avviare e gestire l’aggiornamento

Da dicembre 2025 Microsoft ha pubblicato la procedura ufficiale per gestire queste impostazioni tramite Microsoft Intune usando i Settings catalog, includendo tre opzioni: una per il trigger dell’aggiornamento e due per la gestione degli “assist” da parte di Microsoft stessa (deploy via high confidence o Microsoft-managed rollout).
Come anticipato nell’introduzione, in questo articolo vedremo come distribuire la soluzione tramite Intune, con un focus specifico sui client Windows. È importante però ribadire che la transizione dei certificati Secure Boot riguarda anche Windows Server e, in generale, le macchine virtuali (VM); anche se cambiano gli strumenti di distribuzione e di gestione, il principio e gli obiettivi dell’aggiornamento restano gli stessi.

Prima di proseguire, però, è bene spiegare nel dettaglio i tre settings principali coinvolti in questo processo, al fine di poter configurare la policy in totale confidenza ed in base alle proprie esigenze.

• Configure High Confidence Opt-Out
  

  Questa impostazione serve per escludere esplicitamente i dispositivi dal meccanismo automatico di aggiornamento attraverso gli update mensili, anche se Microsoft li ha classificati come “high confidence” (ovvero noti per supportare bene l’update firmware). In altre parole, impostandola su Enabled si blocca l’applicazione automatica dei certificati tramite Windows Update, richiedendo l’intervento manuale dell’IT. Di default è Disabled, il che significa che i device considerati compliant da Microsoft procederanno con l’aggiornamento automatico quando incluso nelle patch mensili. Potreste valutare di abilitarla solo per quei gruppi di pc su cui volete rimandare l’update automatico (ad esempio hardware critico non ancora testato con le nuove chiavi), così da controllare manualmente tempi e modi dell’aggiornamento. Se invece il vostro obiettivo è lasciare che Microsoft gestisca il rollout, questa opzione va tenuta disabilitata (default) in modo da non effettuare alcun opt-out.

• Configure Microsoft Update Managed Opt-In
  

  Questa policy consente di optare per l’intervento automatico di Microsoft nel distribuire gli aggiornamenti Secure Boot. Se la si imposta su Enabled, si segnala che i dispositivi parteciperanno al Controlled Feature Rollout gestito da Microsoft. Per funzionare richiede che il device invii i dati diagnostici obbligatori a Microsoft (vedi impostazioni telemetria). Tenete presente che per impostazione predefinita questa opzione è Disabled, ovvero se non la toccate i device non daranno automaticamente consenso al rollout assistito. A meno che non preferiate gestire totalmente in autonomia la distribuzione delle chiavi, questa impostazione andrà abilitata. Abilitandola, Microsoft potrà includere quei device nel rilascio graduale tramite gli aggiornamenti mensili di Windows (come descritto nella sezione precedente). Se invece avete motivi per non voler l’aggiornamento automatico, potete lasciarla disabilitata, in tal caso dovrete assicurarvi di effettuare l’aggiornamento delle chiavi tramite l’impostazione successiva (o via script) in modo controllato.

• Enable SecureBoot Certificate Updates
  Questa impostazione, se abilitata, farà sì che Windows inizi automaticamente il processo di distribuzione dei nuovi certificati Secure Boot sul dispositivo. In pratica abilita il trigger di aggiornamento: equivale internamente a impostare la chiave di registro AvailableUpdates con il valore adatto per installare tutti gli aggiornamenti necessari (bitfield 0x5944 che include aggiunta nuove CA 2023, aggiornamento KEK e installazione nuovo boot manager). Vedremo più nel dettaglio queste impostazioni al capitolo Troubleshooting di questa guida.

Queste tre impostazioni le vedremo a breve (Figura 6). Ciò detto, vediamo step-by-step come utilizzare i Settings Catalog per gestire efficacemente l’aggiornamento dei certificati Secure Boot tramite l’aggiornamento in modo controllato.

Ciò detto, vediamo adesso come procedere con Intune.
Come prima cosa, accedere al Microsoft Intune Admin Center e navigare in Devices > Configuration. Successivamente cliccare su Create > New Policy

Figura 3: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 1

Scegliere come Piattaforma Windows 10 and later. Come Tipo di profilo selezionare Settings Catalog e procedete cliccando su Create.

Figura 4: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 2

Nella sezione Basics, assegnare un nome al profilo (ad es. “Manage Secure Boot certificates”), una descrizione (facoltativo) e procedere cliccando su Next

Figura 5: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 3

Nella sezione Configuration settings, cliccare Add settings. Nel campo di ricerca digitare “Secure Boot“, fare click su Search e, quando apparirà, selezionare la categoria Secure Boot. Compariranno le tre impostazioni disponibili viste in precedenza (Configure High Confidence Opt-Out, Configure Microsoft Update Managed Opt-In e Enable SecureBoot Certificate Updates).

Figura 6: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 4

In questo esempio proseguiremo configurando l’impostazione Enable SecureBoot Certificate Updates che, come indicato in precedenza, farà sì che Windows inizi automaticamente il processo di distribuzione dei nuovi certificati Secure Boot
Selezioniamolo tramite l’apposita checkbox; a sinistra apparirà il toggle button da abilitare. Una volta che l’impostazione sarà Enabled, continuare cliccando su Next.

Figura 7: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 5

Nella sezione Scope tags (opzionale) lasciare Default, oppure selezionare uno scope tags già creato in precedenza nel vostro ambiente Intune. Nel nostro caso lasceremo quello di default. Successivamente cliccate su Next.

Figura 8: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 6

A questo punto, nella sezione Assignments, possiamo assegnare la nostra policy al gruppo desiderato (consigliato). In alternativa è possibile includere tutti gli utenti o tutti i dispositivi (sconsigliato).

Per distribuire ad un gruppo specifico fare click su Add groups, cercare il gruppo desiderato, selezionarlo con l’apposita checkbox ed infine fare click su Select.

Figura 9: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 7

Sempre nella pagina di Assignments potete verificare che il gruppo selezionato è stato aggiunto alla lista Included groups. Se volete aggiungere altri gruppi o aggiungere filtri è il momento giusto, altrimenti continuare cliccando nuovamente su Next.

Figura 10: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 8

Arrivati alla sezione Review + create, verificate che tutti i dettagli della policy siano corretti, inclusi i gruppi di assegnazione. Se è tutto ok, proseguire cliccando su Create.

Figura 11: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 9

Se avete configurato tutto correttamente, la policy verrà creata con successo.

Figura 12: Creazione policy tramite Settings Catalog di Microsoft Intune – Parte 10

Tornate in Devices > Configuration e troverete la nuova policy correttamente creata e assegnata. Da qui potrete anche modificarla qualora fosse necessario.

Figura 13: Overview della policy creata tramite Settings Catalog

Entro breve tempo, Intune applicherà i criteri ai dispositivi del gruppo target. Potete monitorare lo stato di distribuzione direttamente dalla console di Intune oppure eseguire una verifica puntuale su un campione di dispositivi pilota, ad esempio controllando che i valori attesi delle chiavi di registro (che vedremo a breve) siano stati impostati correttamente e/o consultando l’Event Viewer per confermare che il processo di aggiornamento dei certificati sia partito regolarmente o si sia già concluso con successo.

Importante:
esiste una Known Issue in riferimento al deploy di questa configurazione tramite Intune che affligge l’edizione di Windows Pro. Applicare questa policy tramite Intune su dispositivi con questa edizione può mostrare un errore 65000 (ahimé, classico errore generico). Al momento non esiste un workaround al problema, e sarà nostra cura integrare la fix non appena ci saranno novità in merito. Nel frattempo vi rimandiamo al link Microsoft in cui è citata la Issue. Se la piattaforma è Pro e la issue si manifesta, valuta metodi alternativi (GPO/registry) per il rollout (ne parliamo al capitolo Alternative al Settings Catalog di Microsoft Intune).

Troubleshooting

Passiamo adesso su un dispositivo al quale è stata applicata la policy per verificare che cosa succede nel dettaglio.
Come citato in precedenza, ci sono vari approcci per verificare se la policy si sia applicata correttamente e che le operazioni di aggiornamento dei certificati per Secure Boot si siano avviate senza problemi.

In questa sezione vedremo i tre metodi principali con i quali vi consigliamo di strutturare un buon troubleshooting:

• Registro di sistema
• Event Viewer
• PowerShell

Registro di sistema

Per cominciare, vediamo che cosa succede nel Registro di sistema di Windows.
L’impostazione Enable SecureBoot Certificate Updates distribuita tramite Intune (vedi Figura 6), applicherà il valore 0x5944 (hex) alla chiave di registro AvailableUpdates presente al percorso HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

Importante: se il valore è 0 (default), significa che la policy non è ancora stata applicata. In questo caso attendere finché la configurazione non verrà distribuita, a quel punto il valore di AvailableUpdates verrà impostato su 0x5944 (valore iniziale).

Figura 14: Verifica della chiave di registro AvailableUpdates con valore iniziale 0x5944

Ma cosa succede esattamente? Qual è il processo dietro al completamento dell’aggiornamento dei certificati?

Windows gestisce un’attività pianificata denominata Secure-Boot-Update, che potete trovare al percorso \Microsoft\Windows\PI del Task Scheduler di sistema e che viene eseguita ogni 12 ore. Tale attività cerca i bit nella chiave di registro AvailableUpdates che necessitano di essere elaborate; quindi, ciascuno dei bit viene elaborato in ordine, fino al completamento dell’attività.

Figura 15: Attività pianificata Secure-Boot-Update

Dopo l’elaborazione dei primi bit, quando la chiave AvailableUpdates avrà raggiunto il valore 0x4100 il sistema necessiterà di un riavvio per completare il task.

Nota bene: Il riavvio non viene notificato da Windows.

Figura 16: AvailableUpdates impostato a 0x4100 (reboot necessario per completare l’operazione)

Una volta riavviato il dispositivo, se l’operazione è stata completata con successo e senza errori, il valore di AvailableUpdates si sarà impostato su 0x4000; sintomo che l’operazione è andata a buon fine.

Figura 17: AvailableUpdates impostato a 0x4000 (operazione completata con successo)

Importante: Come è possibile notare, il valore di AvailableUpdates tende a decrescere man mano che i bit vengono processati e puliti dal task Secure-Boot-Update. Microsoft descrive una progressione tipica, da 0x5944 fino ad arrivare a 0x4100 (reboot) ed infine 0x4000. Quindi, una volta completata correttamente l’operazione associata a un bit, tale bit viene cancellato dalla chiave AvailableUpdates.

Figura 18: Progressione dei bit, partendo dal valore 0x5944, fino ad operazione completato (0x4000)

Un altro ottimo modo per verificare l’andamento dell’operazione consiste nel consultare la chiave di registro UEFICA2023Status, che possiamo trovare al percorso HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing.
I tre valori possibili per questa chiave possono essere:

• NotStarted à l’aggiornamento non è ancora iniziato
• InProgress à l’aggiornamento è in corso (rimane in questo stato anche se si è nella fase di reboot pending citata in precedenza)
• Updated à l’aggiornamento è stato completato con successo

Ricapitolando, inizialmente lo stato della chiave UEFICA2023Status sarà impostato su NotStarted. Cambia in InProgress una volta avviato l’aggiornamento (e rimarrà così fino al completamento del riavvio del dispositivo), ed infine cambierà in Updated quando tutte le nuove chiavi e il nuovo boot manager saranno stati distribuiti.

Figura 19: Valore UEFICA2023Status = Updated à Aggiornamento completato con successo

Allo stesso percorso HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing, in caso di errori durante l’aggiornamento, è possibile che appaia una nuova chiave di registro denominata UEFICA2023Error.

In caso di errori iniziali e che vengono poi risolti in autonomia durante l’aggiornamento o riavvio del pc, questa chiave avrà come valore 0. In caso il codice di errore sia diverso da 0, è possibile verificare più nel dettaglio nell’event viewer (vedi capitolo successivo Event viewer).

Nell’immagine seguente (Figura 20), possiamo notare che il codice di errore della chiave UEFICA2023Error è 0 e che UEFICA2023Status ha come valore “Updated“; questo è uno scenario tipico che potreste ritrovare su molti dispositivi.

In questo caso state tranquilli, l’operazione di aggiornamento è andato a buon fine; i problemi possono esserci solamente se il valore UEFICA2023Error è diverso da 0.

Figura 20: Valore UEFICA2023Error = 0 à Nessun errore durante l’aggiornamento o errori risolti in autonomia (es. durante il reboot del dispositivo)

Event viewer

La chiave di registro UEFICA2023Error che ha un valore diverso da 0, da sola non è sufficiente per capire quale problema stiamo affrontando. Infatti, un altro modo per verificare step-by-step che cosa succede è sicuramente la verifica dei log di sistema tramite Event Viewer.

Vediamo nel dettaglio dove controllare e quali sono gli eventi più rilevanti per capire dove può risiedere il problema.

Innanzitutto, apriamo l’Event Viewer e posizioniamoci su Registri di Windows > Sistema. A questo punto filtriamo i nostri eventi sulla base dell’origine eventi TPM-WMI e fare click su “Ok“.

Figura 21: Filtro “Origine eventi” TPM-WMI in Registri di Windows
à
Sistema

A questo punto otterrete in output tutti gli eventi con origine TPM-WMI: troverete eventi informativi, avvisi e, nei casi più critici, errori che indicano perché l’aggiornamento non è andato a buon fine. L’elenco completo degli Event ID relativi a questo scenario è disponibile alla pagina Secure Boot DB and DBX variable update events – Microsoft Support.

Per facilitarvi il lavoro, qui sotto trovate una versione più user friendly in chiave operativa, che descrive il loro significato e l’azione consigliata per interpretarli rapidamente.

Tabella 1: Summary degli Event ID per TPM-WMI

PowerShell

Se siete persone più da riga di comando, adesso vediamo come usare PowerShell per fare troubleshooting su un client pilota e capire, in modo oggettivo, se:

• Secure Boot è attivo (prerequisito di tutta l’attività)
• la configurazione distribuita è arrivata sul device
• il task schedulato sta lavorando
• gli eventi TPM-WMI indicano avanzamento, completamento o errori

L’approccio migliore è sempre lo stesso, ovvero partire dai prerequisiti, verificare il trigger, controllare stato ed errori, e solo alla fine leggere gli eventi.

Importante: eseguite i comandi in una console PowerShell avviata come amministratore. In un pilota è la scelta più “pulita” perché vi evita falsi negativi su task/registro/log.

Verifica Secure Boot attivo

Innanzitutto, verifichiamo se il Secure Boot è attivo sul dispositivo. Per farlo, è sufficiente eseguire il seguente comando:

Se l’output è True, potete proseguire. Se l’output è False o ricevete un errore, in tutta probabilità il dispositivo non ha Secure Boot attivo.

Figura 22: Esecuzione comando Confirm-SecureBootUEFI in PowerShell

Verifica configurazione distribuita sul device

A questo punto, se Confirm-SecureBootUEFI restituisce True, passiamo alla domanda successiva: il device ha recepito il trigger di aggiornamento?
Il modo più rapido per capire se la policy è arrivata è controllare il valore AvailableUpdates nel registro di sistema. Come visto in precedenza, questa chiave conterrà il valore “trigger” operativo che Windows usa per avviare il processo tramite l’attività pianificata Secure-Boot-Update (vedi Figura 15).
Vediamo come verificare il contenuto di questa chiave con PowerShell.

Eseguite il comando:

Figura 23: Verifica valore AvailableUpdates con Powershell (output decimale)

Come potete notare, l’output di AvailableUpdates viene riportato in formato decimale. Tuttavia, vi consigliamo di lavorare con valori in esadecimale, poiché tutta la documentazione Microsoft riporta i valori in questo formato (vedi Figura 18). Per ottenere l’output in formato esadecimale, possiamo dunque utilizzare questi comandi:

Figura 24: Verifica valore AvailableUpdates con Powershell (output esadecimale)

A questo punto, in base al valore ottenuto in output, possiamo capire in quale stato è il nostro device. Nell’esempio riportato sopra, il valore riportato è 0x4000, il che significa che l’attività di aggiornamento è stata completata con successo (vedi Figura 18 per consultare i valori attesi).

Verifica dello stato di UEFICA2023Status e UEFICA2023Error

Una volta verificato che il trigger è presente, la domanda diventa: a che punto è il processo?
Abbiamo già visto in precedenza (al capitolo Registro di sistema) che ci sono due valori molto utili a questo scopo: UEFICA2023Status e UEFICA2023Error

Per i motivi già citati, mostriamo queste informazioni mantenendo l’output in formato esadecimale:

Figura 25: Verifica stato delle chiavi UEFICA2023Status e UEFICA2023Error con PowerShell

In questo caso, possiamo notare che UEFICA2023Status e UEFICA2023Error mostrano rispettivamente il valore “Updated” e “0x0“, sinonimo del fatto che l’attività è stata completata con successo.

Verifica degli eventi TPM-WMI

Come ulteriore step, possiamo leggere gli eventi senza l’ausilio della UI di Event Viewer. Come visto precedentemente, questi eventi sono nel log System ed il provider è TPM-WMI.
Per ottenere gli eventi con PowerShell possiamo utilizzare un breve script. In questo esempio vedremo come ottenere gli Event ID specifici che ci interessano, generati nell’arco degli ultimi 30 giorni.
Se volete aumentare o ridurre il range temporale di riferimento, è sufficiente modificare la variabile $start.

Figura 26: Verifica lista di Event ID in TPM-WMI con PowerShell

Gestione dei reboot

Come citato in precedenza, durante la transizione alle CA 2023 capiterà sicuramente che un dispositivo arrivi ad uno stato intermedio in cui la prima fase è stata applicata correttamente, ma è richiesto un riavvio per completare il processo.

In questi casi AvailableUpdates assume il valore 0x4100, che indica di fatto una condizione di reboot pending.

Questo non è un errore, anzi, è un passaggio atteso del processo. La differenza in questa fase la farà la vostra capacità di gestire il riavvio in modo controllato, evitando impatti indesiderati sugli utenti finali e rendendo il rollout “chiudibile” (cioè misurabile fino al completamento).

Dal mio punto di vista, il metodo più semplice e meno invasivo è quello di agganciare il riavvio al ciclo di patching mensile (Windows Update ring/maintenance window già esistenti). In questo modo ridurrete sensibilmente la necessità di introdurre reboot extra, che si sa, non sono mai piacevoli per gli utenti.

Check con il vostro OEM di riferimento

Quando si parla di Secure Boot, una parte della catena di trust vive nel firmware. Per questo, nelle transizioni di piattaforma (come quella delle CA 2011 → CA 2023), il ruolo dell’OEM è fondamentale. Microsoft ha dichiarato di aver lavorato a stretto contatto con i principali produttori per pianificare e validare in anticipo questa migrazione, così da ridurre al minimo i rischi di incompatibilità e garantire che i dispositivi restino sicuri e aggiornabili.

Di seguito le pagine OEM di riferimento per Secure Boot, citate nelle documentazioni Microsoft:

• Dell
• HP
• Lenovo
• Microsoft Surface

Alternative al Settings Catalog di Microsoft Intune

Anche se in questo articolo mi sono concentrato principalmente sulla distribuzione tramite Settings Catalog di Microsoft Intune, questa non è l’unica strada possibile. Come anticipato nella sezione Metodi disponibili per l’aggiornamento, esistono altre opzioni valide.

Remediation script di Microsoft Intune

Prima di abbandonare la soluzione via Intune, è bene menzionare che questo prodotto ci viene nuovamente incontro mediante l’utilizzo dei remediation script, che permettono di combinare verifica e correzione in modo strutturato.
Per questo scenario ho pubblicato sul mio GitHub una coppia di script completa e pronta all’uso, per gestire l’aggiornamento dei certificati Secure Boot. Anche questa soluzione si basa sull’approccio Enable SecureBoot Certificate Updates (registro/trigger), non sull’adesione al canale Controlled Feature Rollout gestito da Microsoft.
Trovate le istruzioni complete nel file README.md

GPO

Per ambienti gestiti principalmente on-premises, un approccio naturale è quello di distribuire questa configurazione tramite GPO.
Per la configurazione via GPO vi rimandiamo alla documentazione Microsoft.

SCCM (ConfigMgr)

Un’ altra valida alternativa per ambienti gestiti on-premises è SCCM. Se optate per questa soluzione, vi suggerisco anche in questo caso di adottare l’approccio Enable SecureBoot Certificate Updates e di strutturare il tutto in questo modo:

• Fase pilota
  
  • Creazione device collection contenente qualche device di test (meglio diversificare per modello/hardware)
  • Creazione script “one shot” per un primo test rapido e controllato (in Software Library > Scripts) che esegua:
    • Verifica Secure Boot attivo
    • Verifica dello stato della chiave AvailableUpdates e gestisca i casi principali
      • Ad esempio, se AvailableUpdates = 0x4100 (reboot pending) non serve intervenire
    • Verifica dello stato delle chiavi UEFICA2023Status e UEFICA2023Error
      • Se UEFICA2023Status = “In Progress” o “Updated” non intervenire
      • Se UEFICA2023Status = “NotStarted” imposta chiave di registro AvailableUpdates con il valore 0x5944
    • (Opzionale) avvio del trigger Secure-Boot-Update (in alternativa potete attendere ed il trigger si avvierà da solo entro le canoniche 12 ore)
      • (Consigliato) verifica degli eventi TPM-WMI, utile anche per distinguere quali dispositivi hanno completato la prima fase e necessitano di un riavvio per completare l’attività
  • Deploy dello script ai devices della collection appena creata e analisi degli output
• Produzione
  
  • Creazione Configuration Item (in Assets and Compliance > Compliance Settings > Configuration Items)
    • Creazione discovery script
    • Creazione remediation script
    • Creazione compliance rules
  • Creazione Configuration Baseline per la distribuzione delle impostazioni (in Assets and Compliance > Compliance Settings > Configuration Baselines)
  • Creazione di più device collection di produzione per la gestione dei vari ring
  • Deploy della Baseline con approccio a ring
• Monitoraggio
  
  • Verifica periodica della percentuale di compliance dei vari ring
    
  • (Consigliato) Creazione custom report
    
  • (Consigliato) Creazione e deploy script “one shot” per il troubleshooting (es. verifica eventi TPM-WMI e
    dello stato delle chiavi UEFICA2023Status e UEFICA2023Error)
    

Importante: se lo ritenete necessario, potete distribuire la baseline anche ad un secondo gruppo pilota (prima della fase di deploy in produzione). Suggerisco però di partire da uno script “one shot” per una prima verifica rapida.

Se vi servono un discovery script e un remediation script per questo scenario tramite Configuration Baseline per SCCM, potete partire anche da quelli citati per Microsoft Intune (vedi GitHub); in caso di utilizzo con SCCM, però, vanno adattati.
La differenza principale è che in SCCM la compliance non è guidata dagli exit code come in Intune, ma dalle Compliance Rules del Configuration Item: il discovery script deve restituire un valore valutabile (ad esempio Compliant/Non-compliant) e la remediation viene eseguita solo quando la regola risulta non conforme. Inoltre, l’output testuale non è “centrale” come nei report di Intune. Conviene evitare log (specialmente se troppo verbosi) e, soprattutto, usare con cautela exit 1, perché può essere interpretato come errore di esecuzione piuttosto che come “non conformità”.

Riepilogo e checklist operativa

Prima di chiudere, facciamo nuovamente ordine con una checklist pratica per ridurre i rischi e aumentare la percentuale di successo durante tutta l’attività.
L’obiettivo è quello di scegliere un metodo, validarlo su un pilot rappresentativo, infine scalare mantenendo il pieno controllo.

• Decidete in anticipo quale approccio utilizzare in base alla struttura del vostro ambiente target (Intune, GPO, SCCM, ecc.)
  • Scegliete solamente un metodo per questa attività. Mescolare approcci rende più difficile capire chi ha impostato cosa e in quale ordine.
• Scegliete un pool di 5-10 dispositivi pilota sui quali testare la soluzione scelta (se avete più modelli hardware, vi suggerisco di diversificare la vostra scelta e non utilizzare solo un modello per i test)
• Predisponete la soluzione scelta e distribuitela sui dispositivi di test
• Analizzate la situazione (come visto al paragrafo Troubleshooting) e poniamoci le domande corrette:
  • Il Secure Boot è effettivamente attivo?
  • È necessario aggiornare il firmware su alcuni modelli prima di procedere?
  • Serve coinvolgere l’OEM (errori persistenti, KEK/UEFI variabili non aggiornabili, ecc.)?
  • Il processo segue il flusso atteso dall’inizio alla fine?
• Se necessario estendete il pilota ad un altro gruppo di 5-10 dispositivi
• Quando siete sicuri, potrete distribuire la soluzione a tutti i dispositivi in produzione
  • Suggerisco un approccio di deploy a ring (es. 5% → 20% → 50% → 100%), mantenendo sempre la possibilità di fermare il deploy e correggere rapidamente eventuali anomalie
• Gestite i reboot dei pc in modo smart e non invadente (rivedi capitolo Gestione dei reboot)
• Monitoraggio continuo
  • Tenete sotto controllo gli stati intermedi, i dispositivi in errore e soprattutto i casi di reboot pending (AvailableUpdates = 0x4100), che spesso sono la differenza tra “InProgress” e “Updated“.

Importante: se in azienda avete hardware recente, non date per scontato che l’attività non vi riguardi. Anche in presenza di modelli nuovi, è essenziale verificare lo stato reale della chain di trust e la corretta applicazione degli aggiornamenti, soprattutto in ambienti misti e con più generazioni di dispositivi.

FAQ

Il 10 dicembre 2025, Microsoft ha ospitato una sessione AMA (Ask Microsoft Anything) nei propri canali Tech Community in riferimento a questo argomento.
Se volete recuperare la diretta la potete trovare a questo link. Nei commenti della pagina potete trovare anche un utile riepilogo delle principali Q&A (vedi commento della Community Manager).

Conclusioni

L’aggiornamento delle CA per Secure Boot non è un detail tecnico, bensì un’attività di continuità operativa e compliance, perché mantiene aggiornabile e sicura la catena di boot quando i certificati 2011 inizieranno a scadere a giugno 2026.
Come avrete potuto leggere, non serve “spingere un bottone e sperare”. Serve un rollout controllato, osservabile e ripetibile. E con gli strumenti giusti (Intune/GPO/registro + log + PowerShell), questa attività risulterà molto più gestibile di quanto sembri a prima vista.