IT-Consulting Blog

Microsoft hat im Mai 2026 ein neues Hotfix Update für Exchange Server Subscription Edition, kurz Exchange Server SE, veröffentlicht. Konkret handelt es sich um Exchange Server SE RTM HU6, veröffentlicht am 7. Mai 2026.

Laut Microsoft enthält das Update keine neuen Exchange-Sicherheitsupdates, sondern Korrekturen für nicht sicherheitsrelevante Probleme und neue Funktionalität. Auf den ersten Blick klingt das nach einem normalen Zwischenupdate. In der Praxis ist es aber besonders für Unternehmen mit hybriden Exchange-Umgebungen relevant.

Der wichtigste Punkt: Das Mai-2026-Hotfix-Update schafft die Grundlage dafür, bestimmte Exchange Hybrid Rich Coexistence-Funktionen schrittweise von Exchange Web Services, kurz EWS, auf REST-basierte Microsoft Graph API-Aufrufe umzustellen.

Kurz gesagt: Das Update ist kein klassisches Sicherheitsupdate. Aber für Hybrid-Kunden ist es trotzdem wichtig.

Und diesmal geht es nicht nur um „irgendwann modernisieren“. Microsoft hat konkrete Fristen gesetzt.

Worum geht es?

Viele Unternehmen betreiben Exchange heute hybrid. Ein Teil der Umgebung liegt lokal auf Exchange Server, während Postfächer oder Dienste bereits in Exchange Online beziehungsweise Microsoft 365 genutzt werden.

Damit diese Welten sauber zusammenarbeiten, braucht es Hybrid-Funktionen. Dazu gehören zum Beispiel:

• Frei/Gebucht-Informationen zwischen On-Premises und Exchange Online
• MailTips
• Profilbild-Freigabe
• Kalender- und Verfügbarkeitsfunktionen
• Koexistenzfunktionen während Migrationen
• bestimmte Verwaltungs- und Vermittlungsfunktionen zwischen lokaler Organisation und Cloud

Diese Funktionen wirken für Benutzer selbstverständlich. Im Hintergrund hängen sie aber an Authentifizierung, Berechtigungen, Zertifikaten, APIs, Service Principals und Hybrid-Konfigurationen.

Genau dort setzt Microsoft aktuell an.

Warum Microsoft die Hybrid-Architektur verändert

Microsoft modernisiert die Exchange-Hybrid-Architektur. Ein zentraler Grund ist die stärkere Absicherung hybrider Umgebungen und die Ablösung älterer Mechanismen.

Bisher wurden viele Hybrid-Rich-Coexistence-Funktionen über EWS abgewickelt. Microsoft stellt diese Funktionen nun schrittweise auf Microsoft Graph um. Ziel ist eine modernere, granularere und besser kontrollierbare Kommunikation zwischen Exchange Online und lokalen Exchange-Umgebungen.

Das Ziel ist nachvollziehbar:

• weniger Abhängigkeit von alten Schnittstellen
• modernere Authentifizierung
• klarere Berechtigungen
• bessere Steuerbarkeit
• weniger pauschales Vertrauen zwischen Cloud und On-Premises
• bessere Zukunftsfähigkeit hybrider Exchange-Umgebungen

Für Administratoren bedeutet das aber auch: Hybrid-Umgebungen müssen aktiv gepflegt werden.

Ein „läuft doch seit Jahren“ ist bei Exchange Hybrid keine gute Betriebsstrategie mehr.

Die Microsoft-Timeline: Zwei Stufen

Microsoft hat die Änderung in zwei Stufen geplant.

Stufe 1: Dedizierte Exchange Hybrid Application

Die erste Stufe war die Umstellung auf eine dedizierte Exchange Hybrid Application.

Diese Phase wurde laut Microsoft im Oktober 2025 abgeschlossen. Exchange-Hybrid-Kunden, die weiterhin lokale Postfächer hosten, müssen diese dedizierte Hybrid-App erstellen, damit Rich-Coexistence-Funktionen für lokale Benutzer erhalten bleiben.

Das war bereits ein klares Signal: Microsoft löst alte Hybrid-Vertrauensmodelle schrittweise ab.

Stufe 2: EWS wird abgelöst, Microsoft Graph übernimmt

Die zweite Stufe läuft jetzt.

Microsoft stellt Hybrid-Rich-Coexistence von EWS-Aufrufen auf REST-basierte Microsoft Graph API-Aufrufe um. Genau dafür ist das Mai-2026-Hotfix-Update relevant.

Kunden, die Graph API in hybriden Workflows nutzen wollen, müssen:

1. das Mai-2026-Hotfix Update oder ein neueres Update auf den lokalen Exchange-SE-Servern installieren,
2. danach den Graph API Hybrid Workflow gemäß Microsoft-Dokumentation aktivieren.

Wichtig: Wenn das entsprechende Microsoft-Skript bereits früher ausgeführt wurde, muss es nach Installation des neuen Updates erneut ausgeführt werden, damit die neue Funktionalität aktiviert wird.

Nur patchen reicht also nicht aus. Die Umgebung muss anschließend auch korrekt aktiviert und getestet werden.

Die entscheidenden Fristen: Oktober 2026 und April 2027

Der eigentliche Handlungsdruck entsteht durch die EWS-Abkündigung in Exchange Online.

Microsoft wird EWS in Exchange Online im Oktober 2026 standardmäßig deaktivieren. Danach kann EWS noch vorübergehend wieder aktiviert werden.

Im April 2027 wird EWS in Exchange Online endgültig abgeschaltet.

Für hybride Exchange-Umgebungen heißt das sehr konkret:

Bis Oktober 2026 sollte die Umstellung abgeschlossen sein.

Und:

Bis April 2027 muss die Umstellung abgeschlossen sein.

Nach April 2027 gibt es für EWS in Exchange Online keinen Rückweg mehr.

Wer dann noch auf EWS-basierte Hybrid-Rich-Coexistence angewiesen ist, wird Probleme bekommen.

Hotfix Update heißt nicht automatisch Sicherheitsupdate

Wichtig für die interne Kommunikation: Das Mai-2026-Hotfix-Update ist kein klassisches Patch-Tuesday-Sicherheitsupdate.

Microsoft beschreibt das HU6 für Exchange Server SE RTM als Hotfix mit Korrekturen für nicht sicherheitsrelevante Probleme und neuer Funktionalität. Gleichzeitig enthält das Mai-2026-Hotfix-Update laut Exchange Team Blog keine neuen Exchange Server Security Updates.

Trotzdem sollte man das Update nicht ignorieren. Gerade in hybriden Umgebungen schafft es funktionale Voraussetzungen für kommende Änderungen.

Man muss also unterscheiden:

Security Update: behebt konkrete Sicherheitslücken.
Hotfix Update: behebt Fehler oder bringt neue Funktionalität außerhalb eines CUs.
Cumulative Update: größerer Aktualisierungsstand mit gebündelten Änderungen.

Das Mai-2026-Hotfix-Update ist vor allem deshalb relevant, weil es Exchange Server SE auf die Modernisierung der Hybrid-Funktionalität vorbereitet.

Betrifft das alle Exchange-Umgebungen?

Nicht in gleicher Weise.

Besonders relevant ist das Update für Unternehmen mit:

• Exchange Server Subscription Edition
• hybrider Exchange-Bereitstellung
• Exchange Online in Microsoft 365
• lokalen Postfächern
• Rich-Coexistence-Funktionen zwischen On-Premises und Cloud
• lokalen Exchange-Servern für Empfängerverwaltung
• laufenden oder geplanten Migrationen zu Exchange Online

Für reine On-Premises-Umgebungen ohne Hybrid-Funktionalität ist das Update weniger kritisch. Exchange Server SE sollte natürlich trotzdem aktuell gehalten werden.

Für reine Exchange-Online-Umgebungen ohne lokale Exchange-Koexistenz ist der Hybrid-Teil weniger relevant. Trotzdem sollten auch diese Umgebungen prüfen, ob Drittanwendungen noch EWS verwenden.

Was kann passieren, wenn man nicht handelt?

Kurzfristig passiert möglicherweise nichts Sichtbares. Genau das ist gefährlich.

Die Umgebung läuft weiter. Benutzer arbeiten. Kalenderinformationen funktionieren. Migrationen laufen vielleicht noch. Dadurch entsteht schnell der Eindruck, dass kein akuter Handlungsbedarf besteht.

Das Problem entsteht zeitversetzt.

Wenn EWS in Exchange Online standardmäßig deaktiviert oder später endgültig abgeschaltet wird, können wichtige Funktionen ausfallen.

Mögliche Folgen:

• Frei/Gebucht-Abfragen zwischen On-Premises und Exchange Online funktionieren nicht mehr zuverlässig.
• MailTips zwischen On-Premises und Exchange Online brechen.
• Profilbilder werden nicht mehr korrekt bereitgestellt.
• Hybridfunktionen werden instabil.
• Migrationen oder Verwaltungsaufgaben schlagen fehl.
• Troubleshooting wird unnötig komplex.
• alte EWS-Abhängigkeiten bleiben bestehen.
• Drittanbieter-Anwendungen mit EWS-Abhängigkeit funktionieren nicht mehr.
• Hybrid-Konfigurationen bleiben technisch überaltert.

Gerade historisch gewachsene Hybrid-Umgebungen sind hier anfällig. Viele wurden vor Jahren eingerichtet, mehrfach aktualisiert, teilweise migriert und nie vollständig bereinigt.

Was Administratoren vor der Installation prüfen sollten

Exchange-Updates sollte man nie blind installieren. Das gilt auch für dieses Hotfix Update.

Vorher sollten mindestens folgende Punkte geprüft werden.

1. Exchange-Version und Buildstand

Welche Exchange-Version läuft aktuell? Ist es wirklich Exchange Server SE? Welche Hotfixes oder Security Updates sind bereits installiert?

Das ist besonders wichtig, weil Exchange 2016 und Exchange 2019 keine Graph API Hybrid Calls erhalten.

2. Hybrid-Konfiguration

Wird Exchange hybrid betrieben? Gibt es Exchange Online? Wird der lokale Exchange noch für Empfängerverwaltung, Relay, Migration oder Koexistenzfunktionen genutzt?

3. Lokale Postfächer

Gibt es noch lokale Postfächer? Wenn ja, sind Rich-Coexistence-Funktionen wie Frei/Gebucht, MailTips oder Profilbild-Freigabe relevant?

4. Dedizierte Exchange Hybrid Application

Ist die dedizierte Exchange Hybrid Application bereits eingerichtet? Wurde sie sauber dokumentiert? Sind Berechtigungen nachvollziehbar?

5. Graph API Hybrid Workflow

Ist das Mai-2026-Hotfix Update oder ein neueres Update installiert? Wurde der Graph API Hybrid Workflow danach aktiviert?

