SMS und Voice MFA Deprecation in Entra ID: Was in den folgenden Monaten passiert

SMS & Voice MFA ist “Geschichte” - aber noch nicht ganz…

Die Ankündigung vom 13. Juli 2026, welche das Ende von SMS und Voice als native Authentifizierungsmethoden in Entra ID besiegelt hat, ist eine die sicher dem ein oder anderen Identity Admin gewisse Kopfschmerzen bereitet hat. Denn mit dieser Ankündigung wurde nicht nur SMS und Voice MFA als de-facto “tot” deklariert sondern auch noch der wichtige Push in Richtung “sicherer” MFA Methoden forciert.

Am 1. September 2026 hat Microsoft nämlich auch direkt schon gehandelt, und zwar in der Konfiguration aller betroffenen Tenants. Falls ihr also SMS oder Voice zum Stichtag noch in der Authentication Methods Policy oder in den Legacy MFA Settings aktiviert hattet, wurde bei euch bereits etwas verändert - was konkret schauen wir uns in diesem Artikel an.

Was euch in diesem Blogpost konkret erwartet:

• was am 1. September technisch tatsächlich passiert ist
• warum „kein Opt-out” nicht bedeutet, dass jemand automatisch ausgesperrt wird
• die Detailentscheidung rund um „synced” und „device-bound” Passkeys, welche in fast allen Zusammenfassungen fehlt
• die Tasks, welche bis 1. Februar 2027 abzuarbeiten sind

Warum Microsoft diesen Schritt setzt

Die Begründung ist rein sicherheitstechnischer Natur und ehrlicherweise auch schwer zu widerlegen. SMS und Voice zählen zu den schwächsten der heute noch gängigen MFA-Methoden und sind gegen eine ganze Reihe von Angriffstypen anfällig, allen voran SIM-Swapping, das Abfangen von Einmalcodes und AitM (Adversary-in-the-Middle). Ein per SMS zugestellter Code ist an keine Domain gebunden und läuft daher bei einem AitM-Angriff genauso über den Reverse Proxy des Angreifers wie das Passwort selbst, was ich in meinen Demos auch regelmäßig zeige.

Passkeys verfolgen einen grundlegend anderen Ansatz, da sie auf Public-Key-Kryptografie statt auf einem geteilten Geheimnis basieren und „origin-bound” sind, also fest an die legitime Domain gebunden. Ein Passkey, welcher auf login.microsoft.com registriert wurde, funktioniert auf einer vom Angreifer kontrollierten Phishing-Domain schlicht nicht, wodurch dieser Angriffsvektor vollständig entfällt. Es handelt sich dabei um genau denselben Schutzmechanismus, welcher bereits im Zusammenhang mit MFA Downgrade Attacks relevant war, nur dass Microsoft ihn nun nicht mehr empfiehlt, sondern erzwingt.

Der Zeitplan und wo wir gerade stehen

Datum	Was passiert	Status
1. September 2026	SMS- und Voice-User werden automatisch für Passkeys aktiviert, die Registration Campaign wird auf „Microsoft Managed” gesetzt, der Nudge startet beim nächsten MFA-Login	bereits erledigt
18. September 2026	Die Telekom-Provider im Microsoft Security Store werden samt Konditionen vorgestellt	in wenigen Tagen
30. Oktober 2026	Die Provider lassen sich auswählen und konfigurieren	offen
1. Februar 2027	Die native SMS- und Voice-Zustellung wird abgeschaltet, der Passkey-Prompt wird blockierend, ein Opt-out existiert ab diesem Zeitpunkt nicht mehr	der eigentliche “Hardcut”

Von diesen vier Terminen sind genau zwei echte Entscheidungspunkte, nämlich der bereits vergangene 1. September und der 1. Februar 2027. Dazwischen liegen rund fünf Monate, welche für eine saubere Migration ausreichen, sofern man jetzt damit beginnt und nicht erst im Jänner.

Was am 1. September passiert ist

Für jeden User, welcher zum Stichtag in der Authentication Methods Policy (AMP) oder in den Legacy MFA Settings für SMS oder Voice aktiviert war, hat Microsoft drei Änderungen vorgenommen, und zwar automatisch und ohne Rückfrage.

