Zero Trust nach Microsoft: Die Architektur hinter dem Buzzword

Wer Zero Trust einführt, kauft nicht eine Lösung, sondern verändert, wie Identität, Netzwerk, Endpunkte, Anwendungen und Daten zusammenspielen. Dieser Artikel geht die Architektur durch, wie Microsoft sie definiert – inklusive der neuen KI-Säule, die 2026 hinzugekommen ist.

Die drei Leitprinzipien

Jede Zero-Trust-Entscheidung bei Microsoft leitet sich aus drei Prinzipien ab, die konsequent auf jeden einzelnen Zugriff angewendet werden, nicht nur auf den Netzwerkübergang.

Explizit verifizieren. Jede Anfrage wird anhand aller verfügbaren Signale authentifiziert und autorisiert – Identität, Standort, Gerätezustand, angeforderter Dienst, Datenklassifizierung und Verhaltensauffälligkeiten. Ein Benutzer, der sich erfolgreich anmeldet, hat damit noch keinen pauschalen Zugriff erhalten; jede weitere Anfrage wird erneut anhand des aktuellen Kontexts bewertet.

Minimale Rechte verwenden. Zugriff wird auf das tatsächlich Notwendige begrenzt, zeitlich befristet und risikobasiert – etwa über Just-in-Time-Berechtigungen (Privileged Identity Management) statt dauerhaft vergebener Administratorrechte. Das gilt nicht nur für menschliche Benutzer, sondern zunehmend auch für Dienstkonten, Workloads und – seit 2026 explizit benannt – autonome KI-Agenten.

Von einer Kompromittierung ausgehen. Die Architektur wird so gebaut, als wäre bereits ein Angreifer im Netzwerk. Das bedeutet Netzwerksegmentierung, durchgängige Verschlüsselung, kontinuierliches Monitoring und Analysefähigkeiten, die eine Anomalie erkennen, bevor sie sich lateral ausbreitet – statt sich auf einen einzelnen, harten Perimeter zu verlassen.

Diese drei Prinzipien sind keine Checkliste, die einmal abgehakt wird, sondern eine dauerhafte Haltung, die sich in jeder Konfigurationsentscheidung widerspiegelt: in der Conditional-Access-Policy genauso wie in der Frage, welche Berechtigung eine neue Azure-Function beim Deployment bekommt.

Die Säulen des Microsoft-Zero-Trust-Modells

Microsoft strukturiert die Umsetzung dieser Prinzipien über mehrere Säulen, die im Zusammenspiel die gesamte digitale Umgebung abdecken.

Identitäten bilden das Fundament. Menschliche Identitäten, aber auch nicht-menschliche Identitäten wie Dienstkonten, Workloads und KI-Agenten müssen stark authentifiziert, kontinuierlich bewertet und nach dem Prinzip minimaler Rechte autorisiert werden – unabhängig davon, wo die Anfrage herkommt.

Endpunkte und Geräte müssen einen nachweisbaren Compliance-Status haben, bevor Zugriff gewährt wird. Ein Gerät ohne aktuelle Patches, ohne Verschlüsselung oder mit deaktiviertem Endpoint-Schutz stellt ein Risiko dar, unabhängig davon, wie vertrauenswürdig die angemeldete Identität ist.

Netzwerk wird nicht mehr als vertrauenswürdiger Innenraum hinter einer Firewall behandelt, sondern durchgängig segmentiert, mit Mikrosegmentierung zwischen einzelnen Workloads und Echtzeit-Bedrohungserkennung statt eines einzelnen harten Perimeters.

Anwendungen benötigen In-App-Berechtigungen, kontrollierten Zugriff und Sichtbarkeit über Schatten-IT hinweg – auch selbst entwickelte und Cloud-native Anwendungen müssen sich in dasselbe Kontrollmodell einfügen wie Standardsoftware.

Daten werden klassifiziert, verschlüsselt und mit granularen Zugriffsbeschränkungen versehen, die an der Information selbst hängen, nicht am Speicherort. Eine als vertraulich eingestufte Datei bleibt geschützt, egal ob sie in SharePoint, einem lokalen Fileserver oder als E-Mail-Anhang unterwegs ist.

Infrastruktur – VMs, Container, serverlose Funktionen – wird auf Bedrohungen und Anomalien überwacht, mit automatisierter Erkennung riskanter Konfigurationen und Just-in-Time-Zugriff statt dauerhaft offener administrativer Zugänge.

