BitLocker Chiede la Chiave di Ripristino dopo KB5083769: Guida Helpdesk 2026

Aggiornato: 28 maggio 2026

Se BitLocker chiede la chiave di ripristino all'avvio di Windows 11 dopo l'aggiornamento di aprile 2026, la causa quasi certa è il pacchetto cumulativo KB5083769 (o KB5082052 per la build 26H1): modifica il modo in cui il TPM misura il processo di boot e, sulle macchine con una specifica policy BitLocker che include il registro PCR7, la verifica fallisce e la chiave a 48 cifre diventa obbligatoria. La buona notizia è che, nella maggior parte dei casi, basta inserirla una sola volta; poi si applica l'hotfix KB5089549 e si neutralizza la policy che genera il mismatch.

• Gli aggiornamenti KB5083769 (Windows 11 24H2/25H2), KB5082052 (26H1), KB5082200 (Windows 10) e gli equivalenti di Server 2022/2025 possono attivare la schermata di recupero BitLocker al primo riavvio.
• La causa è l'inclusione del PCR7 nel profilo di validazione TPM combinata con il passaggio al Windows Boot Manager firmato Microsoft UEFI CA 2023.
• L'hotfix ufficiale è KB5089549 rilasciato da Microsoft a maggio 2026.
• Workaround manuale: impostare a "Non configurata" la policy Configure TPM platform validation profile for native UEFI firmware configurations, poi gpupdate /force e manage-bde -protectors -disable/-enable C:.
• Le chiavi di ripristino delle macchine aziendali si recuperano da Microsoft Entra ID, Active Directory o dal portale account.microsoft.com a seconda del tipo di join.
• Nella maggior parte dei casi la chiave viene chiesta una sola volta: i riavvii successivi non riattivano la schermata se la policy non viene cambiata.

Cosa succede esattamente al boot

Il sintomo arriva quasi sempre con lo stesso ticket: utente che la sera spegne il portatile, la mattina lo accende e si ritrova una schermata blu con il messaggio "BitLocker recovery" e la richiesta della chiave a 48 cifre. Niente login, niente Wi-Fi, niente sblocco automatico via TPM. Sul mio service desk, nei primi giorni dopo il Patch Tuesday di aprile 2026, sono arrivati oltre cinquanta ticket identici in 36 ore, quasi tutti su laptop Dell e Lenovo provisionati da Intune con una baseline di sicurezza ereditata da un vecchio template del 2021.

Il punto importante per chi gestisce un helpdesk è capire che non si tratta di un guasto hardware né di una compromissione: il TPM funziona, il disco è integro, il bootloader è firmato. È un disallineamento di misurazione. Microsoft ha cambiato i file di boot durante l'installazione di KB5083769, il TPM ha calcolato un nuovo hash, la policy BitLocker si aspettava il vecchio e quindi ha rifiutato di rilasciare il VMK (Volume Master Key). A quel punto Windows mostra la schermata di ripristino perché è l'unico fallback previsto dalla specifica.

Il modo in cui spieghi la cosa all'utente cambia il tono del ticket. "Non sei stato hackerato, è una patch sbagliata di Microsoft" abbassa subito l'ansia e ti permette di guidare la persona attraverso l'inserimento della chiave senza che pensi di dover formattare la macchina.

Perché BitLocker chiede la chiave di ripristino dopo l'aggiornamento

BitLocker, quando configurato con sblocco TPM-only o TPM+PIN, lega la chiave di crittografia del volume a una serie di registri PCR (Platform Configuration Register) misurati durante il boot. Ogni PCR rappresenta un'area del processo di avvio: PCR0 è il firmware, PCR2 sono i driver opzionali, PCR4 è il bootloader, PCR7 è la catena Secure Boot. Quando i valori al boot corrispondono a quelli registrati al momento dell'attivazione di BitLocker, il TPM rilascia il VMK e Windows si avvia senza chiedere niente.

