Secure Boot, dal 24 giugno scadono tre certificati: le imprese sono chiamate ad aggiornare

Per le aziende che gestiscono parchi Windows, Linux e macchine virtuali con avvio protetto si avvicina una scadenza tecnica ma rilevante per la continuità della sicurezza: a partire dal 24 giugno 2026 inizia la scadenza dei certificati Microsoft del 2011 che sostengono la catena di fiducia di Secure Boot. Come riporta l’analisi tecnica pubblicata da Ars Technica, il punto non è lo spegnimento improvviso dei sistemi, ma la perdita progressiva della capacità di ricevere nuove protezioni contro minacce che colpiscono firmware e fase di avvio.

Il calendario riguarda certificati usati per verificare crittograficamente ciò che viene caricato prima del sistema operativo. Secondo la documentazione Microsoft sui certificati Secure Boot, il Microsoft Corporation KEK CA 2011 scade il 24 giugno 2026, mentre il Microsoft UEFI CA 2011 scade il 27 giugno 2026 per le funzioni legate a bootloader di terze parti e option ROM; il Microsoft Windows Production PCA 2011, usato per firmare Windows Boot Manager, arriva a scadenza il 19 ottobre 2026.

La fiducia del boot va rinnovata

Secure Boot è una funzione del firmware UEFI pensata per consentire l’esecuzione, durante l’avvio, solo di codice firmato e considerato attendibile. La logica è quella di una catena: firmware, bootloader, database delle firme consentite e database delle revoche devono riconoscersi reciprocamente. Se un anello non è riconosciuto, Secure Boot può bloccare l’avvio del dispositivo.

Il meccanismo è stato progettato da Microsoft con i produttori di dispositivi per contrastare i bootkit, malware che si installano nelle componenti coinvolte nell’avvio e partono prima del sistema operativo e degli strumenti antimalware. La criticità per imprese e pubbliche amministrazioni è evidente: un bootkit può sopravvivere alla reinstallazione del sistema operativo e reinfettare la macchina anche dopo una bonifica tradizionale.

La migrazione è dalle autorità di certificazione del 2011 a quelle del 2023. Microsoft indica che i dispositivi non aggiornati continueranno ad avviarsi e a funzionare normalmente, ma non potranno più ricevere nuove protezioni per la fase iniziale del boot, inclusi aggiornamenti a Windows Boot Manager, database Secure Boot, liste di revoca e mitigazioni per nuove vulnerabilità a livello di avvio.

LogoFail ha accelerato il cambio

La pressione sul rinnovo non nasce solo da una scadenza amministrativa. Ars Technica collega la sostituzione delle firme anche alla scoperta di LogoFail, una serie di vulnerabilità critiche nei firmware UEFI che avviano praticamente ogni sistema Windows e Linux. Il bug, legato al parsing delle immagini usate per mostrare i loghi dei produttori durante il boot, ha permesso di aggirare Secure Boot e infettare il firmware con codice malevolo.

Il caso LogoFail si inserisce in una storia più lunga di attacchi alla fase di avvio. Ars Technica ricorda i primi bootkit degli anni Ottanta su Apple II, diffusi tramite floppy disk con giochi piratati, e poi i proof of concept per Windows emersi nei primi anni Duemila, tra cui BootRoot, presentato alla conferenza Black Hat del 2005, oltre a Vbootkit, Stoned Bootkit e Mebroot.

La minaccia si è poi spostata verso EFI e UEFI. Nel 2018 è stato individuato LoJax, indicato come primo caso noto di attacco reale al firmware UEFI e attribuito al gruppo sostenuto dal Cremlino noto anche come Sednit, Fancy Bear e APT 28. Nel 2020 i ricercatori di Kaspersky hanno scoperto MosaicRegressor, un malware che a ogni riavvio verificava la presenza di un file malevolo nella cartella di avvio di Windows e lo reinstallava se assente.

Da allora, secondo la ricostruzione della fonte primaria, sono emersi altri UEFI bootkit tracciati con nomi come ESpecter, FinSpy e MoonBounce. Per i responsabili IT questo rende la scadenza dei certificati un tema di gestione del rischio: non riguarda un singolo aggiornamento di sistema, ma la capacità dell’infrastruttura di restare allineata a una catena di fiducia riconosciuta.

Windows si aggiorna, ma non sempre

Microsoft sostiene che gestirà il processo di aggiornamento per una parte significativa dei dispositivi Windows. La pagina di supporto indica che i sistemi con certificati più recenti potranno continuare a ricevere l’intero set di protezioni di Secure Boot, mentre le organizzazioni che gestiscono direttamente gli aggiornamenti dovranno intervenire su KEK e DB, cioè Key Enrollment Key e Secure Boot Signature Database.

Per le imprese la distinzione operativa è tra endpoint gestiti automaticamente, macchine governate da policy interne e dispositivi specializzati. Microsoft elenca tra gli ambiti interessati Windows 10, Windows 11 e più versioni di Windows Server, inclusi Windows Server 2016, 2019, 2022 e 2025. Il perimetro non è quindi solo quello dei laptop aziendali, ma anche server, dispositivi IoT e ambienti enterprise con cicli di aggiornamento controllati.

Il rischio più immediato non è che un PC aggiornato smetta di accendersi alla mezzanotte della scadenza. Il rischio aziendale, secondo Microsoft, è un degrado della postura di sicurezza: nel tempo i sistemi non aggiornati potrebbero non ricevere revoche e mitigazioni per vulnerabilità di boot scoperte dopo la transizione ai certificati 2023. In scenari dove Secure Boot alimenta controlli più ampi, Microsoft cita possibili effetti su rafforzamento di BitLocker e bootloader di terze parti.

