Der KRITIS-taugliche M365-Tenant: Meine Referenzarchitektur von Identity bis SharePoint

Seit dem NIS2-Umsetzungsgesetz zählen in Deutschland rund 30.000 Unternehmen zu den regulierten Einrichtungen, nicht mehr nur die knapp 4.500 klassischen KRITIS-Betreiber von früher. Die BSI-Registrierungsfrist dafür lief am 6. März 2026 ab. Für die physische Resilienz nach dem KRITIS-Dachgesetz, zuständig ist hier nicht das BSI, sondern das BBK, endete die Registrierungsfrist gerade erst am 17. Juli 2026.

Zwei Fristen, zwei Behörden, ein gemeinsamer Kern: Wer jetzt noch glaubt, KRITIS-Absicherung sei ein Compliance-Häkchen, das man einmal setzt und dann vergisst, hat die eigentliche Anforderung nicht verstanden. Es geht um Meldefähigkeit (24 Stunden Frühwarnung, 72 Stunden erste Bewertung, spätestens 30 Tage Abschlussbericht) und um eine Architektur, die einen Vorfall überhaupt schnell genug erkennt, um diese Fristen einzuhalten.

Das hier ist meine Referenzarchitektur für einen Microsoft-365-Tenant, der dieser Realität standhält, mit konkreten Klick-für-Klick-Schritten und echten Config-Werten aus einem laufenden Tenant, nicht nur der Theorie darüber. Kein vollständiger Anforderungskatalog, sondern die Bausteine, die ich zuerst bauen würde, in der Reihenfolge, in der ich sie bauen würde.

Architektur im Überblick

Identity steht oben, nicht weil es zuerst im Alphabet kommt, sondern weil jede andere Schicht auf ihr aufbaut. Ein kompromittiertes Konto mit gültigem Token umgeht Device Compliance, umgeht Mail-Filter und umgeht DLP, solange die Anmeldung selbst nicht als riskant erkannt und gestoppt wird.

Lizenzrealität, bevor wir weitermachen

Ohne die richtigen Lizenzen ist der Rest dieses Artikels Theorie. Für die volle Architektur brauchst du im Kern:

Baustein	Lizenz
Risk-Based Conditional Access, Identity Protection	Microsoft Entra ID P2
Privileged Identity Management	Microsoft Entra ID P2 oder Entra ID Governance
Erweiterte Mail- und Collaboration-Security	Defender for Office 365 Plan 2
EDR, ASR Rules, Threat & Vulnerability Management	Defender for Endpoint Plan 2
CASB, Session Control, Shadow-IT-Discovery	Defender for Cloud Apps
Sensitivity Labels, DLP, Container-Labels	Microsoft Purview (in E5 enthalten)

In der Praxis heißt das meistens Microsoft 365 E5 oder E3 plus das E5-Security-Add-on. Wer hier spart, spart nicht am Preis, sondern an genau den Fähigkeiten, die eine KRITIS-Meldung in 24 Stunden überhaupt möglich machen.

Baustein 1: Risk-Based Identity Protection

Alles andere in diesem Artikel ist verhandelbar in Reihenfolge und Tiefe. Das hier nicht. Wenn ich nur einen einzigen Baustein aus diesem Artikel umsetzen dürfte, wäre es dieser.

Der Grund ist simpel: In einem Cloud-first-Tenant gibt es kein Netzwerk-Perimeter mehr, das irgendetwas schützt. Jeder Zugriff auf Exchange, Teams, SharePoint oder Azure läuft über eine Anmeldung bei Entra ID. Wenn diese Anmeldung selbst nicht bewertet wird, ist jede andere Kontrolle in diesem Artikel nachgelagert.

Risikotyp	Was bewertet wird	Microsoft-Empfehlung
Sign-in Risk	Wahrscheinlichkeit, dass die konkrete Anmeldung nicht vom rechtmäßigen Besitzer stammt (anonyme IPs, unmögliche Reisegeschwindigkeit, Malware-verknüpfte IPs)	MFA erzwingen ab Medium und High
User Risk	Wahrscheinlichkeit, dass das Konto insgesamt kompromittiert ist (geleakte Zugangsdaten, wiederholte riskante Anmeldungen)	Risk Remediation erzwingen bei High

Der entscheidende Mechanismus dahinter ist Self-Remediation: Erfüllt ein Nutzer die geforderte Kontrolle (MFA bei Sign-in Risk, sicherer Passwortwechsel oder erneute starke Authentifizierung bei User Risk), gilt das Risiko als behoben. Kein Admin muss manuell eingreifen. Genau das macht das Modell in der Fläche überhaupt betreibbar, ohne dass ein SOC-Team jede einzelne Risk Detection einzeln abarbeiten muss.

Baustein 2: Geräte absichern (Intune und Defender for Endpoint)

Erst wenn Identity steht, ergibt Device Compliance als zusätzliche Grant Control überhaupt Sinn, siehe dazu auch meinen Artikel zu Conditional Access. Auf der Geräteseite geht es um drei Dinge, die zusammenspielen müssen: eine Baseline-Konfiguration, aktive Angriffsflächen-Reduktion und eine Compliance-Definition, die Conditional Access überhaupt etwas zum Prüfen gibt.

