Secure Boot 2026 e BitLocker stanno creando enormi problemi in azienda: come risolvere

La scadenza dei certificati Secure Boot prevista tra giugno e ottobre 2026 sta facendo emergere un problema che molte aziende avevano sotto gli occhi da anni ma non avevano mai soppesato: PC apparentemente identici possono avere stati UEFI diversi, chiavi firmware non allineate e BitLocker legato a misure TPM che cambiano appena si tocca il BIOS.

Secure Boot 2026 sta facendo emergere problemi nascosti tra TPM, firmware e BitLocker

Per anni, nella maggior parte degli ambienti enterprise, Secure Boot è stato trattato come una semplice impostazione del BIOS: lo si abilita, Windows si avvia, BitLocker cifra il disco e l’intero meccanismo rimane invisibile all’utente e spesso anche agli amministratori di sistema. Con l’arrivo degli aggiornamenti collegati a Secure Boot 2026, però, molte aziende stanno scoprendo che la relazione tra firmware UEFI, TPM e BitLocker è molto più delicata del previsto.

Di recente abbiamo seguito il caso di un’azienda con circa 40 workstation con Windows 11 e BitLocker attivo. L’obiettivo dell’amministratore era preparare i dispositivi per l’arrivo degli aggiornamenti Secure Boot distribuiti da Microsoft. Alcune macchine hanno completato l’operazione senza problemi, altre invece hanno iniziato a comportarsi in modo completamente anomalo.

Alcune manifestavano l’impossibilità di attivare BitLocker, errori TPM, PCR7 non disponibile, restituivano errori 0x8007000d ed eventi con ID 812 e 878 nel registro (Windows+R, eventvwr.msc).

Quello che inizialmente sembrava un semplice problema di aggiornamento si è rivelato invece un conflitto molto più profondo tra firmware, Secure Boot e meccanismi di trust hardware di Windows 11.

Il dettaglio nascosto nel BIOS

Analizzando le macchine problematiche, l’amministratore ha scoperto che molti notebook erano configurati nel BIOS in questo modo:

Platform Mode: Setup Mode
Secure Boot Mode: Custom Mode

Dopo aver utilizzato la funzione Restore Factory Keys presente nel firmware, la situazione cambiava invece in:

Platform Mode: User Mode
Secure Boot Mode: Standard Mode

A valle di questo intervento, gli aggiornamenti Secure Boot 2026 iniziano improvvisamente a funzionare. In realtà, modificare questa configurazione dopo l’installazione di Windows può causare conseguenze molto pesanti sul funzionamento di BitLocker.

La differenza tra Setup Mode e User Mode

Per capire il problema bisogna chiarire cosa rappresentano le modalità Setup Mode/Custom Mode e User Mode/Standard Mode: nel primo caso significa che la piattaforma non sta utilizzando il set standard di chiavi Secure Boot previste dal produttore o da Microsoft. In pratica il firmware si trova in uno stato più permissivo o personalizzato.

Quando invece il BIOS è riportato in User Mode/Standard Mode, la macchina torna a utilizzare chiavi di piattaforma ufficiali, database Secure Boot standard, policy UEFI considerate affidabili da Windows. È proprio questo lo stato che Windows 11 si aspetta di trovare.

Per questo motivo, quando si prepara un nuovo notebook aziendale, la procedura corretta dovrebbe sempre essere:

• entrare nel BIOS prima dell’installazione di Windows;
• eseguire Restore Factory Keys;
• verificare che Secure Boot sia in User Mode/Standard Mode;
• soltanto dopo installare Windows e attivare BitLocker.

Molte aziende, invece, hanno dispositivi installati anni fa in stati firmware ibridi o personalizzati che fino a poco tempo fa non causavano problemi evidenti.

Perché cambiare Secure Boot rompe BitLocker

Il punto centrale della vicenda è legato al chip TPM e a PCR7. Il TPM contiene una serie di registri chiamati PCR, ovvero Platform Configuration Registers: essi memorizzano informazioni critiche sull’integrità della piattaforma durante il boot.

PCR7, uno dei registri più importanti, memorizza la configurazione Secure Boot, le chiavi UEFI installate, lo stato della catena di boot, le policy firmware, i parametri di trust dell’avvio.

Quando si attiva BitLocker, le chiavi di cifratura non sono semplicemente salvate nel TPM, sono invece “sigillate” (sealed) rispetto ai valori presenti nel registro PCR7. In pratica il TPM memorizza qualcosa di simile a “rilascerò queste chiavi soltanto se il sistema si avvierà esattamente nello stesso stato di sicurezza“. È questo il motivo per cui, ad esempio, talvolta appare la schermata di richieste della chiave di ripristino BitLocker.