Der User wurde in der AMP für Passkeys aktiviert und einem Passkey-Profil zugeordnet, welches sämtliche Passkey-Typen erlaubt (sowohl „synced” als auch „device-bound”, auf diesen Unterschied gehe ich weiter unten noch genauer ein). Zusätzlich wurde die Registration Campaign des Tenants auf den Status „Microsoft Managed” gesetzt und auf Passkeys ausgerichtet, wodurch die betroffenen User automatisch in deren Scope gefallen sind. Beim nächsten Sign-in mit vollständig abgeschlossener MFA bekommt der User schließlich einen sogenannten „Nudge”, also die Aufforderung, einen Passkey zu registrieren.

Wer bereits eine eigene, abgestimmte Registration Campaign betrieben hat, dessen Konfiguration wurde dabei überschrieben. Es lohnt sich daher, unter Entra ID > Authentication methods > Registration campaign nachzusehen, ob dort noch das steht, was euer Team dort ursprünglich hinterlegt hat.

Wichtig für die Praxis ist außerdem, dass zum jetzigen Zeitpunkt noch niemand ausgesperrt wird. Der Nudge ist standardmäßig unbegrenzt aufschiebbar, der User kann die Registrierung also beliebig oft verschieben, was er erfahrungsgemäß auch tun wird. Seit 1. September läuft somit lediglich der sanfte Druck, die tatsächliche Forcierung kommt dann erst im Februar.

1. Februar 2027 und die korrekte Bedeutung von „kein Opt-out”

Der 1. Februar 2027 ist der eigentliche Schnitt, da ab diesem Datum die native Zustellung von SMS und Voice eingestellt wird. Für User, deren einzige verbleibende MFA-Methode SMS oder Voice ist, wird der Passkey-Prompt beim Sign-in blockierend, das heißt die Registrierung eines Passkeys wird zur zwingenden Voraussetzung, um sich weiterhin anmelden zu können.

An dieser Stelle eine Präzisierung, weil der Sachverhalt in vielen Zusammenfassungen dramatischer klingt, als er ist: es handelt sich ausdrücklich NICHT um ein Aussperren. Der betroffene User verliert nicht den Zugang zu seinem Konto, sondern muss vor dem Weiterarbeiten einen Passkey registrieren. Der viel zitierte Ausdruck „kein Opt-out” bezieht sich einzig auf dieses erzwungene Registrierungsverhalten.

Genau hier liegt auch die wichtigste Unterscheidung des gesamten Themas, da zwei völlig verschiedene „Opt-outs” existieren oder eben “nicht” existieren:

• Der temporäre Opt-out für den Zeitraum September bis Februar existiert. Er wird über ein Flag in der Authentication Methods Policy gesetzt und verschiebt ausschließlich die weichen Nudges, während man die eigenen Migrationsschritte umsetzt
• Ein permanenter Opt-out von der Abschaltung selbst existiert hingegen nicht. Der einzige Weg, SMS oder Voice über den 1. Februar 2027 hinaus zu betreiben, führt über einen selbst beauftragten Telekom-Provider.

Der temporäre Opt-out ist dabei kein Schalter im Portal, sondern ein einzelner Graph-PATCH auf Tenant-Ebene, für welchen ihr die Permission Policy.ReadWrite.AuthenticationMethod benötigt:

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
  "optOutSettings": {
    "passkeyDynamicMigration": true
  }
}

Nach dem Setzen dieses Flags ist der Tenant für den genannten Zeitraum von der automatischen Passkey-Aktivierung sowie der Registration Campaign ausgenommen. Ab dem 1. Februar 2027 greifen Migration und Enforcement jedoch unabhängig von dieser Einstellung, das Flag kauft euch also etwas Zeit.

Synced oder device-bound? Die eigentliche Detailentscheidung