Die neue siebte Säule: KI-Systeme und Agenten

Mit der zunehmenden Verbreitung autonomer und teilautonomer KI-Agenten hat Microsoft 2026 eine eigene Zero-Trust-Säule für KI eingeführt. Der Gedanke dahinter: Ein Agent, der überprivilegiert, manipuliert oder fehlgeleitet ist, kann faktisch wie ein Innentäter wirken – ein System, das eigentlich im Sinne des Unternehmens handeln soll, aber gegen dessen Interessen agiert. Die drei Leitprinzipien gelten hier unverändert, nur auf eine neue Angriffsfläche angewendet: Identität und Verhalten von Agenten, Modellen und Workloads kontinuierlich bewerten, Zugriff auf Modelle, Prompts, Plugins und Datenquellen strikt auf das Notwendige begrenzen, und Systeme so gestalten, dass sie Prompt-Injection, Datenvergiftung und laterale Bewegung widerstehen.

Von der Architektur zur Umsetzung

Die theoretischen Prinzipien und Säulen brauchen ein Werkzeug, um sie auf eine konkrete Umgebung anzuwenden. Microsoft stellt dafür die Microsoft Cybersecurity Reference Architecture (MCRA) bereit, zuletzt im Juni 2026 aktualisiert. Sie zeigt, wie die einzelnen Microsoft-Sicherheitsfähigkeiten technisch zusammenspielen, benennt typische Antipatterns – also verbreitete Fehlkonfigurationen und Denkfehler – und ordnet konkrete Microsoft-Fähigkeiten den jeweiligen Zero-Trust-Standards und organisatorischen Rollen zu. Für die Praxis dient sie als Ausgangspunkt für einen Zielarchitektur-Entwurf, nicht als fertiges Rezept, das unverändert übernommen wird.

Ergänzend braucht jede Organisation eine Standortbestimmung: Wo steht die eigene Umgebung heute, und in welcher Reihenfolge sollten Lücken geschlossen werden? Hier kommen zwei etablierte Referenzrahmen ins Spiel. NIST SP 800-207 liefert die grundlegenden technischen Prinzipien und Architekturrichtlinien für Zero Trust in Unternehmensumgebungen. Das Zero Trust Maturity Model (ZTMM) der US-Behörde CISA baut darauf ein strategisches Reifegradmodell, das Organisationen hilft, ihren aktuellen Sicherheitsstand über Identität, Geräte, Netzwerke, Anwendungen und Daten hinweg einzuschätzen und schrittweise auszubauen. Beide Rahmenwerke sind herstellerunabhängig, lassen sich aber direkt auf die Microsoft-Säulenstruktur abbilden – ein Grund, warum Microsofts eigenes Modell in Compliance-Diskussionen regelmäßig als kompatibel mit anerkannten Standards eingeordnet wird.

Praxisszenarien

Conditional Access als gelebtes „Verify Explicitly“: Ein Unternehmen konfiguriert eine Richtlinie, die für Zugriffe auf Finanzanwendungen zusätzlich zum Passwort eine phishing-resistente Multi-Faktor-Authentifizierung verlangt, sobald das Gerät nicht als firmenverwaltet erkannt wird oder der Zugriff aus einem ungewöhnlichen Land erfolgt. Der Zugriff wird nicht pauschal erlaubt oder verweigert, sondern anhand des tatsächlichen Risikokontexts bewertet – exakt das erste Leitprinzip in konkreter Konfiguration.

Absicherung eines KI-Agenten-Workflows nach der neuen AI-Säule: Ein Unternehmen setzt einen Agenten ein, der automatisiert Kundenanfragen kategorisiert und an Fachabteilungen weiterleitet. Statt dem Agenten dauerhaften Vollzugriff auf das CRM-System zu geben, erhält er ein eng begrenztes, auditierbares Berechtigungsprofil, das nur die für die Kategorisierung notwendigen Datenfelder umfasst – und sein Verhalten wird kontinuierlich auf Abweichungen vom erwarteten Muster überwacht, statt einmalig beim Deployment geprüft zu werden.

Stolperfallen in der Praxis

