Microsoft hat die Browserauthentifizierung für externe Identitätsanbieter in Microsoft Entra ID allgemein verfügbar gemacht. Unternehmen, die Microsoft 365 über WS-Fed oder SAML 2.0 an einen externen Identity Provider anbinden, können damit Passkeys, FIDO2-Sicherheitsschlüssel und bestehende Browser-Sitzungen auch für unterstützte Microsoft-Apps nutzen. Für kleine und mittlere Unternehmen ist das vor allem dann relevant, wenn Outlook, Teams oder OneDrive bisher in einer eingebetteten WebView-Anmeldung hängen blieben.
Was Microsoft jetzt freigegeben hat
Der neue Ablauf verlegt nur den Authentifizierungsschritt beim externen Identity Provider aus der eingebetteten WebView in den Systembrowser. Die Microsoft-App startet die Anmeldung weiterhin über den Microsoft Identity Broker; nach der Authentifizierung kehrt der Benutzer per App-Link oder Universal Link in den Broker und anschließend in die App zurück. Laut Microsoft ist die Funktion für die Microsoft Entra Public Cloud allgemein verfügbar, während sie in nationalen Clouds noch als Preview geführt wird.
- Unterstützt werden föderierte Domänen mit WS-Fed oder SAML 2.0.
- Getestet und unterstützt sind Outlook, Teams, OneDrive, Word, Excel, PowerPoint und Microsoft To Do.
- Der externe IdP-Schritt kann Passkeys, FIDO2-Sicherheitsschlüssel, WebAuthn und geeignete Browser-SSO-Sitzungen verwenden.
- Nicht unterstützt sind Linux, unmanaged macOS und OAuth2-/OIDC-Social-IdPs.
Warum das für KMU zählt
Viele KMU nutzen Microsoft 365, haben aber Identitäten historisch über einen externen Anbieter oder eine föderierte Domäne angebunden. Genau dort entsteht ein Bruch: Webanwendungen können moderne Browserfunktionen nutzen, native Apps dagegen fielen bislang teilweise auf eingebettete WebViews zurück. Wenn der externe Anbieter WebViews blockiert oder Passkeys erzwingt, scheitert die Anmeldung oder landet wieder beim Passwort. Die neue Funktion schließt diese Lücke für unterstützte Apps, ohne die Architektur der Föderation komplett umzubauen. Das ist besonders hilfreich, wenn das Unternehmen bereits in phishing-resistente Anmeldung investiert hat und diese Investition nicht nur im Browser, sondern auch in den täglichen Office-Apps wirken soll.
Voraussetzungen und Grenzen
Die Funktion ist ausgeschaltet, bis ein Tenant-Administrator sie in der jeweiligen Federation Configuration aktiviert. Microsoft nennt dafür die Eigenschaft systemBrowserEnabledOn am Objekt InternalDomainFederation. Die Plattformen werden gezielt gesetzt, etwa für Android, iOS oder macOS. Für Android muss Chrome als Standardbrowser eingerichtet sein; für iOS ist Safari mit Microsoft Authenticator erforderlich; für verwaltete macOS-Geräte nennt Microsoft Safari und Company Portal. Windows nutzt laut Learn bereits einen anderen nativen Weg für Drittanbieter-FIDO.
Vor einer Aktivierung sollte außerdem geprüft werden, ob die bestehende Microsoft-Entra-ID-Konfiguration, Broker-Versionen und Geräteverwaltung zusammenpassen. Sonst entsteht kein Sicherheitsgewinn, sondern ein zweiter Anmeldepfad, den der Helpdesk vor dem internen Rollout schwer erklären kann.
Kein Fristthema, aber ein guter Prüfpunkt im Oktober
Microsoft nennt für diese Freigabe keine Umstellungsfrist. Das macht sie weniger dringend als die bereits bekannte SMS- und Voice-Abkündigung, aber nicht unwichtig. Wer heute externe IdP-Passkeys eingeführt hat oder WebViews aus Sicherheitsgründen blockiert, sollte im Oktober prüfen, ob die Microsoft-Apps der eigenen Benutzer noch einen Sonderfall bilden. Besonders relevant sind mobile Geräte, Shared-Device-Szenarien und verwaltete Macs, weil Microsoft dort konkrete Mindestkomponenten und Plattformgrenzen beschreibt.
Nächste Schritte für Administratoren
- Ermitteln Sie, welche Domänen in Entra ID wirklich föderiert sind und welches Protokoll sie verwenden.
- Vergleichen Sie die betroffenen Geräte mit Microsofts Supportmatrix für Android, iOS und managed macOS.
- Aktivieren Sie
systemBrowserEnabledOnzuerst nur für eine Pilotplattform und dokumentieren Sie die Änderung. - Testen Sie Outlook, Teams und OneDrive mit einem Benutzer, dessen externer IdP Passkey oder FIDO2 verlangt.
- Prüfen Sie anschließend, ob Conditional Access, Broker-App und externer IdP dieselbe MFA-Logik erwarten.
Die Validierung sollte lokal und datensparsam bleiben. Microsoft weist ausdrücklich darauf hin, dass Tokens, Broker-Status, Tenant-IDs, Benutzer- oder Gerätekennungen nicht in URLs, Diagnoseprotokollen oder Supportnotizen landen sollten. Für ein Microsoft Security Assessment ist deshalb die beobachtbare Anmeldekette wichtiger als Screenshots mit sensiblen Details.
Offizielle Microsoft-Quellen
- Microsoft Entra Blog: Sign in to Microsoft apps with passkeys from external identity providers
- Microsoft Learn: Browser authentication for external identity providers in Microsoft Entra ID
- Microsoft Graph: internalDomainFederation resource type
Ob sich die neue Browserauthentifizierung für Ihre Microsoft-365-Umgebung lohnt, hängt an Föderation, Geräten und IdP-Vorgaben. ReByteIT prüft diese Punkte strukturiert und hilft bei einer kontrollierten Pilotierung – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
