Windows Credential Guard ist eine Sicherheitsfunktion von Microsoft, die NTLM Kennworthashes, Kerberos Ticket Granting Tickets und von Anwendungen gespeicherte Domänenanmeldedaten schützt. Ziel ist nicht, dein Kennwort anders darzustellen, sondern zu verhindern, dass diese sensiblen Daten aus einem laufenden Windows heraus einfach ausgelesen werden können.
Wichtig ist aber die Grenze der Funktion: Lokale Konten, Microsoft Konten, generische Webzugänge, Keylogger und physische Angriffe werden dadurch nicht zuverlässig abgefangen. Auch Schadsoftware mit hohen Rechten kann weiterhin die Rechte des bereits angemeldeten Benutzers missbrauchen. Credential Guard ist also ein starker Sicherheitsbaustein, aber kein Ersatz für saubere Kontentrennung, aktuelle Updates und vernünftige Sicherheitsrichtlinien.
Warum Credential Guard heute wichtig ist
Viele Angriffe zielen nicht zuerst auf Dateien, sondern auf Anmeldedaten. Wenn Kennworthashes oder Kerberos Tickets aus dem Speicher gelesen werden können, reicht oft schon ein einzelner kompromittierter PC, um sich im Netzwerk weiterzubewegen. Genau hier setzt Windows Credential Guard an: Die Funktion kapselt besonders sensible Geheimnisse in einer geschützten Umgebung und erschwert typische Angriffe auf Anmeldedaten deutlich.
Wie die Schutzfunktion technisch arbeitet
Im Kern nutzt Credential Guard die virtualisierungsbasierte Sicherheit von Windows. Dabei erstellt der Hypervisor einen isolierten Bereich, in dem sensible Geheimnisse getrennt vom normalen Betriebssystem leben. Der klassische Anmeldeprozess arbeitet weiter, kommuniziert für besonders schützenswerte Daten aber mit einem isolierten Prozess. Genau diese Trennung ist der Grund, warum selbst lokale Administratorrechte nicht automatisch genügen, um an geschützte Geheimnisse zu gelangen.

