Consulting Briefing

06.06.2026 · boddenberg.de

Microsoft Entra ID: Passwort-Reset ab September mit neuen Sicherheitsregeln

Executive Summary

Microsoft dreht zum 7. September 2026 an einer Schraube, die in den meisten Unternehmen seit Jahren niemand mehr angefasst hat: dem Self-Service Password Reset (SSPR) in Entra ID. Die Mitteilung trägt den unscheinbaren Namen MC1325414 und liest sich harmlos. Ist sie aber nicht. Ab dem Stichtag akzeptiert Entra ID für die Passwortrücksetzung nur noch Authentifizierungsmethoden, die ein Nutzer ausdrücklich registriert hat — also bewusst hinterlegt und bestätigt. Telefonnummern und alternative E-Mail-Adressen, die nur als Verzeichnisattribut im Profil stehen (weil sie irgendwann mal aus dem HR-System synchronisiert wurden), zählen dann nicht mehr als Identitätsnachweis.

Die gute Nachricht zuerst: Laut Microsoft nutzen bereits rund 86 Prozent aller SSPR-Verifizierungen registrierte Methoden. Für die ändert sich genau nichts. Die schlechte Nachricht: Die restlichen 14 Prozent sind statistisch gesehen genau die Leute, die ihr Passwort am Freitagnachmittag vergessen — und ab dem 8. September keinen Self-Service mehr haben, sondern deinen Helpdesk. Diese Umstellung ist Teil von Microsofts Secure Future Initiative (SFI) und damit kein Vorschlag, über den man verhandeln kann, sondern ein Termin im Kalender.

Abbildung 1: Der Zeitplan von der Registrierungskampagne bis zur Scharfschaltung.

Worum geht es im Detail?

Um zu verstehen, warum diese Änderung überhaupt nötig ist, musst du wissen, wie SSPR bisher tickt. Beim Self-Service Password Reset kann ein Nutzer, der sein Passwort vergessen hat, sich über einen zweiten Kanal ausweisen — ein Code per SMS, ein Anruf, eine Bestätigung in der Authenticator-App. Klingt sauber. Der Haken steckt in der Frage, woher Entra ID die Kontaktdaten für diesen zweiten Kanal nimmt.

Bisher durfte SSPR in vielen Konfigurationen auf simple Verzeichnisattribute zurückgreifen: das Feld mobilePhone, businessPhone oder otherMails im Benutzerobjekt. Diese Felder füllen sich oft ganz von allein — durch HR-Synchronisation, durch ein altes Onboarding-Skript, durch einen Admin, der vor fünf Jahren mal eine CSV-Datei importiert hat. Niemand hat dabei geprüft, ob die Nummer noch stimmt. Und genau das ist das Problem: Ein Verzeichnisattribut ist eine Behauptung, keine bestätigte Tatsache. Wenn ein Angreifer es schafft, dieses Feld zu manipulieren — etwa über ein schlecht abgesichertes Self-Service-Profil oder einen kompromittierten HR-Konnektor —, dann hat er sich gerade selbst einen Reset-Kanal eingerichtet. Das Konto gehört dann praktisch ihm.

Eine registrierte Authentifizierungsmethode ist etwas anderes. Hier hat der Nutzer aktiv bestätigt: „Ja, das ist meine Nummer, das ist meine App.“ Der Eintrag landet im authenticationMethods-Bereich, nicht in einem beliebig befüllbaren Profilfeld. Genau diesen Unterschied macht Microsoft ab September zur harten Bedingung. Verzeichnis-Attribute als alleiniger Nachweis sind dann tot. Die Telefonnummer als solche bleibt erlaubt — aber nur, wenn sie als Methode registriert und damit bestätigt wurde.

Ein konkretes Beispiel aus der Praxis: Bei einem mittelständischen Maschinenbauer hatten wir genau diese Konstellation. Das HR-System hatte über Jahre brav die privaten Handynummern in das Feld mobilePhone geschrieben — als Notfallkontakt, nicht als Sicherheitsmerkmal. SSPR war so konfiguriert, dass diese Nummer als Reset-Kanal genügte. Niemand hatte ein schlechtes Gefühl dabei, bis ein Pentest zeigte, dass ein Sachbearbeiter im HR-Tool diese Nummern ändern durfte. Übersetzt: Eine einzige Person mit einem völlig legitimen Job konnte theoretisch den Reset-Kanal jedes Mitarbeiters umbiegen. Das ist exakt das Loch, das Microsoft jetzt für alle zumauert — ob es dir gefällt oder nicht.

Abbildung 2: Was vor und nach dem Stichtag noch als Identitätsnachweis akzeptiert wird.

