Windows Hello: Passwortlose Authentifizierung erklärt

Windows Hello ist Microsofts integriertes Framework für die passwortlose Authentifizierung in Windows 10 und 11. Es ermöglicht Benutzern die Anmeldung per Biometrie (Gesicht, Fingerabdruck oder Iris) oder einer PIN, die durch kryptografische Schlüssel im Trusted Platform Module (TPM) des Geräts geschützt ist. Im Gegensatz zu Passwörtern verlassen Windows Hello-Anmeldeinformationen das Gerät nie und sind kryptografisch an die lokale Hardware gebunden. Dadurch sind sie resistent gegen Phishing, Anmeldeinformationsdiebstahl und Replay-Angriffe. Windows Hello for Business erweitert diese Funktionalität auf Unternehmensumgebungen und unterstützt Microsoft Entra ID, Active Directory und die FIDO2-Passkey-Authentifizierung über drei Bereitstellungsmodelle.

Wichtige Erkenntnisse

• Es gibt keinen direkten Migrationspfad von einer Zertifikatsvertrauensstellung zu einer Cloud-Kerberos-Vertrauensstellung. Der vorhandene Windows Hello-Container muss gelöscht werden, bevor ein Gerät zu einer Cloud-Kerberos-Vertrauensstellung migriert werden kann.
• Windows Hello ersetzt Passwörter durch ein TPM-gestütztes asymmetrisches Schlüsselpaar. Der private Schlüssel verlässt niemals das Gerät, sodass kein gemeinsames Geheimnis zum Ausspähen, Stehlen oder für Replay-Angriffe verfügbar ist.
• Windows Hello for Business (WHfB) unterstützt drei Vertrauensmodelle für Unternehmen: Cloud-Kerberos-Vertrauensstellung, Schlüsselvertrauensstellung und Zertifikatsvertrauensstellung. Cloud-Kerberos-Vertrauensstellung ist die von Microsoft empfohlene Standardeinstellung für Hybridbereitstellungen.
• Konten in privilegierten Active Directory-Gruppen, einschließlich Domänenadministratoren, können sich systembedingt nicht über Cloud Kerberos Trust authentifizieren, da die Kennwortreplikationsrichtlinie des AzureADKerberos-Objekts dies blockiert.
• Microsoft Entra-Passkeys unter Windows wurden im Jahr 2026 allgemein verfügbar, sodass Windows Hello auch auf Geräten, die nicht bei Entra eingebunden sind, als FIDO2-Passkey-Authenticator fungieren kann.

Warum Passwörter nicht mehr ausreichen

Laut Microsofts Digital Defence Report 2024 blockiert die Multi-Faktor-Authentifizierung über 99 % der identitätsbasierten Angriffe. Dennoch machen Password Spraying, Credential Stuffing und Phishing-Kampagnen weiterhin den Großteil der Erstzugriffe in Microsofts globaler Telemetrie aus, die im vergangenen Jahr über 7,000 Passwortangriffe pro Sekunde verzeichnete. Das Kernproblem ist strukturell bedingt: Passwörter sind gemeinsame Geheimnisse. Sie werden über Netzwerke übertragen, in Datenbanken gespeichert und routinemäßig für verschiedene Dienste wiederverwendet. Jede einzelne Kompromittierung kann zu einer Kettenreaktion von Kontoübernahmen führen.

Die fünf Fehlerarten der passwortbasierten Authentifizierung sind gut dokumentiert und hartnäckig:

• Brute-Force- und Wörterbuchangriffe, die schwache oder wiederverwendete Anmeldeinformationen ausnutzen.
• Phishing-Kampagnen, die Benutzer dazu verleiten, ihre Zugangsdaten auf gefälschten Webseiten einzugeben.
• Credential Stuffing, bei dem Passwörter ausgenutzt werden, die bei unabhängigen Datenlecks erbeutet wurden.
• Diebstahl von Passwortdatenbanken, wodurch gehashte Zugangsdaten offline geknackt werden können.
• Barrieren für die Zugänglichkeit, die Nutzer mit Sehbehinderungen oder motorischen Einschränkungen benachteiligen.

Windows Hello behebt alle fünf Fehlermodi, indem es das Modell des gemeinsamen Geheimnisses durch eine gerätegebundene, asymmetrische kryptografische Anmeldeinformation ersetzt, die nicht durch Phishing abgefangen, repliziert oder übertragen werden kann.

Was ist Windows Hello?

Windows Hello ist Microsofts biometrische und PIN-basierte Lösung. Beglaubigung Das in Windows 10 eingeführte und in Windows 11 deutlich erweiterte Framework ersetzt die Passworteingabe durch eine von drei biometrischen Gesten: Gesichtserkennung, Fingerabdruckscan oder Iris-Scan, abhängig von den Hardwarefunktionen des Geräts. Eine PIN wird ebenfalls als Ausweich- oder primäre Methode unterstützt; entscheidend ist, dass sich diese PIN von einem Passwort dadurch unterscheidet, dass sie gerätespezifisch ist und vom TPM (Technical Property Manager) verwaltet wird, anstatt an einen Server übertragen zu werden.

Windows Hello existiert in zwei Ebenen:

Funktion	Windows Hello (Verbraucherversion)	Windows Hello for Business (WHfB)
Zielbenutzer	Persönliches / Microsoft-Konto	Unternehmens-/Entra-ID oder AD
Anmeldeinformationstyp	Gerätegebundener Schlüssel (Software, falls kein TPM vorhanden)	TPM-gestütztes asymmetrisches Schlüsselpaar (gemäß Richtlinie erforderlich)
Identitätsanbieter	Microsoft-Konto (MSA)	Microsoft Entra ID, Active Directory, AD FS
FIDO2-Unterstützung	Ja, FIDO-Alliance-zertifiziert seit Windows 10 1903	Ja, gilt ab 2026 auch für Entra-Passkeys (FIDO2).
Unternehmensrichtlinie (Intune / Gruppenrichtlinie)	Begrenzt	Vollständige MDM-/Gruppenrichtlinienunterstützung
Zugriff auf lokale Ressourcen	Nicht unterstützt	Ja, über Cloud Kerberos Trust oder Zertifikat Vertrauen können

So funktioniert Windows Hello: Die kryptografische Grundlage

Um Windows Hello zu verstehen, muss man wissen, wie es das Passwortmodell durch Public-Key-Kryptografie ersetzt. Während der Registrierung generiert das Gerät ein asymmetrisches Schlüsselpaar.

Schlüsselerzeugung und -speicherung

• Das TPM generiert für den Benutzer auf diesem Gerät ein privates und ein öffentliches Schlüsselpaar.
• Der private Schlüssel ist im TPM versiegelt und wird niemals exportiert. Er kann nicht extrahiert werden, nicht einmal vom Betriebssystem.
• Der öffentliche Schlüssel wird beim Identitätsanbieter (Microsoft Entra ID, Active Directory oder AD FS) registriert und dem Benutzerkonto zugeordnet.
• Biometrische Daten (Gesichtsvorlage, Fingerabdruckvorlage) werden lokal in einer verschlüsselten Datenbank unter C:\Windows\System32\WinBioDatabase gespeichert. Sie verlassen das Gerät niemals und werden niemals an Microsoft-Server übertragen.

Authentifizierungsablauf

Wenn sich ein Benutzer anmeldet, ist die Abfolge wie folgt:

1. Der Benutzer zeigt dem Windows Hello-Container eine biometrische Geste oder eine PIN an.
2. Die Geste ermöglicht den Zugriff auf den im TPM gespeicherten privaten Schlüssel. Die PIN oder die biometrische Authentifizierung dient als lokaler Entsperrfaktor und verlässt das Gerät nie.
3. Das Gerät verwendet den privaten Schlüssel, um eine kryptografische Herausforderung des Identitätsanbieters zu signieren.
4. Der Identitätsanbieter überprüft die Signatur mithilfe des registrierten öffentlichen Schlüssels und stellt ein Authentifizierungstoken aus.
5. Der Benutzer erhält Zugriff auf Windows, Microsoft 365, Entra-geschützte Apps und, unter WHfB, auf lokale Ressourcen.

Da der private Schlüssel an das TPM gebunden ist und die PIN oder die biometrischen Daten das Gerät nie verlassen, eliminiert dieses Authentifizierungsmodell Angriffsvektoren, die auf Passwörter abzielen. Es gibt keine Anmeldeinformationen zum Phishing, keine Datenbank, die gehackt werden könnte, und keine über das Netzwerk übertragenen Geheimnisse, die abgefangen werden könnten.

Erweiterte Anmeldesicherheit (ESS)

Windows 11 führt die verbesserte Anmeldesicherheit (Enhanced Sign-in Security, ESS) ein. Diese isoliert den Abgleich von Gesichtsvorlagen in einer Virtualisierungsbasierten Sicherheitsumgebung (Virtualization-Based Security, VBS), die beim Systemstart einen sicheren Kanal zu TPM 2.0 herstellt. Für Fingerabdrücke nutzt ESS Hardware zur Gesichtserkennung direkt auf dem Sensormodul. Dort werden Abgleich und Speicherung der Vorlage durchgeführt.

Unter ESS kann selbst ein kompromittierter Betriebssystemkern nicht auf biometrische Vorlagendaten zugreifen oder gefälschte biometrische Signale einspeisen. ESS erfordert speziell entwickelte biometrische Sensoren und wird in Hochsicherheitsumgebungen durch Richtlinien durchgesetzt.

Windows Hello for Business: Bereitstellungsmodelle für Unternehmen

Für Organisationen, die Windows Hello for Business einsetzen, unterstützt Microsoft drei Vertrauensmodelle. Die Wahl des richtigen Modells hängt von der Verzeichnisstruktur und bestehenden Systemen ab. PKI-Infrastrukturund Anforderungen an den Zugriff vor Ort.

Vertrauensmodell	Funktionsweise	Am besten geeignet für
Cloud Kerberos Trust	Verwendet Microsoft Entra Kerberos zur Ausstellung partieller TGTs. Keine PKI oder Schlüsselsynchronisierung erforderlich.	Hybride und reine Entra-Umgebungen. Microsofts empfohlene Standardeinstellung für neue Bereitstellungen.
Schlüsselvertrauen	Der öffentliche Schlüssel wird in Active Directory gespeichert. Domänencontroller benötigen Kerberos-Authentifizierungszertifikate; Entra Connect synchronisiert die Schlüssel.	Hybridumgebungen mit einer bestehenden Enterprise-PKI, die DC-Zertifikate ausstellen kann.
Zertifikat Vertrauen können	AD FS stellt Anmeldezertifikate für den WHfB-Container aus. Eine vollständige PKI-Infrastruktur ist lokal erforderlich.	Organisationen, die eine zertifikatsbasierte Smartcard-Äquivalenz benötigen, oder RDP/VDI-Szenarien, die Benutzerzertifikate erfordern.