Wurde ein früher ausgeführtes Microsoft-Skript nach dem Update erneut ausgeführt?

6. EWS-Abhängigkeiten

Welche Anwendungen, Archivsysteme, Migrationstools, Kalenderintegrationen oder Eigenentwicklungen verwenden noch EWS?

Greifen diese Anwendungen auf Exchange Online zu?

7. Zertifikate

Sind die Exchange-Zertifikate gültig? Stimmen Namen, Laufzeiten und Bindings? Gibt es alte oder nicht mehr benötigte Zertifikate?

8. Backup und Wiederherstellung

Gibt es aktuelle Exchange-Backups? Sind System State, Datenbanken, Konfiguration und virtuelle Maschinen sauber gesichert?

9. Wartungsfenster

Auch ein Hotfix Update braucht Planung. Dienste werden neu gestartet, und in DAG-Umgebungen müssen Server geordnet nacheinander aktualisiert werden.

Empfohlenes Vorgehen

Für produktive Umgebungen empfiehlt sich ein konservatives, sauberes Vorgehen.

1. Inventarisieren

Zuerst sollte klar sein, welche Server betroffen sind:

• Exchange-Version
• installierte Updates
• Serverrollen
• DAG-Mitgliedschaften
• Zertifikate
• verwendete Namespaces
• Connectoren
• Hybrid-Konfiguration
• lokale Postfächer
• Drittanbieter-Integrationen wie Backup, Archivierung, Signaturen, Gateways oder Monitoring
• bekannte EWS-Abhängigkeiten

Ohne diese Übersicht wird jedes Exchange-Update unnötig riskant.

2. Exchange 2016 und 2019 ablösen

Wenn noch Exchange 2016 oder Exchange 2019 im Einsatz ist, sollte das Thema priorisiert werden.

Diese Versionen sind keine Zukunftsplattform für Exchange Hybrid Rich Coexistence. Microsoft stellt für Exchange 2016 und 2019 keine Updates bereit, um Graph API Hybrid Calls zu unterstützen. Auch ESU-Updates enthalten diese Funktionalität nicht.

Kunden haben faktisch zwei Wege:

• Migration zu Exchange Server SE
• vollständige Migration der lokalen Postfächer nach Exchange Online

Ein „wir bleiben einfach auf Exchange 2019 mit ESU“ ist keine tragfähige Strategie für Hybrid Rich Coexistence.

3. Microsoft-Dokumentation und Known Issues prüfen

Vor der Installation sollten Administratoren den Exchange Team Blog, den KB-Artikel und mögliche Known Issues prüfen. Das Mai-2026-HU ist über Windows Update und als eigenständiges Paket verfügbar.

Wichtig sind vor allem:

• Voraussetzungen
• bekannte Probleme
• Buildnummern
• Hybrid-Hinweise
• Hinweise zum Hybrid Configuration Wizard
• Hinweise zum Graph API Hybrid Workflow
• mögliche manuelle Nacharbeiten

4. Testumgebung oder Pilotserver nutzen

Wenn eine Testumgebung existiert, sollte das Update zuerst dort installiert werden.

Wenn keine Testumgebung vorhanden ist, sollte mindestens ein Pilotserver definiert werden. In DAG-Umgebungen kann man kontrolliert Server für Server aktualisieren.

5. Wartungsmodus verwenden

Exchange-Server sollten nicht einfach im laufenden Betrieb gepatcht werden. Vor allem in DAG-Umgebungen gehört ein Server sauber in den Wartungsmodus.

Dazu gehören typischerweise:

• Server aus Load-Balancer-Rotation nehmen
• aktive Datenbanken verschieben
• Transport-Komponenten drainen
• Update installieren
• Neustart durchführen
• Health prüfen
• Server wieder produktiv schalten

6. Graph API Hybrid Workflow aktivieren

Nach der Installation des Mai-2026-Hotfixes oder eines neueren Updates muss der Graph API Hybrid Workflow gemäß Microsoft-Dokumentation aktiviert werden.

Wichtig: Wenn das Microsoft-Skript bereits früher ausgeführt wurde, muss es nach Installation des neuen Updates erneut ausgeführt werden, um die neue Funktionalität zu aktivieren.

7. Hybrid-Funktionen gezielt testen

Nach dem Update reicht es nicht, nur zu prüfen, ob die Dienste laufen.

Wichtige Tests sind:

• Outlook
• OWA
• Mailflow intern und extern
• Autodiscover
• Frei/Gebucht Cloud zu On-Premises
• Frei/Gebucht On-Premises zu Cloud
• MailTips
• Profilbild-Freigabe
• Hybrid-Mailflow
• Migration Batches, falls aktiv
• Exchange Admin Center
• Exchange Management Shell
• Event Logs
• Exchange Health Checker

Gerade Hybrid-Funktionen sollten bewusst getestet werden, weil Probleme häufig erst auffallen, wenn Benutzer Kalenderinformationen benötigen oder Migrationen laufen.

Was ist mit Exchange 2016 und Exchange 2019?

Hier muss man deutlich sein: Exchange Server 2016 und Exchange Server 2019 sind seit dem 14. Oktober 2025 regulär aus dem Support.

Gleichzeitig gibt es für bestimmte Kunden ein kostenpflichtiges Extended Security Update Program, kurz ESU. Das ist aber keine Entwarnung.

ESU bedeutet nicht, dass Exchange 2016 oder Exchange 2019 wieder normale, vollständig unterstützte Plattformen sind. ESU ist eine Übergangslösung für ausgewählte Sicherheitsupdates. Es ist keine langfristige Betriebsstrategie.

Noch wichtiger: Microsoft stellt für Exchange 2016 und 2019 keine Updates bereit, um Graph API Hybrid Calls zu unterstützen. Selbst Updates im Rahmen von Exchange 2016/2019 ESU enthalten diese Funktionalität nicht.

Das bedeutet:

• Exchange 2016 und 2019 nicht als Zielplattform weiterbetreiben.
• ESU nur als erkaufte Übergangszeit verstehen.
• Migration zu Exchange Server SE oder Exchange Online priorisieren.
• Hybrid-Umgebungen nicht dauerhaft auf veralteter Basis betreiben.
• Kunden mit lokalen Postfächern müssen spätestens bis April 2027 migrieren.
• Risiken gegenüber Management und Kunden klar kommunizieren.

Kurz gesagt: ESU ist nicht „Support wie früher“. ESU ist Restzeit.

Typische Fehler beim Exchange-Patching und bei der Hybrid-Modernisierung

In vielen Umgebungen wiederholen sich dieselben Fehler:

• Updates werden zu lange verschoben.
• Das Hotfix wird ignoriert, weil es kein Sicherheitsupdate ist.
• Es gibt keine aktuelle Buildübersicht.
• Hybrid-Funktionen werden nach Updates nicht getestet.
• alte Zertifikate und Service Principals bleiben bestehen.
• Drittanbieter-Software wird vorher nicht geprüft.
• DAG-Server werden nicht sauber in Wartung genommen.
• Health Checker wird nicht genutzt.
• Es gibt kein dokumentiertes Rollback-Szenario.
• Exchange 2016/2019 werden trotz Supportende weiter als Normalbetrieb behandelt.
• ESU wird fälschlich als vollständiger Support verstanden.
• Das Aktivierungsskript wird nach dem neuen Update nicht erneut ausgeführt.
• EWS-Abhängigkeiten von Drittanwendungen bleiben unentdeckt.
• Oktober 2026 wird unterschätzt.
• April 2027 wird als fernes Datum betrachtet, obwohl dann endgültig Schluss ist.

Bei Exchange ist das gefährlich. Exchange hängt tief in Active Directory, DNS, Zertifikaten, Load Balancing, Mailflow, Security, Compliance und Microsoft 365.

Meine Empfehlung für Kundenumgebungen

Ich würde Umgebungen in vier Gruppen einteilen.

Gruppe 1: Exchange 2016/2019 mit Hybrid und lokalen Postfächern

Diese Umgebungen haben den größten Handlungsdruck.

Die Plattform ist nicht mehr regulär unterstützt, erhält keine Graph-Hybrid-Funktionalität und wird spätestens mit der endgültigen EWS-Abschaltung im April 2027 Probleme bekommen.

Priorität: kritisch

Empfehlung: Sofort Migrationsplanung starten.

Gruppe 2: Exchange Server SE mit Hybrid und lokalen Postfächern

Diese Umgebungen sind auf dem richtigen Zielsystem, müssen aber aktualisiert und umgestellt werden.

Das Mai-2026-Hotfix oder ein neueres Update sollte installiert werden. Danach müssen Graph API Hybrid Workflow, dedizierte Hybrid App, Berechtigungen und Rich-Coexistence-Funktionen geprüft werden.

Priorität: hoch

Empfehlung: Umsetzung vor Oktober 2026 abschließen.

Gruppe 3: Exchange Server SE ohne lokale Postfächer

Hier ist der Druck geringer. Trotzdem sollte geprüft werden, ob Exchange noch für Verwaltung, Relay, Hybridreste oder Anwendungen verwendet wird.

Priorität: mittel

Empfehlung: Abhängigkeiten dokumentieren und Umgebung bereinigen.

Gruppe 4: Reine Exchange-Online-Umgebungen

Diese sind vom Exchange-Hybrid-Rich-Coexistence-Thema weniger betroffen. Trotzdem kann EWS für Anwendungen relevant sein.

Priorität: abhängig von EWS-Nutzung

Empfehlung: EWS-Abhängigkeiten von Drittanwendungen prüfen.

Konkrete To-dos

Für Administratoren ergibt sich daraus ein klarer Maßnahmenplan:

1. Exchange-Versionen und Buildstände erfassen.
2. Prüfen, ob Exchange Server SE bereits im Einsatz ist.
3. Lokale Postfächer identifizieren.
4. Hybrid-Konfiguration und Rich-Coexistence-Funktionen dokumentieren.
5. Dedizierte Exchange Hybrid Application prüfen.
6. EWS-Abhängigkeiten identifizieren.
7. Exchange 2016/2019-Migration priorisieren, falls noch vorhanden.
8. Mai-2026-Hotfix oder neuer auf Exchange SE testen und installieren.
9. Graph API Hybrid Workflow aktivieren.
10. Microsoft-Skript nach Update erneut ausführen, falls es früher schon genutzt wurde.
11. Frei/Gebucht, MailTips und Profilbild-Freigabe gezielt testen.
12. Zertifikate, Connectoren und Service Principals prüfen.
13. Wartungsfenster und Testplan erstellen.
14. Zeitplan bis Oktober 2026 und April 2027 erstellen.

Fazit

Das Exchange Server Hotfix Update vom Mai 2026 ist kein klassisches Sicherheitsupdate. Trotzdem ist es für viele Unternehmen wichtig.

