Microsoft dreht den Standard um
Am 13. Juli 2026 hat Microsoft angekündigt, Passkeys zur Standard-Authentifizierungsmethode in Entra ID zu machen — und gleichzeitig die Microsoft-eigene Mehr-Faktor-Authentifizierung per SMS und Sprachanruf schrittweise abzuschalten. Für Unternehmen, die Microsoft 365 und Azure produktiv nutzen, ist das keine Randnotiz, sondern eine terminierte Umstellung mit zwei harten Stichtagen und einem klaren Handlungsdruck für die IT.
Der Auslöser ist kein Selbstzweck. Microsoft begründet den Schritt im Microsoft Digital Defense Report 2025 mit einer deutlichen Verschiebung der Bedrohungslage: KI-gestützte Phishing-Kampagnen erreichten demnach Klickraten von bis zu 54 Prozent, während klassische Kampagnen bei rund 12 Prozent lagen. Warum KI-Phishing so viel wirksamer ist und was das über die Wahl der Anmeldemethode hinaus bedeutet, haben wir in einem eigenen Beitrag zu KI-Phishing aufgearbeitet. Dieser Artikel konzentriert sich auf die konkrete Umstellung in Entra ID: Was ändert sich, bis wann, und was müssen Sie vorbereiten.
Die Stichtage im Überblick
Microsoft rollt die Änderung in mehreren Stufen aus. Entscheidend sind zwei Termine: der 1. September 2026, ab dem Passkeys automatisch aktiviert werden, und der 1. Februar 2027, ab dem die Microsoft-eigene SMS- und Voice-MFA endet. Dazwischen liegen zwei organisatorische Termine für Unternehmen, die SMS oder Sprachanruf zwingend behalten müssen.
| Datum | Was passiert |
|---|---|
| 1. September 2026 | Nutzer, die in der Authentifizierungsmethoden-Richtlinie (oder in den Legacy-MFA-Einstellungen) für SMS oder Sprachanruf aktiviert sind, werden automatisch für Passkeys freigeschaltet. Bei der nächsten Anmeldung mit MFA fordert eine Registrierungskampagne zur Einrichtung eines Passkeys auf. |
| 18. September 2026 | Microsoft veröffentlicht die Liste unterstützter Telekommunikationsanbieter samt Bereitstellungsanleitung, Preisen und Vertragskonditionen über den Microsoft Security Store. |
| 30. Oktober 2026 | Administratoren können einen unterstützten Telekommunikationsanbieter über den Microsoft Security Store auswählen und konfigurieren. |
| 1. Februar 2027 | Microsoft stellt die eigene Bereitstellung von SMS und Sprachanruf ein. Tenants ohne selbst verwalteten Telekommunikationsanbieter können SMS und Voice nicht mehr für MFA nutzen. Nutzer, deren einzige MFA-Methode SMS oder Voice ist, müssen bei der Anmeldung einen Passkey registrieren, bevor sie weiterarbeiten können. |
Wichtig für die Budget- und Projektplanung: Die Migration von SMS- und Voice-Nutzern auf Passkeys verursacht laut Microsoft keine zusätzlichen Kosten. Wer SMS oder Sprachanruf über den 1. Februar 2027 hinaus behalten will — etwa für Szenarien, in denen Passkeys nicht praktikabel sind — muss dagegen einen Drittanbieter über den Microsoft Security Store beauftragen und dessen Konditionen tragen.
Warum SMS und Sprachanruf kein guter zweiter Faktor mehr sind
Ein Einmalcode per SMS war lange besser als gar kein zweiter Faktor — und ist es in absoluten Zahlen noch immer. Das Problem liegt nicht darin, dass SMS-MFA nichts bringt, sondern darin, dass sie gegen die heute dominierenden Angriffsmuster kaum noch schützt. Ein per SMS oder Sprachanruf zugestellter Einmalcode ist ein geteiltes Geheimnis, das der Nutzer abliest und eingibt. Genau das lässt sich abfangen.
Bei einem Adversary-in-the-Middle-Angriff schaltet der Angreifer eine gefälschte Anmeldeseite zwischen Nutzer und echten Dienst. Der Nutzer gibt Passwort und SMS-Code auf der Phishing-Seite ein, der Angreifer reicht beides in Echtzeit an den echten Dienst weiter und übernimmt die Sitzung — inklusive des ausgestellten Tokens. Der zweite Faktor wird dabei nicht umgangen, sondern mitgephisht. Hinzu kommen SIM-Swapping, bei dem Angreifer die Rufnummer auf eine eigene SIM portieren lassen, sowie das Abgreifen von SMS über das veraltete SS7-Signalisierungsprotokoll. Das BSI und die US-Behörde CISA raten seit Jahren von SMS als bevorzugtem zweiten Faktor ab, gerade für privilegierte Konten.
Der Kern des Problems: SMS- und Voice-MFA sind nicht phishing-resistent. Sie setzen darauf, dass der Nutzer erkennt, ob er sich auf der echten Seite befindet — und genau diese Erkennung hebeln moderne Phishing-Kits systematisch aus.
Was ein Passkey ist — und warum er nicht phishbar ist
Ein Passkey ist ein kryptografisches Schlüsselpaar auf Basis der Standards FIDO2 und WebAuthn. Der private Schlüssel verlässt niemals das Gerät und wird durch Biometrie (Fingerabdruck, Gesichtserkennung) oder eine Geräte-PIN entsperrt. Bei der Anmeldung signiert das Gerät eine Challenge des Dienstes; der Dienst prüft die Signatur mit dem hinterlegten öffentlichen Schlüssel. Es wird kein Geheimnis übertragen, das ein Angreifer abfangen könnte.
Der entscheidende Schutzmechanismus ist die Origin-Bindung: Ein Passkey ist kryptografisch an die Domain des Dienstes gebunden, für den er registriert wurde. Landet der Nutzer auf einer Phishing-Domain, die der echten täuschend ähnlich sieht, verweigert der Browser die Signatur — der Passkey funktioniert schlicht nicht auf der falschen Seite. Damit läuft der gesamte Adversary-in-the-Middle-Ansatz ins Leere, unabhängig davon, wie überzeugend die gefälschte Seite aussieht oder wie unaufmerksam der Nutzer ist. Genau das meint „phishing-resistent": Der Schutz hängt nicht mehr an der Wachsamkeit des Menschen.
Gerätegebundene und synchronisierte Passkeys
Entra ID unterstützt zwei Arten von Passkeys, die sich in ihrem Sicherheits- und Komfortprofil unterscheiden. Die Wahl zwischen beiden ist eine der zentralen Governance-Entscheidungen der Migration und sollte nicht dem Zufall überlassen werden.
Synchronisierte Passkeys werden im Anmeldeinformations-Manager der Plattform gespeichert — etwa im iCloud-Schlüsselbund oder im Google Passwortmanager — und stehen über alle Geräte desselben Ökosystems zur Verfügung. Das erhöht den Komfort und die Wiederherstellbarkeit erheblich: Geht ein Gerät verloren, ist der Passkey auf dem nächsten weiterhin vorhanden. Der Preis dafür ist, dass der Schlüssel in einer Cloud des jeweiligen Anbieters liegt und dessen Kontosicherheit übernimmt.
Genau an diesem Punkt lohnt der Blick auf einen plattformübergreifenden, unternehmenskontrollierten Passwortmanager statt auf die geräteeigenen Ökosysteme. Als offizieller Bitwarden-Partner setzen wir Bitwarden auch als Speicherort für Passkeys ein: Der Open-Source-Manager verwaltet FIDO2-Passkeys plattformübergreifend über Windows, macOS, iOS, Android und die gängigen Browser hinweg — nicht gebunden an ein einzelnes Anbieter-Ökosystem. Für Unternehmen mit Anforderungen an digitale Souveränität ist der entscheidende Vorteil, dass Bitwarden per Self-Hosting oder EU-Cloud betrieben werden kann und der Passkey-Bestand damit unter der eigenen Kontrolle bleibt — statt im Schlüsselbund eines US-Konzerns. Über den Bitwarden Directory Connector lassen sich Nutzer und Gruppen zudem direkt aus Entra ID synchronisieren, was Bereitstellung und Entzug an den bestehenden Identitätslebenszyklus koppelt.
Gerätegebundene Passkeys verlassen das Gerät dagegen nie. Dazu zählen Passkeys in Microsoft Authenticator, der Entra-Passkey unter Windows sowie dedizierte FIDO2-Sicherheitsschlüssel. Sie bieten das höchste Sicherheitsniveau und sind für privilegierte Konten und Notfallzugänge die richtige Wahl — erfordern aber ein durchdachtes Konzept für Ersatz und Wiederherstellung, weil ein verlorener Schlüssel nicht einfach aus der Cloud zurückkehrt.
| Kriterium | Synchronisierte Passkeys | Gerätegebundene Passkeys |
|---|---|---|
| Speicherort | Cloud-Schlüsselbund des Anbieters (Apple, Google) | Ausschließlich auf dem Gerät bzw. Sicherheitsschlüssel |
| Beispiele | iCloud-Schlüsselbund, Google Passwortmanager, Bitwarden | Microsoft Authenticator, Entra-Passkey unter Windows, FIDO2-Schlüssel |
| Wiederherstellung | Automatisch über das Anbieter-Konto | Nur über hinterlegten Ersatzschlüssel |
| Sicherheitsniveau | Hoch, hängt an der Kontosicherheit des Anbieters | Sehr hoch, Schlüssel ist nicht exportierbar |
| Empfohlen für | Breite Belegschaft, Standard-Konten | Administratoren, Break-Glass-Konten, hochsensible Rollen |
In der Praxis bewährt sich ein gestaffeltes Modell: synchronisierte Passkeys für die breite Belegschaft, um Adoption und Wiederherstellbarkeit zu maximieren, und gerätegebundene FIDO2-Schlüssel für Administratoren und andere privilegierte Rollen, bei denen jedes zusätzliche Sicherheitsniveau zählt.
Was Administratoren jetzt vorbereiten müssen
Der 1. September 2026 kommt schneller, als es scheint — und die automatische Aktivierung sollte niemanden unvorbereitet treffen. Die zentrale Steuerungsebene ist die Authentifizierungsmethoden-Richtlinie in Entra ID, über die festgelegt wird, welche Methoden für welche Nutzergruppen zugelassen und erzwungen werden. Wer hier vor dem Stichtag Ordnung schafft, vermeidet, dass Nutzer im laufenden Betrieb überrascht werden.
Zuerst gilt es, den Ist-Zustand zu erheben: Welche Konten nutzen SMS oder Sprachanruf überhaupt noch als MFA-Methode, und welche davon haben ausschließlich diese Methode hinterlegt? Letztere sind die kritische Gruppe — sie werden ab dem 1. Februar 2027 zwangsweise zur Passkey-Registrierung geleitet, wenn nicht vorher umgestellt wird. Über die Anmelde- und Authentifizierungsmethoden-Berichte in Entra ID lässt sich diese Gruppe sauber eingrenzen.
Anschließend empfiehlt sich eine bewusste Rollout-Strategie statt eines passiven Abwartens. Microsofts Registrierungskampagnen lassen sich gezielt aktivieren, um Nutzergruppen kontrolliert und mit begleitender Kommunikation zur Passkey-Einrichtung zu führen — idealerweise mit Pilotgruppen beginnend, bevor die gesamte Organisation folgt. Entscheiden Sie dabei bewusst, welche Passkey-Art für welche Gruppe vorgesehen ist, und stellen Sie für Konten mit erhöhtem Schutzbedarf FIDO2-Sicherheitsschlüssel bereit.
Für Unternehmen mit Sonderfällen — Servicekonten, Szenarien ohne biometriefähige Geräte, Alt-Anwendungen — ist zu klären, ob SMS oder Voice tatsächlich unverzichtbar bleiben. Wenn ja, muss ab dem 30. Oktober 2026 ein Drittanbieter über den Microsoft Security Store konfiguriert werden. Diese Entscheidung sollte auf einer echten Bedarfsanalyse beruhen und nicht darauf, dass die Umstellung schlicht aufgeschoben wird.
Sonderfälle, die den Zeitplan sprengen können
Die breite Belegschaft mit Firmengerät und Smartphone lässt sich vergleichsweise reibungslos auf Passkeys umstellen. Anspruchsvoller sind die Ränder der Organisation — und genau dort scheitern Migrationen erfahrungsgemäß, wenn sie nicht früh eingeplant werden. Frontline- und Schichtarbeitende ohne persönliches Endgerät, geteilte Arbeitsplätze in Produktion oder Lager, Kioskszenarien sowie externe Gäste und Partner in B2B-Kollaborationen passen nicht ohne Weiteres in ein Modell, das Biometrie auf einem persönlichen Gerät voraussetzt.
Für geteilte Geräte und Umgebungen ohne persönliches Smartphone sind FIDO2-Sicherheitsschlüssel meist die tragfähigste Lösung: Ein physischer Schlüssel ist personengebunden, aber geräteunabhängig und funktioniert auch an einem Arbeitsplatz, den mehrere Personen nacheinander nutzen. Das erfordert allerdings Beschaffung, Ausgabe und einen Prozess für Verlust und Ersatz — Aufgaben, die Vorlauf brauchen. Für Gastkonten und B2B-Zugriffe lohnt der Blick auf die Cross-Tenant-Access-Einstellungen, über die sich definieren lässt, welche Authentifizierungsanforderungen an externe Identitäten gestellt werden.
Ebenso zu klären sind Alt-Anwendungen und Automatisierungen, die auf Authentifizierungsmuster setzen, die mit Passkeys nicht kompatibel sind. Servicekonten gehören ohnehin nicht in ein interaktives MFA-Modell, sondern sollten über verwaltete Identitäten oder zertifikatsbasierte Verfahren abgesichert werden. Wer diese Sonderfälle erst im Januar 2027 entdeckt, gerät unter Zeitdruck — wer sie jetzt inventarisiert, kann sie geordnet abarbeiten.
Break-Glass-Konten nicht vergessen
Ein Punkt, der bei jeder Änderung an Authentifizierungsmethoden mitgedacht werden muss, sind die Notfallzugänge. Break-Glass-Konten — die cloud-only-Administratorkonten, die einen Tenant-Lockout verhindern — dürfen nicht von einer Methode abhängen, die abgeschaltet wird. Wenn ein Notfallkonto ausschließlich per SMS abgesichert ist, wird aus der Lebensversicherung des Tenants zum 1. Februar 2027 ein Ausfallrisiko.
Break-Glass-Konten sollten ohnehin über FIDO2-Sicherheitsschlüssel abgesichert sein, getrennt von den Methoden regulärer Administratoren. Die aktuelle Umstellung ist ein guter Anlass, das zu verifizieren — und den Notfallzugang einmal vollständig durchzutesten, statt nur seine Existenz zu bestätigen. Wie Break-Glass-Konten, Conditional-Access-Baseline und Token-Schutz zusammenspielen, beschreiben wir ausführlich im Beitrag zur Entra-ID-Resilienz.
Passkeys sind ein Baustein, kein Endpunkt
Die Umstellung auf Passkeys schließt eine der ältesten Lücken der Cloud-Authentifizierung — den phishbaren zweiten Faktor. Sie ersetzt aber keine durchdachte Zugriffsarchitektur. Passkeys schützen den Anmeldevorgang; sie schützen nicht vor gestohlenen Sitzungs-Tokens, überzogenen App-Berechtigungen oder fehlender Conditional-Access-Baseline. Phishing-resistente Anmeldung entfaltet ihre volle Wirkung erst als Teil einer Zero-Trust-Strategie, in der jede Anmeldung anhand von Kontext, Gerätestatus und Risiko bewertet wird.
Für die meisten Unternehmen ist die konkrete Aufgabe der nächsten Monate damit klar umrissen: den Bestand an SMS- und Voice-Nutzern erheben, eine bewusste Passkey-Strategie festlegen, Registrierungskampagnen kontrolliert ausrollen und die Notfallzugänge absichern — alles vor dem 1. September 2026, damit die automatische Umstellung auf vorbereitete Strukturen trifft statt auf Improvisation.
Klarheit über Ihre Identitäts- und Zugriffsarchitektur, bevor die Stichtage greifen. Ein Cloud Security Assessment analysiert Ihre Entra-ID-Konfiguration — Authentifizierungsmethoden, Conditional-Access-Policies, privilegierte Rollen und Notfallzugänge — und liefert einen priorisierten Härtungsplan für die Umstellung auf phishing-resistente Anmeldung. Sprechen Sie mit uns über Ihre Entra-ID-Absicherung.