Cloud Kerberos Trust: Der empfohlene Weg

Cloud Kerberos Trust, eingeführt im Jahr 2022, beseitigt die beiden größten Hürden für die Einführung von WHfB: den Bedarf an einer vollständigen lokalen PKI und die Notwendigkeit, öffentliche Schlüssel mit Active Directory zu synchronisieren. Stattdessen nutzt es dieselbe Entra-Kerberos-Infrastruktur, die bereits die passwortlose Anmeldung nach FIDO2 für Hybridumgebungen ermöglicht. Administratoren konfigurieren es mit einem einzigen PowerShell-Befehl zur Erstellung des AzureADKerberos-Objekts, gefolgt von zwei Intune-Richtlinien oder Gruppenrichtlinienobjekten (GPOs).

Der Authentifizierungsablauf unter Cloud Kerberos Trust: Wenn ein Benutzer sein Gerät mit einer PIN oder biometrischen Daten entsperrt, gibt das TPM den privaten WHfB-Schlüssel frei, der eine Authentifizierungsanfrage an Entra ID signiert. Entra ID sendet ein partielles TGT zurück, ein von der Cloud ausgestelltes Kerberos-Ticket, das der Domänencontroller gegen ein vollständiges lokales Kerberos-TGT eintauscht. Dadurch wird Single Sign-On (SSO) für lokale Ressourcen wie Dateifreigaben und Intranet-Anwendungen ohne erneute Anmeldeaufforderung ermöglicht. Zu keinem Zeitpunkt wird ein Passwort benötigt.

Es gelten zwei betriebliche Einschränkungen. Erstens können sich Konten, die direkte oder indirekte Mitglieder privilegierter, integrierter Sicherheitsgruppen sind (einschließlich Domänenadministratoren), nicht über Cloud Kerberos Trust authentifizieren. Das AzureADKerberos-Objekt verhält sich wie ein schreibgeschützter Domänencontroller, und seine standardmäßige Kennwortreplikationsrichtlinie verhindert die Nutzung durch privilegierte Konten – dieselbe Einschränkung, die auch für Standard-RODCs gilt.

Microsoft rät von einer Lockerung dieser Richtlinie ab, da dadurch eine Sicherheitslücke zwischen Entra ID und Active Directory entstehen würde. Zweitens unterstützt Cloud Kerberos Trust keine RDP- oder VDI-Anmeldung mit bereitgestellten Anmeldeinformationen. Organisationen, die für diese Szenarien eine zertifikatbasierte Smartcard-Äquivalenz benötigen, sollten stattdessen Certificate Trust oder Remote Credential Guard verwenden.

Für die Implementierung von Certificate Trust ist eine funktionierende Enterprise-PKI erforderlich, die sowohl Domänencontroller-Zertifikate als auch optionale Benutzeranmeldezertifikate ausstellt. Die PKI-Services von Encryption Consulting bieten umfassende PKI-Design-, Implementierungs- und Management-Services für IT-Umgebungen, einschließlich der CA-Hierarchie, Zertifikatvorlagen und der für eine Certificate-Trust-WHfB-Implementierung erforderlichen Intune-Integration.

Windows Hello, FIDO2 und Entra-Passkeys

Windows Hello ist seit Windows 10 Version 1903 von der FIDO Alliance FIDO2-zertifiziert. Das bedeutet, dass Windows Hello als Plattformauthentifikator fungiert, der mit den WebAuthn- und CTAP2-Spezifikationen kompatibel ist – denselben offenen Standards, die auch Passkeys in Browsern, Betriebssystemen und Identitätsanbietern zugrunde liegen.

Windows Hello als FIDO2-Plattform-Authentifikator

Wenn eine Website oder Anwendung FIDO2 anfordert BeglaubigungWindows Hello dient als lokaler Authentifizierungsalgorithmus. Es generiert ein FIDO2-Schlüsselpaar im Windows Hello-Schlüsselcontainer, schützt den privaten Schlüssel mit dem TPM und gibt ihn erst frei, nachdem der Benutzer die lokale biometrische Authentifizierung oder PIN-Prüfung erfolgreich abgeschlossen hat. Das Ergebnis ist ein gerätegebundener Passkey, der nicht per Phishing ausgenutzt werden kann, da er kryptografisch an einen bestimmten Ursprung – die Domain der Website – gebunden ist und somit auf gefälschten Anmeldeseiten nicht funktioniert.

Windows Hello ist seit Windows 10 Version 1903 von der FIDO Alliance FIDO2-zertifiziert. Das bedeutet, dass Windows Hello als Plattformauthentifikator fungiert, der mit den WebAuthn- und CTAP2-Spezifikationen kompatibel ist – denselben offenen Standards, die auch Passkeys in Browsern, Betriebssystemen und Identitätsanbietern zugrunde liegen.

Entra-Passkeys über Windows Hello (2026)

