BitLocker Recovery Key: Fix Guide 2026

Ak ste pracovali na helpdesku v apríli 2026, viete presne, o čom je tento článok. Aktualizácie KB5082063, KB5083769 a KB5082142 spustili v podnikovom IT doslova lavínu hovorov: po prvom reštarte sa zariadenia prebudili na modrú obrazovku BitLocker recovery a žiadali 48-miestny obnovovací kľúč. Tikety v ServiceNow, urgentné správy v Teams, panika u vzdialených zamestnancov, ktorí sa do svojho notebooku jednoducho nedostali. Tento sprievodca je presne pre tento scenár — a hlavne pre to, ako sa naň pripraviť na ďalší Patch Tuesday.

Hneď úvodom poviem niečo, čo som sa naučil tvrdou cestou: BitLocker recovery prompt nie je technický problém, je to procesný problém. A práve preto sa opakuje.

Prečo sa BitLocker recovery v 2026 vrátil do popredia

Začnime tým, že BitLocker recovery sa neaktivuje náhodne. Ide o bezpečnostnú reakciu na zmenu v boot reťazci, ktorú TPM nedokáže overiť proti uloženým Platform Configuration Registers (PCR) hodnotám. Aprílový Patch Tuesday 2026 zmenil zaobchádzanie s certifikátmi Secure Boot (presun na Windows UEFI CA 2023), čo v kombinácii s podnikovou GPO konfiguráciou — najmä pri PCR7 binding hlásenom ako Not Possible — spôsobilo, že TPM merania prestali sedieť. Zjednodušene: TPM otvorilo oči, povedalo si „toto nepoznám", a požiadalo o recovery key.

Problém je výhradne podnikový. Microsoft to v Windows release health dashboard potvrdil: zariadenia bez správy IT oddelenia ostali nedotknuté. Zasiahnuté sú scenáre, kde:

BitLocker je zapnutý na systémovom disku (ten, na ktorom beží OS),
GPO alebo Intune profil explicitne zahŕňa PCR7 v TPM validation profile,
PCR7 binding je v msinfo32 reportovaný ako Binding Not Possible,
v Secure Boot DB je už Windows UEFI CA 2023, ale stroj ešte beží s 2011-podpísaným Boot Managerom.

Microsoft zároveň upozornil, že podobné scenáre sa môžu opakovať počas expirácie Secure Boot certifikátov v júni 2026. Inými slovami — v podniku to nebol jednorazový incident. Bola to predzvesť.

Čo musí helpdesk urobiť v prvých 15 minútach

Keď používateľ zavolá s textom „chce odo mňa nejaký BitLocker recovery key", nemá cenu hádzať mu odkazy na dokumentáciu. Postupujte v presnom poradí:

Identifikujte zariadenie. Pýtajte si Key ID (prvých 8 znakov z modrej obrazovky, formát napríklad A1B2C3D4) a hostname alebo sériové číslo.
Overte spôsob pripojenia identity. Microsoft Entra joined? Hybrid joined? AD DS only? Od toho závisí, kde kľúč hľadať — a toto je krok, ktorý ľudia preskakujú najčastejšie.
Vyhľadajte kľúč v správnom úložisku (postupy nižšie).
Diktujte kľúč po skupinách. Kľúč má 8 blokov po 6 čísiel oddelených pomlčkou. Zadávajte ho na fyzickej klávesnici notebooku, nie cez ALT-kódy alebo schránku — pri recovery konzole jednoducho nefungujú.
Po úspešnom odomknutí okamžite spustite re-bind a zaeskalujte tiket pre fleet-wide remediáciu (postup ďalej).

Drobnosť, ktorá sa oplatí: pri diktovaní hovorte „nula", nie „o". Slovenský používateľ pod stresom napíše namiesto nuly písmeno O a potom desať minút hľadá, kde je chyba.

Kde je BitLocker recovery key uložený

BitLocker generuje recovery password (48 číslic) a recovery key (binárny .BEK súbor). V podnikovom prostredí by oba mali byť escrowované do centrálneho úložiska. Microsoftom odporúčaná matica vyzerá takto:

Typ pripojenia	Primárne úložisko	Sekundárne
Microsoft Entra joined	Microsoft Entra ID	Intune (ak je device enrolled)
Hybrid Entra joined	Microsoft Entra ID + AD DS	Intune
AD DS joined (on-prem)	Active Directory	SCCM / MBAM (ak je nasadený)
Workgroup / standalone	USB / vytlačený výstup	Microsoft account (osobné)

Microsoft Entra admin center (Entra joined zariadenia)

