Windows 11 forza la richiesta della chiave BitLocker: utenti bloccati senza motivo

La tornata di aggiornamenti mensili Microsoft continua a rappresentare uno snodo delicato per la sicurezza dei sistemi Windows: il Patch Tuesday di aprile 2026 introduce modifiche rilevanti, ma porta con sé anche un comportamento inatteso legato a BitLocker che merita attenzione. Il tema non è marginale: BitLocker, introdotto con Windows Vista e progressivamente evoluto, oggi protegge milioni di endpoint aziendali grazie all’integrazione con il chip TPM. Secondo i dati Microsoft, la cifratura delle unità di memorizzazione è ormai uno standard nelle configurazioni enterprise moderne ed è progressivamente portata anche in ambito semi-professionale e consumer, non senza qualche mugugno.

Il fatto è che gli aggiornamenti cumulativi di aprile (in Windows 11 con le patch KB5083769 e KB5082052, in Windows 10 con KB5082200, oltre che in Windows Server 2022 e 2025) hanno introdotto un comportamento inatteso: la richiesta della chiave di ripristino BitLocker all’avvio. Non è la prima volta che succede ma, soprattutto negli ambienti aziendali gestiti, questo tipo di comportamento si traduce in interruzioni operative e ticket di supporto a catena.

Origine tecnica del problema: interazione tra BitLocker e TPM

Il comportamento anomalo nasce da una combinazione precisa di configurazioni. La causa primaria sembra essere – almeno a detta di Redmond – la policy Configure TPM platform validation profile for native UEFI firmware configurations (in italiano Configura il profilo di convalida della piattaforma TPM per configurazioni firmware UEFI native), un’impostazione che stabilisce quali registri PCR (Platform Configuration Registers, ovvero aree protette del TPM che memorizzano misurazioni crittografiche dello stato del sistema) sono utilizzati per verificare l’integrità del sistema durante la fase di avvio. In condizioni normali, Windows sceglie automaticamente un insieme di PCR appropriato; modificare manualmente questa impostazione può tuttavia generare risultati non conformi.

In pratica, il punto è che l’aggiornamento Microsoft di aprile modifica implicitamente alcune componenti del processo di boot, in particolare quando entra in gioco il nuovo Windows Boot Manager firmato con il certificato Microsoft UEFI CA 2023. Se il sistema passa a questa nuova catena di fiducia senza aggiornare i binding PCR utilizzati da BitLocker, il TPM rileva una discrepanza e attiva la modalità di ripristino con la comparsa della richiesta del codice.

Dopo l’installazione degli aggiornamenti di aprile 2026, tuttavia, lo stesso problema è riscontrabile su diverse macchine consumer e PC utilizzati da professionisti (non legati a configurazioni gestite e completamente stand alone).

Quando si manifesta la richiesta di inserimento della chiave di ripristino BitLocker

L’anomalia non colpisce indiscriminatamente tutti i sistemi. Il disco di sistema deve essere cifrato con BitLocker e il dispositivo deve usare Secure Boot con una configurazione in cui il binding al registro PCR7 (un valore del TPM che lega la cifratura del sistema allo stato di avvio) non è disponibile. Quest’ultimo dettaglio emerge chiaramente premendo digitando msinfo32 nella casella di ricerca di Windows quindi scegliendo Esegui come amministratore: qui la voce Configurazione PCR7 appare come Non associato.

A complicare il quadro interviene la presenza del certificato Windows UEFI CA 2023 nel database delle firme Secure Boot. L’elemento rende il sistema idoneo a utilizzare il nuovo boot manager firmato, ma solo se non lo sta già adoperando: è una finestra di transizione che, in forza del cambio effettivo del boot manager, porta all’alterazione dei valori PCR provenienti dal TPM.

Quando si verifica la condizione di mismatch, il sistema interrompe la sequenza di boot e richiede la chiave di ripristino BitLocker. Microsoft chiarisce che l’evento si presenta una sola volta: dopo aver inserito la chiave corretta, il sistema aggiorna i binding e torna in uno stato coerente.

Dal punto di vista operativo, però, il problema non va sottovalutato. In ambienti con centinaia o migliaia di endpoint, anche un singolo prompt inatteso può bloccare postazioni critiche. Inoltre, non sempre gli utenti finali hanno accesso immediato alla chiave di ripristino BitLocker, soprattutto se la gestione avviene tramite Active Directory o Azure AD.

Un aspetto interessante riguarda la percezione dell’evento: molti amministratori potrebbero interpretarlo come un attacco o una manomissione del boot. In realtà, il meccanismo dimostra che le protezioni TPM funzionano correttamente; il sistema reagisce esattamente come progettato.

Mitigazioni e workaround consigliati

Microsoft suggerisce un approccio diretto: rimuovere la configurazione manuale della policy TPM prima di applicare l’aggiornamento. Impostare la policy su Non configurata consente al sistema operativo di gestire automaticamente il profilo PCR, evitando incongruenze durante il passaggio al nuovo boot manager.

Una volta modificata la policy, conviene forzare l’aggiornamento con gpupdate /force per poi sospendere temporaneamente BitLocker e riattivarlo tramite i comandi seguenti:

manage-bde -protectors -disable C:
manage-bde -protectors -enable C:

La sospensione e la successiva riabilitazione consentono di aggiornare i binding senza attivare il meccanismo di ripristino. Successivamente, la protezione può essere riattivata senza effetti collaterali.

Chi gestisce infrastrutture Windows dovrebbe quindi adottare una regola semplice: evitare personalizzazioni non strettamente necessarie delle policy TPM e testare sempre gli aggiornamenti in ambienti controllati.