Linux deve guardare allo shim

Il fronte Linux passa soprattutto dallo shim, il piccolo bootloader UEFI di primo stadio che crea un ponte fiduciario tra le chiavi Secure Boot e il bootloader della distribuzione. Ars Technica segnala che i distributori Linux stanno aggiornando gli shim; il passaggio è rilevante perché Microsoft firma questi componenti come autorità centrale riconosciuta da molti firmware.

Red Hat ha chiarito, nella guida per ambienti RHEL, che i sistemi con il certificato Microsoft UEFI CA 2011 già registrato continueranno ad avviarsi dopo il 27 giugno 2026. L’effetto della scadenza riguarda la possibilità di firmare nuovi binari, non l’avvio di quelli esistenti. La società ha inoltre rilasciato nuove versioni di shim per RHEL 8, RHEL 9 e RHEL 10 supportati su architettura x86_64.

Red Hat segnala però un punto operativo delicato: sistemi legacy, server fisici datati, laptop vecchi, appliance senza aggiornamenti firmware o macchine prive di aggiornamenti UEFI del vendor potrebbero incontrare problemi quando sarà necessario installare un nuovo bootloader o shim dopo la scadenza. La raccomandazione è verificare la configurazione di Secure Boot, controllare chiavi e shim installati e testare con attenzione gli aggiornamenti del database UEFI prima di distribuirli in massa.

Anche Fedora invita a non leggere la scadenza come un blocco immediato. Nell’approfondimento pubblicato da Fedora Magazine, il progetto spiega che le macchine fisiche e virtuali continueranno ad avviarsi finché le chiavi pubbliche correnti non verranno rimosse dal firmware o revocate tramite DBX. Fedora Rawhide, versione f45, contiene già un bootloader di primo stadio firmato con più chiavi per massimizzare la compatibilità.

Cloud e virtual machine nel perimetro

La scadenza non riguarda solo i dispositivi fisici. Google Cloud, nella guida per Compute Engine, spiega che le Shielded VM usano UEFI Secure Boot per verificare software e firmware nella sequenza di avvio. Il documento indica come più critici il certificato Microsoft UEFI CA 2011, in scadenza il 27 giugno 2026, e Microsoft Windows Production PCA 2011, in scadenza il 19 ottobre 2026, oltre al Microsoft Corporation KEK CA 2011 del 24 giugno.

Per Compute Engine l’impatto è circoscritto a due condizioni cumulative: l’istanza deve essere stata creata prima del 7 novembre 2025, data in cui Google Cloud ha aggiornato i certificati Secure Boot predefiniti nel firmware UEFI, e deve avere Secure Boot abilitato. Le istanze create da quella data in poi, usando immagini basate sul set predefinito di certificati, includono già i certificati aggiornati.

Il caso cloud mostra perché il tema entra nei piani di continuità operativa. Google Cloud avverte che, se un aggiornamento del sistema operativo sostituisce un bootloader con uno firmato solo dal certificato Microsoft UEFI CA 2023 e il firmware dell’istanza non si fida di quella autorità, la verifica Secure Boot può fallire e bloccare la sequenza di avvio. La mitigazione passa dalla verifica dello stato dei certificati e dall’aggiornamento prima che arrivino componenti firmati solo con le nuove chiavi.

Il nodo operativo per le imprese

Per PMI ed enterprise la priorità è inventariare ciò che usa Secure Boot e separare i casi a basso rischio da quelli che richiedono intervento. Le macchine con Secure Boot disabilitato non sono impattate dalla scadenza in sé, come indicano Red Hat e Google Cloud per i rispettivi ambienti, ma restano fuori dal modello di protezione offerto dalla verifica delle firme in fase di avvio. Dove Secure Boot è parte delle policy di sicurezza, la disattivazione temporanea deve essere trattata come misura di recovery, non come strategia ordinaria.

Un secondo punto riguarda i sistemi che usano TPM, cifratura disco e attestazione. Red Hat avverte che gli aggiornamenti al database UEFI possono modificare i valori PCR del Trusted Platform Module, in particolare PCR7. La stessa cautela compare nella documentazione Google Cloud per configurazioni con vTPM, BitLocker, Virtual Secure Mode o cifratura Linux legata ai PCR. In questi scenari l’aggiornamento delle chiavi può avere ricadute su sblocco automatico dei volumi e gestione dei segreti.

La scadenza del 2026 diventa quindi un progetto di change management: verificare firmware e sistemi operativi supportati, controllare la presenza delle autorità 2023, pianificare eventuali update OEM, testare i modelli hardware più vecchi e coordinare le finestre di manutenzione su endpoint, server e VM. La parte tecnica è circoscritta, ma l’impatto organizzativo cresce con la frammentazione del parco macchine.

La sintesi è che Secure Boot non sta scadendo: stanno scadendo le vecchie radici di fiducia del 2011. I sistemi continueranno in molti casi ad avviarsi, ma chi non completa la migrazione rischia di trovarsi con una protezione di boot ferma, meno capace di assorbire revoche, nuove firme e mitigazioni. Per le aziende, il costo dell’azione è oggi soprattutto inventario e governance; il costo dell’inerzia potrebbe emergere al prossimo aggiornamento critico del bootloader o alla prossima vulnerabilità firmware.