Der Grund liegt in der Exchange-Hybrid-Architektur. Microsoft bereitet Exchange Server SE darauf vor, bestimmte Hybridfunktionen von EWS auf REST-basierte Microsoft-Graph-Aufrufe umzustellen. Für Unternehmen mit Exchange Online und lokalem Exchange ist das ein klares Signal: Hybrid-Umgebungen müssen aktiv gepflegt und modernisiert werden.

Die Microsoft-Timeline ist eindeutig:

Oktober 2025: Stufe 1 abgeschlossen, dedizierte Exchange Hybrid Application erforderlich.
Mai 2026: Exchange Server SE erhält per Hotfix die Grundlage für Graph API Hybrid Workflows.
Oktober 2026: EWS wird in Exchange Online standardmäßig deaktiviert.
April 2027: EWS wird in Exchange Online endgültig abgeschaltet.

Gleichzeitig darf man Exchange 2016 und Exchange 2019 nicht mehr als normale Betriebsplattform betrachten. Beide Versionen sind regulär aus dem Support. ESU kann in bestimmten Fällen noch Sicherheitsupdates liefern, bringt aber keine Graph-Hybrid-Funktionalität.

Die entscheidende Frage lautet daher nicht:

„Müssen wir dieses Hotfix Update sofort installieren?“

Die bessere Frage lautet:

„Ist unsere Exchange-Hybrid-Umgebung rechtzeitig vor Oktober 2026 auf Microsoft Graph vorbereitet – und spätestens bis April 2027 vollständig weg von EWS?“

Microsoft Teams ist in vielen Unternehmen der zentrale Kommunikationskanal. Meetings, Chats, Dateien, Support, Projektarbeit und externe Zusammenarbeit laufen täglich darüber.

Genau deshalb ist Teams für Angreifer interessant.

Ein aktueller Bericht beschreibt, wie Angreifer Microsoft Teams genutzt haben, um Mitarbeitende direkt anzusprechen, Vertrauen aufzubauen, Zugangsdaten abzugreifen und Systeme zu kompromittieren. Die Masche ist dabei nicht völlig neu. Sie funktioniert, weil sie nicht wie ein klassischer Angriff aussieht. Sie wirkt wie normale Zusammenarbeit oder wie ein legitimer IT-Supportfall.

Und genau das macht sie gefährlich.

Der Angriff beginnt nicht mehr nur per E-Mail

Viele Unternehmen haben in den letzten Jahren stark in E-Mail-Sicherheit investiert. Spamfilter, Safe Links, Phishing-Simulationen und Awareness-Kampagnen sind heute weit verbreitet.

Angreifer weichen deshalb zunehmend auf andere Kanäle aus.

Microsoft Teams ist dafür ideal: Eine Chatnachricht wirkt direkter und persönlicher als eine E-Mail. Wenn sich jemand als IT-Support, externer Dienstleister oder internationale IT-Abteilung ausgibt, reagieren viele Mitarbeitende schnell. Besonders dann, wenn die Nachricht dringlich klingt oder ein technisches Problem vorgibt.

Typische Einstiegsszenarien sind:

• eine unerwartete Teams-Nachricht von extern
• ein angeblicher IT-Supportfall
• die Bitte um Bildschirmfreigabe
• die Aufforderung, ein Tool auszuführen
• das Hinzufügen einer neuen MFA-Methode
• die Eingabe von Zugangsdaten in ein Formular oder eine Datei

Der Angriff lebt nicht von technischer Raffinesse allein. Er lebt vom Vertrauen der Benutzer.

So läuft ein solcher Angriff ab

Der Ablauf ist meist einfach, aber wirksam.

Zuerst nehmen die Angreifer über Teams Kontakt auf. Sie geben sich als interne oder externe IT aus und behaupten, es gebe ein Problem mit dem Gerät, dem Konto oder der Anmeldung.

Danach wird das Opfer in eine Bildschirmfreigabe oder Remote-Support-Sitzung gelockt. Der Angreifer begleitet die nächsten Schritte live. Er kann sehen, was der Benutzer macht, kann Rückfragen beantworten und den Benutzer gezielt anleiten.

Anschließend werden Zugangsdaten abgegriffen oder Aktionen durchgeführt, die dem Angreifer Zugriff verschaffen. In aktuellen Berichten wurden Benutzer sogar dazu gebracht, Passwörter in lokale Textdateien einzutragen oder neue MFA-Geräte hinzuzufügen.

Wenn das gelingt, ist der Schaden oft größer als bei einem einfachen Phishing-Link. Der Angreifer hat nicht nur ein Passwort. Er hat möglicherweise Zugriff auf ein Gerät, ein Konto, eine Sitzung oder sogar eine gültige MFA-Methode.

Von dort aus beginnt der nächste Schritt: laterale Bewegung.

Ein realer Fall aus der Praxis

Die Methode ist nicht theoretisch.

Bereits im vergangenen Jahr wurde einer meiner Kunden durch ein sehr ähnliches Vorgehen angegriffen. Die Angreifer gaben sich zunächst als internationale IT-Abteilung aus und nahmen über Microsoft Teams Kontakt auf. Anschließend nutzten sie die Desktop-Sharing-Funktion, um den Benutzer Schritt für Schritt zu manipulieren und den Computer zu kompromittieren.

Von diesem Client aus versuchten die Angreifer, sich im Netzwerk weiterzubewegen.

Genau hier zeigte sich, wie wichtig vorbereitete Sicherheitsarchitektur ist. Der Kunde hatte bereits ein konsequentes Tiering-Modell umgesetzt. Dadurch war der Handlungsspielraum der Angreifer stark begrenzt. Sie konnten sich nicht frei durch die Umgebung bewegen, keine kritischen Administrationspfade ausnutzen und keine hochprivilegierten Systeme erreichen.

Die Detection erfolgte rechtzeitig, bevor größerer Schaden entstehen konnte.

Dieser Fall zeigt sehr deutlich: Gute Erkennung ist wichtig. Aber sie reicht nicht aus. Entscheidend ist, wie weit ein Angreifer überhaupt kommt, wenn der erste Client kompromittiert wurde.

Warum reine Detection zu kurz greift

Viele Unternehmen verlassen sich stark auf EDR, XDR oder SIEM. Diese Werkzeuge sind wichtig und haben ihre Berechtigung.

Aber sie sind keine vollständige Sicherheitsstrategie.

In solchen Angriffen verwenden die Täter oft legitime Werkzeuge und echte Benutzerinteraktionen. Ein Benutzer teilt freiwillig den Bildschirm. Ein Support-Tool wird scheinbar legitim gestartet. Ein Konto meldet sich mit korrektem Passwort und gültiger MFA an. Für ein isoliertes Detection-System ist das nicht immer sofort eindeutig bösartig.

Wenn ein Alarm erst dann entsteht, wenn der Angreifer bereits interaktiv auf dem System arbeitet, ist wertvolle Zeit verloren.

Deshalb braucht es präventive Sicherheitsmaßnahmen, die den Handlungsspielraum von Anfang an begrenzen:

• keine privilegierten Anmeldungen auf Standard-Clients
• klare Trennung von Benutzer- und Admin-Konten
• Tiering-Modell für administrative Zugriffe
• eingeschränkte laterale Bewegung
• kontrollierte Remote-Support-Tools
• gehärtete Teams-Einstellungen
• Conditional Access
• Application Control
• Monitoring und schnelle Reaktion

Ein klassisches XDR als Insellösung hätte in solchen Szenarien unter Umständen zu spät reagiert. Erst die Kombination aus Prävention, Architektur, Erkennung und Reaktion macht den Unterschied.

Microsoft Teams muss Teil des Sicherheitskonzepts werden

Teams wird häufig noch wie ein reines Kommunikationswerkzeug behandelt. Das ist ein Fehler.

Teams ist heute ein sicherheitskritischer Zugangspunkt in die Organisation. Darüber laufen interne Kommunikation, externe Zusammenarbeit, Dateien, Meetings, Links, Anwendungen und Supportprozesse.

Daher sollten Unternehmen Teams genauso bewusst absichern wie E-Mail, Endgeräte und Identitäten.

Wichtige Fragen sind:

• Können externe Benutzer Mitarbeitende direkt anschreiben?
• Ist externe Kommunikation auf vertrauenswürdige Domains beschränkt?
• Sind nicht verwaltete externe Teams-Konten blockiert?
• Dürfen externe Kontakte Bildschirmfreigaben starten?
• Ist Remote Control in Meetings erlaubt?
• Welche Remote-Support-Tools sind zugelassen?
• Werden neue MFA-Methoden überwacht?
• Gibt es klare Regeln, wie echter IT-Support abläuft?
• Wissen Mitarbeitende, dass Passwörter niemals in Chats oder Textdateien gehören?

Diese Fragen sind einfach. Die Antworten fehlen aber in vielen Umgebungen.

Konkrete Schutzmaßnahmen

Unternehmen sollten jetzt nicht panisch reagieren, aber gezielt prüfen und härten.

1. Externe Teams-Kommunikation einschränken

Externe Kommunikation sollte nicht pauschal erlaubt sein. Sinnvoll ist eine Allowlist für bekannte Partner und Dienstleister.

Nicht verwaltete externe Teams-Konten sollten blockiert werden, wenn sie nicht benötigt werden. Externe Benutzer sollten interne Mitarbeitende nicht beliebig kontaktieren können.

2. Bildschirmfreigabe und Remote Control kontrollieren

Desktop Sharing ist praktisch, aber sicherheitskritisch. Besonders gefährlich wird es, wenn externe Personen Benutzer anleiten oder sogar Steuerung übernehmen können.

Unternehmen sollten klar regeln, wer Bildschirmfreigabe nutzen darf, ob externe Teilnehmer Remote Control anfordern können und welche Gruppen strengere Einschränkungen benötigen.

3. Remote-Support-Werkzeuge begrenzen

Tools wie Quick Assist, AnyDesk, TeamViewer, DWAgent oder ähnliche Lösungen sollten nicht unkontrolliert nutzbar sein.

Es braucht eine klare Liste erlaubter Support-Tools. Alles andere sollte blockiert oder zumindest überwacht werden.

4. MFA-Änderungen überwachen

Wenn ein Angreifer ein eigenes MFA-Gerät hinzufügen kann, ist das Konto faktisch übernommen.

Neue MFA-Methoden sollten überwacht werden. Besonders bei privilegierten Konten braucht es zusätzliche Schutzmaßnahmen und klare Freigabeprozesse.

5. Tiering konsequent umsetzen

Der wichtigste Schutz gegen Folgeschäden ist eine saubere Architektur.

Standard-Clients dürfen kein Sprungbrett zu kritischen Systemen sein. Admin-Konten gehören nicht auf normale Arbeitsplätze. Administrative Zugriffe müssen getrennt, kontrolliert und nachvollziehbar erfolgen.