Il pacchetto KB5083769 ha fatto due cose contemporaneamente. Primo, ha completato la migrazione al nuovo Windows Boot Manager firmato con il certificato Microsoft UEFI CA 2023, sostituendo quello firmato con il vecchio certificato del 2011 che Microsoft sta dismettendo. Secondo, ha effettivamente aggiornato i file di boot misurati nel PCR7. Sulle macchine in cui una Group Policy esplicita includeva PCR7 nel profilo di validazione TPM, combinazione tipica delle baseline CIS o di vecchi template enterprise, il valore al boot non combacia più con quello registrato, e BitLocker entra in recovery mode.

La policy incriminata si chiama Configure TPM platform validation profile for native UEFI firmware configurations e vive in Computer Configuration / Administrative Templates / Windows Components / BitLocker Drive Encryption / Operating System Drives. Su un sistema "consumer" Microsoft lascia che sia il sistema operativo a scegliere il profilo, e la migrazione al nuovo boot manager passa inosservata. Su un sistema enterprise con la policy esplicita, il profilo è bloccato sul set definito dall'amministratore e qualunque modifica ai file di boot fa scattare il prompt. Per il dettaglio tecnico ufficiale, vale la pena tenere a portata di mano la pagina Ripristino di BitLocker: problemi noti di Microsoft Learn, che cataloga questo e altri trigger noti.

Chi è colpito e chi no

Microsoft ha confermato che il problema si manifesta solo quando tutte queste condizioni sono vere contemporaneamente: BitLocker è attivo sul volume di sistema, esiste una Group Policy che include esplicitamente PCR7 nel profilo TPM, Secure Boot riporta lo stato "PCR7 binding: Not Possible", il certificato Windows UEFI CA 2023 è già presente nel database Secure Boot UEFI e la macchina non sta ancora usando il Boot Manager firmato 2023. È una catena di condizioni stretta, ed è il motivo per cui in un'azienda lo vedi su intere fasce di endpoint mentre il portatile personale del CFO non se ne è mai accorto.

Nella pratica, nel mio inventario, ho visto il problema soprattutto su:

• Laptop aziendali provisionati con baseline CIS Windows 11 v1.0.0 o successive senza override delle policy BitLocker.
• Workstation di sviluppatori con Secure Boot in modalità Standard ma con PCR7 binding marcato come "Not Possible" perché l'UEFI ha più di una chiave PK personalizzata.
• Server di filiale Windows Server 2022 con disco di sistema crittografato per requisiti GDPR. Qui il problema è doppio perché spesso non c'è nessuno fisicamente davanti alla console.

Le macchine integrate ad Active Directory con account utente bloccati aggiungono un livello di complicazione: se l'account dell'amministratore locale è scaduto, anche una volta sbloccato BitLocker resti tagliato fuori. Conviene preparare un account di emergenza separato prima di propagare l'aggiornamento.

Dove trovo la chiave di ripristino BitLocker

Questa è la prima domanda che ti farà l'utente al telefono e la risposta dipende dal tipo di join dell'identità. Tienile a mente in ordine di probabilità per un ambiente aziendale:

1. Microsoft Entra ID (ex Azure AD): portale entra.microsoft.com, sezione Dispositivi, seleziona la macchina, tab "Chiavi BitLocker". Richiede ruolo Cloud Device Administrator o Global Administrator.
2. Active Directory on-premises: console Utenti e computer di Active Directory con la feature opzionale "BitLocker Recovery Password Viewer" abilitata. Tasto destro sull'oggetto computer, tab BitLocker Recovery.
3. Intune / Microsoft Endpoint Manager: portale intune.microsoft.com, sezione Dispositivi, seleziona la macchina, Chiavi di ripristino.
4. Account Microsoft personale: account.microsoft.com/devices/recoverykey. Vale per i PC con account consumer.
5. Backup locale: file .BEK su chiavetta USB o stampa cartacea archiviata dall'utente.

