Passwörter sind das schwächste Glied in der Authentifizierungskette. MFA fügt zwar einen zweiten Faktor hinzu, es wird aber immer noch ein Passwort übertragen, das theoretisch abgefangen und in anderen Kontexten verwendet werden könnte. Möglicherweise hat es sich noch nicht herumgesprochen, dass die technischen Voraussetzungen für eine vollständig passwortlose Umgebung in Microsoft 365 inzwischen längst reif für den produktiven Einsatz sind.
FIDO2-Sicherheitsschlüssel, Passkeys im Microsoft Authenticator und Windows Hello for Business stellen dazu ein belastbares Fundament zur Verfügung. Eine unfallfreie Einführung erfordert jedoch Planung. Hybride Umgebungen, Fallback-Szenarien und die richtige Reihenfolge bei der Migration entscheiden darüber, ob der Umstieg reibungslos verläuft oder zu Supportaufwand führt.
Was „Passwordless“ in Microsoft 365 bedeutet
Zunächst zur Klärung: Microsoft unterscheidet vier passwortlose Authentifizierungsmethoden, die alle phishing-resistent sind.
- Windows Hello for Business (WHfB) ersetzt das Passwort auf dem Windows-Gerät durch eine PIN oder Biometrie. Das Credential bleibt auf dem Gerät und verlässt es nie. Die Authentifizierung gegen Entra ID erfolgt über einen kryptografischen Schlüssel, der im TPM-Chip des Windows-PCs gespeichert ist.
- FIDO2-Sicherheitsschlüssel (YubiKey, Feitian, Solo Key u. a.) funktionieren geräteunabhängig und sind besonders für Shared-Workstation-Szenarien oder Nutzer ohne eigenes Gerät geeignet. Der Schlüssel enthält das Credential. Die Authentifizierung erfordert den physischen Schlüssel plus PIN oder Biometrie. Ein häufiges Missverständnis. Der FIDO2-Schlüssel muss nicht zwingend ein USB-Stick sein („Roaming-Authenticator“). Auch ein Smartphone eignet sich als Hardware-Schlüssel. Diese Variante heißt auch „Platform-Authenticator“, weil der Schlüssel an das Gerät gebunden ist. Im Gegensatz zu 3. wird das Credential dann z. B bei Android in der so genannten „Secure Enclave“ (StrongBox / TEE) gespeichert und vom so genannten „Android Credential Manager“ verwaltet. Bei Android ist dazu mindestens die Android-Version 16 erforderlich.
- Passkeys im Microsoft Authenticator (seit 2024 GA) speichern das Credential hingegen in der Authenticator-App auf dem Smartphone. Die Anmeldung erfolgt über die App – ohne Passwort und ohne separaten Hardwaretoken.
- Zertifikatsbasierte Authentifizierung (CBA) ist die vierte Option, die vor allem in stark regulierten Umgebungen mit bestehender PKI-Infrastruktur relevant ist und hier nicht im Vordergrund steht.
Die folgende Tabelle betont den Unterschied zwischen 2. und 3., also „MS-Authenticator passwordless“ (Microsoft proprietär) versus „Android-Passkey / Hauptschlüssel (FIDO2)“.
| Feature | Authenticator „Kennwortlos“ (Phone Sign‑in) | Android-Passkey / Hauptschlüssel (FIDO2) |
| Technologie | Microsoft-proprietär | FIDO2 / WebAuthn Standard |
| Speicherort des Schlüssels | In der Authenticator-App | Systemweit im Gerät (TPM/Secure Enclave) |
| Anmeldung | Push-Bestätigung über Authenticator | Biometrie / Gerät entsperren |
| Abhängigkeit von Push | Ja | Nein |
| Plattformunabhängig | Nur Microsoft-Dienste | Alle Dienste, die Passkeys unterstützen |
| Sicherheit | Stark, aber Push-abhängig | Maximale Sicherheit, phishing-resistent |
| Zukunftsfähigkeit | Microsoft schiebt eher weg davon | Zukunftsmodell – Passkeys
|
Technisch betrachtet ist ein Passkey ein FIDO2/WebAuthn‑basiertes Schlüsselpaar, bestehend aus …
- Privater Schlüssel: bleibt immer auf dem Gerät
- Öffentlicher Schlüssel: liegt beim Dienstanbieter (z. B. T‑Online/T‑ID, Microsoft, Google usw.)
Sie melden sich ohne Passwort an, indem das Gerät den privaten Schlüssel mit Ihrer Biometrie/Pin freigibt. Ein Passkey ist demnach weder ein Zahlenschlüssel noch ein ziffernbasiertes Passwort, sondern ein asymmetrischer Kryptoschlüssel, den Sie selbst nie zu Gesicht bekommen. FIDO2 gibt es wie oben bereits erwähnt in zwei Varianten:
- Plattform‑Passkey / Geräteschlüssel – z. B. auf Android (oder Windows Hello)
- Externer FIDO2‑Sicherheitsschlüssel – USB‑Key, NFC‑Key, Bluetooth‑Key
Beides ist technisch FIDO2/WebAuthn und funktioniert für Microsoft‑/Entra‑Konten. Folgende Gerätearten können Passkeys speichern. Die Spalte „Speicherort“ zeigt, „wo“ jeweils der private Schlüssel gespeichert wird.
| Gerät | Speicherort |
| Windows‑PC | TPM |
| Mac | Secure Enclave |
| iPhone | Secure Enclave / iCloud |
| Android | Secure Enclave / StrongBox |
| USB/NFC‑Keys | Hardware‑Sicherheitschip |
Der praktische Unterschied zwischen Smartphone und USB/NFC-Key ist aber durchaus bedeutsam, was die nächste Tabelle zeigt:
| Eigenschaft | Android‑Passkey (Plattform) | USB/NFC‑Schlüssel (Roaming) |
| Schlüssel-Speicherort | Auf dem Gerät | Auf dem physischen Schlüssel |
| Nutzung | Nur auf diesem Gerät | Auf beliebigen Geräten |
| Biometrie | Nutzt System‑Biometrie | Teils Fingerprint (z. B. YubiKey Bio), teils Pin |
| Komfort | Sehr hoch | Hoch (aber Gerät muss physisch gesteckt werden) |
| Sicherheit | Sehr hoch | Sehr hoch |
| Phishing‑resistent | Ja | Ja |
| Ideal für | Phone/PC, Alltagsnutzung | Admins, Hochsicherheit, Multi‑Geräte‑Umgebungen |
Sie könnten natürlich auch den eigenen Desktop PC als Hardware-Schlüssel nutzen. Anbieter wie T-Online bieten diese Methode häufig als MFA-Alternative an. Auch wenn sie hier eine „Pin“ festlegen, handelt es sich technisch gesehen ebenfalls nicht um ein Passwort, sondern um einen auf dem Gerät gespeicherten und an das Gerät gebundenen Passkey, bzw. genau genommen um einen durch ein Geheimnis geschützten privaten Schlüssel, der bei einem Windows-PC im TMP gespeichert wird.
Letztendlich tun alle Verfahren das gleiche; weil jeder Passkeys ein Web‑Standard (FIDO2/WebAuthn) ist, der vom jeweiligen Anbieter (z. B. T‑Online, Microsoft, Google…) unterstützt werden muss.
Beim Windows-PC (Punkt 4 der Aufstellung oben) wird der Passkey im Falle von WHfB allerdings statt im TMP in einem geschützten Bereich im Windows Hello Key Store gespeichert. In diesem Fall melden Sie sich nicht ausschließlich per PIN an, sondern alternativ und falls das Gerät entsprechend ausgestattet ist, auch mit „Windows Hello Gesichtserkennung“ oder Fingerabdruck. Der PC selbst fungiert dann als FIDO2‑Authentifikator und übernimmt den Crypto-Teil.
Voraussetzungen für passwortlose Methoden
Passwortlose Methoden erfordern keine Entra ID P2-Lizenz. Im Gegenteil. Für grundlegende passwortlose Anmeldung (z. B. Microsoft Authenticator Passwordless, FIDO2/Passkeys, Windows Hello) genügt schon „Entra Free“ und damit sind Sie auch schon mit M365 Business Basic oder Standard dabei. Für eine vollständige Rollout-Steuerung via Conditional Access (insbesondere Authentication Strengths) wird allerdings P1 (in Business Premium oder E3 enthalten) benötigt. Folgende Tabelle gibt darüber Auskunft:
| Feature / Szenario | Erforderliche Lizenz | Empfohlen / Vollumfang |
| Grundlegende passwortlose Anmeldung (z. B. Microsoft Authenticator Passwordless, FIDO2/Passkeys, Windows Hello) | Entra ID Free (keine Extra-Lizenz) | — |
| Durchsetzung via Conditional Access (z. B. „Require phishing-resistant MFA“ oder Named Locations) | — | Entra Id P1 (sehr empfohlen) |
| Authentication Strength Policies + Reporting | — | Entra ID P1 |
| Temporary Access Pass (TAP) für Onboarding | — | Entra ID P1 |
| Erweiterte Features (Identity Protection, Risk-basierte Policies) | — | Entra ID P2 |
Cloud Kerberos Trust
Für „Windows Hello for Business in hybriden Umgebungen“ ist der empfohlene Weg seit 2022 hingegen „Cloud Kerberos Trust„: Hierbei wird ein Kerberos-Objekt in Entra ID erstellt, das On-Premises-Ressourcenzugriff über WHfB ohne lokale PKI ermöglicht. Das vereinfacht die Bereitstellung gegenüber dem älteren „Certificate Trust“-Modell erheblich.
Voraussetzungen für Cloud Kerberos Trust:
- Windows 10 21H2 oder neuer (für Cloud Kerberos Trust-Unterstützung)
- Entra ID Connect oder Cloud Sync mit kerberos-fähiger Konfiguration
- Microsoft Entra Kerberos-Objekt im lokalen AD erstellen (per PowerShell)
Für WHfB mit Cloud Kerberos Trust wird ebenfalls Entra P1 benötigt und Entrad ID Connect muss mit aktivierter Cloud Kerberos Trust-Konfiguration betrieben werden. Außerdem benötigen Sie Windows 10/11 Geräte (Entra Joined oder Hybrid Joined).
Im Cloud Kerberos Trust-Modus ist für neue WHfB-Deployments kein On-Prem KDC mehr nötig. Außerdem bietet der Modus bessere Skalierbarkeit und eine einfachere Verwaltung.
Sie werden allerdings vergeblich eine entsprechende Konfigurations-Option für Cloud Kerberos Trust in der GUI von Entra ID Connect suchen. Microsoft hat Cloud Kerberos Trust bewusst als separaten, modernen Schritt außerhalb des normalen Entra Connect Wizards konzipiert. Es wird über das PowerShell-Modul „AzureADHybridAuthenticationManagement“ eingerichtet. Folgendes PS-Skript installiert das Modul und aktiviert den Cloud-Kerberos-Trust:
# PowerShell als Administrator starten
# Modul installieren
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
# Domain und Global Admin angeben
$domain = $env:USERDNSDOMAIN
$userPrincipalName = „dein.globaladmin@deinefirma.de“
# Cloud Kerberos Trust aktivieren
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -SetupCloudTrust
Danach müssen Sie WHfB so konfigurieren, dass es Cloud Kerberos Trust verwendet. Dies gelingt am einfachsten über den Einstellungskatalog in Intune. Suche Sie nach „Windows Hello for Business“ und aktivieren die Einstellung „Use Cloud Trust For On Prem Auth; sowie optional weitere WHfB-Einstellungen (PIN-Länge, Biometrie etc.).
Temporary Access Pass: Schlüssel für die Erstregistrierung
Der häufigste Fehler beim Passwordless-Rollout: Nutzer werden aufgefordert, ihre neue Authentifizierungsmethode zu registrieren, haben selbst aber noch gar keinen zweiten Faktor, mit dem sie sich dabei authentifizieren könnten. Das führt zu Henne-Ei-Problemen, besonders bei Neueinstellungen.
Der Temporary Access Pass (TAP) löst dieses Problem. Ein TAP ist ein zeitlich begrenztes, einmaliges Passwort, das ein Admin für einen Nutzer generiert. Es wird ausschließlich zur Erstregistrierung von passwortlosen Methoden verwendet und danach nicht mehr. Die Gültigkeitsdauer ist konfigurierbar (Standard: 1 Stunde, maximal 8 Stunden oder 30 Tage je nach Typ). Sie können einen TAP als Global Admin oder (besser) als Priviliged Authentication Administrator, bzw. Authentication Administrator wahlweise per PowerShell generieren:
# Microsoft Graph PowerShell
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId „user@contoso.com“ `
-LifetimeInMinutes 60 -IsUsableOnce $true
…. oder im Entra-Portal im Kontext des betreffenden Users unter „seinen“ „Authentifizierungsmethoden “ mit „Athentifizierungsmethode hinzufügen“
Der generierte Code übergeben Sie dem Nutzer dann über einen sicheren Kanal, nicht per E-Mail. Nach der Registrierung des FIDO2-Schlüssels oder Passkeys ist der TAP wertlos.
Migration zu passwordless: Phasenweise vorgehen
Ein Big-Bang-Rollout, also sämtliche Nutzer gleichzeitig auf Passwordless umzustellen ist in produktiven Umgebungen nicht empfehlenswert. Bewährt hat sich ein dreistufiger Ansatz:
Phase 1: Pilotgruppe aktivieren und Methoden registrieren lassen
Erlauben/aktivieren Sie im Entra ID-Portal „Authentifizierungsmethoden / Richtlinien“ FIDO2-Sicherheitsschlüssel und Microsoft Authenticator (Passkey), allerdings zunächst nur für eine Pilotgruppe. Admins gehören als erste in diese Gruppe, nicht als letzte.
Phase 2: Conditional Access mit Authentication Strength
Sobald die Pilotgruppe ihre Methoden registriert hat, wird eine CA-Policy aktiviert, die für diese Gruppe „Phishing-resistant MFA“ als Authentication Strength verlangt. Das erzwingt die Nutzung der passwortlosen Methode und blockiert Fallback auf SMS oder TOTP.
Die „Authentication Strengths” sind in Entra ID unter „Bedingter Zugriff / Authentifizierungsstärken“ vorkonfiguriert. „Phishing-resistant MFA“ umfasst WHfB, FIDO2 und CBA, nicht aber Authenticator-Push oder TOTP.
Phase 3: Breiter Rollout und Passwort-Deaktivierung
Nach erfolgreicher Pilotphase wird die Methoden-Policy auf alle Nutzer ausgeweitet. Die eigentliche Deaktivierung des Passworts („Password is not an authentication method“) ist optional und kann separat konfiguriert werden oder Sie belassen das Passwort als technisches Credential und erzwingt per CA, dass es nicht mehr zur Anmeldung genutzt werden kann.
Fallback-Strategie
Jede passwortlose Strategie braucht eine dokumentierte Fallback-Prozedur für den Fall, dass das primäre Credential nicht verfügbar ist:
- FIDO2-Schlüssel verloren: TAP generieren, neuen Schlüssel registrieren
- Smartphone mit Authenticator-Passkey kaputt: TAP generieren und auf neuem Gerät neu einrichten
- WHfB-Gerät defekt: Nutzer benötigt Zugang über ein alternatives Gerät. Ein TAP plus Browser-basierter Zugang kann hier als Bridge fungieren.
Der TAP-Prozess selbst muss abgesichert sein. Wer einen TAP generieren kann, kann sich potenziell als jeder Nutzer ausgeben. Die Berechtigung zur TAP-Generierung sollte auf eine eng begrenzte Gruppe (Authentication Administrator-Rolle) beschränkt und per PIM abgesichert werden.
Conditional Access als Durchsetzungslayer
Passwortlose Methoden entfalten ihre Sicherheitswirkung vollständig erst, wenn Conditional Access sicherstellt, dass schwächere Methoden (SMS-OTP, TOTP) nicht als Fallback genutzt werden können. Die Authentication Strength in CA-Policies ist dabei präziser als die ältere Einstellung „MFA erforderlich“ – sie definiert nicht nur, dass MFA stattfinden muss, sondern welche Methoden als MFA akzeptiert werden.
Für eine strenge Passwordless-Durchsetzung empfiehlt sich eine CA-Policy mit „Phishing-resistant MFA“ als Bedingung für alle Nutzer und alle Cloud-Apps – mit Ausnahme der Break-Glass-Konten und nach einer dokumentierten Übergangsphase, in der alle Nutzer ihre Methoden registriert haben.
Fazit
Passwordless-Rollouts scheitern selten an der Technologie, häufiger an der Reihenfolge: Erstregistrierung ohne TAP-Prozess, fehlende Pilotphase, kein Fallback-Konzept. Wer diese drei Punkte vor dem Rollout klärt, kann passwortlose Authentifizierung in Microsoft 365 innerhalb weniger Wochen produktiv einführen – auch in hybriden Umgebungen.
Der Einstieg über Windows Hello for Business mit Cloud Kerberos Trust ist für Organisationen mit verwalteten Windows-Geräten der schnellste Weg. FIDO2-Schlüssel ergänzen das Szenario für Nutzer ohne eigenes Gerät. Der Microsoft Authenticator mit Passkey ist die Option mit dem geringsten Hardwareaufwand und inzwischen stabil genug für den produktiven Einsatz.