BitLocker verschlüsselt Laufwerke zuverlässig – doch der eigentliche Risikofaktor im Unternehmenseinsatz ist nicht die Verschlüsselung selbst, sondern der verlorene Recovery-Key. Wer den 48-stelligen Wiederherstellungsschlüssel nicht sicher aufbewahrt, sperrt sich bei einem BIOS-Update, einem TPM-Tausch oder einer Secure-Boot-Änderung dauerhaft aus dem eigenen System aus. Diese Anleitung zeigt dir die drei praxisrelevanten Sicherungswege, erklärt die Voraussetzungen für Silent Encryption, den Unterschied zwischen TPM-only und TPM+PIN, die korrekte AES-256-XTS-Konfiguration sowie die automatische Key-Rotation – inklusive typischer Fehlerbilder und dem 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 (TPM 2.0 dringend empfohlen – wichtig für sicheren Lockout-Mechanismus bei PIN-Brute-Force und Windows 11)
UEFI Native Mode (kein Legacy BIOS, kein CSM/Compatibility Support Module) – 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) und Windows Enterprise E3/E5
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 exportiert und Recovery-Password bekannt
Admin-Rechte auf dem Zielgerät für alle manage-bde-Kommandos

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

Windows verwendet ohne explizite Policy-Konfiguration XTS-AES 128-bit als Standard. Für Unternehmensumgebungen solltest du XTS-AES 256-bit erzwingen – XTS-AES schützt ab Windows 10 Version 1511 zusätzlich vor Cipher-Text-Manipulation. Die Einstellung muss vor der Aktivierung von BitLocker gesetzt sein, da sie rückwirkend nicht auf bereits verschlüsselte Laufwerke wirkt.

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

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

Es gibt drei praxisrelevante Sicherungswege. Die folgende Tabelle hilft dir bei der Entscheidung:

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 du eine Endpoint Security > Disk Encryption Policy verwendest – der Settings Catalog reicht nicht aus, weil dort die TPM-Startup-Authentifizierungseinstellungen fehlen. 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üfe das Geräte-Inventory vorab auf vorhandene Verschlüsselung, um Datenverlust durch doppelte Verschlüsselung zu vermeiden.

Weg B: Active Directory via msFVE-Schema

