Windows Hello for Business Standalone MFA-Faktor Entra Oktober 2026: Die zweite Passkey-Pflicht entfällt

Windows Hello for Business standalone MFA-Faktor Entra Oktober 2026: Was Microsoft angekündigt hat

Windows Hello for Business standalone MFA-Faktor Entra Oktober 2026 ist die Änderung, auf die sich Identity-Teams bereits jetzt vorbereiten sollten. Im Message-Center-Beitrag MC1450134, "Microsoft Entra: Windows Hello for Business and macOS Platform SSO as standalone MFA factors" (veröffentlicht am 7. August 2026, aktualisiert am 18. August 2026), erklärt Microsoft, dass Entra "Windows Hello for Business (WHfB) und macOS Platform Single Sign-On (PSSO) in unterstützten Authentifizierungsszenarien als eigenständige Multi-Faktor-Authentifizierung (MFA)-Faktoren erkennen wird".

Das Rollout-Fenster ist konkret benannt. Die allgemeine Verfügbarkeit (General Availability) für Worldwide- und GCC-Mandanten beginnt "Anfang Oktober 2026 und soll Ende November 2026 abgeschlossen sein". Microsoft kennzeichnet den Beitrag mit planForChange bei normaler Schwere ("normal severity") und stellt klar: "Es sind keine Konfigurationsänderungen erforderlich."

Genau dieser letzte Satz verdient einen zweiten Blick. Zwar ist keine Admin-Aktion erforderlich, aber die Authentifizierungslage jedes Mandanten, in dem sich Nutzer per Windows Hello oder an einem Mac anmelden, ändert sich von selbst — einschließlich der Anzahl an Konten, die Entra als MFA-fähig meldet, und der Geräte, von denen aus sich ein Nutzer noch authentifizieren kann, wenn etwas schiefgeht.

Was sich tatsächlich ändert — und was schon funktioniert hat

Windows Hello for Business wird den Authentifizierungsstärken nicht hinzugefügt — es war bereits Teil davon. Microsofts Referenz zu Authentifizierungsstärken führt "Windows Hello for Business or platform credential" als Erfüllung aller drei integrierten Stärken auf: MFA-Stärke, kennwortlose MFA-Stärke und Phishing-resistente MFA-Stärke.

Was bisher nicht zuverlässig funktioniert hat, ist der Re-Authentifizierungs-Pfad. Dieselbe Seite dokumentiert die heutige Einschränkung in Microsofts eigenen Worten:

Genau diese Lücke schließt MC1450134. Laut dem Message-Center-Beitrag gilt nach dem Rollout folgendes Verhalten:

Zwei dieser Zeilen verdienen besondere Betonung. Die Zeile zum MFA-fähigen Status bedeutet, dass sich Ihre Compliance-Kennzahl verschiebt, ohne dass ein einziger Nutzer etwas Neues registriert — wer den Anteil "MFA-fähiger Nutzer" an einen Prüfer oder ein Board meldet, sollte den Wert vor und nach dem Rollout neu ermitteln, um den Sprung erklären zu können. Die Zeile zum Registrierungs-Hinweis bedeutet, dass das Sicherheitsnetz, das bislang Nutzer mit nur einer Methode auffing, stillschweigend wegfällt.

Microsoft dokumentiert auf derselben Seite zu Authentifizierungsstärken zudem ein bekanntes Problem, das in diesem Licht lesenswert ist: Erfordert eine Ressource sowohl eine Authentifizierungsstärke als auch eine Anmeldehäufigkeit, können Nutzer "beide Anforderungen zu zwei unterschiedlichen Zeitpunkten erfüllen" — Microsofts eigenes Beispiel ist ein Nutzer, der sein Windows-Gerät mit Windows Hello for Business entsperrt, um eine einstündige Anmeldehäufigkeit zu erfüllen, während eine 24 Stunden alte Passkey-Anmeldung die Stärkeanforderung erfüllt.

Der Haken: Geräte-gebundene Anmeldeinformationen reisen nicht mit

Microsoft benennt das Risiko selbst im Abschnitt "Action required and recommendations" von MC1450134: "Da WHfB- und macOS-PSSO-Anmeldeinformationen geräte-gebunden sind, können Nutzer MFA-Herausforderungen möglicherweise nicht von Geräten aus abschließen, auf denen diese Anmeldeinformationen nicht verfügbar sind."

Das ist keine Einschränkung im Kleingedruckten — es ist die definierende Eigenschaft beider Anmeldeinformationen:

• Windows Hello for Business wird von Microsoft als "in erster Linie eine geräte-gebundene Anmeldemethode, verknüpft mit Gerätevertrauen" beschrieben, wobei die Anmeldeinformation "ausschließlich an das für die Geräteregistrierung verwendete Arbeits- oder Schulkonto gebunden" ist. Ihr Passkey-Typ wird als geräte-gebunden, nicht synchronisiert, geführt (Microsoft Entra Passkey unter Windows).
• Platform Credential für macOS "stellt einen durch die Secure Enclave hardware-gebundenen kryptografischen Schlüssel bereit", aufgebaut auf der Windows-Hello-for-Business-Technologie (Platform Credential für macOS).

