IT-Consulting Blog

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.

n den letzten Wochen wurde eine neue, besonders raffinierte Phishing-Technik bekannt, die zeigt, wie Angreifer selbst modernste KI-Tools und Cloud-Plattformen für ihre Zwecke missbrauchen können. Sicherheitsforscher von Datadog entdeckten eine Kampagne namens „CoPhish“, die Microsofts Copilot Studio-Agenten nutzt, um OAuth-Tokens zu stehlen – also digitale Schlüssel, mit denen sich Nutzer gegenüber Cloud-Diensten authentifizieren.

Der Fall ist nicht nur ein Beispiel für geschicktes Social Engineering, sondern auch ein Weckruf: Sicherheit durch Vertrauen reicht nicht mehr. Nur eine konsequent umgesetzte Zero-Trust-Architektur kann solchen Angriffen standhalten.

Wie funktioniert der CoPhish-Angriff?

Der Angriff nutzt aus, dass in Microsoft Copilot Studio Agenten (Chatbots) erstellt werden können, die über eine öffentliche, legitime Microsoft-Domain erreichbar sind.
Ein Angreifer erstellt dabei einen „bösartigen“ Copilot-Agenten, der scheinbar harmlose Aufgaben erfüllt – etwa das Abrufen von Informationen oder die Anmeldung bei einem Cloud-Service.

Im Hintergrund ist der Agent aber mit einer bösartigen Multi-Tenant-App verknüpft.
Wenn ein ahnungsloser Nutzer auf den Link klickt, öffnet sich ein bekannter Microsoft-Login-Dialog und der Nutzer wird gebeten, einer App Zugriff zu gewähren.
Die URL, das Layout und die Domain wirken absolut vertrauenswürdig – denn sie stammen von Microsoft selbst.

Doch hinter dieser Fassade steckt ein Phishing-Flow, der nach dem Login das OAuth-Token des Benutzers an den Angreifer überträgt. Dieses Token erlaubt dem Angreifer, sich als der Benutzer auszugeben – ohne Passwort, MFA oder sichtbare Anomalien.

Das Perfide: Es handelt sich nicht um einen klassischen Phishing-Link oder eine gefälschte Domain, sondern um Missbrauch einer legitimen Plattformfunktion.

Warum klassische Schutzmaßnahmen hier versagen

Traditionelle Sicherheitsansätze verlassen sich auf Vertrauen in bekannte Marken, Zertifikate und Domains.
Doch genau dieses Vertrauen wird hier ausgenutzt.

Selbst Firewalls, Secure Web Gateways oder MFA können nur eingeschränkt helfen, wenn der Nutzer bewusst (aber ahnungslos) einer legitimen App Berechtigungen erteilt.
Der Angriffsvektor liegt nicht in einem Exploit, sondern in einem Missbrauch der Zustimmungskette – etwas, das sich technisch kaum verhindern lässt, solange jeder Benutzer eigenständig Apps autorisieren darf.

Zero Trust als Antwort: Vertrauen ist keine Sicherheitsstrategie

Hier zeigt sich der wahre Wert von Zero Trust.
Zero Trust bedeutet nicht „Misstrauen gegenüber allem“, sondern: Jede Anfrage muss kontinuierlich geprüft, kontextualisiert und autorisiert werden – unabhängig von Quelle oder Identität.

Ein echter Zero-Trust-Ansatz hätte mehrere Verteidigungsschichten gegen CoPhish geboten:

1. Strikte Kontrolle über App-Zustimmungen:
   Nur bestimmte Benutzergruppen dürfen OAuth-Zustimmungen erteilen oder neue Anwendungen registrieren.
2. Identitätsbasierte Segmentierung:
   Selbst wenn ein Token kompromittiert wird, sind dessen Berechtigungen auf das Minimum reduziert (Least Privilege).
   Der Zugriff auf sensible Systeme wäre damit ausgeschlossen.
3. Adaptive Authentifizierung und Kontextprüfung:
   Wird ein Token von einem unbekannten Agenten oder ungewöhnlichem Ort verwendet, schlägt eine automatische Re-Authentifizierung oder Policy-Blockade an.