Der aus Sicht der Informationssicherheit spannendste Punkt wird in den meisten Ankündigungen nicht einmal erwähnt. Bei der automatischen Aktivierung am 1. September wurden die betroffenen User einem Passkey-Profil zugeordnet, welches sämtliche Passkey-Typen zulässt, und Entra ID unterscheidet hier zwei Ausprägungen:

• „Synced Passkeys” werden im Credential-Manager der jeweiligen Plattform abgelegt (z.B. iCloud Keychain oder Google Password Manager) und über die Geräte des Users synchronisiert. Diese Variante ist vor allem für jene Anwender praktikabel, die dazu neigen oft neue Geräte zu bekommen und keiner “High Risk” Usergruppe zugehörig sind (also z.B. kein C-Level, keine IT, etc.)
• „Device-bound Passkeys” werden auf einem konkreten Gerät erzeugt und verlassen dieses nicht. Dazu zählen der Passkey im Microsoft Authenticator, der Entra Passkey unter Windows oder auch der neue “Hello for Business” Passkey

Beide Varianten sind „origin-bound” und damit gegen AitM-Angriffe resistent, der wesentliche Unterschied liegt im Assurance-Level. Ein „synced” Passkey ist letztlich nur so vertrauenswürdig wie das Cloud-Konto, in welchem er gespeichert ist, sowie die Geräte, über welche er synchronisiert wird. Für einen Standard-Benutzer ist das in der Regel ausreichend, für privilegierte Rollen häufig nicht.

Daraus ergibt sich eine Konstellation, welche vor allem bei bestehenden Conditional Access Policies relevant wird: erzwingt eine Policy eine Authentication Strength, welche über „Key-Restrictions” (per AAGUID oder Attestation) auf device-bound Methoden eingeschränkt ist, kann ein „synced” Passkey aus iCloud oder Google diese Anforderung unter Umständen nicht erfüllen. Die automatische Aktivierung durch Microsoft berücksichtigt diese Feinheit selbstverständlich nicht, sondern erlaubt pauschal alle Typen, und die User registrieren dann erfahrungsgemäß den jeweils bequemsten und nicht den sichersten Typ.

Wer für bestimmte Benutzergruppen ausschließlich device-bound Passkeys erzwingen möchte, muss das daher aktiv über die eigene Authentication Methods Policy sowie die passende Authentication Strength definieren, und zwar bevor die halbe Belegschaft ihren Passkey im privaten iCloud-Account liegen hat. Damit setzt sich der Grundgedanke fort, welcher bereits bei den MFA Downgrade Attacks der zentrale Punkt war: entscheidend ist nicht die bloße Existenz einer starken Methode, sondern deren serverseitige Erzwingung.

Weiterbetrieb von SMS und Voice über einen Telekom-Provider

Für Organisationen mit tatsächlichem regulatorischem oder operativem Bedarf entfällt SMS und Voice nicht vollständig, verlagert sich jedoch weg von Microsofts Infrastruktur, da in diesem Fall direkt ein Vertrag mit einem Telekom-Provider aus dem Microsoft Security Store abzuschließen ist. Die entsprechenden Provider werden ab dem 18. September 2026 samt Konditionen vorgestellt und lassen sich ab dem 30. Oktober 2026 auswählen und konfigurieren. Die dabei entstehenden Kosten (typischerweise pro Nachricht, abhängig von Volumen und Region) trägt der Kunde.

Ein Punkt, welcher dabei gerne übersehen wird: laut FAQ bekommen jene User, für welche rechtzeitig ein Provider konfiguriert und die Migration abgeschlossen wurde, den blockierenden Passkey-Prompt am 1. Februar nicht. Wer den Provider hingegen zwar bestellt, die betroffenen User aber weiterhin auf „Microsoft-provided” SMS stehen lässt, fällt trotzdem in die Erzwingung, was in der Planung entsprechend zu berücksichtigen ist.

Der zweite regelmäßig übersehene Punkt betrifft SSPR (Self-Service Password Reset). Die Abschaltung der nativen SMS- und Voice-Zustellung gilt tenant-weit über sämtliche Entra-Funktionen hinweg und somit auch für den Passwort-Reset. Wer SMS bislang als SSPR-Kanal einsetzt, benötigt dafür ebenfalls einen Provider aus dem Security Store oder eine alternative Methode. Microsoft hat hier zusätzlich angekündigt, einen Weg für die Passwortänderung von passwordless angemeldeten Usern nachzuliefern, Details dazu sind derzeit aber noch offen.

