Microsoft ändert SMTP AUTH: Vorbereitung auf die Abschaltung der Basisauthentifizierung

Tausende Drucker, Scanner, ERP-Systeme, Überwachungswerkzeuge und Webanwendungen verbinden sich noch mit smtp.office365.com über Port 587. Viele authentifizieren sich nur mit einer Postfachadresse und einem Kennwort. Microsoft stellt genau dieses Verfahren, die Basisauthentifizierung für SMTP AUTH, schrittweise ein.

Die Änderung muss präzise beschrieben werden: Das Protokoll SMTP AUTH selbst endet nicht. SMTP AUTH kann mit OAuth weiterarbeiten. Beendet wird die Abhängigkeit von dauerhaft gespeicherten Benutzernamen und Kennwörtern, die moderne Zugriffsbedingungen nicht unterstützen und bei einer Offenlegung ein unnötiges Risiko darstellen.

Microsoft hat den Zeitplan geändert, nicht die Richtung

Laut dem aktualisierten Exchange-Online-Zeitplan bleibt das Verhalten bis Ende Dezember 2026 unverändert. Ende Dezember 2026 wird die Basisauthentifizierung für SMTP AUTH in bestehenden Mandanten standardmäßig deaktiviert. Administratoren können sie bei Bedarf vorübergehend wieder aktivieren.

In neuen Mandanten, die nach Dezember 2026 erstellt werden, ist die Basisauthentifizierung standardmäßig nicht verfügbar; OAuth ist dann der unterstützte Weg. Microsoft will den endgültigen Termin für die vollständige Entfernung in der zweiten Jahreshälfte 2027 bekannt geben. Unternehmen haben damit keinen Grund, die Migration aufzuschieben, sondern Zeit für eine kontrollierte Umstellung ohne unterbrochene E-Mail-Abläufe.

Wo sich die alte Anmeldung meist verbirgt

Das größte Problem ist selten Outlook. Betroffen sind Systeme, die im Hintergrund E-Mails senden und nicht als Teil der Microsoft-365-Identitätsumgebung betrachtet werden. Typische Beispiele sind:

• Multifunktionsdrucker und Scanner, die Dokumente per E-Mail versenden,
• ERP-, Buchhaltungs-, Lager- und Zeiterfassungssysteme,
• Überwachung von Servern, Backups, USV- und Netzwerkgeräten,
• Webformulare, interne Anwendungen und Automatisierungen,
• ältere Helpdesk-, Videoüberwachungs- oder Produktionsplattformen.

Die Kenntnis des Kennworts reicht nicht aus, um das Risiko zu bestimmen. Entscheidend sind das tatsächlich verwendete Protokoll und Authentifizierungsverfahren. Öffnen Sie im Exchange Admin Center Reports > Mail flow > SMTP AUTH Clients. Der Bericht SMTP AUTH Clients unterscheidet die als TlsAuthLogin dargestellte Basisauthentifizierung von der modernen Authentifizierung XOAUTH2. Er zeigt außerdem Absender, Nachrichtenvolumen und TLS-Version; der gewählte Berichtszeitraum kann bis zu 90 Tage umfassen.

Was nach der Abschaltung möglicherweise nicht mehr sendet

Wenn ein Gerät oder eine Anwendung nur Benutzername und Kennwort kennt, kann es sich nach der Blockierung der Basisauthentifizierung nicht mehr bei Exchange Online anmelden. Meist fällt nicht ganz Microsoft 365 aus, sondern ein einzelner Ablauf verschwindet unbemerkt: Ein Scan erreicht das Postfach nicht, das ERP sendet keine Rechnung, das Monitoring liefert keinen Alarm oder eine Website bestätigt ein Formular nicht.

Ein App-Kennwort ist keine Lösung, weil es weiterhin Basisauthentifizierung verwendet. Auch Port 587 und TLS-Verschlüsselung machen die Authentifizierung nicht modern; sie schützen die Verbindung, nicht die gespeicherten Anmeldedaten. Für jeden Absender ist daher ein unterstütztes Zielmodell erforderlich.

Die passende Alternative für jedes Szenario

OAuth mit SMTP AUTH

Unterstützt der Hersteller des Geräts oder der Anwendung OAuth für SMTP, kann dies die kleinste Änderung am bestehenden Ablauf sein. Server und Port können gleich bleiben, während der Client statt eines Kennworts ein Token verwendet. Die Microsoft-Dokumentation zu OAuth für SMTP beschreibt den delegierten Bereich SMTP.Send sowie den Anwendungszugriff über SMTP.SendAsApp. Der Anwendungszugriff erfordert eine korrekt konfigurierte App-Registrierung in Microsoft Entra ID, die Zustimmung eines Administrators und die Registrierung eines Dienstprinzipals in Exchange Online.

Microsoft Graph für eigene Anwendungen

Bei einer eigenen Website, einem Portal oder einer Automatisierung ist es häufig sinnvoller, keinen Mailclient mehr nachzubilden und über Microsoft Graph zu senden. Die Operation sendMail unterstützt delegierte und anwendungsbezogene Mail.Send-Berechtigungen, HTML, MIME und Anhänge. Graph ist jedoch kein Wert, der einfach in einen normalen Drucker eingetragen werden kann; die Anwendung muss Tokens abrufen und eine API aufrufen können.