Auf moderner Hardware profitiert dieser Mechanismus zusätzlich von Secure Boot und idealerweise von einem TPM. Beides macht es deutlich schwerer, die Schutzkette schon beim Start oder über manipulierte Firmware auszuhebeln. In der Praxis heißt das ganz einfach: Je aktueller und sauberer dein Gerät aufgestellt ist, desto besser spielt Credential Guard seine Stärke aus.
Welche Voraussetzungen du vorher prüfen solltest
Bevor du irgendetwas aktivierst, prüfst du zuerst deine Edition und den technischen Unterbau. Offiziell wird Credential Guard in Windows Enterprise und Education unterstützt. Seit Windows 11 ab Version 22H2 kann die Funktion auf geeigneten Geräten zudem standardmäßig aktiv sein. Bei Windows Pro gibt es Sonderfälle, vor allem nach vorheriger Nutzung auf einer passenden Lizenz oder nach bestimmten Upgrade Pfaden. Deshalb solltest du hier nicht raten, sondern immer den Status direkt prüfen.
Technisch braucht Credential Guard vor allem VBS und Secure Boot. Dahinter stecken ein 64 Bit Prozessor mit Virtualisierungserweiterungen, SLAT, passende Firmware und im Idealfall TPM 2.0. Wenn du erst noch prüfen musst, welche Version du einsetzt oder wie du TPM, Secure Boot, Virtualisierung und UEFI erreichst, helfen dir unsere Anleitungen weiter. Dort beschreiben wir Dir auch, wie Du ins BIOS oder ins UEFI kommst.
Wenn du Credential Guard in einer virtuellen Maschine einsetzen willst, muss die VM auf Hyper V als Generation 2 laufen. Auf Generation 1 ist die Funktion nicht vorgesehen.
Welche Windows Editionen unterstützen Credential Guard
Folgende Windows Versionen (beachte unseren Ratgeber „Welches Windows habe ich„) unterstützen Credential Guard direkt im Betriebssystem:
| Windows Version | Unterstützung |
|---|---|
| Windows 11 Enterprise | Ja |
| Windows 11 Education | Ja |
| Windows 11 Pro | Eingeschränkt und abhängig vom Szenario |
| Windows Server | Technisch möglich, aber nicht für jede Serverrolle sinnvoll. Auf Domänencontrollern und Exchange Servern sollte Credential Guard nicht unüberlegt aktiviert werden. |
| Windows Home | Nicht als Zielplattform geeignet |
So prüfst und aktivierst du Windows Credential Guard
Der sauberste Weg ist immer gleich: erst prüfen, dann aktivieren. Und wenn der Rechner später einer Domäne beitreten soll, solltest du Credential Guard möglichst vorher einschalten. Sonst können Benutzer oder Gerätegeheimnisse schon vor der Aktivierung im System vorhanden gewesen sein.
Status mit Systeminformationen prüfen
- Drücke die Windows Taste + R.
- Gib „msinfo32“ ein und bestätige.
- Öffne die Systemübersicht.
- Suche nach dem Eintrag „Ausgeführte virtualisierungsbasierte Sicherheitsdienste„.
- Steht dort Credential Guard, ist die Funktion aktiv.
Der Task Manager ist dafür übrigens kein verlässlicher Beweis. Dass irgendwo „LsaIso.exe“ auftaucht, reicht als Nachweis nicht aus.
Credential Guard Status mit PowerShell prüfen
$Status = (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
if ($Status -contains 1) {
"Credential Guard ist aktiv"
} else {
"Credential Guard ist nicht aktiv"
}
Aktivierung per lokaler Gruppenrichtlinie
Wenn deine Edition den lokalen Gruppenrichtlinien Editor mitbringt, ist das für ein einzelnes Testgerät meist der übersichtlichste Vorgehen. Fehlt dir gpedit.msc, lies zuerst unseren Beitrag zu Gruppenrichtlinien in Windows Home Versionen.

- Drücke
Windows + R. - Gib gpedit.msc ein und bestätige.
- Gehe zu Computerkonfiguration > Administrative Vorlagen > System > Device Guard.
- Öffne die Richtlinie „Virtualisierungsbasierte Sicherheit aktivieren„.
- Setze die Richtlinie auf „Aktiviert„.
- Wähle bei der Credential Guard Konfiguration entweder „Ohne Sperre aktiviert“ oder „Aktiviert mit UEFI Sperre„.
- Starte anschließend bitte den Rechner neu.
Für die meisten Einzelgeräte ist Ohne Sperre aktiviert die sinnvollere Wahl. So kannst du die Einstellung später bei Bedarf auch wieder per Richtlinie oder Registry zurücknehmen. Die Variante mit UEFI Sperre ist härter abgesichert, aber beim Rückbau deutlich unbequemer und aufwändiger.
Aktivierung per Registry
Wenn du lieber direkt arbeitest, kannst du Credential Guard auch per Registry einschalten. Vorher lohnt sich ein Backup der Registry.
- Drücke
Windows + R. - Gib
regeditein und bestätige. - Lege unter „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard“ die benötigten DWORD Werte an.
- Lege unter „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa“ den passenden DWORD Wert an.
- Starte den Rechner neu.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard]
"EnableVirtualizationBasedSecurity"=dword:00000001
"RequirePlatformSecurityFeatures"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LsaCfgFlags"=dword:00000002
Der Wert 2 aktiviert Credential Guard ohne Sperre. Der Wert 1 aktiviert die Variante mit UEFI Sperre. Falls du die Richtlinie über eine Domäne verteilst, kannst du den Rollout bei Bedarf mit gpupdate beschleunigen.
Wichtige Hinweise, Grenzen und typische Fehler
Der häufigste Stolperstein sind alte Authentifizierungsverfahren. Wenn in deiner Umgebung noch NTLMv1, MS CHAPv2, Digest oder CredSSP für Single Sign On genutzt werden, kann Credential Guard spürbare Nebenwirkungen haben. Besonders bei WLAN, VPN oder RDP Situationen kann es dann passieren, dass du Anmeldedaten immer wieder neu eingeben musst.
Auch gespeicherte Windows Anmeldeinformationen im Remotedesktop Client können Probleme machen. Windows schützt diese Daten dann strenger, wodurch gespeicherte Logins nicht mehr wie gewohnt an den Zielrechner weitergereicht werden.
Ein weiterer klassischer Fehler ist das unüberlegte Löschen oder Zurücksetzen des TPM. Dabei können VBS geschützte Daten verloren gehen. Auf Geräten mit gespeicherten Windows Anmeldeinformationen führt das im Zweifel dazu, dass diese Einträge verschwinden und neu angelegt werden müssen.
Für Server gilt: Auf Domänencontrollern bringt Credential Guard keinen sinnvollen Zusatznutzen und kann Kompatibilitätsprobleme verursachen. Auf Exchange Servern ist die Aktivierung nicht vorgesehen. Auf normalen Clients, Admin Workstations und Notebooks mit Domänenanmeldung ist die Funktion dagegen in der Praxis meist deutlich sinnvoller.
Credential Guard, LSA Schutz und Speicherintegrität im Vergleich
Windows bietet mehrere Sicherheitsfunktionen, die auf den ersten Blick ähnlich wirken. Credential Guard, LSA Schutz und Speicherintegrität verfolgen aber unterschiedliche Ziele. Gemeinsam erhöhen sie die Sicherheit des Systems, sie schützen jedoch nicht dieselben Bereiche.
Credential Guard schützt vor allem bestimmte Anmeldeinformationen. Dazu gehören zum Beispiel NTLM Kennworthashes und Kerberos Tickets. Diese sensiblen Informationen werden durch virtualisierungsbasierte Sicherheit in einer isolierten Umgebung geschützt. Das erschwert Angriffe, bei denen Anmeldedaten aus dem Speicher eines laufenden Windows Systems ausgelesen werden sollen.
Der LSA Schutz konzentriert sich dagegen auf den Local Security Authority Prozess. Dieser Prozess ist für wichtige Sicherheits und Anmeldevorgänge in Windows zuständig. Wird der LSA Schutz aktiviert, dürfen nur vertrauenswürdige und entsprechend signierte Komponenten in diesen Prozess eingreifen. Dadurch wird es schwieriger, den LSA Prozess zu manipulieren oder direkt auszulesen.
Die Speicherintegrität ist ein Bestandteil der Kernisolierung. Sie schützt den Windows Kernel besser vor unsicheren Treibern und bestimmten Angriffstechniken. Dabei wird ebenfalls virtualisierungsbasierte Sicherheit genutzt. Der Schwerpunkt liegt aber nicht auf gespeicherten Anmeldedaten, sondern auf dem Schutz des Kernels und der geladenen Treiber.
Vereinfacht gesagt schützt Credential Guard die Anmeldegeheimnisse, LSA Schutz schützt den besonders wichtigen Anmeldeprozess und Speicherintegrität schützt den Kernel vor unsicheren Eingriffen. Die Funktionen ersetzen sich nicht gegenseitig, sondern ergänzen sich. Auf modernen Windows 11 Geräten ist es deshalb sinnvoll, alle drei Funktionen zu prüfen und dort zu aktivieren, wo keine Kompatibilitätsprobleme mit Treibern, Anwendungen oder älteren Authentifizierungsverfahren auftreten.
| Funktion | Schützt vor allem | Wichtigster Nutzen |
|---|---|---|
| Credential Guard | Anmeldeinformationen wie NTLM Hashes und Kerberos Tickets | Erschwert den Diebstahl von Domänenanmeldedaten |
| LSA Schutz | Local Security Authority Prozess | Erschwert Manipulationen und Auslesen des LSA Prozesses |
| Speicherintegrität | Windows Kernel und Treiberumgebung | Blockiert unsichere Treiber und schützt vor bestimmten Kernel Angriffen |

