Im Unternehmenseinsatz ist bei BitLocker nicht die Verschlüsselung das Risiko, sondern der verlorene Recovery-Key. Ohne den 48-stelligen Wiederherstellungsschlüssel sperren Sie sich nach einem BIOS-Update, TPM-Tausch oder einer Secure-Boot-Änderung aus. Die Anleitung zeigt die drei Sicherungswege, Silent Encryption, Key-Rotation und den Notfallprozess mit manage-bde und repair-bde.

Voraussetzungen

Windows Pro, Enterprise, Pro Education oder Education (Version 10 1803+ für Silent Encryption mit Admin, 1809+ für Standard-User)
TPM 1.2 oder höher, besser TPM 2.0 (Pflicht für Windows 11, Lockout bei PIN-Brute-Force)
UEFI ohne CSM/Legacy-BIOS, Pflicht für Silent Encryption und Secure Boot
Secure Boot aktiviert und Windows Recovery Environment (WinRE) konfiguriert
Für Intune-Verwaltung: Microsoft-Intune-Lizenz (enthalten in Microsoft 365 Business Premium, E3, E5); Windows Pro genügt für die BitLocker-Verwaltung per Intune
Für AD-Backup: Active Directory mit Schema-Version Windows Server 2012 oder höher, msFVE-Erweiterungen vorhanden
Für Entra-ID-Key-Abruf: Entra-Rolle Cloud Device Administrator, Helpdesk Administrator oder Global Administrator
Für repair-bde: Key-Package aus AD DS und Recovery-Password; für manage-bde Admin-Rechte

Schritt 1: Verschlüsselungsalgorithmus auf AES-256-XTS setzen

Windows verwendet ohne explizite Policy-Konfiguration XTS-AES 128-bit als Standard. Erzwingen Sie XTS-AES 256-bit. Die Einstellung muss vor der Aktivierung gesetzt sein; auf bereits verschlüsselte Laufwerke wirkt sie nicht.

Per Gruppenrichtlinie (GPO) für On-Premises und Hybrid:

Pfad: Computer Configuration > Administrative Templates
      > Windows Components > BitLocker Drive Encryption

Policy: "Choose drive encryption method and cipher strength
         (Windows 10 [Version 1511] and later)"

Einstellung für OS-Laufwerk:       XTS-AES 256-bit
Einstellung für Fixed Data Drives:  XTS-AES 256-bit
Einstellung für Removable Drives:   AES-CBC 256-bit

Per Intune CSP (Endpoint Security > Disk Encryption Policy):

CSP-Pfad: ./Device/Vendor/MSFT/BitLocker/EncryptionMethodByDriveType
Wert:      XTS-AES 256 für OS- und Fixed-Data-Drives

Manuell per manage-bde (Standalone/Test):

manage-bde -on C: -recoverypassword -encryptionmethod XTS_AES_256

Verifizieren: Nach dem Start der Verschlüsselung zeigt manage-bde -status C: unter „Encryption Method“ den Wert „XTS-AES 256“. Steht dort „XTS-AES 128“, griff die Richtlinie vor der Aktivierung nicht (gpresult /r bzw. Intune-Gerätestatus prüfen).

Schritt 2: Recovery-Key-Backup-Weg wählen und konfigurieren

Welcher der drei Sicherungswege passt, zeigt die Tabelle:

Szenario	Empfohlener Backup-Weg	Voraussetzung	Trade-off
Entra-joined (Cloud-only)	Entra ID automatisch	Entra-Joined, Intune-Lizenz	Max. 200 Keys pro Gerät; bei Limit-Überschreitung schlägt Silent Encryption fehl
Hybrid-joined (AD + Entra)	AD DS + Entra ID (beide)	AD Schema Win Server 2012+	Redundanz; Leserecht im AD nur Domain Admins per Standard
On-Premises AD-only	Active Directory (msFVE)	AD Schema Win Server 2012+	Kein Cloud-Zugriff; Leserecht delegierbar über msFVE-RecoveryInformation
Standalone / Arbeitsgruppe	Externes Medium + Passwort-Manager	USB-Laufwerk oder Tresor	Manueller Prozess; Key nie auf demselben Gerät speichern

Weg A: Entra ID / Intune (empfohlen für Cloud-Umgebungen)

Silent Encryption per Intune setzt voraus, dass Sie eine Endpoint Security > Disk Encryption Policy verwenden. Dem Settings Catalog fehlen die TPM-Startup-Authentifizierungseinstellungen. Folgende CSP-Einstellungen sind kritisch:

./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption              = 1
./Device/Vendor/MSFT/BitLocker/AllowWarningForOtherDiskEncryption   = 0
./Device/Vendor/MSFT/BitLocker/AllowStandardUserEncryption          = 1
./Device/Vendor/MSFT/BitLocker/EncryptionMethodByDriveType          = XTS-AES 256
./Device/Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation    = 2