Der Zeitplan ist klar getaktet. Am 6. Juli 2026 startet Microsoft eine Registrierungskampagne: Betroffene Nutzer werden beim Anmelden mit einem Hinweis begrüßt, der sie auffordert, eine Methode zu hinterlegen. Diese Kampagne kannst du als Admin in Frequenz und Dringlichkeit steuern — du musst sie aber auch erlauben. Spätestens zum 6. September solltest du durch sein, denn am 7. September geht die Durchsetzung scharf. Wichtig: Die alten getrennten MFA- und SSPR-Richtlinien sind ohnehin Geschichte; Microsoft hat die Verwaltung bereits zum 30. September 2025 in die einheitliche Authentication-Methods-Policy migriert. Wer das verschlafen hat, stolpert hier gleich über zwei Baustellen auf einmal.

Was sind Chancen? Was sind Risiken?

Fangen wir mit den Chancen an, denn die gibt es wirklich — auch wenn sich die Umstellung erstmal nach Mehrarbeit anfühlt. Du schließt mit einem Schlag einen der beliebtesten Angriffsvektoren auf Konten: den Reset über manipulierbare Kontaktdaten. Account-Takeover über einen entführten Reset-Kanal ist kein theoretisches Szenario, sondern Alltag in jedem Incident-Report. Wer registrierte Methoden erzwingt, hebt das Sicherheitsniveau seiner kompletten Identitätsbasis an, ohne ein einziges neues Produkt zu kaufen. Nebenbei bekommst du saubere Registrierungsdaten — du weißt endlich, welche Nutzer überhaupt eine funktionierende zweite Methode haben. Das ist Gold wert, wenn du später Conditional Access oder passwortlose Anmeldung ausrollen willst.

Jetzt zu den Risiken, und hier wird es konkret. Das größte Risiko ist nicht technischer, sondern organisatorischer Natur: Wenn du am 7. September aufwachst und nichts getan hast, verwandelt sich dein Self-Service in einen Self-Service-mit-Ausnahmen — und die Ausnahmen landen alle bei deinem Helpdesk. Stell dir den Montagmorgen nach einem langen Wochenende vor: Ein Teil der Rückkehrer hat das Passwort vergessen, kann es aber nicht mehr selbst zurücksetzen, weil ihre einzige hinterlegte „Methode“ eine Handynummer aus dem Verzeichnis war. Dein Telefon klingelt durch.

Ein zweites, leiseres Risiko ist die falsche Sicherheit. Manche Organisationen denken: „Wir haben doch MFA, uns betrifft das nicht.“ Das ist ein Trugschluss. MFA schützt die Anmeldung, SSPR schützt den Reset — das sind zwei verschiedene Türen. Es ist durchaus möglich, dass ein Nutzer eine saubere Authenticator-App für die Anmeldung hat, sein SSPR aber historisch auf der Verzeichnis-Telefonnummer fußt. Verlass dich nicht auf Bauchgefühl, sondern auf den Registrierungsbericht.

Und dann ist da noch das Risiko, das gern unterschätzt wird: der Helpdesk als neue Schwachstelle. Wenn nach dem Stichtag plötzlich mehr Leute beim Support anrufen, weil der Self-Service für sie tot ist, steigt der Druck auf die Mitarbeiter, schnell zu helfen. Schnell helfen heißt im Zweifel: weniger genau hinhören, wer da eigentlich anruft. Genau das ist die Spielwiese für Social Engineering — der Anrufer gibt sich als gestresster Vertriebskollege aus, der „in zehn Minuten ins Kundenmeeting muss“, und schon sitzt der freundliche Helpdesk-Mitarbeiter in der Falle. Die Verschärfung verschiebt das Risiko also teilweise nur, statt es aufzulösen — es sei denn, du härtest deinen manuellen Prozess gleich mit.

Abbildung 3: Die 86/14-Frage — die Minderheit verursacht die gesamte Arbeit.

Was müssen wir jetzt schon vorbereiten?

Die Vorbereitung zerfällt in drei Blöcke: messen, erzwingen, absichern. Verschwende keine Zeit mit Diskussionen, ob das alles nötig ist — der Termin steht, also arbeite ihn ab.

Erstens: messen. Geh ins Entra Admin Center und zieh dir den Bericht zur Registrierung von Authentifizierungsmethoden (Authentication methods activity bzw. Registration details). Du willst genau eine Liste: alle Nutzer, die keine registrierte Methode haben oder deren SSPR ausschließlich auf Verzeichnisattributen beruht. Wenn du es skripten willst, hol dir die Daten über Microsoft Graph (reportRoot / userRegistrationDetails). Diese Liste ist deine To-do-Liste — nicht das Bauchgefühl des IT-Leiters.