Microsoft begann im März 2026 mit der schrittweisen Einführung von Microsoft Entra-Passkeys unter Windows in einer öffentlichen Vorschauphase und erweiterte damit die Funktionalität. passwortlose Authentifizierung Die Funktion ist nun auch für Windows-Geräte verfügbar, die nicht in Entra eingebunden oder von Entra verwaltet werden. Sie wird weltweit bis Mitte 2026 eingeführt und in den darauffolgenden Monaten in US-amerikanischen Regierungs-Cloud-Umgebungen (GCC, GCC High und DoD) bereitgestellt. Mit der allgemeinen Verfügbarkeit entfiel die Anforderung der öffentlichen Vorschau, dass Administratoren Windows Hello-AAGUIDs explizit in einem Passkey-Profil zulassen mussten. Organisationen, deren Passkey-Profile bereits gerätegebundene, nicht-attestierte Passkeys erlauben, haben nun standardmäßig Entra-Passkeys unter Windows aktiviert.

Bei dieser Konfiguration registrieren Benutzer einen gerätegebundenen Passkey, der im Windows Hello-Container gespeichert wird und per Gesichtserkennung, Fingerabdruck oder PIN authentifiziert wird. Der Passkey ist kryptografisch an das Gerät gebunden und wird niemals über das Netzwerk übertragen, wodurch er vor Phishing- und Credential-Stuffing-Angriffen geschützt ist.

Wichtige Details zur Entra-Passkey-Integration:

• Jedes Entra-Konto registriert seinen eigenen Passkey pro Gerät. Mehrere Konten können auf einem einzigen Gerät gleichzeitig existieren.
• Passkeys sind gerätegebunden und können nicht geräteübergreifend synchronisiert werden. Jedes Gerät erfordert eine separate Registrierung.
• Windows Hello for Business bleibt die empfohlene Methode für verwaltete, in Entra eingebundene Geräte. Entra-Passkeys unter Windows ergänzen Szenarien mit nicht verwalteten Geräten und unterstützen keine Geräteanmeldung.
• WHfB-Anmeldeinformationen und ein Entra-Passkey können nicht gleichzeitig im selben Container für dasselbe Konto vorhanden sein. Ist eine WHfB-Anmeldeinformation vorhanden, wird die Passkey-Registrierung blockiert, bis diese entfernt wird. Daher hat WHfB auf verwalteten Geräten Vorrang. Microsoft weist darauf hin, dass diese Blockierung aufgehoben werden kann, sobald die Gesamtzahl der Passkeys, WHfB-Anmeldeinformationen und Mac-Plattform-Anmeldeinformationen eines Benutzers auf dem Gerät 50 überschreitet. Dies ist ein seltener Sonderfall, der typische Geräte mit nur einem oder wenigen Konten wahrscheinlich nicht betrifft.

Windows Hello vs. FIDO2-Sicherheitsschlüssel

Abmessungen	Windows Hello (Plattformauthentifikator)	FIDO2-Sicherheitsschlüssel (Roaming-Authenticator)
Tragbarkeit	Gerätegebunden. Der Benutzer muss sich auf jedem Gerät erneut registrieren.	Über USB, NFC oder Bluetooth mit verschiedenen Geräten kompatibel.
Idealer Benutzer	Gerätegebundene Mitarbeiter, Wissensarbeiter	Mitarbeiter im direkten Kundenkontakt, gemeinsam genutzte Geräteumgebungen
Infrastrukturkosten	Kein Hardwarekauf erforderlich (nutzt vorhandenes TPM).	Pro Benutzer ist der Kauf eines physischen Schlüssels erforderlich.
PKI-Anforderung	Optional (nur für das Zertifikatsvertrauensmodell)	Keine Präsentation
RDP/VDI-Anmeldung	Unterstützt mit Remote Credential Guard oder Certificate Trust	Unterstützt über Web-Anmeldung unter Windows 11 24H2 und Windows Server 2025

Sicherheits- und Betriebsvorteile

Phishing-Resistenz

Windows Hello-Anmeldeinformationen sind kryptografisch an die Ursprungsdomäne der vertrauenden Partei, also die Domain der Website oder des Identitätsanbieters, gebunden. Anmeldeinformationen, die für login.microsoftonline.com registriert sind, reagieren nicht auf eine Authentifizierungsanfrage einer gefälschten, ähnlich aussehenden Domain. Diese in der WebAuthn-Spezifikation definierte Ursprungsbindung ist der Hauptgrund dafür, dass Phishing-Angriffe gegen die FIDO2- und Windows Hello-Authentifizierung wirkungslos sind.

Kein Risiko für eine Anmeldeinformationsdatenbank

Da serverseitig kein gemeinsames Geheimnis gespeichert wird, gibt es weder einen Passwort-Hash noch Anmeldeinformationen, die vom Identitätsanbieter gestohlen werden könnten. Der Server speichert lediglich den öffentlichen Schlüssel des Benutzers, der für einen Angreifer ohne Zugriff auf den zugehörigen, im TPM des Geräts gespeicherten privaten Schlüssel wertlos ist.

MFA by Design

Windows Hello ist von Natur aus multifaktoriell. Es kombiniert etwas, das Sie besitzen – das registrierte Gerät mit dem TPM-gebundenen Schlüssel – mit etwas, das Sie sind – einem biometrischen Merkmal – oder etwas, das Sie wissen – einer geräteinternen PIN. Dies erfüllt die Anforderungen der Multi-Faktor-Authentifizierung gemäß [Richtlinie 1] NIST SP 800-63B Authenticator Assurance Level 2 (AAL2) ist für die meisten Unternehmensanwendungen ausreichend. In Umgebungen mit hohen Sicherheitsanforderungen, die AAL3 erfordern, kann die TPM-Attestierung per Richtlinie erzwungen werden, um zu überprüfen, ob sich der Schlüssel auf zertifizierter Hardware befindet.