Wichtig: AllowWarningForOtherDiskEncryption = 0 unterdrückt auch Warnungen bei bereits vorhandener Drittanbieter-Verschlüsselung (McAfee, Symantec). Prüfen Sie das Geräte-Inventar vorab auf vorhandene Verschlüsselung, um Datenverlust durch doppelte Verschlüsselung zu vermeiden.

Weg B: Active Directory via msFVE-Schema

AD speichert Recovery-Passwörter als msFVE-RecoveryInformation-Objekte unter dem Computerobjekt. GPO-Konfiguration:

Pfad: Computer Configuration > Administrative Templates
      > Windows Components > BitLocker Drive Encryption
      > Operating System Drives

Policy: "Choose how BitLocker-protected operating system drives can be recovered"
  ✔ Save BitLocker recovery information to Active Directory Domain Services
  ✔ Backup recovery password and key package
  ✔ Do not enable BitLocker until recovery information is stored in AD DS

Nachträglich sichern, wenn BitLocker bereits aktiv ist:

# Aktuellen Key-Protektor-ID ermitteln
manage-bde -protectors -get C:

# Nachträglich ins AD sichern
manage-bde -protectors -adbackup C: -id "{KeyID-aus-manage-bde-protectors-get}"

Weg C: Standalone ohne AD und Intune

# Recovery-Key als .bek-Datei auf externem Laufwerk speichern
manage-bde -on C: -recoverykey E:\ -recoverypassword

# Alle Key-Protektoren (inkl. Recovery-Password) anzeigen und dokumentieren
manage-bde -protectors -get C:

Speichern Sie den Recovery-Key nie auf dem verschlüsselten Laufwerk selbst oder einem anderen fest eingebauten Laufwerk, sondern im Passwort-Manager oder physisch gesichert im Tresor.

Verifizieren: manage-bde -protectors -get C: listet einen Protektor „Numerical Password“ mit ID. Dieselbe ID finden Sie je nach Weg in Entra ID (Gerät > BitLocker-Schlüssel), in AD (Registerkarte „BitLocker-Wiederherstellung“ am Computerobjekt) oder in Ihrer Ablage.

Schritt 3: TPM-only oder TPM+PIN entscheiden

Die Wahl bestimmt Bedienung, Schutzniveau und ob Silent Encryption möglich ist.

Merkmal	TPM-only	TPM + PIN
Benutzerinteraktion beim Start	Keine	PIN-Eingabe erforderlich
Silent Encryption möglich	Ja	Nein
Schutz gegen physische Manipulation	Ja	Ja
Schutz gegen Cold-Boot-Angriff	Nein	Ja
Remote-Wiping / unbeaufsichtigte Geräte	Ideal	Problematisch
Brute-Force-Schutz (TPM 2.0)	–	Lockout nach wiederholten Fehlversuchen
Empfehlung	Bürogeräte mit Fernlöschung	Außendienst, hochsensible Daten

Die PIN hat mindestens 4 Stellen; wählen Sie 6 oder mehr. TPM 2.0 sperrt nach wiederholten Fehlversuchen (Anti-Hammering) und bremst so Brute-Force-Angriffe.

Verifizieren: manage-bde -protectors -get C: zeigt bei TPM-only den Protektor „TPM“, bei TPM+PIN „TPM And PIN“. Mit PIN fragt der nächste Neustart vor dem Windows-Start nach der PIN.

Schritt 4: Silent Encryption per Intune konfigurieren

Silent Encryption läuft ohne Benutzerinteraktion, sofern alle Voraussetzungen erfüllt sind. Prüfen Sie vorab mit powercfg /a, ob Modern Standby unterstützt wird:

powercfg /a
# Ausgabe "Standby (S0 Low Power Idle) Network Connected" = Modern Standby
# => Silent Encryption verschlüsselt automatisch nur "Used Space Only"

Auf Modern-Standby-Geräten verschlüsselt Silent Encryption immer nur den belegten Speicher („Used Space Only“). Wenn Sie „Full Encryption“ benötigen, setzen Sie den Verschlüsselungstyp zusätzlich explizit per Settings Catalog:

Pfad: Windows Components > BitLocker Drive Encryption
      > Operating System Drives
Policy: "Enforce drive encryption type on operating system drives"
Wert:   "Full encryption"

Verschlüsselungsstatus prüfen:

manage-bde -status C:
# Feld "Conversion Status" zeigt "Used Space Only Encrypted" oder "Fully Encrypted"

Verifizieren: Im Intune Admin Center unter Berichte > Verschlüsselungsbericht steht das Gerät auf „Verschlüsselt“, und manage-bde -status C: meldet „Protection Status: Protection On“.