Zweitens: erzwingen. Aktiviere die SSPR-Registrierungskampagne, damit Entra ID die betroffenen Nutzer beim Login automatisch zur Hinterlegung einer Methode stupst — idealerweise deutlich vor dem 6. Juli, damit du den Anlauf nicht Microsoft überlässt. Stell sicher, dass deine Authentication-Methods-Policy die gewünschten Methoden überhaupt erlaubt (Authenticator-App, FIDO2/Passkey, registrierte Telefonnummer). Wer es ernst meint, koppelt die Registrierung über Conditional Access an eine „Registration“-Policy, sodass die Hinterlegung nicht nur ein freundlicher Vorschlag, sondern eine Bedingung wird.

Ein praktischer Stolperstein, den ich immer wieder sehe: Die Registrierungskampagne stupst zwar an, aber sie zwingt nicht. Ein routinierter Anwender klickt den freundlichen Hinweis genauso routiniert weg wie das Cookie-Banner. Genau deshalb ist die Kombination aus Kampagne und Conditional-Access-Pflicht so wirkungsvoll: Die Kampagne macht es bequem, der Conditional-Access-Zwang macht es unausweichlich. Wer nur auf die Kampagne setzt, wird im August feststellen, dass die letzten 14 Prozent exakt die Leute sind, die sich von einem Pop-up noch nie haben beeindrucken lassen. Plane dafür einen Puffer ein und kommuniziere die Deadline so, dass sie auch beim Außendienst und in der Produktion ankommt — also nicht nur per E-Mail an Leute, die gerade kein Postfach offen haben.

Drittens: absichern. Bereite deinen Helpdesk darauf vor, dass es Nutzer geben wird, die es trotz aller Kampagnen nicht geschafft haben. Definiere einen sicheren, identitätsgeprüften Prozess für den manuellen Reset durch den Helpdesk — und zwar einen, der nicht selbst zur Hintertür wird. Ein Helpdesk, der auf Zuruf Passwörter zurücksetzt, ist der gleiche Angriffsvektor in Grün. Nutze die Gelegenheit, gleich einen ordentlichen Verifizierungsprozess einzuführen. Und kommuniziere früh und mehrfach an die Endnutzer: ein Satz im Intranet reicht nicht, die Leute klicken Sicherheitshinweise routiniert weg.

Unterm Strich: Diese Umstellung ist kein Drama, wenn du jetzt anfängst. Sie wird zum Drama, wenn du sie für eine dieser Microsoft-Ankündigungen hältst, die sich von selbst erledigen. Tut sie nicht. Am 7. September steht sie vor der Tür, unabhängig davon, ob dein Helpdesk vorbereitet ist.

Häufig gestellte Fragen

Was passiert genau am 7. September 2026 mit dem Self-Service Password Reset?

Ab diesem Tag akzeptiert Entra ID für die Passwortrücksetzung nur noch Authentifizierungsmethoden, die der Nutzer ausdrücklich registriert hat. Kontaktdaten, die nur als Verzeichnisattribut (mobilePhone, businessPhone, otherMails) existieren, zählen dann nicht mehr als Identitätsnachweis.

Mein Unternehmen nutzt bereits MFA — sind wir damit automatisch sicher?

Nein, nicht zwangsläufig. MFA schützt die Anmeldung, SSPR den Passwort-Reset — das sind getrennte Mechanismen. Ein Nutzer kann eine registrierte Authenticator-App für die Anmeldung haben, während sein SSPR historisch auf einer Verzeichnis-Telefonnummer beruht. Prüfe deshalb den Registrierungsbericht, statt dich auf MFA zu verlassen.

Wie finde ich heraus, welche Nutzer betroffen sind?

Über den Bericht zur Registrierung von Authentifizierungsmethoden im Entra Admin Center oder per Microsoft Graph (userRegistrationDetails). Du suchst alle Konten ohne registrierte Methode beziehungsweise solche, deren Nachweis ausschließlich auf Verzeichnisattributen beruht.

Was passiert mit einem Nutzer, der nach dem Stichtag keine registrierte Methode hat?

Er kann sein Passwort nicht mehr selbst zurücksetzen und muss entweder zuerst eine Methode hinzufügen oder sich an den Helpdesk wenden. Genau deshalb solltest du den manuellen Reset-Prozess vorab sauber und identitätsgeprüft definieren.

Müssen wir dafür neue Lizenzen kaufen?

Nein. Es handelt sich um eine Verschärfung bestehender SSPR-Regeln im Rahmen der Secure Future Initiative, nicht um ein neues Produkt. Der Aufwand liegt in Konfiguration, Registrierungskampagne und Kommunikation — nicht im Einkauf.

Quellen: borncity.com/blog/2026/05/31/microsoft-entra-id-passwort-reset-ab-september-mit-neuen-sicherheitsregeln/ mc.merill.net/message/MC1325414 techzine.eu/news/security/141721/microsoft-is-tightening-password-reset-security-in-entra-id/ learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage