MFA und SSPR Deepdive Aktivierung, Registrierungsmethoden, erzwungener Rollout durch Microsoft

In fast allen Azure- und M365-Schulungen wird MFA thematisiert, oft als zentrale Komponente des Zero-Trust-Prinzips. Während es kaum Erklärungsbedarf hinsichtlich der grundsätzlichen Funktionsweise und der prinzipiellen Notwendigkeit der Verwendung gibt, ist es nicht einfach zu durchdringen, „wie“ und „wann“ MFA im Umfeld der Microsoft-Cloud-Dienste (Entra ID) durchgesetzt wird, „wo“ die für Nutzer zulässigen Authentifizierungsmethoden konfiguriert werden, warum es „veraltete“ und „moderne“ Methoden gibt und was der im Oktober 2024 von Microsoft gestartete Rollout der MFA-Erzwingung für Admins und Nutzer konkret bedeutet.

Da ich hier schon häufiger über MFA referiert habe, konzentriere ich mich in diesem Beitrag nur auf die in der Einleitung skizzierten Themen. Was MFA ist und wie es funktioniert, habe ich bereits in anderen Artikeln behandelt. Außerdem hilft hier die Microsoft-Dokumentation weiter. Aus meiner eigenen Erfahrung herrscht bei Benutzern aber in folgenden Punkte oft Verwirrung:

• MFA vs. SSPR
• Alte Methoden versus „vereinheitliche“ Methoden
• Migration von „alt“ auf „neu“
• „Wo“ ist „was“ im Azure-Portal vs. Entra-Portal zu finden
• „Wie“ wird MFA aktiviert („Sicherheitsstandards“ vs. „per User“ vs. „CA-erzwungen“)
• „Was“, wenn „sowohl“ CA, „als auch“ Per-User-MFA aktiv sind?
• Für „welche“ Anmeldevorgänge und Security-Prinzipal-Typen macht Microsoft MFA ab 2025 zwingend?
• Was passiert, wenn MFA deaktiviert ist?

Schauen wir ins die Punkte im Einzelnen an:

MFA und SSPR