Otvorte entra.microsoft.com a prihláste sa ako Cloud Device Administrator alebo Helpdesk Administrator.
Prejdite na Devices → All devices, vyhľadajte zariadenie podľa hostname.
Kliknite na zariadenie a vyberte tab BitLocker keys.
Skontrolujte zhodu Key ID s tým, čo používateľ číta z obrazovky. Toto je dôležitejšie, než to znie — viac o tom nižšie.
Kliknite Show recovery key. Kľúč sa zaloguje do auditu (kto a kedy ho pozrel), takže rátajte s tým, že vás compliance team uvidí.

Microsoft Intune admin center

Intune má dve cesty — buď cez Device properties, alebo cez Encryption report:

V intune.microsoft.com prejdite na Devices → All devices, otvorte zariadenie a kliknite Recovery keys.
Alternatívne Devices → Monitor → Encryption report ukáže status BitLocker pre celý fleet a umožní rýchle filtrovanie zariadení bez escrowed kľúča. Toto je presne ten report, ktorý chcete pozrieť deň pred Patch Tuesday.

Active Directory Users and Computers (AD DS)

V on-prem AD je kľúč uložený ako msFVE-RecoveryInformation objekt pod počítačovým účtom. Aby ste ho videli, potrebujete:

nainštalovaný BitLocker Drive Encryption Administration Utilities RSAT feature,
delegované práva na čítanie atribútu msFVE-RecoveryPassword.

V ADUC zapnite View → Advanced Features (bez tohto kroku tab BitLocker Recovery jednoducho neuvidíte).
Vyhľadajte počítačový objekt, otvorte Properties → BitLocker Recovery.
V tabuľke porovnajte Password ID s tým, čo má používateľ na obrazovke.

PowerShell rýchle recepty pre helpdesk

Klávesnica je rýchlejšia ako klikanie. Vždy. Tieto skripty fungujú v Windows PowerShell 5.1 aj v PowerShell 7.4+ (potrebné moduly: Microsoft.Graph v2.20+ pre cloud, ActiveDirectory RSAT pre on-prem).

1) Lokálne zobrazenie kľúča (na zariadení používateľa)

(Get-BitLockerVolume -MountPoint "C:").KeyProtector |
    Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" } |
    Select-Object KeyProtectorId, RecoveryPassword

2) Vyhľadanie kľúča v Active Directory podľa Key ID

$KeyId = "A1B2C3D4-XXXX-XXXX-XXXX-XXXXXXXXXXXX"  # z modrej obrazovky

Get-ADObject -Filter { objectClass -eq "msFVE-RecoveryInformation" } `
    -SearchBase (Get-ADDomain).DistinguishedName `
    -Properties msFVE-RecoveryPassword, Name |
    Where-Object { $_.Name -like "*$KeyId*" } |
    Select-Object Name, @{N="RecoveryPassword";E={$_."msFVE-RecoveryPassword"}}

3) Vyhľadanie kľúča v Microsoft Entra ID cez Microsoft Graph

Connect-MgGraph -Scopes "BitLockerKey.Read.All", "Device.Read.All"

# Krok 1: zoznam vsetkych BitLocker recovery klucov v tenante (vrati len metadata)
$keys = Get-MgInformationProtectionBitlockerRecoveryKey -All

# Krok 2: vybrat podla Key ID, ktory nahlasil pouzivatel
$keyId = "a1b2c3d4-1234-5678-9abc-def012345678"
$match = $keys | Where-Object { $_.Id -eq $keyId }

# Krok 3: ziskat samotny 48-miestny kluc (audit log sa zapise automaticky)
Get-MgInformationProtectionBitlockerRecoveryKey -BitlockerRecoveryKeyId $match.Id `
    -Property "key" |
    Select-Object Id, CreatedDateTime, DeviceId, Key

4) Audit: ktoré Intune zariadenia nemajú kľúč escrowovaný v Entra ID

Toto je skript, ktorý by mal bežať každý piatok pred Patch Tuesday. Vážne.

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All", "BitLockerKey.Read.All"

$intuneDevices = Get-MgDeviceManagementManagedDevice -All `
    -Filter "operatingSystem eq 'Windows'" |
    Select-Object Id, DeviceName, AzureAdDeviceId

$bitlockerKeys = Get-MgInformationProtectionBitlockerRecoveryKey -All
$keyedDeviceIds = $bitlockerKeys.DeviceId | Sort-Object -Unique

$missing = $intuneDevices | Where-Object { $_.AzureAdDeviceId -notin $keyedDeviceIds }
$missing | Export-Csv -Path "C:\Reports\BitLocker-MissingKeys.csv" -NoTypeInformation
Write-Host "Zariadeni bez escrowed kluca: $($missing.Count)"

