Mit Explicit Forward Proxy verlagert Entra Internet Access die Arbeit in Policies, Tokens und Netzpfade

Viele Sicherheits- und Workplace-Teams lesen den neuen Explicit Forward Proxy für Microsoft Entra Internet Access zuerst als reine Erleichterung. Kein Client auf dem einzelnen Gerät, stattdessen Proxy-Logik über Browser, PAC-Datei und Session-Management. Das klingt nach weniger Rollout-Aufwand. In der Praxis verschiebt sich die Arbeit aber nur. Sie wandert weg vom Client-Projekt und hinein in Trusted Networks, Conditional Access, DNS-Verhalten, Token-Laufzeiten und die Frage, welcher Datenpfad im Betrieb wirklich greift.

Genau deshalb ist die neue Explicit-Forward-Proxy-Option fachlich interessant. Microsoft beschreibt sie seit dem 7. Mai 2026 als Preview-Funktion, mit der sich die Secure-Web- und AI-Gateway-Fähigkeiten von Entra Internet Access ohne installierten Global-Secure-Access-Client nutzen lassen. Wer nur die Überschrift liest, versteht das schnell als simplere Einführung. Wer die Dokumentation genauer liest, sieht dagegen einen deutlich strengeren Betriebsrahmen: TLS Inspection ist Pflicht, Smart Session Management ist standardmässig aktiv und Microsoft empfiehlt explizit, den Proxy-Zugriff per Conditional Access auf vertrauenswürdige Netze zu begrenzen.

Der neue Proxy-Pfad spart Rollout-Reibung, aber nicht die Policy-Arbeit

Microsoft nennt Entra Internet Access in der Grundlagendokumentation ein identity-based Secure Web Gateway für Internet- und SaaS-Zugriffe. Zu den Kernfunktionen gehören laut Produktübersicht Traffic Acquisition, detaillierte Traffic Logs, Kontextsteuerung über Benutzer-, Geräte- und Risikosignale sowie Web-Content- und FQDN-Filtering. Der operative Charme des Explicit Forward Proxy liegt nun darin, dass Browser-Traffic über PAC-Dateien eingebunden werden kann, ohne den GSA-Client auf jedem Endgerät vorauszusetzen.

Das ist vor allem für gemischte Flotten, Partnergeräte, stark reglementierte Browser-Kontexte oder Zwischenstufen in Migrationen attraktiv. Gleichzeitig verschiebt es die Problemklasse. Wo zuvor vor allem Client-Verteilung, Agent-Zustand und Endpunktdiagnose im Fokus standen, rutschen jetzt PAC-Logik, Netzgrenzen, Header-Sitzungsmanagement und IP-Affinität ins Zentrum. Genau deshalb ist Microsofts Hinweis auf Trusted Networks keine Nebensache. Wenn Session-Management einen Teil seiner Bindung über IP-Affinität herstellt, wird der Unterschied zwischen kontrolliertem Unternehmensnetz und beliebigem Ausleitungsweg plötzlich sicherheitsrelevant.

Für IT-Management bedeutet das: Explicit Forward Proxy ist kein Shortcut um Governance herum. Es ist ein anderer Governance-Pfad. Wer ihn sauber nutzen will, braucht ein klares Bild davon, welche Browser, Netze, Proxy-Profile und Conditional-Access-Signale überhaupt als vertrauenswürdig gelten sollen. Ohne diese Vorarbeit wird aus dem einfacheren Rollout schnell ein schwer durchschaubarer Mischbetrieb.

Die Stolperstellen liegen nicht in der Featureliste, sondern in den Voraussetzungen

