Entra ID Passwordless MFA Registrierung: Was Microsoft vereinfacht hat und warum es für den Rollout wichtig ist

Entra ID Passwordless MFA Registrierung, erklärt

Jahrelang hat Microsoft Entra ID neue Nutzer durch einen Onboarding-Pfad nach dem Prinzip „schwächste Methode zuerst" geführt: Bevor Sie einen Passkey, einen FIDO2-Sicherheitsschlüssel, Windows Hello for Business, macOS Platform SSO oder die passwortlose Anmeldung über Microsoft Authenticator registrieren konnten, mussten Sie zunächst eine Basis-MFA-Methode einrichten — meist SMS oder Sprachanruf. Diese Reihenfolge machte phishing-anfällige, SIM-Swapping-verwundbare Methoden zum Standardeinstieg in jede neue Identität, selbst in Tenants, die überall Passkeys wollten. Diese Entra ID Passwordless MFA Registrierung, die Microsoft jetzt ausrollt, hebt diese Anforderung auf.

Laut Microsoft-365-Message-Center-Tracking (MC1450133, zusammengefasst von PUPUWEB und OurCloudNetwork, und diese Woche in der Community-Diskussion auf r/AZURE und r/entra aufgegriffen) können berechtigte Nutzer künftig einen synchronisierten Passkey, einen Microsoft-Entra-Passkey unter Windows oder einen FIDO2-Sicherheitsschlüssel als allererste Authentifizierungsmethode registrieren — ganz ohne SMS- oder Anruf-Umweg.

Laut denselben Tracking-Quellen erfolgt der Rollout in Phasen:

• Phase 1 — synchronisierte Passkeys, Microsoft-Entra-Passkeys unter Windows und FIDO2-Sicherheitsschlüssel — startet weltweit und in GCC-Tenants Mitte Oktober 2026, der Abschluss wird für Mitte November 2026 erwartet.
• Phase 2 — Erweiterung der Passwordless-Erstfaktor-Registrierung auf Windows Hello for Business, macOS Platform SSO und die passwortlose Telefonanmeldung über Microsoft Authenticator — folgt danach.

Administratoren verlieren dabei nicht die Kontrolle: Die bestehende Authentifizierungsmethoden-Richtlinie und Conditional Access bestimmen weiterhin, welche Methoden tatsächlich verfügbar sind und für wen. Die Änderung senkt die Registrierungshürde, sie aktiviert Passkeys aber nicht stillschweigend für Tenants, die die Methode nicht eingeschaltet haben.

So funktioniert es

Passwordless-First-Registrierung nutzt Infrastruktur, die in Entra ID bereits vorhanden ist: die Authentifizierungsmethoden-Richtlinie (welche Authentifizierungsmethoden tenant-weit aktiviert sind, einschließlich FIDO2/Passkey mit „Self-Service-Setup zulassen") und das Registration-Campaign-Feature, das angemeldete Nutzer nach Abschluss der MFA zu einer Zielmethode hin anstößt.

Laut der Registration-Campaign-Dokumentation von Microsoft Learn wird die Kampagne über den Block registrationEnforcement.authenticationMethodsRegistrationCampaign der Authentifizierungsmethoden-Richtlinie konfiguriert (lesbar/schreibbar über Microsoft Graph unter GET/PATCH https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy), mit folgenden Eigenschaften:

Bei Verwendung des Status „Microsoft managed" verschiebt Microsoft das Ziel bereits schrittweise von Authenticator zu fido2 (Passkeys) und setzt das Snooze-Intervall auf 1 Tag — deaktiviert dabei aber auch das Limit „Registrierung nach 3 Snoozes erzwingen", sodass Hinweise häufiger erscheinen, während die erzwungene Registrierung für Tenants ohne explizit gesetzte Werte ausbleibt — gut zu wissen, bevor Sie davon ausgehen, dass Ihr aktuelles Kampagnenziel noch dem entspricht, was Sie vor Monaten konfiguriert haben.

Erkennung: Was Sie in Ihrem Tenant prüfen sollten

Bevor Phase 1 eintrifft, prüfen Sie, was Ihr Tenant tatsächlich zulässt und wer sich tatsächlich registriert:

Remediation: Vorbereitung auf den Rollout

1. Aktivieren Sie die Passkey-Methode (FIDO2) mit Self-Service-Setup, falls noch nicht geschehen — das ist die Voraussetzung dafür, dass Nutzer überhaupt von der Passwordless-First-Registrierung profitieren.
2. Legen Sie jetzt das Ziel Ihrer Registration Campaign fest. Wenn neue Nutzer bei Passkeys statt bei Authenticator-Push landen sollen, setzen Sie targetedAuthenticationMethod explizit auf fido2, statt sich auf Microsoft-managed-Standardwerte zu verlassen, die sich nach Microsofts Zeitplan ändern, nicht nach Ihrem.
3. Überprüfen Sie Conditional Access für „Register security information". Falls die Registrierung nur von verwalteten Geräten oder vertrauenswürdigen Netzwerken aus erfolgen soll, bestätigen Sie, dass diese Richtlinie weiterhin greift, sobald Passwordless zur ersten Anlaufstelle wird und nicht nur ein späteres Upgrade ist — häufige Lücken finden Sie in unserem Leitfaden zu Conditional-Access-Lücken.
4. Testen Sie mit einem Pilotprojekt, bevor Phase 1 in Ihrer Region abgeschlossen ist. Passkey-Hinweise werden pro Geräte-Browser-Kombination ausgewertet, nicht pro Nutzer — testen Sie das Erlebnis über Ihre tatsächliche Geräteflotte hinweg (Windows/Chrome, macOS/Safari, Mobile), statt einheitliches Verhalten anzunehmen.
5. Prüfen Sie MC1450133 näher am Rollout-Fenster direkt in Ihrem Microsoft-365-Admin-Center-Message-Center erneut — Microsofts eigener Zeitplan-Text für Phase 2 ist in sich widersprüchlich, und das Message Center ist die tenant-spezifische Quelle der Wahrheit für Ihre Rollout-Welle.
6. Bleiben Sie nicht bei der Registrierungsreihenfolge stehen. Passwordless-First-Registrierung schließt nur einen Teil der Lücke — welche Conditional-Access- und Security-Defaults-Kontrollen weiterhin nötig sind, erfahren Sie in Warum MFA allein nicht ausreicht.

Wie EtcSec dies erkennt

EtcSec markiert Tenants, in denen Passwordless-Methoden nicht verfügbar oder nicht erzwungen sind, über die Checks MFA_NO_PASSWORDLESS und MFA_NO_FIDO2 (Passkey/FIDO2 nicht aktiviert oder nicht für Self-Service konfiguriert), MFA_NO_STRONG_METHOD (überhaupt keine phishing-resistente Methode konfiguriert), MFA_PHONE_ONLY (Nutzer auf telefonbasierte MFA beschränkt — genau das Muster, von dem diese Microsoft-Änderung wegführen soll) und CA_NO_MFA_REQUIREMENT (keine Conditional-Access-Richtlinie erzwingt überhaupt MFA, was jede Verbesserung der Registrierungsreihenfolge untergräbt).