In vielen Tenants, die ich betreue, finde ich nach wie vor benutzerdefinierte Steuerelemente für die Multi-Faktor-Authentifizierung. Meist handelt es sich um Umgebungen, in denen die Anmeldung noch über Drittanbieter wie Duo, Okta oder RSA läuft. Seit Microsoft in Entra ID die externen Authentifizierungsmethoden (External Authentication Methods, EAM) als moderne Alternative eingeführt hat, sind die Tage der alten Custom Controls gezählt. Den Umstieg sollte man trotzdem sorgfältig planen. Die EAM-Integration eröffnet neue Möglichkeiten, hat aber auch ihre Tücken.

Externe Authentifizierungsmethoden binden Drittanbieter-MFA offiziell an Entra ID an

Viele Unternehmen wollten ihre MFA-Lösung von Drittanbietern schon lange offiziell in Entra ID einbinden, mit sauberer Unterstützung für Conditional Access (CA) und ohne Bastellösungen. Genau darauf antwortet Microsoft mit den externen Authentifizierungsmethoden. Ihr richtet sie im Entra Admin Center unter Entra ID → Authentifizierungsmethoden → Richtlinien → Externe Methode hinzufügen ein. Anbinden lassen sich dort Duo, Okta, RSA oder auch unternehmenseigene Lösungen, sofern sie das passende Protokoll und die Integration als External Authentication Method Provider unterstützen (Details und Anforderungen).

Für den Alltag heißt das, dass die MFA-Anforderung nicht mehr über die fehleranfälligen und unsicheren Custom Controls im Conditional Access laufen muss, sondern direkt von einer externen Methode erfüllt wird. Conditional Access wertet das als „Mehrstufige Authentifizierung“. Bei einer Policy wie „MFA für alle Benutzer“ zählt also auch ein zweiter Faktor, den EAM ausgelöst hat. Custom Controls sind damit allenfalls noch eine Übergangslösung, und Microsoft rät schon seit einiger Zeit zum Wechsel auf EAM (siehe Dokumentation).

Der Wechsel von Custom Controls zu EAM verläuft in mehreren Schritten

Technisch lässt sich die Migration umsetzen, im Detail hängt aber vieles vom jeweiligen Anbieter ab. Der übliche Ablauf sieht so aus: Zuerst registriert und aktiviert man das externe System als Provider im Entra Admin Center. Danach steht EAM im Conditional Access als „authentifizierte Methode“ zur Verfügung. Die Registrierung der Nutzer für die externe Methode passiert allerdings meist nicht von selbst. Häufig müssen die User im Drittanbietersystem noch einmal ein Onboarding durchlaufen, bevor der Claim im Entra-Token ankommt.

Gern übersehen wird, dass die vorhandene MFA-Registrierung in Entra ID bestehen bleibt. Nutzer können also unter Umständen Entra-eigene MFA-Methoden wie die Authenticator-App und externe Methoden nebeneinander verwenden. Wer das verhindern will, muss die Richtlinien für die Authentifizierungsmethoden gezielt anpassen. Gerade in gewachsenen Umgebungen mit vielen Altlasten aus den Custom Controls hat sich bei mir ein vollständiges Audit der bestehenden Policies und Claims bewährt. Andernfalls bleibt womöglich irgendwo doch noch ein Schlupfloch für schwache Authentifizierung offen.

Tipp: Plant für die Migration genügend Testzeit ein und arbeitet mit getrennten Pilotgruppen. Wenn die Registrierung nicht sauber durchgelaufen ist, sehen User bei EAM gern kryptische Fehlermeldungen wie „Method not available“.

EAM stößt im Conditional Access an klare Grenzen

EAM erfüllt die MFA-Claims für Conditional Access zwar elegant, hat aber einige Einschränkungen, die ich im Projektalltag immer wieder erläutern muss:

  • EAM ist nicht phishingresistent (anders als FIDO2 oder Certificate-based Authentication), es sei denn, der Anbieter liefert eigene Schutzmechanismen mit.
  • In vielen Entra-ID-Berichten und -Auswertungen erscheint EAM (noch) nicht als eigene Methode. Für Audits ist die Nachvollziehbarkeit deshalb eingeschränkt.
  • Die Registrierung der User läuft nicht zentral. In der Regel meldet sich der Nutzer selbst im Drittanbietersystem an, und Entra ID hat auf diesen Prozess keinen Einfluss.
  • Laut aktueller Ankündigung lässt sich EAM nur eingeschränkt mit anderen Methoden kombinieren (etwa „require two of …“ oder „Authentication Strengths“). Für fein abgestufte CA-Policies ist die native Microsoft-MFA daher oft die bessere Wahl.