Phishing-Resistenz

Zugänglichkeit und Benutzererfahrung

Die biometrische Anmeldung beseitigt Hürden für Nutzer, die Schwierigkeiten mit der Passworteingabe haben. Die Gesichtserkennung ermöglicht eine berührungslose Authentifizierung, und da Windows Hello gerätespezifisch ist, stehen bei einem Ausfall keine Server zur Verfügung. Microsoft berichtet, dass Unternehmen, die auf Windows Hello umgestiegen sind, messbare Rückgänge bei Helpdesk-Anrufen im Zusammenhang mit Passwortzurücksetzungen verzeichnen – einer der häufigsten Kategorien im IT-Support.

FIDO2 SSO über verschiedene Anwendungen hinweg

Windows Hello-Anmeldeinformationen funktionieren für alle Anwendungen und Websites, die FIDO2/WebAuthn unterstützen, darunter Microsoft 365, Azure-geschützte Apps, GitHub, Dropbox, Finanzdienstleistungsplattformen und ein wachsendes Ökosystem von SaaS-Anwendungen für Unternehmen. In Unternehmensumgebungen ermöglicht WHfB Single Sign-On für Cloud- und lokale Ressourcen über Kerberos, ohne dass sich Benutzer für jeden Dienst erneut authentifizieren müssen.

Zugänglichkeit und Benutzererfahrung

Die biometrische Anmeldung beseitigt Hürden für Nutzer, die Schwierigkeiten mit der Passworteingabe haben. Insbesondere die Gesichtserkennung ermöglicht eine berührungslose Authentifizierung, und da Windows Hello gerätespezifisch ist, stehen bei einem Ausfall keine Server zur Verfügung. Microsoft berichtet, dass Unternehmen, die auf Windows Hello umgestiegen sind, messbare Rückgänge bei Helpdesk-Anrufen im Zusammenhang mit Passwortzurücksetzungen verzeichnen – einer der häufigsten Kategorien im IT-Support.

FIDO2 SSO über verschiedene Anwendungen hinweg

Windows Hello-Anmeldeinformationen funktionieren für alle Anwendungen und Websites, die FIDO2/WebAuthn unterstützen, darunter Microsoft 365, Azure-geschützte Apps, GitHub, Dropbox, Finanzdienstleistungsplattformen und ein wachsendes Ökosystem von SaaS-Anwendungen für Unternehmen. In Unternehmensumgebungen ermöglicht WHfB die einmalige Anmeldung für Cloud- und lokale Ressourcen (via Kerberos), ohne dass sich Benutzer für jeden Dienst erneut authentifizieren müssen.

Windows Hello for Business einführen: Was die IT wissen muss

Die Bereitstellung von Windows Hello for Business erfordert eine Planung in vier Bereichen: Hardware, Verzeichnis, Richtlinien und Benutzer-Onboarding.

Hardwarevoraussetzungen

• Für den Schutz von Schlüsseln auf Unternehmensebene ist TPM 2.0 erforderlich. TPM 1.2 wird zwar unterstützt, aber aufgrund von Richtlinienunterschieden nicht empfohlen.
• Für die Gesichtserkennung wird eine Infrarotkamera mit Anti-Spoofing-Funktion benötigt. Standard-Webcams reichen für Windows Hello Face nicht aus.
• Für Enhanced Sign-in Security (ESS) werden spezielle ESS-kompatible biometrische Sensoren und ein VBS-fähiges Gerät mit TPM 2.0 benötigt.

Verzeichnis- und Identitätsvoraussetzungen

• Cloud Kerberos Trust: ein Microsoft Entra ID-Mandant, Entra Connect-Synchronisierung, Windows Server 2016 oder höher DCs und Intune für die Richtlinienbereitstellung.
• Key Trust: eine unternehmensweite PKI zur Ausstellung von DC-Kerberos-Authentifizierungszertifikaten (mindestens RSA 2048 / SHA-256, Key Storage Provider erforderlich).
• Zertifikatsvertrauensstellung: lokales AD FS, eine unternehmensweite PKI mit Benutzerzertifikatvorlagen und Intune oder GPO für Richtlinien.

Richtlinienkonfiguration über Intune

Für Cloud-Kerberos-Vertrauensstellung benötigt der Intune-Einstellungskatalog drei wichtige Richtlinieneinstellungen: „Windows Hello for Business verwenden“ (Aktiviert), „Cloud-Vertrauensstellung für lokale Authentifizierung verwenden“ (Aktiviert) und „Sicherheitsgerät erforderlich“ (Aktiviert, wodurch die Speicherung von TPM-Schlüsseln erzwungen wird). Zertifikatsvertrauensrichtlinien dürfen nicht gleichzeitig konfiguriert werden, da die Zertifikatsvertrauensstellung die Cloud-Vertrauensstellung überschreibt, wenn beide vorhanden sind.

Benutzerregistrierung

Nachdem die Richtlinie bereitgestellt wurde und das Gerät die Voraussetzungen erfüllt, startet die Bereitstellung von Windows Hello for Business automatisch nach der ersten Anmeldung des Benutzers. Der Benutzer legt eine PIN fest, deren Komplexität und Länge durch die Richtlinie vorgegeben sind, und kann optional biometrische Daten registrieren. Die PIN ist gerätespezifisch, wird niemals über das Netzwerk übertragen und durch die TPM-Sperrrichtlinie geschützt. Dadurch sind Brute-Force-Angriffe ohne physischen Gerätezugriff praktisch unmöglich.

