Letztes Jahr habe ich meine Microsoft-365-Sicherheits-Baseline für 2025 veröffentlicht. Ruhig ist es seitdem erwartungsgemäß nicht geworden, denn auch dieses Jahr gab es bei Identity, E-Mail und Cloud-Governance ständig Bewegung. In vielen Kundentenants, die ich betreue, steigen die Anforderungen, Audits schauen genauer hin, und Microsofts Vorgaben umzusetzen ist für die meisten längst keine freiwillige Sache mehr. Die Sicherheits-Baseline 2026 verstehe ich deshalb nicht als Wunschliste. Sie beschreibt den realistischen Mindeststandard, der sich aus dem Jahr 2025 ergibt, also aus Compliance-Anforderungen, Angriffswellen und Microsofts neuem Standard-Schutzniveau. Grundlage sind meine Erfahrungen aus Projekten und das, was Microsoft inzwischen entweder verpflichtend vorschreibt oder über Lizenz, Roadmap oder Security Score dringend empfiehlt. Im Folgenden gleiche ich die Baseline mit der Sicherheits-Checkliste 2025 aus dem Vorjahr ab und zeige, welche Neuerungen in keinem Tenant fehlen sollten.

Phishing-resistente MFA wird zur Pflicht und verlangt eine saubere Migration

Rückblickend hat Microsoft 2025 den phishing-resistenten MFA-Rollout zur Pflicht gemacht. Wer privilegierte Konten noch mit klassischen Authenticator-Prompts, SMS oder App-Bestätigungen absichert, kommt schon jetzt nicht mehr überall durch. Zumindest die Admin-Portale (Entra, Microsoft 365, Azure) verlangen seit Oktober 2025 zwingend eine Mehrfaktor-Authentifizierung. Zugleich wächst der Druck, auch Standardnutzer und Servicekonten mit wirklich sicherer MFA zu schützen. Trotzdem begegnen mir immer noch Tenants mit alten „Per-User-MFA“-Aktivierungen oder überholten Richtlinien für Self-Service Password Reset und MFA. An der Migration auf die neue Authentifizierungsmethodenrichtlinie in Entra ID führt inzwischen kein Weg mehr vorbei. Nur mit ihr lassen sich passwortlose Methoden, Passkeys und FIDO2-Schlüssel differenziert steuern, und die alten Richtlinien schaltet Microsoft nach und nach ab.

Praxistipp: Wer viele Altsysteme oder Automatisierungen betreibt, sollte vor der Migration die Berichte zur Authentifizierungsmethode in Entra ID (Identity → Schutz → Authentifizierungsmethoden) auswerten. So spürt man unbekannte Abhängigkeiten auf und kann Nutzungsstatistiken exportieren.

Wie die Umstellung konkret abläuft, lest ihr in meinem Beitrag Auf die Authentifizierungsmethodenrichtlinie migrieren.

Der Device-Code-Flow gehört endgültig blockiert

Als Einfallstor wird der Device-Code-Flow für OAuth-Apps oft unterschätzt. 2025 haben ihn fast alle Mandanten per Conditional Access gesperrt. Die Angriffe rund um Storm-2372 und Midnight Blizzard haben gezeigt, dass selbst unscheinbare Altfunktionen in Microsoft 365 erhebliche Risiken bergen. Unter Conditional Access → Neue Richtlinie legt man dafür einfach eine Richtlinie mit dem Filter „Client App“ → „Device Code“ an und unterbindet damit die Anmeldung per Device-Code-Flow. Betroffen sind vor allem ältere Automatisierungen, CLI-Tools und Legacy-Anwendungen, die noch nicht auf moderne Authentifizierungsmethoden oder Workload Identities umgestellt sind. Microsoft rät in der Zero-Trust-Guidance ausdrücklich zu diesem Schritt, und in der Baseline 2026 ist er Pflicht.

flowchart TD
    Logins["Benutzer-Logins"] --> CA["Conditional Access"]
    CA --> DeviceCode["Device Code Flow blockiert"]
    CA --> ModernAuth["Moderne Authentifizierung erlaubt"]
    DeviceCode --> Blocked["Zugriff verweigert"]
    ModernAuth --> Allowed["Zugriff gewährt"]

Abbildung: Conditional Access blockiert den Device-Code-Flow, zugelassen sind nur moderne Authentifizierungsmethoden.

Direct Send und DMARC setzen veraltete SMTP-Integrationen unter Druck

Das ganze Jahr 2025 über hat uns außerdem E-Mail-Spoofing über Direct Send oder ungesicherte SMTP-Gateways beschäftigt. Seit Mitte 2025 blockiert Microsoft „Direct Send“ bei neuen Tenants standardmäßig. Die Durchsetzung von DMARC für ein- und ausgehende Nachrichten wird zur Pflicht, spätestens mit den Vorgaben für Großkunden und Behörden ab dem vierten Quartal. Wer noch keine DMARC-Policy im DNS hinterlegt hat, muss das spätestens jetzt nachholen.

