MFA ist eingeführt, das war der erste große Schritt. Trotzdem habt ihr das Gefühl, dass die Sicherheit eures Microsoft-365-Tenants weiterhin auf einem dünnen Eis steht: Niemand weiß genau, wer welche Zugriffe hat, Conditional Access ist ein Mysterium, und ob die Notebooks der Außendienst-Mitarbeitenden compliant sind, kann man nur hoffen. Zero Trust ist kein Produkt, das man kauft. Wir bauen die Baseline mit euch in drei realistischen Schritten ein, ohne dass eure Mitarbeitenden in den Streik gehen.
Hast du diese Situation?
- MFA läuft, aber niemand kann auf Anhieb sagen, ob wirklich alle Konten geschützt sind. Es gibt Verdacht auf ein paar Ausnahmen aus der Einführungsphase, die niemand sauber aufgeräumt hat — Service-Accounts, Notfall-Logins, der eine Geschäftsführer, dem MFA „zu lästig” war.
- Conditional Access existiert als Begriff, aber wer sich die Policies im Tenant ansieht, findet eine wilde Mischung: zwei Policies vom Einführungs-Dienstleister, eine selbst angelegte mit dem Namen „Test”, und eine Microsoft-Standard-Policy, die niemand bewusst aktiviert hat.
- Notebooks im Außendienst werden nicht systematisch verwaltet. Ob darauf die Festplatten verschlüsselt sind, ob das Betriebssystem aktuell ist, ob Defender aktiviert ist — das ist Vertrauenssache, nicht Nachweis.
- Externe Personen (Steuerberater:in, Wirtschaftsprüfer:in, Lieferanten, Freelancer:innen) haben über die Jahre Gast-Zugriffe auf SharePoint oder Teams bekommen. Ob diese Gäste noch aktiv sein müssen, hat seit der ersten Einladung niemand mehr geprüft.
- Der Cyber-Versicherer oder ein Kunde verlangt einen Nachweis über Zugriffs-Governance — und ihr habt das Gefühl, dass die ehrliche Antwort „wir sind dran” eher schwach klingen würde.
Warum das jetzt löst statt verschoben wird
Zero Trust ist kein Modewort, sondern eine pragmatische Antwort auf eine veränderte Welt: Anwender:innen arbeiten von überall, Geräte sind unterschiedlich gut verwaltet, Identitäten sind das eigentliche Tor zur Firma. Wer Sicherheit weiterhin allein an Netzwerk-Grenzen festmacht („Firewall am Standort”), spielt ein Spiel, das vor zehn Jahren noch funktioniert hat. Heute kommen die meisten Angriffe über kompromittierte Identitäten, nicht über durchbrochene Firewalls.
Die unangenehme Nachricht: Eine vollständige Zero-Trust-Architektur in einem mittelständischen Unternehmen einzuführen ist nicht ein Projekt von drei Wochen. Die gute Nachricht: Die Baseline — die wichtigsten 70 bis 80 Prozent des Effekts — ist machbar, und sie ist machbar ohne Big-Bang-Migration.
Typische Auslöser, die jetzt dran sind:
- Cyber-Versicherer verlangt einen Nachweis über MFA-Abdeckung, Conditional Access und Geräte-Compliance.
- NIS-2 trifft euch direkt oder als Zulieferer — Identity-Governance und Zugriffskontrolle sind Pflichtthemen.
- Ein:e Kunde verlangt einen Lieferanten-Security-Fragebogen — und die Fragen sind nicht oberflächlich.
- Ein Phishing-Vorfall hat gerade gezeigt, wie weit ein einzelner kompromittierter Account kommt.
- Audit-Bemerkung zu Berechtigungen, Logging oder Gäste-Governance liegt auf dem Tisch.
So sähe das bei euch aus
Wir gehen das bewusst nicht als Big-Bang an, sondern in drei Schritten — Identity, Devices, Governance. Pro Schritt eine Pilot-Phase mit einer kleinen Gruppe, dann Ausrollen. Wer alles auf einmal scharf schaltet, sperrt am Montagmorgen die halbe Belegschaft aus, und das Vertrauen ist dann für Monate weg.
Schritt 1 — Identity-Inventur und MFA-Lückenschluss
Bevor wir Conditional Access aufbauen, machen wir eine ehrliche Bestandsaufnahme: Welche Konten existieren im Tenant, welche sind aktiv, welche sind privilegiert, wo fehlt MFA wirklich? Wir schauen uns auch die unangenehmen Bereiche an: ehemalige Mitarbeiter:innen, deren Konto „aus Versehen” noch aktiv ist; Service-Accounts mit alten Passwörtern; Geschäftsführungs-Konten, die als „besondere Ausnahme” aus der MFA-Pflicht herausgehalten wurden.
Liefer-Ergebnis: eine Identity-Übersicht, in der jedes Konto einen Status hat (aktiv/inaktiv, MFA-Status, privilegierte Rolle ja/nein, letzter Login). Plus ein priorisierter Lückenschluss-Plan. Allein dieser Schritt entdeckt in den meisten mittelständischen Tenants zwischen 5 und 20 Konten, die niemand mehr braucht — oder die längst hätten geschützt sein müssen.
Stack-Hinweise: Entra ID Sign-in Logs, Audit Logs, Microsoft Graph für Identity-Inventar, Entra ID PIM für privilegierte Rollen.
Schritt 2 — Conditional Access pragmatisch aufbauen
Hier liegt der größte Hebel und gleichzeitig das größte Risiko. Wir bauen eine Conditional-Access-Baseline, die folgende Kern-Fragen beantwortet:
- Müssen sich alle Benutzer:innen mit MFA anmelden — auch privilegierte Konten, gerade die?
- Werden Anmeldungen aus dem Ausland anders behandelt, wenn die Firma rein in DACH operiert?
- Werden veraltete Authentifizierungs-Protokolle (Legacy Auth, IMAP, POP) blockiert?
- Werden Anmeldungen von nicht-verwalteten Geräten anders behandelt als von Firmen-Geräten?
- Gibt es einen Break-Glass-Account für den Notfall, der bewusst von Conditional Access ausgenommen ist, und ist sein Passwort sicher verwahrt?
Wir setzen das schrittweise um: erst Report-Only-Modus, damit wir sehen, was eine Policy blockieren würde, ohne wirklich zu blockieren. Dann Pilot mit der IT und freiwilligen Anwender:innen. Erst dann breitflächig. Liefer-Ergebnis: ein dokumentiertes Set von 5 bis 10 Policies, die euer Tenant trägt — mit klar benannten Ausnahmen für Spezialfälle (z. B. CAD-Workstation ohne MFA-fähiges Gerät, wenn das wirklich nicht anders geht).
Stack-Hinweise: Conditional Access (inkl. Report-Only-Mode), Authentication Strengths, Continuous Access Evaluation, Break-Glass-Account-Pattern.
Schritt 3 — Device-Baseline mit Intune
Identity allein reicht nicht. Wenn ein Notebook kompromittiert ist, hilft die beste MFA nichts. Deshalb bauen wir eine Geräte-Baseline auf: Firmen-Notebooks werden in Intune aufgenommen, bekommen eine Compliance-Policy (BitLocker an, Defender aktiv, OS aktuell), und Conditional Access wird so erweitert, dass kritische Anwendungen nur von compliant-markierten Geräten zugänglich sind.
Bei BYOD (eigenes Smartphone der Mitarbeitenden, das auch fürs Postfach genutzt wird) verzichten wir bewusst auf Vollverwaltung. Stattdessen App-Protection: Firmen-Daten in der Outlook-App werden vor Copy/Paste in private Apps geschützt, ohne dass Nexaro oder die IT auf private Fotos zugreift. Das ist akzeptabel für die Mitarbeitenden und schützt trotzdem den relevanten Datenpfad.
Liefer-Ergebnis: alle Firmen-Notebooks in Intune, Compliance-Policy aktiv, BYOD-Smartphones mit App-Protection. Plus ein Onboarding-Pfad für neue Geräte (Autopilot), damit das nicht wieder zerfällt.
Stack-Hinweise: Microsoft Intune, Compliance Policies, App Protection Policies, Autopilot, Defender for Endpoint Onboarding.
Schritt 4 — Gäste-Governance und privilegierter Zugang
Externe Personen, die seit Jahren Zugriff haben, sind ein häufig übersehenes Risiko. Wir bauen mit euch einen Review-Rhythmus: Alle Gast-Konten werden einmal pro Quartal von der einladenden Person bestätigt — wer nicht bestätigt wird, wird automatisch deaktiviert. Dazu Access Reviews für interne privilegierte Rollen: wer ist Global Administrator, wer ist SharePoint-Administrator, ist das noch begründet?
Liefer-Ergebnis: ein Quartals-Rhythmus für Access Reviews, eingerichtet im Tenant, mit klaren Verantwortlichkeiten. Plus ein eingerichtetes Privileged Identity Management für die Top-Rollen — sodass z. B. Global-Admin-Rechte nicht permanent vergeben sind, sondern bei Bedarf für ein paar Stunden aktiviert werden.
Stack-Hinweise: Entra ID Access Reviews, Entra ID PIM, Entitlement Management für Gäste-Onboarding.
Schritt 5 — Mitarbeiter-Kommunikation und Verständigung
Das ist der Schritt, an dem die meisten Zero-Trust-Projekte scheitern — nicht an der Technik. Wir helfen euch dabei, intern zu kommunizieren, was sich für die Anwender:innen ändert, warum, und wann. Eine kurze E-Mail an alle reicht nicht. Wir schlagen ein kleines Paket vor: ein One-Pager für die Geschäftsführung (warum machen wir das überhaupt), ein One-Pager für die Anwender:innen (was ändert sich konkret, was muss ich tun), eine Q&A-Liste für die häufigsten Rückfragen, und einen klaren Ansprechpartner für die Pilot-Phase.
Liefer-Ergebnis: Kommunikations-Material in eurer Sprache, freigegeben durch die Geschäftsführung, ausgerollt eine Woche vor der jeweiligen Policy-Aktivierung.
Worauf du dabei achten solltest
- Frag nach dem Rollback-Plan, bevor irgendeine Conditional-Access-Policy scharfgeschaltet wird. Wer auf die Frage „Was passiert, wenn die Policy plötzlich die halbe Firma aussperrt?” keine schnelle Antwort hat, hat keinen Plan. Break-Glass-Account und Report-Only-Modus sind Pflicht.
- Zero Trust ist kein Produkt, sondern eine Architektur-Haltung. Wer euch Zero Trust als gekauftes Paket verkaufen will, hat es nicht verstanden. Es ist die Summe aus Identity-, Device- und Zugriffs-Entscheidungen, und es passiert in Schritten.
- Lass dich nicht von „risikobasierter Authentifizierung” beeindrucken, wenn die Basics nicht stehen. Conditional Access mit Risiko-Signalen ist mächtig, aber sie braucht eine saubere Identity-Basis. Wer beim ersten Schritt auf den dritten springt, baut auf Sand.
- Klärt mit der Geschäftsführung VOR dem Rollout, dass kurzfristig Unbequemlichkeiten kommen werden. Wenn die Geschäftsführung im ersten Beschwerde-Sturm einknickt und Ausnahmen für sich selbst verlangt, ist das Projekt politisch tot. Geschäftsführung als sichtbares Vorbild ist hier wichtiger als jede Policy.
- Pass auf bei Templates und „Best-Practice-Pakete”. Die Microsoft-Templates für Conditional Access sind ein guter Startpunkt, aber sie passen selten ohne Anpassung. Wer 1:1 das Microsoft-Template ausrollt, blockiert mit hoher Wahrscheinlichkeit etwas, das bei euch geschäftskritisch ist.
Was sich danach realistisch ändert
- Auf die Frage „Hat jede:r Mitarbeiter:in MFA?” könnt ihr in einer Minute mit einer dokumentierten Liste antworten — inklusive der bewussten Ausnahmen mit Begründung.
- Conditional Access ist nicht mehr ein Mysterium, sondern ein dokumentiertes Set von Policies, das eine externe Auditor:in nachvollziehen kann.
- Firmen-Notebooks sind kein Vertrauens-Thema mehr, sondern ein Compliance-Status. Ein nicht-compliantes Notebook bekommt keinen Zugriff auf SharePoint mit den Konstruktionsdaten.
- Gast-Konten werden quartalsweise überprüft, statt über Jahre stillschweigend zu bestehen.
- Wenn der Cyber-Versicherer oder ein:e Kund:in nach Zugriffs-Governance fragt, habt ihr Dokumente, keine Floskeln.
Was ihr beisteuert
- Administrative Zugriffe auf Entra ID, Conditional Access und Intune (mit zeitlicher Eingrenzung, gerne über PIM).
- Eine Person bei euch, die das Projekt mitträgt, Kommunikation an die Belegschaft begleitet und in der Pilot-Phase ansprechbar ist.
- Bereitschaft der Geschäftsführung, das Thema sichtbar mitzutragen — inklusive eigener MFA, eigener Compliance-Anforderungen am Geschäftsführungs-Notebook, eigener Gast-Reviews.
- Etwa 15 bis 30 Stunden Stakeholder-Zeit verteilt über mehrere Monate, plus die rein technischen Umsetzungs-Termine.
Risiken und wann es nicht passt
- Wenn der Tenant gerade frisch migriert wurde und noch instabil ist — dann erst Stabilität, dann Zero Trust. Eine Conditional-Access-Policy auf einer halb-fertigen Migration ist ein doppeltes Problem.
- Wenn die Geschäftsführung das Thema nicht trägt und Ausnahmen für sich selbst einfordert, scheitert das Projekt politisch. Wir sagen dann lieber im Erstgespräch: erst die Haltung klären, dann die Technik.
- Wenn ihr aktuell auch noch einen Tenant-Aufräum-Bedarf habt, gehen wir das vorher oder parallel an — Zero Trust auf einem aufgeräumten Tenant ist deutlich entspannter als auf einer Müllhalde.
- Wenn euer Lizenz-Stand keine Business-Premium- oder E3-Funktionen umfasst, fehlen Conditional Access und Intune. Das klären wir im Erstgespräch — manchmal ist eine Lizenz-Anpassung der erste Schritt.
So fängt das Gespräch an
- 30 Minuten Erstgespräch, kostenfrei, per Video oder Telefon.
- Was wir klären: aktueller MFA-Stand, vorhandene Conditional-Access-Policies (oder Fehlen davon), Lizenz-Stand, Geräte-Landschaft (überwiegend Firmen-Notebooks oder Mischung), aktueller Druck (Versicherer, NIS-2, Vorfall).
- Optional vorab nützlich: ein Screenshot der Lizenz-Übersicht aus dem Microsoft-365-Admin-Center, grobe Mitarbeitendenzahl, Information ob Intune bereits eingesetzt wird.
Häufige Fragen
Müssen wir Microsoft E5 haben, um Zero Trust einzuführen? Nein. Business Premium oder E3 reichen für eine solide Baseline — MFA, Conditional Access, Intune und Defender for Endpoint sind dort enthalten. E5 bringt zusätzliche Funktionen wie risikobasierte Authentifizierung und Defender for Identity, die in größeren Umgebungen Sinn ergeben. Im Mittelstand ist Business Premium für die meisten Szenarien ausreichend.
Wie lange dauert die Einführung der Baseline? Realistisch 3 bis 6 Monate von Identity-Inventur bis zu einer stabilen Conditional-Access-Konfiguration mit Device-Compliance, je nach Größe und Ausgangszustand. Das ist kein Drei-Wochen-Projekt — und sollte es auch nicht sein, wenn die Belegschaft am Ende noch arbeiten können soll.
Werden unsere Mitarbeitenden das akzeptieren? Wenn die Kommunikation gut läuft und die Geschäftsführung sichtbar mitzieht: ja. Conditional Access ist im Alltag für die meisten Anwender:innen kaum spürbar — sie melden sich morgens einmal mit MFA an, danach läuft es. Spürbar wird es nur in den Spezialfällen (Zugriff von einem unbekannten Gerät, Reise außerhalb DACH), und genau dort soll es spürbar sein.
Was, wenn wir Notfall-Zugriff brauchen und MFA nicht geht? Dafür ist der Break-Glass-Account da — ein bewusst ausgenommenes Notfall-Konto mit einem sehr langen Passwort, das in einem Safe liegt. Den nutzt niemand im Alltag, aber er existiert für den Tag, an dem MFA-Provider, Internet oder Conditional Access selbst Probleme machen. Den Break-Glass-Account einzurichten ist Pflicht, kein Nice-to-have.