FAQ zu Windows Credential Guard
Das kann sein, aber nicht auf jedem Gerät. Ab Windows 11 22H2 kann Credential Guard auf geeigneten Systemen standardmäßig aktiv sein. Ob das bei dir wirklich der Fall ist, prüfst du am besten direkt mit msinfo32 oder per PowerShell.
Nein. Der Fokus liegt auf NTLM, Kerberos und domänenbezogenen Geheimnissen. Lokale Konten, Microsoft Konten und generische Webanmeldungen profitieren davon nicht in gleicher Weise.
LSA Schutz verhindert vor allem unzuverlässige Eingriffe in den LSA Prozess und erschwert Speicherdumps. Credential Guard geht noch einen Schritt weiter und lagert Geheimnisse in eine isolierte VBS Umgebung aus. Beide Funktionen ergänzen sich, sind aber nicht identisch.
Wenn du Credential Guard ohne UEFI Sperre aktiviert hast, kannst du denselben Weg zurückgehen und die Richtlinie auf Deaktiviert setzen oder in der Registry den relevanten Wert auf 0 stellen. Wurde die Funktion mit UEFI Sperre aktiviert, brauchst du für die Deaktivierung lokalen Zugriff am Gerät und einen deutlich aufwendigeren Rückbau.
Nein, TPM 2.0 ist nicht in jedem Fall zwingend erforderlich, wird aber dringend empfohlen. Windows Credential Guard basiert vor allem auf virtualisierungsbasierter Sicherheit, Secure Boot und geeigneter Hardwarevirtualisierung. Ein TPM 2.0 verbessert die Schutzkette zusätzlich, weil sicherheitsrelevante Startinformationen und Schlüssel besser abgesichert werden können. Für moderne Windows 11 Geräte solltest du deshalb TPM 2.0 möglichst aktiviert lassen.
Ja, das kann passieren. Credential Guard kann bei älteren oder unsauber konfigurierten Authentifizierungsverfahren Probleme verursachen. Besonders bei RDP, VPN, WLAN oder Single Sign On Lösungen kann es vorkommen, dass gespeicherte Anmeldedaten nicht mehr automatisch übergeben werden oder Benutzer ihre Zugangsdaten erneut eingeben müssen.
Häufig sind alte Verfahren wie NTLMv1, MS CHAPv2, Digest oder bestimmte CredSSP Szenarien die Ursache. In solchen Fällen solltest du vor einem breiten Rollout zuerst mit einzelnen Testgeräten prüfen, ob alle Anmeldewege weiterhin sauber funktionieren.
Fazit
Windows Credential Guard ist eine der sinnvollsten Schutzfunktionen gegen den Diebstahl von Anmeldedaten unter Windows. Wenn dein Gerät die Voraussetzungen erfüllt und deine Umgebung keine Altlasten bei VPN, WLAN oder älteren Authentifizierungswegen mitschleppt, solltest du die Funktion ernsthaft einplanen. Wichtig ist nur, dass du nicht blind aktivierst, sondern Edition, Hardware und mögliche Nebenwirkungen vorher sauber prüfst.





Neueste Kommentare