Für Exchange Online kann ein minimales DMARC-Setup im DNS etwa so aussehen:

_dmarc.example.com.   3600   IN   TXT   "v=DMARC1; p=reject; rua=mailto:[email protected]"

Ob Nutzer oder Geräte noch per Direct Send verschicken, sieht man im Exchange Admin Center → Nachrichtenfluss → Sendeconnectors und in den Überwachungsprotokollen. Wie ihr SMTP sicher konfiguriert, zeige ich im Beitrag SPF, DKIM und DMARC für Exchange Online einrichten.

Altlasten bei Windows 10, Exchange und SharePoint müssen verschwinden

Mit der Abkündigung von Windows 10 zum Jahresende 2025 ist das Thema End-of-Life endgültig bis in den letzten Winkel der Organisation vorgedrungen. In der Praxis stoße ich häufiger, als man denkt, auf einzelne Altgeräte, Spezialanwendungen oder Lab-PCs, die noch unter Windows 10 laufen. Die Sicherheits-Baseline 2026 zieht hier eine klare Grenze und lässt keinen produktiven Windows-10-Client mehr ohne Extended Security Updates (ESU) oder vollständige Isolierung zu. Hybrid- und Legacy-Server wie Exchange und SharePoint gehören auf den aktuellen Patchstand. Die Angriffe mit ToolShell-Exploits und die Schwachstellen in Exchange-Hybridumgebungen haben 2025 deutlich gemacht, dass jeder ungepatchte Server ein Einfallstor ist. Wer noch hybrid arbeitet, sollte sich dringend mit der dedizierten Hybrid-App und dem Patchmanagement befassen (Exchange-Hybrid-Schwachstelle und dedizierte Hybrid-App).

Workload-Identitäten und Agenten brauchen Governance statt Secrets

Agenten und Servicekonten gehören 2025 in jedem Tenant zum Alltag, nicht zuletzt wegen Copilot, Automatisierung und Multi-Cloud-Workloads. Trotzdem finde ich in der Praxis leider noch zahlreiche App-Registrierungen mit Client-Secrets, die nie ablaufen. Die neue Baseline lässt hier keinen Spielraum. Alle produktiv genutzten Service Principals müssen auf Workload Identity Federation (z. B. Workload Identity Federation in Entra ID für GitHub Actions oder Azure DevOps) oder Managed Identities umziehen. Damit sinkt das Risiko von Secret-Leaks, und Rotation und Überwachung werden einfacher. Eine Governance für KI- und Automatisierungs-Agenten, etwa über „Administrative Units“ oder Azure Policy, ist inzwischen ebenfalls Pflicht. Wer Copilot Studio oder andere Agentenplattformen einsetzt, sollte Berechtigungen und Data Loss Prevention (DLP) nicht auf die lange Bank schieben (Checkliste zur Agenten-Governance in Microsoft 365).

Logging, Aufbewahrung und Sentinel im Defender-Portal schließen die Lücken im Audit

Ein weiterer Schwerpunkt 2025 war die Vereinheitlichung von Security- und Audit-Logs. Sentinel ist jetzt in das Defender-Portal integriert, was Analyse und Incident Response spürbar vereinfacht. Grundvoraussetzung bleibt, dass jeder Tenant die zentralen Logs – Entra-ID-Anmeldeprotokolle, Audit-Logs, M365-Workloads – mindestens 90 Tage, besser 180 Tage aufbewahrt. Wer Advanced Auditing oder Microsoft 365 E5 lizenziert hat, kann im Compliance-Portal detaillierte Aufbewahrungsrichtlinien festlegen. In meinen Projekten zeigt sich immer wieder, dass JIT-Rollenvergabe, Access Reviews und Incident Response erst dann verlässlich funktionieren, wenn die zentralen Logs an einer Stelle zusammenlaufen (Vorbereitung auf Incident Response mit Protokollen in Microsoft 365).

Die Log-Aufbewahrung sollte man regelmäßig unter Compliance-Portal → Lösungen → Audit → Aufbewahrungsrichtlinien kontrollieren.

Die Baseline bleibt auch in Zukunft nicht stehen

Die Sicherheits-Baseline 2026 ist damit kein optionales Sicherheitsniveau mehr, sie beschreibt das Minimum. Microsoft wird Standards wie phishing-resistente MFA, DMARC oder Agenten-Governance künftig noch schneller durchsetzen. Wer jetzt investiert, erspart sich meiner Überzeugung nach aufwendige Nacharbeiten, Korrekturen nach Audits und Risiken für den eigenen Ruf. Im Rückblick war 2025 das Jahr, in dem aus „Best Practice“ und „Empfehlung“ in vielen Bereichen echtes Pflichtprogramm wurde. Ich gehe davon aus, dass die Baseline auch 2026 weiter wächst. Was heute schon Pflicht ist, sollte trotzdem kein Tenant mehr aufschieben.