„Wir machen Zero Trust." Diesen Satz höre ich in fast jedem Erstgespräch — und in neun von zehn Fällen ist damit gemeint: „Wir haben MFA aktiviert." Das ist ein Anfang, aber kein Zero Trust. Zero Trust ist kein Produkt, das Du kaufst, und kein Häkchen, das Du setzt. Es ist ein Architekturprinzip, das Du über Identität, Geräte, Netzwerk, Apps und Daten hinweg konsequent durchziehst.
Die gute Nachricht für KMU: Wenn Du Microsoft 365 in einem E3- oder E5-Plan einsetzt, hast Du die meisten Bausteine bereits lizenziert. Du musst sie nur richtig zusammensetzen. In diesem Guide zeige ich Dir, was Zero Trust mit Microsoft 365 konkret bedeutet, in welcher Reihenfolge Du die Säulen umsetzt, und wie eine realistische Reifegrad-Roadmap für ein Unternehmen mit 50–500 Mitarbeitenden aussieht — ohne dass Du alles doppelt baust.
Alles Wichtige auf einen Blick
Zero Trust in drei Sätzen — und was es für KMU heißt
Zero Trust mit Microsoft 365 bedeutet, dass kein Benutzer, kein Gerät und keine App automatisch als vertrauenswürdig gilt — jeder Zugriff auf Daten, Apps und Dienste wird in Echtzeit anhand von Identität, Gerätestatus und Risiko geprüft. Microsoft 365 liefert die Bausteine dafür über alle Säulen hinweg: Entra ID und Conditional Access für die Identität, Intune und Defender for Endpoint für Endgeräte, Global Secure Access (ZTNA) für das Netzwerk und Microsoft Purview für die Daten. Du kaufst also keine neue Plattform, sondern setzt vorhandene Funktionen richtig zusammen.
Zero Trust beruht auf drei Leitsätzen, die Microsoft sauber formuliert hat: explizit verifizieren (jeder Zugriff wird anhand aller verfügbaren Signale geprüft), Least Privilege durchsetzen (jede Identität bekommt nur so viele Rechte wie nötig, just-in-time) und Breach annehmen (Du gestaltest die Umgebung so, als sei der Angreifer bereits drin — und begrenzt seinen Bewegungsradius).
Für ein KMU heißt das vor allem eines: Schluss mit dem impliziten Vertrauen ins „interne Netzwerk". Das klassische Burg-und-Graben-Modell — Firewall außen, alles innen vertrauenswürdig — ist mit Cloud, Homeoffice und BYOD nicht mehr zu halten. Sobald eine einzige Identität kompromittiert ist, bewegt sich der Angreifer in einem flachen Netzwerk seitwärts (laterale Bewegung) und erreicht in Stunden Deine Kronjuwelen.
Zero Trust dreht das um: Nicht der Standort entscheidet über Vertrauen, sondern der jeweils geprüfte Kontext — Wer bist Du? Von welchem Gerät? Ist das Gerät gesund? Ist das Verhalten unauffällig? Erst wenn diese Signale stimmen, gibt es Zugriff — und auch dann nur auf das, was wirklich gebraucht wird. Die offizielle Einordnung findest Du in der Microsoft-Dokumentation zum Zero-Trust-Modell.
Die Säulen von Zero Trust im Microsoft-Mapping
Microsoft strukturiert Zero Trust in sechs Domänen. So ordnest Du die M365-Bausteine zu:
| Säule | Frage | Microsoft-Baustein |
|---|---|---|
| Identität | Wer greift zu? | Entra ID, Conditional Access, MFA, Identity Protection |
| Endpunkte | Ist das Gerät gesund? | Intune (Compliance), Defender for Endpoint |
| Apps | Ist die Anwendung kontrolliert? | Defender for Cloud Apps, App-Governance |
| Netzwerk | Ist der Zugriffsweg abgesichert? | Global Secure Access (SSE) |
| Daten | Sind die Daten klassifiziert und geschützt? | Microsoft Purview (Labels, DLP) |
| Sichtbarkeit & Automatisierung | Erkenne und reagiere ich? | Defender XDR, Sentinel, Secure Score |
Der entscheidende Punkt: Du musst nicht alle sechs Säulen gleichzeitig auf Maximum drehen. Zero Trust ist ein Reifegrad-Modell. Du fängst dort an, wo der Hebel am größten ist — bei der Identität — und arbeitest Dich nach außen vor. Einen strukturierten Einstieg in die Umsetzung bietet Microsofts Zero-Trust-Bereitstellungsleitfaden. Wer die Entra-Komponenten im Zusammenhang verstehen will, findet in unserem Guide zur Microsoft Entra Suite den passenden Überblick.
Der Unterschied zur klassischen Perimeter-Sicherheit ist fundamental: Firewalls und VPN ziehen eine Grenze zwischen „drinnen" und „draußen" — aber in einer Welt aus SaaS-Diensten, Cloud Apps und mobilen Mitarbeitern gibt es dieses „drinnen" nicht mehr. Deine Workloads liegen in Microsofts Cloud, Deine User arbeiten von überall, Deine Daten reisen zwischen Diensten. Zero Trust verschiebt die Kontrolle deshalb von der Netzwerkgrenze hin zu jeder einzelnen Zugriffsanfrage. Das Konzept dahinter — Zero Trust Network Access (ZTNA) — ersetzt das alte „einmal drin, immer vertraut" durch eine kontinuierliche Überprüfung pro Ressource. Genau das macht die Architektur tauglich für eine moderne, verteilte Infrastruktur.
Identität zuerst: Conditional Access und phishing-resistente MFA
Identität ist die neue Perimetergrenze. Über 80 Prozent der Angriffe, die ich in der Praxis sehe, beginnen mit einer kompromittierten Identität — nicht mit einer durchbrochenen Firewall. Deshalb ist die Identitätssäule der Startpunkt jeder Zero-Trust-Umsetzung.
Conditional Access als Policy-Engine
Conditional Access ist das Herzstück. Jede Anmeldung wird gegen Bedingungen geprüft — Benutzer, Gruppe, Anwendung, Standort, Geräte-Status, Risiko-Level — und das Ergebnis ist eine Entscheidung: zulassen, blockieren oder zusätzliche Kontrollen verlangen. Das ist „explizit verifizieren" in Reinform.
Eine häufige Frage aus der Praxis: „Wie kombiniere ich Zero Trust mit MFA und Conditional Access, ohne alles doppelt zu bauen?" Die Antwort: Du baust gar nichts doppelt. Conditional Access ist der Ort, an dem MFA, Geräte-Compliance und Risiko-Signale zusammenlaufen. MFA ist eine Kontrolle, die CA erzwingt — keine separate Welt. Starte mit den fünf Must-Have-CA-Richtlinien als Fundament, bevor Du in erweiterte Szenarien gehst.
Von „irgendeiner" MFA zu phishing-resistenter MFA
Hier liegt der häufigste Reifegrad-Fehler: MFA ist aktiviert, aber per SMS oder Push-Bestätigung — und damit anfällig für MFA-Fatigue und Adversary-in-the-Middle-Angriffe. Echtes Zero Trust verlangt phishing-resistente Verfahren (FIDO2-Sicherheitsschlüssel, Passkeys, Windows Hello for Business, zertifikatsbasierte Authentifizierung). Diese erzwingst Du über die Authentication Strengths in Conditional Access — beginnend bei den privilegierten Konten. Wie Du verhinderst, dass Angreifer Deine MFA umgehen, habe ich im Detail unter MFA-Bypass verhindern beschrieben; die Grundlagen findest Du im Guide zur Multi-Faktor-Authentifizierung.
Risiko-Signale und Least Privilege
Mit Entra ID P2 kommt Identity Protection ins Spiel: Anmelderisiko und Benutzerrisiko werden automatisch bewertet und fließen als Bedingung in CA ein. So entstehen risikobasierte Zugriffsrichtlinien, die bei verdächtigem Verhalten automatisch eine erneute Authentifizierung oder Sperre auslösen — und die etwa auch Token-Diebstahl spürbar erschweren.
Die Least-Privilege-Komponente realisierst Du über Privileged Identity Management: privilegierte Rollen werden nur noch just-in-time aktiviert statt dauerhaft zugewiesen. Mehr dazu im PIM-Guide. All das gehört zu den Entra ID Best Practices, die das Identitätsfundament Deines Zero-Trust-Modells bilden.
Geräte: Intune-Compliance und Defender-Signale in Conditional Access
Eine geprüfte Identität auf einem kompromittierten Gerät ist wertlos. Deshalb ist die zweite Säule der Gerätekontext — und der schönste Teil daran: Du baust ihn direkt in die bestehenden Conditional-Access-Richtlinien ein, statt eine zweite Kontrollebene zu errichten.
Der Ablauf hat drei Schritte:
Genau hier schließt sich der Kreis zur „Assume Breach"-Logik: Ein infiziertes Gerät verliert seinen Zugriff automatisch, ohne dass ein Admin eingreifen muss. Die Endpunkt- und XDR-Signale orchestrierst Du am besten im Zusammenspiel, das ich im Guide zur Defender-XDR-Umgebung beschreibe.
Netzwerk und Apps: Global Secure Access als Zero-Trust-Schicht
Die Netzwerksäule ist die, die in KMU am häufigsten fehlt — weil hier lange Zeit nur das alte VPN stand. Ein klassisches VPN ist das Gegenteil von Zero Trust: Wer einmal drin ist, ist „im Netz" und genießt implizites Vertrauen. Genau diese laterale Bewegung wollen wir verhindern.
Microsofts Antwort heißt Global Secure Access — die Security-Service-Edge-(SSE)-Lösung, die Zugriff nicht mehr netzwerk-, sondern identitäts- und richtlinienbasiert vergibt. Statt „Tunnel ins Netzwerk" gibt es granularen Zugriff pro Anwendung, abgesichert durch dieselben Conditional-Access-Richtlinien wie der Rest Deiner Umgebung. Die Frage „Welche Suite deckt MFA, Conditional Access und Least Privilege für eine Remote-Belegschaft ab?" beantwortet sich damit elegant: Es ist dieselbe Entra-/CA-Schicht, nur auf die Netzwerkebene ausgedehnt.
Zwei Bausteine sind relevant:
Den vollständigen Einstieg habe ich im Leitfaden zur Global-Secure-Access-SSE-Lösung beschrieben; die offizielle Referenz liefert die Microsoft-Dokumentation zu Global Secure Access. Auf App-Ebene ergänzt Defender for Cloud Apps die Sichtbarkeit über Schatten-IT und riskante OAuth-Anwendungen — eine Lücke, die in fast jedem gewachsenen Tenant existiert.
Daten: Purview-Labels und Least Privilege
Alle bisherigen Säulen schützen den Weg zu den Daten. Die letzte Säule schützt die Daten selbst — für den Fall, dass doch jemand durchkommt. Das ist „Assume Breach" konsequent zu Ende gedacht: Selbst wenn ein Angreifer eine Datei erreicht, soll sie für ihn nutzlos bleiben.
Drei Maßnahmen bilden das Fundament:
Gerade mit der Einführung von Microsoft 365 Copilot wird diese Säule kritisch: Copilot sieht alles, worauf der Benutzer Zugriff hat. Eine schlampige Berechtigungsstruktur wird so über Nacht zum Daten-Leck.
Sichtbarkeit und Automatisierung: die sechste Säule
Die fünf Kernsäulen schützen Identitäten, Geräte, Netzwerk, Apps und Daten. Die sechste Säule liegt quer darüber und entscheidet, ob das Ganze im Alltag funktioniert: Sichtbarkeit und Automatisierung. Denn „Assume Breach" bedeutet nicht nur, einen Angriff zu erwarten — es bedeutet, ihn auch zu erkennen und automatisiert darauf zu reagieren.
Das zentrale Werkzeug ist Microsoft Defender XDR: Es führt die Signale aus Identität, Endpunkten, E-Mail und Cloud Apps in einer Oberfläche zusammen und korreliert sie zu nachvollziehbaren Vorfällen. Statt 50 Einzelwarnungen aus verschiedenen Tools bekommst Du einen zusammenhängenden Angriffsverlauf. Wie Du diese Defender-XDR-Umgebung aufsetzt, habe ich separat beschrieben.
Für größere oder regulierte Umgebungen ergänzt Microsoft Sentinel als SIEM die Langzeit-Überwachung und das automatisierte Reagieren (SOAR) — inklusive der Einblicke, die ein Auditor zur Einhaltung von NIS2 oder ISO 27001 sehen will. Die kontinuierliche Überprüfung über alle Komponenten hinweg ist das, was Zero Trust von einer einmaligen Härtung unterscheidet: Es ist ein laufender Betrieb, kein Projekt mit Abschlussdatum.
Welche Lizenzen Deine Zero-Trust-Strategie voraussetzt
Eine häufige Sorge ist, dass Zero Trust ein teures Lizenz-Upgrade erzwingt. In der Praxis kommst Du mit den vorhandenen Microsoft-365-Plänen erstaunlich weit — entscheidend ist, welche Funktionen Du tatsächlich aktivierst:
Meine Empfehlung: Kauf nicht blind E5, sondern mappe zuerst Deine Zero-Trust-Roadmap auf die Funktionen, die Du in den nächsten Phasen wirklich brauchst. Oft reicht E3 plus ein gezieltes Add-on, um die nächste Reifegradstufe in der gesamten Umgebung zu erreichen — und Du investierst nur dort, wo die Sicherheit es rechtfertigt.
Die Zero-Trust-Reifegrad-Roadmap für KMU
Zero Trust auf einmal umzusetzen, überfordert jedes KMU. Deshalb arbeite ich mit meinen Kunden in Phasen. Die folgende Roadmap ist die, die sich in der Praxis bewährt hat:
Phase 1 — Identitätsfundament (Wochen 1–4)
Conditional-Access-Baseline ausrollen, MFA für alle erzwingen, phishing-resistente MFA für Admins, Break-Glass-Konten sauber lösen, PIM für privilegierte Rollen aktivieren. Das ist der Phase mit dem höchsten Sicherheitsgewinn pro Aufwand.
Phase 2 — Gerätevertrauen (Wochen 4–8)
Intune-Compliance-Richtlinien definieren, Geräte einbinden, „konformes Gerät" als CA-Bedingung schärfen, Defender-for-Endpoint-Risikosignal verdrahten.
Phase 3 — Netzwerk und Apps (Wochen 8–12)
Global Secure Access pilotieren, VPN-Ablösung für erste interne Apps, Schatten-IT mit Defender for Cloud Apps sichtbar machen.
Phase 4 — Daten und Reife (ab Woche 12)
Sensitivity-Label-Taxonomie ausrollen, DLP-Richtlinien scharfschalten, Berechtigungen bereinigen, Reviews etablieren.
Phase 5 — Betrieb und Nachweis (laufend)
Microsoft Secure Score als Fortschrittsmesser nutzen, Defender XDR und Sentinel für Erkennung und Reaktion, Konfiguration für Audits dokumentieren. Eine kompakte Maßnahmenliste findest Du in der Übersicht Microsoft 365 Security und Empfehlungen.
Der wichtigste Rat aus der Praxis: Miss Deinen Fortschritt, statt nur zu „fühlen", dass es sicherer wird. Der Secure Score und das Reifegrad-Modell geben Dir eine belastbare Standortbestimmung — und genau die brauchst Du, wenn ein NIS2- oder ISO-27001-Auditor nach Deinem Sicherheitskonzept fragt.
Die drei häufigsten Zero-Trust-Fehler in KMU
Aus Dutzenden Tenant-Reviews kenne ich die immer gleichen Stolperfallen — und Du sparst Dir viel Frust, wenn Du sie von Anfang an vermeidest:
Zero Trust ist am Ende kein Technologie-, sondern ein Priorisierungsproblem: die richtigen Bausteine in der richtigen Reihenfolge, gemessen an einem klaren Reifegrad.
Häufige Fragen zu Zero Trust mit Microsoft 365
Welche Microsoft-365-Lizenz brauche ich für Zero Trust?
Die Kernbausteine stecken bereits in Microsoft 365 E3 (Entra ID P1, Intune, Defender for Office 365, Purview-Basis). Für die fortgeschrittenen Funktionen — Identity Protection, Global Secure Access, Defender for Endpoint P2, Defender for Cloud Apps und die erweiterte Purview Information Protection — brauchst Du E5 oder die Entra Suite. Viele KMU kommen mit E3 plus einem gezielten Add-on weit, ohne gleich alle Benutzer auf E5 zu heben.
Was ist ZTNA und wie hängt es mit Zero Trust zusammen?
ZTNA (Zero Trust Network Access) ist die Netzwerk-Umsetzung von Zero Trust: Statt Benutzer per VPN ins gesamte Netzwerk zu lassen, gewährt ZTNA Zugriff pro App und prüft jede Verbindung gegen Identität und Gerätestatus. In Microsoft 365 setzt Du das mit Global Secure Access um — es ersetzt die alte Firewalls-/VPN-Logik durch identitätsbasierte Zugriffskontrolle in Echtzeit.
Ersetzt Zero Trust meine Firewall?
Nein. Firewalls und Netzwerksegmentierung bleiben sinnvoll, sind aber nicht mehr die Hauptverteidigung. In einer Umgebung aus SaaS-Anwendungen, Cloud Apps und hybriden Arbeitsplätzen verschiebt Zero Trust die Kontrolle von der Netzwerkgrenze auf jeden einzelnen Zugriff von Benutzern und Endgeräten — egal, ob sie im Büro, im Homeoffice oder unterwegs arbeiten.
Wo fange ich mit Zero Trust an?
Bei der Identität. Über 80 Prozent der Angriffe beginnen mit kompromittierten Anmeldedaten, nicht mit durchbrochenen Firewalls. Roll zuerst Conditional Access und phishing-resistente MFA aus, dann das Gerätevertrauen über Intune und Defender, dann Netzwerk und Apps über Global Secure Access und zuletzt die Daten über Microsoft Purview. Diese Roadmap in Phasen verhindert, dass Du Dich verzettelst und Funktionen doppelt baust.
Wo steht Dein Tenant? Der nächste Schritt
Zero Trust ist kein Projekt mit Enddatum, sondern ein Reifegrad, den Du Schritt für Schritt erhöhst. Die häufigste Frage, die meine Kunden mir stellen, ist deshalb nicht „Was ist Zero Trust?", sondern „Wo stehe ich gerade — und was kommt als Nächstes?"
Ich bin Aaron Siller, Microsoft MVP für Security und Gründer von siller.consulting. In meiner Beratungspraxis härte ich täglich Microsoft-365-Tenants nach genau diesem Modell — hands-on, nicht auf Folien.
In einem persönlichen Zero-Trust-Workshop gehen wir Deinen Tenant gemeinsam durch: Wir bestimmen Deinen aktuellen Reifegrad über alle Säulen, identifizieren die größten Lücken und priorisieren die nächsten Schritte. Kein Frontalvortrag, sondern Arbeit an Deiner echten Umgebung.
Oder Du startest direkt mit unserem Microsoft 365 Hardening Check: Damit bekommst Du eine fundierte Zero-Trust-Standortbestimmung Deiner aktuellen Konfiguration — und weißt genau, an welcher Säule Du als Nächstes ansetzen musst.