5) Re-escrow kľúča do Entra ID po nájdení chýbajúceho zariadenia

Tento skript treba spustiť ako System alebo (lepšie) cez Intune remediation script:

$volume = Get-BitLockerVolume -MountPoint $env:SystemDrive
$recoveryProtector = $volume.KeyProtector |
    Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" } |
    Select-Object -First 1

if ($recoveryProtector) {
    BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive `
        -KeyProtectorId $recoveryProtector.KeyProtectorId
    Write-Output "Recovery key escrowed: $($recoveryProtector.KeyProtectorId)"
} else {
    Write-Error "Recovery password protector neexistuje - vytvorte ho cez Add-BitLockerKeyProtector."
}

Re-bind po recovery: zabráňte opakovanému promptu

Keď používateľ raz zadá kľúč, BitLocker síce zariadenie odomkne, ale tu prichádza zákerná časť: ďalšie reštarty po Patch Tuesday môžu spustiť rovnaký prompt znova, ak nezmeníte boot meranie. Riešenie je dočasne suspend a opätovne enable ochrany — to vynúti reseal TPM proti aktuálnemu PCR stavu:

manage-bde -protectors -disable C: -rebootcount 0
Restart-Computer -Force
# Po prvom restarte:
manage-bde -protectors -enable C:

Pre celý fleet to spravte cez Intune Proactive Remediation alebo cez Invoke-Command v PowerShell. Detection skript môže overiť hodnotu PCR7 binding cez (Get-Tpm).TpmReady a msinfo32. Mimochodom, ak vidíte v telemetrii desiatky zariadení, ktoré recovery prompt dostali viackrát po sebe, je takmer isté, že chýba presne tento krok.

Prevencia: čo nastaviť pred ďalším Patch Tuesday

Žiadny incident nemal nastať. Tento checklist drží podnik v zelenej zóne:

Rotácia recovery passwordu po každom použití. V Intune cez Endpoint security → Disk encryption → BitLocker policy → Client-driven recovery password rotation nastavte na Enabled for both Azure AD-joined and Hybrid devices.
Compliance policy, ktorá blokuje prístup k podnikovým zdrojom, ak BitLocker nie je Encrypted. V Intune Compliance → System security → Require encryption of data storage on device = Yes.
Pred-patch audit: spustite vyššie uvedený skript č. 4 v deň pred Patch Tuesday a opravte chýbajúce escrowy.
PCR7 audit: na pilotnej skupine overte výstup msinfo32 sekcie Secure Boot State a PCR7 Configuration. Ak vidíte Binding Not Possible, upravte GPO TPM validation profile (odstráňte PCR7) pred patchovaním.
Known Issue Rollback (KIR): pre podniky bez možnosti rýchlej zmeny GPO Microsoft poskytol KIR ADMX šablónu — nasadenie cez GPO odloží zmenu o niekoľko týždňov.
Self-service recovery: myaccount.microsoft.com umožní používateľovi pozrieť si kľúč z mobilu (odbremeňuje helpdesk pre Entra joined zariadenia).
Staged rollout: rings 1 → 2 → 3 cez Windows Update for Business alebo Intune Update rings. Žiaden patch by sa nemal dostať do produkcie bez 48-hodinového okna na pilotke. Áno, viem, že obchodné tímy budú reptať. Áno, oplatí sa to.

Špeciálne scenáre, ktoré dokumentácia obvykle prehliada

VPN-only používatelia bez prístupu k AD

Ak je notebook AD DS joined a používateľ nikdy nebol fyzicky v sieti, kľúč mohol skončiť v local cache bez replikácie do AD. Nepredpokladajte, že je v ADUC — nie je. Cez Intune (ak je device co-managed) skontrolujte Encryption report ako sekundárny zdroj. Toto je mimochodom najčastejší prípad, keď „kľúč jednoducho nikde nie je" — a väčšinou tam je, len nie tam, kde sa pozeráte.

BitLocker To Go (USB a externé disky)

Recovery key pre removable jednotky sa neeskaluje automaticky do Entra ID — musíte ho explicitne povoliť cez Removable Drives sekciu Intune politiky alebo GPO Choose how BitLocker-protected removable drives can be recovered.

Autopilot zariadenia v stave OOBE

Ak zariadenie zlyhá počas Autopilotu pred dokončením enrollmentu, recovery kľúč ešte nebol escrowed. Recovery v tomto stave znamená preinštalovať cez Autopilot reset alebo PXE. Kľúč v Entre nikdy nebude. Bohužiaľ.

Re-imagované zariadenia s rovnakým hostname

Po reimagingu vznikne v Entra ID nový device object. Starý objekt s pôvodným kľúčom zostáva — vo vyhľadávaní podľa hostname dostanete dva výsledky. Vždy porovnajte Key ID, nikdy nie hostname. Toto je presne ten dôvod, prečo sme v kroku 1 trvali na Key ID.

Eskalačná matica pre helpdesk

Tier	Kedy	Akcia
Tier 1	Bežný prompt, Entra/AD má kľúč	Diktovať kľúč, urobiť re-bind, zatvoriť tiket
Tier 2	Kľúč chýba v centrálnom úložisku	Skontrolovať Intune, lokálny cache, BackupToAAD remediation
Tier 3	Fleet-wide incident (>50 zariadení/hodinu)	Aktivovať KIR, otvoriť Microsoft Pro Support tiket, komunikovať statuspage
Tier 4	Žiadny kľúč nikde, dáta sú kritické	Forenzná recovery (Microsoft Data Recovery Agent ak je nakonfigurovaný), inak strata dát

FAQ — najčastejšie otázky používateľov a správcov

Prečo Windows žiada BitLocker recovery key, keď som nič nezmenil?

BitLocker overuje boot reťazec proti hodnotám TPM. Ak Windows Update zmení boot manager, Secure Boot certifikáty alebo firmvér, merania prestanú sedieť a TPM odmietne odomknúť kľúč. V apríli 2026 to spôsobil prechod na Windows UEFI CA 2023 v kombinácii s podnikovou GPO obsahujúcou PCR7. Z pohľadu používateľa „nič nezmenil", z pohľadu TPM sa zmenilo všetko.

Kde nájdem BitLocker recovery key, ak nemám prístup k Entra ID portálu?

Prejdite na myaccount.microsoft.com z iného zariadenia alebo mobilu, prihláste sa pracovným kontom a otvorte sekciu Devices. Pri každom zariadení je tlačidlo View BitLocker keys. Funguje to len pre Entra joined zariadenia, kde má používateľ na zariadení pridanú vlastnú identitu.

Je 48-miestne číslo to isté čo BitLocker recovery key?

Technicky nie. Recovery password je 48-miestne číslo zložené z 8 blokov po 6 čísel — tým odomykáte cez modrú obrazovku. Recovery key je binárny súbor .BEK, ktorý sa používa pri neinteraktívnom odomykaní (napríklad cez USB). V helpdesk hovore používateľ takmer vždy potrebuje recovery password, nie .BEK súbor.

Ako zabránim opakovaným recovery prompts po každej Windows aktualizácii?

Tri vrstvy ochrany. Po prvé, v GPO alebo Intune odstráňte PCR7 z TPM validation profile, ak je PCR7 binding Not Possible. Po druhé, po každom úspešnom recovery spustite manage-bde -protectors -disable C: -rebootcount 0 a po reštarte -enable. A po tretie — staged rollout aktualizácií s 48-hodinovým pilotným oknom. Tieto tri veci spolu pokryjú asi 95 % opakovaných promptov.

Môže si používateľ sám pozrieť svoj BitLocker recovery key?

Áno, ale iba cez myaccount.microsoft.com a iba pre Entra joined zariadenia, kde je sám zaregistrovaný. Pre AD DS-only zariadenia musí kľúč poskytnúť helpdesk po overení identity (typicky callback na overené telefónne číslo alebo MFA challenge).

Stačí mať BitLocker zapnutý, alebo musím aj zálohovať kľúč?

Samotné šifrovanie nie je obrana, ale riziko, ak kľúč nemáte mimo zariadenia. Bez escrowed recovery key je BitLocker po prvom recovery prompt jednosmerný lístok do straty dát. Compliance politika musí vynucovať escrow do Entra ID alebo AD DS, inak BitLocker zhoršuje vašu BCP/DR pozíciu, nie zlepšuje. Toto je tvrdé, ale je to pravda.

Zhrnutie

Aprílové aktualizácie 2026 ukázali jednu nepríjemnú vec: BitLocker recovery nie je výnimočná udalosť. Je to operačný proces, ktorý musí byť pripravený rovnako ako password reset. S Entra ID alebo AD DS escrow, automatickou rotáciou kľúčov, pred-patch auditom a štruktúrovanou eskalačnou maticou váš helpdesk neutopia ani ďalšie Patch Tuesday vlny, ani očakávané zmeny okolo expirácie Secure Boot certifikátov v júni 2026. Investícia do týchto procesov sa vráti pri prvom incidente, ktorému sa vyhnete — a to sa stane skôr, než si myslíte.