Entra ID Custom Controls Einstellung External Authentication Methods: Migrationsleitfaden vor September 2026

Entra ID Custom Controls Einstellung External Authentication Methods: Was sich ändert und warum

Der Termin für die Entra-ID-Custom-Controls-Einstellung bei External Authentication Methods steht jetzt fest. Laut Microsoft Learns eigener Dokumentation zu Conditional Access ist es ab September 2026 nicht mehr möglich, neue Custom Controls zu erstellen oder bestehende zu bearbeiten; die vollständige Einstellung ist für Anfang 2027 vorgesehen. Ein Microsoft-365-Message-Center-Hinweis, MC1422061 ("Microsoft Entra ID: Retirement of Custom Controls in Conditional Access and migration to External MFA"), bestätigt dieselbe Sperre ab September 2026 und legt die vollständige Einstellung auf Mai 2027 fest, ab dem Custom Controls vollständig nicht mehr unterstützt werden. External Authentication Methods — die standardbasierte Fähigkeit, die Microsoft inzwischen als External MFA vermarktet — ist der einzige unterstützte Ersatz.

Custom Controls waren nie eine ausgereifte, allgemein verfügbare Conditional-Access-Funktion — Microsoft Learn beschreibt sie von Anfang an als "eine Preview-Fähigkeit". Nutzte eine Policy ein Custom Control, wurde der Browser eines angemeldeten Benutzers zu einem zugelassenen Drittanbieterdienst umgeleitet, führte dort die Authentifizierung durch und wurde zurück zu Entra ID geleitet, das die Antwort verifizierte, bevor der Anmeldevorgang fortgesetzt wurde. Genau diese Umleitung wird jetzt eingestellt: dasselbe Ergebnis — Drittanbieter-MFA innerhalb von Conditional Access durchgesetzt — läuft künftig über eine native, GA-Authentifizierungsmethode statt über einen Redirect-und-Verifizierungs-Handshake.

Wie Custom Controls funktionieren — und warum External MFA sie ersetzt

Die Einstellung ist nicht rein kosmetisch. Microsofts eigene Migrationsanleitung listet konkrete funktionale Lücken auf, die Custom Controls schon immer hatten — Lücken, die External MFA schließt:

Quelle: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access."

Microsofts Custom-Controls-Dokumentation nennt dieselbe Lücke aus der anderen Richtung: Custom Controls können ausdrücklich nicht verwendet werden, um die automatisierte MFA-Anforderung von Identity Protection, das Self-Service-Passwort-Reset von Microsoft Entra, MFA-Claim-Anforderungen, Sign-in-Frequency-Kontrollen, PIM-Rollenaktivierung, Intune-Geräteregistrierung, Cross-Tenant-Trust oder Device Join zu erfüllen. Ein Tenant, der sich für "MFA" auf ein Custom Control verlässt, betreibt in der Praxis ein Imitat, das mehrere andere Entra-Funktionen gar nicht als MFA erkennen — eine relevante Lücke gegenüber nativen Methoden, die wir in unserer Analyse der Änderungen bei der passwortlosen MFA-Registrierung behandeln.

Es gibt auch eine Namensfalle, die man während der Migration im Blick behalten sollte: Der Ersatz erschien zunächst als Preview unter dem Namen "external authentication methods" und erreichte dann unter dem Namen External MFA (External Multifactor Authentication) die allgemeine Verfügbarkeit, laut Microsofts GA-Ankündigung im Entra-Blog. Microsoft Learn, die Admin-Center-Oberfläche und Graph-API-Objekte (externalAuthenticationMethodConfiguration) verwenden intern weiterhin die Terminologie "external authentication method" — je nachdem, wo Sie nachsehen, begegnen Ihnen also beide Namen.

Erkennung: Jede Conditional-Access-Policy finden, die Custom Controls verwendet

Bevor Sie irgendetwas ändern, erstellen Sie ein Inventar der Conditional-Access-Policies, die heute tatsächlich ein Custom Control verwenden. Laut Microsofts Migrationsanleitung geht das auf zwei Wegen:

Portal: Melden Sie sich im Microsoft Entra admin center mindestens als Authentication Policy Administrator an, navigieren Sie zu Protection > Conditional Access > Policies und prüfen Sie bei jeder Policy die Grant-Kontrollen auf einen Verweis auf ein Custom Control. Notieren Sie bei jedem Treffer den Policy-Namen und die ID, die anvisierten Benutzer/Gruppen und Cloud-Apps, den referenzierten Custom-Control-Anbieter sowie alle Bedingungen (Standorte, Geräteplattformen).

Microsoft Graph PowerShell (schneller bei großen Tenants — Microsofts Anleitung weist darauf hin, dass manche Umgebungen Dutzende oder Hunderte Conditional-Access-Policies zu prüfen haben):

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and (
        @($_.GrantControls.CustomAuthenticationFactors) |
        Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }
    ).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }) -join "," }
}

