Exchange Online | EWS Abschaltung Mai 2027

Das Ende von Exchange Web Services (EWS) in Exchange Online ist kein theoretisches Szenario mehr, sondern ein terminierter Prozess, der Deine Infrastruktur-Planung ab sofort dominieren muss. Microsoft hat den endgültigen Zeitplan für die Deaktivierung und vollständige Entfernung von EWS veröffentlicht, wodurch die Migration auf die Microsoft Graph API von einer Empfehlung zur akuten Notwendigkeit wird.

EWS stammt aus einer Ära, in der On-Premises-Datacenter der Standard waren und Sicherheitsbedrohungen im Vergleich zu heutigen Angriffsszenarien trivial wirkten. Das Protokoll erlaubt tiefgreifenden Zugriff auf Postfächer, ist jedoch strukturell nicht für die granularen Berechtigungsmodelle und Sicherheitsanforderungen moderner Cloud-Umgebungen ausgelegt. Um die Angriffsfläche Deines Tenants zu verringern, wird Microsoft EWS schrittweise eliminieren, was direkte Auswirkungen auf Backup-Lösungen, CRM-Integrationen und Archivierungstools hat.

Microsoft agiert hier nicht impulsiv, sondern folgt einem kausalen Deaktivierungspfad, um kritische Business-Workflows nicht unvorbereitet zu unterbrechen. Dennoch bleibt die Zeitachse unerbittlich.

Ab Oktober 2026 initiiert Microsoft die erste technische Hürde. In allen Exchange Online Tenants wird die Eigenschaft EWSEnabled hart von True auf False gesetzt. Dieser Schritt blockiert unmittelbar alle EWS-basierten Verbindungen. In dieser Phase hast Du noch die administrative Hoheit, den Wert manuell auf True zurückzusetzen oder auf Null zu belassen, um den Betrieb Deiner Legacy-Apps vorübergehend zu retten. Dies ist jedoch keine Lösung, sondern lediglich ein Aufschub für die Fehlerbehebung.

Der finale Cut erfolgt am 1. April 2027. Ab diesem Datum beginnt die permanente Deaktivierung. Bis Mai 2027 wird EWS vollständig aus der Exchange Online Infrastruktur entfernt sein. Eine Reaktivierung über PowerShell oder das Admin Center ist dann technisch unmöglich.

Da viele Organisationen auf Drittanbieter-Apps angewiesen sind, die den Umstieg auf Graph noch nicht vollzogen haben, führt Microsoft eine neue „Allow List“ für EWS-Anwendungen ein. Diese Liste hat Vorrang vor der bisherigen EWSApplicationAccessPolicy.

Microsoft plant, diese Liste proaktiv auf Basis der tatsächlich beobachteten EWS-Nutzung in Deinem Tenant zu erstellen. Das ist zwar ein hilfreicher Service, entbindet Dich aber nicht von der Pflicht, diese Liste kritisch zu prüfen. Du musst verstehen, welche App welche Daten abgreift. Eine automatisierte Liste kann veraltete oder unsichere Integrationen enthalten, die Du im Sinne des Principle of Least Privilege (PoLP) eigentlich eliminieren müsstest.

Um die Inventur durchzuführen, solltest Du die EWS-Nutzungsberichte im Admin Center analysieren. Nur so identifizierst Du Schatten-IT oder Legacy-Skripte, die am Tag X den Dienst quittieren würden.

Die Strategie von Microsoft ist klar: Die Graph API ist der einzige Weg nach vorne. Allerdings ist der Wechsel kein einfacher 1-zu-1-Austausch von Endpunkten. EWS bot Funktionen, die in Graph bisher nur teilweise oder über Umwege verfügbar sind.

Microsoft arbeitet intensiv daran, diese Lücken zu schließen. Jüngste Veröffentlichungen wie die Exchange Admin API (ein Wrapper für PowerShell-Cmdlets) und die Graph userConfiguration API sind wichtige Bausteine. Dennoch bleiben kritische Bereiche wie der Zugriff auf Archiv-Postfächer oder öffentliche Ordner (Public Folders) problematisch. Es ist wahrscheinlich, dass einige nischige EWS-Funktionen niemals den Weg in die Graph API finden werden. Hier musst Du Deine Workflows architektonisch neu bewerten.

Ein weiteres Risiko für Entwickler: Viele der neuen Exchange-relevanten Graph-Endpunkte befinden sich derzeit noch im Beta-Stadium. Das bedeutet, dass Microsoft diese APIs ohne große Vorankündigung ändern oder entfernen kann. Für produktive Enterprise-Lösungen ist das ein unsicherer Zustand, weshalb der Druck auf Microsoft wächst, diese Endpunkte schnellstmöglich in den V1.0-Status zu überführen.

Wenn Du eine Hybrid-Konfiguration betreibst, verschärft sich die Situation durch die Abhängigkeit von der Exchange Server Edition (SE). Microsoft hat klargestellt, dass für eine reibungslose Koexistenz (z. B. Free/Busy-Abfragen oder MailTips) zwischen On-Premises und Cloud zwingend Exchange SE erforderlich ist.

Sobald EWS im Oktober 2026 in der Cloud deaktiviert wird, müssen Hybrid-Bereitstellungen auf Graph-basierte Abfragen umstellen. Das funktioniert technisch nur, wenn die On-Premises-Postfächer auf Exchange SE gehostet werden. Wer noch auf Exchange 2019 oder älter setzt, wird feststellen, dass die Brücke zur Cloud brüchig wird. Während EWS für rein interne On-Premises-Anwendungen weiterhin funktioniert, bricht die Kommunikation mit Exchange Online ohne den Wechsel auf Graph und Exchange SE zusammen.

Die Abkündigung von EWS ist die konsequente Fortführung der „Secure Future Initiative“ von Microsoft. Aus technischer Sicht ist die Entfernung eines fast 20 Jahre alten Protokolls überfällig, da EWS in einer Welt von Zero Trust und granularen API-Berechtigungen wie ein Fremdkörper wirkt. Die Abhängigkeit von einem einzigen, mächtigen Protokoll hat in der Vergangenheit oft zu lateralen Bewegungen bei Angriffen geführt, was durch das feingliedrige Scoping der Graph API deutlich erschwert wird.

Für Dich als Administrator bedeutet das jedoch einen massiven Aufwand. Es reicht nicht, nur die eigenen Skripte anzupassen. Du bist abhängig von der Release-Geschwindigkeit Deiner Software-Lieferanten. Wenn Dein Backup-Anbieter oder Dein Archivierungssystem bis April 2027 keine native Graph-Unterstützung bietet, riskierst Du Datenverlust oder Compliance-Verstöße.

Besonders kritisch sehe ich die aktuelle Lücke bei den Archiv-Postfächern und Public Folders. Viele Unternehmen nutzen diese für die rechtssichere Aufbewahrung. Dass Microsoft hier so kurz vor knapp noch keine finalen V1.0-APIs liefert, bringt IT-Abteilungen in eine unnötige Defensive.