Tiering verhindert nicht jeden Angriff. Aber es begrenzt den Schaden massiv.

6. Mitarbeitende auf Teams-Phishing vorbereiten

Awareness darf nicht bei E-Mail enden.

Mitarbeitende müssen wissen, dass Phishing auch über Teams, Telefon, Kalender, Messenger und Remote-Support-Anfragen stattfinden kann.

Eine einfache Botschaft sollte jeder kennen:

Die IT fragt niemals nach Passwörtern, fordert keine Eingabe in Textdateien und lässt keine unbekannten MFA-Geräte hinzufügen.

Fazit

Microsoft Teams ist längst Teil der Angriffsfläche.

Angreifer nutzen die Plattform, weil sie dort Vertrauen, Geschwindigkeit und direkte Interaktion finden. Sie geben sich als IT-Support aus, starten Bildschirmfreigaben, manipulieren Benutzer und versuchen anschließend, sich im Netzwerk weiterzubewegen.

Die Methode ist nicht neu. Sie wurde bereits in realen Kundenumgebungen beobachtet. Der Unterschied zwischen einem begrenzten Vorfall und einem großen Schaden liegt oft nicht allein in der Detection, sondern in der vorbereiteten Sicherheitsarchitektur.

Deshalb reicht es nicht, nur auf XDR, EDR oder SIEM zu setzen.

Unternehmen brauchen einen ganzheitlichen Ansatz:

Teams härten. Externe Kommunikation begrenzen. Remote Tools kontrollieren. MFA-Änderungen überwachen. Tiering umsetzen. Admin-Zugriffe trennen. Mitarbeitende sensibilisieren.

Die entscheidende Frage lautet nicht:

„Haben wir einen Alarm, wenn etwas passiert?“

Die bessere Frage lautet:

„Wie weit kommt ein Angreifer, wenn ein Benutzer auf einen vermeintlichen Teams-Supportkontakt hereinfällt?“

Eine aktuelle Sicherheitsanalyse zu Microsoft Edge zeigt sehr deutlich, warum ich seit Jahren davor warne, Browser in Unternehmensumgebungen ungehärtet zu betreiben.

Der konkrete Vorwurf ist brisant: Microsoft Edge soll gespeicherte Passwörter bereits beim Start des Browsers vollständig in den Prozessspeicher laden und dort im Klartext vorhalten. Nicht erst dann, wenn der Benutzer die passende Webseite besucht. Nicht erst dann, wenn ein Login-Formular automatisch ausgefüllt wird. Sondern direkt nach dem Start des Browsers.

Damit entsteht ein dauerhaftes Ziel im Arbeitsspeicher.

Besonders kritisch: Zu der Analyse wurde auch ein Proof-of-Concept veröffentlicht. Dieses Tool, in Berichten unter anderem als EdgeSavedPasswordsDumper beschrieben, demonstriert, dass gespeicherte Zugangsdaten aus laufenden Edge-Prozessen ausgelesen werden können, wenn ein Angreifer den Prozessspeicher lesen darf. Laut Berichten wurde in einer Demonstration gezeigt, dass auf einem gemeinsam genutzten System sogar Zugangsdaten aus mehreren angemeldeten beziehungsweise getrennten Benutzersitzungen extrahiert werden konnten.

Und genau hier wird aus einer technischen Designentscheidung ein echtes Unternehmensrisiko.

Worum geht es bei der aktuellen Schwachstelle?

Browser-Passwortmanager speichern Zugangsdaten normalerweise verschlüsselt auf dem Datenträger. Das klingt zunächst beruhigend. Viele Benutzer gehen deshalb davon aus, dass ihre gespeicherten Passwörter sicher sind.

Das Problem liegt aber nicht nur auf der Festplatte.

Das Problem liegt zur Laufzeit.

Wenn Microsoft Edge beim Start alle gespeicherten Zugangsdaten entschlüsselt und im Klartext im Arbeitsspeicher des Browserprozesses vorhält, dann hilft die Verschlüsselung auf dem Datenträger im konkreten Angriffsszenario nur noch begrenzt. Denn der Angreifer muss dann nicht zwingend die Passwortdatenbank sauber entschlüsseln. Er kann versuchen, den laufenden Prozessspeicher auszulesen.

Genau dieses Verhalten wurde nun öffentlich thematisiert. Laut Cybersecurity News lädt Edge die gespeicherten Passwörter beim Browserstart in den Prozessspeicher und hält sie dort im Klartext vor — unabhängig davon, ob die jeweilige Webseite überhaupt verwendet wird. Heise beschreibt ebenfalls einen einfachen Test: Passwort im Edge-Passwortmanager gespeichert, Browser neu gestartet, Speicherabbild erzeugt, Klartext-Passwort im Dump gefunden.

Das ist aus Unternehmenssicht kein Detailproblem. Das ist genau die Art von Verhalten, die Angreifer lieben.

Die EXE macht das Risiko greifbar

Der veröffentlichte Proof-of-Concept ist deshalb so relevant, weil er das Problem aus der Theorie in die Praxis holt.

Solange über „Passwörter im Arbeitsspeicher“ gesprochen wird, klingt das für viele Entscheider abstrakt. Sobald aber eine ausführbare Datei beziehungsweise ein Demonstrationswerkzeug zeigt, dass gespeicherte Zugangsdaten aus laufenden Edge-Prozessen extrahiert werden können, wird das Risiko greifbar.

Wichtig ist dabei: Ein solches Tool ist nicht automatisch ein magischer Generalschlüssel. Ein Angreifer benötigt passende Rechte und Zugriff auf das System beziehungsweise auf die relevanten Prozesse. Aber genau das ist in realen Angriffsketten kein unrealistisches Szenario.

Nach einer erfolgreichen Kompromittierung suchen Angreifer fast immer nach Zugangsdaten. Credential Dumping ist ein Standardziel in Post-Exploitation-Szenarien. Passwörter, Tokens, Cookies, Sessions und Browserdaten sind für Angreifer extrem wertvoll, weil sie laterale Bewegung, Cloud-Zugriffe und Zugriff auf Fachanwendungen ermöglichen.

Wenn der Browser gespeicherte Kennwörter bereits im Klartext im Speicher bereithält, wird dem Angreifer die Arbeit erleichtert.

„By Design“ ist kein Freifahrtschein

Microsoft soll das Verhalten als „by design“ eingeordnet haben. Auch Microsofts eigene Dokumentation zu Browser-Sicherheit und Richtlinien macht deutlich, dass Browser über zentrale Policies in Unternehmen gesteuert werden können und sollten.

Das Argument „by design“ ist technisch nicht automatisch falsch. Hersteller definieren Threat Models. Häufig gilt: Wenn ein Angreifer bereits im lokalen Benutzerkontext oder mit administrativen Rechten auf dem System aktiv ist, liegt das Problem außerhalb des engeren Browser-Sicherheitsmodells.

Für die Praxis reicht diese Sichtweise aber nicht.

Professionelle IT-Sicherheit besteht aus mehreren Schutzschichten. Wenn ein Angreifer eine Schicht überwindet, darf nicht automatisch alles offenliegen. Genau deshalb gibt es Least Privilege, Applikationskontrolle, MFA, Conditional Access, Privileged Access Workstations, Credential Guard, EDR, Monitoring und Netzwerksegmentierung.

Ein integrierter Browser-Kennwortmanager, der alle gespeicherten Passwörter komfortabel im Speicher verfügbar hält, passt in vielen Unternehmensszenarien nicht zu diesem Schutzgedanken.

Er reduziert Reibung für Benutzer.

Leider reduziert er auch Reibung für Angreifer.

Die Re-Authentifizierung täuscht Sicherheit vor

Viele Benutzer kennen die Funktion: Wenn gespeicherte Passwörter im Browser angezeigt werden sollen, verlangt Edge eine erneute Authentifizierung, zum Beispiel über Windows Hello oder eine Windows-Anmeldung.

Das sieht sicher aus.

Aber genau hier liegt der Widerspruch.

Wenn die Zugangsdaten bereits im Klartext im Prozessspeicher liegen, schützt diese Abfrage in erster Linie die Oberfläche des Passwortmanagers. Sie verhindert nicht automatisch, dass ein Angreifer mit passenden Rechten den Speicher des Browserprozesses ausliest.

Die Benutzeroberfläche sagt: „Du musst dich erneut authentifizieren.“

Der Prozessspeicher sagt im schlechtesten Fall: „Die Daten sind bereits da.“

Das ist ein gefährlicher Unterschied zwischen gefühlter Sicherheit und tatsächlicher Schutzwirkung.

Terminalserver, RDS und Citrix: Der Jackpot für Angreifer

Besonders kritisch wird das Thema in geteilten Umgebungen wie Terminalservern, Remote Desktop Services, Citrix-Systemen oder anderen Multi-User-Plattformen.

Dort arbeiten mehrere Benutzer auf derselben Maschine oder Plattform. Es laufen mehrere Sitzungen, mehrere Browserprozesse, mehrere Benutzerprofile und häufig Zugriffe auf zentrale Fachanwendungen, Cloud-Portale, Kundensysteme oder Administrationsoberflächen.

Wenn in einer solchen Umgebung Browser-Kennwortmanager erlaubt sind, entsteht ein hochattraktives Ziel.

Für einen Angreifer ist das ein Jackpot.

Ein kompromittierter Terminalserver ist ohnehin ein schwerwiegender Vorfall. Wenn dort aber zusätzlich gespeicherte Browser-Passwörter im Klartext im Speicher laufender Prozesse verfügbar sind, kann aus einem einzelnen kompromittierten System eine Sammelstelle für Zugangsdaten werden.

Besonders gefährlich sind getrennte, aber weiterhin aktive Sitzungen. Benutzer melden sich oft nicht sauber ab, sondern trennen nur die Verbindung. Der Prozess läuft weiter. Der Browser bleibt geöffnet oder wird später wiederhergestellt. Die Sitzung bleibt ein lohnendes Ziel.

In solchen Umgebungen darf es aus meiner Sicht keine Diskussion geben:

Integrierte Browser-Kennwortmanager gehören auf Terminalservern, RDS-Hosts, Citrix-Systemen und VDI-Umgebungen deaktiviert.

Das eigentliche Problem ist größer als Microsoft Edge

Auch wenn die aktuelle Meldung Microsoft Edge betrifft, wäre es falsch, das Thema nur auf einen einzelnen Browser zu reduzieren.

Das eigentliche Problem ist grundsätzlicher: Viele Unternehmen behandeln Browser noch immer nicht als sicherheitskritische Anwendung.

Dabei ist der Browser heute der zentrale Zugangspunkt zu:

• Microsoft 365
• Entra ID
• Azure-Portalen
• CRM-Systemen
• ERP-Anwendungen
• Helpdesk-Systemen
• Cloud-Speichern
• Banking-Portalen
• internen Webanwendungen
• Administrationsoberflächen
• Kundensystemen

Wer den Browser kompromittiert oder dort gespeicherte Zugangsdaten auslesen kann, braucht oft keinen klassischen Domain-Admin mehr. Der Zugriff erfolgt dann direkt über legitime Webportale.

Deshalb sage ich seit Jahren: Browser dürfen in Unternehmensumgebungen nicht ungehärtet betrieben werden.

Und zur Härtung gehört ganz klar die Deaktivierung der integrierten Kennwortmanager.

Was Unternehmen jetzt konkret tun müssen

Die richtige Reaktion ist nicht, abzuwarten, ob Microsoft das Verhalten irgendwann ändert.

Die richtige Reaktion ist, die eigene Umgebung sofort zu prüfen und Browser-Härtung verbindlich umzusetzen.

1. Browser-Passwortmanager sofort prüfen

Unternehmen sollten kurzfristig prüfen:

• Ist der Edge-Passwortmanager aktiv?
• Können Benutzer Passwörter im Browser speichern?
• Gibt es gespeicherte Passwörter in bestehenden Profilen?
• Ist Autofill für Zugangsdaten aktiv?
• Werden Passwörter über Browserprofile synchronisiert?
• Gilt das auch auf Terminalservern, RDS, Citrix oder VDI?
• Gibt es unterschiedliche Regeln für Clients, Server und Admin-Systeme?

Gerade auf Terminalservern sollte diese Prüfung höchste Priorität haben.

2. Speichern von Passwörtern im Browser deaktivieren

Der integrierte Passwortmanager sollte in Unternehmensumgebungen per Richtlinie deaktiviert werden.

Für Microsoft Edge lässt sich das zentral über Gruppenrichtlinien, Intune, MDM oder andere Managementsysteme steuern. Microsoft stellt dafür umfangreiche Browser-Policies bereit, mit denen Unternehmen das Verhalten von Edge zentral konfigurieren können.

Wichtig ist: Es reicht nicht, Benutzer zu bitten, keine Passwörter zu speichern.

Das muss technisch verhindert werden.

3. Bereits gespeicherte Passwörter entfernen

Wenn der Passwortmanager deaktiviert wird, sollte zusätzlich geprüft werden, ob bereits gespeicherte Zugangsdaten in vorhandenen Browserprofilen liegen.

Sonst bleibt ein Altbestand bestehen, der weiterhin ein Risiko darstellen kann.

Hier braucht es ein sauberes Vorgehen:

• Bestandsaufnahme
• Kommunikation an Benutzer
• Migration in einen Enterprise-Passwortmanager
• Entfernung gespeicherter Browser-Passwörter
• technische Sperre gegen erneutes Speichern

Gerade dieser Punkt wird in der Praxis häufig vergessen. Eine Policy für die Zukunft ist gut. Aber sie löst nicht automatisch das Problem bereits gespeicherter Zugangsdaten.

4. Enterprise-Passwortmanager einsetzen

Wenn Benutzer viele Passwörter verwalten müssen, braucht es eine dafür geeignete Lösung.

Ein Enterprise-Passwortmanager sollte mindestens bieten:

• zentrale Verwaltung
• MFA
• Rollen- und Rechtekonzept
• Auditierung
• sicheres Teilen von Zugangsdaten
• Offboarding-Prozesse
• Richtlinien für Passwortqualität
• Zugriffskontrolle
• Trennung privater und geschäftlicher Zugangsdaten

Ein Browser-Passwortmanager ist kein Ersatz für ein professionelles Passwortmanagement.

5. Autofill restriktiv behandeln

Autofill ist bequem, aber ebenfalls kritisch. Automatisch ausgefüllte Zugangsdaten können missbraucht werden, insbesondere bei Phishing, manipulierten Formularen oder kompromittierten Webseiten.

In sensiblen Bereichen sollte Autofill deaktiviert oder stark eingeschränkt werden.

Das gilt besonders für:

• Admin-Portale
• Cloud-Management
• Banking
• Kundensysteme
• Fachanwendungen mit sensiblen Daten
• Terminalserver
• gemeinsam genutzte Arbeitsplätze

6. Browser-Synchronisation kontrollieren

Browser-Synchronisation kann ein weiteres Risiko sein.

Wenn Passwörter, Favoriten, Erweiterungen, Formulardaten und Einstellungen über private Konten oder unkontrollierte Profile synchronisiert werden, verliert die Organisation die Kontrolle über geschäftliche Daten.

Deshalb sollten Unternehmen klar regeln:

• Welche Konten dürfen im Browser angemeldet werden?
• Ist private Synchronisation erlaubt?
• Welche Daten dürfen synchronisiert werden?
• Sind geschäftliche Profile verpflichtend?
• Werden private Microsoft- oder Google-Konten blockiert?

Private Browser-Synchronisation hat auf Unternehmenssystemen nichts verloren.

7. Erweiterungen zentral verwalten

Browser-Erweiterungen sind eine massive Angriffsfläche.

Sie können Webseiteninhalte lesen, Formulare beeinflussen, Daten übertragen, Sitzungen manipulieren oder Benutzerverhalten auswerten. Deshalb sollten Erweiterungen nicht frei installierbar sein.

Empfehlung:

• Allowlist statt freier Installation
• Blocklist für bekannte Risiken
• regelmäßige Prüfung installierter Erweiterungen
• getrennte Regeln für Standardbenutzer und Administratoren
• keine privaten Erweiterungen auf Unternehmenssystemen

8. Terminalserver und RDS besonders absichern

Für Terminalserver, RDS, Citrix und VDI müssen strengere Regeln gelten als für normale Clients.

Dort sollten mindestens umgesetzt werden:

• Browser-Passwortmanager deaktivieren
• Autofill deaktivieren oder einschränken
• Browser-Synchronisation deaktivieren
• private Konten blockieren
• Erweiterungen zentral verwalten
• Sitzungen sauber beenden
• getrennte Profile kontrollieren
• lokale Administratorrechte stark begrenzen
• Monitoring auf verdächtige Prozesszugriffe
• EDR-Regeln für Credential-Dumping-Verhalten
• regelmäßige Bereinigung alter Profile

Ein Terminalserver ist kein normaler Arbeitsplatz. Er ist ein Konzentrator von Risiko.

9. Admin-Zugriffe vom Alltag trennen

Administrative Tätigkeiten gehören nicht in denselben Browserkontext wie normales Arbeiten.

Admin-Portale sollten über getrennte, gehärtete Umgebungen genutzt werden:

• separate Admin-Konten
• separate Browserprofile
• Privileged Access Workstations
• Conditional Access
• MFA
• keine Passwortspeicherung
• keine privaten Erweiterungen
• keine parallele Alltagsnutzung

Wer mit demselben Browser gleichzeitig Mails liest, Webseiten besucht und Admin-Portale öffnet, schafft unnötige Angriffsfläche.

10. Browser-Härtung regelmäßig überprüfen

Browser ändern sich ständig. Neue Funktionen kommen hinzu. Richtlinien ändern sich. Hersteller passen Standardverhalten an. Neue Synchronisations-, KI- oder Komfortfunktionen werden aktiviert.

Deshalb reicht es nicht, Browser-Härtung einmal einzurichten und dann jahrelang nicht mehr anzufassen.

Browser-Policies gehören regelmäßig geprüft.

Mindestens bei:

• neuen Browser-Versionen
• neuen Unternehmensanforderungen
• Einführung von M365-/Cloud-Diensten
• RDS-/VDI-Projekten
• Security-Audits
• Kunden- oder Compliance-Anforderungen
• bekannten Schwachstellen oder neuen PoCs

Die falsche Frage: „Ist das wirklich eine Schwachstelle?“

In Diskussionen zu solchen Themen kommt oft schnell die Frage auf, ob es sich im engeren Sinne um eine Schwachstelle handelt.

Diese Frage ist für die Praxis zweitrangig.

Die bessere Frage lautet:

Will ich als Unternehmen, dass gespeicherte Unternehmenspasswörter in Browserprofilen und laufenden Browserprozessen verfügbar sind?

Meine Antwort ist klar: Nein.

Gerade in professionellen IT-Umgebungen darf man sich nicht auf Standardkonfigurationen verlassen. Standards sind auf breite Nutzbarkeit ausgelegt. Nicht auf das höchste Sicherheitsniveau für jede Unternehmensumgebung.

Für private Benutzer mag ein integrierter Browser-Kennwortmanager ein akzeptabler Komfortkompromiss sein. Für Unternehmensumgebungen, Terminalserver, Administratoren und geteilte Systeme ist dieser Kompromiss aus meiner Sicht nicht tragbar.

Fazit: Die aktuelle Edge-Schwachstelle ist ein Weckruf

Die aktuelle Diskussion um Microsoft Edge zeigt sehr deutlich, was ich seit Jahren sage:

Browser sind keine harmlose Standardsoftware mehr.

Sie sind zentrale Zugangspunkte zu Unternehmensdaten, Cloud-Diensten, Fachanwendungen und Administrationsoberflächen. Wer Browser nicht härtet, lässt eine der wichtigsten Anwendungen im Unternehmen weitgehend unkontrolliert.

Die veröffentlichte EXE beziehungsweise der Proof-of-Concept macht das Risiko greifbar: Gespeicherte Passwörter im Browser sind nicht nur ein theoretisches Problem. Sie können im falschen Szenario zu einem direkten Ziel für Credential Dumping werden.

Besonders auf Terminalservern, RDS-, Citrix- und VDI-Systemen ist das brandgefährlich.

Deshalb müssen Unternehmen jetzt handeln:

Browser-Passwortmanager deaktivieren. Bereits gespeicherte Passwörter entfernen. Enterprise-Passwortmanager einsetzen. Browser zentral härten. Terminalserver gesondert absichern. Admin-Zugriffe trennen.

Bequemlichkeit darf nicht über Sicherheit stehen.

Der Browser ist heute nicht mehr nur ein Werkzeug zum Surfen.

Er ist ein sicherheitskritischer Zugangspunkt zum Unternehmen.

Und genau so muss er behandelt werden.

Im Juli 2026 führt Microsoft eine Änderung in Exchange Online ein, die auf den ersten Blick wie eine kleine DNS-Anpassung wirkt, tatsächlich aber ein wichtiger Schritt für eine stärkere Sicherheitsarchitektur im E-Mail-Transport ist.

Bei neuen akzeptierten Domains werden MX-Records künftig nicht mehr unter
*.mail.protection.outlook.com
bereitgestellt, sondern unter
*.mx.microsoft.

Diese Änderung schafft die Grundlage für eine saubere DNSSEC-Vertrauenskette und eine bessere Unterstützung von SMTP DANE, wodurch die Sicherheit beim Versand von E-Mails deutlich verbessert werden kann.