Schritt 5: Automatische Key-Rotation konfigurieren

Key-Rotation erzeugt und sichert nach Nutzung eines Recovery-Passwords automatisch ein neues. Voraussetzung: Backup-Policy auf „Required“.

CSP: ./Device/Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation
  0 = Rotation deaktiviert
  1 = Automatisch nach Nutzung für Entra-joined Geräte
  2 = Automatisch für Entra-joined und Hybrid-joined Geräte (empfohlen)

In Intune: „Client-driven recovery password rotation“ auf „Enable rotation on Microsoft Entra ID and hybrid joined devices“ und „Store recovery information in Microsoft Entra ID before enabling BitLocker“ auf „Required“.

Verifizieren: Nach einer Entsperrung mit dem Recovery-Password zeigt manage-bde -protectors -get C: eine neue ID für „Numerical Password“, und in Entra ID erscheint ein neuer Schlüssel mit aktuellem Datum.

Schritt 6: Recovery-Keys abrufen

Abruf aus Entra ID (Portal)

Im Microsoft Entra Admin Center (entra.microsoft.com) unter Geräte > Alle Geräte das Gerät auswählen und „BitLocker Keys anzeigen“ klicken. Alternativ im Intune Admin Center unter Geräte > Alle Geräte > Gerät > Monitor > Recovery keys > „Show Recovery Key“. Das Audit-Log protokolliert jeden Zugriff unter „Key Management“. Rollen siehe Voraussetzungen.

Massenabruf per PowerShell (Graph API)

Install-Module Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Identity.DirectoryManagement -Scope CurrentUser -Force
Import-Module Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Identity.DirectoryManagement
Connect-MgGraph -Scopes 'BitlockerKey.Read.All','Device.Read.All' -NoWelcome

