Bedingter Zugriff Sicherheitsinformationen Registrieren Windows Hello macOS Platform SSO: Geltungsbereich geändert (13. Juli 2026)

Bedingter Zugriff Sicherheitsinformationen Registrieren Windows Hello macOS Platform SSO: Was sich geändert hat

Bedingter Zugriff Sicherheitsinformationen Registrieren Windows Hello macOS Platform SSO — das ist der Begriff, den Microsoft-Entra-Admins jetzt kennen müssen. Seit dem 13. Juli 2026 gelten Conditional-Access-Richtlinien, die auf die Benutzeraktion Sicherheitsinformationen registrieren ausgerichtet sind, auch für die Registrierung von Windows Hello for Business (WHfB) und macOS Platform Single Sign-on (SSO) — unabhängig davon, ob das beim ursprünglichen Scoping der Richtlinie so beabsichtigt war. Hat Ihr Tenant diese Benutzeraktion eng gefasst — etwa nur für die kombinierte MFA/SSPR-Registrierungserfahrung —, wird die WHfB- und macOS-Platform-SSO-Registrierung jetzt unerwartet von denselben Grant-Kontrollen blockiert. Hat Ihr Tenant diese Flows bewusst ausgeschlossen, um die Geräteprovisionierung reibungslos zu halten, gilt dieser Ausschluss ebenfalls nicht mehr: Die Flows sind jetzt standardmäßig im Geltungsbereich.

Vor dieser Änderung werteten Windows Hello for Business und macOS Platform SSO Conditional-Access-Richtlinien, die auf Sicherheitsinformationen registrieren ausgerichtet waren, überhaupt nicht aus — selbst wenn eine Richtlinie existierte und diese Benutzeraktion adressierte, wurde sie bei der WHfB-/Platform-SSO-Registrierung schlicht nicht berücksichtigt. Microsofts offizielle Anleitung ist eindeutig, was sich geändert hat und was nicht:

Microsoft hat das Rollout-Fenster und den Wirkungsbereich außerdem im Message-Center-Beitrag MC1326253 bestätigt, „Conditional Access policies now apply to Windows Hello for Business and macOS Platform SSO registration“: Das Rollout begann am 6. Juli 2026 und war am 13. Juli 2026 abgeschlossen; Tenants ohne eine auf Sicherheitsinformationen registrieren ausgerichtete Conditional-Access-Richtlinie sehen keine Änderung — die standardmäßige MFA-Durchsetzung für die Registrierung passwortloser Anmeldeinformationen bleibt unangetastet.

Wie die Durchsetzung funktioniert

Der Mechanismus selbst ist nicht neu — es ist dieselbe Benutzeraktion Sicherheitsinformationen registrieren, die seit Jahren die kombinierte MFA/SSPR-Registrierungserfahrung steuert. Neu ist, dass die Windows-Hello-for-Business-Provisionierung und die macOS-Platform-SSO-Registrierung jetzt über dieselbe Conditional-Access-Auswertung laufen. Konkret muss ein Benutzer, der WHfB- oder macOS-Platform-SSO-Anmeldeinformationen registriert, nach der Durchsetzung die Grant-Kontrollen der passenden Richtlinie erfüllen — Authentication Strength, einen vertrauenswürdigen Standort, eine bestimmte MFA-Methode oder Gerätekonformität —, bevor die Registrierung abgeschlossen wird.

Zwei Details aus Microsofts Anleitung sind für Ihre Planung relevant:

• External Authentication Methods sind derzeit nicht mit Authentication Strength kompatibel als Grant-Kontrolle für diese Benutzeraktion — eine Kompatibilitätslücke, die die umfassendere Einstellung der Custom Controls für External Authentication Methods widerspiegelt, die in Entra bereits läuft. Kombiniert Ihre Richtlinie Sicherheitsinformationen registrieren mit einer Authentication-Strength-Anforderung und Ihr Tenant setzt auf External Authentication Methods, empfiehlt Microsoft stattdessen die Grant-Kontrolle Multi-Faktor-Authentifizierung erforderlich.
• Temporary Access Pass (TAP) erfüllt die Conditional-Access-MFA-Anforderung für die Registrierung — so erwartet Microsoft, dass Admins neue Benutzer ohne Henne-Ei-Problem in WHfB/macOS Platform SSO bootstrappen (ein Benutzer kann eine MFA-/Authentication-Strength-Grant-Kontrolle nicht mit einer Anmeldeinformation erfüllen, die er noch nicht registriert hat). TAP funktioniert nicht für Gastbenutzer.

Wen es trifft

Das ist eine Änderung des Geltungsbereichs, keine neue Richtlinie, die Sie selbst verfassen müssen — genau deshalb ist sie leicht zu übersehen. Zwei Fehlerbilder lohnt es sich gezielt zu prüfen:

1. Enge Richtlinie, neue Reibung. Eine auf Sicherheitsinformationen registrieren skopierte Richtlinie mit Grant: Authentication Strength erforderlich (gebaut, um MFA-/SSPR-Registrierung abzusichern) gilt jetzt auch für WHfB und macOS Platform SSO. Ein neuer Mitarbeiter, der ein verwaltetes Windows-Gerät außerhalb eines vertrauenswürdigen Netzwerks registriert, kann mitten in der Einrichtung blockiert werden, weil er die geforderte Authentication Strength noch nicht erfüllen kann — genau die Lücke, die Temporary Access Pass schließen soll.
2. Bewusster Ausschluss, stillschweigend aufgehoben. Hat Ihr Team die WHfB-/macOS-Platform-SSO-Provisionierung bisher bewusst außerhalb des Conditional-Access-Geltungsbereichs gehalten — etwa um die Zero-Touch-Geräteverteilung nicht zu verlangsamen —, ist dieser Vorbehalt seit dem 13. Juli 2026 aufgehoben. Der Registrierungs-Flow wird jetzt standardmäßig erzwungen; ihn erneut auszuschließen erfordert eine explizite Änderung.

Verwandte Themen: unsere Berichterstattung zur Änderung bei der passwortlosen MFA-Registrierung und der umfassendere Leitfaden zu Lücken beim bedingten Zugriff berühren beide angrenzende Scoping-Entscheidungen, die sich lohnen, im Zuge dieses Rollouts noch einmal zu prüfen.

Erkennung — die Exposition Ihres Tenants auditieren

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2026-07-06T00:00:00Z and createdDateTime le 2026-07-13T23:59:59Z) and conditionalAccessStatus eq 'failure'

Get-MgAuditLogSignIn -Filter "createdDateTime gt 2026-07-06T00:00:00Z" | Select-Object `
  @{Name="User";Expression={$_.UserDisplayName}}, `
  @{Name="ClientApp";Expression={$_.ClientAppUsed}}, `
  @{Name="CA Result";Expression={$_.ConditionalAccessStatus}}, `
  @{Name="FailureReason";Expression={$_.FailureReason}}, `
  @{Name="Device";Expression={$_.DeviceDetail.DeviceDisplayName}}

Remediation — diese Schritte jetzt umsetzen

1. Erfassen Sie jede Richtlinie, die auf Sicherheitsinformationen registrieren skopiert ist, und notieren Sie deren Grant-Kontrollen. Das ist die vollständige Expositionsfläche dieser Änderung — sonst ist nichts an Ihrem Conditional-Access-Regelwerk betroffen.
2. Führen Sie jede Richtlinie erneut im Report-only-Modus aus und prüfen Sie die Policy-Impact-Ergebnisse, bevor Sie annehmen, dass sich am 13. Juli nichts geändert hat.
3. Schließen Sie Break-Glass-Konten (Notfallzugang) sowie Dienstkonten/Service Principals von jeder Richtlinie aus, die auf diese Benutzeraktion zielt — gemäß Microsofts Standardempfehlung; siehe unsere Berichterstattung zu Break-Glass-Konten dazu, warum nicht ausgeschlossene Notfallkonten ein wiederkehrender Befund sind.
4. Stellen Sie einen Temporary Access Pass aus für neue Mitarbeiter und Geräte-Re-Provisionierung, damit die WHfB-/macOS-Platform-SSO-Registrierung nicht am Henne-Ei-Problem der Authentication Strength scheitert. TAP erfüllt die Conditional-Access-MFA-Anforderung für die Registrierung — funktioniert aber nicht für Gastbenutzer.
5. Kombinieren Sie External Authentication Methods nicht mit einer Grant-Kontrolle „Authentication Strength erforderlich“ für diese Benutzeraktion; verwenden Sie stattdessen Multi-Faktor-Authentifizierung erforderlich, gemäß Microsofts expliziter Kompatibilitätswarnung.
6. Aktualisieren Sie die Helpdesk-Dokumentation zu den neuen Authentifizierungsabfragen, die Benutzer mitten in der Einrichtung sehen können — das war Microsofts eigene Empfehlung in MC1326253 und der günstigste Weg, Support-Tickets verwirrter neuer Mitarbeiter zu reduzieren. Unser Entra-ID-Audit-Leitfaden zeigt, wo Conditional-Access-Scope-Reviews in eine umfassendere Tenant-Prüfung passen.

Wie EtcSec das erkennt

EtcSecs Conditional-Access-Checks markieren genau die Fehlkonfigurationen, die dieses Rollout von einem Non-Event zu einem Ausfall machen können: CA_POLICY_REPORT_ONLY erkennt Richtlinien im Report-only-Modus, von denen Admins annehmen, sie würden erzwingen (sodass die Änderung vom 13. Juli getestet, aber nie wirklich aktiviert wurde), CA_NO_BREAK_GLASS_EXCLUSION erkennt Notfallzugangskonten, die nicht von einer Register-Security-Information-Richtlinie ausgeschlossen sind — jetzt ein Lockout-Risiko bei der Registrierung, nicht nur bei der Anmeldung —, und CA_EXCESSIVE_EXCLUSIONS markiert Richtlinien, deren Ausschlusslisten so breit geworden sind, dass die durch dieses Rollout gebrachte Verschärfung des Geltungsbereichs faktisch wirkungslos ist.