---

Warum diese Änderung wichtig ist

Die Anpassung betrifft nicht das Routing von E-Mails, sondern die zugrunde liegende Sicherheitsarchitektur.
Der bisherige MX-Namespace erschwerte es, eine durchgängige DNSSEC-Trust-Chain bis in die Microsoft-Mailinfrastruktur aufzubauen.

Mit dem neuen Namespace kann Microsoft künftig:

• MX-Endpunkte besser mit DNSSEC-fähiger Infrastruktur verknüpfen
• TLSA-Records für SMTP DANE sauber bereitstellen
• die Identität von Mailservern während der TLS-Verhandlung zuverlässiger prüfen

Das Ziel ist eine stärkere Absicherung der Transportverschlüsselung zwischen Mailservern.

---

Hintergrund: TLS ohne verpflichtende Validierung reicht nicht mehr aus

Der überwiegende Teil des E-Mail-Verkehrs im Internet verwendet weiterhin TLS ohne verpflichtende Servervalidierung.
Dabei wird die Verbindung zwar verschlüsselt, aber das Zielsystem wird nicht streng authentifiziert.

Das eröffnet theoretisch Angriffsflächen, zum Beispiel durch:

• DNS-Manipulation
• Downgrade-Angriffe
• Man-in-the-Middle-Angriffe
• kompromittierte Zertifikate

Hier setzen DNSSEC und SMTP DANE an.

DNSSEC

• signiert DNS-Antworten kryptografisch
• verhindert DNS-Spoofing
• stellt sicher, dass MX-Einträge authentisch sind

SMTP DANE

• veröffentlicht TLS-Informationen über DNS (TLSA-Records)
• nutzt DNSSEC zur Absicherung
• stellt sicher, dass Mailserver nur mit verifizierter Infrastruktur kommunizieren
• verhindert TLS-Downgrades und Man-in-the-Middle-Angriffe

Der neue Namespace mx.microsoft erleichtert es Microsoft, eine vollständige DNSSEC-Trust-Chain bis zu Exchange Online aufzubauen und damit eine stärkere Validierung des Mailtransports zu ermöglichen.

---

Was Administratoren jetzt tun sollten

Für die meisten Tenants ist keine sofortige Aktion erforderlich.
Die Änderung betrifft zunächst nur neu hinzugefügte akzeptierte Domains.

Trotzdem ist dies ein guter Zeitpunkt, die eigene Mail-Security zu überprüfen.

Empfohlene Checks

• Prüfen, ob die eigene DNS-Zone mit DNSSEC signiert ist
• Sicherstellen, dass Skripte oder Automatisierungen kein festes MX-Format erwarten
• Mail-Transport mit DNSSEC- / DANE-Testtools überprüfen
• Monitoring für MX- und TLS-Validierung aktivieren

---

Wichtiger Hinweis

Bestehende Domains sollten durch diese Änderung nicht beeinträchtigt werden.
Probleme können jedoch auftreten, wenn Umgebungen auf hart codierte MX-Hostnamen, Validierungsregeln oder alte Automatisierungsskripte angewiesen sind.

Gerade in größeren oder stark automatisierten Microsoft-365-Umgebungen empfiehlt es sich daher, die Kompatibilität frühzeitig zu prüfen.

---

Fazit

Die Umstellung auf *.mx.microsoft ist keine kosmetische Änderung, sondern ein strategischer Schritt hin zu:

• stärkerer Transportverschlüsselung
• verifizierbaren Mailserver-Identitäten
• besserer DNSSEC-Integration
• breiterer Unterstützung von SMTP DANE

Damit schafft Microsoft eine wichtige Grundlage für einen deutlich sichereren E-Mail-Transport im Microsoft-365-Ökosystem.

Einleitung

Zwischen „TLS wird schon irgendwie genutzt“ und wirklich belastbarer Transportsicherheit liegt im Mailflow ein großer Unterschied. Genau in dieser Lücke bewegen sich SMTP DANE und MTA-STS. Microsoft hat am 10. März 2026 angekündigt, dass sich diese Sicherheitsmechanismen in Exchange Online nun auch gezielt über Outbound Connectors steuern lassen. Das ist vor allem für Partnerstrecken, Smart-Host-Szenarien und regulierte Kommunikationspfade relevant.

Wichtig ist die Einordnung: SMTP DANE mit DNSSEC und MTA-STS sind im ausgehenden Pfad von Exchange Online bereits standardmäßig aktiv. Neu ist nicht die generelle Existenz der Protokolle, sondern die Möglichkeit, ihr Verhalten pro Outbound Connector bewusster zu steuern. Damit wird aus einer Plattformfunktion ein Architektur- und Betriebshebel für konkrete Routing-Szenarien.

Was bedeutet das?

Die neue Konstellation betrifft vor allem Organisationen, die E-Mails nicht ausschließlich über den Standardpfad von Exchange Online zustellen. Sobald domänenspezifische Outbound Connectors, Partner-Connectoren oder Smart Hosts im Spiel sind, entsteht die Frage, wie strikt Exchange Online die Transportabsicherung auf genau diesen Routen prüfen soll. Genau dafür sind die neuen Connector Modes gedacht.

Für die Praxis heißt das: Sicherheitsvorgaben lassen sich besser an den jeweiligen Kommunikationspfad anpassen. Gleichzeitig steigt die Verantwortung in Design und Betrieb, denn ein zu lockerer Modus reduziert die Schutzwirkung, während ein zu strenger Modus zu Warteschlangen, NDRs und im Fehlerfall zu verworfenen Nachrichten führen kann.

Was ist SMTP DANE?

SMTP DANE erweitert den SMTP-Transport um eine kryptografisch abgesicherte Vertrauenskette auf Basis von DNSSEC und TLSA-Records. Vereinfacht gesagt prüft der sendende Server nicht nur, ob TLS möglich ist, sondern auch, ob der angesprochene Zielserver tatsächlich der erwartete Mailserver für die Domain ist und ob dessen Zertifikat zu den veröffentlichten TLSA-Informationen passt. Damit wird ein Teil des Risikos adressiert, das bei rein opportunistischem TLS durch DNS-Manipulation oder Man-in-the-Middle-Angriffe bestehen bleibt.

Wenn für eine Ziel-Domain kein TLSA-Record vorhanden ist, läuft der Mailflow grundsätzlich ohne DANE-Prüfung weiter. Wenn die Domain jedoch DANE signalisiert und die DNSSEC- oder TLSA-Prüfung fehlschlägt, kann Exchange Online die Zustellung zurückstellen oder blockieren. Microsoft dokumentiert dafür unter anderem Fehlerbilder wie tlsa-invalid, dnssec-invalid, starttls-not-supported oder Zertifikat-Host-Mismatch.

Was ist MTA-STS?

MTA-STS verfolgt dasselbe Ziel wie DANE: den Schutz des SMTP-Transports gegen Downgrade- und Man-in-the-Middle-Angriffe. Technisch funktioniert es aber anders. Statt auf DNSSEC und TLSA zu setzen, veröffentlicht die Ziel-Domain per DNS-TXT-Eintrag einen Hinweis auf eine per HTTPS bereitgestellte Richtlinie. Diese Policy definiert, welche MX-Hosts erwartet werden, ob TLS erzwungen werden soll und wie lange die Richtlinie gecacht werden darf.

Für Exchange Online ist relevant, dass MTA-STS im ausgehenden Pfad Teil der Sicherheitsinfrastruktur ist. Bei Smart-Host-basierten Outbound Connectors prüft Exchange Online MTA-STS nicht gegen die finale Empfängerdomain, sondern gegen die Smart-Host-Domain. Das ist ein wichtiger Punkt, weil sich dadurch die Vertrauenskette an der tatsächlichen Routing-Architektur orientiert.

Der Unterschied zwischen SMTP DANE und MTA-STS

Beide Standards schließen Sicherheitslücken, die opportunistisches TLS allein nicht abdeckt. Der wesentliche Unterschied liegt im Vertrauensmodell: DANE stützt sich auf DNSSEC und TLSA, MTA-STS auf Zertifizierungsstellen sowie eine per HTTPS veröffentlichte Richtlinie. Microsoft beschreibt ausdrücklich, dass beide Protokolle demselben Zweck dienen, aber unterschiedliche technische Grundlagen nutzen.

Für Architekturentscheidungen ist das mehr als ein Protokolldetail. DANE ist besonders stark, wenn DNSSEC sauber betrieben wird. MTA-STS ist oft einfacher in bestehende Web- und Zertifikatsprozesse einzubetten. In hybriden oder partnerbezogenen Szenarien ist deshalb nicht nur wichtig, welches Protokoll sicherer wirkt, sondern welches entlang der gesamten Route sauber betrieben und dauerhaft überwacht werden kann. Diese Einordnung ist eine fachliche Schlussfolgerung auf Basis der von Microsoft beschriebenen Vertrauensmodelle und Betriebsanforderungen.

Was ist an den neuen Connector Modes in Exchange Online neu?

Für Outbound Connectors dokumentiert Microsoft jetzt zwei steuerbare Parameter: SmtpDaneMode und MtaStsMode. Für SMTP DANE sind die Werte Opportunistic, Mandatory und None verfügbar. Für MTA-STS sind die Werte Opportunistic und None dokumentiert. In beiden Fällen ist Opportunistic der Standardwert.

Bei SmtpDaneMode=Opportunistic nutzt Exchange Online DANE, wenn die Ziel-Domain DANE mit DNSSEC unterstützt. Wenn die Domain DANE nicht unterstützt, wird die Nachricht mit den Connector- oder Standard-Einstellungen zugestellt. Unterstützt die Domain DANE, aber die Validierung scheitert, stellt Exchange Online die Nachricht bis zu 24 Stunden zurück, versucht gegebenenfalls auf einen sekundären MX auszuweichen und verwirft die Nachricht anschließend, wenn die Validierung weiterhin fehlschlägt. Mit Mandatory wird DANE für diesen Connector zur Pflicht, also auch dann zum Zustellhindernis, wenn die Ziel-Domain DANE gar nicht anbietet.

Bei MtaStsMode=Opportunistic verhält sich Exchange Online ähnlich zurückhaltend, aber mit einer wichtigen Besonderheit: Es gibt hier keinen separaten Mandatory-Wert auf Connector-Ebene. Die harte Wirkung entsteht dann, wenn die Ziel-Domain selbst eine MTA-STS-Policy im Modus enforce veröffentlicht und die Validierung fehlschlägt. Dann wird die Nachricht bis zu 24 Stunden erneut versucht und anschließend verworfen. None deaktiviert die Prüfung, senkt laut Microsoft aber ausdrücklich die Sicherheit und kann Umleitungen oder Abfangen von Nachrichten begünstigen.