SMTP-Relay für lokale Geräte

Für Geräte in einem stabilen Firmennetz kann SMTP-Relay über einen Exchange-Online-Connector geeignet sein. Die Authentifizierung wird an ein Zertifikat oder eine statische, nicht gemeinsam genutzte öffentliche IP-Adresse gebunden, und das Relay kann an interne sowie externe Empfänger senden. Erforderlich sind ein korrekt eingerichteter Connector, Port 25 und Kontrollen, die ein offenes Relay verhindern.

HVE, Direct Send und Azure Communication Services

High Volume Email ist für den umfangreichen internen Versand innerhalb der Organisation vorgesehen und kann laut Microsoft auch Anwendungen unterstützen, die bei Drittanbietern gehostet werden. Für externe Transaktionsnachrichten ist es kein Ersatz. Direct Send kann nur an Empfänger in derselben Organisation zustellen und ist laut Microsoft eher für fortgeschrittene, streng kontrollierte Szenarien gedacht. Für externen Anwendungsversand und hohe Volumina empfiehlt Microsoft, Azure Communication Services Email zu prüfen.

Der offizielle Entscheidungsleitfaden von Microsoft vergleicht die Grenzen dieser Möglichkeiten. Die Entscheidung sollte nicht nur davon abhängen, was am schnellsten eingerichtet ist. Wichtig sind die Empfänger, der Betriebsort der Anwendung, ihre OAuth-Unterstützung, das Versandvolumen und die spätere Entziehung der Berechtigungen.

Warum ein erneutes Aktivieren der Basisauthentifizierung nicht genügt

Eine vorübergehende Reaktivierung kann während eines Vorfalls oder einer schrittweisen Migration helfen, ist aber kein Zielzustand. Die Basisauthentifizierung präsentiert bei jedem Versuch dieselben Anmeldedaten und kann Mehrfaktorauthentifizierung nicht so nutzen wie moderner tokenbasierter Zugriff. Erhält ein Angreifer das Kennwort, kann er es außerhalb des verwalteten Geräts und des üblichen Benutzerkontexts testen.

Microsoft empfiehlt, SMTP AUTH für die gesamte Organisation zu deaktivieren und nur für Postfächer zu aktivieren, die es tatsächlich benötigen. Zusätzlich müssen Security Defaults und Authentifizierungsrichtlinien geprüft werden, weil sie die Basisauthentifizierung unabhängig von der individuellen SMTP-AUTH-Einstellung eines Postfachs blockieren können.

Eine unterbrechungsfreie Migration braucht Verantwortliche und einen Pilotbetrieb

1. Inventar erstellen. Kombinieren Sie den SMTP-AUTH-Clients-Bericht, Microsoft-Entra-ID-Anmeldeprotokolle, Gerätekonfigurationen, DNS- und Firewall-Daten sowie Gespräche mit Anwendungsverantwortlichen.
2. Verantwortung zuweisen. Jeder Absender benötigt eine verantwortliche Person, einen Geschäftszweck, definierte Empfänger und einen Herstellerkontakt.
3. Zielarchitektur auswählen. Entscheiden Sie zwischen OAuth SMTP, Graph, Relay, HVE, Direct Send oder einem spezialisierten E-Mail-Dienst.
4. Außerhalb kritischer Abläufe testen. Prüfen Sie Anhänge, HTML, Absenderidentität, Grenzwerte, externe Zustellung, SPF/DKIM/DMARC und das Verhalten bei Fehlern.
5. Nach der Umstellung überwachen. Eine Antwort der API oder des SMTP-Servers reicht nicht. Beobachten Sie tatsächliche Zustellung, Warteschlangen, Unzustellbarkeiten und Anwendungsprotokolle.
6. Alte Geheimnisse entfernen. Widerrufen Sie nach erfolgreicher Umstellung Kennwörter und Ausnahmen, dokumentieren Sie die Lösung und planen Sie die Erneuerung von Zertifikaten oder Anwendungsgeheimnissen.

Welche Informationen die Geschäftsleitung braucht

Das Ergebnis sollte nicht nur eine Liste technischer Konten sein. Die Geschäftsleitung muss wissen, welche Prozesse ausfallen könnten, welche Folgen ein Ausfall hätte, wer die Behebung verantwortet und wann sie abgeschlossen sein wird. Rechnungsstellung, Sicherheitsalarme, Kundenkommunikation und betriebliche Meldungen haben die höchste Priorität.

Yenwa kann ein Microsoft-365-Audit mit einem Netzwerk- und Anwendungsinventar verbinden, für jeden Absender den passenden Weg auswählen und sowohl den Pilotbetrieb als auch die Kontrolle nach der Migration vorbereiten. Wir erbringen diese Leistungen im Rahmen unserer Cloud-Dienste, der laufenden IT-Betreuung sowie der Entwicklung individueller Anwendungen und Integrationen.

Der beste Zeitpunkt für den ersten Bericht ist nicht der Tag, an dem sich ein Scanner nicht mehr anmelden kann. Er ist jetzt, solange sich einzelne Abläufe ohne Zeitdruck testen und Lösungen nach ihrem tatsächlichen Zweck auswählen lassen.