Active Directory: BitLocker-Wiederherstellungsschlüssel fehlt – Lösung

BitLocker-Wiederherstellungsschlüssel fehlt in Active Directory? Erfahren Sie, wie Sie ihn in AD, Azure AD und Microsoft Intune schnell wiederherstellen.

Wenn der BitLocker-Wiederherstellungsschlüssel in Active Directory fehlt, stehen IT-Administratoren vor einem ernsten Problem: Ein verschlüsselter Rechner fordert den 48-stelligen Schlüssel, doch im AD findet sich keine einzige Eintragung.

Dieser Artikel erklärt, warum das passiert, wie Sie den Schlüssel nachträglich sichern und wie Sie durch korrekte Gruppenrichtlinien künftige Lücken zuverlässig verhindern – für lokale AD-Umgebungen ebenso wie für Microsoft Entra ID und Hybridumgebungen.

Was BitLocker in Unternehmensumgebungen leisten soll

BitLocker ist Microsofts integriertes Werkzeug zur vollständigen Laufwerkverschlüsselung und schützt Daten auf Workstations, Notebooks und Servern wirksam vor unbefugtem Zugriff. In Unternehmensumgebungen ist die sichere Speicherung von BitLocker-Wiederherstellungsschlüsseln unerlässlich, um die Datenwiederherstellung zu gewährleisten, falls Benutzer Passwörter vergessen oder Hardwareprobleme auftreten. Die Verschlüsselung selbst ist jedoch nur so stark wie die Ablage des dazugehörigen Wiederherstellungsschlüssels. Deshalb ist das Zusammenspiel zwischen BitLocker und Active Directory ein kritischer Bestandteil jeder sicherheitsbewussten IT-Infrastruktur.

BitLocker gilt für folgende Systeme:

• Windows 10 Pro/Enterprise und Windows 11 Pro/Enterprise (Clientsysteme)
• Windows Server 2016, 2019, 2022 und 2025 (Serversysteme)
• Geräte, die in lokales Active Directory (AD DS) eingebunden sind
• Geräte, die in Microsoft Entra ID (ehemals Azure Active Directory) eingebunden sind
• Geräte in hybriden Umgebungen (Entra-Hybrid-Join)

Der Wiederherstellungsprozess betrifft damit Windows 11, Windows 10, Windows Server 2025, Windows Server 2022, Windows Server 2019 und Windows Server 2016 gleichermassen.

Warum der Wiederherstellungsschlüssel im AD fehlen kann

Ein typisches Problem: Ein mit BitLocker verschlüsselter Rechner streikt und fragt nach dem Recovery Key. „Kein Problem, die GPO sagt, die Schlüssel sind im AD gespeichert“ – so die Theorie. Doch dann kommt das böse Erwachen: Ein Blick ins Active Directory zeigt keine Informationen.

Für dieses Problem gibt es mehrere häufige Ursachen, die nachfolgend im Detail erklärt werden.

Gruppenrichtlinie war bei der Aktivierung noch nicht aktiv

Der häufigste Grund ist schlicht der Zeitpunkt. BitLocker speichert den Wiederherstellungsschlüssel im AD nur dann automatisch, wenn die entsprechende Gruppenrichtlinie bereits beim Verschlüsselungsvorgang aktiv war. Wurde das Laufwerk also verschlüsselt, bevor die GPO überhaupt ausgerollt oder auf den Client repliziert wurde, findet sich im AD kein Eintrag – obwohl die Richtlinie später korrekt gilt.

Zusätzlich ist zu beachten, dass GPO-Replikation Zeit braucht. Nach der Anwendung des Gruppenrichtlinienobjekts muss man 10 bis 20 Minuten warten, während das GPO auf andere Domänencontroller repliziert wird. Wer BitLocker aktiviert, bevor diese Replikation abgeschlossen ist, erhält keinen Eintrag im AD.

GPO ist falsch konfiguriert oder nicht verknüpft

Häufige Probleme sind die falsche Konfiguration der BitLocker-GPO-Active-Directory-Einstellungen sowie die fehlende sichere Speicherung von Wiederherstellungsschlüsseln. Besonders kritisch: Die Richtlinie ist zwar angelegt, aber nicht mit der richtigen Organisationseinheit (OU) verknüpft, in der sich die betroffenen Computer befinden.