Windows Hello und PKI: Die Verbindung

Obwohl Cloud Kerberos Trust die PKI-Abhängigkeit für die meisten Bereitstellungen reduziert, bleibt PKI in verschiedenen Szenarien für Windows Hello relevant:

• Bei der Bereitstellung von Zertifikatsvertrauenslösungen werden Benutzeranmeldezertifikate über eine Unternehmenszertifizierungsstelle im Windows Hello-Container ausgestellt, wodurch eine Smartcard-Äquivalenz für Szenarien erreicht wird, die eine zertifikatbasierte Authentifizierung erfordern.
• Domänencontrollerzertifikate sind sowohl im Key-Trust- als auch im Certificate-Trust-Modell erforderlich. Diese Vorlagen müssen moderne Kryptografie (RSA 2048+, SHA-256, Key Storage Provider) verwenden und dürfen keine veralteten v1-Vorlagen sein.
• Die TPM-Schlüsselattestierung erfordert, wenn sie über eine Richtlinie erzwungen wird, von der Zertifizierungsstelle die Überprüfung, ob der WHfB-Schlüssel innerhalb eines zertifizierten TPM generiert wurde, wodurch eine Hardware-Sicherheitskette bereitgestellt wird.
• Certificate Trust unterstützt RDP/VDI-Szenarien und die S/MIME-E-Mail-Signierung, Anwendungsfälle, die von schlüsselbasierten oder Cloud-Kerberos-Vertrauensmodellen nicht abgedeckt werden.
• Vertrauensmodelle sind nach der Bereitstellung nicht mehr ohne Weiteres austauschbar. Die Migration von Key Trust zu Cloud Kerberos Trust wird direkt über Gruppenrichtlinien oder Intune unterstützt. Es gibt keinen vergleichbaren direkten Weg von Certificate Trust zu Cloud Kerberos Trust: Der vorhandene Windows Hello-Container muss gelöscht werden, bevor das Gerät unter Cloud Kerberos Trust neu bereitgestellt werden kann. Organisationen, die von Certificate Trust wegkommen möchten, sollten diesen erneuten Registrierungsschritt berücksichtigen und ihn nicht als reine Richtlinienänderung behandeln.

Für Organisationen mit einer älteren PKI, die vor Windows Hello entwickelt wurde, ist die Modernisierung der Vorlagen zwingend erforderlich. Ältere Domänencontroller-Vorlagen (v1) verfügen nicht über die Kerberos-Authentifizierungs-EKU und verwenden keine CNG-Schlüsselspeicheranbieter. Beides ist jedoch für die Funktion der WHfB-Zertifikatvertrauensstellung notwendig.

Regulatorische Ausrichtung und Compliance-Überlegungen

Windows Hello for Business ist mit mehreren aktuellen regulatorischen und Standardisierungsrahmen kompatibel:

Rahmen / Regulierung	Relevanz von Windows Hello
NIST SP 800-63B	WHfB mit TPM-gestützten Schlüsseln und Biometrie erfüllt AAL2. TPM-Attestierung und ESS können die Anforderungen von AAL3 unterstützen.
CISA-Leitfaden für Phishing-resistente MFA	Die FIDO2-basierte Authentifizierung, die WHfB implementiert, wird in den CISA-Richtlinien für Bundesbehörden ausdrücklich als phishingresistente MFA-Methode aufgeführt.
Microsoft Secure Future Initiative	Microsofts SFI, das im November 2023 eingeführt wurde, schreibt die Multi-Faktor-Authentifizierung (MFA) für alle Microsoft-Cloud-Konten vor. Windows Hello ist der primäre Bereitstellungsmechanismus für Privat- und Geschäftskunden.
Zero Trust-Architektur	WHfB erfüllt die Anforderung der verifizierten Identität gemäß NIST SP 800-207 Zero Trust, indem die Authentifizierung an ein bestimmtes Gerät und biometrische Benutzerdaten gebunden wird, nicht an gemeinsam genutzte Anmeldeinformationen.
NIS2-Richtlinie (EU)	NIS2 Artikel 21 schreibt die Multi-Faktor-Authentifizierung für die betroffenen Entitäten vor. WHfB erfüllt diese Anforderung für Windows-basierte Umgebungen.

Ausblick: Überlegungen nach der Quantenphysik und die passwortlose Zukunft

Microsofts Kurs ist eindeutig: Im Mai 2025 kündigte das Unternehmen an, dass alle neuen Microsoft-Konten standardmäßig passwortlos sein werden und das Passwort somit nicht mehr als Anmeldeoption bei der Kontoerstellung benötigt wird. Dies beschleunigt einen Übergang, den Windows Hello seit 2015 ermöglicht. Für IT-Teams in Unternehmen stellt sich nicht mehr die Frage, ob Windows Hello for Business eingeführt werden soll, sondern welches Vertrauensmodell, in welchem ​​Umfang und zu welchem ​​Zeitpunkt.

Post-Quanten-Kryptographie und Windows Hello