4. Monitoring & Alerting in Echtzeit:
   Zero-Trust-Architekturen setzen auf Telemetrie – ungewöhnliche OAuth-Zustimmungen oder App-Registrierungen werden erkannt und gemeldet.
5. Klar definierte Vertrauenszonen:
   Nur Anwendungen und Agenten, die durch Governance-Prozesse geprüft und zertifiziert sind, dürfen Zugriff auf Unternehmensdaten haben.

Schutzmaßnahmen in der Praxis

Wer Microsoft- oder andere Cloud-Dienste betreibt, sollte folgende Punkte prüfen:

• App-Consent Policies aktivieren: Nur Administratoren dürfen neuen Apps Berechtigungen erteilen.
• Überwachung von App-Registrierungen: Regelmäßig prüfen, welche Anwendungen Zugriff auf Entra ID (ehemals Azure AD) haben.
• Rollen und Berechtigungen reduzieren: Least-Privilege konsequent umsetzen.
• Schulungen und Awareness-Programme: Nutzer sollten OAuth-Zustimmungsdialoge kritisch prüfen.
• Zero-Trust-Governance etablieren: Kein System, keine Identität und kein Agent sollte per se als vertrauenswürdig gelten.

Fazit

Der CoPhish-Angriff zeigt eindrucksvoll, wie Angreifer legitime Plattformen als trojanische Pferde nutzen.
Die Lösung liegt nicht in noch mehr Firewalls oder Filtern, sondern in einem Paradigmenwechsel: Vertrauen muss ersetzt werden durch überprüfbare Sicherheit.

Zero Trust ist kein Buzzword mehr, sondern eine Notwendigkeit.
In einer Welt, in der sogar Microsoft-Domains zum Einfallstor werden können, gilt:

„Never trust, always verify.“

In vielen Unternehmen gehört Microsoft Edge mittlerweile zum festen Bestandteil der modernen Arbeitsplatzumgebung. Der Browser bietet zahlreiche Komfortfunktionen – von der nahtlosen Anmeldung mit dem Entra ID-Konto (ehemals Azure AD) bis hin zur Synchronisation von Passwörtern, Favoriten und Einstellungen über verschiedene Geräte hinweg.

Doch genau dieser Komfort kann schnell zum Risiko werden. Denn was für den privaten Nutzer bequem ist, stellt im Unternehmenskontext eine potenzielle Sicherheitslücke dar – insbesondere, wenn Mitarbeitende sich mit ihrem Arbeitskonto auf nicht verwalteten Geräten anmelden.

Warum Passwort-Synchronisation zum Risiko werden kann

Die Passwort-Synchronisation in Edge sorgt dafür, dass gespeicherte Anmeldeinformationen verschlüsselt in der Cloud abgelegt und auf allen Geräten eines Nutzers verfügbar sind. Das ist im privaten Umfeld praktisch – im Unternehmenskontext jedoch heikel.

Meldet sich ein Mitarbeitender mit seinem Arbeitskonto auf einem privaten Laptop an, kann die Synchronisation dazu führen, dass sensible Zugangsdaten auf einem Gerät landen, welches weder durch das Unternehmen verwaltet noch gehärtet ist. Selbst wenn dort lokale Sicherheitsmaßnahmen aktiv sind, bleibt unklar, ob das Gerät den Compliance-Anforderungen entspricht oder Malware-frei ist.

Hinzu kommt: Wird der integrierte Passwort-Manager des Browsers genutzt, bleiben die Daten auch lokal abrufbar – selbst wenn das Unternehmen zentral Richtlinien zur Deaktivierung oder Löschung setzt.

Meine persönliche Empfehlung aus der Praxis:
In meinen Projekten sensibilisiere ich Kunden regelmäßig dafür, dass der Browser nach wie vor das Hacker-Tool Nummer 1 ist – und somit eines der größten Einfallstore in moderne IT-Umgebungen darstellt. Daher sollte der Browser genauso konsequent gehärtet werden wie Betriebssystem, Endpoint-Schutz oder Identitätsmanagement.

Besonders kritisch sehe ich die Nutzung der integrierten Passwort-Manager in Browsern. Sie widersprechen in vielen Fällen den gängigen Sicherheitsvorgaben führender Institutionen:

• Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seinen IT-Grundschutz-Bausteinen (z. B. APP.4.4 Webbrowser und SYS.1.6 Clients) ausdrücklich, Komfortfunktionen wie automatische Passwortspeicherung oder Formularausfüllung zu deaktivieren.
• Auch die CIS Benchmarks (Center for Internet Security) für Microsoft Edge und Google Chrome listen das Deaktivieren des Passwort-Managers als empfohlene Sicherheitsmaßnahme (Level 1 Control).
• Entsprechende Anforderungen finden sich ebenso in der ISO 27001/27002 unter dem Themenkomplex „Access Control“ (A.9) und in den Microsoft Security Baselines für Edge, die ebenfalls eine restriktive Browserkonfiguration vorsehen.

Aus diesen Gründen empfehle ich grundsätzlich, die integrierten Passwort-Manager über geeignete Hardening-Maßnahmen – etwa per Gruppenrichtlinien, MDM-Profilen oder Edge Management Policies – vollständig zu deaktivieren.

So lässt sich sicherstellen, dass Browser keine Passwörter speichern oder synchronisieren dürfen, und das Risiko wird erheblich reduziert, dass Unternehmenszugangsdaten außerhalb der kontrollierten und geschützten Umgebung abgelegt werden.

Steuerungsmechanismen: So lässt sich Passwort-Sync sicher einschränken

Um den Spagat zwischen Sicherheit und Benutzerfreundlichkeit zu schaffen, stehen zwei zentrale Werkzeuge zur Verfügung:

1. Conditional Access in Microsoft Entra ID

Mit Conditional Access lässt sich präzise steuern, unter welchen Bedingungen ein Nutzer Daten synchronisieren oder sich überhaupt anmelden darf.
Beispielsweise kann eine Richtlinie definiert werden, die das „Edge Sync“-App-Objekt in Entra ID einbindet und die Synchronisation nur dann erlaubt, wenn das Gerät compliant oder hybrid Azure AD-joined ist.

Das bedeutet:

• Unternehmens-Konten können sich nur dann mit Edge synchronisieren, wenn das Gerät verwaltet wird.
• BYOD-Geräte (Bring Your Own Device), die nicht compliant sind, werden automatisch ausgeschlossen.

Das sorgt für eine klare Trennung zwischen verwalteter Unternehmensumgebung und privater Nutzung.

2. Microsoft Edge Management Service

Das Edge Management Service ist eine relativ neue Möglichkeit, Browser-Richtlinien cloudbasiert zu verteilen – auch auf nicht verwalteten Windows-Geräten.
Damit lassen sich beispielsweise folgende Richtlinien umsetzen:

• Deaktivieren des Passwort-Managers
• Einschränken oder Zulassen bestimmter Erweiterungen
• Blockieren der Synchronisation für bestimmte Kontotypen

Gerade für Unternehmen, die BYOD zulassen oder flexible Arbeitsumgebungen fördern, ist das ein sehr wirksamer Ansatz.
Einziger Nachteil: Die Unterstützung für macOS und mobile Plattformen ist aktuell noch eingeschränkt.

Kombination bringt den größten Effekt

In der Praxis hat sich gezeigt, dass keine dieser Maßnahmen allein ausreicht. Erst die Kombination aus Conditional Access und Edge Management Policies bietet den notwendigen Schutz:

• Conditional Access stellt sicher, dass nur compliant Geräte Zugriff haben.
• Edge-Richtlinien verhindern, dass selbst auf zulässigen Geräten unnötige Risiken durch Passwort- oder Sync-Funktionen entstehen.

Dieses zweistufige Modell schafft eine klare Sicherheitsarchitektur, ohne den Anwender unnötig einzuschränken.

Mein Fazit aus der Beratungspraxis

Die Balance zwischen Kontrolle und Komfort ist kein theoretisches Problem – sie entscheidet im Alltag, ob ein Unternehmen wirklich sicher arbeitet.
Die Passwort-Synchronisation in Microsoft Edge ist eine wertvolle Funktion, aber sie gehört nicht unkontrolliert in Unternehmensumgebungen.

Ich empfehle daher:

1. Edge-Passwort-Manager konsequent deaktivieren (Hardening).
2. Conditional Access-Richtlinien einrichten, um den Zugriff auf den Sync-Dienst nur für verwaltete Geräte zuzulassen.
3. Edge Management Policies einsetzen, um Richtlinien auch auf BYOD-Geräten durchzusetzen.
4. Mitarbeitende aktiv sensibilisieren, warum Passwort-Manager im Browser ein Sicherheitsrisiko darstellen können.

In der heutigen Bedrohungslandschaft kann sich keine Organisation mehr leisten, auf Vertrauen zu bauen. Der Ansatz der „Zero Trust Architecture“ (ZTA) ist längst kein Trendthema mehr, sondern eine strategische Notwendigkeit. Zero Trust basiert auf dem Grundsatz „Vertraue niemandem, überprüfe alles“ und ersetzt das veraltete Sicherheitsmodell, bei dem interne Akteure automatisch als vertrauenswürdig galten.

Dieser Artikel beleuchtet, warum der Zero-Trust-Ansatz so entscheidend ist, welche Vorteile und Risiken damit verbunden sind und welche zentrale Rolle die Datenklassifizierung – auch bekannt als Data Tiering – bei der erfolgreichen Umsetzung spielt.

Was ist Zero Trust?

Zero Trust ist kein Produkt, sondern ein umfassendes Sicherheitskonzept. Im Kern geht es darum, jedem Zugriff – egal ob von innen oder außen – grundsätzlich zu misstrauen. Jeder Nutzer, jedes Gerät und jede Verbindung wird kontinuierlich überprüft.

Wichtige Prinzipien sind:

• Assume Breach: Es wird davon ausgegangen, dass ein Angriff bereits stattgefunden hat – dadurch wird jedes System grundsätzlich hinterfragt.
• Least Privilege: Nutzer und Anwendungen erhalten nur die minimal notwendigen Berechtigungen.
• Kontinuierliche Verifikation: Zugriffe werden nicht einmalig, sondern dauerhaft überprüft – abhängig von Kontext, Gerät, Standort und Verhalten.
• Mikrosegmentierung: Netzwerke und Systeme werden in kleine Sicherheitszonen unterteilt, um Angriffe einzudämmen.
• Transparenz und Überwachung: Sämtliche Aktivitäten werden protokolliert, analysiert und auf Anomalien geprüft.

Zero Trust bricht damit das alte Modell der „sicheren Perimeter“ auf – in einer Zeit, in der Daten, Geräte und Mitarbeiter zunehmend dezentral agieren, ist das unverzichtbar.

Vorteile einer Zero Trust Architektur

Die Einführung von Zero Trust bringt zahlreiche Vorteile – sowohl in technischer als auch in organisatorischer Hinsicht:

• Erhöhte Sicherheit: Durch kontinuierliche Überprüfung und restriktive Zugriffsrechte sinkt das Risiko erfolgreicher Angriffe erheblich.
• Bessere Sichtbarkeit: IT-Teams erhalten volle Transparenz darüber, wer wann auf welche Ressourcen zugreift. Das erleichtert die Früherkennung von Bedrohungen.
• Reduziertes Insider-Risiko: Selbst interne Benutzer müssen sich regelmäßig authentifizieren. Dadurch werden kompromittierte Konten weniger gefährlich.
• Compliance und Datenschutz: Der Schutz sensibler Daten wird gezielter gesteuert – wichtig für regulatorische Anforderungen und Vertrauen bei Kunden.
• Flexibilität für moderne Arbeitsformen: Ob Remote Work, Cloud oder BYOD – Zero Trust erlaubt sicheren Zugriff unabhängig vom Standort.

Kurz gesagt: Zero Trust stärkt die Sicherheit, erhöht die Kontrolle und ermöglicht gleichzeitig moderne, agile Arbeitsweisen.

Risiken und Herausforderungen

Die Umsetzung einer Zero Trust Architektur ist anspruchsvoll und bringt eigene Herausforderungen mit sich:

• Hohe Komplexität: Bestehende Systeme, Rollen und Zugriffsmodelle müssen neu bewertet und oft umgestaltet werden.
• Benutzerakzeptanz: Häufige Authentifizierungen oder Sicherheitsprüfungen können Mitarbeitende frustrieren, wenn sie schlecht umgesetzt sind.
• Ressourcenbedarf: Die Einführung erfordert neue Tools, Fachwissen und Zeit – insbesondere für kontinuierliches Monitoring und Regelpflege.
• Fehlalarme: Zu strenge Richtlinien können legitime Aktionen blockieren und Geschäftsprozesse stören.
• Kulturelle Umstellung: Zero Trust ist kein „Tool“, sondern ein Mindset – Unternehmen müssen lernen, Sicherheit als fortlaufenden Prozess zu verstehen.

Diese Hürden lassen sich durch klare Kommunikation, iterative Umsetzung und gezieltes Change Management deutlich reduzieren.

Häufige Missverständnisse

Bei der Einführung von Zero Trust begegnet man oft falschen Annahmen:

• „Zero Trust ist ein Produkt.“ Falsch – es ist eine Strategie, die mehrere Technologien integriert.
• „Es geht nur um Identität.“ Nicht nur – Geräte, Netzwerke und Daten spielen eine ebenso wichtige Rolle.
• „Zero Trust ist zu kompliziert.“ Mit einem schrittweisen Ansatz kann es schmerzfrei und effektiv eingeführt werden.
• „Das bedeutet, wir vertrauen unseren Mitarbeitern nicht.“ Nein – das Vertrauen gilt Personen, nicht Systemzugriffen. Sicherheit soll schützen, nicht misstrauen.
• „Zero Trust löst alle Sicherheitsprobleme.“ Es ist ein mächtiger Ansatz, aber kein Allheilmittel. Schulung, Monitoring und Incident Response bleiben unverzichtbar.

Die Rolle von Data Tiering

Ein entscheidender Erfolgsfaktor für Zero Trust ist das Verständnis der eigenen Daten. Genau hier setzt Data Tiering – also die Klassifizierung von Informationen – an.

Datenklassifizierung teilt Informationen nach Sensitivität und Wert in Kategorien ein, beispielsweise „Öffentlich“, „Intern“, „Vertraulich“ oder „Streng vertraulich“.

Das ermöglicht:

• Gezielten Schutz: Besonders sensible Daten erhalten stärkere Sicherheitsmaßnahmen.
• Präzise Zugriffskontrolle: Nur berechtigte Personen können auf bestimmte Daten zugreifen – abhängig von Klassifikation und Kontext.
• Vermeidung von Datenlecks: Automatische Schutzmechanismen können verhindern, dass vertrauliche Daten versehentlich geteilt werden.
• Effizientere Governance: Unternehmen wissen, wo ihre kritischen Daten liegen, wie lange sie aufbewahrt werden und wer sie nutzt.

Ohne klare Datenklassifizierung bleibt Zero Trust unvollständig – denn man kann nur schützen, was man kennt.

Bedeutung für Cloud- und KI-Strategien

Data Tiering ist nicht nur ein Sicherheitsinstrument, sondern auch eine Grundlage für Innovation:

• Cloud-Migration: Klassifizierung hilft zu entscheiden, welche Daten sicher in die Cloud verschoben werden können und welche besondere Schutzanforderungen haben.
• Compliance in der Cloud: Daten lassen sich gezielt in bestimmten Regionen oder mit bestimmten Verschlüsselungsniveaus speichern.
• Kosteneffizienz: Weniger sensible oder selten genutzte Daten können in günstigere Speicherklassen ausgelagert werden.
• KI und maschinelles Lernen: Nur geeignete, nicht vertrauliche Datensätze werden für das Training genutzt – was Datenschutz und Qualität verbessert.

So entsteht eine Balance zwischen Innovation und Sicherheit.

Fazit

Zero Trust ist kein Modewort, sondern ein langfristiger Paradigmenwechsel in der IT-Sicherheit. Der Ansatz stärkt Organisationen gegen moderne Bedrohungen und schafft gleichzeitig die Basis für sichere digitale Transformation.

Doch Zero Trust funktioniert nur, wenn Unternehmen ihre Daten kennen und verstehen. Data Tiering liefert diese Grundlage – es verbindet Sicherheit, Compliance und Effizienz.

Wer Zero Trust mit konsequenter Datenklassifizierung kombiniert, schafft nicht nur Schutz, sondern auch Vertrauen und Agilität. Es ist der Weg zu einer sicheren, modernen und zukunftsfähigen IT-Architektur.