Quelle: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access."

Exportieren Sie die Ergebnisse, bevor Sie mit der Migration beginnen. Hat eine Policy keinen Custom-Control-Verweis, ist laut Microsofts eigener Anleitung keine Aktion nötig — investieren Sie keinen Migrationsaufwand in unbetroffene Policies.

Remediation: Vor der Frist zu External Authentication Methods migrieren

Sobald das Inventar steht, beschreibt Microsofts Migrationsanleitung einen gestuften Weg. Zuerst die Voraussetzungen: eine Microsoft-Entra-ID-P1- oder -P2-Lizenz, die Rolle Authentication Policy Administrator (Global Administrator funktioniert ebenfalls), Privileged Role Administrator, um den Admin-Consent für die App des Anbieters zu erteilen, sowie Metadaten Ihres External-MFA-Anbieters — dessen Application ID, Client ID und OIDC Discovery URL.

1. Den External-MFA-Anbieter registrieren. Gehen Sie im Admin Center zu Protection > Authentication methods > Policies > Add external method, geben Sie den Anzeigenamen (nach dem Erstellen nicht mehr änderbar), die Client ID, die App ID und den Discovery Endpoint an und erteilen Sie anschließend den Admin-Consent für die App des Anbieters. Dieselbe Konfiguration ist auch über die Graph API verfügbar (POST /policies/authenticationMethodsPolicy/authenticationMethodConfigurations mit @odata.type: "#microsoft.graph.externalAuthenticationMethodConfiguration") oder über das PowerShell-Cmdlet New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration, für Teams, die den Rollout automatisieren.
2. Zielen Sie beim Aktivieren der Methode nur auf eine Testgruppe — nicht auf alle Benutzer — und registrieren Sie diese Testnutzer für die External Authentication Method, bevor Sie fortfahren.
3. Bauen Sie eine neue Conditional-Access-Policy im Report-Only-Modus mit dem Standard-Grant "Require multifactor authentication" (nicht dem Custom Control), skopiert auf dieselben Cloud-Apps und Bedingungen wie die alte Policy, zielt auf die Testgruppe und schließt Break-Glass- und Notfallzugangskonten aus.

🚨 Gefahr: Microsofts Anleitung stellt ausdrücklich klar, dass External MFA noch nicht mit "Require authentication strength" kompatibel ist — nur der Standard-Grant "Require multifactor authentication" erfüllt die Anforderung. Wird die Testpolicy auf eine Authentication-Strength-Anforderung aufgebaut, funktioniert sie stillschweigend nicht wie erwartet.

4. Zuerst im Report-Only-Modus verifizieren: Prüfen Sie im Conditional-Access-Tab der Sign-in-Logs, dass die Policy wie erwartet ausgewertet wird und die MFA-Methode Ihren externen Anbieter zeigt, und schalten Sie die Policy dann auf Ein.
5. Schließen Sie die Testgruppe von der alten Custom-Control-Policy aus und bestätigen Sie mit dem What-If-Tool, dass nur die neue Policy für sie gilt und dass Test-Anmeldungen tatsächlich vom externen Anbieter und nicht vom Custom Control geprüft werden.
6. Rollen Sie stufenweise aus — Testgruppe, dann IT/Early Adopters, dann Abteilung für Abteilung, dann alle Benutzer — und erweitern Sie bei jeder Stufe sowohl die Zielgruppe der External-MFA-Methode als auch den Geltungsbereich der neuen Conditional-Access-Policy.
7. Die alte Policy zuletzt einstellen, nicht zuerst. Deaktivieren (nicht löschen) Sie die alte Custom-Control-Policy und beobachten Sie ein bis zwei Wochen lang die Sign-in-Logs, bevor Sie sie löschen und die Custom-Control-Definition entfernen — und behalten Sie dabei einen Rollback-Weg für den Fall von Regressionen.

Wie EtcSec das erkennt

EtcSecs Conditional-Access-Checks decken genau die Lücke auf, die diese Einstellung erzwingt: CA_NO_MFA_REQUIREMENT zeigt Cloud-Apps und Benutzerbereiche ohne eine Conditional-Access-Policy, die tatsächlich MFA erfordert — genau der Zustand, in den ein Tenant gerät, wenn eine Custom-Control-Policy stillschweigend aufhört zu funktionieren und nichts sie ersetzt. MFA_NOT_ENFORCED_ADMINS und MFA_NO_STRONG_METHOD erfassen privilegierte Konten und schwache Methodenkonfigurationen, die ein defektes oder nicht migriertes Custom Control verschleiern kann, da Custom Controls von Anfang an nie als native MFA-Claim reflektiert wurden. CA_POLICY_REPORT_ONLY markiert Policies — einschließlich der von dieser Migration empfohlenen Report-Only-Testpolicy —, die nie auf "erzwungen" umgeschaltet wurden, damit eine pausierte Migration nicht unbemerkt durchrutscht.