Per identificare la chiave giusta quando ce ne sono molte, sulla schermata di recupero compare un Key ID di 8 caratteri: confronta i primi 8 caratteri del campo "Identifier" nel portale con quelli sullo schermo. È un dettaglio banale ma fa risparmiare cinque minuti su ogni ticket.

Fix immediato sull'endpoint bloccato

Quando l'utente è davanti alla schermata di recupero, l'unica cosa che lo riporta dentro Windows è la chiave a 48 cifre digitata sul tastierino numerico. Una volta inserita, il sistema completa il boot normalmente e la maggior parte degli utenti non rivedrà più quella schermata. Subito dopo il login, prima di lasciare la macchina, conviene fare tre cose in sequenza:

# 1. Verifica lo stato corrente di BitLocker e dei protectors
manage-bde -status C:
manage-bde -protectors -get C:

# 2. Sospendi e riattiva la protezione per ribindare il TPM allo stato attuale
manage-bde -protectors -disable C: -RebootCount 0
manage-bde -protectors -enable C:

# 3. Forza il backup della chiave aggiornata su Entra ID o AD
manage-bde -protectors -get C: -Type RecoveryPassword -id "{numeric-id}"
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId "{numeric-id}"

Il passaggio disable seguito da enable non decrittografa il disco: rimuove e ricrea i protector TPM in modo che le nuove misurazioni PCR diventino quelle "buone". Senza questo passaggio, qualunque altra modifica al boot (un firmware update, un cambio di policy) potrebbe far riapparire il prompt. Il BackupToAAD-BitLockerKeyProtector è una rete di sicurezza: se l'utente cambia la password locale o un altro evento ricicla il protector, vuoi essere certo che la nuova chiave sia in cloud prima di chiudere il ticket.

Rimuovere la policy PCR7 prima del riavvio

Il modo corretto di prevenire ulteriori recovery prompt, e di proteggere le macchine non ancora aggiornate, è neutralizzare la policy che forza PCR7. Microsoft consiglia di lasciare al sistema operativo la scelta del profilo di validazione, perché conosce quando il boot manager cambia certificato e adatta il profilo di conseguenza.

Su una singola workstation:

1. Apri gpedit.msc come amministratore.
2. Vai in Configurazione computer, Modelli amministrativi, Componenti di Windows, Crittografia unità BitLocker, Unità del sistema operativo.
3. Apri Configura il profilo di convalida della piattaforma TPM per configurazioni del firmware UEFI nativo e imposta a Non configurata.
4. Da prompt amministrativo esegui gpupdate /force.
5. Esegui i comandi manage-bde -protectors -disable C: e -enable C: della sezione precedente.

Su una flotta gestita centralmente la stessa modifica va fatta nella Group Policy Object aziendale o nel profilo di sicurezza di Intune (sezione Endpoint security, Disk encryption). Distribuiscila prima di rilasciare KB5083769 al ring successivo e il problema semplicemente non si presenta.

Installare l'hotfix KB5089549

Microsoft ha pubblicato a fine maggio 2026 l'aggiornamento cumulativo KB5089549 che corregge alla radice il comportamento del Windows Boot Manager rispetto al PCR7. La nota di rilascio elenca esplicitamente il fix per "an issue where some devices might enter BitLocker Recovery after updating boot files on systems with certain TPM validation settings". Installato KB5089549, anche le macchine con la policy PCR7 ancora attiva non vedono più il prompt al riavvio.

L'installazione standard via Windows Update funziona, ma su una flotta vale la pena forzare il pull con un piccolo script per evitare di aspettare il refresh casuale del client:

# Script di rollout controllato per KB5089549
# Eseguire come SYSTEM via Intune o GPO scheduled task

$kb = "KB5089549"
$installed = Get-HotFix -Id $kb -ErrorAction SilentlyContinue
if ($installed) {
    Write-Output "$kb gia installato in data $($installed.InstalledOn)"
    exit 0
}

