Microsoft Entra ID (ehemals Azure AD) bietet eine ganze Palette an Authentifizierungsmethoden – von klassischen Passwörtern über Multi-Faktor-Authentifizierung (MFA) bis hin zu modernen passwortlosen Verfahren. Aber hier wird’s interessant: Welche Abhängigkeiten bestehen eigentlich zwischen diesen Methoden?
In dieser zweiteiligen Serie schauen wir uns die wichtigsten Authentifizierungsmethoden in Microsoft Entra ID an – ihre Voraussetzungen und vor allem die kritischen Abhängigkeiten. Part 1 legt die Grundlagen: Wir klären, welche Methoden es gibt, wofür sie verwendet werden können (primäre Anmeldung, MFA, SSPR), und warum selbst bei einer vollständig passwortlosen Strategie bestimmte „Fallback-Methoden“ unverzichtbar bleiben.
Überblick: Welche Authentifizierungsmethoden gibt es?
Microsoft Entra ID unterstützt mittlerweile eine beachtliche Anzahl an Authentifizierungsmethoden. Die folgende Tabelle zeigt die wichtigsten und ihre Einsatzmöglichkeiten:
| Methode | Primäre Anmeldung | Zweiter Faktor (MFA) | Für SSPR nutzbar? |
|---|---|---|---|
| Passwort | Ja | – | – (Ziel von SSPR) |
| Telefonanruf | Nein | Ja | Ja |
| SMS-Code | Ja (SMS-Login möglich) | Ja | Ja |
| E-Mail OTP | Nein | Nein | Ja (für SSPR/Gast) |
| Authenticator-App (Push/Code) | Ja (Push als Teil der Anmeldung) | Ja | Ja |
| Authenticator-App (passwortlos) | Ja (Telefonanmeldung) | Nein | – |
| Hardware/Software OATH-Token | Nein | Ja | Ja |
| QR Code | Ja (nur Frontline Worker) | Nein | Nein |
| Windows Hello for Business | Ja | Ja (zählt als MFA) | Nein |
| FIDO2-Sicherheitsschlüssel | Ja | Ja (zählt als MFA) | Nein |
| Zertifikat-basierte Auth. | Ja | Ja | Eingeschränkt |
| Temporary Access Pass (TAP) | Ja (temporär) | Ja (zweckgebunden) | Nein |
Legende:
- Primäre Anmeldung: Methode kann anstelle eines Passworts zum Einloggen verwendet werden
- Zweiter Faktor (MFA): Methode kann zusätzlich zum Passwort eingesetzt werden
- SSPR: Methode kann zur Self-Service Password Reset genutzt werden
Schon in dieser Übersicht zeigt sich die erste wichtige Erkenntnis: Nicht jede Methode kann für alle Zwecke verwendet werden. Besonders auffällig: Die modernsten und sichersten Methoden (Windows Hello, FIDO2, Authenticator passwortlos) sind nicht für SSPR verwendbar. Das hat weitreichende Konsequenzen für deine Planung – dazu später mehr.
Kurzer Hinweis zu QR Code: Die QR Code Authentifizierung ist eine spezialisierte Methode für Frontline Worker (z.B. im Einzelhandel oder der Produktion) auf gemeinsam genutzten mobilen Geräten. Ein QR Code wird mit einer PIN kombiniert und dient als Single-Factor Authentifizierung. Diese Methode funktioniert nur auf iOS/Android-Geräten und sollte nur für spezifische Benutzergruppen aktiviert werden, nicht organisationsweit. Sie ist nicht für MFA oder SSPR geeignet und sollte durch Conditional Access Policies zusätzlich abgesichert werden.
Die drei Kategorien: Primäre Anmeldung, MFA und SSPR
Um die Abhängigkeiten zu verstehen, müssen wir zunächst die drei Einsatzbereiche auseinanderhalten:
Primäre Anmeldung (First Factor)
Die primäre Anmeldung ist das, womit sich ein Benutzer zuerst identifiziert. Klassisch ist das das Passwort, aber moderne Methoden wie Windows Hello, FIDO2 oder Authenticator (passwortlos) können das Passwort komplett ersetzen.
Wichtig zu wissen: Passwortlose Methoden wie FIDO2 oder Windows Hello erfüllen bereits von sich aus MFA-Anforderungen, weil sie zwei Faktoren kombinieren:
- Etwas, das man hat: Das Gerät, der Sicherheitsschlüssel
- Etwas, das man weiß oder ist: PIN oder Biometrie (Fingerabdruck, Gesichtserkennung)
Sicherheitshinweis zu Windows Hello for Business: Obwohl sowohl PIN als auch Biometrie unterstützt werden, solltest du im Produktivbetrieb Biometrie (Fingerabdruck oder Gesichtserkennung) bevorzugen. Die PIN ist anfällig für Shoulder Surfing – ein Kollege oder Angreifer könnte die PIN-Eingabe beobachten und bei Zugriff auf das Gerät (z.B. unbeaufsichtigter Arbeitsplatz) diese nutzen. Biometrische Merkmale kann man nicht einfach ausspähen. Die PIN sollte nur als Fallback dienen, wenn biometrische Hardware nicht verfügbar ist.
Multi-Faktor-Authentifizierung (MFA)
MFA bedeutet: Zusätzlich zur primären Anmeldung (meist Passwort) ist ein zweiter Faktor erforderlich. Das kennst du wahrscheinlich zur Genüge:
- SMS-Code oder Telefonanruf
- Authenticator-App (Push-Benachrichtigung oder OTP-Code)
- Hardware OATH-Token
Microsoft unterscheidet dabei zwischen:
- Klassische MFA: SMS, Anruf, OTP – diese Methoden sind anfällig für Phishing-Angriffe
- Phishing-resistente MFA: Windows Hello, FIDO2, Zertifikate – diese Methoden können nicht per Remote-Phishing abgefangen werden
Microsoft empfiehlt eindeutig phishing-resistente Methoden, besonders für Admins und den Zugriff auf sensible Ressourcen. Und das aus gutem Grund – die Angriffe werden immer raffinierter.
Self-Service Password Reset (SSPR)
SSPR ermöglicht es Benutzern, ihr vergessenes Passwort selbst zurückzusetzen, ohne den Helpdesk anzurufen. Dafür muss sich der Benutzer mit registrierten Methoden verifizieren.
Und hier kommt der Haken: Nicht alle Authentifizierungsmethoden können für SSPR verwendet werden. Besonders die modernsten passwortlosen Methoden (Windows Hello, FIDO2, Authenticator passwortlos) sind nicht für SSPR verfügbar. Das ist eine der kritischsten Einschränkungen im Entra ID Authentifizierungssystem und führt oft zu Verwirrung bei der Planung.
SSPR im Detail: Welche Methoden funktionieren?
Microsoft dokumentiert in den offiziellen Learn-Artikeln nicht explizit, warum bestimmte Methoden nicht für SSPR unterstützt werden. Die Dokumentation listet lediglich auf, welche Methoden zugelassen sind. Hier die Übersicht:
Für SSPR zugelassen:
- ✅ Microsoft Authenticator (Push-Benachrichtigungen oder Code)
- ✅ Hardware/Software OATH-Token
- ✅ SMS-Code
- ✅ Sprachanruf
- ✅ E-Mail OTP
Nicht für SSPR zugelassen:
- ❌ Windows Hello for Business
- ❌ FIDO2-Sicherheitsschlüssel
- ❌ Authenticator (passwortlos/Passkey)
- ❌ QR Code
Sicherheitsbedenken bei E-Mail als SSPR-Methode
E-Mail als SSPR-Methode ist technisch möglich, aber es gibt wichtige Punkte zu beachten:
Warum geschäftliche E-Mail-Adressen nicht funktionieren: Geschäftliche E-Mail-Adressen (z.B. benutzer@firma.de) sind selbst über Entra ID geschützt. Wenn ein Benutzer sein Entra ID Passwort vergessen hat, kann er auch nicht auf seine geschäftliche E-Mail zugreifen – ein klassischer Zirkelschluss. Deshalb kommen für SSPR nur private E-Mail-Adressen in Frage (Gmail, Outlook.com, Yahoo, etc.).
Das Problem mit privaten E-Mail-Adressen: Private E-Mail-Adressen liegen außerhalb deiner Kontrolle.
- Schwächere Sicherheit: Private E-Mail-Accounts haben oft schwächere Passwörter und keine MFA aktiviert
- Keine Kontrolle: Du hast keine Möglichkeit, Sicherheitsrichtlinien durchzusetzen
- Account-Übernahme-Risiko: Private Mailaccounts sind ein beliebtes Angriffsziel und oft leichter zu kompromittieren
- Kein Monitoring: Du kannst nicht erkennen, wenn der private Account übernommen wurde
Worst-Case-Szenario: Ein Angreifer übernimmt den privaten Gmail-Account eines Benutzers. Wenn E-Mail die einzige SSPR-Methode ist, kann er das Entra ID Passwort zurücksetzen und sich Zugriff auf alle Unternehmensressourcen verschaffen. Nicht gut.
Meine Empfehlung basierend auf SSPR-Konfiguration:
- Bei zwei erforderlichen SSPR-Methoden: E-Mail kann aktiviert bleiben. Ein kompromittierter E-Mail-Account alleine reicht nicht aus – der Angreifer benötigt zusätzlich Zugriff auf die zweite Methode (z.B. Telefon oder Authenticator-App). Die Kombination aus Telefonnummer + E-Mail oder Authenticator + E-Mail ist akzeptabel.
- Bei nur einer erforderlichen SSPR-Methode: E-Mail sollte aus Sicherheitsgründen deaktiviert werden. Das Risiko ist zu hoch. Besser: Telefonnummer oder Authenticator-App als einzige Methode.
Kritische Abhängigkeiten zwischen Authentifizierungsmethoden
Jetzt kommen wir zum Kern der Sache. Die folgenden drei Abhängigkeiten sind entscheidend dafür, dass deine Authentifizierungsstrategie auch in der Praxis funktioniert:
Abhängigkeit #1: Passwortlose Methoden benötigen Fallback für SSPR
Stell dir folgendes Szenario vor:
- Ein Unternehmen führt Windows Hello for Business ein
- Benutzer melden sich fortan nur noch mit PIN oder Fingerabdruck an
- Das AD-Passwort wird nicht mehr im Alltag verwendet
Problem: Was passiert, wenn der Benutzer das (nicht mehr genutzte) Passwort vergisst oder aus irgendeinem Grund zurücksetzen muss?
Da Windows Hello nicht für SSPR verwendet werden kann, benötigt der Benutzer eine alternative Methode zur Verifikation. Ohne registrierte SSPR-Methode (z.B. Telefonnummer oder E-Mail) gibt’s nur einen Weg: Anruf beim Helpdesk. Und das nervt beide Seiten.
Deshalb die goldene Regel:
Selbst bei vollständig passwortloser Strategie muss jeder Benutzer mindestens eine SSPR-fähige Methode registriert haben – typischerweise eine Telefonnummer oder alternative E-Mail-Adresse.
Microsoft empfiehlt standardmäßig, dass Benutzer mindestens zwei Methoden für SSPR registrieren. Das erhöht die Ausfallsicherheit – wenn das Telefon mal verloren geht, gibt’s immer noch eine Alternative.
Abhängigkeit #2: Windows Hello und FIDO2 benötigen initiale MFA
Die zweite wichtige Abhängigkeit betrifft das Onboarding von passwortlosen Methoden:
Windows Hello for Business und FIDO2-Schlüssel können nicht „einfach so“ eingerichtet werden. Zur Registrierung dieser Methoden verlangt Microsoft eine vorherige MFA-Überprüfung.
Warum ist das so?
Sicherheit. Wenn jemand einfach einen FIDO2-Schlüssel zu einem Account hinzufügen könnte, ohne sich stark zu authentifizieren, könnte ein Angreifer einen Schlüssel zum gehackten Account hinzufügen und hätte dauerhaften Zugang. Das will man vermeiden.
Der typische Ablauf beim Einrichten von Windows Hello:
- Benutzer meldet sich mit Passwort an seinem Gerät an
- Windows fordert zur Einrichtung von Hello auf
- Azure AD verlangt eine MFA-Überprüfung (z.B. Push an Authenticator-App oder SMS-Code)
- Nach erfolgreicher MFA wird das Hello-Schlüsselpaar erstellt und im TPM gespeichert
- Ab jetzt kann sich der Benutzer mit Hello anmelden
Dasselbe gilt für FIDO2-Schlüssel:
- Benutzer meldet sich im Portal „Meine Sicherheitsinformationen“ an
- Wählt „Sicherheitsschlüssel hinzufügen“
- Azure AD verlangt MFA-Überprüfung
- Nach erfolgreicher MFA kann der Schlüssel registriert werden
Die Abhängigkeit:
Vor der Einführung von Windows Hello oder FIDO2 muss sichergestellt sein, dass Benutzer bereits eine MFA-Methode registriert haben (z.B. Authenticator-App oder SMS).
Für neue Benutzer, die noch keine MFA-Methode haben, gibt es zwei Lösungen:
- Combined Security Info Registration: Beim ersten Login werden Benutzer aufgefordert, MFA-Methoden zu registrieren
- Temporary Access Pass (TAP): Ein Administrator erstellt einen zeitlich begrenzten Einmalcode, mit dem der Benutzer sich anmelden und direkt passwortlose Methoden einrichten kann (dazu später mehr in Part 2)
Abhängigkeit #3: Authenticator-App alleine reicht oft nicht aus
Die Microsoft Authenticator App ist vielseitig: Sie kann für MFA (Push/Code) und für SSPR verwendet werden. Klingt nach einer Komplettlösung, oder? Nicht ganz.
Warum Authenticator alleine problematisch sein kann
Szenario 1: Geräteverlust
Ein Benutzer hat nur die Authenticator-App registriert, keine andere Methode. Das Smartphone geht verloren oder wird zurückgesetzt.
- Der Benutzer kann sich nicht mehr anmelden (keine MFA)
- Der Benutzer kann auch kein Passwort zurücksetzen (keine SSPR-Methode)
- Ergebnis: Helpdesk muss ran
Szenario 2: SSPR-Policy mit zwei Methoden
Microsoft empfiehlt (und viele Unternehmen konfigurieren das so), dass SSPR mindestens zwei verschiedene Methoden erfordert. Die Authenticator-App zählt dabei als eine Methode, egal ob Push oder Code verwendet wird.
Das bedeutet: Auch wenn die Authenticator-App technisch für SSPR funktioniert, benötigt der Benutzer eine zweite Methode – typischerweise Telefon oder E-Mail.
Mobilnummer als Abhängigkeit für Authenticator
Es gibt noch eine weitere Abhängigkeit: Für bestimmte Features der Authenticator-App (z.B. passwortlose Telefonanmeldung) kann Microsoft verlangen, dass eine Telefonnummer hinterlegt ist, um die Identität des Benutzers zusätzlich zu verifizieren.
Best Practice:
Auch wenn die Authenticator-App die Hauptmethode ist, sollten Benutzer mindestens eine alternative Methode registriert haben – idealerweise Telefonnummer oder E-Mail als Fallback.
Abhängigkeitsdiagramm: Was braucht was?
Hier nochmal die wichtigsten Abhängigkeiten auf einen Blick:
| Methode | Benötigt zur Einrichtung | SSPR-Fallback erforderlich? |
|---|---|---|
| Passwort | – | Nein (ist Ziel von SSPR) |
| SMS / Anruf | Authentifizierter Zugriff (z.B. mit Passwort) | Empfohlen (zweite Methode) |
| Authenticator-App | Authentifizierter Zugriff + QR-Code scannen | Empfohlen (Telefon/E-Mail als Backup) |
| QR Code | Admin-Erstellung, nur für Frontline Worker | Ja (QR Code nicht für SSPR) |
| Windows Hello | Vorhandene MFA-Methode zur Verifizierung | Ja, zwingend (Hello nicht für SSPR) |
| FIDO2 | Vorhandene MFA-Methode zur Verifizierung | Ja, zwingend (FIDO nicht für SSPR) |
| Authenticator (passwortlos) | Vorhandene MFA-Methode zur Einrichtung | Ja, zwingend (nicht für SSPR) |
| Temporary Access Pass | Admin-Erstellung | Nach Ablauf andere Methode nötig |
Phishing-Resistenz: Die wichtige Unterscheidung
Microsoft kategorisiert Authentifizierungsmethoden nach ihrer Widerstandsfähigkeit gegen Phishing-Angriffe. Das ist nicht nur Marketing – die Unterschiede sind in der Praxis erheblich:
Phishing-anfällige Methoden
- Passwort: Kann auf gefälschten Login-Seiten abgefangen werden
- SMS / Anruf: Code kann vom Benutzer auf Phishing-Seite eingegeben werden
- Authenticator Push: Trotz Number Matching kann ein überzeugender Angriff Benutzer zur Bestätigung verleiten
- OTP-Codes: Können in Echtzeit auf gefälschter Seite abgefangen und verwendet werden
Phishing-resistente Methoden
- Windows Hello for Business: Privater Schlüssel verlässt nie das TPM, kein übertragbares Geheimnis
- FIDO2-Sicherheitsschlüssel: Der Schlüssel ist an die echte Domain gebunden (z.B. login.microsoft.com). Selbst wenn ein Angreifer eine täuschend echte Phishing-Seite erstellt (z.B. login-micros0ft.com mit einer Null statt O), wird der FIDO2-Schlüssel keine Anmeldung durchführen, da die Domain nicht übereinstimmt. Der Benutzer kann sich nur auf der echten Website anmelden.
- Authenticator (passwortlos / Passkey): Gerätgebundener Schlüssel mit Kryptographie
- Zertifikat-basierte Authentifizierung: Asymmetrische Kryptographie, Smartcard
Microsoft sagt es ziemlich klar:
„Microsoft recommends using phishing-resistant authentication methods such as Windows Hello for Business, passkeys (FIDO2) and FIDO2 security keys, or certificate-based authentication (CBA) because they provide the most secure sign-in experience.“
Microsoft Learn: Authentication Methods Overview
Für die Planung bedeutet das: Für hochprivilegierte Accounts (Administratoren) und den Zugriff auf sensitive Ressourcen solltest du ausschließlich phishing-resistente Methoden zulassen. Für normale Benutzer bietet bereits die Kombination Passwort + MFA deutlich mehr Sicherheit als ein reines Passwort, aber mittelfristig sind passwortlose Verfahren sowohl sicherer als auch benutzerfreundlicher.
System Preferred MFA: Automatische Auswahl der sichersten Methode
Mit System Preferred MFA bietet Microsoft die Möglichkeit, automatisch die sicherste verfügbare Authentifizierungsmethode aus den registrierten Methoden eines Benutzers auszuwählen.
Statt dass der Benutzer bei jeder MFA-Aufforderung zwischen SMS, Authenticator-Push oder anderen Methoden wählen muss, entscheidet das System basierend auf einer Microsoft-definierten Sicherheitshierarchie.
Der Vorteil: Benutzer verwenden automatisch die sicherste Methode, ohne sich Gedanken machen zu müssen. Das vereinfacht den Rollout moderner Methoden erheblich – du kannst neue Methoden ausrollen, ohne dass Benutzer manuell umstellen müssen.
Hinweis: Die Konfiguration und praktische Implementierung von System Preferred MFA behandeln wir in Part 2 dieser Serie.
Hybrid-Umgebungen: Zusätzliche Überlegungen
In Hybrid-Umgebungen (lokales Active Directory synchronisiert mit Entra ID) kommen weitere Abhängigkeiten hinzu:
Windows Hello for Business in Hybrid
Windows Hello for Business funktioniert auch in Hybrid-Umgebungen (lokales Active Directory + Entra ID). Die Einrichtung ist allerdings komplexer und erfordert spezifische Voraussetzungen.
Wichtig für diesen Artikel: In Hybrid-Szenarien gelten dieselben Abhängigkeiten wie in reinen Cloud-Umgebungen:
- Benutzer benötigen eine vorhandene MFA-Methode zur Einrichtung von Hello
- Benutzer benötigen eine SSPR-fähige Methode (Telefon/E-Mail) als Fallback
- TPM 2.0 auf Client-Geräten wird dringend empfohlen
Hinweis: Eine detaillierte Anleitung zu Windows Hello for Business mit Cloud Kerberos Trust für Hybrid-Umgebungen findest du in meiner separaten Artikelserie: Windows Hello for Business SSO mit Cloud Kerberos Trust
FIDO2 für Windows-Login in Hybrid
FIDO2-Schlüssel können auch für den Windows-Login auf Hybrid-Joined Geräten verwendet werden, benötigen aber zusätzliche Konfiguration:
- Azure AD Hybrid Authentication Management PowerShell-Modul
- Domain Controller mit aktuellen Patches
- Intune Policy oder GPO zur Aktivierung des FIDO2-Logins
- Konfiguration für Kerberos-Ticket-Ausstellung über Azure AD
Ohne diese Konfiguration kann sich der Benutzer zwar mit dem FIDO2-Schlüssel an Azure AD anmelden, erhält aber keine Kerberos-Tickets für On-Premises Ressourcen (Fileshares, interne Webseiten etc.). Das führt dann zu Verwirrung beim Benutzer – „Ich bin doch angemeldet, warum kann ich nicht auf das Laufwerk zugreifen?“
Minimalsets: Was braucht ein Benutzer mindestens?
Basierend auf den Abhängigkeiten können wir Minimalsets definieren. Diese sind wichtig für die Planung, aber in Part 2 gehen wir noch viel detaillierter darauf ein:
Minimalset für klassische MFA
- Passwort (primäre Anmeldung)
- Authenticator-App oder SMS/Anruf (zweiter Faktor)
- Zweite SSPR-Methode (z.B. Telefon, wenn Authenticator die erste ist)
Minimalset für passwortlose Strategie (Windows Hello)
- Passwort (technisch vorhanden, aber nicht mehr im Alltag genutzt)
- Authenticator-App oder SMS (für initiales Hello-Setup und als MFA-Fallback)
- Windows Hello for Business (primäre Anmeldemethode)
- Telefonnummer oder E-Mail (für SSPR, da Hello nicht dafür nutzbar)
Empfohlenes Set für maximale Flexibilität
- Windows Hello (primär am eigenen Gerät)
- FIDO2-Sicherheitsschlüssel (Backup, für fremde Geräte)
- Authenticator-App (für mobile Anmeldungen, als Fallback)
- Telefonnummer (für SSPR und Notfälle)
- Passwort (vorhanden, aber nur für Legacy-Szenarien)
Diese Kombination deckt die meisten Szenarien ab und bietet mehrere Fallback-Optionen bei Geräteverlust oder technischen Problemen. Mehr dazu in Part 2.
Häufige Missverständnisse und Stolpersteine
„Passwortlos bedeutet, das Passwort wird gelöscht“
Realität: Das Passwort existiert weiterhin im Active Directory / Entra ID, wird aber nicht mehr aktiv verwendet. Es dient als Fallback für Systeme, die moderne Authentifizierung noch nicht unterstützen. Und davon gibt’s mehr, als man denkt.
„Mit FIDO2 brauche ich keine andere Methode“
Realität: Du benötigst mindestens eine SSPR-fähige Methode (Telefon/E-Mail), da FIDO2 nicht für Self-Service Password Reset verwendet werden kann. Außerdem brauchst du eine MFA-Methode, um den FIDO2-Schlüssel überhaupt erst registrieren zu können. Das ist ein Henne-Ei-Problem, das viele erst beim Rollout bemerken.
„SMS ist genauso sicher wie Authenticator“
Realität: SMS ist anfälliger für SIM-Swapping-Angriffe und Phishing. Die Authenticator-App ist deutlich sicherer, besonders mit Number Matching. Für hochsensible Bereiche sollten nur phishing-resistente Methoden (FIDO2, Hello) zugelassen werden. SMS ist besser als nichts, aber definitiv nicht die erste Wahl.
Stolperstein: Legacy-Authentifizierung
Selbst wenn du modernste MFA-Methoden einführst, können veraltete Protokolle (IMAP, POP3, SMTP Basic Auth) diese komplett umgehen. Solche Legacy-Authentifizierungen senden oft nur Benutzername + Passwort und ignorieren MFA komplett.
Die Lösung: Legacy-Authentifizierung muss via Conditional Access oder Security Defaults blockiert werden, sonst bleibt ein riesiges Sicherheitsloch bestehen. Das wird oft vergessen und ist dann die Hintertür für Angreifer.
Zusammenfassung und Ausblick
Die wichtigsten Erkenntnisse aus Part 1 auf einen Blick:
- Nicht alle Methoden können für alle Zwecke verwendet werden – besonders die Einschränkung bei SSPR ist kritisch und muss bei der Planung berücksichtigt werden
- Passwortlose Methoden haben Abhängigkeiten zu klassischen Methoden – sowohl beim Onboarding (MFA erforderlich) als auch als Fallback (SSPR)
- Selbst bei passwortloser Strategie braucht jeder Benutzer eine SSPR-fähige Methode (Telefon oder E-Mail) – das ist keine optionale Empfehlung, sondern Pflicht
- Phishing-resistente Methoden sollten der Standard sein, besonders für Administratoren und sensitive Bereiche – die Angriffe werden nicht einfacher
- Minimalsets sind wichtig, aber mehr Redundanz erhöht die Ausfallsicherheit und reduziert Helpdesk-Anfragen
Wie geht es weiter?
In Part 2 dieser Serie wird’s praktisch: Wir schauen uns detailliert an, welche Kombinationen von Authentifizierungsmethoden für verschiedene Szenarien empfohlen werden (Admins, Office-Mitarbeiter, Remote-Worker, Frontline Worker etc.). Außerdem behandeln wir Best Practices für den Rollout, häufige Fehler aus der Praxis und geben dir konkrete Empfehlungen, wie du die Minimalsets in deiner Umgebung umsetzt.
Referenzen
- Microsoft Entra Authentication Overview – Microsoft Learn
- Passkeys (FIDO2) authentication method in Microsoft Entra ID – Microsoft Learn
- Get started with a phishing-resistant passwordless authentication deployment – Microsoft Learn
- Microsoft Authenticator authentication method – Microsoft Learn
- QR code authentication method in Microsoft Entra ID – Microsoft Learn
- How self-service password reset works in Microsoft Entra ID – Microsoft Learn
- Prepare users to provision and use Windows Hello for Business – Microsoft Learn