Ebenso kommt es vor, dass nur der allgemeine BitLocker-Pfad in der GPO aktiviert wurde, jedoch der spezifische Unterordner für Betriebssystemlaufwerke, Festplattenlaufwerke oder Wechseldatenträger nicht separat konfiguriert wurde – denn jeder Laufwerkstyp benötigt eine eigene Einstellung.

OEM-Vorverschlüsselung ohne AD-Anbindung

Besonders problematisch ist die Vorverschlüsselung durch den OEM-Hersteller, da dieses Thema sehr oft im Zusammenhang mit fehlenden AD-Einträgen auftritt. Viele moderne Notebooks und Workstations werden ab Werk mit aktiviertem BitLocker Device Encryption ausgeliefert. Dabei wird der Wiederherstellungsschlüssel automatisch im Microsoft-Konto des ersten Benutzers gespeichert – nicht jedoch in Active Directory. Sobald das Gerät zur Domäne hinzugefügt wird, bleibt der ursprüngliche Schlüssel im Microsoft-Konto, und im AD erscheint nichts.

Berechtigungsprobleme im Active Directory

Damit BitLocker-Wiederherstellungsinformationen im AD gespeichert werden können, müssen die Computerobjekte die notwendigen Schreibberechtigungen auf das Attribut msFVE-RecoveryPassword besitzen. Fehlen diese Berechtigungen, scheitert die Sicherung still und ohne Fehlermeldung.

Manuell aktiviertes BitLocker ohne AD-Option

Wer BitLocker manuell aktiviert hat, wurde von Windows lediglich aufgefordert, den Schlüssel zu sichern. Dabei stehen drei Optionen zur Wahl: Datei speichern, drucken oder USB-Stick. Die Option „In Active Directory speichern“ erscheint in dieser Auswahl nicht, wenn keine GPO aktiv ist. Deshalb landen die Schlüssel in diesem Fall häufig auf einem USB-Stick oder in einer Textdatei – oder gehen ganz verloren.

Wiederherstellungsschlüssel nachträglich in Active Directory sichern

Wenn der Schlüssel im AD fehlt, das Laufwerk aber noch zugänglich ist, lässt er sich nachträglich sichern. Dafür stehen zwei Methoden zur Verfügung: manage-bde.exe per Eingabeaufforderung und PowerShell.

Methode 1: manage-bde.exe (Eingabeaufforderung)

Öffnen Sie eine Eingabeaufforderung als Administrator und führen Sie zunächst diesen Befehl aus, um die Schlüssel-ID des vorhandenen Wiederherstellungsschlüssels abzurufen:

manage-bde -protectors -get C:

In der Ausgabe suchen Sie den Eintrag „Numerisches Kennwort“ (auch „Recovery Password“). Die 48-stellige Zahlenfolge darunter ist der Wiederherstellungsschlüssel. Notieren Sie außerdem die GUID in geschweiften Klammern, die als Schlüssel-ID dient.

Führen Sie anschließend diesen Befehl aus, um den Schlüssel in AD zu sichern:

manage-bde -protectors -adbackup C: -id {IHRE-SCHLÜSSEL-ID}

Mit diesem Befehl wird der angegebene Schlüssel sicher im Active Directory gesichert und so der verbesserte Schutz und die Wiederherstellung des verschlüsselten Laufwerks gewährleistet.

Methode 2: PowerShell (empfohlen für viele Clients)

Die PowerShell-Variante eignet sich besonders gut für das nachträgliche Massensichern von Schlüsseln über mehrere Geräte hinweg. Öffnen Sie eine PowerShell-Konsole als Administrator und führen Sie aus:

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

Statt manage-bde empfehlen Experten die eingebauten PowerShell-Cmdlets zu verwenden, da diese keine Lokalisierungsprobleme verursachen. Deshalb ist PowerShell mit Backup-BitLockerKeyProtector für Skriptlösungen in grösseren Umgebungen die empfohlene Vorgehensweise.

Methode 3: Für Microsoft Entra ID (Hybridumgebungen)