Zero Trust wird zum reinen Identity-Projekt verkürzt. Viele Unternehmen setzen Conditional Access und MFA um und betrachten das Thema als erledigt. Netzwerksegmentierung, Datenklassifizierung und Infrastruktur-Absicherung bleiben liegen – dabei ist Zero Trust ausdrücklich als Zusammenspiel aller Säulen konzipiert, nicht als Identitätsprojekt mit Nebeneffekten.

Assume Breach ohne Segmentierung bleibt wirkungslos. Wer von einer Kompromittierung ausgeht, aber das interne Netzwerk weiterhin als eine große, flache Zone betreibt, hat das Prinzip nur auf dem Papier umgesetzt. Ohne Mikrosegmentierung kann sich ein Angreifer nach einem erfolgreichen Erstzugriff weiterhin ungehindert lateral bewegen.

Das Reifegradmodell wird zur einmaligen Checkbox-Übung. Das CISA-Modell ist als kontinuierlicher Prozess gedacht, wird in der Praxis aber oft als einmaliges Assessment durchgeführt, dessen Ergebnis anschließend in einer Schublade landet. Ohne wiederkehrende Bewertung verliert die Organisation den Überblick, wo sich die Bedrohungslage und die eigene Umgebung seither weiterentwickelt haben.

Legacy-Anwendungen werden bei der Planung übersehen. Ältere Anwendungen ohne moderne Authentifizierungsprotokolle lassen sich nicht ohne Weiteres in eine Conditional-Access-Architektur einbinden. Wird das erst spät im Projekt entdeckt, entstehen teure Sonderlösungen oder faktische Ausnahmen vom eigentlichen Sicherheitsmodell.

Abgrenzung und Limitierungen

Zero Trust ersetzt kein Incident-Response-Konzept. Die Architektur reduziert die Angriffsfläche und die Möglichkeit lateraler Bewegung erheblich, ersetzt aber nicht den Prozess, der greift, wenn trotzdem ein Sicherheitsvorfall eintritt – Erkennung, Eindämmung, Wiederherstellung und Nachbereitung bleiben ein eigenständiges Thema.

Zero Trust ist außerdem keine automatische Compliance-Zertifizierung. Die Ausrichtung an NIST SP 800-207 oder dem CISA-Reifegradmodell unterstützt regulatorische Nachweise, ersetzt aber nicht die spezifischen Anforderungen einzelner Compliance-Rahmenwerke wie ISO 27001 oder branchenspezifischer Vorgaben.

Der Umsetzungsaufwand ist bei gewachsenen Umgebungen mit viel Legacy-Software erheblich. Anwendungen, die nur Basisauthentifizierung unterstützen, oder Netzwerksegmente, die historisch gewachsen und schlecht dokumentiert sind, verlangsamen die Einführung spürbar und erfordern oft eine mehrjährige Roadmap statt eines einmaligen Projekts.

Lizenz- und Voraussetzungsfragen

Die vollständige Umsetzung des Microsoft-Zero-Trust-Modells setzt in der Regel höherwertige Lizenzkomponenten voraus. Funktionen wie erweiterte Conditional-Access-Szenarien, Privileged Identity Management und umfassende Datenklassifizierung sind typischerweise Bestandteil der E5-Lizenzstufe von Microsoft 365 beziehungsweise entsprechender Entra-ID- und Purview-Add-ons. Für die Endpunkt- und Infrastruktursäule kommen je nach Umfang die verschiedenen Microsoft-Defender-Pläne hinzu. Eine realistische Zero-Trust-Roadmap beginnt deshalb meist mit einer Lizenzanalyse: Welche Fähigkeiten sind mit dem vorhandenen Lizenzbestand bereits abgedeckt, und wo entstehen durch fehlende Komponenten Lücken, die vor der technischen Umsetzung geschlossen werden müssen.

Ausblick

Die Erweiterung um die KI-Säule zeigt, wohin sich das Modell entwickelt: Zero Trust war nie auf einen festen Satz von Technologien beschränkt, sondern auf die Prinzipien, die neue Angriffsflächen konsequent mit einbeziehen. Mit der zunehmenden Verbreitung autonomer Agenten in Geschäftsprozessen wird die Frage, wie deren Identität, Berechtigungen und Verhalten kontrolliert werden, zu einem der zentralen Sicherheitsthemen der kommenden Jahre – und Zero Trust liefert dafür bereits heute den strukturellen Rahmen, nicht erst als zukünftige Erweiterung.