Die von Windows Hello generierten asymmetrischen Schlüsselpaare basieren derzeit auf elliptischen Kurven oder RSA Beide Algorithmen sind theoretisch anfällig für kryptografisch relevante Quantencomputer. Das NIST finalisierte seine Post-Quanten-Kryptografiestandards am 13. August 2024 (FIPS 203, FIPS 204 und FIPS 205), und Microsoft hat sein Engagement für … bekräftigt. PQC Die Migration innerhalb der Authentifizierungsinfrastruktur ist von großer Bedeutung. Organisationen, die Windows Hello for Business heute einsetzen, sollten die Migrationsrichtlinien des NIST PQC und Microsofts Roadmap für die algorithmische Agilität im WHfB-Schlüsselcontainer im Auge behalten, da dies innerhalb der nächsten fünf bis zehn Jahre ein wichtiger Planungsaspekt sein wird.

Die Programme von Encryption Consulting zur kryptografischen Bestandsaufnahme und Agilität, die auf folgenden Säulen basieren: CBOM Secure, um Organisationen dabei zu helfen, bestehende kryptografische Abhängigkeiten, einschließlich der Authentifizierungsinfrastruktur, zu erfassen, bevor eine Migration erforderlich wird und nicht erst danach.

Passkeys als Konvergenzpunkt

Das FIDO2/Passkey-Ökosystem entwickelt sich hin zu einem einheitlichen Modell, in dem Plattform-Authentifikatoren wie Windows Hello, Apples Passkeys und die FIDO2-Implementierung von Android ein konsistentes, phishing-sicheres Anmeldeerlebnis über alle Betriebssysteme hinweg bieten. Die nun allgemein verfügbare Entra-Passkey-Integration in Windows Hello ist ein Schritt in diese Richtung und ermöglicht es Unternehmen, FIDO2 für ihre heterogenen Geräteflotten zu standardisieren, ohne separate Authentifizierungsmechanismen für jede Plattform verwalten zu müssen.

Wie Verschlüsselungsberatung hilft

Die Bereitstellung von Windows Hello for Business, ob über Cloud Kerberos Trust, Key Trust oder Certificate Trust, hängt von der Integrität der zugrunde liegenden Identitäts- und PKI-Infrastruktur ab. Encryption Consulting bietet Unterstützung. PKI-Dienste Wir bieten umfassende Beratung für Unternehmen, die eine WHfB-Einführung planen oder Probleme beheben müssen: von der Gestaltung der CA-Hierarchie und der Zertifikatvorlagen, die für eine Certificate Trust-Bereitstellung erforderlich sind, über die Modernisierung veralteter Domänencontroller-Vorlagen zur Unterstützung von Key Trust bis hin zur Validierung der Entra Connect- und Entra Kerberos-Konfiguration für Cloud Kerberos Trust.

Für Organisationen, die den operativen Aufwand für PKI vollständig eliminieren möchten, PKI-as-a-Service Bietet eine verwaltete, Cloud-basierte Zertifizierungsstelle, sodass IT-Teams Key Trust- oder Certificate Trust-Implementierungen unterstützen können, ohne die PKI-Infrastruktur direkt vor Ort betreiben zu müssen. Sobald WHfB bereitgestellt ist, CertSecure Manager Bietet IT- und Sicherheitsteams Transparenz und Lebenszyklusautomatisierung für die Zertifikate, auf denen die Modelle Key Trust und Certificate Trust basieren, einschließlich Domänencontroller-Zertifikaten und Benutzeranmeldezertifikaten, wodurch das Risiko verringert wird, dass ein abgelaufenes oder falsch konfiguriertes Zertifikat die Authentifizierung für eine gesamte Website unterbricht.

Häufig gestellte Fragen

Was ist Windows Hello und wie unterscheidet es sich von einem Passwort?

Windows Hello ist Microsofts passwortloses Authentifizierungssystem für Windows 10 und 11. Anstatt ein gemeinsames Geheimnis (ein Passwort) an einen Server zu übertragen, verwendet es ein TPM-basiertes asymmetrisches Schlüsselpaar, bei dem der private Schlüssel das Gerät niemals verlässt. Der Benutzer entsperrt den privaten Schlüssel lokal per Biometrie oder PIN, und das Gerät signiert eine kryptografische Anfrage des Identitätsanbieters. Der Server verifiziert die Signatur mit dem öffentlichen Schlüssel des Benutzers. Es wird niemals ein Passwort übertragen oder serverseitig gespeichert.

Ist Windows Hello sicher genug für Unternehmensumgebungen?

Ja. Windows Hello for Business mit TPM-gesicherten Schlüsseln erfüllt die Anforderungen des NIST SP 800-63B Authenticator Assurance Level 2 (AAL2), dem Standard, der für die meisten Unternehmensanwendungen erforderlich ist. Es wird in den CISA-Richtlinien für Bundesbehörden explizit als phishingresistente MFA-Methode aufgeführt. Für Szenarien mit höheren Sicherheitsanforderungen können die Durchsetzung der TPM-Attestierung und die erweiterte Anmeldesicherheit (ESS) das Sicherheitsniveau weiter erhöhen. Organisationen in regulierten Branchen, darunter Finanzwesen, Gesundheitswesen und Behörden, setzen WHfB als primären Authentifizierungsmechanismus ein.

Worin besteht der Unterschied zwischen Windows Hello für Unternehmen und Windows Hello für Privatkunden?