# Forza Windows Update a controllare immediatamente
$updateSession = New-Object -ComObject Microsoft.Update.Session
$searcher = $updateSession.CreateUpdateSearcher()
$result = $searcher.Search("IsInstalled=0 and Type='Software'")

$kbUpdates = $result.Updates | Where-Object { $_.Title -match $kb }
if (-not $kbUpdates) {
    Write-Output "$kb non offerto su questo dispositivo (build non supportata)"
    exit 1
}

$downloader = $updateSession.CreateUpdateDownloader()
$downloader.Updates = $kbUpdates
$downloader.Download()

$installer = $updateSession.CreateUpdateInstaller()
$installer.Updates = $kbUpdates
$installResult = $installer.Install()
Write-Output "Risultato installazione: $($installResult.ResultCode)"

Prevenzione su flotta gestita

Se sei nella posizione che vorrei aver avuto io a marzo, e quindi il rollout di KB5083769 non è ancora partito sul tuo anello di produzione, hai tre azioni di prevenzione che valgono il pomeriggio che ci dedichi:

1. Backup forzato delle chiavi su Entra ID/AD per tutta la flotta. Distribuisci uno script che esegua BackupToAAD-BitLockerKeyProtector su ogni macchina e logga il risultato in un file condiviso. Quando i ticket cominceranno ad arrivare avrai la garanzia che la chiave esiste in un posto a cui l'helpdesk ha accesso, non solo nella stampa che l'utente ha perso nel 2022.
2. Rimozione della policy PCR7 nelle GPO/profilo Intune. Imposta a "Non configurata" la voce Configure TPM platform validation profile for native UEFI firmware configurations e propaga prima di KB5083769. Microsoft documenta che lasciare al sistema la scelta del profilo è la modalità raccomandata; la policy esplicita è un retaggio di template degli anni dieci.
3. Pilot ring documentato. Tieni un anello pilota di una ventina di macchine rappresentative (Dell, Lenovo, HP, Surface; con e senza dock TB) e applica gli aggiornamenti lì almeno 72 ore prima della produzione. Se il prompt riappare, hai tempo per fermare la deploy ring più ampia.

Per il monitoraggio post-deploy uso una semplice query KQL su Microsoft Defender for Endpoint che alza un alert quando un dispositivo registra l'evento ID 24620 nel registro Microsoft-Windows-BitLocker/BitLocker Management nelle 24 ore successive a un aggiornamento. È l'evento che corrisponde a un recovery prompt riuscito, e ti dà il conteggio reale di chi è stato colpito invece di affidarti ai ticket spontanei.

Runbook helpdesk: cosa fare al primo ticket

Trasformare la procedura in un runbook condivisibile fa la differenza tra una giornata gestibile e il caos. Questo è il flusso che ho stampato e attaccato sopra la scrivania dei tier 1 nel mio team durante l'ondata di aprile:

1. Identifica la macchina chiedendo all'utente il numero seriale o il device name visibile sulla schermata di recupero.
2. Recupera la chiave dal portale appropriato confrontando il Key ID a 8 caratteri.
3. Dettatura controllata: usa la chat aziendale autenticata, non il telefono. Spiega che la chiave è composta da 8 gruppi di 6 cifre separati da trattini.
4. Conferma il login Windows prima di chiudere il canale di comunicazione.
5. Esegui in remoto (via Intune, ConnectWise, o quello che usi) lo script di disable/enable protectors e di backup chiave.
6. Aggiungi un'annotazione al ticket con l'evento ID e il KB installato per alimentare il tuo log di incidenti: quando l'analisi post-mortem arriva, ti servirà.
7. Registra l'utente nella lista pilota per gli aggiornamenti successivi: la sua macchina è probabilmente rappresentativa di un'intera fascia di endpoint, e averla in pilot ring ti dà visibilità anticipata.

Per situazioni in cui il problema BitLocker si combina con altre criticità da aggiornamento, dai un'occhiata anche alla nostra guida su Windows 11 che non si avvia dopo l'aggiornamento, perché spesso lo stesso ticket parte come "PC non parte" e diventa BitLocker dopo i primi tre minuti di triage.

Errori comuni in escalation

Tre errori che ho visto fare ai miei tier 1 e che vale la pena evitare:

Decrittografare il disco "per sicurezza". Non serve, e su volumi grandi può richiedere ore durante le quali l'utente è completamente fermo. Il prompt di recovery non è sintomo di corruzione: il disco è sano, è solo che il TPM non vuole rilasciare la chiave. Decrittografare e ricriptare non risolve la causa e ti fa partire da capo con il bootstrap delle chiavi.

Disabilitare BitLocker permanentemente. Se la macchina rientra in uno scope di compliance (GDPR, ISO 27001, NIS2), disabilitare la crittografia è una violazione che andrà notificata e remediata. Sospendere la protezione per un riavvio è OK; disabilitarla a tempo indeterminato è un altro discorso.

Cambiare la password locale durante la schermata di recovery. Sembra ovvio ma succede: l'utente, pensando che il problema sia la password, tenta un reset via account aziendale che fallisce perché il PC non è online. Risultato: due ticket invece di uno. Spiega all'utente che la chiave a 48 cifre è l'unica via, e che la password normale tornerà a funzionare appena Windows si avvia.

Per problemi di connettività post-sblocco, quando la macchina parte ma il VPN o Wi-Fi corporate non si aggancia perché il certificato è scaduto durante il downtime, è utile avere a portata di mano la nostra guida al troubleshooting della VPN aziendale su Windows 11, perché i due ticket arrivano spesso in coppia.

Domande frequenti

Perché BitLocker chiede la chiave di ripristino ad ogni riavvio?

Se la chiave viene richiesta ad ogni riavvio (non solo dopo l'aggiornamento), significa che i protector TPM non sono più legati alla configurazione attuale del boot. Esegui manage-bde -protectors -disable C: seguito da -enable C: dopo il primo sblocco per ribindare il TPM allo stato corrente. Se il problema persiste, controlla che non ci sia una Group Policy che reimpone un profilo PCR incompatibile.

Cosa succede se non ho la chiave di ripristino BitLocker?

Senza la chiave a 48 cifre i dati sul volume non sono recuperabili: è il design intenzionale di BitLocker. Controlla in ordine il portale Microsoft Entra ID, Active Directory, Intune, il tuo account Microsoft personale e qualunque backup cartaceo o su chiavetta USB. Se nessuna fonte ha la chiave, l'unica opzione è formattare e reinstallare; i dati sono persi.

Quali aggiornamenti di aprile 2026 causano il problema BitLocker?

I pacchetti coinvolti sono KB5083769 per Windows 11 24H2 e 25H2, KB5082052 per Windows 11 26H1, KB5082200 per Windows 10 22H2, e gli equivalenti per Windows Server 2022 e 2025. Tutti modificano i file di boot e attivano il prompt sui sistemi con policy PCR7 esplicita. KB5089549 di maggio 2026 corregge il comportamento.

Come disattivare BitLocker temporaneamente senza decrittografare?

Da prompt amministrativo esegui manage-bde -protectors -disable C:. Il comando sospende la protezione lasciando i dati cifrati ma rendendo la chiave accessibile in chiaro fino al successivo -enable (o al numero di riavvii specificato con -RebootCount). È il metodo corretto per aggiornare firmware o BIOS senza far scattare il recovery prompt al riavvio.

La chiave di ripristino BitLocker viene chiesta una sola volta?

Nel caso specifico di KB5083769, sì: una volta inserita la chiave al primo riavvio, i boot successivi avvengono normalmente perché il nuovo Windows Boot Manager 2023 diventa la baseline misurata. Se invece la chiave viene richiesta ripetutamente, c'è una policy che continua a invalidare il binding TPM e va sistemata come descritto sopra.