Besonders deutlich wird das in Microsofts Konfigurationshinweisen für Web Content Filtering. Dort beschreibt Microsoft Entra Internet Access seine ersten SWG-Funktionen als URL-, Webkategorie- und FQDN-basierte Filterung mit Anbindung an Conditional Access. Gleichzeitig listet die Doku aber mehrere Voraussetzungen, die im Projektalltag gerne unterschätzt werden: DNS over HTTPS muss deaktiviert sein, Chrome und Edge sollen ihre eingebaute Secure-DNS-Logik abschalten, IPv6 wird vom Clientpfad nicht erfasst und soll deshalb für vollständige Tunnelerfassung auf IPv4-preferred gesetzt werden. Hinzu kommt, dass UDP-Traffic beziehungsweise QUIC in der aktuellen Preview nicht unterstützt wird.

Das ist kein kosmetisches Detail. Viele moderne Browser und Dienste bevorzugen heute gerade diese Mechanismen, um Verbindungen schneller oder privater aufzubauen. Wenn ein Team also nur die Gateway-Policies modelliert, aber DNS-, QUIC- und Adapterverhalten auf den Geräten offenlässt, entsteht eine unangenehme Grauzone: Der Sollzustand im Entra-Portal sieht sauber aus, der Istzustand im realen Datenpfad kann aber daran vorbeilaufen oder sich zumindest anders verhalten als geplant.

Microsoft empfiehlt für QUIC in der Preview sogar explizit eine Windows-Firewall-Regel auf UDP 443, damit Browser auf TCP zurückfallen. Genau daran erkennt man, wie dieses Thema operativ gelesen werden muss. Es geht nicht nur um ein neues Security-Feature, sondern um eine abgestimmte Kombination aus Browser-Verhalten, Endpunktkonfiguration, Netzpfad und Identitätskontrolle.

Conditional Access bleibt das Rückgrat, aber nicht jeder Pfad hängt gleich daran

Ein weiterer Punkt ist noch wichtiger: Microsoft beschreibt Conditional Access im Web-Filtering-Pfad als eigentlichen Delivery-Mechanismus für user- und context-aware Policies. Security Profiles werden über Conditional Access Session Controls zugewiesen. Gleichzeitig nennt die Doku aber zwei Einschränkungen, die in der Betriebsrealität sofort relevant sind.

Erstens ist Explicit Forward Proxy in der Preview laut Microsoft aktuell nicht in der Gruppe All internet resources with Global Secure Access enthalten. Teams müssen für EFP also die gesonderte Conditional-Access-Konfiguration für diesen Pfad beachten, statt gedanklich davon auszugehen, dass die bestehende Internet-Access-Policy automatisch alles abdeckt. Zweitens können neue Security Profiles laut Microsoft 60 bis 90 Minuten brauchen, bis sie über neue Tokens wirksam werden. Bei Änderungen an bestehenden Profilen geht es zwar schneller, aber auch dort ist Token-Verhalten ein echter Betriebsfaktor und keine Randnotiz.

Das hat direkte Folgen für Rollout, Test und Incident-Kommunikation. Wenn ein Team eine neue Regel anlegt und wenige Minuten später auf Testergebnissen besteht, kann es leicht die falschen Schlüsse ziehen. Vielleicht greift die Policy noch nicht, vielleicht läuft sie nur auf einem anderen Pfad, vielleicht fehlt ein erneuerter Token. Microsoft nennt selbst den praktikablen Workaround: Sessions für Testnutzer gezielt widerrufen, damit neue Tokens mit aktualisierten Security-Profile-Claims gezogen werden. Wer diesen Mechanismus nicht mitdenkt, verwechselt Policy-Fehler schnell mit Zeitverzug oder umgekehrt.

Der eigentliche Betriebsgewinn entsteht erst aus sauber getrennten Zonen

Die klügste Lesart für Explicit Forward Proxy ist deshalb nicht: endlich ohne Client. Sie lautet eher: jetzt mit klarerer Zonierung. Ein Unternehmen kann den neuen Pfad dort einsetzen, wo Browser-basierter Zugriff aus verwalteten oder bewusst vertrauten Netzen schnell unter Gateway-Kontrolle kommen soll. Für mobile, stark wechselnde oder tiefer integrierte Szenarien bleibt der Clientpfad oft trotzdem sinnvoll, weil er die Verkehrsaufnahme breiter und robuster absichern kann.