Wegen der fehlenden Phishingresistenz und der dürftigen Einbindung in die Berichte betrachte ich EAM vor allem als Brückenlösung für Bestandsumgebungen. Wer ohnehin alle Anwender neu registrieren lässt, ist auf lange Sicht mit Passkeys, FIDO2 oder wenigstens dem Microsoft Authenticator mit „Number Matching“ besser aufgestellt.

Entra ID setzt nach der EAM-Challenge einen MFA-Claim im Token

Aus Sicht des Tokens und des Conditional Access läuft EAM folgendermaßen ab: Hat der Nutzer die Anmeldung und die EAM-Challenge bestanden, wird ein MFA-Claim gesetzt. Das Diagramm zeigt die einzelnen Schritte von der Anmeldung bis zur Policy-Entscheidung:

sequenceDiagram
    participant Benutzer as "[Nutzer]"
    participant Entra as "[Entra ID]"
    participant EAM as "[EAM Provider]"
    Benutzer->>Entra: "[Anmeldung]"
    Entra->>EAM: "[Anforderung externer Faktor]"
    EAM-->>Benutzer: "[MFA Challenge]"
    Benutzer-->>EAM: "[Antwort]"
    EAM-->>Entra: "[Erfolg/Misserfolg]"
    Entra->>Entra: "[Conditional Access Prüfung]"
    Entra-->>Benutzer: "[Zugang erlauben/verweigern]"

Abbildung: Entra ID bindet eine externe Authentifizierungsmethode in den Anmeldeablauf ein.

Solange der externe Anbieter zuverlässig arbeitet, greifen die meisten Standard-Policies („MFA erforderlich“, Geoblocking usw.) dadurch weiterhin ohne Probleme. Kritisch wird es, wenn der EAM-Provider ausfällt, denn dann kommen die Nutzer nicht mehr herein. Ich rate deshalb grundsätzlich dazu, einen Break-Glass-Account mit nativer MFA vorzuhalten (siehe Notfallzugang).

Die Auswertung der EAM-Nutzer erfordert noch eigene Skripte

Welche Nutzer EAM tatsächlich als MFA-Methode eingerichtet haben, zeigt Entra ID im Juni 2026 nur sehr rudimentär an. Für einen schnellen Überblick genügt das Reporting zu den Authentifizierungsmethoden, ausführliche Listen sucht man dort aber meist vergeblich. Für genauere Ergebnisse braucht man ein eigenes Abfrageskript. Das lässt sich zum Beispiel mit PowerShell 7 und dem Microsoft Graph PowerShell SDK umsetzen (erforderlich ist die Rolle Global Reader oder Authentication Policy Administrator):

# PowerShell 7, Microsoft.Graph.AuthenticationMethods Modul
Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All'
Get-MgUserAuthenticationMethod -All
# Sucht nach Methoden vom Typ external oder Drittanbieter

So ausführlich wie bei FIDO2 oder dem Authenticator ist die Ausgabe noch nicht. Um Pilotgruppen zu überprüfen, reicht sie in meinen Projekten aber in der Regel aus.

Native MFA bleibt für neue Umgebungen die bessere Wahl

Sinnvoll ist EAM aus meiner Sicht vor allem dann, wenn ein Unternehmen bereits in Drittanbieter-MFA investiert hat, diese weiter nutzen muss und ein kurzfristiger Wechsel auf eine native Methode nicht realistisch ist. In neuen Cloud-first-Umgebungen und überall, wo die Sicherheit Vorrang hat, empfehle ich dagegen stets den Umstieg auf phishingresistente Methoden (Passkeys, FIDO2 oder Certificate-based MFA). Für native Methoden sprechen neben dem Schutz vor Angriffen wie AiTM-Phishing auch die bessere Einbindung in Conditional Access, Lifecycle-Management und Compliance-Reporting. Ausführlicher bin ich darauf im Beitrag Migration der Authentifizierungsmethoden in Entra ID meistern eingegangen.

EAM eignet sich also als Werkzeug für kontrollierte Übergänge, nicht als Dauerlösung. Wer den Wechsel vorbereitet, sollte jetzt die Altlasten aus den Custom Controls prüfen, Testgruppen für EAM anlegen und auf längere Sicht ein klares Zielbild für die MFA-Strategie im Tenant erarbeiten.