Baustein 3: E-Mail absichern (Exchange Online und Defender for Office 365)

E-Mail bleibt der häufigste Erstzugriffsvektor, das ändert sich seit Jahren nicht. Bevor Defender for Office 365 irgendetwas Sinnvolles filtern kann, müssen aber die Grundlagen stehen, das wird in Projekten überraschend oft übersprungen, weil es "eh schon lange läuft".

Baustein 4: Teams, SharePoint und OneDrive (Purview als Klammer)

Zwei Label-Ebenen, die häufig verwechselt werden:

Item-Labels schützen einzelne Dateien und E-Mails, inklusive Verschlüsselung und Wasserzeichen.
Container-Labels schützen die Arbeitsumgebung selbst, also Teams, Microsoft-365-Gruppen und SharePoint-Sites, über externe Freigabe, Gastzugriff und Zugriff von nicht verwalteten Geräten.

Ohne Container-Labels kann ein Team mit offenem Gastzugriff entstehen, in dem trotzdem als „Vertraulich“ gekennzeichnete Dokumente landen. Die Site-Sicherheit und die Dokumenten-Klassifizierung laufen dann komplett auseinander.

Baustein 5: Defender for Cloud Apps als Klammer über allem

Defender for Cloud Apps würde ich nicht isoliert betrachten, sondern als die Schicht, die Conditional-Access-Entscheidungen in die tatsächliche Session hinein verlängert. Eine Conditional-Access-Policy entscheidet beim Login, Defender for Cloud Apps kann dieselbe Entscheidungslogik während der laufenden Session weiter durchsetzen.

Baustein 6: Monitoring und die eigentliche Meldepflicht

Der Grund, warum ich Monitoring nicht als Nebensache behandle: Die 24-Stunden-Frühwarnfrist beginnt nicht mit der Entscheidung, ob ihr meldet, sondern mit dem Zeitpunkt, an dem der Vorfall erkennbar gewesen wäre. Fünf getrennte Portale für Endpoint, Mail, Identity und Cloud Apps, zwischen denen ein Mensch händisch korrelieren muss, sind für diese Frist schlicht zu langsam.

Meine Priorisierung, wenn Zeit und Budget begrenzt sind

Realistisch baut niemand alles gleichzeitig. Wenn ich priorisieren müsste:

Risk-Based Conditional Access, phishing-resistente MFA, PIM. Das ist der Baustein, der jeden anderen erst wirksam macht. Ohne ihn ist alles Weitere Absicherung eines Perimeters, den es in der Cloud gar nicht mehr gibt.
Device Compliance und ASR Rules. Die zweite Kontrollebene, die verhindert, dass ein kompromittiertes Gerät trotz sauberer Identität zum Einfallstor wird.
Defender for Office 365 mit sauberer Mail-Authentifizierung. E-Mail bleibt der häufigste Erstzugriffsvektor, das ändert sich seit Jahren nicht.
Sensitivity Labels und DLP für Teams und SharePoint. Schützt die Daten dort, wo Identity und Device bereits versagt haben könnten.
Defender for Cloud Apps als letzte Kontrollebene. Wichtig, aber am wenigsten wirksam, wenn die ersten vier Schichten nicht stehen.
Monitoring und der Meldeprozess selbst. Technisch am Ende der Kette, aber ohne diesen Baustein bringt euch die beste Architektur nichts, wenn ihr die 24-Stunden-Frist trotzdem reißt, weil niemand weiß, wer wie meldet.

Diese Reihenfolge ist kein Zufall. Sie folgt genau der Architektur-Grafik von oben. Und sie ist der Grund, warum ich am Anfang dieses Artikels so viel Zeit auf Identity Protection verwendet habe, während andere Bausteine kompakter bleiben: In einem KRITIS-Tenant ist Identity nicht ein Baustein unter vielen. Es ist der Baustein, der entscheidet, ob alle anderen überhaupt noch etwas wert sind.

TL;DR

Identity zuerst: Sign-in-Risk- und User-Risk-Policies in Conditional Access (nicht im alten Identity Protection Blade, das wird am 1.10.2026 abgeschaltet), phishing-resistente Authentication Strength, PIM für alle privilegierten Rollen
Device: Security Baseline als Startpunkt, ASR Rules mit den drei Standardregeln direkt auf Block, Rest zuerst im Audit-Modus
Exchange: SPF/DKIM/DMARC vollständig (auch für Subdomains), Basic Auth aus, Preset Security Policies statt selbstgebauter Custom Policies
Purview: vier bis fünf Label-Stufen reichen, Container-Label + Conditional-Access-Authentication-Context + DLP müssen zusammen wirken, sonst ist das Label nur Metadaten
Cloud Apps: Conditional Access App Control aktiv routen, sonst bleibt es reines Reporting ohne Durchsetzung
Monitoring: Defender XDR als einzige Incident-Quelle, Eskalationspfad für die 24h-Frist getestet (nicht nur dokumentiert), BSI- und BBK-Meldewege vorab sauber getrennt hinterlegt