What now?

Damit bleiben für die nächsten Wochen folgende Tasks übrig, und zwar sinnvollerweise in dieser Reihenfolge:

1. Nachsehen, was Microsoft bei euch verändert hat. Prüft die Authentication Methods Policy auf das neue Passkey-Profil und die Registration Campaign auf den Status „Microsoft Managed”. Vor allem in Tenants mit einer eigenen, gut abgestimmten Kampagne ist das der Punkt, an welchem seit 1. September etwas anders läuft als geplant.
2. Betroffene User identifizieren. Microsoft stellt dafür ein PowerShell-Skript bereit, den entra-sms-voice-usage-analyzer auf GitHub, wofür eine der Rollen Global Reader, Authentication Policy Administrator oder Security Reader ausreicht. Jedes Ergebnis ungleich Null bedeutet, dass ihr im Scope seid.
3. Passkey-Typen bewusst festlegen. Anstatt es beim automatisch zugewiesenen „alles erlaubt”-Profil zu belassen, gehören die erlaubten Typen samt „Key-Restrictions” definiert, und für privilegierte Rollen sollte eine Authentication Strength greifen, welche ausschließlich device-bound Passkeys akzeptiert.
4. Registrierung selbst steuern oder bewusst pausieren. Entweder ihr übernehmt die Kampagne wieder selbst und adressiert gezielt die Sicherheitsgruppe der SMS- und Voice-User, oder ihr setzt den temporären Opt-out per Graph, solange die Vorarbeiten laufen. Beides ist vertretbar, nur das Aussitzen nicht.
5. Nutzerkommunikation aufsetzen. Eine koordinierte Kommunikation ist erfahrungsgemäß der wesentlichste Faktor für einen reibungslosen Rollout, sinnvoll ist ein dreistufiger Ablauf (Awareness, Action, Reminder). Entsprechende Vorlagen stellt Microsoft unter aka.ms/mfatemplates bereit.
6. Telekom-Provider nur bei echtem Bedarf evaluieren. Ab 18. September stehen die Konditionen zur Verfügung, ab 30. Oktober die Konfiguration, und für jedes Segment ohne regulatorische Notwendigkeit bleibt der Passkey die Standardmethode.

Ergänzend zu beachten ist, dass auch B2B- und interne Gast-User unter dieses Retirement fallen, während der zugehörige Passkey-Support laut Microsoft erst für Ende 2026 vorgesehen ist. Bei einer größeren Anzahl externer Identitäten gehört dieser Punkt daher früh in die Planung, weil sich hier ein Zeitfenster auftut, welches unangenehm knapp werden kann.

Fazit

Zwei Punkte bleiben festzuhalten. Erstens war der 1. September jener Zeitpunkt, an welchem über den Erhalt der eigenen Kontrolle entschieden wurde, und wer ihn verpasst hat, arbeitet ab jetzt in einer von Microsoft gesetzten Konfiguration, welche man aktiv zurückholen muss. Zweitens bezieht sich „kein Opt-out” ausschließlich auf die erzwungene Passkey-Registrierung und nicht auf ein Aussperren, während der einzige Weg, SMS oder Voice darüber hinaus zu erhalten, mit Kosten verbunden ist und einen eigenen Telekom-Provider voraussetzt.

Bis 1. Februar 2027 bleiben rund fünf Monate. Das ist ausreichend, aber nur dann, wenn die Analyse jetzt passiert und nicht erst dann, wenn der erste User im Jänner mit einem blockierenden Prompt beim Helpdesk anruft.

Falls ihr Fragen zum Thema habt oder eure Erfahrungen aus der Migration teilen wollt, meldet euch gerne, ich bin neugierig wie sauber die automatische Aktivierung in der Breite tatsächlich gelaufen ist.

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
  "optOutSettings": {
    "passkeyDynamicMigration": true
  }
}