Seit dem Update zur Microsoft Secure Future Initiative im April 2025 fragen sich viele IT-Teams, welche der großen Ankündigungen im eigenen Tenant inzwischen tatsächlich umgesetzt sind. In meinem Arbeitsalltag begegnen mir zahlreiche Veränderungen, die direkt auf die Secure Future Initiative zurückgehen. Manche fallen durch neue Einstellungen auf, andere merkt man erst, wenn sie im Hintergrund greifen. Vor allem bei Kunden, die Microsoft 365 und Azure intensiv nutzen, gibt es heute deutlich mehr sicherheitsrelevante Standardeinstellungen und verpflichtende Vorgaben als früher. Automatisch sicher ist damit aber noch nichts, und manches bleibt weiterhin meine Aufgabe als Admin.

In den Kundentenants ist von der Secure Future Initiative schon viel angekommen

Wer heute einen durchschnittlichen Cloud-Tenant öffnet, erkennt schnell die Richtung, nämlich „secure by default“. Microsoft hat die Messlatte in den letzten Monaten spürbar angehoben, etwa mit der MFA-Pflicht für die Azure- und Entra-Adminportale (Details im Blog) und mit immer mehr Microsoft-verwalteten Conditional-Access-Richtlinien (Details und Praxiseinschätzung). Neue Tenants starten inzwischen mit deutlich strengeren Grundeinstellungen. Standardfreigaben für Externe, unsichere Authentifizierungsprotokolle oder anonyme Freigaben sind meist schon ab Werk eingeschränkt oder abgeschaltet.

Außerdem räumt Microsoft im Zuge der Secure Future Initiative konsequent mit Altlasten auf. Veraltete Protokolle wie Basic Auth, POP oder IMAP werden nach und nach endgültig deaktiviert, gerade bei Exchange Online und Entra. Damit müssen auch Umgebungen modernisieren, in denen Sicherheit bisher keine große Rolle gespielt hat. Und gelegentlich ist die Überraschung groß, wenn ältere Workflows plötzlich nicht mehr laufen. Wer sich früh darum gekümmert hat, war klar im Vorteil.

Praxistipp: Wer noch irgendwo POP, IMAP oder Basic Auth einsetzt, sollte dringend prüfen, ob dort bereits Abschaltungen anstehen. Einen schnellen Überblick bietet das Exchange Online Admin Center → Einstellungen → E-Mail-Apps.

Einige SFI-Prinzipien können Admins direkt übernehmen

Neben den technischen Maßnahmen steckt in der Secure Future Initiative für mich vor allem eine Reihe von Prinzipien, die man als Admin selbst übernehmen kann und häufig auch sollte. „Secure by default“ ist dabei mehr als ein Werbespruch. Lege ich neue Ressourcen oder Identitäten an, sollten restriktive Einstellungen und minimale Berechtigungen der Normalfall sein und nicht die Ausnahme. Dazu gehört in erster Linie, für alle privilegierten Konten phishing-resistente MFA strikt durchzusetzen, zum Beispiel mit FIDO2-Keys oder Passkeys.

Bewährt hat sich in der Praxis auch die strikte Isolierung von Produktionsumgebungen. Testuser haben in Produktivgruppen nichts verloren, und Service-Accounts teilt man nicht zwischen Umgebungen. Mit SBUs in Azure und Administrative Units in Entra zeigt Microsoft inzwischen besser, wie das gehen kann, die organisatorische Trennung bleibt aber Chefsache. Ebenso eindeutig ist, dass lückenlose Protokollierung und längere Aufbewahrung heute Pflicht sind und keine Kür. Wer sich auf die Standardaufbewahrung verlässt, kann im Ernstfall oft zu wenig nachvollziehen.