$DeviceID = (Get-MgDevice -filter "displayName eq 'COMPUTERNAME'").DeviceId
$KeyIds = (Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '$DeviceId'").Id
foreach ($keyId in $KeyIds) {
  (Get-MgInformationProtectionBitlockerRecoveryKey -BitlockerRecoveryKeyId $keyId -Select "key").key
}

Nachträgliches Backup in Entra ID

# Key-ID ermitteln
manage-bde -protectors -get C:

# Nachträglich in Entra ID sichern
manage-bde -protectors -aadbackup C: -id "{KeyID-aus-manage-bde-protectors-get}"

Verifizieren: Das Skript gibt je Schlüssel ein 48-stelliges Recovery-Password aus. Nach -aadbackup steht der Schlüssel im Entra Admin Center beim Gerät.

Schritt 7: BitLocker vor Firmware-Updates suspendieren

Das TPM misst beim Start Firmware und Bootkette (unter anderem PCR 0 für die Firmware). Ändert sich die Firmware, die Secure-Boot-Konfiguration oder die Bootreihenfolge, weichen die Werte ab, und BitLocker fordert das Recovery-Password.

# VOR dem Firmware-Update: BitLocker suspendieren
# ohne -rc endet die Suspendierung nach dem nächsten Neustart; -rc 2 für Updates mit zwei Neustarts
manage-bde -protectors -disable C: -rc 1

# Firmware-Update durchführen, dann neu starten

# Falls der Schutz noch ausgesetzt ist: wieder aktivieren
manage-bde -protectors -enable C:

Wurde das Suspendieren vergessen: Recovery-Password eingeben. Danach aktualisiert Windows das Platform Validation Profile automatisch mit den neuen PCR-Messwerten – beim nächsten Start ist keine Recovery-Eingabe mehr nötig.

Verifizieren: Nach dem Update meldet manage-bde -status C: „Protection Status: Protection On“. Steht dort „Protection Off“, führen Sie manage-bde -protectors -enable C: aus.

Schritt 8: Notfall-Wiederherstellung mit manage-bde und repair-bde

Laufwerk per Recovery-Password entsperren

manage-bde -unlock C: -recoverypassword 123456-789012-345678-901234-567890-123456-789012-345678

Laufwerk per DRA-Zertifikat entsperren

manage-bde -unlock D: -Certificate -ct f46563b1d4791d5bd827f32265341ff9068b0c42

Block-Level-Wiederherstellung bei beschädigtem Laufwerk (repair-bde)

repair-bde rettet Daten eines beschädigten Laufwerks auf Block-Ebene. Voraussetzung: AD-Backup mit „Backup recovery password and key package“. Während der Ver- oder Entschlüsselung beschädigte Laufwerke kann es nicht retten.

repair-bde <beschädigtes Laufwerk> <Ziel-Laufwerk> -kp <Pfad-zum-KeyPackage> -rp <48-stelliges-RecoveryPassword>

Verifizieren: Nach -unlock zeigt manage-bde -status „Lock Status: Unlocked“; nach repair-bde öffnet sich das Ziel-Laufwerk im Explorer, und Sie prüfen Stichproben der Dateien.

Troubleshooting / Typische Fehler

Recovery-Abfrage nach BIOS/Firmware-Update: Siehe Schritt 7. Fix: Recovery-Password eingeben, künftig vorher suspendieren.
Silent Encryption startet nicht trotz Intune-Policy: Settings Catalog statt Disk Encryption Policy verwendet (siehe Weg A). Fix: Endpoint Security > Disk Encryption Policy oder Device Configuration > Endpoint Protection verwenden.
Security Baseline blockiert Silent Encryption: Eine Baseline mit Startup-PIN verhindert Silent Encryption. Fix: Richtlinienkonflikt in Intune prüfen, Einstellung übersteuern oder Gerät ausschließen.
„No BitLocker key found“ in Intune, obwohl das Gerät verschlüsselt ist: Gerät beim Verschlüsseln nicht Entra-joined, Policy nicht aktiv oder Verschlüsselung vor dem Enrollment aktiviert. Fix: manage-bde -protectors -aadbackup C: -id {KeyID} ausführen.
Entra-ID-Limit von 200 Recovery-Keys pro Gerät erreicht: Das Key-Backup und damit Silent Encryption schlagen fehl. Fix: nicht mehr benötigte Keys in Entra ID löschen.
Key-Rotation funktioniert nicht: Backup-Policy nicht auf „Required“. Fix: „Do not enable BitLocker until recovery information is stored“ aktivieren, Policy neu zuweisen.
Drittanbieter-Verschlüsselung und Silent BitLocker: Siehe Weg A; doppelte Verschlüsselung kann das System instabil machen. Fix: Inventar vor dem Rollout prüfen.
Intune-Geräteobjekt gelöscht, BitLocker ausgesetzt: Die Key-Protektoren des OS-Volumes fehlen, die Daten liegen ungeschützt, aber verschlüsselt vor. Fix: Gerät neu registrieren, Policy neu anwenden.
TPM-Austausch oder OS-Laufwerk in anderem Gerät: Nach dem Entsperren bindet sich BitLocker an das neue TPM; beim Zurückbauen fragt es erneut. Erwartetes Verhalten.

Häufige Fragen

Wie rufe ich den Recovery Key für ein bestimmtes Gerät aus Entra ID ab?

Wie in Schritt 6 beschrieben: im Entra Admin Center beim Gerät oder im Intune Admin Center unter Monitor > Recovery keys. Standard-User können Keys über myaccount.microsoft.com selbst abrufen, sofern der Tenant das erlaubt.

Was ist der Unterschied zwischen Recovery Password und Recovery Key?

Das Recovery Password ist eine 48-stellige Ziffernfolge, die Sie am Boot-Bildschirm eintippen. Der Recovery Key ist eine .bek-Datei auf einem USB-Laufwerk. Für KMU ist das Recovery Password praktischer.

Warum fordert BitLocker nach einem BIOS-Update zur Recovery auf?

Die Firmware-Änderung verändert die TPM-Messwerte (PCR 0), daher gibt das TPM den Schlüssel nicht frei. Details und Vorbeugung stehen in Schritt 7.

Wann sollte ich TPM+PIN statt TPM-only einsetzen?

Für Außendienst und Geräte mit sensiblen Daten; TPM-only für Bürogeräte mit Fernlöschung über Intune (Tabelle in Schritt 3). TPM+PIN verhindert Silent Encryption.

Wie sichere ich Recovery-Keys ohne Intune und ohne Active Directory?

Wie unter Weg C beschrieben: .bek-Datei auf externem Medium, beim Aktivieren „In Datei speichern“ oder „Drucken“, oder das Recovery-Password aus manage-bde -protectors -get C: im Passwort-Manager ablegen. Nie auf demselben Gerät speichern.

Welche Lizenz benötige ich für BitLocker-Verwaltung per Intune?

Windows Pro, Enterprise oder Education genügen; „Modern BitLocker Management“ und der BitLocker-CSP gelten laut Microsoft ab Pro. Dazu kommt je Benutzer eine Intune-Lizenz, etwa über Microsoft 365 Business Premium, E3 oder E5.

Fazit

Setzen Sie XTS-AES 256-bit, erzwingen Sie das Key-Backup vor der Verschlüsselung („Do not enable BitLocker until recovery information is stored“), nutzen Sie in Intune die Disk Encryption Policy und suspendieren Sie BitLocker vor Firmware-Updates. In hybriden Umgebungen sichern Sie redundant in AD DS und Entra ID.

Weiterführende Anleitungen und Quellen

Quellen: Microsoft Learn: BitLocker-Übersicht, BitLocker-CSP, manage-bde -protectors, BitLocker mit Intune.