BitLocker recovery-loop fix (W11)

Opdateret: 30. juni 2026

Når BitLocker beder om gendannelsesnøglen ved hver opstart i Windows 11, er årsagen næsten altid en PCR-uoverensstemmelse i TPM'en udløst af en firmware-, Secure Boot- eller bootloader-ændring, typisk efter april 2026-opdateringen KB5083769 eller en BIOS-flash, hvor BitLocker ikke blev suspenderet først. Den korrekte løsning er at installere KB5089549 (maj 2026), suspendere BitLocker før fremtidige firmware-opdateringer, og rette den TPM-platformvalideringsprofil, der inkluderer PCR7, så nøglen rebindes til en stabil profil. Denne guide går igennem hele kæden fra første ticket til permanent fix.

Recovery-promptet betyder, at TPM'en nægter at frigive BitLocker-nøglen, fordi en monitoreret PCR (oftest PCR7 for Secure Boot-politik, eller PCR0/PCR2 for firmware) har ændret sig siden sidste forsegling.
KB5083769 (14. april 2026) udløste recovery-loops på maskiner med PCR7-baseret valideringsprofil; KB5089549 (12. maj 2026) er den officielle out-of-band-fix.
Gendannelsesnøglen findes via Microsoft-kontoen (aka.ms/myrecoverykey), Entra ID-enhedsbladet eller AD's msFVE-RecoveryInformation-attribut. Match Key ID, ikke kun pc-navnet.
Suspendér altid BitLocker med manage-bde -protectors -disable C: -RebootCount 1 før BIOS-, TPM- eller UEFI-firmwareopdateringer; PowerShell-wrapperen Suspend-BitLocker har kendte bugs i 24H2.
Juni 2026-Secure Boot-certifikatudløbet (Microsoft UEFI CA 2011) kører ind i samme problem. Planlæg en KIR eller en kontrolleret rebind, før den ramler ind i din flåde.

Hvorfor beder BitLocker om gendannelsesnøglen ved hver opstart?

BitLocker beder om gendannelsesnøglen, hver gang TPM'en (Trusted Platform Module) nægter at frigive den forseglede volumen-master-nøgle. Forseglingen er bundet til en udvalgt mængde Platform Configuration Registers (PCR'er), som registrerer hash af firmware, Secure Boot-politik, bootloader og Windows-bootmanageren. Når én af de monitorerede PCR'er ikke matcher det, der var i tørnen, da nøglen blev forseglet, betragter TPM'en det som tampering, holder nøglen tilbage, og din slutbruger får den blå skærm med 48-cifret prompt.

I min erfaring som helpdesk-leder er der fire klassiske triggers, der står for langt over 90 % af de tickets, vi får på dette:

BIOS-, UEFI- eller TPM-firmwareopdatering uden BitLocker-suspension. En Dell BIOS-flash via Command Update eller en HP Image Assistant-rul ændrer PCR0/PCR2, og hvis ingen huskede at suspendere BitLocker først, lander brugeren på recovery-skærmen ved næste reboot.
Secure Boot-politikændring. En tilføjelse til Secure Boot DB'en, en skifte mellem Standard og Custom Secure Boot, eller, som vi så i april 2026, Windows' automatiske overgang til den 2023-signerede Windows Boot Manager rammer PCR7.
Hardware-skift. Nyt bundkort, RAM-modul flyttet til en anden DIMM-bank på visse OEM'er, eller et systemkort-RMA-bytte. Disse rører ikke nødvendigvis PCR'erne direkte, men TPM'en kan opfattes som ny.
Dual-boot eller bootrækkefølgeændring. Hver gang en bruger trykker F12 og booter fra USB, eller hvis Linux-bootloaderen omarrangerer EFI-stien, kan PCR4 og PCR5 hoppe.

Det centrale at huske: recovery-promptet er ikke en fejl, det er BitLockers designede adfærd. Den beskytter mod en angriber, der har skiftet bootloaderen ud. Men når den udløses af en legitim opdatering, skal helpdesken kende både den ene-gangs-løsning (indtast nøglen) og den varige rebind, der forhindrer en gentagelse.

Sådan finder du din BitLocker-gendannelsesnøgle

