EWS-Abschaltung in Exchange Online: Was jetzt zählt — und warum die Uhr bereits läuft
Microsoft schaltet Exchange Web Services (EWS) in Exchange Online ab. Die phasenweise Deaktivierung beginnt am 1. Oktober 2026, die vollständige Abschaltung folgt am 1. April 2027.
EWS ist die Schnittstelle, über die Anwendungen seit Jahren im Hintergrund auf E-Mails, Kalender, Kontakte und Postfachordner zugreifen — oft, ohne dass es im Betrieb auffällt. Betroffen ist weit mehr als das klassische Mail-Programm: auch Backup, Archivierung, zentrale Signaturen, Ticket- und ERP-Systeme sowie automatisierte Geschäftsprozesse nutzen EWS.
Wichtig zuerst: Die Frist läuft bereits
Ab dem 1. Oktober 2026 setzt Microsoft bei jedem Tenant, dessen Parameter EWSEnabled noch auf Null steht, den Wert automatisch auf False — das blockiert EWS für alle Anwendungen im Tenant.
Um dieser automatischen Blockade zu entgehen, sind zwei Schritte nötig, möglichst bis Ende August 2026:
EWSEnabledexplizit aufTruesetzen- eine AppID Allow List (
EWSAllowedAppIDs) pflegen, die die weiterhin benötigten Anwendungen enthält
Zur Klarstellung: Die Allow List ist ein Zeitpuffer, keine Lösung. Sie hält kritische Anwendungen bis maximal April 2027 am Leben. Danach ist EWS endgültig weg — ohne Admin-Override.
Wo EWS im Einsatz sein kann — und wie damit umzugehen ist
EWS kann überall dort eine Rolle spielen, wo eine Anwendung auf ein Exchange-Online-Postfach zugreift. Typische Kategorien und die jeweils passende Entscheidung:
| Kategorie / Fall | Empfohlene Behandlung |
|---|---|
| Backup- und Archivierungslösungen für Microsoft 365 | Hersteller-Roadmap prüfen, auf Graph umstellen |
| Zentrale E-Mail-Signaturen | Kompatible Version einsetzen oder Ersatz planen |
| Identity- und Berechtigungsmanagement | Migration prüfen, Authentifizierung anpassen |
| Ticket- und ERP-Systeme, die E-Mails verarbeiten | Kritikalität bewerten, Übergang planen |
| Scan-to-Mail und vergleichbare Gerätefunktionen | Firmware / Konfiguration prüfen |
| Nicht mehr benötigte Anwendung | Zugriff beenden |
| Bereits Graph-kompatible Anwendung | Update oder Umstellung durchführen |
| Unbekannte Application ID | Anwendung und Verantwortliche identifizieren |
| Individuelle Eigenentwicklung | Code und genutzte EWS-Funktionen analysieren |
Das Problem: Solange eine Integration läuft, gibt es im Alltag keinen Anlass, nach der Schnittstelle dahinter zu fragen. Genau diese unsichtbaren Abhängigkeiten werden im Oktober zum Risiko.
Warum die Bestandsaufnahme aufwendiger ist als erwartet
Microsoft stellt im Microsoft 365 Admin Center einen EWS-Nutzungsbericht bereit. Er zeigt aktive Anwendungen, genutzte EWS-/SOAP-Aktionen, das Aufrufvolumen, die letzte registrierte Aktivität und die jeweilige Application ID. Zwei Fallstricke sind dabei zu beachten:
Zeitverzug
Die Daten werden wöchentlich aggregiert; es kann bis zu zehn Tage dauern, bis eine Aktivität im Bericht auftaucht. Ein zu kurzer Betrachtungszeitraum liefert ein unvollständiges Bild.
Nur IDs, keine Namen
Der Bericht zeigt eine Application ID, aber selten einen sofort verständlichen Produktnamen. Jede ID muss einer Anwendung, einem Hersteller oder einer internen Entwicklung zugeordnet werden.
Erst danach beginnt die eigentliche fachliche Arbeit: Wer ist intern verantwortlich? Wird die Anwendung noch produktiv genutzt? Welche Postfächer und Prozesse hängen daran? Ist sie geschäftskritisch? Unterstützt der Hersteller bereits Microsoft Graph? Aus dem technischen Bericht wird so ein echtes Migrationsprojekt.
Microsoft Graph ist die Zielplattform — aber kein simpler Austausch
Microsoft empfiehlt, EWS-Abhängigkeiten zu identifizieren und Anwendungen auf Microsoft Graph umzustellen. Viele Szenarien lassen sich damit bereits abbilden. Für einzelne EWS-Funktionen bestehen laut Microsoft aber noch funktionale Lücken, die in die Planung gehören.
Eine Migration ist deshalb selten nur ein Schnittstellen-Tausch. Je nach Anwendung bedeutet sie ein Hersteller-Update, eine geänderte Authentifizierung, angepasste Berechtigungen oder die Überarbeitung individueller Integrationen.
Fünf Arbeitspakete für die strukturierte Vorbereitung
- EWS-Nutzung erfassenNutzungsbericht prüfen, ausreichend langen Zeitraum wählen.
- Application IDs zuordnenIDs bekannten Anwendungen, Herstellern oder Eigenentwicklungen zuweisen.
- Kritikalität bewertenFeststellen, welche Prozesse ausfallen, wenn der Zugriff endet.
- Verantwortlichkeiten klärenJe einen fachlichen und einen technischen Ansprechpartner benennen.
- Migrationsweg festlegenUpdate, Graph-Umstellung, Übergangslösung oder Ersatz entscheiden.
EWS prüfen, bevor aus der Abhängigkeit eine Störung wird
Die EWS-Abschaltung betrifft nicht nur die Exchange-Administration. Sie kann Anwendungen und Prozesse treffen, die über Jahre gewachsen sind und heute selbstverständlich laufen. Der wichtigste Schritt ist die vollständige Bestandsaufnahme — erst wenn klar ist, welche Anwendungen EWS nutzen, lassen sich Risiken priorisieren und realistische Entscheidungen treffen. Und weil die automatische Blockade bereits im Oktober 2026 greift, ist der richtige Zeitpunkt jetzt.
Migration planen, bevor die Uhr abläuft
Artaker IT Services analysiert Ihre EWS-Nutzung, ordnet die Application IDs zu, konfiguriert EWSEnabled und Allow List und plant den Umstieg auf Microsoft Graph. So wird aus einer unbekannten Abhängigkeit ein kontrollierbares Migrationsvorhaben.