Microsofts Dokumentation zur Registrierungskampagne zeigt bereits, wie eng diese Bindung in der Praxis ist. Der Passkey-Hinweis wird pro Kombination aus Gerät und Browser ausgewertet, und die veröffentlichte Plattformtabelle zeigt, dass eine Windows-Hello-for-Business-Anmeldeinformation den Hinweis nur unter Windows unterdrückt, während eine Mac-Platform-SSO-Anmeldeinformation ihn nur unter macOS unterdrückt. Microsofts eigenes Beispiel: "Hat ein Nutzer eine Windows-Hello-for-Business-Anmeldeinformation und meldet sich unter Windows mit Chrome an, wird der Hinweis unterdrückt. Meldet sich derselbe Nutzer jedoch an einem Mac mit Chrome an, wird er trotzdem aufgefordert, da diese Anmeldeinformation für diese Plattform nicht gilt." Dieselbe Seite merkt an, dass Linux-Nutzer nie einen Hinweis erhalten, da FIDO2-Passkeys unter Linux nicht verfügbar sind.

Setzt man die Teile zusammen, wird die Angriffsfläche konkret. Ab Oktober zählt ein Nutzer, dessen einzige registrierte MFA-Anmeldeinformation eine Windows-Hello-for-Business-Anmeldeinformation ist, als MFA-fähig, wird nicht mehr aufgefordert, etwas Portables zu registrieren — und kann dennoch keine MFA-Herausforderung von einem privaten Smartphone, einem Leihgerät, einem Mac oder einer Linux-Workstation aus abschließen. Ein defekter Laptop, ein neu aufgesetztes Gerät, ein Reisetag, eine Incident-Response von einem fremden Rechner aus — all das wird statt zu einer Zweitfaktor-Abfrage zu einem Helpdesk-Anruf. Dieses Risiko trifft ausgerechnet die Konten am härtesten, deren Aussperrung Sie sich am wenigsten leisten können — weshalb Notfallzugangskonten niemals von einer an ein einzelnes Gerät gebundenen Anmeldeinformation abhängen sollten.

Das läuft zudem parallel zur Abschaffung von SMS- und Sprach-MFA und zur Änderung der kennwortlosen MFA-Registrierung: Die portablen Fallback-Optionen, auf die sich viele Mandanten noch verlassen, werden genau zu dem Zeitpunkt entfernt, zu dem das System aufhört, Nutzer zur Registrierung eines Ersatzes aufzufordern.

Erkennung: Finden Sie Ihre ausschließlich geräte-gebundenen Nutzer vor Oktober

Alle für eine kennwortlose Methode registrierten Nutzer — FIDO2, Windows Hello for Business oder kennwortlose Telefonanmeldung. Das ist der äußere Ring, nicht die Antwort:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isPasswordlessCapable eq true

Alle Nutzer mit einem geräte-gebundenen FIDO2-Passkey. Beachten Sie, was dies nicht liefert: passKeyDeviceBound ist die Methode für geräte-gebundene Passkeys, nicht Windows Hello for Business oder macOS PSSO — allein damit finden Sie die in diesem Abschnitt gesuchten reinen WHfB-Nutzer nicht:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=methodsRegistered/any(x:x eq 'passKeyDeviceBound')

Microsoft dokumentiert methodsRegistered als mit any/eq filterbar, veröffentlicht aber nicht die vollständige Liste möglicher Werte — raten Sie also nicht bei einem Methodenstring innerhalb von $filter. Ziehen Sie methodsRegistered für jeden Nutzer und filtern Sie lokal — genau das macht der folgende Export — oder lesen Sie die Spalte Methods registered im Portal, wo Windows Hello for Business namentlich aufgeführt wird.

Import-Module Microsoft.Graph.Reports

# Baseline aller registrierten Methoden je Nutzer vor Beginn des Rollouts erfassen.
# Erfordert AuditLog.Read.All (Reports Reader, Security Reader, Security Administrator oder Global Reader).
Get-MgReportAuthenticationMethodUserRegistrationDetail |
  Select-Object UserPrincipalName, IsAdmin, IsMfaCapable, IsPasswordlessCapable,
    @{Name = "Methods"; Expression = { $_.MethodsRegistered -join ";" }} |
  Export-Csv .\entra-mfa-baseline-pre-october-2026.csv -NoTypeInformation

Abhilfe: Was Sie vor Beginn des Rollouts tun sollten