Der Self-Service-Password-Reset (SSPR) hat zwar technisch gesehen überhaupt nichts mit MFA zu tun, erfordert aber von ihren Benutzern ebenfalls, dass diese in Ihrem Organisationskonto (https://myaccount.microsoft.com) entsprechende Authentifizierungsmethoden einrichten. Welche davon zulässig sind, bzw. als primäre oder sekundäre Methode bei MFA, bzw. vom SSPR akzeptiert werden legen Sie als Admin fest.

Historisch wurde beide Funktionen von Microsoft getrennt behandelt, d. h. für beiden Funktionen standen/stehen unterschiedliche Methoden zur Verfügung, welche die Nutzer jeweils getrennt voneinander registrieren mussten. Das erhöhte sowohl für den Admin, als auch den Nutzer den Aufwand. Mit den „neuen“ vereinheitlichten Verfahren müssen sich Benutzer nur einmal anmelden, um ihre Authentifizierungsmethoden zu registrieren. Diese Registrierung gilt dann sowohl für MFA, als auch für SSPR.

Die Funktion der vereinheitlichten Methoden wurde ursprünglich bereits im Jahr 2019 eingeführt, war aber zunächst optional und musste manuell aktiviert werden. Seitdem wurde sie schrittweise zum Standard für alle Mandanten. Seit Anfang 2025 ist sie für alle Kunden in Azure und Azure Government verfügbar. Die Pfade in den jeweiligen Admin-Centern (Entra Portal oder Azure-Portal) sind Folgende:

Neue, vereinheitlichte Verfahren

Pfad im Azure Portal: Microsoft Entra ID > Sicherheit > Authentifizierungsmethoden > Richtlinie

Pfad im Entra Admin Center: Entra ID > Schutz > Authentifizierungsmethoden

Hier können Sie ihre Methoden für MFS und SSPR gleichzeitig verwalten (aktivieren/deaktivieren), wie  z. B. Microsoft Authenticator App, FIDO2, SMS, OATH, Temporärer Zugriffspass usw. sowie die  Zielgruppen (alle Benutzer oder bestimmte Gruppen) festlegen. Diese neue Richtlinie ersetzt die getrennten Legacy-Richtlinien für MFA und SSPR.

Aber Achtung: Nicht alle Methoden sind für beide Zwecke geeignet: So können Sie z. B. FIDO2 und Windows nur für die Authentifizierung, nicht für SSPR nutzen, während Sicherheitsfragen und  E-Mail nur für SSPR, nicht aber für MFA bereitstehen.

Die moderne Richtlinie erlaubt eine einheitliche Verwaltung und ist zukunftssicher. Sind beide Systeme parallel aktiv hast (was häufig vorkommt), hat die neue Richtlinie Vorrang, wenn sie aktiviert ist. Die alten Einstellungen (z. B. MFA pro Benutzer, SSPR-Methoden) gelten nur, wenn die neue Richtlinie nicht aktiv ist oder für bestimmte Benutzergruppen nicht greift. Das von Microsoft empfohlene Vorgehen (BP) ist Folgendes:

1. Neue Authentifizierungsmethodenrichtlinie aktivieren.
2. Alle gewünschten Methoden dort konfigurieren.
3. CA-Richtlinien nutzen, um MFA-Anforderungen zu steuern.
4. Alte MFA- und SSPR-Richtlinien deaktivieren.
5. Migration im Entra-Portal als „abgeschlossen“ markieren.

Punkt 5 bezieht sich darauf, dass Microsoft einen Migrationsassistenten bereitstellt, um von den alten Richtlinien zur neuen zu wechseln. Assistent ist in dieser Hinsicht vielleicht übertrieben. Letztendlich geben Sie mit einem Klick auf „Ändern“ neben „Migrationsstatus“ gegenüber Microsoft nur, an dass z. B. der Status ihrer „Migration in Bearbeitung“ ist. In diesem Zeitraum weisen Sie ihre Benutzer an, sich ggf. für die neuen vereinheitlichten Methoden zu registrieren, sofern noch nicht geschehen. Sobald alle Nutzer damit durch sind, wechseln Sie auf die Option „Migration abgeschlossen“.

Ist die Migration ihrerseits abgeschlossen, wird das Steuerelement im Portal, mit dem Sie  zwischen alter und neuer Registrierung wechseln, entfernt.

Altes Verfahren für MFA

Pfad im Azure-Portal: Microsoft Entra ID > Benutzer → MFA pro Benutzer → Diensteinstellungen

Pfad im Entra Admin Center: Entra ID > Benutzer → MFA pro Benutzer → Diensteinstellungen

Der Screenshot stammt vom Entra-Portal. Die Einstellung sieht aber im Azure-Portal identisch aus.

Altes Verfahren für SSPR

Pfad im Azure-Portal: Microsoft Entra ID > Zurücksetzen des Kennworts > Authentifizierungsmethoden

Pfad im Entra Admin Center: Entra ID > Zurücksetzen des Kennworts > Authentifizierungsmethoden

Diesmal  ein Screenshot vom Azure-Portal; auch dieser Dialog sind im Entra-Portal gleich aus.

Wenn Sie auch früher schon weitsichtig geplant haben, können Sie den Aufwand gering halten, wenn Sie sich z. B. auch schon bei den alten Methoden auf jene konzentriert hätten, die von beiden Funktionen unterstützt wurden/werden und überdies jene weglassen, die Sie in ihrem Unternehmen mangels Lizenzen oder Aufwand nicht nutzen können oder wollen, wie Hardware-basierenden Methoden. Außerdem könnten Sie Verfahren ausschließen, die nicht Pishing-resistent sind, wie SMS oder Voicemail. Suchen Sie am besten in folgender Tabelle nach dem kleinsten gemeinsamen Nenner:

Ein guter Kompromiss unter Verzicht auf Hardware-Token wäre z. B. die Microsoft Authenticator App, Passkeys und temporärer Zugriffscode. Sie werden allerdings keine sicheren Verfahren finden, die in Kombination sowohl bei den alten, wie den vereinheitlichten Methoden für MFA UND SSPR funktionieren. Sie können aber anstreben, den Aufwand für Ihre Benutzer gering zu halten. Evtl. müssen diese das eine oder andere Verfahren erneut registrieren.

Sie können Ihrer Benutzer auch zwingen, ihre Methoden neu zu registrieren, z. B. über eine Richtlinie oder durch die skizzierten Änderungen an den Authentifizierungsmethoden.

Der Vorteil der kombinierten Registrierung überwiegt allerdings sowohl für Benutzer, als auch bei Administratoren:

• Bessere Benutzererfahrung (nur ein Setup)
• Konsistente Sicherheitsrichtlinien
• Weniger Helpdesk-Anfragen bei Passwortproblemen
• Einfachere Verwaltung für Admins

Ihre Nutzer müssen also nicht aktiv werden, wenn Sie bereits vor der Migration ihre Methoden in Ihrer Kontoverwaltung in https://myaccount.microsoft.com eingerichtet haben und die gewählten Methoden  auch in der neuen Richtlinie erlaubt sind. Wenn Sie allerdings in der neuen Richtlinie bestimmte Methoden nicht mehr erlauben (z. B. SMS oder Anruf) oder ihre Benutzer bisher nur Methoden verwendet haben, die Sie  künftig ausschließen möchten, müssen Benutzer ihre Benutzer diese auf jeden Fall neu einrichten.

Wie wird MFA aktiviert (Sicherheitsstandards vs. per User)

Kommen wir zu der Frage, wie man MFA aktiviert. Im Grunde gibt es hier Fälle zu unterscheiden;

1. MFA deaktiviert (keine wirkliche Option), zumal Microsoft die MFA-Erzwingung seit Oktober 2024, über zwei Phasen verpflichtend ausrollt, beginnend mit der interaktiven Anmeldung am Azure-/Entra-Portal und am Intune-Portal.
2. Sicherheitsstandard aktiviert
3. MFA per User
4. MFA granular durch eine Conditional-Access-Policy erzwungen (erfordert P1/P2-Lizenz)

Für alle Mandanten, die seit dem 22.10.2019 erstellt wurden, aktiviert Microsoft automatisch die so genannten Sicherheitsstandards.

Sicherheitsstandards

Die Sicherheitsstandards umfassen:

• Multi-Faktor-Authentifizierung (MFA)
  • Alle Benutzer müssen sich für MFA registrieren.
  • Administratoren müssen MFA verwenden.
  • Benutzer müssen MFA durchführen, wenn es erforderlich ist (z. B. bei riskanten Anmeldungen).
• Blockieren von Legacy-Authentifizierung
  • Veraltete Protokolle wie SMTP, IMAP, POP oder Office 2010 werden blockiert.
  • Diese Protokolle unterstützen keine MFA und sind anfällig für Angriffe.
• Schutz privilegierter Aktivitäten
  • Zugriff auf sensible Bereiche wie das Azure-Portal wird besonders geschützt.
  • MFA ist hier zwingend erforderlich.

Sie finden den Schalter zum Deaktivieren der Sicherheitsstandards im Azure Portal unter „Microsoft Entra ID > Eigenschaften“ im Abschnitt „Sicherheitsstandards“ oder im Entra Portal unter Entra ID im Menü Übersicht im Tab „Eigenschaften“:

Wenn Sie die Sicherheitsstands hier deaktivieren und kein User-basiertes MFA (statisch) oder CA-erzwungenes MFA verwenden, gilt „im Prinzip“ folgendes nicht zu tolerierendes Verhalten. In diesem Fall wird bei einer Anmeldeanforderung keine MFA-Anforderung gestellt. Das wiederum bedeutet:

• Benutzer können sich ausschließlich mit Benutzername + Passwort anmelden.
• Es gibt keinen Schutz durch MFA, auch nicht für Administratoren.
• Legacy-Authentifizierung ist erlaubt, sofern nicht separat blockiert.

Dieses Verhalten kollidiert übrigens NICHT mit der oben erwähnten seit Oktober 2024 laufenden schrittweisen MFA-Erzwingung durch Microsoft (dazu unten mehr), denn diese gilt zunächst nur für den Zugriff aus das Azure-Portal, das Microsoft Entra Admin Center und das Microsoft Intune Admin Center. Für alle anderen Anwendungen (z. B. Outlook, Teams, SharePoint, Drittanbieter-Apps) würde tatsächlich keine MFA-Anforderung ergehen, wenn alle drei MFA-Erzwingungsmethoden (Sicherheitsstandards, MFA per Benutzer, CA-Richtlinien) deaktiviert sind.

MFA per User

Das vollständige Deaktivieren ist natürlich trotzdem ein NoGo für die Sicherheit ihres Mandanten. Sofern Sie über keine P2-Lizenzen verfügen, aktivieren Sie das benutzerspezifische MFA. Sie finden die Option sowohl im Azure-Portal, als auch im Entra-Portal im Menü „Benutzer“. Klicken Sie dort auf „MFA pro Benutzer“. Hier können Sie MFA für jeden einzelnen Benutzer gezielt ein- oder ausschalten. Microsoft unterscheid übrigens beim „Status“ zwischen „disabled“, „enabled“ und „enforced“.

Der Unterschied zwischen letzteren beiden Zuständen ist Folgender. Mit „enabled“ ist MFA ist für den Benutzer aktiviert, aber der Benutzer hat sich noch nicht mit seiner bevorzugten Methode registriert (z. B. keine Authenticator-App oder Telefonnummer hinterlegt). Beim nächsten interaktiven Login wird der Benutzer zur Registrierung aufgefordert, d. h. MFA wird noch nicht erzwungen, bis die Registrierung abgeschlossen ist.

„Enforced“ hingegen bedeutet, dass sich der Benutzer bereits registriert hat. Ab jetzt wird MFA bei jeder Anmeldung verpflichtend abgefragt, je nach Anwendung und Kontext und der betreffende Benutzer kann sich nicht mehr ohne MFA anmelden.

Trotzdem sei eine Warnung angebracht: Diese klassische Methode gilt als veraltet und wird von Microsoft nicht mehr empfohlen. Nutzer sollten MFA stattdessen über Conditional Access (CA) oder die Sicherheitsstandards steuern.

MFA und Conditional Access

Wenden wir uns also der von Microsoft favorisierten MFA-Erzwingungs-Methode mittels Conditional Access Richtlinien (bedingter Zugriff) zu. Hierzu ist eine Entra ID P1-Lizenz (P2 bei Kombination risikobasierten Richtlinien) erforderlich. Ich möchte hier nicht noch einmal das Thema Conditional Access komplett aufmachen, denn hierzu habe ich schon mehrere Beiträge verfasst.

Wichtig ist mir nur einzuordnen, dass bedingter Zugriff selbstverständlich nicht in erster Linie ein Werkzeug zur MFA-Erzwingung ist, sondern ein Tool zum Implementieren von Richtlinien ist, die dafür sorgen, dass Zugriffs- oder Block-Entscheidungen auf Cloud-Apps (darunter z. B. auch das Azure-Portal, dazu gehören aber auch Dinge wie das O365-Portal oder Dienstprinzipale wie z. B. Azure Virtual Desktop oder Microsoft Remote Desktop) von verschiedenen (kombinierbaren) Bedingungen abhängig gemacht werden können.

Bedingungen umfassen z. B. Risikobewertungen, Netzwerkstandorte, Client-Plattformen oder Client-Apps u.v.m.. Solche CA-Richtlinien lassen sich dann gezielt Benutzern oder Gruppen zuweisen. Das Erzwingen von MFA z. B. für alle Benutzer und bestimmten (granular steuerbaren) Bedingungen ist also nur „ein“ Use-Case unter vielen von Conditional Access.

Seit Microsoft Vorlagen für gängige MFA-Szenarien mitliefert wie z. B. „Multi-Faktor-Authentifizierung für alle Benutzer erfordern“ ist die Implementation ein Kinderspiel. Sie finden die Vorlagen z. B. im Entra Admin Center unter „Entra ID > Bedingter Zugriff > Übersicht > Neue Richtlinie aus Vorlage erstellen“.

Wenn Sie also MFA in ihrem Mandanten durch Richtlinien für den bedingten Zugriff steuern, regelt die CA-Richtlinie „wann“ MFA erforderlich ist, also unter welchen Bedingungen sich ein Benutzer mit MFA anmelden muss. Typische, häufig in den diversen Dokumentationen angeführte Beispiele wären:

• Wenn sich jemand außerhalb Deutschlands anmeldet.
• Wenn ein Benutzer auf eine sensible App zugreift (z. B. Exchange Online).
• Wenn das Gerät (in Intune) nicht compliant ist.
• Wenn die Anmeldung risikobehaftet ist (z. B. ungewöhnlicher Standort).

Diese Beispiele sind aus meiner Sicht allerdings häufig nicht mehr zeitgemäß. Ich würde MFA mittels CA für alle Benutzer erzwingen und darüber hinaus mittels CA jeden Anmeldeversucht blockieren, der z. B. aus Ländern kommt, von denen ich sicher weiß, dass meine Mitarbeiter dort nicht tätig sind. Man könnte allenfalls auf MFA verzichten, wenn Intune das Gerät, von dem die Anmeldung kommt, als compliant einstuft. Darüber hinaus würde ich immer den Identitätsschutz in die Zugriffsentscheidung einbeziehen und vor allem Legacy-Protokoll blockieren. Im Einzelfall müssen Sie  dann ggf. noch klären, wie Sie mit einen Drucker mit „Scan-to-E-Mail-Funktion“ umgehen. Für diesen dürfte es schwierig sein, den MFA-Workflow umzusetzen.

Jetzt fragen Sie sich möglicherweise was passiert, wenn MFA-per-User und MFA-per-CA gleichzeitig aktiv sind? Nur dieser Fall einer „Doppel-Aktivierung“ ist relevant, denn solange die Sicherheitsstandards aktiv sind gelten diese ohne Ausnahme für alle Benutzer, auch wenn Sie einzelnen Benutzer in „MFA per Nutzer“ deaktivieren. Sind Sicherheitsstandards UND MFA-per-User deaktiviert, ergeht keine MFA-Anforderung, außer Sie nutzen Conditional-Access-Richtlinien. Letztere haben immer Vorrang. In diesem Fall wird MFA nur ausgelöst, wenn Ihre CA-Richtlinie es verlangt, weil CA-Richtlinien wie erwähnt kontextabhängig (z. B. nur bei bestimmten Apps, Standorten, Risiken etc.) arbeiten.

Es hindert Sie aber auf der anderes Seite niemand, MFA per CA-Richtlinie für einen bestimmten Benutzerkreis zu aktivieren (Sicherheitsgruppe) und zusätzliche MFA für ausgewählte „andere“ Nutzer via Per-User-MFA zu aktivieren. Letztere ist dann eine globale Konfiguration für das betreffende Benutzerkonto, d. h. sie greift bei jeder Anmeldung, sofern keine CA-Richtlinie etwas anderes erzwingt oder blockiert.

Wichtig hierbei: MFA-per-User hat Vorrang, wenn keine CA-Richtlinie greift. Wenn beide aktiv sind, kann es zu doppelten MFA-Aufforderungen oder unerwartetem Verhalten kommen. Microsoft empfiehlt daher, „nicht“ beide Methoden gleichzeitig zu verwenden, sondern vollständig auf CA-basierte MFA umzusteigen.

Abschließend noch ein paar Worte zu erwähnten MFA-Erzwingung durch Microsoft. Diese wird in zwei Phasen ausgerollt.