In hybriden oder reinen Entra-ID-Umgebungen empfiehlt Microsoft eine andere Vorgehensweise. Für Microsoft Entra verbundene Geräte sollte der Wiederherstellungsschlüssel in Microsoft Entra ID gespeichert werden; für in Active Directory eingebundene Geräte hingegen in AD DS.

Das Microsoft Entra Admin Center ermöglicht Administratoren das Abrufen von BitLocker-Wiederherstellungskennwörtern. Eine weitere Möglichkeit ist die Verwendung der Microsoft Graph API, die für integrierte oder skriptbasierte Lösungen nützlich sein kann.

Für die nachträgliche Sicherung in Entra ID via PowerShell verwenden Sie:

BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $KeyProtector.KeyProtectorId

GPO korrekt konfigurieren: Schritt-für-Schritt-Anleitung

Um sicherzustellen, dass künftig alle Wiederherstellungsschlüssel automatisch im AD landen, benötigen Sie eine korrekt konfigurierte Gruppenrichtlinie.

Schritt 1: Gruppenrichtlinienobjekt erstellen

Öffnen Sie die Gruppenrichtlinienverwaltungskonsole (GPMC) auf einem Domänencontroller oder einem Verwaltungsrechner mit installierten RSAT-Tools. Klicken Sie unter dem Domänenknoten mit der rechten Maustaste auf Gruppenrichtlinienobjekte und wählen Sie Neu. Geben Sie dem Objekt einen sprechenden Namen, zum Beispiel GPO-BitLocker-AD-Backup.

Schritt 2: GPO bearbeiten und Pfad aufrufen

Klicken Sie mit der rechten Maustaste auf das neu erstellte GPO und wählen Sie Bearbeiten. Navigieren Sie im Gruppenrichtlinien-Editor zu folgendem Pfad:

Computerkonfiguration
  → Richtlinien
    → Administrative Vorlagen
      → Windows-Komponenten
        → BitLocker-Laufwerkverschlüsselung

Schritt 3: Allgemeine AD-Speicherung aktivieren

Aktivieren Sie die Option „BitLocker-Wiederherstellungsinformationen in Active Directory-Domänendiensten speichern“. Diese Einstellung ist die Grundvoraussetzung für jede automatische AD-Sicherung.

Schritt 4: Laufwerkstypspezifische Einstellungen konfigurieren

Möchte man den Recovery Key für Betriebssystemlaufwerke im Active Directory speichern, aktiviert man die entsprechende Einstellung im Unterordner „Betriebssystemlaufwerke“. Dasselbe gilt separat für Festplattenlaufwerke und Wechseldatenträger. Wählen Sie für jede dieser Kategorien die Einstellung:

• Festlegen, wie BitLocker-geschützte Betriebssystemlaufwerke wiederhergestellt werden können
• Festlegen, wie BitLocker-geschützte Festplattenlaufwerke wiederhergestellt werden können
• Festlegen, wie BitLocker-geschützte Wechseldatenträger wiederhergestellt werden können

Aktivieren Sie jeweils die Option und setzen Sie einen Haken bei „BitLocker-Wiederherstellungsinformationen in AD DS speichern“. Zusätzlich empfiehlt sich die Aktivierung der Option „BitLocker erst aktivieren, nachdem Wiederherstellungsinformationen in AD DS gespeichert wurden“ – so wird BitLocker nur dann aktiv, wenn die AD-Sicherung auch tatsächlich erfolgreich war.

Schritt 5: GPO mit der richtigen OU verknüpfen

Verknüpfen Sie das GPO mit der Organisationseinheit, die die Computerobjekte der zu verwaltenden Geräte enthält – oder wahlweise mit dem gesamten Domänenstamm, wenn alle Rechner abgedeckt werden sollen.

Schritt 6: RSAT-Tool zur Anzeige installieren

Damit Administratoren gespeicherte Schlüssel im AD einsehen können, benötigen Sie den BitLocker Active Directory-Wiederherstellungskennwort-Viewer. Dieser lässt sich per PowerShell mit folgendem Befehl installieren:

Install-WindowsFeature RSAT-Feature-Tools-BitLocker-BdeAducExt, RSAT-Feature-Tools-BitLocker-RemoteAdminTool, RSAT-Feature-Tools-BitLocker

Nach der Installation erscheint in den Eigenschaften eines Computerobjekts in „Active Directory-Benutzer und -Computer“ ein zusätzliches Register „BitLocker-Wiederherstellung“, über das gespeicherte Schlüssel abgerufen werden können.

Wiederherstellungsschlüssel aus Active Directory abrufen

Wenn der Schlüssel korrekt im AD gespeichert wurde, stehen mehrere Wege zur Verfügung, um ihn im Ernstfall abzurufen.

Über die MMC „Active Directory-Benutzer und -Computer“

Suchen Sie das Computerobjekt des betroffenen Geräts, klicken Sie mit der rechten Maustaste darauf und wählen Sie Eigenschaften. Im Register „BitLocker-Wiederherstellung“ (sichtbar nach Installation des RSAT-Viewers) finden Sie alle gespeicherten Schlüssel mit Datum und Schlüssel-ID.

Über PowerShell und das AD-Modul

Get-ADObject -Filter {objectclass -eq "msFVE-RecoveryInformation"} -SearchBase "CN=COMPUTERNAME,OU=IhreOU,DC=domain,DC=local" -Properties msFVE-RecoveryPassword | Select-Object msFVE-RecoveryPassword

Ersetzen Sie dabei COMPUTERNAME und die Domänenpfadangaben entsprechend Ihrer Umgebung.

Über das Microsoft Entra Admin Center

Das Microsoft Entra Admin Center ermöglicht Administratoren ebenfalls das direkte Abrufen von BitLocker-Wiederherstellungskennwörtern über eine grafische Oberfläche. Navigieren Sie im Entra Admin Center zu Geräte → Alle Geräte, wählen Sie das entsprechende Gerät aus und öffnen Sie den Abschnitt BitLocker-Schlüssel.

Massenreparatur: Alle fehlenden Schlüssel im AD per Skript nachholen

In grösseren Umgebungen ist es nicht praktikabel, jeden Rechner einzeln zu behandeln. Deshalb empfiehlt sich ein PowerShell-Skript, das alle domänenverbundenen Computer überprüft und fehlende Schlüssel automatisch sichert.

Das folgende Skript führt diese Aufgabe für den aktuell angemeldeten Computer aus und kann per GPO-Startskript oder über Microsoft Intune als Geräteskript auf alle Clients ausgerollt werden:

$BitLockerVolume = Get-BitLockerVolume -MountPoint $env:SystemDrive
if ($BitLockerVolume.ProtectionStatus -eq "On") {
    $KeyProtector = $BitLockerVolume.KeyProtector |
        Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }
    if ($KeyProtector) {
        Backup-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $KeyProtector.KeyProtectorId
        Write-Host "Schlüssel erfolgreich im AD gesichert."
    } else {
        Write-Host "Kein Wiederherstellungsschlüssel vorhanden – bitte prüfen."
    }
}

Zudem sollten Sie sicherstellen, dass die Registry-Einstellungen auf den Clients korrekt gesetzt sind, da fehlerhafte Konfigurationen die AD-Sicherung ebenfalls verhindern können.

OEM-Vorverschlüsselung: Sonderfall mit besonderem Handlungsbedarf

Besonders in Unternehmensumgebungen, die neue Hardware direkt aus dem Handel einsetzen, ist die OEM-Vorverschlüsselung ein häufig unterschätztes Problem. Dabei aktiviert Windows die BitLocker-Geräteverschlüsselung automatisch, noch bevor das Gerät zur Domäne hinzugefügt wird. Der Wiederherstellungsschlüssel landet in diesem Fall im Microsoft-Konto des ersten Benutzers.

Deshalb empfehlen Administratoren in der Praxis zwei Vorgehensweisen:

Option A – Neu verschlüsseln: Entschlüsseln Sie das Laufwerk vollständig (manage-bde -off C:), warten Sie den Abschluss ab und aktivieren Sie BitLocker anschliessend erneut – diesmal bei aktiver GPO, sodass der Schlüssel korrekt im AD landet.

Option B – Schlüssel nachträglich sichern: Wenn eine erneute Verschlüsselung nicht infrage kommt, sichern Sie den bestehenden Schlüssel wie oben beschrieben mit manage-bde -protectors -adbackup oder dem PowerShell-Cmdlet Backup-BitLockerKeyProtector.

Wiederherstellungsschlüssel im Notfall anwenden

Sobald der Schlüssel vorliegt, gestaltet sich die eigentliche Entsperrung unkompliziert. Der BitLocker-Wiederherstellungsschlüssel ist eine 48-stellige Nummer, die verwendet wird, um ein Volume zu entsperren, wenn es sich im Wiederherstellungsmodus befindet.

Beim Systemstart erscheint ein blauer Bildschirm mit der Aufforderung zur Schlüsseleingabe. Geben Sie dort die 48-stellige Zahlenfolge ein – aufgeteilt in acht Gruppen zu je sechs Ziffern. Alternativ entsperren Sie ein zugängliches, aber gesperrtes Laufwerk per Befehlszeile:

manage-bde.exe -unlock D: -recoverypassword XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX

Ersetzen Sie dabei D: durch den Laufwerksbuchstaben des gesperrten Volumes und die X-Gruppen durch Ihren tatsächlichen Wiederherstellungsschlüssel.

Empfohlene Vorgehensweisen für eine lückenlose Schlüsselverwaltung

Um dauerhaft sicherzustellen, dass kein Wiederherstellungsschlüssel verlorengeht, empfehlen sich folgende Massnahmen:

1. GPO vor der ersten Verschlüsselung einrichten: Konfigurieren Sie die BitLocker-Gruppenrichtlinie vollständig, bevor Sie BitLocker auf irgendeinem Client aktivieren. Setzen Sie zwingend die Option „BitLocker erst aktivieren, nachdem Wiederherstellungsinformationen in AD DS gespeichert wurden“.

2. Regelmässige Inventur per Skript: Führen Sie monatlich ein PowerShell-Skript aus, das alle domänenverbundenen Geräte überprüft und fehlende AD-Einträge meldet. So entdecken Sie Lücken, bevor sie zum Problem werden.

3. Schlüssel nach Hardware-Änderungen erneuern: Wenn über eine GPO festgelegt wurde, dass der Wiederherstellungsschlüssel im Active Directory gespeichert werden soll, greift diese Richtlinie auch beim Anlegen eines jeden neuen Recovery Keys. Erneuern Sie den Schlüssel daher nach jedem BIOS-Update, jeder TPM-Änderung oder jedem Motherboard-Tausch.

4. Alte Schlüssel bereinigen: Alte und nicht mehr gültige Schlüssel bleiben weiterhin im Attribut msFVE-RecoveryPassword des jeweiligen Computerobjekts. Diese sollten manuell über „Active Directory-Benutzer und -Computer“ entfernt werden, um Verwirrung im Ernstfall zu vermeiden.

5. Zugriffsberechtigungen auf Schlüssel einschränken: Es ist in der Regel besser, wenn Benutzer erst gar keinen Zugang zum Wiederherstellungsschlüssel erhalten, da die Gefahr besteht, dass das Kennwort auf Papier notiert oder anderweitig unsicher aufbewahrt wird.

6. Intune für moderne Umgebungen nutzen: In Microsoft-Intune-verwalteten oder Entra-Hybrid-Umgebungen lassen sich BitLocker-Richtlinien über Endpunktsicherheitsrichtlinien in Intune zentralisiert steuern und die Schlüsselsicherung erzwingen – ohne klassische GPO.

Häufige Fragen zu fehlenden BitLocker-Schlüsseln in AD

Warum ist kein BitLocker-Schlüssel im Active Directory zu finden, obwohl BitLocker aktiv ist?

Der häufigste Grund ist, dass BitLocker aktiviert wurde, bevor die GPO zur AD-Sicherung aktiv oder vollständig repliziert war. Ausserdem können OEM-Vorverschlüsselung, fehlende Schreibberechtigungen auf das AD-Objekt oder ein falsch verknüpftes Gruppenrichtlinienobjekt dazu führen, dass kein Eintrag entsteht.

Wie kann man den Wiederherstellungsschlüssel nachträglich in Active Directory sichern?

Solange das verschlüsselte Laufwerk noch zugänglich ist, können Sie den Schlüssel mit dem Befehl manage-bde -protectors -adbackup C: -id {SCHLÜSSEL-ID} oder via PowerShell mit Backup-BitLockerKeyProtector nachträglich ins AD hochladen.

