Windows Hello for Business ersetzt das Passwort bei der Windows-Anmeldung durch einen gerätegebundenen Schlüssel, den der Benutzer per PIN oder Biometrie freigibt. Weil es dabei kein symmetrisches Geheimnis mehr gibt, kann ein Angreifer weder ein Passwort vom Server stehlen noch es dem Benutzer per Phishing-Mail abnehmen (Microsoft: Windows Hello for Business – Übersicht).
Solange sich Deine Mitarbeitenden mit Passwort an Windows anmelden, bleibt die erste Tür zu Deinem Netzwerk ein Geheimnis, das gestohlen oder abgephisht werden kann. Wer für die Endpunkte verantwortlich ist, muss erklären können, warum dieses Risiko noch offen ist, obwohl Windows den Ersatz bereits mitbringt.
Der eigentliche Aufwand liegt dabei nicht im Einschalter. Er liegt in drei Entscheidungen: aus welcher Richtlinienquelle WHfB konfiguriert wird, welches Vertrauensmodell Du für Active Directory brauchst und wie Benutzer an eine vergessene PIN kommen. In diesem Guide zeige ich Dir, wie Du Windows Hello for Business mit Intune einrichtest, pilotierst und sauber ausrollst.
Windows Hello vs. Windows Hello for Business
Windows Hello ersetzt das Passwort an der Windows-Anmeldung durch PIN oder Biometrie. Windows Hello for Business ist die Erweiterung für Organisationen: Sie bringt Unternehmensverwaltung mit, unter anderem Gerätebestätigung, zertifikatbasierte Authentifizierung und Conditional Access, und Du verteilst die Einstellungen als Richtlinie auf die Geräte.
| Windows Hello | Windows Hello for Business | |
|---|---|---|
| Konto | Microsoft-Konto oder FIDO2-fähige Dienste | Entra ID, Active Directory oder FIDO2-fähige Dienste |
| Verfahren | schlüsselbasiert | schlüssel- oder zertifikatbasiert |
| Verwaltung | durch den Benutzer | zentral per Richtlinie, z. B. über Intune, inklusive Gerätebestätigung und Conditional Access |
Windows Hello for Business gilt als Zwei-Faktor-Authentifizierung. Der erste Faktor ist Besitz: der private Schlüssel, den das Sicherheitsmodul des Geräts schützt, idealerweise das Trusted Platform Module (TPM). Der zweite Faktor ist Wissen, also die PIN, oder Biometrie statt der PIN, wobei die PIN immer als Fallback bleibt. Die PIN verlässt das Gerät nicht und ist durch einen eingebauten Brute-Force-Schutz abgesichert.
Biometrische Daten wie Fingerabdruck oder Gesichtserkennung werden nur lokal auf dem Gerät gespeichert, roamen nicht und werden nie an einen Server gesendet. Für Gesichtserkennung brauchst Du IR-Kameras mit Anti-Spoofing. Registriere und nutze die Gesichtserkennung ohne Maske. Mit Maske nimm PIN oder Fingerabdruck, sonst wird die Erkennung unsicherer.
Zur Abgrenzung: Passkeys im Microsoft Authenticator sind ein Benutzer-Credential auf dem Smartphone, Windows Hello for Business ist ein gerätegebundenes Windows-Credential, das Du per Intune-Richtlinie steuerst. Wie Du Passkeys registrierst, steht in meinem Artikel zu Passkeys in Microsoft 365. Wie Du phishing-resistente Methoden per Conditional Access durchsetzt, beschreibe ich im Beitrag zur phishing-resistenten MFA in Microsoft 365.
Voraussetzungen
Bevor Du eine Richtlinie anlegst, prüfe diese Punkte:
Für hybride Umgebungen mit Cloud Kerberos Trust gelten zusätzlich Mindestversionen: Windows 10 21H2 mit KB5010415 oder Windows 11 21H2 mit KB5010414 auf den Clients sowie Domänencontroller ab Windows Server 2016 (KB4534307) oder 2019 (KB4534321), alternativ 2022 oder 2025. Die Benutzer authentifizieren sich gegenüber Entra ID per Kennwort-Hash-Synchronisierung, Passthrough-Authentifizierung oder Föderation. Das sind technische Mindeststände, keine Empfehlung für den Produktivbetrieb. Nutze unterstützte, vollständig gepatchte Windows-Versionen; bei LTSC und ESU hängen Supportlaufzeit und Updateversorgung von der konkreten Version und den jeweiligen Bedingungen ab.
Das richtige Vertrauensmodell wählen
Ein Vertrauensmodell brauchst Du nur, wenn sich Benutzer mit Windows Hello for Business auch gegenüber Active Directory authentifizieren, also an Dateiservern oder anderen On-Premises-Ressourcen. Reine Cloud-Umgebungen benötigen keines. Laut Microsoft ist keines der drei Modelle sicherer als das andere; sie unterscheiden sich in Infrastruktur und Aufwand (Microsoft: Planen einer Bereitstellung).
| Szenario | PKI nötig? | Zusätzlich | Einordnung |
|---|---|---|---|
| Cloud-only (Entra joined, nur Cloud-Ressourcen) | nein | – | kein Vertrauensmodell erforderlich |
| Hybrid mit Cloud Kerberos Trust | nein | Microsoft Entra Kerberos | von Microsoft empfohlen |
| Hybrid mit Key Trust | ja (DC-Zertifikate) | – | Schlüssel-Synchronisation verzögert die Nutzung |
| Hybrid mit Certificate Trust | ja (DC-Zertifikate) | AD FS als Registrierungsstelle, Entra ID P1 | nur bei echten Zertifikatsszenarien |
Microsoft empfiehlt Cloud Kerberos Trust gegenüber Key Trust und bevorzugt es immer dann, wenn Du keine Zertifikatsszenarien brauchst. Es ist die einzige Hybrid-Option ohne PKI und ohne Wartezeit durch die Schlüssel-Synchronisation. Wenn Du keine eigene PKI betreibst, ersparst Du Dir damit den Aufbau von Domänencontroller-Zertifikaten.
Die Grenzen solltest Du vor der Entscheidung kennen. Mit Cloud Kerberos Trust nicht unterstützt sind RDP- und VDI-Sitzungen mit eingegebenen Anmeldedaten (außer mit Remote Credential Guard oder einem Zertifikat im WHfB-Container), „Ausführen als“ sowie die Anmeldung an einem hybrid joined Gerät, auf dem sich der Benutzer noch nie mit Sichtverbindung zu einem Domänencontroller angemeldet hat.
Für die Planung bietet Microsoft im Microsoft 365 Admin Center einen interaktiven Passwordless-Assistenten, der dieselben Entscheidungen abfragt.
Schritt für Schritt in Intune
Die folgenden Schritte beziehen sich auf das Intune Admin Center. Falls Du Intune gerade erst aufbaust, findest Du die Grundlagen in meinem Überblick zu Microsoft Intune.
Mandantenweite Richtlinie prüfen
Unter Devices → Windows → Windows Enrollment → Windows Hello for Business liegt die mandantenweite Richtlinie (tenant-wide policy). Sie wirkt nur zum Zeitpunkt der Registrierung und gilt für alle neu registrierten Geräte. Änderungen an ihr erreichen bereits registrierte Geräte nicht.
Genau deshalb wird diese Richtlinie üblicherweise deaktiviert und Windows Hello for Business stattdessen über eine Richtlinie aktiviert, die Du gezielt Gruppen zuweist. So steuerst Du den Rollout in Ringen und kannst Einstellungen auch für Bestandsgeräte ändern. Microsoft beschreibt die Wege im Artikel Konfigurieren von Windows Hello for Business.
Für die Konfiguration nach der Registrierung stehen Dir in Intune mehrere Quellen zur Verfügung: Settings catalog (Einstellungskatalog), Security baselines, Custom-Profile über den PassportForWork CSP, Account protection (Kontoschutz) und Identity protection. Wähle eine davon als führende Quelle.
Settings-catalog-Richtlinie für die Pilotgruppe
Lege im Settings catalog ein Profil an und wähle die Kategorie Windows Hello for Business. Für Cloud-only-Geräte reicht bei deaktivierter mandantenweiter Richtlinie:
Bei Entra joined Geräten mit Standardeinstellungen versucht Windows die WHfB-Registrierung übrigens automatisch beim Entra Join, ganz ohne Zusatzkonfiguration (Microsoft: Cloud-only-Bereitstellung).
Für hybride Umgebungen mit Cloud Kerberos Trust kommt eine Einstellung hinzu:
Die Einstellung Use certificate for on-premises authentication muss dabei nicht konfiguriert bleiben. Ist sie gesetzt, hat Certificate Trust Vorrang, und Cloud Kerberos Trust greift nicht.
Weise das Profil zunächst einer kleinen Pilotgruppe zu. Wenn Du innerhalb dieser Gruppe nach Gerätemerkmalen eingrenzen willst, helfen Dir Intune-Filter bei Zuweisungen.
Für Hybrid: Microsoft Entra Kerberos bereitstellen
Cloud Kerberos Trust setzt voraus, dass Microsoft Entra Kerberos in Deinem Active Directory bereitgestellt ist. Dabei entsteht das Kerberos-Serverobjekt AzureADKerberos. Hast Du bereits FIDO2-Sicherheitsschlüssel mit Single Sign-on für On-Premises-Ressourcen eingerichtet, existiert dieses Objekt schon. Die Bereitstellung selbst beschreibt Microsoft im Leitfaden zu Cloud Kerberos Trust; diesen Schritt solltest Du nicht improvisieren.
Plane genügend beschreibbare Domänencontroller pro AD-Standort ein. Und kläre früh die privilegierten Konten: Mitglieder privilegierter integrierter Gruppen können Cloud Kerberos Trust standardmäßig nicht nutzen. Die Password Replication Policy dafür zu lockern, empfiehlt Microsoft nicht. Administrative Konten behandelst Du deshalb getrennt, so wie Du auch lokale Admins in Intune gesondert steuerst.
Enrollment Status Page bei neuen Geräten
Wenn Du die mandantenweite Richtlinie deaktiviert hast, aktiviere die Enrollment Status Page (ESP). Sie sorgt dafür, dass die WHfB-Richtlinie auf neuen Geräten ankommt, bevor der Benutzer den Desktop erreicht. Wie die ESP in die Bereitstellung neuer Geräte passt, zeige ich in der Einführung zu Windows Autopilot.
Pilot prüfen, bevor Du breit ausrollst
Der Pilot ist der Punkt, an dem Du Fehler noch billig findest. Geh den Registrierungsablauf aus Benutzersicht durch: optional Biometrie einrichten, bestätigen, MFA durchführen, PIN gemäß Komplexitätsrichtlinie anlegen. Im Hintergrund erzeugt Windows ein asymmetrisches Schlüsselpaar, bevorzugt im TPM, und registriert den öffentlichen Schlüssel beim Identity Provider.
Prüfe danach auf dem Gerät mit dsregcmd /status, ob die Voraussetzungen erfüllt sind. Was die einzelnen Felder bedeuten, erkläre ich ausführlich im Artikel zu dsregcmd. Ergänzend zeigt das Ereignisprotokoll User Device Registration (Admin) das Ergebnis der Cloud-Kerberos-Voraussetzungsprüfung.
Bei hybrid joined Geräten gilt: Die erste Anmeldung mit PIN braucht Sichtverbindung zu einem Domänencontroller. Danach funktioniert die Anmeldung über Cached Sign-in auch ohne. Teste deshalb bewusst den Fall „Gerät im Homeoffice, noch nie im Büro angemeldet“.
Rolle danach in Ringen aus, nicht als Big Bang: IT-Team, eine Fachabteilung, dann der Rest. Jede Stufe startet erst, wenn die vorherige ohne offene Tickets läuft.
Richtlinienkonflikte vermeiden
Konfiguriere Windows Hello for Business entweder per Gruppenrichtlinie (GPO) oder per CSP über Intune, aber nie gemischt. Gemischte Einstellungen führen laut Microsoft zu unerwartetem Verhalten. Die GPO hat Vorrang; kollidierende CSP-Einstellungen greifen erst, wenn die GPO entfernt ist.
Verlass Dich dabei nicht auf MDMWinsOverGP. Diese Einstellung gilt nicht für WHfB, weil der PassportForWork CSP kein Teil des Policy CSP ist. Außerdem hat die Benutzerrichtlinie Vorrang vor der Computerrichtlinie, und bei PIN-Vorgaben aus DeviceLock und PassportForWork gewinnt die strengste.
Achte auch auf Quellen innerhalb von Intune: Security Baselines können ebenfalls WHfB-Einstellungen enthalten. Wenn Du Baselines nutzt, lege fest, welches Profil die WHfB-Einstellungen führt, und halte die anderen davon frei.
Vergessene PIN: Recovery vor dem Rollout klären
An der vergessenen PIN entscheidet sich, ob Dein Rollout im Helpdesk unnötige Arbeit erzeugt. Windows Hello for Business kennt zwei Varianten des PIN-Resets (Microsoft: PIN-Zurücksetzung):
| Destruktiv | Nicht destruktiv | |
|---|---|---|
| Konfiguration | Standard, keine nötig | PIN-Reset-Dienst plus Intune-Einstellung |
| Was passiert | Container, Schlüssel und Zertifikate werden gelöscht und neu bereitgestellt | Container bleibt erhalten |
| Lizenz | keine | keine |
Für den nicht destruktiven Reset muss mindestens ein Application Administrator den Apps Microsoft Pin Reset Service Production und Microsoft Pin Reset Client Production zustimmen. Anschließend setzt Du in Intune Enable Pin Recovery = True, entweder im Settings catalog oder unter Endpoint security → Account protection. Der nicht destruktive PIN-Reset funktioniert nur für Unternehmenskonten, hybrid oder cloud-only.
Ob die Konfiguration auf dem Gerät angekommen ist, siehst Du wieder mit dsregcmd /status: Das Feld CanReset zeigt DestructiveOnly oder DestructiveAndNonDestructive. Einen Sonderfall kennst Du besser vorher: Bei Key Trust auf hybrid joined Geräten funktioniert der destruktive Reset nicht vom Sperrbildschirm aus. Für den destruktiven Reset auf hybrid joined Geräten muss ein Domänencontroller über das Unternehmensnetz erreichbar sein.
Für Benutzer ist der Weg einfach: „Ich habe meine PIN vergessen“ am Sperrbildschirm oder unter Einstellungen → Konten → Anmeldeoptionen. MFA ist dabei erforderlich. Dieser Weg gehört in die Pilot-Kommunikation, nicht erst ins erste Ticket.
Bestehende Key- oder Certificate-Trust-Umgebung umstellen
Läuft Deine Umgebung bereits mit Key Trust oder Certificate Trust, hängt die Umstellung auf Cloud Kerberos Trust vom Ausgangspunkt ab:
Plane die Certificate-Trust-Migration deshalb wie einen kleinen Neu-Rollout, mit Pilotgruppe und Kommunikation.
Typische Fehler aus der Praxis
Diese Punkte solltest Du prüfen, bevor der breite Rollout startet:
Zum letzten Punkt: Wenn Du Windows Hello for Business bewusst noch nicht nutzen willst, deaktivierst Du es über die mandantenweite Richtlinie, eine Intune-Richtlinie zusammen mit der ESP, ein Bereitstellungspaket oder ein Skript.
Häufige Fragen zu Windows Hello for Business
Was ist der Unterschied zwischen Windows Hello und Windows Hello for Business?
Windows Hello ersetzt das Passwort an der Windows-Anmeldung durch PIN oder Biometrie. Windows Hello for Business erweitert das für Organisationen um zentrale Verwaltung per Richtlinie, zertifikatbasierte Authentifizierung, Gerätebestätigung und Conditional Access. Benutzer melden sich damit an Entra ID, Active Directory oder FIDO2-fähigen Diensten an.
Welche Voraussetzungen braucht Windows Hello for Business?
Du brauchst Windows Pro, Enterprise, Pro Education/SE oder Education, in Entra ID registrierte Geräte (für den Intune-Rollout typischerweise Entra joined oder hybrid joined) und erfolgreiche MFA bei der Registrierung. WHfB selbst benötigt keine Entra ID P1 oder P2; Abhängigkeiten wie automatische MDM-Registrierung und Conditional Access schon.
Braucht Windows Hello for Business eine PKI?
Nicht zwingend. Cloud-only-Umgebungen und hybride Umgebungen mit Cloud Kerberos Trust kommen ohne PKI aus. Nur Key Trust und Certificate Trust benötigen eine PKI mit Domänencontroller-Zertifikaten.
Was passiert, wenn ein Benutzer seine PIN vergisst?
Der Benutzer wählt „Ich habe meine PIN vergessen“ und bestätigt sich per MFA. Standardmäßig läuft ein destruktiver Reset, der den WHfB-Container neu bereitstellt. Mit eingerichtetem PIN-Reset-Dienst und „Enable Pin Recovery“ bleibt der Container erhalten.
Ist Windows Hello for Business eine MFA?
Ja. Windows Hello for Business gilt als Zwei-Faktor-Authentifizierung: Besitz des privaten Schlüssels auf dem Gerät plus Wissen (PIN) oder Biometrie.
Windows Hello for Business sauber pilotieren und ausrollen
Ich bin Aaron Siller, Microsoft MVP für Security und Gründer von siller.consulting. Wenn ein WHfB-Rollout hakt, prüfe zuerst die drei Entscheidungen aus diesem Guide: Richtlinienquelle, Vertrauensmodell und PIN-Recovery.
Wenn Du Windows Hello for Business strukturiert pilotieren, das passende Vertrauensmodell festlegen und den Rollout so aufsetzen willst, dass Dein Team ihn selbst weiterführen kann, unterstütze ich Dich dabei im Rahmen meiner Microsoft Intune Beratung.
Du willst erst wissen, wo Dein Tenant insgesamt steht? Dann starte mit dem Microsoft 365 Hardening Check.
