Illustration Absmeier foto ki designer

Zero Trust in Microsoft 365 ist kein Lizenz- oder Toolprojekt, sondern ein steuerbares Sicherheitsprogramm. Entscheidend sind klare Schutzobjekte, belastbare Entscheidungswege, befristete Ausnahmen und messbare Nachweise – damit aus technischen Kontrollen echte Risikoreduktion für das Unternehmen wird.

Management Summary

Zero Trust braucht Führung: Der Nutzen entsteht erst, wenn Geschäftsrisiko, technische Kontrolle und überprüfbarer Zielzustand zusammengeführt werden.
Schutzobjekte vor Produkten: Privilegierte Konten, sensible Datenbereiche und kritische Anwendungen definieren die Reihenfolge – nicht die Navigation im Admin-Portal.
Identität ist das Fundament: Starke Anmeldung, Conditional Access und geregelte Rollenmodelle reduzieren Risiken, ersetzen aber keine Gesamtstrategie.
Governance entscheidet: Ausnahmen sind zulässig, müssen aber Eigentümer, Begründung, Geltungsbereich und Ablaufdatum haben.
Wirkung statt Rollout messen: Fortschritt zeigt sich an Abdeckung, geprüfter Durchsetzung, offenen Ausnahmen und belastbaren Wiederherstellungswegen.

Zero Trust wird in vielen Unternehmen auf Leitungsebene beschlossen und kommt im Betrieb als lose Sammlung technischer Einzelmaßnahmen an: Multi-Faktor-Authentifizierung ist aktiviert, Geräte werden verwaltet, irgendwo existiert eine Richtlinie für externe Zugriffe. Was fehlt, ist selten eine weitere Sicherheitsfunktion. Es fehlt die Verbindung zwischen Geschäftsrisiko, technischer Kontrolle und einem überprüfbaren Ergebnis.

Eine Zero-Trust-Strategie schafft genau diese Verbindung. Sie beschreibt nicht nur eine Zielarchitektur, sondern auch Entscheidungen, Verantwortlichkeiten und Nachweise. Gerade in Microsoft 365 ist das wichtig, weil Identitäten, Geräte, Anwendungen und Daten eng miteinander verzahnt sind. Wird nur eine Ebene betrachtet, bleiben Umgehungswege offen.

Aaron Siller, Microsoft MVP für Security und Gründer von siller.consulting, beobachtet in Hardening-Projekten ein wiederkehrendes Muster: »Zero Trust scheitert fast nie an einer fehlenden Lizenz. Es scheitert an der Frage, wer eine Ausnahme verantwortet und wann sie endet.«

Drei Zero-Trust-Prinzipien werden zu Steuerungsfragen

Microsoft beschreibt Zero Trust über drei Grundsätze: explizit verifizieren, Zugriff mit den geringstmöglichen Rechten vergeben und von einer Kompromittierung ausgehen. Damit daraus mehr als ein Leitbild wird, muss jedes Prinzip in eine konkrete Steuerungsfrage übersetzt werden.

Aus »explizit verifizieren« wird: Unter welchen nachweisbaren Bedingungen darf auf eine kritische Anwendung zugegriffen werden? Dazu können eine starke Anmeldung, ein verwaltetes Gerät, ein akzeptables Anmelderisiko und ein nachvollziehbarer Standort gehören. Entscheidend ist, dass die Bedingungen aus dem Schutzbedarf folgen und nicht nur deshalb gewählt werden, weil eine Lizenz sie ermöglicht.

»Geringstmögliche Rechte« führt zur Frage, ob privilegierte Rollen dauerhaft notwendig sind und wer regelmäßig bestätigt, dass Berechtigungen noch begründet sind. »Von einer Kompromittierung ausgehen« heißt schließlich: Ist protokolliert, ausgewertet und geübt, was passiert, wenn ein Konto, ein Gerät oder eine Anwendung trotz aller Kontrollen übernommen wird?

Schutzobjekte kommen vor Produkten

Der erste Schritt einer Zero-Trust-Architektur ist nicht die Auswahl eines Werkzeugs. Zuerst muss klar sein, was geschützt werden soll: privilegierte Konten, sensible SharePoint-Bereiche, geschäftskritische Fachanwendungen, besonders exponierte Personengruppen oder vertrauliche Kommunikationswege.

Für jedes Schutzobjekt sollte festgehalten werden, wer unter welchen Bedingungen zugreifen darf, welche Abhängigkeiten bestehen und welches Restrisiko bewusst getragen wird. Diese Beschreibung bildet den Maßstab für spätere technische Entscheidungen. Ohne sie wird Zero Trust schnell zu einer Produktsammlung, deren Nutzen sich weder priorisieren noch abnehmen lässt.

In Microsoft 365 lässt sich das anschließend einer technischen Architektur zuordnen: Identität und Conditional Access bilden das Fundament, der Gerätekontext ergänzt die Zugriffsentscheidung, danach folgen Anwendungen und Gastzugriffe, zuletzt die Datenebene mit Klassifizierung, externen Freigaben und Schutz vor Datenabfluss. Wer bei der Datenklassifizierung beginnt, ohne Identitäten und Zugriffswege im Griff zu haben, sichert eine Tür in einer Wand, die noch nicht steht.

Das Zero-Trust-Modell ist damit kein fertiger Bauplan, der unverändert übernommen werden kann. Ein Zero-Trust-Framework gibt Prinzipien und Prüffragen vor; die konkrete Architektur entsteht erst aus den Schutzobjekten, Risiken und Betriebsbedingungen des Unternehmens. Diese Übersetzung verhindert, dass abstrakte Sicherheitsziele im Projektverlauf zu einer unverbundenen Liste technischer Aufgaben werden.

Identitäten sind das Fundament, aber nicht die ganze Strategie

Eine starke Authentifizierung reduziert das Risiko gestohlener Kennwörter, löst aber nicht jedes Identitätsproblem. Eine Zero-Trust-Strategie muss ebenso privilegierte Rollen, Notfallkonten, externe Identitäten und Anwendungskonten berücksichtigen. Gerade App-Berechtigungen werden leicht übersehen, weil sie unabhängig von einer interaktiven Benutzeranmeldung auf Daten zugreifen können.

Conditional Access verbindet viele dieser Signale. Richtlinien können Anmelderisiko, Gerät, Standort, Anwendung und Benutzerrolle berücksichtigen. Ihre Wirksamkeit hängt jedoch an der Reichweite: Wer ist ausgenommen, wie lange gilt die Ausnahme und welcher Prozess verhindert, dass eine Übergangslösung dauerhaft bestehen bleibt? Eine formal aktive Richtlinie ist noch kein Nachweis dafür, dass das gewünschte Schutzobjekt tatsächlich abgesichert ist.

Geräte, Anwendungen und Daten bilden die nächste Ausbaustufe

Nach dem Identitätsfundament folgt der Gerätekontext. Zugriff kann davon abhängig gemacht werden, ob ein Endgerät verwaltet wird, definierte Compliance-Anforderungen erfüllt und keine erkennbaren Hochrisikosignale trägt. Dabei muss das Unternehmen entscheiden, welche Anwendungen einen solchen Nachweis zwingend voraussetzen und wo ein eingeschränkter Browserzugriff ausreicht.

Anwendungen benötigen eine eigene Betrachtung. Registrierungen und Einwilligungen können über lange Zeit weitreichende Rechte behalten. Eine Zero-Trust-Roadmap sollte deshalb vorsehen, ungenutzte Anwendungen zu entfernen, privilegierte Berechtigungen zu begründen und neue Einwilligungen kontrolliert zu vergeben.

Erst danach folgt die Datenebene. Klassifizierung, Aufbewahrung und Schutz vor Datenabfluss entfalten ihren Wert nur, wenn bekannt ist, welche Identität über welches Gerät und welche Anwendung auf die Daten zugreift. Zero Trust verbindet diese Signale zu einer Entscheidung; es ersetzt sie nicht durch ein einzelnes Produkt.

Entscheidungswege statt Einzelfreigaben

Der häufigste Rückfall in Einzelmaßnahmen ist organisatorisch. Eine Sicherheitsfunktion darf nicht deshalb tenantweit aktiviert werden, weil sie verfügbar ist. Vor der Entscheidung gehören Auswirkungen auf Anwender, Notfallzugänge, Dienstkonten und Geschäftsprozesse auf den Tisch. Danach folgen technischer Funktionstest, Pilotierung und formale Abnahme.

Genauso wichtig ist ein benannter Weg für Ausnahmen. »Ausnahmen sind in einem Zero-Trust-Programm normal«, sagt Siller. »Dauerhafte Ausnahmen ohne Eigentümer und ohne Ablaufdatum sind es nicht.« Jede Ausnahme braucht daher einen Verantwortlichen, eine Begründung, einen Geltungsbereich und einen Termin zur erneuten Prüfung. Ohne diese Mechanik entstehen Richtlinien, deren tatsächliche Reichweite niemand mehr kennt.

Eine gute Governance trennt außerdem die Rollen. Wer eine Ausnahme beantragt, sollte sie nicht allein genehmigen. Wer eine Richtlinie technisch umsetzt, sollte nicht selbst bestätigen, dass der Geschäftsprozess weiterhin funktioniert. Diese Trennung muss nicht bürokratisch sein; sie macht Entscheidungen nachvollziehbar und verhindert, dass technische Übergangslösungen unbemerkt zum Dauerzustand werden.

In Etappen umsetzen, ohne den Betrieb zu gefährden

Zero Trust ist kein Big-Bang-Projekt. Eine belastbare Einführung beginnt mit einem begrenzten Schutzobjekt und einem messbaren Zielzustand. Zugriffsrichtlinien lassen sich zunächst im Berichtmodus auswerten, danach an Pilotgruppen testen und erst nach der Auswertung breiter aktivieren. Für jede Stufe braucht es einen erhaltenen Rückfallweg.

Eine sinnvolle erste Etappe kann privilegierte Identitäten umfassen: starke Anmeldeverfahren, zeitlich begrenzte Rollen, überwachte Notfallkonten und dokumentierte Ausnahmen. Die nächste Etappe verbindet den Zugriff mit verwalteten Geräten. Danach folgen Anwendungen, externe Zusammenarbeit und sensible Datenbereiche. Die genaue Reihenfolge hängt vom Risiko ab, nicht von der Produktnavigation im Admin-Portal.

Fortschritt über Wirkung messen, nicht über Rollout

Eine Roadmap braucht pro Phase einen prüfbaren Zielzustand. »MFA ausgerollt« ist dafür zu ungenau. Aussagekräftiger ist: Privilegierte Konten nutzen ausschließlich freigegebene starke Methoden, Ausnahmen sind dokumentiert und befristet, und ein Test belegt die Durchsetzung. Dasselbe Muster gilt für Geräte, Anwendungen und Datenzugriffe.

Kennzahlen wie der Secure Score können Trends sichtbar machen, ersetzen aber keine Risikobewertung. Ein steigender Wert zeigt, dass mehr empfohlene Kontrollen umgesetzt wurden. Er belegt nicht automatisch, dass die wichtigsten Geschäftsrisiken reduziert sind. Ergänzend braucht es deshalb Nachweise zur tatsächlichen Abdeckung, zu offenen Ausnahmen, privilegierten Zuweisungen, erkannten Vorfällen und erfolgreich geprüften Wiederherstellungswegen.

Wie sich diese Bausteine im Tenant konkret verzahnen, zeigt der Praxisbeitrag Zero Trust in Microsoft 365 umsetzen. Die tragfähige Linie für Entscheider bleibt dieselbe: mit einem klaren Schutzobjekt beginnen, Verantwortung und Abnahmekriterien vorab benennen, Änderungen kontrolliert ausrollen und jede Stufe belegen, bevor die nächste beginnt.

Aaron Siller

Aaron Siller ist Microsoft MVP für Security, Fachbuchautor (»Microsoft 365 absichern«, Rheinwerk Verlag) und Gründer von siller.consulting.

FAQ: Zero Trust in Microsoft 365

Was ist der Kern einer Zero-Trust-Strategie?
Zero Trust geht davon aus, dass kein Zugriff automatisch vertrauenswürdig ist. Jeder Zugriff muss kontextbezogen geprüft, begrenzt und nachvollziehbar abgesichert werden.
Praxisbeispiel: Ein Vertriebsmitarbeiter greift unterwegs auf Kundenangebote in SharePoint zu. Der Zugriff wird nur erlaubt, wenn MFA erfolgreich ist, das Gerät compliant ist und keine ungewöhnlichen Anmelderisiken vorliegen.
Warum reicht Multi-Faktor-Authentifizierung allein nicht aus?
MFA senkt das Risiko gestohlener Kennwörter, berücksichtigt aber nicht automatisch Gerätequalität, Rollen, App-Berechtigungen, Gastzugriffe oder Datenklassifizierung.
Praxisbeispiel: Ein Konto besteht die MFA-Prüfung, meldet sich aber von einem privaten, ungepatchten Gerät aus an und lädt sensible Dateien herunter. Ohne Gerätekontext und Datenkontrolle bleibt dieses Risiko bestehen.
Wo sollte ein Unternehmen mit Zero Trust beginnen?
Der Startpunkt sollte ein klar definiertes Schutzobjekt mit hohem Risiko sein, etwa privilegierte Identitäten, vertrauliche SharePoint-Bereiche oder kritische Fachanwendungen.
Praxisbeispiel: Ein Unternehmen startet mit Administratorkonten: Rollen werden zeitlich begrenzt vergeben, Notfallkonten überwacht und jede Ausnahme mit Ablaufdatum dokumentiert.
Welche Rolle spielt Conditional Access?
Conditional Access verbindet Signale wie Benutzerrolle, Gerät, Standort, Anwendung und Risiko zu einer Zugriffsentscheidung. Entscheidend ist, wie vollständig die Richtlinien greifen und wie Ausnahmen gesteuert werden.
Praxisbeispiel: Der Zugriff auf Exchange Online wird für Führungskräfte nur von verwalteten Geräten erlaubt; bei Anmeldung aus einem unbekannten Land wird zusätzlich ein erhöhtes Risiko erkannt und der Zugriff blockiert.
Warum sind Ausnahmen ein Risiko?
Ausnahmen werden gefährlich, wenn sie keinen Eigentümer, keine Begründung, keinen Geltungsbereich und kein Ablaufdatum haben. Dann unterlaufen sie die tatsächliche Reichweite der Sicherheitsrichtlinien.
Praxisbeispiel: Eine Legacy-Anwendung kann zunächst keine moderne Anmeldung nutzen. Statt die Ausnahme dauerhaft offen zu lassen, wird sie auf eine Benutzergruppe begrenzt, einem Service Owner zugewiesen und nach 60 Tagen erneut geprüft.
Wie lässt sich Zero Trust ohne Betriebsrisiko einführen?
Sinnvoll ist ein stufenweises Vorgehen: Berichtmodus, Pilotgruppen, Auswertung, Abnahme und erst danach breitere Aktivierung mit definiertem Rückfallweg.
Praxisbeispiel: Eine neue Richtlinie für SharePoint-Zugriffe läuft zunächst im Berichtmodus. Nach Auswertung falscher Blockierungen wird sie mit 50 Pilotanwendern getestet und erst danach für weitere Bereiche aktiviert.
Welche Kennzahlen sind für Entscheider relevant?
Neben technischen Scores zählen vor allem Abdeckung, offene Ausnahmen, privilegierte Zuweisungen, erkannte Vorfälle und geprüfte Wiederherstellungswege.
Praxisbeispiel: Das Management-Dashboard zeigt nicht nur den Secure Score, sondern auch die Zahl unbefristeter Ausnahmen, privilegierter Konten ohne Just-in-Time-Zuweisung und erfolgreich getesteter Wiederherstellungsprozesse.
Warum kommen Schutzobjekte vor Produkten?
Nur wenn klar ist, was geschützt werden soll, lassen sich passende Kontrollen, Prioritäten und Abnahmekriterien bestimmen. Sonst entsteht eine Produktsammlung ohne belastbaren Steuerungsnutzen.
Praxisbeispiel: Für den Vorstandsdatenraum wird zuerst festgelegt, wer zugreifen darf, welche Geräte zulässig sind und welche Protokollierung erforderlich ist. Erst danach werden passende Richtlinien und Tools konfiguriert.
Welche Bedeutung haben Anwendungskonten und App-Berechtigungen?
Sie können dauerhaft weitreichende Zugriffe behalten, auch ohne interaktive Benutzeranmeldung. Deshalb müssen sie regelmäßig geprüft, begründet und bei Nichtnutzung entfernt werden.
Praxisbeispiel: Eine veraltete Reporting-App besitzt weiterhin Leserechte auf mehrere Teams-Bereiche, obwohl sie nicht mehr genutzt wird. Im Review werden die Berechtigungen entfernt und die App-Registrierung gelöscht.
Wann ist eine Zero-Trust-Etappe abgeschlossen?
Eine Etappe ist abgeschlossen, wenn der Zielzustand nachweisbar erreicht ist: Richtlinien greifen, Ausnahmen sind dokumentiert, Verantwortlichkeiten sind benannt und die Wirksamkeit wurde getestet.
Praxisbeispiel: Nach der Einführung für privilegierte Konten prüft das Team stichprobenartig Anmeldewege, testet ein Notfallkonto, kontrolliert offene Ausnahmen und dokumentiert die Abnahme durch Security und Fachverantwortliche.

Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

1444 Artikel zu „zero trust“

News | Healthcare IT | Infrastruktur | IT-Security | Kommunikation

TI 2.0 und Cybersicherheit: Was VSDM 2.0, PoPP und Zero Trust für Primärsysteme bedeuten

18. Juli 2026

Die Telematikinfrastruktur (TI) vernetzt Praxen, Apotheken, Kliniken und Krankenkassen im deutschen Gesundheitswesen. Die nächste Ausbaustufe TI 2.0 bringt neue Verfahren wie VSDM 2.0, die elektronische Prüfung und Aktualisierung der Versichertenstammdaten, PoPP, den Nachweis, dass ein Patient vor Ort ist, und ZETA – Zero Trust Access, ein Sicherheitsmodell, das jeden Zugriff einzeln prüft. Für Hersteller von…