Das AD speichert Recovery-Passwörter als msFVE-RecoveryInformation-Objekte unterhalb des Computerobjekts. Die 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ägliches Backup in AD DS (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:

Den Recovery-Key niemals auf dem zu verschlüsselnden Laufwerk selbst, im Wurzelverzeichnis eines fest eingebauten Laufwerks oder auf einem bereits verschlüsselten Volume speichern. Empfehlung: Passwort-Manager mit AES-256-Verschlüsselung oder physisch gesicherter Tresor.

Schritt 3: TPM-only oder TPM+PIN entscheiden

Die Entscheidung zwischen TPM-only und TPM+PIN hat erhebliche Auswirkungen auf Benutzerfreundlichkeit, Sicherheitsniveau und ob Silent Encryption überhaupt 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-Mindestlänge beträgt 4 Stellen, der empfohlene Standard liegt bei 6–20 Stellen. TPM 2.0 sperrt nach wiederholten Fehlversuchen (z.B. 32 sofortige Versuche, danach 1 Versuch alle 2 Stunden) – ein wirksamer Brute-Force-Schutz ohne zusätzliche Software.

Schritt 4: Silent Encryption per Intune konfigurieren

Silent Encryption läuft vollständig ohne Benutzerinteraktion – aber nur, wenn alle Voraussetzungen erfüllt sind. Prüfe 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 (Surface, neuere Thin-and-Light-Notebooks) verwendet Silent Encryption immer „Used Space Only", unabhängig von der Policy-Einstellung. Wenn du „Full Encryption" benötigst, setze 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"

Schritt 5: Automatische Key-Rotation konfigurieren

Key-Rotation stellt sicher, dass nach Nutzung eines Recovery-Passwords automatisch ein neues generiert und gesichert wird. Die Rotation funktioniert nur, wenn die Backup-Policy auf „Required" gesetzt ist.

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

In Intune entspricht das der Einstellung „Client-driven recovery password rotation" auf „Enable rotation on Microsoft Entra ID and hybrid joined devices". Zusätzlich muss „Store recovery information in Microsoft Entra ID before enabling BitLocker" auf „Required" stehen – sonst rotiert der Key trotz aktivierter Policy nicht.

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". Jeder Zugriff wird im Audit-Log unter „Key Management" protokolliert. Für die Berechtigung benötigst du die Rolle Cloud Device Administrator, Helpdesk Administrator oder Global Administrator.

Massenabruf per PowerShell (Graph API)

Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser -Force
Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'BitlockerKey.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}"

Schritt 7: BitLocker vor Firmware-Updates suspendieren

Das TPM misst beim Bootvorgang kritische Komponenten (PCR 0: BIOS/Firmware, PCR 4: MBR, PCR 10: Boot Manager). Ändert sich die Firmware, weichen die gemessenen Werte von den erwarteten ab – BitLocker verweigert den Bootvorgang und fordert das Recovery-Password. Dieses Verhalten trifft auch Secure-Boot-Konfigurationsänderungen und Änderungen der Bootreihenfolge.

# VOR dem Firmware-Update: BitLocker suspendieren
manage-bde -protectors -disable C:

# Firmware-Update durchführen, dann neu starten

# NACH dem Update: BitLocker 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.

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 ermöglicht Datenrettung auf Block-Ebene, wenn das Laufwerk beschädigt ist. Voraussetzung: Das AD-Backup muss mit „Backup recovery password and key package" konfiguriert gewesen sein. repair-bde kann kein Laufwerk reparieren, das während der Ver- oder Entschlüsselung beschädigt wurde.

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

Troubleshooting / Typische Fehler

Recovery-Abfrage nach BIOS/Firmware-Update: PCR-Messwerte weichen durch Firmware-Änderung ab. Fix: Recovery-Password eingeben (aktualisiert Platform Validation Profile automatisch). Prävention: Immer manage-bde -protectors -disable C: vor Firmware-Updates.
Silent Encryption startet nicht trotz Intune-Policy: Settings Catalog statt Endpoint Security Disk Encryption Policy verwendet. TPM-Startup-Authentifizierungseinstellungen fehlen im Settings Catalog. Fix: Ausschließlich Endpoint Security > Disk Encryption Policy oder Device Configuration > Endpoint Protection Template verwenden.
Microsoft Defender Security Baseline blockiert Silent Encryption: Die Baseline aktiviert TPM Startup PIN standardmäßig, was Silent Encryption verhindert. Fix: Policy-Konflikte in Intune unter „Policy Conflict Detection" prüfen; Security-Baseline-Einstellung explizit übersteuern oder Gerät aus der Baseline ausschließen.
„No BitLocker key found" in Intune obwohl Gerät verschlüsselt ist: Gerät war beim Verschlüsseln nicht Entra-joined, Policy war nicht aktiv, Entra-ID-Limit von 200 Keys erreicht, oder Verschlüsselung vor dem Intune-Enrollment manuell aktiviert. Fix: manage-bde -protectors -aadbackup C: -id {KeyID} ausführen.
Entra ID Limit von 200 Recovery Keys pro Gerät: Silent Encryption schlägt fehl, weil das Key-Backup nicht erfolgreich ist. Diagnose: Encryption Report in Intune zeigt „No BitLocker key found". Fix: Alte nicht mehr benötigte Recovery-Keys aus Entra ID löschen.
Key-Rotation funktioniert nicht: ConfigureRecoveryPasswordRotation wirkt nur, wenn die Backup-Policy auf „Required" gesetzt ist. Fix: „Do not enable BitLocker until recovery information is stored" aktivieren und Policy-Zuweisung neu auslösen.
Drittanbieter-Verschlüsselung + Silent BitLocker: AllowWarningForOtherDiskEncryption = 0 unterdrückt Warnungen bei bereits aktiver Drittanbieter-Verschlüsselung. BitLocker verschlüsselt dann zusätzlich – Systeminstabilität möglich. Fix: Device-Inventory vor dem Rollout auf vorhandene Verschlüsselung prüfen.
Intune-Geräteobjekt gelöscht – BitLocker suspended: Intune entfernt Key-Protektoren des OS-Volumes. BitLocker ist suspended (ungeschützt, aber nicht entschlüsselt). Fix: Gerät neu enrollen und Policy neu anwenden.
TPM-Austausch oder OS-Laufwerk in anderes Gerät eingebaut: BitLocker bindet sich nach dem ersten Entsperren per Recovery-Password an das neue TPM. Beim Zurückeinbauen in das Originalgerät wird erneut das Recovery-Password benötigt. Korrektes Verhalten – muss im Asset-Management berücksichtigt werden.

Häufige Fragen

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

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". 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 numerische Zeichenfolge – die bei einer Recovery-Abfrage am Boot-Screen eingetippt wird. Der Recovery Key ist ein 256-Bit-Schlüssel als .bek-Datei für ein USB-Laufwerk. Beide können in AD DS, Entra ID, auf USB oder als Ausdruck gesichert werden. Für die meisten KMU-Umgebungen ist das Recovery Password die praktischere Option.

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

Das TPM misst beim Bootvorgang kritische Komponenten. PCR 0 enthält den BIOS/Firmware-Hash, PCR 4 den MBR, PCR 10 den Boot Manager. Ändert sich die Firmware, weichen die Messwerte ab – das TPM gibt den BitLocker-Schlüssel nicht frei. Nach der Recovery-Eingabe aktualisiert Windows das Platform Validation Profile automatisch. Prävention: Immer vor Firmware-Updates suspendieren, danach wieder aktivieren.

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

TPM+PIN empfiehlt sich für Außendienstmitarbeiter und Geräte mit hochsensiblen Daten, da der zweite Faktor auch bei eingeschaltetem Gerät Schutz bietet. TPM-only ist ideal für Bürogeräte mit aktivierter Fernlösch-Option über Intune. Beachte: TPM+PIN blockiert Silent Encryption vollständig.

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

Drei Möglichkeiten: (1) manage-bde -on C: -recoverykey E:\ speichert eine .bek-Datei auf einem externen Medium. (2) In der BitLocker-Systemsteuerung beim Aktivieren „In Datei speichern" oder „Drucken" wählen. (3) manage-bde -protectors -get C: zeigt alle Keys – manuell in einem AES-256-verschlüsselten Passwort-Manager oder Tresor dokumentieren. Entscheidend: Den Key niemals auf demselben Gerät speichern.

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

BitLocker-Management per MDM/CSP erfordert Windows Enterprise E3/E5 oder Education A3/A5. Auf Windows Pro ist nur lokale GPO-Verwaltung möglich. Intune selbst ist in Microsoft 365 Business Premium, E3 und E5 enthalten.

Fazit

BitLocker ist ein ausgereiftes Verschlüsselungswerkzeug – aber der Recovery-Key-Prozess ist die eigentliche Schwachstelle in der Praxis. Die wichtigsten Punkte zusammengefasst: Verschlüsselungsalgorithmus explizit auf XTS-AES 256-bit setzen, Recovery-Key-Backup zwingend vor der Verschlüsselung konfigurieren und mit „Do not enable BitLocker until recovery information is stored" erzwingen, für Intune-Rollouts ausschließlich Endpoint Security Disk Encryption Policy verwenden, und vor jedem Firmware-Update BitLocker suspendieren. Für hybride Umgebungen empfiehlt sich der Backup in beide Systeme (AD DS und Entra ID) als Redundanz. Wer diese Grundregeln einhält, vermeidet den klassischen Albtraum: ein verschlüsseltes Gerät ohne Recovery-Key.

Passende weiterführende Anleitungen auf s-edv.com: Gruppenrichtlinien (GPO) – Grundlagen und Praxis für Windows-Admins, Intune und Windows Autopilot: Geräte automatisiert ausrollen, Active Directory Domäne einrichten: Benutzer und OUs verwalten sowie MFA und Conditional Access in Entra ID einrichten.

Weiterführende Anleitungen und Quellen

Quellen: Microsoft Learn – BitLocker Planning Guide (Juli 2025), Microsoft Learn – Encrypt Windows devices with BitLocker using Intune (Mai 2026), Microsoft Learn – BitLocker Recovery Process (Juli 2025), Microsoft Learn – Configure BitLocker (GPO/CSP-Referenz, Juli 2025), Microsoft Learn – manage-bde on Befehlsreferenz, Windows OS Hub – Store BitLocker Recovery Keys in Active Directory.