BitLocker crea una relazione diretta tra configurazione firmware, Secure Boot, TPM e stato PCR7. Se Windows è installato mentre il BIOS si trova in Setup Mode/Custom Mode, BitLocker esegue il sealing TPM utilizzando i valori PCR7 associati.

Se, successivamente, l’amministratore modifica Secure Boot passando a User Mode/Standard Mode, il contenuto di PCR7 cambia completamente: dal punto di vista del chip TPM, il sistema non è più lo stesso.

A quel punto BitLocker non riesce più a effettuare l’estrazioni delle chiavi TPM e iniziano a comparire errori come quelli citati in precedenza.

La procedura corretta per correggere sistemi Windows 11 già distribuiti

Uno degli aspetti più interessanti emersi durante la risoluzione del problema che riguardava buona parte delle 40 workstation è che, nella maggior parte dei casi, non è necessario decodificare completamente l’unità protetta con BitLocker per gestire i nuovi certificati Secure Boot.

Prima si sospende temporaneamente BitLocker:

Suspend-BitLocker -MountPoint "C:" -RebootCount 0

Successivamente, si riavvia il sistema, si corregge Secure Boot nel BIOS passando alla configurazione User Mode/Standard Mode, si riattiva il sealing:

Resume-BitLocker -MountPoint "C:"

In questo modo BitLocker esegue nuovamente l’associazione con il chip TPM utilizzando il nuovo valore PCR7 corretto. L’approccio illustrato di solita dispensa l’amministratore dal dover effettuare una completa nuova cifratura dell’unità di sistema.

Quando PCR7 mostra “Non disponibile”

Su alcune macchine, digitando msinfo32 nella casella di ricerca di Windows 11, scegliendo Esegui come amministratore e infine cercando Configurazione PCR7 nel pannello a destra, il sistema mostra il messaggio Non disponibile.

È un riscontro, questo, che purtroppo cambia completamente il significato del problema. Nel caso precedente, infatti, BitLocker lamentava semplicemente una mancata corrispondenza tra i vecchi valori PCR7 e quelli nuovi. Qui invece Windows non riesce proprio a utilizzare PCR7: il sistema operativo considera la piattaforma non idonea per l’associazione Secure Boot/TPM.

Se la configurazione PCR7 risulta Non disponibile, il problema non riguarda più soltanto BitLocker ma il rapporto stesso tra firmware, TPM, protezione DMA e integrità della procedura di avvio.

Come risolvere

La prima verifica da effettuare in questi casi riguarda lo stato del TPM. Da una finestra PowerShell aperta con i diritti di amministratore si deve digitare Get-Tpm per poi controllare che le voci TpmPresent, TpmReady e TpmEnabled risultino tutte impostate su True.

Se TpmReady=False, il problema è quasi certamente legato al provisioning TPM. In questi casi può essere necessario svuotare completamente il TPM, reinizializzarlo e ricreare il trust hardware. La procedura tipica prevede l’uso del comando Clear-Tpm, il riavvio del sistema quindi Initialize-Tpm per poi controllare di nuovo lo stato del TPM.

DMA Protection

Uno dei messaggi più importanti emersi durante le verifiche è “Invalid DMA-capable bus/device(s) detected“.

L’errore indica che Windows ha rilevato periferiche DMA considerate non sicure. Negli ultimi anni Microsoft ha aumentato enormemente i controlli relativi a Thunderbolt, USB4, DMA remapping, Kernel DMA Protection, Intel VT-d: se il firmware non implementa correttamente queste protezioni, Windows può disabilitare PCR7.

È la situazione che spiega tanti malfunzionamenti dopo l’applicazione di nuovi aggiornamenti firmware.

Uno degli aspetti più interessanti è che alcuni notebook identici, ma privi degli ultimi aggiornamenti BIOS o Thunderbolt firmware, continuavano a mostrare PCR7 perfettamente disponibile. Ciò suggerisce che alcuni firmware recenti stiano modificando gestione DMA, policy Secure Boot, inizializzazione TPM e comportamento Thunderbolt con effetti collaterali molto pesanti sul trust hardware di Windows 11.

Per questo motivo, quando PCR7 non risulta disponibile, vale sempre la pena controllare gli aggiornamenti BIOS, il firmware Thunderbolt, il firmware Intel ME e il contenuto delle note di rilascio relative a TPM e Secure Boot. Il problema potrebbe trovarsi interamente nel firmware della piattaforma.