Welcher GPO-Pfad ist für die BitLocker-AD-Sicherung zuständig?

Der relevante Pfad lautet: Computerkonfiguration → Richtlinien → Administrative Vorlagen → Windows-Komponenten → BitLocker-Laufwerkverschlüsselung. Dort müssen für Betriebssystemlaufwerke, Festplattenlaufwerke und Wechseldatenträger jeweils separate Einstellungen aktiviert werden.

Was passiert, wenn der Wiederherstellungsschlüssel weder im AD noch anderswo gespeichert wurde?

In diesem Fall ist der Zugriff auf das verschlüsselte Laufwerk ohne den Schlüssel dauerhaft nicht möglich. Eine Entschlüsselung ohne den Wiederherstellungsschlüssel oder das ursprüngliche TPM-Gerät scheidet aus. Deshalb ist eine proaktive Schlüsselsicherung unerlässlich.

Kann man BitLocker-Schlüssel aus Microsoft Entra ID abrufen?

Ja. Entra-ID-verbundene Geräte speichern Schlüssel in der Cloud. Administratoren rufen diese im Microsoft Entra Admin Center unter „Geräte → BitLocker-Schlüssel“ ab oder nutzen die Microsoft Graph API mit dem Cmdlet Get-MgInformationProtectionBitlockerRecoveryKey.

Was ist der Unterschied zwischen dem Wiederherstellungsschlüssel und dem Wiederherstellungskennwort?

Beide Begriffe bezeichnen dasselbe: die 48-stellige numerische Zeichenfolge, die zum Entsperren eines BitLocker-Volumes im Notfall verwendet wird. Im AD wird diese Information im Attribut msFVE-RecoveryPassword des Computerobjekts gespeichert.

Warum speichert BitLocker den Schlüssel im Microsoft-Konto statt im AD?

Dies geschieht typischerweise bei OEM-Geräten, die vor dem Domänenbeitritt mit einer persönlichen Microsoft-Anmeldung in Betrieb genommen wurden. Windows speichert den Schlüssel dann automatisch im damit verknüpften Microsoft-Konto unter account.microsoft.com.

Wie stellt man sicher, dass BitLocker nur bei erfolgreicher AD-Sicherung aktiviert wird?

Aktivieren Sie in der GPO die Option „BitLocker erst aktivieren, nachdem Wiederherstellungsinformationen in AD DS gespeichert wurden“. Damit scheitert die Verschlüsselung kontrolliert, falls die AD-Sicherung nicht erfolgreich ist – anstatt ohne Schlüsseleintrag durchzulaufen.

Wie findet man im AD, welchem Computer ein Wiederherstellungsschlüssel gehört?

Jeder Schlüssel ist im AD dem jeweiligen Computerobjekt als untergeordnetes Objekt (Klasse msFVE-RecoveryInformation) zugeordnet. Über den RSAT-Viewer in „AD-Benutzer und -Computer“ oder per PowerShell lässt sich der Schlüssel einem bestimmten Gerät und einer Schlüssel-ID eindeutig zuordnen.

Muss der Wiederherstellungsschlüssel nach einem BIOS-Update neu gesichert werden?

Ja. Änderungen an der Firmware, am TPM-Chip oder an zentralen Startkomponenten können dazu führen, dass BitLocker in den Wiederherstellungsmodus wechselt. Zudem erzeugt ein neuer Schlüsselprotector eine neue ID – der alte Eintrag im AD ist dann nicht mehr gültig und sollte durch einen aktuellen ersetzt werden.

Fazit

Ein fehlender BitLocker-Wiederherstellungsschlüssel in Active Directory ist meist vermeidbar: Korrekte Gruppenrichtlinien, die vor der ersten Verschlüsselung greifen, und eine regelmässige Prüfung per PowerShell schliessen die meisten Lücken zuverlässig.

Wer bereits betroffene Geräte hat, sichert bestehende Schlüssel mit manage-bde oder Backup-BitLockerKeyProtector nach – solange das Laufwerk noch zugänglich ist. Jede Stunde, die dabei vergeht, ist ein vermeidbares Risiko.