Genau diese Unterscheidung ist für die Beratung wichtig: SMTP DANE kann auf Connector-Ebene explizit verpflichtend gemacht werden. MTA-STS lässt sich auf Connector-Ebene dagegen nur opportunistisch nutzen oder abschalten. Wer beide Protokolle gedanklich gleich behandelt, übersieht einen entscheidenden Architekturunterschied.

Was sollte man beachten und tun?

Outbound Connectors zuerst fachlich klassifizieren

Nicht jeder Connector braucht dieselbe Strenge. Zuerst sollte klar sein, welche Connectoren sicherheitskritische Partnerkommunikation, regulierte Mailflows oder Smart-Host-Routen bedienen und welche nur technische Sonderwege abbilden. Erst danach ergibt eine Entscheidung über Opportunistic, Mandatory oder None fachlich Sinn. Die Dokumentation der Parameter zeigt, dass diese Entscheidung direkte Auswirkungen auf Zustellverhalten und Sicherheitsniveau hat.

None nur als bewusste Ausnahme behandeln

Microsoft weist bei None für beide Protokolle ausdrücklich auf reduzierte Sicherheit sowie das Risiko von Umleitung oder Abfangen durch bösartige Gegenstellen hin. Daraus folgt für Governance und Beratung: None sollte kein bequemer Standard sein, sondern eine dokumentierte Ausnahme mit klarer Begründung, etwa für temporäre Interoperabilitätsprobleme. Diese Empfehlung ist eine unmittelbare Ableitung aus Microsofts Risikobeschreibung.

Smart-Host-Szenarien sauber prüfen

Gerade bei Partner- oder Gateway-Routen ist die technische Realität oft komplexer als das Ziel-Domain-Modell. Für MTA-STS dokumentiert Microsoft ausdrücklich, dass bei Smart-Host-Connectoren gegen die Smart-Host-Domain validiert wird. Wer diesen Punkt im Design übersieht, bewertet Fehlermeldungen falsch oder setzt die falschen Erwartungen an die Gegenstelle.

Monitoring und Troubleshooting vorbereiten

Für den operativen Betrieb ist der Bericht Outbound messages in Transit Security relevant. Dort zeigt Exchange Online Daten zu DANE, MTA-STS, TLS-Only und No TLS sowie blockierte Nachrichten aufgrund von Validierungsfehlern. Ergänzend helfen NDR- und SMTP-Fehlercodes wie 5.4.8, 5.7.5, 4.7.323 oder 4.7.324, um zwischen Policy-, Zertifikats-, DNSSEC- und TLSA-Problemen zu unterscheiden.

Eigene Domains auf Eingangsseite sauber vorbereiten

Wer nicht nur ausgehend sicher senden, sondern auch eingehend geschützt empfangen will, sollte die eigene Domain-Konfiguration prüfen. Für MTA-STS beschreibt Microsoft die notwendige Kombination aus TXT-Record und HTTPS-Policy. Für DNSSEC- und DANE-bezogene Prüfungen stellt Exchange Online zudem das Cmdlet Get-DnssecStatusForVerifiedDomain bereit, das DNS-, MX- und MTA-STS-bezogene Validierungen für akzeptierte Domains sichtbar macht.

Fazit

Die Ankündigung zu SMTP DANE- und MTA-STS-Connector-Modes in Exchange Online ist kein kleines Transport-Detail, sondern eine relevante Erweiterung für alle Organisationen mit differenziertem Mailrouting. Der eigentliche Mehrwert liegt darin, Sicherheitsmechanismen nicht nur global hinzunehmen, sondern pro Connector bewusst in die Mailflow-Architektur einzubauen.

Wer Exchange Online mit Partner-Connectoren, Smart Hosts oder streng regulierten Kommunikationspfaden betreibt, sollte diese neuen Steuerungsmöglichkeiten jetzt in Designstandards, Betriebsdokumentation und Fehlerszenarien aufnehmen. Besonders wichtig ist dabei die saubere Trennung zwischen DANE und MTA-STS, weil beide zwar dasselbe Ziel verfolgen, in Exchange Online aber nicht identisch gesteuert werden.

Mit der Veröffentlichung der aktuellen Exchange Server Sicherheitsupdates macht Microsoft erneut deutlich, wie kritisch der sichere Betrieb von On-Premises-E-Mail-Systemen ist. Auch wenn aktuell keine aktiv ausgenutzten Angriffe gemeldet wurden, ist die Botschaft klar: Ungepatchte oder nicht mehr unterstützte Exchange-Server stellen ein erhebliches Risiko dar.

Für Unternehmen bedeutet das konkret:

Entweder Exchange Server Subscription Edition (SE) einsetzen – oder zwingend am ESU-Programm teilnehmen.

Alles andere ist aus Sicherheits- und Compliance-Sicht nicht mehr vertretbar.

Was bedeutet die aktuelle Sicherheitsupdate-Ankündigung?

Microsoft stellt Sicherheitsupdates inzwischen primär für Exchange Server Subscription Edition (SE) bereit.

Für Exchange Server 2016 und 2019 gilt:

• Sicherheitsupdates gibt es nur noch im Rahmen des kostenpflichtigen Extended Security Update (ESU) Programms
• Ohne ESU-Teilnahme erhalten diese Versionen keine weiteren Security Updates
• Das ESU-Programm ist zeitlich befristet und endet spätestens im April 2026

Damit ist klar: Exchange 2016/2019 befinden sich faktisch im End-of-Life-Betrieb – selbst wenn sie technisch noch laufen.

Warum Unternehmen längst auf Exchange SE umgestellt haben sollten

Als IT-Consultant sehe ich in Projekten immer wieder dieselbe Situation:

Exchange funktioniert „noch“, also wird das Thema Migration aufgeschoben. Genau das ist gefährlich.

1. Sicherheitsrisiko

Exchange war in den letzten Jahren regelmäßig Ziel großflächiger Angriffe. Ein ungepatchter Server ist kein isoliertes Risiko, sondern oft ein Einstiegspunkt ins gesamte Unternehmensnetzwerk.

2. Compliance & Audit-Fähigkeit

Viele Standards (ISO 27001, TISAX, NIS2, interne Audits) verlangen:

• Hersteller-Support
• zeitnahe Sicherheitsupdates
• dokumentierte Patch-Prozesse

Ein Exchange ohne Support oder ESU ist hier nicht mehr verteidigungsfähig.

3. Exchange SE ist der neue Standard

Microsoft hat die Richtung klar vorgegeben:

• Exchange Server SE ist die einzige On-Premises-Version mit langfristigem Update-Pfad
• Regelmäßige Sicherheitsupdates
• Planbare Wartung
• Keine Sonderprogramme oder Ausnahmen mehr nötig

Kurz gesagt: SE ist kein „Upgrade“, sondern der neue Normalzustand.

Was ist das ESU-Programm – und wann ist es sinnvoll?

Das Extended Security Update (ESU) Programm ist eine Übergangslösung für Unternehmen, die aus organisatorischen oder technischen Gründen noch nicht auf Exchange SE migriert sind.

Was ESU bietet:

• Sicherheitsupdates für Exchange 2016 / 2019
• Nur Critical und Important Vulnerabilities
• Keine Feature-Updates
• Kein regulärer Produktsupport

Was ESU nicht ist:

• Keine dauerhafte Lösung
• Kein Ersatz für eine Migration
• Keine Garantie auf monatliche Updates

ESU kauft Zeit – nicht Sicherheit auf Dauer.

Wie kann man das ESU-Programm erwerben?

Der Erwerb des ESU-Programms läuft nicht automatisiert, sondern über Microsoft bzw. Partner.

Voraussetzungen

• Exchange 2016: CU23
• Exchange 2019: CU14 oder CU15
• Sauberer, unterstützter Update-Stand

Ablauf in der Praxis

1. Microsoft Account Team oder Partner kontaktieren
   Falls kein eigenes Account Team vorhanden ist, übernimmt dies meist ein Microsoft-Partner.
2. ESU-Lizenz pro Exchange-Server erwerben
3. Zugriff auf private Security Updates erhalten
4. Patch-Prozess weiterhin aktiv betreiben

Wichtig:

Nach Ende der öffentlichen Updates werden ESU-Security-Updates nicht mehr frei verfügbar, sondern nur noch ESU-Kunden bereitgestellt.

Microsoft Entra ID unterstützt Conditional Access für Agent Identities. Überblick zu Konzept, Einsatzszenarien und Sicherheitsvorteilen.

Conditional Access für Agent Identities in Microsoft Entra ID

Mit der zunehmenden Nutzung von Automatisierung, Workflows und KI-gestützten Diensten steigt die Anzahl nicht-menschlicher Identitäten in Entra-ID-Umgebungen deutlich. Microsoft adressiert diese Entwicklung mit der Einführung von Conditional Access für sogenannte Agent Identities. Der Microsoft-Beitrag aus der Tech Community beschreibt, wie diese Identitäten abgesichert werden können und welche neuen Steuerungsmöglichkeiten sich daraus ergeben.

Was sind Agent Identities?

Agent Identities repräsentieren nicht-interaktive Akteure wie:

• KI-Agenten
  • Automatisierte Services
    • Hintergrundprozesse
• Orchestrierte Workflows

Im Gegensatz zu klassischen Benutzeridentitäten agieren sie eigenständig, oft dauerhaft und mit weitreichenden Berechtigungen. Genau daraus ergibt sich ein erhöhtes Sicherheitsrisiko, wenn Zugriffe nicht granular kontrolliert werden.

Sicherheitsproblem klassischer Service-Identitäten

Traditionell werden für nicht-menschliche Zugriffe Service Principals, Managed Identities oder App-Registrierungen verwendet. Diese Identitäten:

• Arbeiten häufig mit langlebigen Geheimnissen oder Zertifikaten
• Unterliegen nicht denselben Conditional-Access-Regeln wie Benutzer
• Entziehen sich kontextbasierter Zugriffskontrolle

Der Microsoft-Artikel ordnet Agent Identities als Weiterentwicklung ein, um diese Lücke zu schließen.

Conditional Access für Agent Identities – Konzept

Conditional Access für Agent Identities erweitert das bekannte CA-Modell um nicht-menschliche Identitäten. Dabei werden Zugriffsentscheidungen nicht mehr ausschließlich auf Benutzerkontexten getroffen, sondern auf Eigenschaften des Agenten und dessen Ausführungsumgebung.

Mögliche Steuerungsparameter sind unter anderem:

• Identität des Agenten
• Zielressource
• Risiko- und Kontextinformationen
• Mandanten- und Workload-Zugehörigkeit

Abgrenzung zu Benutzer-Conditional-Access

Ein zentrales Thema des Beitrags ist die klare Trennung zwischen Benutzer- und Agenten-Policies. Agent Identities benötigen eigene Richtlinien, da klassische Bedingungen wie Standort, Gerät oder MFA nicht anwendbar sind.

