Zero Trust predigt seit Jahren: „Never trust, always verify.“ Identitäten sind der neue Perimeter. Genau deshalb ist Multi‑Faktor‑Authentifizierung (MFA) der wichtigste, schnellste und messbar wirksamste Hebel gegen Account‑Übernahmen – Microsoft beziffert den Schutzgewinn traditionell mit „> 99,9 % weniger kompromittiert“ bei aktivem MFA. Der Weg von „MFA einschalten“ zu „MFA funktioniert robust und reibungslos“ ist jedoch ein ganz eigener Engineering‑Job: Standards (FIDO2/WebAuthn), Microsoft Entra (ehem. Azure AD), Conditional Access (CA), Authentication Methods und Authentication Strengths müssen zusammenpassen.
Folgendes Problem aus der Praxis: Ich besorgte mir vergangene Woche ein neues Android-Smartphone via Backmarket; wie üblich nicht, weil das „alte“ defekt war, sondern um die maximal unterstützte Android-Version auf ein sicherheitstechnisch vertretbares Level (hier 16) zu bringen.
Das Übertragen sämtlicher Apps per Galaxy-Smartswitch (einschließlich MS-Authenticator), sowie das Übertragen der Authenticator-MFA-Konten via MS-Account-Sicherung an sich war kein Problem, allerdings funktionierte nach dem Wechsel MS-Authenticator Push für neu registrierte Konten nicht mehr mit dem neuen Smartphone; die bestehenden Konten waren davon jedoch nicht betroffen, weshalb das Problem nicht unmittelbar zutage trat.
Dass es nicht an Entra ID, Conditional Access, meinem Client-Gerät, am Browser oder Microsoft lag, ließ sich sich schnell verifizieren, da es – also das Registrieren neuer Koten via Authenticator-Push – mit dem alten Device weiter funktioniert.
Die im folgenden präsentierte finale Lösung gibt mir Anlass, vorrangig zur Info für meine Leser und Kursteilnehmer einmal grundsätzlich für Klarheit zum Thema des Zusammenwirkens von Entra-Setup, MFA, Conditional Access, MS-Authenticator und Hardware-Schlüsseln zu sorgen, wie immer kurz knapp und strukturiert, zum Abharken.
Ein Praxisfall mit ge-rootetem Android, geblocktem Authenticator‑Push – und der Weg zur stabilen Passwordless‑Strategie
Also noch Mal in Kürze: neues Android‑Smartphone, Microsoft Authenticator‑Push bricht beim Registrieren ab, TOTP funktioniert; auf dem alten Phone geht Push dagegen sofort – sogar für neu angelegte Konten. Klingt paradox? Ist es nicht.
Die Auflösung führt mitten hinein in CA‑Richtlinien, Registrierungs‑Policies, Passkeys (FIDO2) – und eine neue Root/Jailbreak‑Erkennung der Authenticator‑App (seit 02/2026), die genau solche Fälle auslösen kann,
Kernaussagen, die wir daraus ableiten:
- CA‑Richtlinien sind nicht die Ursache – sie gelten für beide Geräte identisch.
- Das Problem liegt im Client/OS‑Pfad der Registrierung (neues Gerät), nicht in der Nutzung vorhandener Methoden.
- Seit Februar 2026 führt Microsoft im Authenticator eine Root/Jailbreak‑Erkennung für Work/School‑Entra‑Credentials ein. Bei (auch falschem) Root‑Signal ist die Registrierung blockiert – genau dann sieht man generische Fehler und TOTP bleibt als „Fallback“ übrig.
In Kürze hier, was man dann tun kann/könnte:
- Benachrichtigungen & Akku‑Berechtigungen „hart“ setzen,
- Cache/Channel‑Reset (Authenticator + Google Play‑Dienste),
- portalgeführte Registrierung via
mysignins.microsoft.com/security-info - notfalls Clean‑Reinstall ohne Android‑System‑Restore (nur App‑internes Backup)
Da ich allerdings zugunsten von TOTP gerne auf Authenticator-Push verzichten kann (das Sicherheits-Level ist bei beiden in etwas gleich), ist es auch wieder nicht so tragisch, aber beruhigend, die Ursache zu kennen.
Nebenkriegsschauplätze, die häufig verwirren:
- „Warum wird bei neuen Nutzern nur TOTP angeboten?“? Weil in genau diesem Registrierungsflow eine CA‑Strength aktiv ist, die Push nicht zulässt oder weil der Client‑Flow (neues Gerät) scheitert. Dann zeigt die Registrierungs-Seite TOTP als verfügbare Alternative.
- Das Was‑wäre‑wenn‑Tool (What‑If) in Entra/Conditional Acess mit User‑Action „Register security information“ zeigt die greifenden Policies exakt.
- Und „Warum lässt sich die Standardanmeldemethode nicht ändern?“ Solange nur eine zulässige Methode existiert (z. B. TOTP), gibt es nichts, worauf man umstellen könnte. Erst wenn Push oder FIDO2/Passkey erfolgreich registriert ist und durch Strength erlaubt wird, macht ein Wechsel Sinn.
Fundament: Authenticator‑Push, TOTP, FIDO2/Passkeys – wer ist wer?
Vergleichen wir bei der Gelegenheit die verfügbare und „vertretbaren“ (kein SMS oder Voice-Mail) MFA-Methoden:
TOTP (OATH)
- Standard: RFC 6238 (zeitbasierte Einmalcodes) – 6‑stellige Codes.
- Eigenschaften: einfach, offlinefähig, aber phishing‑anfällig (Code kann abgefischt/weitergereicht werden).
- Microsoft‑Kontext: In Entra als „Software‑OATH‑Token“ geführt, in der UI oft verwirrend unter „Microsoft Authenticator – Code“ angezeigt.
Authenticator‑Push / Phone Sign‑In
- Push‑MFA: Microsoft‑proprietäre Challenge (Zahl‑Match, Ort, etc.).
- Phone Sign‑In: kennwortloser Flow mit App‑gebundenem Schlüssel + Push, aber kein FIDO2.
- Stärke: gut, komfortabel – aber ebenfalls nicht so phishing‑resistent wie FIDO2.
FIDO2 & Passkeys
- Standard: FIDO2 = WebAuthn (Browser/API) + CTAP2 (Schlüssel‑Transport).
- Stärke: Phishing‑resistent (origin‑bound Kryptografie, Private Key verlässt Gerät nie).
- Zwei Formen:
- Roaming‑Key (z. B. YubiKey, Thetis) – funktioniert an vielen Geräten.
- Device‑bound Passkey (Windows Hello, Android/iOS Credential Manager) – im TPM/Keystore/Secure Enclave des Geräts gespeichert.
- Microsoft‑Kontext: In Entra heißen beide „Passkeys (FIDO2)“; sie werden als Sicherheitsschlüssel/Passkey in der Security‑Info registriert (NICHT in der Authenticator‑App).
Conditional Access richtig lesen: Authentication Methods, Strengths & User‑Actions
1) Authentication Methods Policy (Tenant‑weit)
Hier legen Sie fest, welche Methoden grundsätzlich erlaubt sind und für welche Zielgruppen (z. B. „Passkeys (FIDO2)“ → Enabled + Self‑Service Setup). Ist eine Methode hier aus, taucht sie in der Security‑Info nicht auf.
2) Authentication Strengths (pro Anmeldung/Aktion)
Die Strength einer CA‑Policy bestimmt, welche Methoden in diesem Moment zulässig sind:
- Multifactor authentication → Push, TOTP, SMS/Voice (nicht automatisch FIDO2).
- Passwordless MFA → Enthält u. a. Microsoft Authenticator passwordless und Passkeys.
- Phishing‑resistant MFA → FIDO2/Passkeys, CBA – kein Push/TOTP.
Merksatz: Die Strength entscheidet, ob eine Methode erscheinen darf – NICHT die Reihenfolge.
3) User Actions – „Register security information“
Die Registrierung selbst ist eine eigene Zielgröße in CA. Viele Unternehmen sichern sie ab (Trusted Location, compliant device, TAP, etc.). Sind Sie hier zu streng (z. B. Phishing‑resistant für die Registrierung, Benutzer hat noch kein FIDO2), dann blockieren Sie die Erstregistrierung. Das What‑If‑Tool zeigt diese Policies, wenn Sie als Target „resource → User actions → Register security information“ simulieren.
Und warum registriert das „alte“ Gerät problemlos neue Konten? Das alte Phone hat eine funktionierende Geräte‑/Push‑Bindung und erfüllt die Strength. Der Client‑Flow ist stabil (kein Root‑Flag, intakter FCM‑Channel). Das neue Phone scheitert nur im Registrierungs‑Flow – welche Methode später nutzen darf, ist eine andere Frage. Genau deshalb nutzt man für Onboarding gern TAP oder eine mildere CA‑Stärke nur für die User‑Action „Register security information“, danach greifen wieder die strengen Policies.
Passwordless unterwegs: Passkeys & FIDO2 „richtig“ einsetzen
- Roaming‑FIDO‑Keys (USB/NFC) sind ideal für Reisen/Admins – ein Key, viele Geräte.
- Device‑bound Passkeys sind ideal für persönliche Geräte (Windows Hello am Managed‑PC, Android‑Passkey am Smartphone).
- Microsoft Authenticator Phone Sign‑In ist komfortabel und schnell, aber kein FIDO2 – als zweite Schicht sinnvoll, nicht als Ersatz.
- Empfohlene Strategie:
– Admins/High‑Risk: Phishing‑resistant (FIDO2/Passkeys oder CBA) via CA‑Strength;
– Standard‑User: Onboarding via TAP → Push/Passkey, danach Migration auf Passkeys.
FIDO2/Passkeys: Die Technik kurz erklärt:
Allgemein ist ein Passkey ein FIDO2/WebAuthn‑basiertes Schlüsselpaar:
- Privater Schlüssel: bleibt immer auf Ihrem Gerät
- Öffentlicher Schlüssel: liegt beim Dienstanbieter (z. B. T‑Online/T‑ID, Microsoft, Google usw.)
Passkeys können gespeichert sein auf …
|
Gerät |
Eignung für Passkeys |
Speicherort |
|
Windows‑PC |
Ja |
TPM |
|
Mac |
Ja |
Secure Enclave |
|
iPhone |
Ja |
Secure Enclave / iCloud |
|
Android |
Ja |
Secure Enclave / StrongBox |
|
Hardwareschlüssel, |
Ja |
Hardware‑Sicherheitschip, z. B. YubiKey |
Im Falle Andoid-Phone verwirrend: Microsoft verwendet den Begriff „Hauptschlüssel“ („Device Key“ oder „Primary Key“) allgemein, um einen plattformgebundenen Passkey zu benennen, der:
- im Gerät selbst gespeichert ist
- nicht in der Authenticator‑App liegt
- nicht im TPM eines anderen Gerätes liegt
- nicht im YubiKey liegt
- sondern im Falle des Smartphones im Secure Enclave / Android Keystore gespeichert ist
Auch solche, an Ihr Android-Smartphone gebundene Schlüssel, sind also technisch betrachtet WebAuthn/Fido2. Bei Android sind Sie Bestandteil des Credential Managers, in iOS Bestandteil der iCloud Keychain. Sie sind zwar auf dem jeweiligen Gerät gespeichert, gehören aber nicht zu dem Authenticator-MFA‑Methoden (Push/TOTP).
Dann stellt sich gleich anschließend die Frage, warum Sie diese Methode beim Registrieren anhand der Bezeichnung „Hauptschlüssel in „Microsoft Authenticator“ auswählen müssen, selbst wenn der Schlüssel gar nicht im Authenticator gespeichert wird?
Die Antwort: Weil Microsoft den Authenticator als „Passkey‑Browser“ verwendet. Android/iOS speichern Passkeys immer im System. Der Authenticator …
- zeigt Ihnen diese Passkeys an
- lässt Sie auswählen, welchen Sie nutzen möchten
- lädt Passkeys NICHT selbst
- registriert Passkeys NICHT selbst
Merken Sie sich einfach: Die Bezeichnung „Hauptschlüssel“ ist nur Microsoft‑Wording.
In der Praxis wird Fido2 leider oft mit Hardwareschlüssel gleich gesetzt, was faktisch nicht korrekt ist. Ein Yubikey ist nur eine der 5 obengenannten Methoden zur Geräte-basierten Schlüsselspeicherung, die Roaming-fähig ist.
In Entra selbst ist „FIDO2-Sicherheitsschlüssel“, eine Methode, die beide Typen unterstützt, also :
- Plattform‑Authentifikatoren
(Windows Hello, Android‑Passkeys, iOS‑Passkeys) - Roaming‑Authentifikatoren
(USB‑/NFC‑Hardwarekeys)
Sie benötigen also faktisch gar keinen Microsoft Authenticator, sobald Sie eine FIDO2‑basierte passwortlose Anmeldung verwenden. Dazu gehören (zur Erinnerung):
A) FIDO2 Passkeys auf einem Gerät (Plattform-Passkey)
- Windows‑PC mit TPM + Windows Hello
- Android‑Phone als FIDO2‑Gerät
- iPhone/iPad mit Passkeys
->Anmeldung läuft direkt über das Gerät, ohne MS-Authenticator
B) Externe FIDO2-Schlüssel (USB/NFC)
- YubiKey
- Feitian
->Anmeldung läuft über den Hardware‑Key → kein Authenticator nötig
- Registrierung: Relying Party (Entra) → Challenge; Authenticator (Key/TPM) → Schlüsselpaar erzeugen; Public Key an Entra, Private Key bleibt lokal (Key/TPM/Keystore).
- Anmeldung: Entra → neue Challenge; Authenticator signiert mit Private Key; Browser sendet Signatur + Credential‑ID; Entra prüft mit Public Key.→ Keine Passwörter, kein Shared Secret, origin‑bound – phishing‑resistent by desig
MS Authenticator als MFA-Methode
Für Nutzer kommt verwirrend hinzu, dass der MS-Authenticator als verfügbare MFA-Methode im Nutzerkontext drei völlig unterschiedliche Methoden zusammenfasst,
|
Funktion im Authenticator |
Technische Kategorie |
Entra‑Methode |
|
1. 6‑stellige Einmalkennwörter |
TOTP (Software‑OATH) |
Microsoft Authenticator |
|
2. Push‑Bestätigung |
App‑Benachrichtigungs‑MFA |
Microsoft Authenticator |
|
3. Kennwortlose Anmeldung (Phone Sign‑In) |
Gerätegebundener App‑Schlüssel + Push |
Microsoft Authenticator |
Die Methoden 2 und 3 sind quasi „Microsoft“-eigene. Lediglich bei 1 TOTP=Time-Oased One‑Time Password = zeitbasierter Einmalcode (bei Microsoft auch Software-OATH-Token genannt) handelt es sich um einen offenen Standard (RFC 6238). Hierfür könnten Sie auf Wunsch auch eine Software nutzen, wie z. B. den Google-Authenticator.
Trotzdem verzweifelt mancher Nutzer an der Fehlersuche. Warum wird die gewünschte Methode für die initiale Registrierung oder bei der Authentifizierung nicht angeboten oder nicht in der gewünschten Reihenfolge oder nicht für diesen oder jenen Nutzer oder funktioniert nicht? Troubleshooting: CA-What-If & Authenticator‑Logs Conditional Access: Drei Regeln, die 95 % aller MFA‑Störungen erklären Praxistaugliches Empfehlung Dies alles lässt sich aber neben dem Verwenden des What-If-Tools am Ende doch recht gut eingrenzen, wenn Sie die am Workflow beteiligten Komponenten kennen: Ebene Beschreibung 1. Methoden aktiviert im Tenant Welche Methoden grundsätzlich erlaubt sind 2. CA‑Strength Welche Methoden bei dieser Anmeldung/Aktion erlaubt sind 3. User‑registrierte Methoden Methoden, die der Benutzer bereits besitzt 4. Default‑Methode des Users Welche Methode zuerst angeboten wird 5. System‑preferred MFA Welche Methode Microsoft „bevorzugt“ 6. User Action Policies (Register Security Info) Welche Methoden bei der Registrierung selbst erlaubt sind
Warum sind MFA-Authentifizierungsprobleme so schwer zu diagnostizieren?
Zum Abschluss noch eine hoffentlich recht nützliche Tabelle, die sämtliche verfügbaren Authentifizierungsmethoden mit Ihrem Stärken, Schwächen, Standards/Verfahren und Use-Cases gegenüberstellt:
Tipp: Lesen Sie zumindest DIESEN Artikel der aufwendigen Tabellendarstellung wegen besser nicht auf ihrem Smartphone:
|
Methode (Benutzerbezeichnung) |
Technisches Verfahren |
Wo liegt der private Schlüssel / das Geheimnis? |
Wo wird eingerichtet? |
Gerätegebunden? |
Sicherheits‑qualität |
Im Microsoft Authenticator sichtbar? |
Typischer Use‑Case |
|
Passkey (plattformgebunden) – z. B. „Hauptschlüssel“ am Android/Windows |
FIDO2/WebAuthn (device‑bound Passkey) |
Im Gerät: Android Keystore/StrongBox, iOS Secure Enclave, Windows TPM (Windows Hello) |
Browser → mysignins.microsoft.com/security-info → Sicherheitsschlüssel/Passkey (Methode muss in Entra Passkeys (FIDO2) aktiviert sein) |
Ja (an das Gerät) |
🔒🔒🔒 (phishing‑resistent, passwordless) |
Ja, als „Hauptschlüssel“ angezeigt, aber nicht in der App gespeichert (der Passkey bleibt im System‑Keystore) |
Passwordless‑Login unterwegs ohne Dongle; QR‑Flow „Anderes Gerät verwenden“ im Browser |
|
FIDO2‑Sicherheitsschlüssel (USB/NFC) – z. B. Y |
FIDO2/WebAuthn (roaming key) |
Im Hardware‑Key (Secure Element des Sticks) |
Browser → mysignins.microsoft.com/security-info → Sicherheitsschlüssel (Passkeys/FIDO2 in Entra enabled + self‑service erforderlich) |
Nein (roaming) – an vielen Geräten nutzbar |
🔒🔒🔒 (phishing‑resistent, passwordless) |
Nein (nur Nutzung als externer Schlüssel, nicht in der App gespeichert) |
Admin-/Travel‑Szenarien, getrennter Zweitfaktor in der Tasche |
|
Phone Sign‑In (kennwortlos mit Authenticator) |
Microsoft‑proprietärer App‑Schlüssel + Push |
Gerätegebundener App‑Schlüssel in der Authenticator‑App (an das Gerät gebunden) |
Authenticator‑App → Kennwortlos aktivieren bzw. Security‑Info → Authenticator (Methode Microsoft Authenticator in Entra aktiv) |
Ja (an dieses Smartphone) |
🔒🔒 (passwordless, aber push‑abhängig; nicht FIDO2) |
Ja (native Hauptfunktion der App) |
Schnelle, komfortable Passwordless‑Anmeldung ohne Hardware‑Key |
|
Microsoft Authenticator (Push‑MFA) |
Push‑Challenge (App‑basierte MFA) |
Kein privater Schlüssel; Challenge‑Zustellung via Push; Freigabe in der App |
Security‑Info → Microsoft Authenticator oder On‑screen‑Enrollment; Methode Microsoft Authenticator muss in Entra Push erlauben |
Ja (App‑Binding ans Gerät) |
🔒🔒 (starke MFA; nicht phishing‑resistent wie FIDO2) |
Ja |
Standard‑MFA für breite Belegschaft |
|
OATH (TOTP) – 6‑stellige Codes |
Software‑OATH (TOTP) nach RFC 6238 |
In der App, als Geheimnis (shared secret) |
Security‑Info → Microsoft Authenticator (OATH) oder externer OTP‑Generator; Methode Software‑OATH in Entra erlaubt |
Ja (an jede App‑Instanz, die den Secret besitzt) |
🔒🔒 (starke MFA; nicht phishing‑resistent) |
Ja – als „Authenticator (Code)“ (auch wenn technisch OATH) |
Fallback/Offline‑MFA, wenn Push nicht möglich ist |
|
OATH‑Hardwaretoken |
OATH‑HOTP/TOTP |
Im Token (Seed im Gerät) |
Adminseitige Hochladung/Zuweisung (Seed‑Import); Methode OATH‑Hardwaretoken muss erlaubt sein |
Nein (roaming) |
🔒🔒 |
Nein |
Produktion/Schichtbetrieb ohne Smartphones |
|
SMS/Telefonanruf |
Einmalcode per Netz/Call |
– |
Security‑Info → Telefon/SMS (wenn als Methode erlaubt) |
Nein |
🔒 (basale MFA; anfällig für SIM‑Swap/Phishing) – nur wo nötig einsetzen |
Nein |
Ausnahmefälle/„Letzter Ausweg“ |
|
CBA (Certificate‑Based Authentication) |
X.509‑Zertifikat |
Auf Smartcard/Device‑Keystore |
PKI‑bereitgestellt; Entra CBA konfigurieren (Policies/AAGUID/Issuer‑Bindungen möglich) |
Ja (an Trägerkarte/Endgerät) |
🔒🔒🔒 (phishing‑resistent) |
Nein |
Behörden, regulierte Branchen, Smartcard‑Infrastrukturen |
|
Windows Hello (for Business) |
FIDO2‑Passkey (plattformgebunden) |
Windows‑TPM |
Windows‑Onboarding / Security‑Info (Passkey); in Entra als Passkeys (FIDO2) gewertet |
Ja (an dieses Windows‑Gerät) |
🔒🔒🔒 (phishing‑resistent) |
Nein (systemeigene Anmeldung) |
Passwordless am Managed‑PC (SSO auf M365/Apps) |
|
Temporary Access Pass (TAP) |
Zeitlich begrenzter Einmal‑„Schlüssel“ (Bootstrap‑Credential) |
– (serverseitig generiert) |
Admin: Entra → TAP erstellen; Nutzer verwendet TAP, um starke Methode (Passkey/FIDO2/Authenticator) zu registrieren |
Nein |
– (kein Dauerfaktor; Bootstrap) |
Nein |
Sichere Erstregistrierung/Wiederherstellung starker Methoden |