Diese SFI-Prinzipien lassen sich am besten auf eigene Richtlinien und Prozesse übertragen:

  • „Secure by default“ – restriktive Standardwerte für neue Ressourcen
  • Phishing-resistente MFA für alle privilegierten Konten
  • Strikte Isolierung von Entwicklungs-, Test- und Produktionsumgebungen
  • Lückenlose Protokollierung und erweiterte Aufbewahrung (z. B. Purview Audit)
  • Regelmäßige Kontrolle und Entfernung veralteter Protokolle und Integrationen

Weitere Hintergründe stehen in meinem älteren Beitrag zur Secure Future Initiative und in der Übersicht zu den Zero-Trust-Prinzipien.

Vieles bleibt trotzdem in der Verantwortung der Admins

Auch wenn sich durch die Secure Future Initiative einiges getan hat, kann und will Microsoft nicht alles zentral regeln. In fast allen Kundenprojekten beobachte ich, dass Richtlinien und Standardeinstellungen zwar eine solide Grundlage schaffen, aber nur so viel bringen, wie die Umsetzung vor Ort hergibt. Microsoft-verwaltete Conditional-Access-Richtlinien etwa sind oft ein guter Anfang, treffen besondere Anforderungen aber selten genau. Wer wirklich wissen will, was in seinem Tenant vor sich geht, kommt um eine regelmäßige Auswertung der Audit- und Aktivitätslogs und um eigene Alarme nicht herum.

Eine Daueraufgabe bleiben auch das Prinzip der minimalen Rechte („least privilege“) und die Kontrolle von App-Berechtigungen. Die SFI hat für sichere Standardwerte viel getan, gegen Schatten-IT, zu weit gefasste OAuth-Berechtigungen und vergessene Gastkonten hilft aber keine zentrale Vorgabe. Die von Microsoft bereitgestellten Richtlinien für den Gastzugriff greifen zum Beispiel in historisch gewachsenen Tenants häufig nicht. Dann muss man selbst mit Access Reviews und Bereinigungstools nacharbeiten, so wie ich es im Beitrag zu Gastkonten und Access Reviews beschrieben habe.

SFI-Änderungen erreichen den Tenant meist in mehreren Schritten

Das folgende Diagramm zeigt, wie Microsoft-Initiative, Tenant-Standardwerte und Maßnahmen der Admins ineinandergreifen. Neue SFI-Maßnahmen landen meist in mehreren Etappen im Kundentenant, und an welcher Stelle der Admin weiterhin am längeren Hebel sitzt, ist darin ebenfalls zu sehen.

flowchart TD
    SFI["SFI-Maßnahme angekündigt"] --> MSCloud["Microsoft-Cloud-Update"]
    MSCloud --> Defaults["Neue sichere Defaults"]
    MSCloud --> Policies["Microsoft-verwaltete Richtlinien"]
    Defaults --> Tenant["Kundentenant: Einstellungen aktualisiert"]
    Policies --> Tenant
    Tenant --> Admin["Admin: Überprüfung und Anpassung"]
    Admin --> SecureOps["Eigene Prozesse/Policies"]

Abbildung: Von der SFI-Ankündigung bis zur Umsetzung im Kundentenant und in den Admin-Prozessen.

Die SFI gibt Rückenwind, ist aber kein Autopilot

Mit der Secure Future Initiative ist die Microsoft-Cloud sicherer geworden, und viele längst überfällige Standardeinstellungen gelten nun flächendeckend. In der Praxis sehe ich aber immer wieder, dass ein Tenant erst dann wirklich sicher ist, wenn Admins die SFI-Prinzipien als Startpunkt nutzen und konsequent weiterentwickeln. Wer sich nur auf zentrale Vorgaben verlässt, übersieht neue Risiken und Ausnahmen schnell. Bei der Aufbewahrung der Auditlogs, bei Gastberechtigungen oder bei MFA-Methoden kommt es weiterhin auf die eigene Verantwortung an. Einen Autopiloten bekommt man mit der SFI nicht, wohl aber den Rückenwind, den jedes Cloud-Team braucht, um Sicherheit als Standard zu etablieren. Wer diesen Rückenwind nutzt, ist 2025 klar im Vorteil.