1. Machen Sie eine portable Methode im Onboarding verpflichtend. Dies ist Microsofts eigene erste Empfehlung in MC1450134: "Onboarding-Anleitungen aktualisieren, damit Nutzer mindestens eine portable MFA-Methode registrieren." Eine geräte-gebundene Anmeldeinformation ohne Alternative ist pro Nutzer ein Single Point of Failure.
2. Wählen Sie die portable Methode bewusst aus. Microsoft schlägt "einen synchronisierten Passkey oder Microsoft-Authenticator-Passkey zusätzlich zu WHfB oder macOS PSSO" vor. Beachten Sie den von Microsoft dokumentierten Kompromiss: "Synchronisierte Passkeys unterstützen keine Attestation" — ein Profil mit Enforce attestation auf Yes schließt sie daher bei der Registrierung aus. Microsofts eigenes Beispiel für hochprivilegierte Konten kombiniert erzwungene Attestation mit ausschließlich geräte-gebundenen Passkeys (Passkeys (FIDO2) aktivieren). Entscheiden Sie, welche dieser beiden Eigenschaften Sie tatsächlich benötigen, bevor Sie die Anleitung veröffentlichen.
3. Prüfen Sie benutzerdefinierte Authentication Strengths. MC1450134 fordert Sie auf, "benutzerdefinierte Authentication-Strength-Richtlinien zu überprüfen, um zu bestätigen, dass WHfB und macOS PSSO dort zugelassen sind, wo es angemessen ist". Die drei integrierten Stärken enthalten "Windows Hello for Business or platform credential" bereits — es sind die selbst geschriebenen benutzerdefinierten Stärken, die sich jetzt anders verhalten könnten als angenommen.
4. Prüfen Sie AAGUID-Zulassungslisten in Ihrem Passkey-Profil, bevor Sie Nutzer zur Registrierung auffordern. Falls Sie Schlüsseleinschränkungen nutzen, dokumentiert Microsoft, dass die AAGUID 7FD635B3-2EF9-4542-8D9D-164F2C771EFC der macOS Platform Credential für WebAuthn-Herausforderungen in der Zulassungsliste stehen muss. Für Windows-Hello-Passkeys sind die dokumentierten AAGUIDs 08987058-cadc-4b81-b6e1-30de50dcbe96 (Hardware-TPM), 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (VBS-Hardware) und 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (Software-TPM) — und Microsoft weist darauf hin, dass ein auf diese ausgerichtetes Profil keine Attestation erzwingen kann.
5. Sichern Sie zuerst die Break-Glass-Konten. Notfallzugangskonten müssen von einem Gerät aus erreichbar sein, das nicht das ausgefallene ist. Stellen Sie sicher, dass sie eine portable Anmeldeinformation besitzen und weiterhin von den Richtlinien ausgeschlossen sind, die sie sonst aussperren würden.
6. Ermitteln Sie die MFA-fähig-Kennzahl neu und informieren Sie deren Empfänger. Die Zahl verschiebt sich, weil sich die Definition geändert hat — nicht weil die Abdeckung besser wurde. Vergleichen Sie Ihre Vor-Rollout-CSV mit der nach dem Rollout, statt die neue Zahl als Fortschritt zu melden.
7. Testen Sie im Report-only-Modus. Conditional-Access-Richtlinienänderungen, die Sie als Reaktion hierauf vornehmen, sollten anhand echten Datenverkehrs validiert werden, bevor sie erzwungen werden — dieselbe Disziplin, die die Lücken in der Baseline-Richtlinienabdeckung aufdeckt, die die meisten Mandanten mit sich tragen.
8. Aktualisieren Sie die Helpdesk-Dokumentation. Die letzte Empfehlung aus MC1450134 ist eindeutig: Nutzer mit ausschließlich WHfB oder macOS PSSO "werden nicht mehr automatisch zur Registrierung einer zusätzlichen MFA-Methode angeleitet" — die Anleitung muss also von Ihnen kommen. Eine breitere Betrachtung, wo dies in die Mandanten-Hygiene einzuordnen ist, finden Sie in unserem Leitfaden zur Entra-ID-Prüfung.

Wie EtcSec dies erkennt

Die Prüfungen von EtcSec für Conditional Access und privilegierten Zugriff zielen genau auf die Bedingungen, die dieses Rollout von einem Non-Event zu einer Aussperrung machen. CA_NO_MFA_REQUIREMENT kennzeichnet Mandanten ohne Richtlinie, die MFA tatsächlich erzwingt — dort schafft eine sich verschiebende MFA-fähig-Kennzahl trügerische Sicherheit. CA_NO_BREAK_GLASS_EXCLUSION erkennt Notfallzugangskonten ohne dokumentiertes Ausschlussmuster — genau die Konten, die am ehesten durch eine ausschließlich geräte-gebundene Anmeldeinformation ausgesperrt werden. PA_GLOBAL_ADMIN_NOT_MFA deckt privilegierte Konten auf, deren MFA-Durchsetzung nicht standhält. CA_NO_SESSION_CONTROLS findet Mandanten, die sich auf eine Anmeldehäufigkeit verlassen, die WHfB und macOS PSSO künftig während 2FA erfüllen, und CA_POLICY_REPORT_ONLY erkennt Richtlinien, die Sie für diese Änderung getestet, aber nie tatsächlich erzwungen haben.