Den hurtigste vej til en BitLocker-gendannelsesnøgle afhænger af, hvor nøglen er escroweret. I et velkonfigureret miljø havner den ét eller flere af disse fire steder. Match altid Key ID'et på recovery-skærmen (de første otte tegn). Pc-navnet alene er ikke nok, fordi en maskine kan have flere gemte nøgler over tid.

1. Microsoft-konto (personlig eller MSA-baseret)

For privatbrugere og BYOD-enheder, der er logget ind med en Microsoft-konto: åbn https://aka.ms/myrecoverykey på en anden enhed, log ind, og kig efter Key ID'et, der starter med de samme otte tegn som skærmen viser.

2. Microsoft Entra ID (det tidligere Azure AD)

For Entra-tilsluttede eller hybrid-tilsluttede enheder: gå til Entra Admin Center → Enheder → vælg enheden → BitLocker-nøgler. Kræver minimum Cloud Device Administrator-rolle.

3. Active Directory (on-prem)

Hvis I har konfigureret GPO'en Store BitLocker recovery information in Active Directory Domain Services, ligger nøglen som msFVE-RecoveryInformation på computerobjektet. Hent den med PowerShell:

# Hent alle BitLocker-recovery-passwords for en given maskine
# Kræver AD-modul + Read msFVE-permission
Get-ADObject -Filter 'objectclass -eq "msFVE-RecoveryInformation"' `
    -SearchBase "CN=PC-NAVN,OU=Workstations,DC=corp,DC=local" `
    -Properties msFVE-RecoveryPassword, Name |
    Select-Object Name, msFVE-RecoveryPassword

4. Intune / Microsoft Endpoint Manager

For MDM-managed enheder: Intune Admin Center → Enheder → vælg enhed → Recovery keys. Eller endnu hurtigere via Graph PowerShell:

# Kræver Microsoft.Graph + BitlockerKey.Read.All scope
Connect-MgGraph -Scopes "BitlockerKey.Read.All"
# Erstat  med Entra-enhedens objectId
Get-MgInformationProtectionBitlockerRecoveryKey -BitlockerRecoveryKeyId  `
    -Property "key"

KB5083769 og KB5089549: Microsofts BitLocker-fejl fra april–maj 2026

Den 14. april 2026 udrullede Microsoft KB5083769 som månedens Patch Tuesday-bundle for Windows 11 24H2 og 25H2. Inden for 72 timer eksploderede vores ticketkø: maskiner, der havde boot'et fint dagen før, sad nu på BitLocker-recovery-skærmen ved første reboot efter opdateringen. Det var ikke en enkeltstående fejl, men en konfigurationskollision, der ramte en specifik (men ikke usædvanlig) opsætning.

Hvad gik galt

KB5083769 var den første rulning, der under bestemte betingelser automatisk skiftede maskinen til den nye 2023-signerede Windows Boot Manager. Det skifte ændrer Secure Boot-evalueringen, og dermed PCR7. Hvis BitLockers TPM-platformvalideringsprofil inkluderede PCR7 (hvilket den gør på mange virksomheds-images), opfattede TPM'en boot-kæden som ændret og holdt nøglen tilbage.

Microsoft offentliggjorde betingelserne, der måtte være opfyldt samtidig, for at problemet ramte:

BitLocker aktiveret på OS-drevet.
GPO'en "Configure TPM platform validation profile for native UEFI firmware configurations" konfigureret med PCR7 i profilen.
System Information rapporterer Secure Boot State PCR7 Binding som "Not Possible".
Microsoft UEFI CA 2023-certifikatet findes i Secure Boot DB, og enheden kører ikke allerede den 2023-signerede Windows Boot Manager.

KB5089549: den officielle løsning

Den 12. maj 2026 udsendte Microsoft KB5089549 som out-of-band-opdatering. Den er kirurgisk: ingen sikkerheds- eller funktionsændringer, kun en rettelse af forseglingslogikken, så boot-manager-skiftet ikke længere udløser recovery. Installation kræver, at KB5083769 allerede er installeret.

For maskiner, der allerede er låst ude, fjerner KB5089549 ikke promptet (du skal stadig indtaste nøglen én gang. Det den gør, er at forhindre gentagne prompts, når den 2023-signerede boot manager træder i kraft fuldt ud). Læs BleepingComputers gennemgang af KB5089549 for build-numre og kendte rest-issues.

Trin-for-trin fejlfinding af BitLocker-recovery-loop

Når en ticket lander med "BitLocker beder om nøglen hver gang", er det her, jeg får tier-1 til at gå igennem, i denne rækkefølge. Spring ikke trin over; diagnose før remediation sparer dig for at låse maskinen ude permanent.

Trin 1: Lås maskinen op én gang og log ind

Indtast den 48-cifrede nøgle. Vent på, at Windows boot'er helt op, og log ind som en konto med lokal admin. Uden et fungerende OS er resten ren gætteleg.

Trin 2: Bekræft protector- og PCR-tilstand

# Kør i en hævet (admin) PowerShell-prompt
# Viser nuværende protectors og krypteringsstatus
manage-bde -protectors -get C:

# Viser den valideringsprofil, der i øjeblikket bruges
manage-bde -status C:

# Detaljeret TPM-tilstand inklusive PCR-værdier
Get-Tpm

Kig efter en "TPM"-protector og en "Numerical Password"-protector. Hvis Numerical Password mangler, er der ingen recovery-mulighed — fix det først.

Trin 3: Tjek hvilken PCR-profil der gælder

Den effektive profil er ofte arvet fra GPO'en. Validér med:

# Læs den policy-erede PCR-profil fra registry
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" `
    -Name "PlatformValidationProfile" -ErrorAction SilentlyContinue

En værdi som 0,2,4,7,11 betyder, at PCR7 er med. Det er præcis den profil, der bider, efter KB5083769.

Trin 4: Tjek event-loggen for forsegling-fejl

Event Viewer → Applications and Services Logs → Microsoft → Windows → BitLocker-API → Management. Event ID 24620 ("The boot configuration changed") og 24586 ("Unable to unlock") fortæller dig præcist, hvilken PCR der ikke matcher.

Trin 5: Patch og rebind

Installer KB5089549 (eller den nyeste kumulative, der inkluderer fixet). Reboot. Kør derefter:

# Reseal nøglen mod den nuværende boot-kæde
# -disable suspenderer; -enable rebinder protectors til nye PCR-værdier
manage-bde -protectors -disable C: -RebootCount 0
manage-bde -protectors -enable C:

Denne sekvens er det, jeg insisterer på, at tier-1 lærer udenad. Den løser 80 % af recovery-loops uden at skulle pille ved Group Policy.

Hvis maskinen stadig prompter efter trin 5, er du i den restende 20 %. Gå videre til PCR7-justeringen i sektion TPM-platformvalideringsprofil nedenfor. For relaterede Windows 11-issues på samme maskinetype, så se vores generelle Windows 11 fejlfinding for IT-helpdesk-guide.

Sådan suspenderer du BitLocker før firmware- eller BIOS-opdateringer

Det her er det enkleste forebyggende trin i hele guiden, og samtidig det, der oftest bliver glemt af tier-1. Suspendér altid BitLocker, før du flash'er BIOS, UEFI eller TPM-firmware, før du ændrer Secure Boot-indstillinger, eller før du opdaterer komponenter med firmware-payload (NVMe SSD'er, dockingstationer med firmware-driver, Thunderbolt-controllere).

Den anbefalede kommando (manage-bde)

# Suspendér BitLocker med automatisk genoptagelse efter 1 reboot
# Perfekt til en planlagt firmware-opdatering
manage-bde -protectors -disable C: -RebootCount 1

Med -RebootCount 1 genoptages beskyttelsen automatisk efter den næste opstart. Det betyder, at du ikke kan glemme at re-enable bagefter, hvilket sker oftere end nogen vil indrømme.

PowerShell-alternativet (med advarsel)

# Suspend-BitLocker-cmdletten gør det samme, men ...
Suspend-BitLocker -MountPoint "C:" -RebootCount 1

Genoptag manuelt, hvis du suspenderede med RebootCount 0

# Hvis du suspenderede uden auto-resume, så genaktivér eksplicit
manage-bde -protectors -enable C:
manage-bde -status C:
# Status skal vise "Protection Status: Protection On"

Centraliseret suspension via Intune / Configuration Manager

For større flåder: skub et proaktivt remediation-script via Intune, der suspenderer BitLocker, før firmware-pakken installeres, og verificerer status efter. Se Microsofts officielle vejledning til BitLocker-suspension ved ikke-Microsoft-opdateringer for de scenarier, der kræver manuel suspension.

TPM-platformvalideringsprofil (PCR7): Group Policy-fixet

Hvis recovery-promptet bliver ved efter både KB5089549 og en suspend-resume-cyklus, er du nødt til at justere selve valideringsprofilen. Det er her, Group Policy-fans som mig kommer på arbejde, og det er også her, jeg ser mest skade i ufaglærte hænder. Test på én OU, før du udruller til alle.

Den problematiske GPO

Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives → Configure TPM platform validation profile for native UEFI firmware configurations.

Standardprofilen (når GPO'en er "Not Configured") er 0, 2, 4, 11 på UEFI-systemer. Den er stabil over Secure Boot-skift. Mange virksomheders hærdnings-baselines tilføjer PCR7, og det er præcis dét, der nu giver bagslag. Microsofts officielle BitLocker FAQ beskriver konsekvenserne af hver PCR-tilføjelse i detaljer.

Anbefalet rettelse

Åbn GPMC, naviger til den GPO, der sætter profilen.
Sæt indstillingen til Not Configured (anbefalet) eller eksplicit til 0, 2, 4, 11 uden PCR7.
Klik Apply, OK, og kør på targetmaskinerne:

# Tving GPO-refresh
gpupdate /target:computer /force

# Rebind BitLocker-protectors mod den nye profil
manage-bde -protectors -disable C: -RebootCount 0
manage-bde -protectors -enable C:

# Verificér ny profil er aktiv
manage-bde -status C:

Juni 2026: Secure Boot-certifikatfornyelsen, du skal forberede

Det her er det næste, der kommer til at ramme jeres telefoner. Microsoft UEFI CA 2011 (det certifikat, der har signeret bootloadere i over et årti) udløber gradvist gennem juni 2026. Microsoft har rullet erstatningen, Microsoft UEFI CA 2023, ud via firmware-opdateringer og Windows Update siden 2024, men ikke alle OEM'er har fået den i DB'en på alle modeller.

På maskiner med PCR7 i valideringsprofilen og en manglende 2023-cert udløser certifikatrotationen samme symptom som KB5083769: recovery-prompt ved hver opstart. HP EliteBook 840 G9/G10 og visse Dell Latitude 5440-batches er overrepræsenteret i de tickets, jeg har set.

Forberedelseschecklist for helpdesken

Inventér Secure Boot DB'en på 10–20 maskiner pr. model. Brug [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) i en PowerShell-prompt og søg efter "Microsoft UEFI CA 2023".
Udrul OEM's seneste firmware-bundle. Dell Command Update, HP Image Assistant og Lenovo Vantage skubber typisk 2023-cert'en med BIOS-rul fra Q1/Q2 2026.
Patch til mindst KB5089549, og helst juni-cumulativen, som ifølge Microsofts release-notes håndterer cert-overgangen mere graciøst.
Hav en KIR (Known Issue Rollback) klar. Enterprise-kunder kan rekvirere KIR-policy'en gennem Microsoft Premier; det er din "nødbremse", hvis en model udruller cert-skiftet samtidig med Patch Tuesday.
Træn første-linje i suspend-resume-cyklen. Det er den enkeltsætning, der oftest løser et akut recovery-loop hos en bruger, mens du venter på, at den centrale fix udrulles.

For relaterede netværks- og endpoint-issues, der ofte følger med en stor patch-bølge, se vores VPN-fejlfinding i Windows 11 for helpdesk-guide og Active Directory kontolåsninger-guiden. To ting, der typisk eskalerer parallelt, når en Patch Tuesday går skævt.

Forebyggelse: helpdesk-checkliste før udrulning

Bedre at undgå end at slukke brande. Det her er den runbook, vi kører før hver større opdateringsbølge: Patch Tuesday, BIOS-rul, OS feature-upgrade. Den har sparet os for hundredvis af recovery-tickets de sidste 18 måneder.

Før selve udrulningen

Verificér escrow-dækning. Kør en rapport, der finder maskiner uden gemte recovery-nøgler i Entra/AD/Intune. En enkelt maskine uden escrow er én ticket, du ikke kan løse.
Pilotér i 5–10 % af flåden. Inkludér mindst én af hver primær OEM-model, du har. Vent 24 timer før bred udrulning.
Hav recovery-key-portalen klar. Selvbetjenings-URL (aka.ms/myrecoverykey eller en virksomhedsportal med Entra-SSO) skal kommunikeres før, ikke efter, at brugeren står på den blå skærm.
Suspendér BitLocker centralt for kendte risikobølger. Til BIOS-rul og store feature-opdateringer pusher vi manage-bde -protectors -disable C: -RebootCount 1 via Intune som proaktiv remediation 2 timer før vinduet.

Under udrulningen

Overvåg ticket-volumen for keywords som "BitLocker", "recovery key", "blue screen 48 digits".
Hav en tier-1-runbook med præcis ordlyden, brugeren skal sige (Key ID-matching, hvor de finder nøglen, hvad de gør efter login).
Eskalér til tier-2, så snart samme model rapporteres 3+ gange, fordi det er mønstret for en flådebred konfigurationskollision, ikke en enkeltmaskinefejl.

Efter udrulningen

Kør en rapport over maskiner med suspenderet BitLocker, der ikke er auto-resumed. RebootCount 1 burde have håndteret det, men edge cases findes.
Audit GPO'en for "Configure TPM platform validation profile"; er der nogen baseline-template, der genaktiverer PCR7 efter en Group Policy-refresh?
Opdater postmortem-dokumentet med trigger, antal ramte tickets, og hvilken kommando der løste det. Næste bølge er kun et par måneder ude.

Ofte stillede spørgsmål

Hvorfor beder min computer om BitLocker-gendannelsesnøglen ved hver opstart?

Fordi TPM'en registrerer en ændring i en monitoreret PCR, typisk PCR7 (Secure Boot-politik) eller PCR0/PCR2 (firmware) — siden BitLocker-nøglen sidst blev forseglet. Almindelige triggers er BIOS-opdateringer, KB5083769 fra april 2026, eller en Secure Boot-cert-rotation. Den varige løsning er at installere KB5089549 og rebinde protectors med manage-bde -protectors -disable C: -RebootCount 0 efterfulgt af -enable.

Kan jeg deaktivere BitLocker-gendannelsesnøglepromptet permanent?

Nej — recovery-promptet er en sikkerhedsfunktion, ikke en konfigurationsindstilling. Du kan reducere hyppigheden ved at fjerne PCR7 fra TPM-platformvalideringsprofilen, så Secure Boot-politikændringer ikke udløser den. Men hvis du dekrypterer drevet helt for at slippe for promptet, mister du al BitLocker-beskyttelse mod tyveri af enheden.

Hvor finder jeg min BitLocker-gendannelsesnøgle, hvis jeg er logget ind med en arbejdskonto?

Tre primære steder: Microsoft Entra Admin Center under enhedens BitLocker-nøgler (kræver Cloud Device Administrator-rolle), Intune Admin Center under enhedens Recovery keys, eller Active Directory som msFVE-RecoveryInformation-attributten på computerobjektet. Match altid Key ID'ets første otte tegn fra recovery-skærmen mod den gemte nøgle.

Skal jeg suspendere BitLocker før hver Windows-opdatering?

Nej, ikke før almindelige kumulative Windows-opdateringer, fordi Windows Update håndterer BitLocker-resealing internt. Suspendér før BIOS- eller UEFI-firmwareopdateringer, TPM-firmware-flash, Secure Boot-konfigurationsændringer, og før ikke-Microsoft-værktøjer rører bootloaderen. Brug manage-bde -protectors -disable C: -RebootCount 1 for automatisk genoptagelse efter næste reboot.

Hvad er forskellen på KB5083769 og KB5089549?

KB5083769 er Patch Tuesday-bundlen fra 14. april 2026, der under bestemte betingelser udløste BitLocker-recovery-loop på maskiner med PCR7 i valideringsprofilen. KB5089549 fra 12. maj 2026 er en out-of-band, kirurgisk fix, der retter forseglingslogikken, så boot-manager-skiftet ikke længere udløser recovery. KB5089549 fjerner ikke en allerede udløst prompt. Du skal stadig låse op én gang og rebinde protectors.