Diese Trennung hilft auch organisatorisch. Security bekommt einen saubereren Rahmen für vertrauensgebundene Proxy-Sessions. Workplace- und Netzwerk-Teams behalten klare Verantwortung für DNS-, Browser- und QUIC-Verhalten. IAM- und Conditional-Access-Verantwortliche definieren, welche Security Profiles für welche Nutzer oder Netze überhaupt ausgeliefert werden. Und der Service Desk kann Fehlerbilder endlich besser unterscheiden: Token noch alt, Browser nutzt DoH, QUIC fällt nicht sauber auf TCP zurück, Profil nicht am richtigen Netz gebunden oder Security Profile noch nicht wirksam.

Genau darin liegt die eigentliche Stärke von Entra Internet Access. Microsoft baut kein klassisches URL-Filter-Werkzeug, sondern ein identitätszentriertes SWG mit enger Verknüpfung zu Conditional Access und Graph-gestürten Policy-Objekten. Auch die Graph-Tutorials zeigen das deutlich: Traffic Forwarding Profile, Filtering Policies und Security Profiles gehören zusammen. Explicit Forward Proxy verändert daran nichts. Es macht diese Architektur nur sichtbarer, weil der bequeme Gedanke eines einzelnen Agents als Universalantwort wegfällt.

Was Teams vor einem produktiven Rollout festziehen sollten

Bevor Explicit Forward Proxy produktiv in die Breite geht, lohnt sich ein kurzer, aber harter Kontrolllauf. Erstens sollte festgelegt werden, welche Netze ausdrücklich als vertrauenswürdig für EFP gelten und wie diese Bindung in Conditional Access modelliert wird. Zweitens müssen Browser- und Endpunktvorgaben für DoH, QUIC und IPv6 nicht nur dokumentiert, sondern wirklich durchgesetzt werden. Drittens sollten Testabläufe immer Token-Erneuerung und Rollback berücksichtigen. Viertens braucht der Service Desk eine saubere Fehler-Matrix für die ersten Wochen, damit Session-, Netz- und Policy-Probleme nicht im gleichen Ticketkorb landen.

Wenn diese Punkte sitzen, kann Explicit Forward Proxy sehr sinnvoll sein. Er spart dann tatsächlich Rollout-Reibung, ohne die Steuerbarkeit zu verlieren. Fehlen diese Vorarbeiten, wird aus der neuen Preview-Funktion schnell ein Projekt, das im Dashboard sauber und im Alltag widersprüchlich wirkt.

Fazit

Explicit Forward Proxy ist für Entra Internet Access kein kleines Add-on, sondern ein Perspektivwechsel. Die Einführung verschiebt die Hauptarbeit weg vom einzelnen Client und hin zu Policies, Tokens, Browser-Verhalten und klar definierten Netzgrenzen. Genau deshalb ist der neue Pfad interessant. Er zwingt Teams, den eigentlichen Daten- und Entscheidungsfluss sauber zu benennen, statt Sicherheit nur über einen installierten Agenten zu denken.

Wer das ernst nimmt, bekommt mehr als einen bequemeren Browser-Pfad. Er bekommt ein klareres Betriebsmodell für identitätsbasierten Internetzugriff. Wer den Proxy dagegen nur als schnellere Abkürzung ausrollt, riskiert ein Gateway, das formal vorhanden ist, aber praktisch an den falschen Stellen vorbeigeht.

Quellen

• Microsoft Learn: Configure Explicit Forward Proxy (preview), zuletzt aktualisiert 07.05.2026
• Microsoft Learn: What is Global Secure Access?, zuletzt aktualisiert 15.04.2026
• Microsoft Learn: How to configure Global Secure Access web content filtering
• Microsoft Graph: Configure Microsoft Entra Internet Access using Microsoft Graph APIs