Microsoft verfolgt hier einen separaten Policy-Ansatz, um Fehlkonfigurationen und unbeabsichtigte Blockierungen produktiver Workloads zu vermeiden.

Typische Einsatzszenarien

Absicherung von KI- und Automatisierungsdiensten

Agent Identities eignen sich besonders für KI-basierte Dienste, die selbstständig auf APIs, Daten oder andere Cloud-Ressourcen zugreifen. Conditional Access ermöglicht hier eine gezielte Einschränkung auf notwendige Zielsysteme.

Zero-Trust-Architekturen für Workloads

Durch Conditional Access für Agenten lässt sich das Zero-Trust-Prinzip auch auf nicht-menschliche Identitäten anwenden. Jeder Zugriff wird explizit bewertet und autorisiert.

Reduktion von Seitwärtsbewegungen

Granulare CA-Regeln können verhindern, dass kompromittierte Agenten unkontrolliert auf weitere Ressourcen zugreifen.

Aktueller Stand und Einschränkungen

Der Microsoft-Beitrag macht deutlich, dass sich Conditional Access für Agent Identities noch in der Weiterentwicklung befindet. Nicht alle Szenarien und Dienste werden aktuell unterstützt. Organisationen sollten daher:

• Den unterstützten Funktionsumfang genau prüfen
• Bestehende Service-Identitäten evaluieren
• Pilotprojekte klar abgrenzen

Einordnung aus Beratungssicht

Conditional Access für Agent Identities ist ein wichtiger Schritt, um die Sicherheitslücke zwischen Benutzer- und Workload-Identitäten zu schließen. Der Ansatz zeigt, dass Microsoft die steigende Bedeutung autonomer Systeme in Entra ID strategisch adressiert.

Für produktive Umgebungen ist jedoch entscheidend, neue Richtlinien kontrolliert einzuführen und bestehende Automatisierungen nicht unbeabsichtigt zu beeinträchtigen.

Zusammenfassung

Der Microsoft-Tech-Community-Beitrag zeigt, wie Conditional Access gezielt auf Agent Identities angewendet werden kann. Damit lassen sich moderne Automatisierungs- und KI-Szenarien besser absichern, ohne auf klassische Benutzermechanismen zurückzugreifen. Für Unternehmen mit wachsender Anzahl nicht-menschlicher Identitäten ist dies ein relevanter Baustein moderner Entra-ID-Sicherheitsarchitekturen.

Mit seinem aktuellen Update kündigt Microsoft an, dass Security Copilot künftig ohne Zusatzkosten als Bestandteil der Microsoft 365 E5-Lizenz enthalten sein wird. Damit wird eine leistungsstarke KI-gestützte Sicherheitslösung direkt in die täglichen Arbeitsabläufe von Sicherheitsteams integriert. 

Überblick und Zeitpunkt

Die Integration startet ab dem 18. November 2025 für bestehende Kunden von Microsoft 365 E5, die Security Copilot bereits nutzen.  Im Anschluss erfolgt die sukzessive Ausrollung für alle Microsoft 365 E5-Kunden. Vor Aktivierung erhalten Kunden eine 30-Tage Vorankündigung. 

Lizenz- und Nutzungskapazitäten

• Für jeden 1.000 bezahlten Nutzerlizenzen im Rahmen von Microsoft 365 E5 werden monatlich 400 Security Compute Units (SCU) kostenfrei bereitgestellt, maximal bis zu 10.000 SCU pro Monat.  
• Beispiel: Ein Unternehmen mit 400 Nutzerlizenzen bekommt 160 SCU pro Monat. Bei 4.000 Nutzerlizenzen sind es 1.600 SCU pro Monat.  
• Nicht genutzte SCUs verfallen am Monatsende — ein Übertrag in spätere Monate erfolgt nicht.  

Was ist inbegriffen – und was nicht?

Inbegriffene Fähigkeiten:

• Zugriff auf die Kern-Erlebnisse von Security Copilot wie Chat- und Agent-Szenarien über Produkte wie Microsoft Defender, Microsoft Entra, Microsoft Intune und Microsoft Purview.  
• Möglichkeit, selbst (oder durch Partner) Agenten, Prompt-Bücher oder Integrationen zu entwickeln (z. B. über Agent Builder, APIs) innerhalb dieses Angebots.  

Nicht automatisch inbegriffen:

• Kosten für bestimmte Zusatzkomponenten wie z. B. Daten-Lake-Compute/Storage in Microsoft Sentinel, oder Lizenzen für Partner-Agenten über den Security Store.  
• Voraussetzungen außerhalb der Microsoft 365 E5 Lizenz, wenn erforderlich, sind nicht automatisch abgedeckt.  

Zugangs- und Einsatzbedingungen

• Jeder Microsoft 365 E5-Kunde ist für die Inklusion berechtigt – unabhängig von der Anzahl der Nutzerlizenzen.  
• Es ist keine zusätzliche Provisionierung von SCUs notwendig: Die Nutzung wird automatisch bereitgestellt, wenn das Angebot aktiviert wird.  
• Kunden ohne Microsoft 365 E5 können Security Copilot weiterhin über das bisherige Preismodell beziehen – die Inklusion ist nicht exklusiv und ersetzt nicht das eigenständige Angebot.  

Bedeutung für Unternehmen

Für Unternehmen bedeutet diese Entscheidung: Sicherheitsteams bekommen künftig mit minimalem administrativen Aufwand Zugriff auf fortschrittliche KI-Agenten, die in den bekannten Microsoft‐Sicherheitsprodukten arbeiten. Das senkt Einstiegshürden, erleichtert die Nutzung von Automatisierung im Sicherheitsbetrieb (z. B. bei Incident-Triage, Phishing-Bearbeitung, Zugriffskontrollen) und verbessert insgesamt die Reaktionsfähigkeit.

Gleichzeitig bleibt es wichtig, diese Kapazitäten sinnvoll zu steuern: Die verfügbar gemachten SCUs sind limitiert, nicht genutzte Einheiten verfallen, und bei Überschreitung können Zusatzkosten entstehen. Zudem muss das Unternehmen die Konfiguration von Agenten und Workflows aktiv angehen – die Technologie liefert das „Werkzeug“, nicht automatisch das „Fertigsystem“.

Fazit

Mit der Einbindung von Security Copilot in die Microsoft 365 E5-Lizenz setzt Microsoft einen klaren Impuls: Sicherheits-KI wird nicht mehr exklusives Premium-Tool, sondern Teil der Standard-Sicherheitsinfrastruktur im Unternehmenskontext. Das stärkt die Automatisierung und Effizienz von IT-Sicherheits- und Betriebsaufgaben. Für Berater und IT-Verantwortliche gilt: Jetzt gilt es, die Einführung zu planen – von Lizenzcheck über Kapazitäts-Monitoring bis hin zur organisatorischen Verankerung solcher Agenten-Workflows.

Microsoft hat angekündigt, das bislang separat erhältliche Sysinternals-Tool Sysmon (System Monitor) direkt in Windows 11 sowie Windows Server 2025 zu integrieren. Damit wird ein wichtiges Analyse- und Sicherheitswerkzeug künftig Bestandteil des Betriebssystems und muss nicht mehr manuell nachinstalliert werden.

Was ist Sysmon?

Sysmon ist ein Überwachungstool, das tiefgehende Informationen über Prozessstarts, Netzwerkverbindungen, Dateiänderungen und andere sicherheitsrelevante Systemaktivitäten erfasst. Diese Ereignisse werden im Windows-Eventlog protokolliert und dienen als Grundlage für Sicherheitsanalysen, Incident Response und forensische Untersuchungen.

Bisher war Sysmon ein optionales Tool aus der Sysinternals-Suite, das Unternehmen manuell verteilen und konfigurieren mussten.

Was ändert sich durch die neue Integration?

• Optionale Windows-Komponente
  Sysmon wird künftig als aktivierbare Funktion direkt im Betriebssystem vorhanden sein. Administratoren können es also ohne separaten Download einrichten.
• Einfachere Updates
  Die Aktualisierung erfolgt künftig über reguläre Windows-Update-Mechanismen. Das erleichtert insbesondere in größeren Umgebungen den Rollout und die Wartung.
• Bewährte Funktionen bleiben erhalten
  Die bekannten Features wie benutzerdefinierte Konfigurationsdateien, fein granulierte Event-Filter oder die umfangreiche Protokollierung von Systemaktivitäten werden weiterhin unterstützt.
• Erweiterte Dokumentation und zukünftige Features
  Microsoft plant verbesserte Dokumentationen sowie zusätzliche Verwaltungs- und Sicherheitsfunktionen, darunter neue Optionen für Enterprise-Management und KI-gestützte Bedrohungserkennung.

Bedeutung für Unternehmen und IT-Administratoren

• Erhöhte Standardisierung
  Da Sysmon nun ein offizieller Bestandteil des Betriebssystems wird, kann es einfacher in Standard-Images und Baselines integriert werden.
• Besseres Sicherheitsmonitoring
  Durch die verbesserte Abdeckung und die niedrigere Einstiegshürde profitieren Unternehmen von konsistenterer Protokollierung verdächtiger Aktivitäten.
• Weniger Aufwand bei Deployment und Verwaltung
  Ohne manuelle Installation oder Updateroutinen lässt sich Sysmon einfacher betriebsweit einführen – gerade in größeren IT-Landschaften.
• Nahtlose Integration in bestehende Security-Workflows
  Die bekannten Ereignistypen und Konfigurationsmöglichkeiten bleiben bestehen und können weiterhin in SIEM-, SOC- und Forensik-Prozessen genutzt werden.

Hinweise zur praktischen Umsetzung

• Eine durchdachte Sysmon-Konfiguration bleibt entscheidend: Nur sinnvoll gefilterte Ereignisse sorgen für wertvolle Logs und vermeiden unnötige Datenmengen.
• In Unternehmensumgebungen empfiehlt sich weiterhin ein zentrales Management, z. B. über Gruppenrichtlinien oder Konfigurationsmanagement-Systeme.
• Bestehende Installationen sollten hinsichtlich Migration und Kompatibilität geprüft werden – insbesondere, wenn spezielle Konfigurationsdateien oder externe Versionen im Einsatz sind.

Fazit

Die Integration von Sysmon direkt in Windows 11 und Windows Server 2025 ist ein bedeutender Schritt für die Sicherheitsüberwachung in Unternehmensumgebungen. Sie reduziert den administrativen Aufwand, verbessert die Standardisierung und stärkt die Möglichkeiten für tiefergehende Analysen. Gleichzeitig bleibt eine sorgfältige Konfiguration und Einbettung in bestehende Sicherheitsprozesse weiterhin unerlässlich.