Windows Hello für Privatnutzer ist für persönliche Microsoft-Konten konfiguriert und unterstützt keine Identitätsanbieter für Unternehmen, Gruppenrichtlinien, Intune-Verwaltung oder den Zugriff auf lokale Ressourcen. Windows Hello for Business (WHfB) ist die Variante für Unternehmen. Es ist in Microsoft Enterprise ID und/oder Active Directory integriert, wird über Intune oder Gruppenrichtlinienobjekte (GPO) verwaltet und ermöglicht Single Sign-On (SSO) für Cloud- und lokale Ressourcen über Cloud-Kerberos-Vertrauensstellung oder Zertifikatsvertrauensstellung.

Benötige ich eine PKI, um Windows Hello for Business bereitzustellen?

Nicht unbedingt. Cloud Kerberos Trust, das von Microsoft empfohlene Standardbereitstellungsmodell, benötigt keine unternehmensweite PKI oder Zertifikatsinfrastruktur für Endbenutzergeräte. Es wird lediglich ein Microsoft Entra Kerberos-Objekt benötigt, das mit einem einzigen PowerShell-Befehl erstellt wird, sowie die Bereitstellung von Intune- oder Gruppenrichtlinien. Certificate Trust, das eine PKI erfordert, ist Umgebungen vorbehalten, die eine gleichwertige zertifikatsbasierte Authentifizierung benötigen, sowie RDP/VDI-Szenarien oder S/MIME-Signierung.

Kann jedes Konto Cloud Kerberos Trust nutzen?

Nein. Konten, die direkt oder indirekt Mitglieder privilegierter, integrierter Sicherheitsgruppen sind, einschließlich Domänenadministratoren, können sich nicht über Cloud Kerberos Trust authentifizieren. Das AzureADKerberos-Objekt unterliegt denselben Einschränkungen der Kennwortreplikationsrichtlinie wie ein standardmäßiger schreibgeschützter Domänencontroller, wodurch privilegierte Konten systembedingt blockiert werden. Microsoft rät dringend davon ab, diese Richtlinie zu lockern, da dies eine Angriffsmöglichkeit zwischen Entra ID und Active Directory schafft. Organisationen, die WHfB für privilegierte Konten benötigen, sollten stattdessen Key Trust oder Certificate Trust verwenden.

Kann ich direkt von einer Zertifikatsvertrauensstellung zu einer Cloud-Kerberos-Vertrauensstellung migrieren?

Nein. Es gibt keinen direkten Migrationspfad von Zertifikatsvertrauensstellung zu Cloud-Kerberos-Vertrauensstellung. Der vorhandene Windows Hello-Container muss gelöscht werden, bevor ein Gerät unter Cloud-Kerberos-Vertrauensstellung neu bereitgestellt werden kann. Die Migration von Schlüsselvertrauensstellung zu Cloud-Kerberos-Vertrauensstellung ist einfacher und kann über Gruppenrichtlinien oder Intune ohne Löschen des Containers durchgeführt werden.

Was passiert, wenn ein Benutzergerät verloren geht oder gestohlen wird?

Da Windows Hello-Anmeldeinformationen gerätegebunden sind, können sie nicht auf einem anderen Gerät verwendet werden. Geht ein Gerät verloren, kann ein Administrator den registrierten öffentlichen Schlüssel umgehend aus der Entra-ID oder dem Active Directory-Konto des Benutzers entfernen und so alle Authentifizierungsversuche von diesem Gerät aus ungültig machen. Die auf dem Gerät gespeicherten biometrischen Daten sind verschlüsselt und können nicht zu einem verwendbaren biometrischen Muster rekonstruiert werden. Ohne den biometrischen Sensor des Geräts sind sie für einen Dieb wertlos.

In welchem ​​Zusammenhang steht Windows Hello mit FIDO2-Passkeys?

Windows Hello ist ein FIDO2-zertifizierter Plattformauthentifikator und implementiert somit die WebAuthn- und CTAP2-Spezifikationen. Jede mit Windows Hello für eine FIDO2-fähige Website oder Anwendung erstellte Anmeldeinformation ist technisch gesehen ein Passkey – eine gerätegebundene FIDO2-Anmeldeinformation. Windows Hello unterstützt außerdem die Registrierung von Entra-ID-Passkeys, die nun allgemein verfügbar ist. Dadurch können Unternehmen Windows Hello als FIDO2-Passkey-Authentifikator für Microsoft-Entra-Konten verwenden, auch auf Geräten, die nicht in Entra eingebunden sind.

Kann Windows Hello für RDP- oder VDI-Sitzungen verwendet werden?

Dies hängt vom Bereitstellungsmodell ab. Cloud Kerberos Trust unterstützt kein RDP mit bereitgestellten Anmeldeinformationen. Certificate Trust unterstützt RDP/VDI durch die Registrierung eines Benutzerzertifikats im WHfB-Container. Alternativ kann Remote Credential Guard RDP-Sitzungen schützen, ohne dass Certificate Trust erforderlich ist. Ab Windows 11 24H2 und Windows Server 2025 kann die FIDO2-Authentifizierung, einschließlich Windows Hello, für RDP über Web Sign-in verwendet werden, sofern sie sowohl auf Client- als auch auf Hostseite aktiviert ist.

Wählen Sie das richtige Authentifizierungsmodell mit Zuversicht

Sie planen die Einführung von Windows Hello for Business oder möchten ein Problem mit einem hybriden Vertrauensmodell lösen? Siehe PKI-Dienste in Aktion oder lesen Sie darüber Windows Hello – Best Practices.