Secure Boot Windows: guida alla creazione e gestione delle chiavi UEFI — e perché il 2026 è una scadenza critica

2

Come funziona l’architettura di sicurezza che protegge ogni PC Windows dal primo istante di accensione, e cosa devono fare OEM, aziende e utenti consumer prima che i certificati del 2011 scadano.

Che cos’è il Secure Boot e perché è così importante

Ogni volta che accendiamo un PC Windows, prima ancora che il logo di Windows compaia sullo schermo, il firmware UEFI esegue una serie di controlli crittografici silenziosi. Questi controlli formano ciò che Microsoft chiama Secure Boot: un meccanismo standardizzato dall’industria che verifica la firma digitale di ogni componente software caricato durante la fase di avvio.

L’obiettivo è preciso: impedire l’esecuzione di codice non firmato o manomesso prima che il sistema operativo prenda il controllo. Senza questa protezione, un aggressore potrebbe installare un rootkit o un bootkit — malware che si annida nel processo di avvio, invisibile agli antivirus e ai controlli di sicurezza ordinari, e che persiste anche dopo la reinstallazione del sistema operativo.

Secure Boot è basato sull’infrastruttura a chiave pubblica (PKI) ed è parte dell’architettura Windows Trusted Boot. Microsoft lo richiede su tutti i PC certificati per Windows 8 e versioni successive.

L’architettura PKI di Secure Boot: le chiavi e i database

Il cuore tecnico del Secure Boot è un sistema gerarchico di chiavi crittografiche e database di firme, tutti memorizzati nella RAM non volatile (NV-RAM) del firmware UEFI durante la fase di produzione del PC.

Platform Key (PK) — la chiave radice

La Platform Key è il vertice della catena di fiducia. Stabilisce la relazione di trust tra il proprietario della piattaforma (tipicamente l’OEM, cioè il produttore del PC) e il firmware. È con la PK che vengono autenticate tutte le operazioni successive sulla piattaforma.

Un PC con una PK installata si trova in “User Mode“: il Secure Boot è attivo e tutte le modifiche al firmware o ai database richiedono l’autenticazione tramite la PK.

Key Enrollment Key (KEK) — la chiave di gestione

La KEK si trova un livello sotto la PK e serve a firmare gli aggiornamenti ai database di firma (DB e DBX). Microsoft richiede che ogni PC contenga almeno una sua KEK nel database KEK, in modo da poter aggiornare in futuro i database con nuovi sistemi operativi attendibili o revocare immagini compromesse. OEM e aziende possono aggiungere le proprie KEK per gestire i propri aggiornamenti.

Signature Database (DB) e Revoked Database (DBX)

Il DB (Allowed Signatures Database) contiene le firme o gli hash delle immagini UEFI, dei bootloader e dei driver considerati attendibili. Solo il codice presente in questo database può essere eseguito durante il boot. Il DBX (Forbidden Signatures Database) è l’opposto: contiene le firme revocate, ovvero immagini che non devono mai essere caricate anche se un tempo erano considerate sicure. In caso di conflitto tra DB e DBX, ha sempre la precedenza il DBX.

Questi quattro elementi — PK, KEK, DB, DBX — formano la spina dorsale del Secure Boot. La documentazione ufficiale Microsoft su Microsoft Learn fornisce guidance dettagliata agli OEM e agli ODM su come creare, archiviare e gestire questi elementi in un ambiente di produzione industriale, compresa la gestione di chiavi di aggiornamento firmware sicuro e di KEK di terze parti.

Come funziona il processo di verifica al boot

All’avvio, il firmware UEFI esegue in sequenza questi passaggi:

1. Verifica la firma del firmware stesso (Option ROMs, driver UEFI) contro il DB e il DBX.
2. Verifica il bootloader del sistema operativo (es. Windows Boot Manager).
3. Se tutte le verifiche passano, cede il controllo al sistema operativo.
4. Se una verifica fallisce, il firmware avvia procedure OEM-specifiche di recupero o remediation.

Da questo punto in poi entra in gioco l’architettura Trusted Boot di Windows: il kernel verifica i driver, poi carica il software antimalware, e infine inizializza tutti gli altri processi in user mode. È una catena di fiducia che si estende dall’hardware fino alle applicazioni.

Il ruolo degli OEM: dalla fabbrica al consumatore

La responsabilità della corretta implementazione del Secure Boot ricade primariamente sugli OEM (Original Equipment Manufacturer), cioè i produttori di PC. Durante la fase di produzione, l’OEM deve:

• Generare o procurarsi le chiavi crittografiche (PK, KEK) in un ambiente sicuro, tipicamente tramite un Hardware Security Module (HSM).
• Programmare i database DB e DBX nel firmware del dispositivo, includendo i certificati Microsoft richiesti.
• Bloccare il firmware dalla modifica, eccetto per aggiornamenti firmati con la chiave corretta o operazioni eseguite fisicamente dall’utente tramite i menu UEFI.
• Assicurarsi che tutti i driver e le option ROM inclusi nel dispositivo siano firmati e inclusi nel DB.

Microsoft mette a disposizione nel suo repository open-source Secure Boot i binari raccomandati per PK, KEK, DB e DBX, già formattati secondo le specifiche EDKII per una semplice integrazione nel firmware. Gli OEM possono utilizzare questi binari come punto di partenza per le loro implementazioni.

L’urgenza del 2026: i certificati del 2011 stanno scadendo

⚠  SCADENZA CRITICA

Il certificato Microsoft Corporation KEK CA 2011 e altri certificati Secure Boot emessi nel 2011 iniziano a scadere a partire da giugno 2026. Tutti i dispositivi interessati devono ricevere i nuovi certificati 2023 prima di questa data per evitare interruzioni del boot.

I certificati crittografici, come tutti i certificati X.509, hanno una data di scadenza. Quelli utilizzati da Microsoft per firmare il Secure Boot risalgono al 2011 — all’epoca in cui il Secure Boot fu introdotto con Windows 8. Quasi 15 anni dopo, è arrivato il momento del rinnovo.

Microsoft ha già iniziato il processo di transizione verso i nuovi certificati denominati Windows UEFI CA 2023, Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023. I PC prodotti dal 2024 in poi includono già i nuovi certificati. Per i dispositivi più vecchi, Microsoft distribuisce gli aggiornamenti tramite Windows Update.

Cosa succede se non si aggiorna in tempo

Se un dispositivo non riceve i nuovi certificati prima della scadenza dei vecchi, potrebbe non riuscire ad avviare correttamente il sistema operativo o i componenti firmware firmati con i vecchi certificati. In un contesto aziendale, questo potrebbe tradursi in interruzioni operative su larga scala.

Chi deve fare cosa

• OEM/ODM: devono creare, firmare e distribuire aggiornamenti firmware che includano i nuovi certificati KEK 2023, rispettando le linee guida Microsoft.
• Aziende e IT manager: devono inventariare i dispositivi, applicare prima gli aggiornamenti firmware OEM e poi procedere con il deploy dei nuovi certificati tramite Intune, Group Policy o registry keys.
• Utenti consumer: per la maggior parte dei casi non è richiesta azione manuale — Microsoft aggiornerà automaticamente i dispositivi ad alta confidenza tramite Windows Update. È sufficiente mantenere il sistema aggiornato e il Secure Boot attivo.

Il playbook Microsoft per gli IT manager: 5 passi operativi

Microsoft ha pubblicato un playbook dettagliato per guidare le organizzazioni nel processo di aggiornamento dei certificati Secure Boot. Ecco i cinque step principali:

Step 1 — Inventario e preparazione dell’ambiente

Il primo passo è capire quanti e quali dispositivi sono coinvolti. La maggior parte dei PC prodotti dal 2012 in poi ha già il Secure Boot attivo, ma è necessario verificarlo. Microsoft consiglia di controllare il valore della registry key UEFICA2023Status e di utilizzare i comandi PowerShell di inventario disponibili nella documentazione ufficiale. Chi usa Windows Autopatch ha a disposizione un nuovo report dedicato allo stato del Secure Boot.

Step 2 — Monitoraggio dello stato dei certificati

Una volta completato l’inventario, occorre identificare i dispositivi non ancora aggiornati e costruire un campione rappresentativo per pilotare l’aggiornamento. Particolare attenzione va ai dispositivi meno comuni, per i quali la determinazione di alta confidenza non è automatica.

Step 3 — Aggiornamenti firmware OEM prima degli aggiornamenti Microsoft

Questo è un passaggio critico spesso sottovalutato: prima di applicare i nuovi certificati Secure Boot tramite Windows Update o strumenti MDM, è fondamentale assicurarsi che il firmware del dispositivo sia già stato aggiornato dall’OEM. Se il firmware non è pronto, l’aggiornamento dei certificati può fallire con errori come Event ID 1795 nel registro eventi di sistema.

Step 4 — Deploy dei certificati

Microsoft mette a disposizione quattro modalità di deployment:

• Microsoft Intune (modalità raccomandata): tramite CSP per dispositivi gestiti via MDM.
• Registry keys: impostando il valore della chiave AvailableUpdates a 0x5144 per distribuire tutti i certificati necessari e aggiornare il boot manager firmato con Windows UEFI CA 2023.
• WinCS (Windows Configuration System APIs): nuovi strumenti command-line disponibili per client Windows 11 domain-joined su versioni 23H2, 24H2 e 25H2.
• Group Policy: tramite il percorso Computer Configuration > Administrative Templates > Windows Components > Secure Boot.

Step 5 — Troubleshooting e remediation

I problemi più comuni includono il fallimento del deploy della KEK quando l’OEM non ha ancora pubblicato un aggiornamento firmware compatibile (Event ID 1803/1796) e il mancato avanzamento oltre il deploy della nuova KEK (AvailableUpdates rimane a 0x0004 anche dopo i riavvii). In questi casi, il primo passo è sempre verificare con l’OEM se è disponibile un aggiornamento firmware.

Soluzioni di Key Management per OEM e aziende

La documentazione Microsoft identifica diverse categorie di soluzioni per la gestione sicura delle chiavi Secure Boot:

Hardware Security Module (HSM)

La soluzione raccomandata per la generazione e l’archiviazione delle chiavi è un HSM (Hardware Security Module), un dispositivo hardware dedicato che garantisce che le chiavi private non lascino mai l’ambiente sicuro. Alcuni vendor HSM offrono anche consulenza specifica per la gestione delle chiavi Secure Boot.

Trusted Platform Module (TPM)

Il TPM è un chip hardware sulla scheda madre che archivia chiavi crittografiche usate per la cifratura. Presente su quasi tutti i PC moderni (è requisito obbligatorio per Windows 11), il TPM lavora in sinergia con il Secure Boot: può generare, archiviare e proteggere le chiavi del processo di cifratura e decifratura, e supporta funzionalità come BitLocker mantenendo i dischi in stato sealed finché il PC non completa con successo la verifica del boot.

Infrastruttura PKI interna o di terze parti

La PKI che governa Secure Boot comprende quattro componenti: una Certificate Authority (CA) che emette i certificati digitali, una Registration Authority che verifica l’identità dei richiedenti, un directory centralizzato per l’archiviazione e l’indicizzazione delle chiavi, e un sistema di gestione dei certificati. Le organizzazioni possono scegliere di gestire questa infrastruttura internamente o affidarsi a partner certificati.

Come verificare lo stato del Secure Boot sul tuo PC

Per gli utenti consumer e i professionisti IT che vogliono verificare rapidamente lo stato del Secure Boot su un dispositivo Windows:

• Da Windows: apri msinfo32 (Informazioni di sistema) e cerca la voce “Stato avvio protetto” — deve essere “Abilitato”.
• Da PowerShell (admin): esegui
  Confirm-SecureBootUEFI
  restituisce True se attivo.

• Dal BIOS/UEFI: riavvia il PC e accedi al firmware premendo il tasto indicato dal produttore (spesso F2, Del o F12). Cerca la sezione Boot o Security.
• Registry (stato certificati): controlla
  HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
  e il valore UEFICA2023Status.

Conclusione: la scadenza del 2026 non è rinviabile

Il Secure Boot è uno dei meccanismi di sicurezza più efficaci e trasparenti dell’ecosistema Windows. Opera in silenzio, senza richiedere interventi quotidiani, ma la sua corretta configurazione è la prima linea di difesa contro alcune delle minacce più sofisticate e persistenti: i bootkit e i rootkit pre-OS.

La scadenza dei certificati del 2011 rappresenta una finestra di manutenzione obbligatoria per tutta la filiera: Microsoft, OEM, aziende e utenti. Il processo è ben documentato e gli strumenti sono già disponibili. L’unico rischio reale è l’inazione.

Per OEM e IT manager la raccomandazione è chiara: iniziare oggi l’inventario, verificare la disponibilità degli aggiornamenti firmware e pianificare il deploy dei nuovi certificati prima di giugno 2026. Per gli utenti consumer, la regola d’oro rimane sempre la stessa: mantenere Windows aggiornato e non disabilitare il Secure Boot.

Fonte: Microsoft Learn — Windows Secure Boot Key Creation and Management Guidance | Microsoft Tech Community — Secure Boot playbook for certificates expiring in 2026

Riferimenti: KB Windows Health Dashboard WI1250978/79 | aka.ms/GetSecureBoot | Windows UEFI CA 2023