Conditional Access in Microsoft 365

Management Summary

Bedingter Zugriff („Conditional Access“) ist das Sicherheits-Türsteher-Prinzip für die Cloud: Nur wer definierte Bedingungen erfüllt – richtige Person, passendes Gerät, zulässiger Ort und geringes Risiko – erhält Zugang zu Unternehmensdaten. Insbesondere in Microsoft 365 mit Microsoft Entra ID (ehemals Azure AD) bildet Conditional Access ein zentrales Element der Zero-Trust-Strategie („nie vertrauen, immer überprüfen“). Es ermöglicht technisch versierten Entscheidern und Administratoren, präzise zu steuern, wer wann wie und von wo auf welche Dienste zugreifen darf. So bleiben vertrauliche Daten geschützt, ohne die Produktivität legitimer Benutzer zu beeinträchtigen.

Für die Praxis bedeutet das: Selbst wenn Anmeldedaten in falsche Hände geraten, kann ein Hacker ohne weiteres nicht ins System – MFA, Geräteprüfungen oder Standortregeln stellen sich dazwischen. Microsoft berichtet, dass erfolgreiche Kontoübernahmen um über 99 % zurückgehen, sobald Multi-Faktor-Authentifizierung verpflichtend aktiviert ist. Conditional Access erlaubt es, solche Schutzmechanismen zielgerichtet und flexibel durchzusetzen: z.B. den Zugriff aus unbekannten Ländern komplett zu blockieren, auf nicht verwalteten Geräten nur einen schreibgeschützten Web-Zugriff zu erlauben oder bei riskantem Benutzerverhalten eine Passwortänderung zu erzwingen. Kurz: Mit bedingtem Zugriff erreicht man ein Höchstmaß an Sicherheit nach Stand der Technik, ohne jedem Benutzer pauschal Steine in den Weg zu legen.

Dieser Fachartikel gibt einen umfassenden Überblick über Conditional Access in Microsoft 365 (Entra ID) – von den Grundlagen und der Architektur über bewährte Richtlinien bis hin zur sicheren Einführung, dem Betrieb und Spezialfällen. Technische Entscheider und Admins erhalten praxisnahe Empfehlungen in lockerem, pointiertem Stil – ohne Buzzword-Bingo und ohne Umschweife. Nach der Lektüre wissen Sie, wie Sie Conditional Access strategisch planen, sauber ausrollen und dauerhaft betreiben – und wie Sie gängige Stolperfallen umgehen. Zum Abschluss stellen wir ein persönliches Beratungsangebot mit drei abgestuften Fixpreis-Paketen vor. November 2025: alle Inhalte berücksichtigen den aktuellen Stand (inklusive Entra ID-Umbenennung und neuer Features wie Token Protection). Viel Spaß beim Lesen – und beim Absichern Ihrer Cloud-Umgebung!

1. Grundlagen & Architektur von Conditional Access

Conditional Access (deutsch: bedingter Zugriff) ist ein Feature von Microsoft Entra ID (Azure AD), das als Policy Engine im Hintergrund fungiert. Vereinfacht gesagt: “Wenn Benutzer X unter Bedingungen Y auf Ressource Z zugreifen will, dann erlaube/versage das gemäß Richtlinie.” Es geht darum, dass Identitäten der neue Sicherheitsperimeter sind – nicht mehr das Firmennetz allein. Conditional Access aggregiert verschiedene Signale über Benutzer, Gerät, Standort, etc., um eine fundierte Entscheidung für jeden Zugriffsversuch zu treffen. Man kann es sich wie einen Sicherheits-Türsteher in der Cloud vorstellen: Er prüft bei jeder Anmeldung, ob Ausweis (Identität) und Benehmen (Kontext) stimmen, bevor er die Tür zu Outlook, Teams, SharePoint & Co. öffnet.

Wie funktioniert das technisch? Wenn sich ein Benutzer an Microsoft 365 anmeldet (sei es im Browser, in Outlook, auf dem Handy…), durchläuft er zunächst die primäre Authentifizierung (Passwort, ggf. MFA). Direkt danach kommt Conditional Access ins Spiel: Noch bevor ein Zugriffstoken für die App ausgestellt wird, checkt Entra ID alle aktiven Richtlinien. Diese CA-Richtlinien sind if-then-Regeln, die Admins definieren. Dabei können sie auf zahlreiche Signale zugreifen, u.a.:

• Benutzer oder Gruppe: z.B. gelten strengere Policies für Admin-Rollen oder VIPs.
• Anwendung: man kann Policies nur für bestimmte Dienste erzwingen (etwa andere Regeln für das Azure-Portal als für SharePoint).
• Standort (IP-Adresse): z.B. Anmeldungen von definierten Länder- oder IP-Range-Blacklist blockieren, oder interne Netzwerke als vertrauenswürdig einstufen.
• Gerätezustand: Plattform (Windows, iOS, Android, Linux), ob das Gerät Azure AD-registriert ist, ob es den Unternehmens-Richtlinien entspricht (compliant per Intune) oder hybrid-joined ist. Sogar Geräteeigenschaften kann man filtern (bspw. alle Geräte mit bestimmtem Tag als „Privileged Workstation“ behandeln).
• Benutzerrisiko und Anmelderisiko: Wenn man Entra ID Protection (Identity Protection, P2) lizenziert hat, fließen Bewertungen wie “höheres Risiko durch geleaktes Passwort” oder “ungewöhnlicher Anmeldeort” ein. Eine Anmeldung, die als riskant eingestuft wird, kann dann z.B. automatisch blockiert werden.
• Echtzeit-App-Signale: Über die Integration mit Defender for Cloud Apps (MCAS) kann CA auch Sitzungen überwachen und steuern (z.B. Live-Erkennung von ungewöhnlichen Aktivitäten in einer SaaS-App). Darauf basierend lassen sich Sitzungen in Echtzeit begrenzen – etwa Datei-Downloads blockieren, wenn bestimmte Bedingungen verletzt werden.

All diese Signale wertet der bedingte Zugriff in Sekundenschnelle aus und trifft dann Entscheidungen gemäß den konfigurierten Richtlinien. Die häufigsten Entscheidungen sind:

• Zugriff blockieren: Der härteste Einschnitt – der Anmeldeversuch wird abgewiesen. (Beispiel: Ein externer Angriff aus einem Land, in dem die Firma keinerlei Mitarbeiter hat, wird pauschal geblockt.)
• Zugriff gewähren, aber unter Auflagen: Hier gibt es mehrere Kontrollmöglichkeiten, die man kombinieren oder alternativ anbieten kann:
• MFA verlangen: Der Klassiker – zusätzlich zum Passwort muss ein weiterer Faktor (App-Bestätigung, SMS, Telefonanruf, Hardwaretoken) erfolgreich eingegeben werden. (MFA lässt sich auch direkt per Richtlinie erzwingen, ohne auf „Security Defaults“ angewiesen zu sein.)
• Bestimmte Authentifizierungsstärke verlangen: Neuere Option, um z.B. phishing-resistente MFA vorzuschreiben – etwa FIDO2-Sicherheitsschlüssel oder Zertifikatslogin. So stellt man sicher, dass einfache Push-TAN oder SMS nicht genügen.
• Kompatibles bzw. konformes Gerät erfordern: Der Benutzer muss von einem durch die Organisation verwalteten und richtlinienkonformen Gerät kommen (meist via Intune-Compliance). Nicht gemanagte Privatgeräte fallen dann durchs Raster.
• Hybrid Azure AD Joined Device erfordern: Alternativ kann man auch speziell nur Geräte zulassen, die mit dem lokalen AD verknüpft sind (für klassische Hybrid-Setups).
• Genehmigte Client-App erfordern: Nur bestimmte Apps dürfen verwendet werden – z.B. Outlook oder Teams-App – während andere Clients blockiert werden. So kann man etwa Exchange Online für native Apps zulassen, aber Drittanbieter-Mailapps verweigern.
• App-Schutzrichtlinien verlangen: Speziell für Mobil/BYOD-Szenarien kann man verlangen, dass auf dem Gerät ein App-Schutzprofil (MAM-Policy) aktiv ist. So werden Firmendaten in Apps wie Outlook mobil isoliert (z.B. kein Copy/Paste aus Unternehmens-Mail in private Apps).
• Passwortänderung erzwingen: Bei verdächtigen Logins kann man den Benutzer zwingen, sein Kennwort zurückzusetzen, bevor er weitermacht. Dies greift meist bei Identity Protection-Szenarien (P2), wenn ein Konto als kompromittiert gilt.
• Nutzungsbedingungen zustimmen: Der Benutzer muss zuerst unternehmensspezifische Terms of Use akzeptieren. Praktisch, um rechtliche Hinweise abzusichern, bevor Zugriff gewährt wird.
• Sitzungseinschränkungen: Zusätzlich zu den obigen Zugriffsentscheidungen kann CA auch Session Controls setzen. Beispielsweise „Keine persistente Anmeldung“ (Benutzer müssen sich häufiger neu einloggen) oder – in Kombination mit Defender for Cloud Apps – eine laufende Session überwachen (Dateidownloads blockieren, als Read-Only markieren etc.). Diese Feinsteuerung kommt oft zum Einsatz, wenn man unverwalteten Geräten nur eingeschränkten Zugriff geben will, anstatt komplett zu blocken.

Wichtig: Mehrere CA-Richtlinien können gleichzeitig gelten. Falls ein Nutzer in den Geltungsbereich von mehreren Policies fällt, werden alle relevanten Anforderungen kumulativ durchgesetzt. Dabei gilt im Effekt: Das Strengere setzt sich durch. Beispiel: Eine Richtlinie verlangt MFA, eine andere blockiert den Zugriff – dann wird geblockt. Eine Policy kann den Zugriff erlauben, aber eine zweite erzwingt MFA – dann muss MFA her. Es gibt keine Prioritätenreihenfolge, weshalb ein durchdachtes Design der Regeln entscheidend ist (siehe Abschnitt „Policy-Kochbuch“). Für Admins bietet das Entra-Portal übrigens ein „Was-wäre-wenn“-Tool: Damit lässt sich vorab simulieren, welche Policies für einen bestimmten Benutzer unter bestimmten Bedingungen greifen würden.

Aus Administratorsicht ist Conditional Access in der Microsoft Entra Admin Center Web-Oberfläche konfigurierbar (Entra ID > Bedingter Zugriff). Dort legt man seine Richtlinien mit wenigen Klicks an. Microsoft liefert auch vorgefertigte Vorlagen für gängige Anwendungsfälle (z.B. „MFA für Administratoren erzwingen“, „Legacy-Authentifizierung blockieren“ etc.), die man als Startpunkt nutzen kann. Neue Preview-Features wie der Conditional Access Berechtigungs- & Optimierungs-Agent (in Kombination mit Security Copilot) versprechen in Zukunft sogar automatische Policy-Empfehlungen basierend auf Best Practices – aber Stand heute (Ende 2025) ist weiterhin Admin-Fachwissen und Sorgfalt gefragt.

Architektonisch läuft die CA-Policy-Evaluierung vollständig in der Cloud innerhalb von Entra ID ab – es braucht also keine zusätzliche Infrastruktur on-premises. Das heißt aber auch: Wenn Entra ID ausfällt (extrem selten, aber denkbar) oder man sich durch falsche Policies aussperrt, kommt niemand mehr ran (außer über einen vorher eingerichteten Notfall-Account). Daher immer mindestens ein Notfall-Administratorkonto einrichten, das von allen CA-Regeln ausgenommen ist – eine Art Generalschlüssel im Tresor, für den Fall der Fälle! Auf das Thema kommen wir im Abschnitt Betrieb nochmals zurück.

Im Ergebnis ermöglicht Conditional Access eine dynamische, risikobasierte Zugriffskontrolle für Microsoft 365 und darüber hinaus. Sie bildet den Kern eines modernen Identity- und Zugriffsmanagements, wo Identität der neue Perimeter ist. Ohne CA bleiben Admins letztlich nur starre Alles-oder-nichts-Entscheidungen (z.B. globales MFA an oder aus). Mit CA hingegen lassen sich granulare Policies definieren, die Sicherheit und Benutzerfreundlichkeit ausbalancieren – ganz nach dem Motto: So restriktiv wie nötig, so flexibel wie möglich.

2. Bewährte Regeln („Policy-Kochbuch“)

Welche Conditional-Access-Richtlinien haben sich in der Praxis besonders bewährt? In diesem Kapitel stellen wir ein Policy-Kochbuch vor – eine Sammlung von 15+ empfehlenswerten Richtlinien, die in den meisten Microsoft-365-Umgebungen für deutlich mehr Sicherheit sorgen. Jede Organisation ist anders, aber diese „Rezepte“ liefern eine solide Grundlage, die Sie an Ihre Bedürfnisse anpassen können. Anschließend gibt es eine Checkliste, mit der Sie prüfen können, ob Sie an alle wichtigen Punkte gedacht haben.

Empfohlene Conditional-Access-Policies (Übersicht)

Policy / Richtlinie	Beschreibung & Zweck
1. MFA für alle Benutzer erzwingen	Jeder Benutzer muss bei der Anmeldung einen zweiten Faktor (MFA) durchlaufen. Gilt tenant-weit für alle Apps.<br>• Zweck: Schützt alle Konten durch MFA – Basis-Schutzmaßnahme gegen Passwortdiebstahl.<br>• Details: Umsetzung meist via „Alle Benutzer, alle Cloud-Apps“ und Grant Control „MFA erforderlich“. Ausnahmen: Service Accounts, Notfallkonto.
2. MFA für Administratoren (strikte Variante)	Spezielle MFA-Pflicht nur für Administratoren und privilegierte Rollen – und zwar bei jedem Anmeldevorgang.<br>• Zweck: Sichert hochprivilegierte Accounts nochmals schärfer ab, selbst innerhalb vertrauenswürdiger Umgebungen.<br>• Details: Betrifft Azure AD Rollen wie Global Admin, SharePoint Admin, Exchange Admin etc. In Entra ID lassen sich Rollen direkt auswählen. Zusätzlich kann man „Access Management für Azure“ erzwingen (MFA fürs Azure-Portal). Keine Ausnahmen außer Notfallkonto.
3. Schutz der MFA-Registrierung	Richtlinie, die den Registrierungsprozess für Sicherheitsinformationen absichert.<br>• Zweck: Verhindert, dass ein Angreifer sich unbefugt einen zweiten Faktor zu einem Konto hinzufügt (z.B. wenn er das Passwort schon kennt).<br>• Details: Gilt für den Cloud-App-Typ „Benutzeraktivitäten“ – speziell „Registration of security info“. Grant: z.B. „MFA erforderlich“ ODER „vertrauenswürdiger Standort erforderlich“. Damit kann man festlegen, dass Nutzer ihre MFA-Geräte nur im Firmen-LAN oder nach bestehender MFA hinzufügen/ändern dürfen.
4. Legacy-Authentifizierung blockieren	Alte Protokolle ohne MFA-Unterstützung komplett verbieten.<br>• Zweck: Schließt eine der größten Lücken, da Angreifer oft über SMTP, IMAP, POP3 oder alte Office-Clients Passwörter abgreifen. Legacy Auth erlaubt kein MFA – also: deaktivieren!<br>• Details: Gilt auf „Alle Benutzer“ und Anwendungs-Filter „Alle Cloud-Apps“. Unter Bedingungen -> Client-Apps „Legacy Authentication“ auswählen. Blockieren als Kontrollentscheidung. Ausnahmen evtl. für notwendige Service-Accounts, die Basic Auth benötigen (besser: diese umstellen, falls möglich).
5. Zugriff aus bestimmten Ländern blockieren	Regionen/Länder blockieren, aus denen keine legitimen Logins zu erwarten sind.<br>• Zweck: Erschwert Angriffe aus typischen Fraud-Herkunftsländern (oder allen außer den Ländern der eigenen Niederlassungen).<br>• Details: Einrichtung eines Namensstandorts (Named Location) mit z.B. „Rest der Welt“ oder spezifischer Blacklist-Liste. Dann Richtlinie: „Standort ist in Blacklisted Countries“ -> Zugriff blockieren. Eventuell separate Policy „Zugriff nur aus [Deutschland, EU, etc.] erlauben“ als Whitelist-Ansatz. Wichtig: Ausschluss des Notfall-Admins, falls dieser sich auch mal von außerhalb anmelden muss.
6. Vertrauenswürdige Orte für interne Apps nutzen	Um internen Mitarbeitern im Büro etwas entgegenzukommen: Weniger strenge Vorgaben im Firmennetz.<br>• Zweck: Weniger MFA-Aufforderungen intern, aber voller Schutz extern – verbessert User Experience, wenn im internen Netz bereits andere Schutzmechanismen greifen.<br>• Details: Definition eines Named Location (z.B. öffentliche IP des VPN/Standort). Dann Policy A: „Standort = intern -> MFA nicht erforderlich“ (oder Policy so bauen, dass MFA-Policy externe Location als Bedingung voraussetzt). Wichtig: Zero-Trust-Prinzip empfiehlt eigentlich, überall zu verifizieren; viele Unternehmen erlauben intern jedoch Erleichterungen. Entscheid nach Risikobewertung treffen!
7. Geräte-Compliance für sensible Apps	Nur compliant Devices dürfen auf bestimmte sensible Anwendungen zugreifen.<br>• Zweck: Datenzugriff auf kritische Apps (z.B. Finanzsysteme, HR-Daten, Power BI) nur von voll gemanagten und sicheren Geräten aus – verhindert Datenabfluss von Privatgeräten.<br>• Details: Richtlinie zielt auf ausgewählte Anwendungen (Cloud-Apps auswählen) wie z.B. das ERP-System (falls via Entra integriert) oder auch alle High-Impact Azure Enterprise Apps. Bedingung: Gerätefilter „Device Is Compliant = true“. Grant: Zugriff gewähren, andernfalls blockieren (oder alternativ MFA als Sekundär-Auflage, aber meist block). Voraussetzung: Geräteverwaltung via Intune und richtlinienkonforme Geräte.
8. Hybrid Join oder MFA (entweder/oder)	Kombinierte Regel: Entweder Gerät ist Domänen-joined (Hybrid Azure AD Join) oder Benutzer muss MFA machen.<br>• Zweck: Erreicht Benutzerfreundlichkeit auf Firmen-PCs (angemeldet in AD = kein ständiges MFA) bei gleichzeitiger Sicherheit für externe/Privat-Geräte (müssen MFA).<br>• Details: In einer CA-Policy lässt sich unter Grant Controls die Option „erfülle eine der folgenden“ wählen. Dort: „Require hybrid AD joined device“ und „Require MFA“ ankreuzen und auf eine der ausgewählten setzen. Gilt z.B. für Alle Benutzer, alle Apps oder breiter. Ergebnis: Domänen-PC im Büro braucht kein extra MFA, alles andere schon.
9. App-geschützte Zugriffssession (SharePoint)	Downloads auf nicht vertrauenswürdigen Geräten verhindern, statt kompletten Zugriff zu sperren.<br>• Zweck: Balance zwischen Sicherheit und Usability: Externe oder BYO-Benutzer dürfen z.B. in SharePoint Online lesen/bearbeiten, aber keine Dateien auf ihr unsicheres Gerät kopieren.<br>• Details: CA-Policy für „SharePoint Online“ (und OneDrive) mit Bedingung „Device ist nicht compliant bzw. unbekannt“. Session-Control: „Use app enforced restrictions“. SharePoint verfügt über eingebaute Mechanismen, um im Browser die Download/Sync/Print-Funktionen zu beschränken, sobald CA dies vorgibt. (Hinweis: Full Blocking wäre Alternative, aber hiermit ermöglicht man read-only Zugriff für BYOD.)
10. Durchsetzung von Terms of Use	Nutzungsbedingungen vor Zugriff einblenden und Zustimmung protokollieren.<br>• Zweck: Rechtliche Absicherung, dass Nutzer (Mitarbeiter oder Gäste) bestimmten Regeln zustimmen (z.B. Acceptable Use Policy, Datenschutzrichtlinie) bevor sie Services verwenden.<br>• Details: Zuerst in Entra ID eine Terms-of-Use-Datei hochladen. Dann CA-Policy: „Alle Nutzer“ (oder bestimmte Gruppen) auf relevante Cloud-App(s) -> Grant-Control: „Require Terms of Use“. Der User sieht beim Login einmalig das PDF und muss bestätigen. Praktisch insbesondere für Gastnutzer bei B2B-Kollaboration, um NDAs etc. einzuholen.
11. Riskante Anmeldungen blockieren (Identity Protection)	(P2-Funktion) Sign-ins mit hohem Risiko automatisch blockieren.<br>• Zweck: Wenn das System verdächtige Anmeldung erkennt (z.B. unmögliche Reise: User vor 1h in Europa, jetzt in Asien), wird der Zugriff verweigert – noch bevor Schaden entsteht.<br>• Details: Identity Protection stuft jede Anmeldung mit einem Risiko-Level ein (niedrig/mittel/hoch). CA-Policy kann „User sign-in risk = high“ als Bedingung nehmen und Zugriff blockieren. Für mittleres Risiko evtl. MFA oder Passwortwechsel verlangen (je nach Unternehmensstrategie). Erfordert Entra ID P2-Lizenz.
12. Kompromittierte Accounts blockieren	(P2-Funktion) Benutzer mit hohem Risiko blockieren oder zur Passwortänderung zwingen.<br>• Zweck: Erkennt kontoweit gefährdete User (z.B. Passwort geleakt im Darknet) und verhindert deren weiteren Zugriff, bis geklärt ist.<br>• Details: Identity Protection bewertet das Benutzerobjekt (user risk) unabhängig von einzelnen Sign-ins. Bei hohem Risiko kann eine CA-Policy greifen: entweder Blockieren oder Require password change (was den Login zur Passwortzurücksetzung umleitet). So bleibt ein gehacktes Konto nicht ungehindert aktiv.
13. Phishing-resistente MFA für kritische Rollen	(P1/P2 mit Authentifizierungsstärken) Erfordernis von besonders sicheren MFA-Methoden für bestimmte Gruppen.<br>• Zweck: Sicherstellen, dass z.B. Admins oder Entwickler mit Prod-Zugriff Hardware-Phishing-Schutz nutzen (FIDO2 Key, certbasierte Auth oder wenigstens Number-Matching) – da diese Zielgruppen oft im Visier von Phishing stehen.<br>• Details: Entra ID erlaubt, Authentication Strengths als Bedingung zu verwenden. Man definiert eine Stärke (z.B. „Phishing-resistant MFA“ umfasst FIDO2 und Certificate). CA-Policy auf Zielgruppe Admins anwenden, Kontrolle „Require authentication strength: PhishingResistant“. Ergebnis: Einfache MFA wie SMS oder mobile App reichen dann nicht aus – nur z.B. der FIDO2-Schlüssel.
14. Workload identities absichern	(Preview P2) CA für Service-Accounts/Apps (Workload Identities) anwenden.<br>• Zweck: Auch nicht-personelle Anmeldungen (z.B. ein CI/CD-Service-Prinzipal oder eine Legacy-App, die per eigenem Account auf M365 zugreift) unter Policies stellen – etwa Einschränkung auf bestimmte IPs oder Zeiten.<br>• Details: Entra ID bietet Conditional Access auch für Client-Apps/Service Principals. Beispiel: Ein Service-Principal darf nur von definierter IP (Rechenzentrum) aus Token bekommen. Oder er wird blockiert, falls ungewöhnliche Nutzung erkannt wird. So zieht man Zero Trust sogar für automatisierte Zugriffe durch.
15. Notfall-Accounts ausschließen	Break-Glass-Konto von allen CA-Policies ausnehmen (Konfigurationsvorgabe, keine Endnutzer-Policy).<br>• Zweck: Sicherstellen, dass immer ein Adminzugang bleibt, selbst wenn eine fehlerhafte Richtlinie alle anderen aussperrt.<br>• Details: Mindestens ein Cloud-Admin-Konto anlegen, MFA-fähig aber nicht durch CA erzwungen, und nirgendwo in Policies einschließen. In jeder CA-Policy sollte bei Ausnahmen eine Gruppe „Notfallkonten“ oder zumindest das eine Konto stehen. Dieses Konto muss gut geschützt offline verwahrt werden (und regelmäßig auf Funktion geprüft!).

Legende: MFA = Multi-Faktor-Authentifizierung, P1/P2 = Entra ID Premium P1/P2 Lizenz erforderlich, MCAS/Defender for Cloud Apps = separate E5-Lizenz ggf. erforderlich für volle Funktion.

Die obige Tabelle kombiniert universelle Basics (z.B. MFA, Legacy-Block) mit fortgeschrittenen Szenarien (Risk-Based Controls, Token Protection, Workload Identities). In der Praxis sollte man zunächst die kritischen Must-haves umsetzen und dann nach Bedarf erweitern. Wichtig ist, die Policies klar zu benennen und verständlich zu dokumentieren – so behält man auch bei 15+ Regeln den Überblick.

Checkliste: Wichtige Punkte bei Conditional Access

Haben Sie an alles gedacht? – Diese Checkliste hilft, typische Fallstricke zu vermeiden und Ihre Conditional-Access-Implementierung abzurunden. Gehen Sie die Punkte durch und haken Sie mental ab:

• [ ] Notfall-Zugriff sichergestellt: Mindestens ein Notfall-Administratorkonto existiert, ist von allen Richtlinien ausgenommen, getestet und die Zugangsdaten liegen sicher vor.
• [ ] Alle Admins geschützt: Sämtliche Administratoren- und privilegierte Konten unterliegen MFA und ggf. zusätzlichen Controls (keine Dauer-Ausnahmen für „VIPs“ ohne Kompensation).
• [ ] Legacy Auth deaktiviert: Alte Authentifizierungsprotokolle sind unterbunden oder die wenigen benötigten Ausnahmen sind sauber eingegrenzt. Überwachungs-Logs zeigen keine erfolgreichen Legacy-Logins mehr.
• [ ] Benutzer kommuniziert & geschult: Die Anwender wissen über die MFA-Einführung und neue Zugriffsregeln Bescheid (Rollout-Ankündigung, Guides für MFA-App eingerichtet). Helpdesk bereit für MFA-Fragen.
• [ ] Policies getestet (Report-Only): Neue oder geänderte Richtlinien wurden zunächst im Report-Only-Modus oder mit Test-Usern geprüft. Die What-If-Analyse wurde für kritische Szenarien genutzt, bevor man „Einschaltet“ geklickt hat.
• [ ] Keine Überschneidungen ohne Absicht: Policy-Konflikte wurden vermieden – die Reihenfolge der Bedingungen und Ausnahmen ist durchdacht. (Tipp: Lieber wenige, klar abgegrenzte Policies als eine unübersichtliche Alles-in-einem-Regel.)
• [ ] Service Accounts berücksichtigt: Accounts, die nicht interaktiv arbeiten (z.B. Anwendungen, Scanner, Legacy-Systeme), wurden identifiziert und entweder auf moderne Auth umgestellt oder aus Policies exkludiert und anderweitig abgesichert.
• [ ] Gerätemanagement integriert: Falls „Compliant Device“ gefordert wird, ist Intune (oder ein kompatibles MDM) ausgerollt und die Geräte sind registriert. Andernfalls greifen solche Policies ins Leere.
• [ ] Gäste und B2B bedacht: Zugriff externer Partner wurde geprüft – ggf. separate Richtlinien (z.B. immer MFA für Gäste) eingerichtet. Cross-Tenant-Einstellungen so konfiguriert, dass sie MFA-Ansprüche externer IdP berücksichtigen (für bessere Usability).
• [ ] Monitoring eingerichtet: Verantwortliche schauen regelmäßig in die Sign-In Logs von Entra ID, um abgelehnte Anmeldungen oder ungewöhnliche Muster zu erkennen. Optional: Einrichtung des Azure Monitor Workbooks oder SIEM-Integration für CA-Events.
• [ ] Dokumentation & Änderungen: Alle Policies sind im Policy-Register festgehalten (siehe Abschnitt 7). Es gibt einen definierten Prozess, wie neue Anforderungen umgesetzt oder Änderungen genehmigt werden (Governance vorhanden).

Wenn Sie alle Punkte abhaken können – Glückwunsch! Ihre Umgebung ist auf einem sehr guten Weg. Natürlich bleibt Conditional Access ein lebendes Konstrukt: Man wird immer mal nachjustieren müssen, neue Ausnahmen kommen hinzu, alte entfallen. Mit einer sauberen Grundstruktur und dieser Checkliste im Hinterkopf behalten Sie aber dauerhaft die Kontrolle.

3. Sichere Einführung: Methodik & Rollout

Eine gute Planung ist die halbe Miete – das gilt besonders bei sicherheitsrelevanten Features wie Conditional Access. „Hart aber herzlich“ sollte die Devise sein: Strenge Policies, aber mit Augenmaß eingeführt, um Geschäftsprozesse nicht zu stören. In diesem Abschnitt skizzieren wir eine bewährte Einführungs-Methodik mit Phasenmodell, gehen auf Governance-Aspekte ein und zeigen, welche KPIs den Erfolg messbar machen.

Phasenmodell für den Rollout

Typischerweise empfiehlt sich ein mehrstufiges Vorgehen, um Conditional Access in einem Unternehmen auszurollen. Eine mögliche Projekt-Phasierung könnte so aussehen:

1. Planung & Konzeption (Phase 1): Analyse der aktuellen Lage – Welche Benutzer und Daten müssen besonders geschützt werden? Gibt es schon MFA im Einsatz (z.B. per Security Defaults)? Inventarisierung aller eingesetzten Anwendungen und Gerätearten. Darauf basierend Policy-Framework entwerfen: Welche Richtlinien wollen wir umsetzen (z.B. aus dem obigen Kochbuch) und in welcher Reihenfolge? Schon hier die Stakeholder einbeziehen: IT-Leitung, Security Officer, ggf. Betriebsrat (bei größeren Änderungen für Benutzer). Ergebnis dieser Phase: Eine Roadmap mit priorisierten Policies, festgelegten Pilotgruppen und Erfolgskriterien. Governance vorbereiten: Rollen & Verantwortlichkeiten definieren (z.B. wer darf später neue CA-Policies anlegen? Change-Management-Prozess skizzieren).
2. Pilot & Testing (Phase 2): In dieser Phase wird das Konzept im Kleinen erprobt. Einrichten der ersten CA-Richtlinien im Report-Only-Modus – so kann man in den Entra-Auswertungen sehen, was passiert ohne real zu blocken. Auswahl einer Pilotgruppe (idealerweise technisch versierte Nutzer oder eine bestimmte Abteilung), die neue Policies tatsächlich enforced bekommt. Beispielsweise zunächst MFA-Pflicht für IT-Team und freiwillige Power-User, während der Rest noch frei ist. Enges Monitoring: Tägliches Prüfen der Anmeldeprotokolle, Feedback der Pilotteilnehmer einholen. In dieser Phase gilt es, etwaige Probleme früh zu erkennen: Kommt jemand nicht mehr in eine benötigte Applikation? Haben wir einen Legacy-Client übersehen, der nun nicht mehr funktioniert? Gegebenenfalls Feinjustierung der Richtlinien vornehmen oder zusätzliche Ausnahmen definieren. Wichtig auch: Benutzer-Schulung und Kommunikation im Pilot – die Kollegen müssen wissen, wie sie die Authenticator-App benutzen oder was zu tun ist, wenn eine Meldung erscheint.
3. Stufenweiser Rollout (Phase 3): Nun wird Conditional Access schrittweise unternehmensweit ausgerollt. Dabei nicht alles auf einmal „scharf schalten“, sondern in Wellen vorgehen – z.B. Abteilung für Abteilung, oder Policy für Policy. Viele starten etwa mit einer generellen MFA-Pflicht für alle (nachdem Pilotuser es vorgemacht haben), dann ein paar Wochen später kommen die Standort- und Geräterestriktionen hinzu. Das reduziert die gleichzeitige Belastung von Helpdesk und Change-Management. Vor jeder Welle: Stakeholder informieren, ggf. How-To-Anleitungen bereitstellen („Wie melde ich mein Gerät an?“, „Was tun bei MFA-Problemen?“). Während jeder Welle: KPIs beobachten (siehe unten) – z.B. Anstieg fehlgeschlagener Logins? Support-Tickets? – und darauf reagieren. Parallel weiter Kommunikation betreiben: Erfolge ans Management berichten („Wir haben jetzt XX% der Anmeldungen mit MFA geschützt“), aber auch offen über etwaige Schwierigkeiten informieren.
4. Betrieb & Optimierung (Phase 4): Ist Conditional Access einmal überall aktiv, geht das Projekt in den Regelbetrieb über (siehe auch nächstes Kapitel für Details). Hier sollte man aber von Anfang an eine kontinuierliche Verbesserung einplanen. Neue Anforderungen kommen garantiert: Vielleicht möchte in ein paar Monaten die Compliance-Abteilung, dass eine Terms-of-Use-Bestätigung eingeführt wird; oder die Geschäftsführung entscheidet, externen Partnern doch mehr Zugriff einzuräumen (mit entsprechenden Sicherheitsvorkehrungen). Daher einplanen: Regelmäßige Reviews der Policies (Empfehlung: alle 6–12 Monate) und Monitoring-Routinen (wöchentliches Prüfen der Anmeldeberichte). In dieser Phase greift dann die etablierte Governance: Änderungen gehen durchs definierte Prozedere, Notfall-Ausnahmen werden dokumentiert, KPIs werden gemessen und berichtet.

Zusammengefasst: Eine sanfte, aber bestimmte Einführung in Phasen minimiert das Risiko von Geschäftsunterbrechungen. Mitarbeiter und Führungskräfte nehmen die Veränderungen eher an, wenn sie schrittweise eingeführt und gut begründet werden („Wir führen MFA ein, weil es 99% der Angriffe verhindert – siehe Bericht XY“). Zudem lassen sich so Kinderkrankheiten früh kurieren, bevor alle betroffen sind.

Governance: Richtlinien steuern statt Wildwuchs

Gerade weil Conditional Access so mächtig ist, braucht es klare Governance und Zuständigkeiten. Nichts wäre schlimmer, als wenn zig Admins unkoordiniert Policies bauen und am Ende keiner mehr durchblickt, welche Regel was bewirkt.

Best Practices für Governance bei CA:

• Klare Rollenverteilung: Legen Sie fest, wer Richtlinien erstellen, ändern und freigeben darf. Typischerweise sollte ein kleines Kernteam aus Security- und Identity-Admins diese Aufgabe haben. In Entra ID gibt es die Rolle Conditional Access Administrator – weise diese nur sparsam zu! Für Änderungen sollte idealerweise das Vier-Augen-Prinzip gelten (eine Person schlägt vor, eine zweite prüft und genehmigt).
• Change-Management-Prozess: Jede neue CA-Policy oder Änderung sollte durch einen kurzen Prozess laufen: Antrag -> Impact-Analyse -> Genehmigung -> Umsetzung -> Dokumentation. Das muss kein Bürokratiemonster sein, aber zumindest schriftlich festgehalten werden. Wichtig, um im Nachhinein nachvollziehen zu können, warum z.B. am 10. Mai Policy XY deaktiviert wurde und wer das entschieden hat.
• Policy-Register führen: Wie in Abschnitt 7 beschrieben, hilft eine Tabelle oder Liste aller Richtlinien mit Details (Name, Zweck, Gültigkeitsbereich, Ersteller, Änderungsdatum, etc.). Dieses Register wird bei jeder Änderung aktualisiert. So hat man immer eine aktuelle Referenz und kann sie z.B. Auditoren vorlegen (Stichwort ISO 27001 oder interne Revision).
• Regelmäßige Überprüfung: Setzen Sie einen wiederkehrenden Termin (z.B. vierteljährlich), an dem das CA-Team alle aktiven Policies durchgeht: Passen die noch? Gibt es inzwischen bessere Lösungen (neue Features)? Sind temporäre Ausnahmen inzwischen obsolet? Diese Reviews sorgen dafür, dass keine „Karteileichen“ bleiben und die Strategie angepasst wird, wenn sich Geschäftsanforderungen ändern.
• Schulungen und Awareness: Governance heißt auch, das Thema in der Organisation bekannt zu machen. Halten Sie die IT-Abteilung und auch Vertreter der Fachbereiche auf dem Laufenden, welche Access-Policies gelten. So vermeiden Sie Überraschungen („Wieso kann meine Abteilung X nicht mehr auf Tool Y zugreifen?“ – „Weil eine Policy das jetzt verlangt, und Sie wussten von nichts.“) Ein kurzer Eintrag im IT-Newsletter oder Intranet kann Wunder wirken.
• Notfallprozeduren: Definieren Sie im Governance-Dokument, wie vorzugehen ist, wenn eine CA-Richtlinie versehentlich legitime Zugriffe verhindert. Beispiel: Wenn plötzlich ein ganzer Standort wegen einer IP-Veränderung ausgesperrt ist, wer darf die Policy kurzfristig deaktivieren? Wie informieren wir die Nutzer? Gibt es einen Backup-Weg (z.B. temporär Security Defaults anwerfen)? Solche Abläufe sollte man im Vorfeld durchdenken – am besten auch praktisch durchspielen (Fire-Drill).

Im Kern geht es darum, Conditional Access wie einen lebenden Organismus zu behandeln, der gepflegt werden muss. Governance sorgt dafür, dass er gesund bleibt und kontrolliert wächst, anstatt Chaos zu stiften.

KPIs & Erfolgsmessung

Wie erkennen Sie, ob Ihre Conditional-Access-Initiative erfolgreich ist? Einige Key Performance Indicators (KPIs) und Metriken können helfen:

• MFA-Abdeckungsquote: Anteil der Anmeldungen, die mit MFA erfolgen. Wenn anfangs nur 10% der Sign-ins MFA erforderten und nach dem Rollout 95%, ist das ein klares Zeichen für gesteigerte Sicherheit. (Microsoft Secure Score greift so eine Kennzahl übrigens auf.)
• Blockierte Anmeldeversuche: Anzahl der Logins, die durch CA blockiert wurden, aufgeschlüsselt nach Grund (z.B. 200 Blockierungen im letzten Monat wegen Legacy Auth, 50 wegen Standort China, 5 wegen hohem Risiko). Dies zeigt direkt, wie viele potenziell gefährliche Zugriffe verhindert wurden. Idealerweise sollten einige dieser Zahlen mit der Zeit sinken – z.B. Legacy Auth Blocks werden weniger, weil keine Clients mehr übrig sind, die es versuchen.
• Anmeldedauer/Benutzerfeedback: Ist zwar kein klassischer KPI, aber man kann die Auswirkungen auf Usability im Blick behalten. Z.B. Umfragen oder stichprobenhaftes Feedback: „Fühlen Sie sich durch MFA stark beeinträchtigt?“ Wenn 90% antworten „Es stört kaum/nicht“, hat man’s richtig gemacht. Steigen hingegen Helpdesk-Tickets mit Betreff „MFA geht nicht“ oder „Kann mich nicht anmelden“, sollte man das ernst nehmen.
• Anzahl Sicherheitsvorfälle (Konto-Kompromittierungen): Idealerweise messen Sie, wie viele Account-Breaches es vor und nach CA gab. Oft sieht man einen drastischen Rückgang nach Einführung von MFA & Co. (Falls doch mal was passiert: War es vielleicht ein Konto, das von CA ausgenommen war? Daraus lernt man dann.)
• Secure Score und Audit-Compliance: Microsoft Secure Score gibt Punkte für implementierte CA-Controls. Ein Sprung von z.B. 30% auf 60% im Bereich Identity Security zeigt Erfolg. Ebenso können interne/Externe Audits als Gradmesser dienen: Fragte der Auditor letztes Jahr noch „Warum haben Sie kein MFA?“, so wird er dieses Jahr zufrieden sein, wenn er die CA-Policies sieht. Erfüllung von Normen (BSI IT-Grundschutz, ISO 27001 A.9) lässt sich mit CA schön nachweisen – das kann ein KPI für Compliance sein.
• Nutzer-Abdeckung Conditional Access: Ähnlich MFA-Quote, aber man kann tracken: wie viele User fallen inzwischen unter mindestens eine CA-Policy? (Antwort sollte sein: alle Benutzer, außer definierte Ausnahmen). Wenn das 100% ist, Ziel erreicht.
• Zeit bis zur Reaktion: Ein etwas fortgeschrittener KPI wäre: Wie schnell reagieren wir auf geänderte Rahmenbedingungen? Z.B. neue Home-Office-Welle -> haben wir innerhalb einer Woche Policies angepasst (z.B. Vertrauen in Home-IPs entfernt)? Oder Entdeckung eines geleakten Accounts -> in Minuten blockiert? Hier misst man die Agilität des Teams im Umgang mit CA.

Wichtig ist, die KPIs mit der Geschäftsleitung zu teilen. Zeigen Sie in Reports auf, welche Verbesserungen erzielt wurden („99 phishing-Versuche blockiert diese Woche“). Das schafft Rückendeckung für Security-Maßnahmen. Übertreiben sollte man es nicht – nicht jeder Vorstand will tägliche Login-Statistiken sehen – aber ein aussagekräftiger KPI im quartalsweisen IT-Sicherheitsbericht (z.B. „MFA-Abdeckung bei 98% aller Logins, gegenüber 5% vor einem Jahr“) spricht Bände.

Zusammengefasst: Mit geplanten Phasen, klarer Governance und kontinuierlichem Monitoring der KPIs stellen Sie sicher, dass Conditional Access sicher eingeführt und nachhaltig betrieben wird. So wird aus einer technischen Einstellung ein gelebter Bestandteil der Unternehmenssicherheit.

4. Betrieb & Fehlerbehebung

Nachdem Conditional Access etabliert ist, geht die Arbeit erst richtig los: Die tägliche Pflege, Überwachung und gelegentliche Fehlersuche stehen an. Dieser Abschnitt beleuchtet typische Stolperfallen im Betrieb, gibt Tipps zur Problemanalyse und zeigt, wie Sie Ihre Policies aktuell und wirksam halten.

Typische Stolperfallen im Alltag

Auch bei guter Planung tauchen im laufenden Betrieb immer wieder Situationen auf, die man nachjustieren muss. Hier einige der klassischen Fallen und wie man ihnen begegnet:

• „Wir haben uns ausgeschlossen!“ – Der Super-GAU: Durch eine vorschnelle Policy-Aktualisierung sperrt man alle Admins (und Nutzer) aus. Zum Beispiel „Alle Benutzer MFA“ aktiviert, aber die Authenticator-Benachrichtigungen funktionierten grad nicht – schon kommt keiner mehr rein. Prävention: Notfallkonto nie vergessen (und nicht mit Conditional Access belegen, siehe Policy 15 oben). Außerdem immer erst Report-Only testen oder nur kleine Pilotgruppe einschalten. Falls es doch passiert: Mit dem Breakglass-Account anmelden und die betreffende Policy deaktivieren oder entschärfen. Wenn kein Notfall-Account existiert (aua!), bleibt nur der Weg über Microsoft Support – das kostet wertvolle Zeit und Nerven. Also: Vorsorge ist hier die einzige Rettung.
• Vergessene Ausnahmen: Vielleicht haben Sie strikte Policies gebaut – und dann meldet sich der Scanner/Kopierer im Büro, der über ein einfaches IMAP-Mailkonto Scans verschickt: „Plötzlich kann ich keine Mails mehr senden.“ Ursache: Die Block Legacy Auth-Policy hat diesen „User“ erwischt. Solche Service Accounts und technischen Benutzer übersieht man gerne. Lösung: Entweder diesen Accounts gezielt moderne Auth beibringen (manche Geräte unterstützen OAuth inzwischen), oder sie aus der betreffenden Policy herausnehmen (Ausnahmegruppe) und alternative Controls anwenden – z.B. Mailfluss-Regeln, um ihre Aktivitäten einzuschränken. Generell sollte die Zahl solcher Ausnahmen minimal sein und dokumentiert werden, sonst unterminieren Sie den Sicherheitsgewinn.
• Policy-Reihenfolge und Kollisionen: Wie erwähnt gibt es keine feste Reihenfolge – alle CA-Richtlinien werden parallel ausgewertet. Das kann aber zu unintendierten Effekten führen, wenn man es nicht bedenkt. Beispiel: Sie haben eine Policy „Geräte müssen compliant sein“ (andernfalls Block). Gleichzeitig eine Policy „MFA für alle“. Ein Mitarbeiter auf einem nicht konformen Gerät bekommt dann evtl. zwei Meldungen: erst MFA, danach trotzdem Block wegen Device – extrem frustrierend für ihn („Ich hab doch MFA gemacht und komm trotzdem nicht rein!“). Tipp: Solche Situationen vermeidet man, indem man Policies kombiniert (z.B. MFA ODER compliant wie in Policy 8) oder die Kommunikation anpasst („Auf deinem Gerät ist leider trotz MFA kein Zugriff erlaubt“). Auch die Reihenfolge der Anforderungen sollte konsistent sein: Erst blockieren, dann MFA? In der Regel will man lieber zuerst block klar definierte No-Gos (gesperrtes Land, kompromittierter User), dann Auflagen wie MFA für alles andere.
• Auswirkungen neuer Features unterschätzt: Microsoft entwickelt ständig weiter. Beispiel: Continuous Access Evaluation (CAE) – diese sorgt dafür, dass Access Tokens in near-realtime ungültig werden, wenn gewisse Events eintreten (Passwort geändert, Konto deaktiviert, etc.). Das ist toll für Sicherheit, aber bei einem komplexen Setup kann es verwirren: Ein User meldet, er wurde ausgeloggt, weil wir seinen Account im AD umbenannt haben (was CAE als potenziell riskant sah). Lernpunkt: Beim Betrieb stets up-to-date bleiben, was neue Entra ID-Features tun, und ob sie auf bestehende Policies Einfluss haben. Ab und zu in die Microsoft-Roadmap schauen oder Tech-Community lesen, damit einen neue Preview-Settings nicht überraschen.
• Lizenzprobleme: Conditional Access setzt Premium-Lizenzen voraus (siehe Abschnitt 5). Eine Falle im Betrieb: Wenn z.B. ein E5 Testtenant ausläuft oder Lizenzen versehentlich entzogen werden. Die Policies bleiben zwar bestehen, können aber nicht mehr editiert werden, und einige (v.a. P2-Funktionen) greifen evtl. nicht mehr zuverlässig. Maßnahme: Lizenzierungsstatus im Blick behalten. Azure AD meldet z.B. im Portal, wenn die Lizenz nicht (mehr) ausreicht für die konfigurierten Policies. Im Zweifel: Reduzieren auf die Basis-P1-Regeln oder Lizenzen nachkaufen, bevor etwas Ungültiges im System steht.
• Benutzerwechsel & Rollenänderungen: Ein gern übersehener Aspekt: Conditional Access bezieht sich oft auf Gruppen oder Rollen. Wenn Personen das Unternehmen verlassen oder neue dazukommen, sollten Sie sicherstellen, dass die Gruppenzuordnungen aktuell sind. Beispiel: Ein neuer Admin wird ernannt – steckt der schon in der „MFA for Admins“-Policy drin? Oder eine Führungskraft verlässt die Firma – hängt deren Account vielleicht noch als Ausnahme irgendwo drin? Regel: Offboarding-Prozesse mit CA-Gruppen verzahnen und regelmäßige Access Reviews (P2-Feature) nutzen, um verwaiste Accounts/Groups zu bereinigen.

Troubleshooting: Wenn ein Nutzer nicht reinkommt

Trotz aller Sorgfalt wird es vorkommen, dass Ihnen ein Anruf im IT-Support durchgestellt wird: „Ich kann mich nicht anmelden – da steht etwas von Conditional Access…“ Wie gehen Sie vor?

1. Ruhig bleiben & Fakten sammeln: Welche Anwendung? Welcher Benutzer? Welche Uhrzeit ca.? Was für eine Meldung bekommt er? Oft sehen Endbenutzer nur generische Texte wie „Ihre Organisation lässt den Zugriff nicht zu.“ – nicht sehr hilfreich. Also im nächsten Schritt…
2. Sign-In Logs prüfen: Als Entra-Admin ab ins Azure AD Portal -> Anmeldungen (Sign-in logs). Filtern nach dem betreffenden User und Zeit. Dort sieht man den Eintrag mit Status „Interrupted“ oder „Failed“, und einem Conditional Access Abschnitt. Dieser zeigt, welche Policies angewendet wurden und welche letztlich den Ausschlag gab. Beispiel: Policy „Block Legacy Auth“ = Matched, Result = Failure. Aha. Oder „Require Compliant Device = Not satisfied“. Mit dieser Info kennen Sie den Grund.
3. Policy-Details interpretieren: Nun wissen Sie, welche Richtlinie zugeschlagen hat. Nächste Frage: War das korrekt so, oder ein Fehlalarm? Vielleicht war der Benutzer mit einem neuen Handy online, das noch nicht registriert ist – und unsere Policy hat es zu Recht blockiert. Lösung wäre dann, dem Benutzer zu helfen, sein Gerät compliant zu machen. Oder aber: Die Policy hat überreagiert – z.B. weil wir die IP unseres neuen Büros noch nicht als intern markiert haben, wurden alle dort geblockt. Dann heißt es: Policy ändern (IP hinzufügen) und alle können wieder rein.
4. Maßnahme umsetzen & dokumentieren: Haben Sie eine Policy angepasst oder ausnahmsweise deaktiviert, vergessen Sie nicht, das im Policy-Register zu vermerken und ggf. die Governance-Schleife einzuhalten (im Notfall darf man natürlich sofort handeln, aber später sollte man es im Change-Log nachtragen). Dem Benutzer kommunizieren, was Phase ist: „Wir haben gerade eine neue Sicherheitsrichtlinie, deshalb gab’s die Sperre. Jetzt sollten Sie wieder Zugriff haben – und wir haben gelernt, dass wir Ihr Szenario beim nächsten Mal vorher berücksichtigen.“ Transparenz schafft hier Akzeptanz.
5. Langfristige Lösung ableiten: Ein Einzelfall kann Hinweise geben für generelle Verbesserungen. Wenn z.B. viele mobile Mitarbeiter plötzlich Probleme melden, weil sie ständig MFA machen müssen, könnte man überlegen: Liegt’s an einer zu kurzen Session-Lifetime? Müssten wir „Remember MFA“ länger setzen oder CAE feintunen? Wenn ein bestimmtes altes Tool regelmäßig an Policies scheitert – besser ersetzen, statt ewig Ausnahmen zu pflegen.

Tool-Tipp: Nutzen Sie auch das „What If“ im Portal (unter Conditional Access -> WhatIf): Damit können Sie im Vorfeld testen, ob ein hypothetischer Login von Benutzer X, Standort Y, Gerät Z zugelassen würde oder nicht – ohne es wirklich zu blockieren. Das hilft bei komplexen Policy-Setups enorm, um zu verstehen, welche Richtlinien greifen würden.

Kontinuierlicher Betrieb & Review-Strategie

Im Betrieb von Conditional Access gibt es zwei große Aufgabenbereiche: proaktiv warten und reaktiv optimieren.

Proaktiv / Wartung:

• Regelmäßige Policy-Reviews: Wie schon im Governance-Teil erwähnt, sollte ein fester Turnus etabliert sein, um alle Richtlinien zu überprüfen. Schauen Sie z.B. vierteljährlich: Sind die benutzten Bedingungen noch aktuell? (Vielleicht gibt’s inzwischen neue Named Locations, neue Gerätetypen etc.) Gab es Microsoft-Updates, die eine Policy überflüssig machen? (Beispiel: Irgendwann ist Legacy Auth komplett von Microsoft deaktiviert – dann braucht man die Block-Policy evtl. nicht mehr, in 2025 ist es größtenteils schon so weit.)
• Logs und Reports durchgehen: Mindestens wöchentlich einen Blick in die Sign-In Logs werfen – speziell auf Fehler und Blockierungen. Gibt es wiederkehrende Muster? Z.B. Nutzer aus Abteilung X werden häufig blockiert wegen Gerät Compliance – eventuell braucht diese Abteilung eine alternative Lösung (wenn deren Geräte nicht Intune-managed werden können). Oder viele versuchte Logins aus Ausland, geblockt: Ggf. Security Team informieren, da passiert Reconnaissance.
• Lizenz und Feature-Monitoring: Stellen Sie sicher, dass ausreichend Lizenzen vorhanden sind, gerade wenn Mitarbeiterzahlen steigen oder mehr Gäste aktiv sind. Prüfen Sie auch Azure AD News: z.B. wenn „Token Protection“ GA wird, könnte man erwägen, das zusätzlich zu aktivieren. Oder wenn Microsoft eine depreciation ankündigt, muss man reagieren (etwa haben sie früher „Baseline Policies“ abgekündigt zugunsten von Security Defaults/CA Templates – so etwas sollte man nicht verpassen).
• Notfallübungen: Es mag ungewöhnlich klingen, aber man kann mal simulieren: Was tun wir, wenn alle Admins ausgesperrt sind? Hat jeder im Team Zugriff auf die Notfallkonto-Details? Funktioniert der Prozess? Solche Übungen (ähnlich wie Feueralarm-Proben) sorgen dafür, dass im echten Ernstfall keine Panik ausbricht und jeder weiß, was zu tun ist.

Reaktiv / Optimierung:

• Auf neue Geschäftsanforderungen reagieren: Conditional Access muss mit dem Unternehmen mitwachsen. Neue Cloud-App eingeführt? – Nicht vergessen, in die CA-Abdeckung aufzunehmen! (Zur Not temporär „alles außer diese App blockieren“-Policy als Lückenfüller, bis man sie integriert hat.) Home-Office-Anteil steigt? – Vielleicht Standortabhängigkeiten überdenken oder mehr auf Device Trust setzen. Flexibilität ist Trumpf.
• Vorfallsanalyse: Wenn doch mal etwas passiert – z.B. ein kompromittierter Account, der trotz CA Mist bauen konnte – dann unbedingt Lesson Learned: Wo war die Lücke? Muss eine Policy verschärft werden (z.B. bisher wurde bei Risky Sign-In nur gewarnt, künftig direkt blockieren)? Jeder sicherheitsrelevante Vorfall sollte daraufhin überprüft werden, ob CA ihn hätte verhindern können oder ob es umgangen wurde. Dann anpassen.
• Benutzer-Feedback ernstnehmen: Manchmal melden Nutzer Friktionen, die in den Logs nicht offensichtlich sind. Z.B.: „Jeden Montag muss ich mich zig Mal neu anmelden“ – könnte an einer zu kurzen Sign-in Frequency liegen. Oder „Unsere externen Berater können nicht aufs WLAN-Gästenetz und daher CA nicht erfüllen“ – vielleicht muss man ihnen einen Weg über Conditional Access Guest-Exclusion bieten oder einen Managed Device Loaner. Solche Hinweise helfen, Policies lebensnah zu justieren.
• Technische Weiterentwicklung: Mit der Zeit könnten bestimmte Policies durch bessere ersetzt werden. Beispiel: Anfangs nutzt man IP-Blocklisten, später stellt man auf „vertrauenswürdige Geräte mit Token Protection“ um, was IP-Filter teilweise überflüssig macht. Bleiben Sie offen für Refactoring Ihrer CA-Umgebung. Auch können ehemals getrennte Policies zusammengefasst werden, wenn das die Übersicht verbessert (oder umgekehrt, eine Monster-Policy aufteilen, um flexibler zu steuern).

Zuletzt: Dokumentation aktuell halten! Nichts ist schlimmer als veraltete Doku. Wenn Sie im Betrieb Änderungen machen, sofort ins Policy-Register eintragen und ggf. betroffene Prozessdokumente anpassen. Dann greifen auch neue Teammitglieder oder Auditoren nicht auf falsche Informationen zu.

Betrieb und Fehlersuche bei Conditional Access erfordern ein gewisses Maß an Detektivarbeit, aber mit sauberem Vorgehen und regelmäßiger Pflege wird das System zum zuverlässigen Wächter, der meist unauffällig im Hintergrund läuft. Die Nutzer werden es kaum merken – außer dass selten mal ein „Zugriff verweigert“ auftaucht, der aber genau die Angriffe abhält, die man verhindern wollte.

5. Lizenzierung

Security gibt es nicht umsonst – das gilt auch für Conditional Access. Welche Lizenzen benötigt man und welche Funktionen stehen in den verschiedenen Editions (Free, P1, P2) zur Verfügung? In diesem Abschnitt schaffen wir Klarheit, inklusive einer kompakten Tabelle. Ebenso werfen wir einen Blick auf Microsoft 365 Business und externe Benutzer (B2B) in Bezug auf Lizenzen.

Zunächst die Grundlagen: Microsoft Entra ID (Azure AD) gibt es in mehreren Ausbaustufen: – Entra ID Free: Basisfunktionen für Identitätsverwaltung – ohne anpassbare Conditional-Access-Policies. Nur die Security Defaults (MFA für Admins, Benutzer-Registrierung etc.) stehen als rudimentärer Schutz zur Verfügung. Für kleine Umgebungen oder Testtenants okay, aber nicht granular. – Entra ID Premium P1: Voller Zugang zu Conditional Access! Diese Lizenzstufe (oft enthalten in Enterprise-Mobility+Security E3 oder Microsoft 365 E3, ebenso im Microsoft 365 Business Premium für KMU) ermöglicht benutzerdefinierte CA-Richtlinien, MFA per Richtlinie und weitere Identity-Funktionen (wie Azure AD Join, Intune Device Compliance, Dynamic Groups usw.). P1 ist in den meisten Fällen der Mindeststandard, wenn man CA sinnvoll nutzen will. – Entra ID Premium P2: Enthält alles von P1 und ergänzt Identity Protection (Risiko-basierte Steuerung) und Identity Governance-Features (Access Reviews, PIM – Privileged Identity Management). P2 ist oft in Microsoft 365 E5 enthalten oder als Add-on (EMS E5). Für Conditional Access bedeutet P2 vor allem, dass man Benutzerrisiko/Anmelderisiko als Condition nutzen kann und Tools für automatische Reaktionen auf erkannte Risiken hat. PIM erlaubt Just-in-Time Adminrechte – auch wichtig, aber tangiert CA nur indirekt (man könnte z.B. CA-Regeln auf PIM-aktivierte Sessions abstimmen).

Nachfolgend eine Übersicht ausgewählter Funktionen vs. Lizenzlevel:

Funktion/Feature	Entra ID Free	Premium P1	Premium P2
Benutzerdefinierte Conditional-Access Policies	❌ (nicht verfügbar) <br>(nur Security Defaults)	✅ Ja	✅ Ja
Multi-Faktor-Authentifizierung (MFA)	✅ Per User (manuell pro Konto oder via Security Defaults) <br>❌ keine CA-basierte Steuerung	✅ CA-gestützt, inkl. MFA via App, FIDO, SMS etc.	✅ wie P1
Named Locations (Standortbedingungen)	❌	✅	✅
Geräte-basiert (Compliant/Hybrid Join)	❌	✅ Erfordert Intune für Compliance	✅
Device Filter (nach Gerätetyp/Eigenschaften)	❌	✅	✅
Anwendungsbezogene Policies	❌	✅ z.B. nur für bestimmte Azure AD-Apps	✅
Session Controls (App enforced, limited)	❌	✅ Basis (z.B. App-enforced Restrictions mit SharePoint) <br>(MCAS Shadow-IT Discovery inkl.)	✅ wie P1
Defender for Cloud Apps Integration	❌	⚠️ Teilweise – (CASB Cloud Discovery ist inkl., aber volle CASB-Proxy-Funktionen erfordern separate Lizenz oder E5)	⚠️ Teilweise
Terms of Use (Nutzungsbedingungen)	❌	✅	✅
Benutzerrisiko als Condition	❌	❌	✅ Identity Protection Risk-Level (hoch, mittel) nutzbar
Anmelderisiko als Condition	❌	❌	✅
Require Password Change (bei Risk)	❌	❌	✅
Privileged Identity Management (PIM)	❌	❌	✅ (P2 beinhaltet PIM für JIT-Adminrechte)
Access Reviews, Entitlement Mgmt	❌	❌	✅ (Teil von Entra ID Governance Add-On/P2)
Authentifizierungsstärken (z.B. nur FIDO)	❌	✅ Definition und Einsatz von Auth. Strength in CA	✅
Token Protection (Token an Gerät binden)	❌	✅ (Preview, P1 ausreichend laut MS)	✅
Continuous Access Evaluation (CAE)	⚙️ Automatisch für unterstützte Apps	⚙️ Automatisch	⚙️ Automatisch
SLA & Support	⭕ Keine Verfügbarkeits-SLA	✔️ 99,9% SLA, Support inklusive	✔️ 99,9% SLA, erweiterter Support mit E5

(Legende: ✅ = Verfügbar, ❌ = Nicht verfügbar, ⚠️ = eingeschränkt/mit zusätzlichem Produkt, ⚙️ = Feature greift unabhängig von Lizenz, ⭕ = vorhanden mit Einschränkungen)

Ein paar Erläuterungen zur Tabelle: – Security Defaults: In Entra ID Free gibt es die vordefinierten Security Defaults (MFA für Admins, Legacy Auth off etc.), aber man kann keine eigenen Policies anlegen. Für individuelle CA-Szenarien braucht es also P1. – Defender for Cloud Apps (MCAS): P1-Lizenz umfasst Cloud App Discovery (Schatten-IT via Logfiles) und erlaubt die Nutzung der Conditional Access Session Controls (z.B. „Use app enforced restrictions“ für SharePoint). ABER: Die volle MCAS-Funktionalität (eigene Session Policies definieren, Echtzeitkontrolle für beliebige Apps) erfordert eine separate Lizenz (enthalten in M365 E5 oder als Add-on „Defender for Cloud Apps“). D.h. mit P1 kann man die von Microsoft vorgesehenen Integrationen nutzen, aber keine freien eigenen Proxy-Regeln erstellen. – CAE (Continuous Access Eval): Das ist kein lizenzpflichtiges Feature, sondern generelles Platform-Feature. Heißt: Wenn Ihre App und Entra ID CAE unterstützen, profitieren Sie automatisch – z.B. ein abgelöschter User wird fast instant aus Teams gekegelt. Man kann CAE nicht „kaufen“, es ist überall an, wo technisch möglich. – Microsoft 365 Business Premium: Das Produkt für kleinere Unternehmen (<300 Benutzer) beinhaltet im Grunde Entra ID P1 Features, inkl. Conditional Access und Intune. In obiger Tabelle also vergleichbar mit P1 (Business Premium entspricht grob EMS E3). – Lizenzierung pro User: Jedes Konto, das von einer Conditional-Access-Policy betroffen ist, sollte lizenziert sein. Für interne Nutzer ist das klar (jedem einen P1/P2 zuweisen oder über M365-Pakete abdecken). Externe B2B-Gäste: Hier greift ein spezielles Modell – Microsoft erlaubt die Nutzung von Premium-Funktionen für Gäste ohne pro Gast Lizenz, solange das verhältnismäßig ist. Früher galt die 1:5-Regel (ein lizensierter User deckt 5 Gäste ab); heute (seit 2021) gibt es das MAU-Modell: Bis zu 50.000 monatlich aktive Gäste sind in P1/P2 umsonst dabei, darüber hinaus fallen minimale Kosten pro zusätzlichem Gast-Login an (Größenordnung 0,00x €). Für die meisten Unternehmen heißt das de facto: Man kann Conditional Access auch auf Gäste anwenden, ohne extra Lizenzen zu kaufen – sofern man eh die internen Nutzer lizenziert hat. Achtung: Externe Nutzer aus anderen Entra tenants mit eigenen Lizenzen zählen nicht zu Ihrem Budget; und B2C (Customer Identities) ist nochmal ein separates Thema.

Zusammengefasst: Um Conditional Access voll auszukosten, benötigt man mindestens Azure AD / Entra ID P1. P2 bringt zusätzliche Sicherheit durch Identity Protection und Governance – sehr wertvoll für größere, regulierte Umgebungen, aber nicht zwingend Voraussetzung für die meisten CA-Grundfunktionen. Viele Unternehmen fahren gut mit einer Mischung: z.B. E3 (P1) für den Großteil und ein paar E5 (P2) für die Admins/Sensitive User, um risikobasierte Policies nutzen zu können. Wichtig ist, sich der Grenzen bewusst zu sein: Ohne P1 keine granularen Policies; mit P1 aber ohne P2 kein automatisches Risk-Blocking. Man kann jedoch auch mit P1 schon vieles kompensieren (z.B. via sign-in Analyse und manueller Reaktion).

Und noch ein Tipp: Lizenz-Audit regelmäßig machen! Conditional Access policies werden nicht automatisch deaktiviert, wenn Lizenzen wegfallen – sie laufen im „Grace State“, aber man kann nichts ändern. Das gibt Zeit zum Nachlizenzieren, sollte aber nicht übersehen werden. Also: In Entra ID Admin Center > Lizenzen immer mal prüfen, ob alle benötigten Abos aktiv sind.

6. Spezielle Szenarien & Best Practices

Jede Umgebung hat ihre Eigenheiten. In diesem Kapitel betrachten wir einige besondere Szenarien und wie man Conditional Access dort optimal einsetzt. Dazu gehören typische Herausforderungen wie VDI-Umgebungen, die Zusammenarbeit mit externen Partnern (B2B) und der Schutz vor Token-Diebstahl. Außerdem fließen hier noch ein paar allgemeine Best Practices ein, die in den vorherigen Abschnitten keinen Platz fanden.

Conditional Access im VDI- und Shared-Desktop-Umfeld

Virtual Desktop Infrastructure (VDI) – also Remote-Desktop-Farmen, Citrix-Umgebungen oder Azure Virtual Desktop – stellen eine besondere Herausforderung dar. Oft nutzen hier mehrere User denselben Host oder es werden dynamisch generierte VM-Instanzen genutzt. Wie greift CA hier?

Problemstellung: Conditional Access sieht primär die Benutzeridentität und gewisse Gerätemerkmale. In einem Shared-VDI sind aber mehrere Nutzer vom selben Gerät (bzw. derselben VM) aus aktiv. Zudem sind VDI-Maschinen häufig nicht als individuelle Geräte in Azure AD registriert – ein Windows 10 Multi-Session z.B. kann nicht einfach Intune-compliant werden pro Nutzer. Dadurch können strikte Device-Regeln (wie „muss compliant sein“) viele VDI-Szenarien aussperren.

Best Practices für VDI:

• Hybrid Join der VDI-Hosts: Wenn möglich, die virtuellen Desktop-Maschinen Hybrid Azure AD Joinen (also ins lokale AD und per Azure AD Connect ins Entra registrieren). So erkennt Conditional Access zumindest „Device is Hybrid Joined = true“. In einer Policy kann man dann evtl. diese Bedingung als Zugangsweg erlauben. Beispiel: „Erlaube Zugriff von Hybrid-joined Geräten ODER require MFA“ – die VDI-Maschine erfüllt Hybrid, der Nutzer muss kein MFA machen, andere Geräte müssten MFA.
• VDI-IPs als vertrauenswürdig einstufen: Falls die VDI-Farm an einem bekannten Standort (z.B. Firmen-Rechenzentrum oder Azure Region) läuft, kann man deren ausgehende IP-Adressen als Named Location (Trusted) definieren. Anschließend könnten Policies so gestaltet werden, dass Logins von diesen internen VDI-IPs weniger Einschränkungen unterliegen. Beispiel: „Wenn Anmeldung von Trusted IP (VDI-Range), dann kein Geräte-Compliance-Zwang“ – weil man davon ausgeht, dass die VDI intern schon abgesichert ist. Aber Vorsicht: Das sollte man nur tun, wenn man der VDI-Umgebung sehr vertraut; Zero Trust puristen würden argumentieren, IP als Trust ist riskant.
• Ausschlüsse oder spezielle VDI-Policy: In manchen Fällen lohnt es sich, eine separate CA-Richtlinie für VDI-Nutzer einzuführen. Beispielsweise wenn bestimmte Cloud-Apps ausschließlich über den virtuellen Desktop genutzt werden sollen. Man könnte dann sagen: Blockiere Zugriff auf App X von allen nicht-VDI-Geräten. Wie erkennt man VDI? Möglicher Hack: Gerätefilter, wenn z.B. alle VDI-VMs bestimmten Hostnamen oder Prefix haben. In Azure Virtual Desktop gibt es z.B. Gerätetags („AzureVirtualDesktop“ als trustType), die man in CA filtern kann. So könnte eine Policy definieren: „Falls Gerät != AzureVirtualDesktop, dann App X blockieren“. Die Nutzer müssen dann via VDI rein, wo ggf. weitere Schutzmechanismen aktiv sind.
• MFA in VDI: Interessant ist auch das MFA-Erlebnis in VDI. Wenn jemand innerhalb des virtuellen Desktops auf eine cloud-App zugreift und MFA gefordert ist, muss er das eventuell auf demselben Gerät bestätigen – was doof ist, wenn der virtuelle Desktop im Vollbild läuft und man das Smartphone braucht. Hier kann es sinnvoll sein, in VDI-Umgebungen verstärkt auf Smartcard oder FIDO2-Keys zu setzen, die ins Session-Host durchgereicht werden können, um MFA zu erfüllen ohne Zweitgerät. Ist natürlich kein reines CA-Thema, aber praktikabel.
• Azure Virtual Desktop spezifisch: Microsoft hat Anleitungen, wie man Azure AD Conditional Access mit Azure Virtual Desktop (AVD) einsetzt, bspw. um MFA vor dem Start einer Sitzung zu verlangen. Hier wird die AVD-Verbindungsanfrage selbst (Client-App) mit CA belegt. Wenn man AVD als zentrale Lösung einsetzt, ist es sinnvoll, mindestens MFA via CA davorzuschalten – so kommt kein Unbefugter überhaupt in eine Session.

Fazit für VDI: Dokumentieren Sie in Ihrer CA-Strategie klar, wie mit virtuellen Desktops umgegangen wird. Wenn Standard-Policies wie „Device must be compliant“ gelten, braucht es für VDI oft Ausnahmen oder Sonderbehandlungen. Die Kunst ist, eine Balance zu finden: VDI-Umgebungen sind ja oft dazu da, ein sicheres, kontrolliertes Arbeitsumfeld zu bieten. Man will sie also eher als vertrauenswürdig einstufen, darf aber nicht blind alle Regeln ignorieren, sonst könnten sie zum Schlupfloch werden. Ein guter Ansatz ist meist: VDI intern vertrauen, aber absichern – z.B. durch Integration in AD, restriktive Netzwerksegmente, und ggf. separate CA-Regeln, die Zugriffe auf sensibelste Daten außerhalb der VDI blockieren.

B2B-Zusammenarbeit & Gastbenutzer

Die moderne Arbeitswelt ist vernetzt: Externe Partner, Lieferanten oder Kunden loggen sich als Gastnutzer in Ihrem Tenant ein, um auf Teams, SharePoint oder Anwendungen zuzugreifen. Conditional Access sollte diese B2B-User nicht vergessen – schließlich können kompromittierte Partner-Accounts genauso Schaden anrichten.

Herausforderungen mit Gästen: – Gastnutzer stammen oft aus anderen Organisationen (mit eigenem Azure AD) oder sind „nur“ per E-Mail eingeladen (Microsoft-Konto oder OTP). Man hat also in der Regel keine Kontrolle über deren Endgeräte oder MFA-Vorkehrungen. Eine normale CA-Policy „Gerät muss compliant sein“ würde nahezu alle Gäste aussperren, da deren Geräte nicht in Ihrer Intune gemanagt sind. – Andererseits will man die Zusammenarbeit nicht unnötig erschweren. Wenn der Geschäftspartner schon bei sich MFA einsetzt, wäre es ärgerlich, ihn nochmal bei jedem Login durch zig Reifen springen zu lassen.

Best Practices für B2B:

• Separate Gast-Policies: Definieren Sie Conditional Access Richtlinien gezielt für „Alle Gast- und externen Benutzer“ (dies kann man im Nutzer-Ziel auswählen). Zum Beispiel: „Gäste müssen immer MFA machen“ – so ist sichergestellt, dass egal wer da von extern kommt, mindestens eine MFA-Hürde vorhanden ist. Dies greift sogar, wenn der Gast aus einem Tenant kommt, wo er vielleicht kein MFA hatte (dann wird er via Ihrem Tenant gezwungen, eine OTP per Handy einzugeben).
• Cross-Tenant MFA Trust: Microsoft bietet in Entra ID Cross-tenant Access Settings. Darüber können Sie konfigurieren, ob Sie MFA-Bestätigungen anderer Tenants anerkennen. Beispiel: Ihr Partner hat eigenen Azure AD mit MFA, und dessen Admin hat eingestellt, dass er E-MFA-Claims an externe weitergibt. Sie können nun in Ihren Einstellungen sagen: „Vertraue Contoso AG Tenant, was MFA angeht“. Dann passiert folgendes: Ihr Gast loggt sich mit seinem Azure AD Account ein, Microsoft sieht, dass er dort MFA bereits erfüllt hat -> Ihr Conditional Access könnte das als ausreichend akzeptieren, ohne erneut eine Abfrage zu triggern. So vermeidet man doppelte MFA-Schleifen für externe, sofern man dem anderen Tenant vertraut. (Das sollte man natürlich nur für Unternehmen machen, von denen man weiß, dass deren MFA-Policy robust ist.)
• Gerätebedingungen vermeiden für Gäste: In Standard-Policies sollte man Gastkonten ausschließen, wenn sie Bedingungen enthalten, die externe nicht erfüllen können (compliant device, hybrid join etc.). Alternativ, wenn man Gäste einschließen will, muss man andere Controls wählen: z.B. statt „compliant Gerät“ dann lieber „Gäste dürfen nur via Web“ oder so.
• App-Limits für Gäste: Eine gute Praxis: Begrenzen Sie, auf welche Anwendungen Gäste zugreifen können. Azure AD bietet eine Einstellung „Gäste haben nur Zugriff auf explizit freigegebene Apps“ – nutzen! Und mittels CA kann man zusätzlich definieren, dass z.B. kritische Applikationen nur für interne Konten erlaubt sind (Policy: Alle Gäste -> App XYZ -> Block). So minimiert man das Risiko, dass ein Externer auf sensible Bereiche kommt.
• Session Restriktionen für Gäste: Ähnlich wie bei BYOD kann man Gästen erlauben, ins SharePoint zu schauen, aber über Conditional Access + MCAS Session Control z.B. Downloads blockieren oder Dateien mit Wasserzeichen versehen. Microsoft erlaubt inzwischen, was Gäste innerhalb von Teams/SharePoint dürfen, sehr fein einzustellen – CA kann hier als Trigger dienen (Gast = nur Web, keine Extraktion).
• B2B Direct Connect & Trust Frameworks: Für fortgeschrittene Szenarien (große Partnernetzwerke) gibt es auch die Möglichkeit, via Entra Cross-Tenant Policies bestimmte MFA oder Compliant-Device-Claims gegenseitig anzuerkennen. Beispiel: Zwei Firmen stimmen bilateral zu, nur Gerätezugriff zu erlauben, die jeweils in Intune compliant sind – und tauschen dafür CA-Signale aus. Solche Konstellationen sind komplex, aber Entra ID P2 und Verified ID Features könnten hier helfen, Vertrauen herzustellen ohne identische Policies zu duplizieren. Im Kern sollte man aber realistisch sein: Meist behandelt man Gäste wie untrusted Devices und schützt dementsprechend.

Lizenzthema Gäste: Wie zuvor erwähnt, müssen Gäste nicht einzeln lizenziert werden, solange Ihre internen User lizenziert sind (bis 50k MAU free). Das heißt, Sie können ruhig P1/P2 Policies auf Gäste anwenden, ohne jedem Externen eine P1 zu kaufen. Das wirtschaftliche Argument, externe dann auszuklammern, fällt also weg – nutzen Sie lieber CA konsequent, um auch die externen Zugänge abzusichern.

Merke: Die größte Schwachstelle in vielen Cloud-Setups sind nicht die eigenen Mitarbeiter, sondern oft ein gehackter Partner-Account, der als Gast Zugriff auf kritische Daten hat (man denke an Fälle, wo ein Dienstleister-Konto den Angriff ermöglichte). Conditional Access ist Ihr Freund, um dieses Risiko deutlich zu senken: Immer MFA fordern, Zugriff einschränken, Logging an – auch (oder gerade) bei Gästen.

Schutz vor Token-Diebstahl & Session-Hijacking

„Passwort geklaut? Egal, wir haben MFA.“ – Das denken viele nach MFA-Einführung. Doch Kriminelle schlafen nicht: Sie umgehen MFA zunehmend, indem sie Session Tokens stehlen. Bei Phishing-Angriffen kommen sog. Man-in-the-Middle-Kits zum Einsatz, die dem Benutzer die echte Login-Seite vorsetzen, MFA abfragen – und im Hintergrund den erzeugten Session-Cookie abgreifen. Mit diesem Token kann der Angreifer dann ohne Passwort und MFA auf die Cloud-Ressourcen zugreifen, solange das Token gültig ist. Auch Malware auf einem infizierten Gerät könnte Tokens aus dem Browser oder aus Speicher ziehen (Session-Hijacking). Wie kann Conditional Access hier helfen?

1. Gerät als Schlüssel – Token an Hardware binden: Microsoft hat reagiert und ein CA-Feature namens Token Protection eingeführt (aktuell Preview, P1). Damit lassen sich Refresh Tokens an ein bestimmtes Gerät koppeln. Konkret: Ein Benutzer meldet sich auf seinem Windows 10/11 PC an, Azure AD erstellt einen Primary Refresh Token (PRT), der mit Geräteschlüsseln signiert ist. Ist Token Protection-Policy aktiv, akzeptiert Azure AD nur noch dieses Gerät für weitere Access Tokens. Wenn ein Angreifer nun den Token klaut und auf seinem eigenen Rechner benutzt, schlägt die Token-Prüfung fehl – Zugriff verweigert. Praktisch bedeutet das: Der gestohlene Token ist wertlos außerhalb des Geräts. Aktuell geht das für Exchange, SharePoint, Teams und einige Client-Apps (Unterstützung muss gegeben sein). Best Practice: Token Protection aktivieren für hochkritische Ressourcen, sobald GA – besonders, wenn man viele persistente Sessions hat (z.B. Win10, Outlook bleibt offen etc.). Allerdings: Voraussetzungen wie Azure AD Join und TPM am Gerät müssen erfüllt sein, sonst blockiert man sich womöglich selbst (daher im Rollout vorsichtig angehen, erstmal Audit-Mode etc.).

2. Sitzungsdauer und erneute Prüfung: Conditional Access ermöglicht über Session Controls z.B. die Sign-in Frequency festzulegen. Wenn man Angst vor Session-Hijacking hat, könnte man Tokens kürzer leben lassen – etwa alle 4 Stunden muss der Nutzer sich neu auth. Das reduziert die Zeit, die ein gestohlener Token nutzbar ist. Allerdings nervt es Benutzer bei zu kurzer Frequenz enorm, hier gilt es Abwägung zu treffen. Continuous Access Evaluation (CAE), wie erwähnt, tritt automatisch bei gewissen Events in Kraft (Account disabled, Passwort geändert etc.). Stellen Sie sicher, dass CAE bei Ihnen funktioniert (Clients updaten etc.), denn so wird z.B. bei einem gemeldeten Token-Diebstahl (Sie erkennen z.B. ungewöhnliche Session) ein „Revoke Session“ schnell wirksam.

3. Risk-Based CA (P2): Identity Protection erkennt oft einen Token-Diebstahl daran, dass plötzlich ein User gleichzeitig von zwei weit entfernten Orten aktiv ist (Impossible Travel). Das erzeugt einen hohen Anmelderisiko-Wert. Mit P2-Lizenz könnte man diese high-risk Sign-ins blockieren oder zumindest MFA erzwingen. Tipp: Falls kein P2 vorhanden, dennoch Alerts einrichten (via Azure AD Diagnostic Settings + Log Analytics) – so kann man manuell reagieren. Aber mit P2 > CA-Policy: „Blockiere Sign-ins mit high risk“ ist der Automatismus, der sowas direkt unterbindet.

4. Phishing-resistente MFA erzwingen: Die meisten Token-Diebstahl-Angriffe erfordern, dass der Benutzer seine MFA eingibt auf der Fake-Seite. Tools wie Evilginx können Standard-MFA (Push, OTP) abfangen. Doch Phishing-resistente Methoden wie FIDO2 oder Certificate-based Auth sind schwerer zu proxyn. Wenn man also z.B. via CA AuthN-Strength sagt „Admin-Logins nur mit FIDO2“, dann wird es für Angreifer extrem aufwändig, diese Session mitzuschneiden. Sprich: Je stärker der MFA-Faktor, desto geringer die Token-Klau-Gefahr. Das ist keine Garantie, aber erhöht die Sicherheit massiv.

5. Gerätestatus und Netzbedingungen nutzen: Ein gestohlener Token wird oft von einem anderen Gerät/OS benutzt als dem legitimen. Conditional Access kann via Device Filter oder „Hybrid Join“-Status hier indirekt wirken: Wenn z.B. man voraussetzt „Access nur von Azure AD registered Geräten“, dann fällt der Hacker mit seinem nicht-registrierten Rechner durch. Ebenso kann Location helfen: Der gestohlene Token kommt evtl. von einer fremden IP – wenn man „vertrauenswürdige Standorte erforderlich“ hat, wird er geblockt. Das greift natürlich nur in manchen Szenarien (Angreifer ist wirklich woanders; bei Evilginx oft im Ausland gehostet – das kann man mit Geoblocking abfangen).

6. Warnmechanismen & Benutzer sensibilisieren: Zwar keine CA-Funktion, aber als Best Practice: Schalten Sie MFA-Nummer-Matching und zusätzliche Kontextinfos ein (Standard seit 2023). Dann sieht der User auf seiner Auth-App, wo der Anmeldeversuch herkommt. Klickt er „Nein, war nicht ich“, markiert Azure AD das als hohes Risiko und blockiert ggf. automatisch (mit P2). Die beste Technik bringt nichts, wenn Nutzer unbedarft jeden MFA Prompt abnicken – deswegen Awareness und die Nutzung solcher Sicherheitsfeatures (auch „MFA als Push nur mit Code“ etc.) sind entscheidend.

Fazit Token-Diebstahl: Conditional Access entwickelt sich stetig weiter, um auch Sitzungen abzusichern, nicht nur die initiale Anmeldung. Mit Token Protection steht ein mächtiges Tool vor der Tür, das Token Replay Attacken deutlich erschwert. Bis zur vollständigen Verfügbarkeit gilt: Risiko-Policies, kurze Sessions, starke MFA und genaues Hinsehen (Logs) sind Ihre Freunde. Kein System ist 100% gegen Session Hijacking gefeit, aber Sie können den Angreifern das Leben so schwer wie möglich machen – sodass sie sich lieber ein leichteres Opfer suchen.

Weitere Best Practices & Tipps

Zum Abschluss dieses Kapitels noch ein paar gemischte Hinweise, die anderswo nicht passten:

• Emergency Access Routine einüben: Der Notfall-Admin sollte regelmäßig verwendet werden, um sicherzustellen, dass er funktioniert. Viele richten den Account ein und merken erst im Ernstfall, dass das Passwort abgelaufen ist oder keiner die Smartcard dafür findet. Planen Sie z.B. halbjährlich einen Controlled Breakglass-Test: mit dem Konto einloggen, schauen ob’s klappt, dann Kennwort ändern und wieder sicher weglegen.
• „Monitor only“-Policen: Wussten Sie, dass Sie CA-Richtlinien auch dauerhaft im Report-Only belassen können, um Dinge zu beobachten? Beispielsweise könnten Sie eine Policy haben „Report if login not from compliant device“. So sehen Sie im Log, wer alles unsichere Geräte nutzt, ohne gleich einzuschränken. Das kann man zur Entscheidungsfindung nutzen („Wir sehen 30% Logins sind von unmanaged Geräten – vielleicht nächstes Quartal diese 30% addressieren mit MAM/MFA“).
• Ausgeschlafene Benennung: Geben Sie Ihren CA-Policies sprechende Namen. Klingt trivial, ist aber Gold wert, wenn man Fehlersuche betreibt. Ein Name wie „#Block_LegacyAuth_all“ oder „MFA_all_users_except_breakglass“ hilft sofort zu kapieren was gemeint ist. Nutzen Sie Beschreibungstexte im Policy-Objekt für Details (man vergisst sonst nach 1 Jahr, was man sich dachte). Einige nutzen Prefixes wie „SEC-“ oder Nummern, um eine Sortierung zu simulieren – kann man machen, obwohl echte Priorität davon unabhängig ist.
• Nicht auf „alte Schule“ verlassen: Früher implementierte man manche Zugriffssteuern in ADFS oder Firewalls. Heute sollte man möglichst alles über Conditional Access lösen, sofern es Cloud-Apps betrifft. Doppelte Mechanismen stiften Verwirrung. Wenn z.B. ADFS noch IP-Blocking macht und Azure AD auch – dann pflegen Sie zwei Listen. Vereinfachen Sie: Langfristig ADFS ablösen oder zumindest die Policies auf einer Seite bündeln (meist Azure AD). Conditional Access kann vieles, was früher GPOs oder NetScaler machten – one control plane to rule them all.
• VDI + MFA z.B. RDP Gateway: Wenn VDI extern erreichbar ist, denken Sie an MFA dort. Indirekt Teil von CA-Strategie: Die Quelle von Cloud-Zugriffen sichern. Azure Virtual Desktop kann direkt mit Azure MFA geschützt werden (via CA), On-Prem RDS via Azure MFA NPS Extension etc. Das ist zwar nicht Conditional Access per se, aber rundet das Schutzkonzept ab, damit nicht über den Umweg VDI einer ins cloud-gesicherte System reinkommt.
• Keep an eye on Reports: Azure AD bietet einen speziellen Conditional Access Insights Report (wenn man Azure Monitor nutzt), der analysiert, welche Nutzer noch von keiner Policy erfasst sind, oder welche App eventuell ungeschützt ist. Solche Tools, oft in Preview, sollte man ausprobieren – sie geben Hinweise, wo Lücken sein könnten.
• Rückfall und Ausschluss-Strategie: Definieren Sie einen generellen Plan: Welche Konten sind in welcher Ausnahmegruppe? (z.B. Breakglass, evtl. einige Service Principals) und wie gehen wir mit neuen Apps um, solange kein CA greift? (z.B. Security Defaults anlassen bis CA fertig oder generell blocken bis freigegeben). Eine Policy „Block all apps unless…“ kann man in Erwägung ziehen für streng regulierte Umgebungen: Darin werden alle Cloud-Apps geblockt, außer diejenigen, die in anderen Policies ausdrücklich erlaubt sind. So fängt man „vergessene Apps“ ab. Ist aber komplex zu pflegen und nicht für jeden nötig.
• Collaboration mit anderen Teams: Conditional Access überschneidet sich mit SecOps (SIEM) und IT-Support. Stellen Sie sicher, dass das SOC über Risky Sign-ins Bescheid weiß (ggf. via Sentinel Connector) und dass der Helpdesk klare Knowledge Base Artikel hat („Wenn Nutzer X wegen CA blockiert: Schaut in Azure AD Logs, dann ggf. in Gruppe Y aufnehmen falls Ausnahme berechtigt“). So wird CA Teil der täglichen Betriebsprozesse und nicht als Fremdkörper gesehen.

Damit haben wir einen Rundumschlag durch Spezial- und Alltagsszenarien gemacht. Man sieht: Conditional Access ist kein starres Konstrukt, sondern verlangt immer wieder situative Entscheidungen. Aber genau das macht es so wertvoll – es ist ein lebendiges Werkzeug, das man an praktisch jede Sicherheitsanforderung anpassen kann.

7. Artefakte zum Mitnehmen

In einem umfangreichen Conditional-Access-Projekt entstehen nicht nur Policies in der Cloud, sondern auch handfeste Artefakte – Dokumente und Hilfsmittel, die Ihnen bei Einführung, Betrieb und Audit helfen. Hier sind einige wichtige „Mitnehmsel“ aus der Praxis:

• Policy-Register: Eine tabellarische Übersicht aller CA-Richtlinien. Typischer Inhalt pro Eintrag: Name der Policy, Zweck/Beschreibung, Ersteller/Owner, Gültigkeitsbereich (welche Benutzer/Apps betroffen), Controls (MFA, Block etc.), Datum der Einführung und letzte Änderung, sowie evtl. Verweis auf Genehmigung (Change Ticket Nummer). Dieses Register dient als zentrales Nachschlagewerk. Es hilft bei Team-Kommunikation („Schau in Register, Policy Nr. 12 erklärt, warum Gastzugriff blockiert wird“) und ist Gold wert für Audits. Tipp: Auch ausgeschaltete oder veraltete Policies nicht löschen, sondern im Register als inaktiv markieren – so bleibt die historische Nachvollziehbarkeit.
• RACI-Matrix: RACI steht für Responsible, Accountable, Consulted, Informed. Eine kleine Matrix für Conditional Access klärt, wer welche Verantwortung im Lebenszyklus der Policies trägt. Beispiel: Responsible (verantwortlich) könnte der Identity Architect sein, Accountable (rechenschaftspflichtig) der CISO oder IT-Leiter, Consulted könnten Vertreter der Fachbereiche sein (wenn Zugriffsregeln deren Apps betreffen), Informed der Helpdesk und das SOC. Diese Matrix stellt sicher, dass jeder weiß, welche Rolle er hat – etwa dass ein Helpdesk-Mitarbeiter nicht eigenmächtig Policies ändert (weil er weder R noch A ist), aber er wird informiert, wenn Änderungen live gehen (damit er auf Anfragen reagieren kann).
• Betriebs- und Notfall-Runbooks: Schriftliche Anleitungen für wiederkehrende oder kritische Prozeduren. Beispiele: „Schritte bei Aussperrung durch CA-Policy“ – enthält, wie man mit dem Breakglass-Konto die Policy disabled, wie man kommuniziert etc. Oder „Neuen Cloud-Dienst sicher anbinden“ – beschreibt, wie vorzugehen ist, wenn ein Fachbereich eine neue Anwendung will: Welche Conditional Access Fragen sind zu stellen (Benutzergruppe? Zugriff von extern erlaubt? etc.), wer genehmigt und wie man dann eine Policy erstellt. Weitere Runbooks könnten das Handling von False Positives beschreiben oder quartalsweiser Policy-Review (Checkliste was zu prüfen ist, wer eingeladen wird). Runbooks sind wichtig, um Wissen zu standardisieren, damit nicht alles an Einzelpersonen hängt.
• Risikoregister: Identity- und Zugriffsrisiken, die erkannt wurden, aber vielleicht (noch) nicht komplett mitigiert sind, sollten in ein Risikoregister (z.B. Bestandteil des allgemeinen IT-Risk-Registers) aufgenommen werden. Beispiel: „Risiko: Mögliche Umgehung von MFA über app passwords für Legacy Auth (falls ein Benutzer das heimlich nutzt)“ – Gegenmaßnahme: Überwachen und regelmäßig auswerten, langfristig Basic Auth abschalten. Oder „Risiko: Breakglass-Account Missbrauch“ – Maßnahme: Streng limitierter Zugang, regelmäßig Reporting ob genutzt. Solche Dinge gehören dokumentiert, damit sie nicht in Vergessenheit geraten und man gegenüber Revision/Prüfern zeigen kann: Wir kennen unsere Baustellen und bearbeiten sie.
• Kommunikationspakete: Nicht zu unterschätzen – sammeln Sie die E-Mails/Präsentationen, die Sie an die User geschickt haben, in einem Ordner. Die MFA-Ankündigung, die Anleitung „Wie registriere ich mich für MFA“, FAQs für Endbenutzer, etc. Das sind Artefakte, die bei späteren Rollouts (oder falls mal jemand neu ins Projekt kommt) sehr hilfreich sind. Sie lassen sich wiederverwenden oder dienen als Referenz, was kommuniziert wurde.
• Reports & Dashboards: Falls Sie eigene Dashboards erstellt haben (z.B. im Azure Monitor Workbook für sign-ins oder ein PowerBI, das die Logdaten auswertet), zählen auch die zu den Artefakten. Heben Sie diese Abfragen und Einstellungen auf. Oft will das Management quartalsweise einen Bericht – wer konnte das letzte Mal worauf nicht zugreifen etc. Wenn man einmal ein schönes Diagramm „Blocked sign-ins by country“ gebastelt hat, sollte man das pflegen.
• Schulungsnachweise: Wenn Admins oder Helpdesk in Conditional Access geschult wurden, kann man auch das festhalten (z.B. Teilnahmezertifikate oder interne Schulungsfolien). Im Audit-Fragenkatalog á la ISO 27001 kommt oft „Werden Administratoren regelmäßig geschult?“ – da kann man Bezug auf diese Unterlagen nehmen.

Diese Artefakte mögen nach Papierkram klingen, machen aber oft den Unterschied zwischen einem chaotischen und einem revisionssicheren Betrieb aus. Sie helfen, Wissen zu konservieren, und zeigen intern wie extern: Unsere Access Security ist nicht wild zusammengeklickt, sondern durchdacht, dokumentiert und gemanagt.

Tipp: Packen Sie die wichtigsten Dokumente (Policy-Register, RACI, Notfallverfahren) in einen kleinen „CA-Betriebshandbuch“-Ordner und hinterlegen Sie ihn an einem zentralen Ort (zugänglich auch im Notfall). So haben alle Verantwortlichen jederzeit Zugriff auf die relevanten Infos, auch wenn mal jemand ausfällt.

8. FAQ – Häufige Fragen aus der Praxis

In der Beratung zu Conditional Access begegnen einem immer wieder ähnliche Fragen. Im folgenden Abschnitt haben wir 15 praxisnahe FAQ zusammengestellt – natürlich mit klaren Antworten, ohne Umschweife.

Frage 1: „Wir haben Angst, uns selbst auszusperren. Was passiert, wenn kein Admin mehr reinkommt?“
Antwort: Für diesen Fall muss es ein Notfall-Admin-Konto geben, das von allen CA-Policies ausgenommen ist. Solange Sie dieses „Breakglass“-Konto haben und die Anmeldedaten sicher verwahren, können Sie sich nie vollständig aussperren – im Worst Case nutzen Sie dieses Konto, um die Policy wieder abzuschalten. Microsoft empfiehlt mindestens zwei solche Accounts. Außerdem sollten Änderungen immer erst mit Report-Only getestet werden. Absolute Notlösung, falls wirklich alles schiefging (und kein Notfallkonto existiert): Den Microsoft Support kontaktieren, die können im Hintergrund CA-Policies deaktivieren – aber das dauert und ist peinlich. Daher: vorausschauend handeln, dann sperrt man sich nicht aus.

Frage 2: „Wie kann ich Conditional Access Policies testen, bevor ich sie einschalte?“
Antwort: Nutzen Sie den Report-Only-Modus! Wenn Sie eine neue Policy erstellen, setzen Sie sie zunächst auf „Nur Bericht“. Dann können Sie im Entra-Portal unter „Anmeldungen“ sehen, welche Sign-ins hypothetisch blockiert/erfordert worden wären (die Policy erscheint mit „Report-only“ Hinweis). Auch das What-If-Tool im Conditional Access Bereich ist sehr hilfreich: Dort simulieren Sie, wie sich eine bestimmte Policy auf einen bestimmten User in einer bestimmten Situation auswirken würde. Nehmen Sie sich die Zeit zum Testen – es lohnt sich. Zusätzlich bietet es sich an, Policies zunächst nur auf eine kleine Pilotgruppe anzuwenden (z.B. IT-Team), bevor Sie „Alle Nutzer“ auswählen.

Frage 3: „Gelten Conditional-Access-Regeln auch für lokale On-Premises-Anwendungen?“
Antwort: Nur wenn diese Anwendungen an Azure AD angebunden sind. Conditional Access wirkt immer dann, wenn die Authentifizierung über Entra ID/Azure AD läuft. Für rein lokale Legacy-Anwendungen (z.B. ein altes Intranet ohne Azure AD Integration) greifen CA-Policies nicht. ABER: Sie können viele on-prem Apps via Azure AD Application Proxy oder SAML/OIDC-Integration „cloudfähig“ machen, dann profitieren sie ebenfalls von CA. Wenn Sie z.B. einen On-Prem-Webdienst über Azure AD veröffentlichen, kann dort MFA etc. erzwungen werden. Falls Sie noch ADFS nutzen: ADFS hat eigene Claims-Regeln – die sind von CA separat. Es empfiehlt sich langfristig, auf Azure AD Auth umzusteigen, um die einheitlichen CA-Policies nutzen zu können. Zusammengefasst: Nur Cloud-authentifizierte Sessions können von Conditional Access kontrolliert werden.

Frage 4: „Was machen wir mit alten Anwendungen oder Clients, die kein modernes Authentifizieren unterstützen?“
Antwort: Diese nennt man Legacy Authentication – und die ist Ihr Feind. Ideal ist, solche Anwendungen loszuwerden oder upzugraden. Falls das nicht geht (manches Gerät oder Dienst lässt sich nicht modernisieren), gibt es ein paar Optionen: – Nutzen Sie App-Kennwörter (App Passwords) als Übergangslösung. Das sind spezielle Passwörter, die anwendbar sind, wenn MFA aktiviert ist, aber natürlich unsicherer als echtes MFA. Microsoft erlaubt App Passwords nur, wenn ein Benutzer auf per-user MFA gesetzt ist (nicht bei CA-driven MFA). Das ist umständlich und sollte vermieden werden. – Besser: Isolieren Sie die Legacy-App. Zum Beispiel könnte man den Zugriff darauf auf ein bestimmtes Netzwerk segmentieren oder nur über einen speziellen Service Account erlauben, der streng limitiert ist. – Conditional Access Ausnahme: Sie könnten eine Policy machen „Block Legacy Auth für alle außer ServiceAccountXYZ“ und dann sehr genau überwachen, was dieser Account tut. Letztlich führt aber kein Weg daran vorbei: Legacy Auth muss weg. Microsoft hat die Unterstützung für Basic Auth bei Exchange Online 2022 eingestellt (abgeschaltet). Andere Dienste werden folgen. Jeder Tag, den Sie eine legacy App durchschleppen, ist ein Risiko. Falls es eine Client-App ist (z.B. alter Outlook 2010), überzeugen Sie die Nutzer, auf neuere Versionen umzusteigen – mit Verweis auf Sicherheitsrichtlinie. Notfalls mit technischem Druck (wenn’s nicht mehr geht, müssen sie wechseln).

Frage 5: „Wie handhaben wir Service Accounts, die sich nicht interaktiv anmelden können? Können die CA-Policies umgehen?“
Antwort: Nicht-interaktive Service Accounts (z.B. für Scripts, Anwendungen) haben tatsächlich Sonderstatus: Conditional Access greift standardmäßig auf Benutzer und interaktive Anmeldungen. Service Principals (App-Registrierungen) sind von User-basierten CA-Policies ausgenommen. Für sie gibt es (in Preview) Workload Identity CA Policies – damit kann man z.B. Token-Nutzung von Service Principals einschränken. Traditionelle Service-User (normale AD-Konten, die z.B. ein Synchronisierungstool nutzen) können von CA getroffen werden. Sie sollten solche Accounts nach Möglichkeit auf moderne Auth umstellen (z.B. OAuth-Client-Creds mit Zert, Managed Identity etc.). Wenn das nicht geht, müssen Sie diese Accounts von Policies ausnehmen – aber dann anderweitig schützen (minimale Rechte, random High-Entropy Password, evtl. nur aus bestimmter IP arbeiten lassen). Sie umgehen CA nur, wenn technisch nötig, und dokumentieren das Risiko. Noch besser: Wo es geht, weg von Accounts hin zu Managed Identity – Letztere tauchen als eigene Entity auf, und für die gibt’s wie erwähnt bald eigene CA Controls.

Frage 6: „Was ist der Unterschied zwischen den ‚Security Defaults‘ und Conditional Access? Brauchen wir CA, wenn Security Defaults an sind?“
Antwort: Security Defaults sind ein vereinfachtes, vordefiniertes Satz an Policies, die Microsoft gratis anbietet. Sie umfassen: MFA für alle Benutzer (via App-Notification oder Phone), MFA-Zwang für Adminrollen bei jedem Login, Legacy Auth wird blockiert, neue User müssen MFA registrieren etc. Das ist ein guter Basisschutz für kleine Umgebungen ohne Know-how. Aber: Man kann Security Defaults überhaupt nicht anpassen. Alle oder nichts. Conditional Access hingegen erlaubt feingranulare Einstellungen – wer, wann, wo, mit welchen Ausnahmen usw. Mit CA können Sie auch viel mehr Conditions nutzen (Geräte, Apps, Risk). In einer professionellen Umgebung stößt man mit Security Defaults schnell an Grenzen (z.B. ein Dienstaccount ohne MFA – geht nicht mit Defaults; unterschiedliche Policy für Admin vs. User – geht kaum). Deshalb: Security Defaults deaktivieren, sobald Sie eigene CA-Policies einführen. Man soll nicht beides parallel haben (Portal schließt das auch aus, entweder oder). In Kürze: Security Defaults = Good, Conditional Access = Better (aber erfordert P1-Lizenz).

Frage 7: „Sollten wir Security Defaults ausschalten, wenn wir anfangen, eigene CA-Policies zu nutzen?“
Antwort: Ja. Sobald Sie im Conditional Access Bereich aktiv werden (und entsprechende Lizenzen haben), ist es ratsam, die Security Defaults auszuschalten. Warum? Weil sie sonst konkurrierende Effekte haben können. Z.B. Security Defaults erzwingen MFA für alle – Ihre Policies vielleicht auch, aber was, wenn Sie eine Ausnahme wollten? Defaults würden das ignorieren. Außerdem ist es redundant: CA kann alles, was die Defaults können, und mehr. Typischer Ablauf: Lizenzen beschaffen, CA-Policies definieren (erst Report-Only testen), dann Security Defaults -> Deaktivieren (Schalter im Portal). Danach gelten nur noch die von Ihnen kontrollierten CA-Richtlinien. Das sollte koordiniert passieren, idealerweise in einer Nebenzeit, damit man im Notfall rasch Defaults wieder aktivieren könnte. Aber bei gutem Plan braucht man das nicht – CA übernimmt lückenlos.

Frage 8: „Unsere Benutzer beschweren sich über ständige MFA-Abfragen. Können wir das reduzieren, ohne Sicherheit zu verlieren?“
Antwort: Ein gewisser MFA-„Stress“ ist normal am Anfang, lässt aber nach, weil Tokens i.d.R. 90 Tage leben (bei Standardsettings) und Refresh silent passieren. Wenn Nutzer ständig Prompts sehen, kann das mehrere Gründe haben: – Vielleicht ist „Persistent Browser Session“ nicht erlaubt (CA hat Option „keine persistenten Cookies“), dann müssen sie sich öfter neu anmelden. Überlegen Sie, ob Sie vertrauenswürdigen Geräten längere Session erlauben können. – Sign-in Frequency Policy könnte zu aggressiv sein (z.B. täglich). Lockern Sie die, außer in Hochsicherheitsumgebungen. – Nutzer wechseln oft Gerät/Netzwerk? Dann triggert CA jedes Mal neu (z.B. jeder Wechsel zwischen Home und Office erkennt andere IP). Hier könnte man interne Netzwerke von MFA ausnehmen (aber das ist Abwägung). – „Keep me signed in“ Pop-up – Wenn die Leute das falsch klicken, werden sie öfter ausgeloggt. Man kann diesen Prompt via Company Branding steuern (z.B. ausblenden, um Verwirrung zu vermeiden). In Summe: Balance finden. Vielleicht muss nicht jede Anwendung bei jeder Anmeldung MFA fordern. Überlegen Sie kritisch: Evtl. reicht es, MFA einmal pro Woche zu erzwingen, außer es gibt riskante Umstände. Nutzen Sie Risiko-basierte Ansätze, falls P2 da ist (nur bei ungewöhnlichem Verhalten MFA extra). Und ganz wichtig: Schulen Sie die User, warum MFA nötig ist. Das Verständnis reduziert die Beschwerden. Meist pendelt es sich ein – viele Apps nutzen Single Sign-On im Hintergrund, sodass MFA nur selten tatsächlich required wird, wenn man die Token leben lässt. Falls nicht: Man kann CA so konfigurieren, dass z.B. „Device compliant UND im Büro -> kein MFA verlangt“. Das verringert Prompt-Frequency drastisch, birgt aber etwas mehr Risiko extern. Hier nach Umfeld entscheiden.

Frage 9: „Beziehen sich unsere CA-Policies auch auf Gäste/Externe, die wir in unser Azure AD einladen?“
Antwort: Ja, sofern die Richtlinien sie einschließen. Standardmäßig gilt eine CA-Policy für Alle Benutzer tatsächlich für alle – also interne Konten und Gastkonten gleichermaßen. Sie können aber in jeder Policy Gäste ausschließen oder separat behandeln. Es ist empfehlenswert, eigene Policies für Gäste zu erstellen (siehe Abschnitt B2B). Beispielsweise „Require MFA for guest users“ – dann müssen alle Externen immer MFA machen, egal ob ihre eigene Organisation das hat oder nicht (wer kein Azure AD hat, kriegt dann E-Mail-Code). Interne Policies kann man dann so bauen, dass Gäste dort ausgeschlossen sind, damit sie z.B. nicht an Geräte-Compliance oder ähnlichem scheitern. Fazit: Ja, CA greift für B2B-Gäste, und Sie sollten das aktiv nutzen, um externe Zugriffe abzusichern. Wenn Sie aus Versehen Gäste ausgesperrt haben (kommt vor, z.B. Policy „device must be compliant“ ohne Ausnahme), dann schnell nachjustieren – Gäste können idR nicht compliant sein in Ihrem Tenant.

Frage 10: „Wir haben noch keine P1/P2-Lizenzen. Lohnt sich die Investition für Conditional Access wirklich?“
Antwort: Klare Gegenfrage: Wie viel wäre es Ihnen wert, 99% der häufigsten Angriffe (Passwort-Phishing, Brute Force, etc.) ins Leere laufen zu lassen? Genau das erreicht MFA + CA. In der heutigen Bedrohungslage sollte MFA Pflicht sein, und Conditional Access ist der Weg, MFA und andere Controls intelligent durchzusetzen. Eine P1-Lizenz kostet ca. 6€ pro Benutzer/Monat (oft schon in M365 E3 enthalten). Für kleinere Firmen bis 300 User bietet Business Premium (ca. 16€) nicht nur P1, sondern auch Intune und Defender – ein Sicherheits-Schnäppchen, ehrlich gesagt. Wenn man bedenkt, was ein einziger Security Incident kosten kann (Ausfall, Reputation, ggf. Lösegeld), sind die Lizenzkosten für CA mehr als gerechtfertigt. Die meisten erfahrenen Admins werden bestätigen: Azure AD ohne P1 fühlt sich blind an – man weiß nicht, wer sich wie einloggt und kann es nicht steuern. Also ja: Lohnt sich absolut. P2 hingegen (zusätzliche ~3€) ist nice-to-have für die Automatisierung (Risikoerkennung, PIM). Größere Unternehmen oder solche mit hohem Schutzbedarf sollten P2 ernsthaft erwägen. Aber als Einstieg ist P1 der Gamechanger.

Frage 11: „Wie integriert sich Conditional Access mit unserem VPN oder internen Netzwerk? Können wir interne Logins anders behandeln?“
Antwort: Sie können in Conditional Access Named Locations definieren, z.B. alle öffentlichen IPs Ihrer Firmenstandorte oder VPN-Ausgangspunkte als „vertrauenswürdiger Standort“ markieren. Dann können Sie Policies so gestalten, dass Logins von dort weniger Hürden haben (z.B. kein MFA, wie in Policy 6 oben). Allerdings propagiert das Zero-Trust-Modell, Internen Netzwerken nicht blind zu vertrauen. Viele entscheiden sich trotzdem, on-premise Logins etwas zu erleichtern, etwa weil man davon ausgeht, dass es dort schon physische Zutrittskontrollen gibt. Letztlich ist es eine Risikoentscheidung: – Option A: Intern gleich behandeln wie extern (hohe Sicherheit, etwas unbequemer intern). – Option B: Intern weniger MFA oder Restriktionen (besseres UX im Büro, aber höheres Risiko falls Perimeter durchdrungen). Man kann auch Zwischenwege gehen, z.B. intern kein MFA aber trotzdem Anforderungen ans Gerät (muss Domänenmitglied sein). Wichtig: Sollte Ihr VPN Azure AD nutzen für Auth (Stichwort Azure AD Authentication for VPN), dann greifen CA-Policies auch auf VPN-Logins! Das kann gut sein (MFA vorm VPN) oder zu Überraschung führen (User kommt nicht ins VPN, weil CA was will und VPN-Client zeigt es schlecht an). Testen Sie das also. Grundlegend: Conditional Access kann sehr wohl Netzwerkszenarien abdecken, Sie müssen nur die Locations definieren und sauber mit den Policies verweben.

Frage 12: „Können wir Conditional Access einsetzen, um nur bestimmte Authentifizierungsmethoden zuzulassen (z.B. Passwort + FIDO, aber kein SMS)?“
Antwort: Ja, über das Feature Authentication Strength (seit 2022 GA). Man kann eigene „Stärken“ definieren, z.B. „Phishing-resistant MFA“ (schließt dann z.B. SMS und Voice aus, nur FIDO2, Zertifikat oder App mit Number Matching zählen). In einer CA-Policy wählen Sie dann „Require authentication strength: XYZ“. Dadurch werden nur die erlaubten Methoden akzeptiert, alle anderen lehnt Azure AD ab. Das ersetzt gewissermaßen die klassische „MFA-Methoden einschränken“-Policy, die es früher in MFA Service Settings gab (dort konnte man SMS disable etc., was tenantweit galt). Jetzt kann man per CA kontextabhängig steuern. Beispiel: Für normale User erlauben wir alle MFA-Methoden, aber für Administrator-Rollen Policy „Require Strong MFA“ => nur HW-Token/CBA. Somit: Feingranular möglich. Achtung: Auth Strength erfordert P1-Lizenz. Und es wirkt nur, wenn CA greift (wenn Nutzer sich normal anmeldet und keine Policy es erzwingt, kann er natürlich mit jeder registrierten Methode MFA machen). Aber in Praxis kombiniert man es immer: Policy greift -> verlangt bestimmte Stärke -> Azure AD sorgt dafür, dass ggf. gleich die richtige Methode angeboten wird. Antwort also: Ja, CA kann MFA-Methoden whitelisten.

Frage 13: „Braucht man Intune bzw. Gerätemanagement, um Conditional Access sinnvoll zu nutzen?“
Antwort: Jein. Viele CA-Funktionieren gehen ohne Intune: MFA, Location, App, User-Risiko etc. Aber sobald Sie Geräte-Compliance als Kriterium nutzen wollen, ist Intune (oder ein kompatibles MDM via Azure AD) erforderlich, um den Status „Compliant“ überhaupt zu vergeben. Ebenso Hybrid-Join: dafür brauchen Sie Azure AD Connect und ggf. AD FS oder Seamless SSO. Also: Man kann Conditional Access auch ohne Intune betreiben – z.B. rein auf MFA/Location basierend – und gewinnt bereits viel Sicherheit. Doch um das volle Potenzial auszuschöpfen (insb. Richtlinie „nur Firmengeräte“), kommt man an Intune (oder Endpoint Manager) nicht vorbei. Microsoft 365 Business Premium/E3 etc. enthalten Intune, wodurch P1-Kunden es oft eh dabei haben. Falls Sie wirklich gar kein MDM wollen, können Sie bedingt mit „Azure AD Registered“ Geräten arbeiten (also jeder User kann sein Gerät registrieren, dann hat Azure AD zumindest Device ID) – aber compliance (Patch, AV etc.) können Sie ohne Intune nicht prüfen. Kurzum: Nicht zwingend nötig, aber sehr empfehlenswert. Ohne Gerätemanagement verpasst man einen wichtigen Strang von Zero Trust, nämlich das Gerätvertrauen.

Frage 14: „Wie gehen wir mit Ausnahmefällen um, z.B. ein Vorstandsmitglied will kein MFA benutzen?“
Antwort: Ah, der VIP ohne MFA-Klassiker. Prinzipiell sollte auch der Vorstand MFA nutzen – gerade deren Accounts sind hochattraktiv für Angreifer. Aber wenn politisch Druck kommt: Suchen Sie einen Kompromiss, der das Risiko minimiert. Möglichkeiten: – Alternative sichere Methode: Vielleicht lehnt der VIP die Authenticator-App ab, wäre aber einverstanden, einen FIDO2-Sicherheitsschlüssel zu verwenden (weil der weniger „Technik“ erfordert von ihm). Das wäre sogar sicherer und komfortabler (ein Schlüsselanhänger den er nur anstecken muss). – Sonderbehandlung mit anderen Controls: Wenn absolut kein MFA: Man kann eine Ausnahme für diesen Account in MFA-Policy machen – aber dann unbedingt andere Schutzmaßnahmen verschärfen: z.B. Gerät muss Company-Notebook sein und up-to-date, Login nur aus Büro oder per VPN mit starker Auth, etc. Und vielleicht einen Monitoring-Alert auf dieses Konto setzen (jede Anmeldung checken). – Risiko schriftlich festhalten: Wenn sich jemand MFA verweigert, lassen Sie sich von ihm schriftlich bestätigen, dass er das Risiko versteht und übernimmt (das schreckt evtl. ab oder dient als Absicherung für Sie falls was passiert). – Kurzzeit-Ausnahme: In manchen Fällen will jemand nur temporär kein MFA (z.B. auf Reisen mit schlechtem Empfang). Azure AD P2 hat „Temporary Access Pass“ – damit kann man einen befristeten Code generieren, der wie MFA wirkt. Evtl. Option. Schlussendlich: Dauerhafte Ausnahmen sollten vermieden werden. Versuchen Sie zu überzeugen: MFA kann man dem Vorstand auch so „verkaufen“, dass es fürs Unternehmen kritisch ist. Notfalls zeigt man ein Worst-Case-Szenario auf (Konto gehackt => Ad-hoc-Pressekonferenz). Wenn trotzdem nicht: Minimale Ausnahme einrichten, streng isolieren und nicht breittreten (sonst wollen das alle). Aber meistens findet sich ein Weg – viele VIPs sind am Ende einsichtig, wenn man die passenden Hilfsmittel (wie YubiKey) anbietet.

Frage 15: „Wie überwachen wir, ob Conditional Access funktioniert und keine legitimen Zugriffe blockiert? Gibt es Tools dafür?“
Antwort: Monitoring ist wichtig. Möglichkeiten: – Im Entra Portal unter „Übersicht > Sign-ins“ sehen Sie Statistiken: Erfolgreiche vs. unterbrochene Anmeldungen, Risikoanmeldungen etc. Über Filter können Sie gezielt „Zugriff verweigert“ Einträge analysieren. – Microsoft bietet ein Workbook namens „Conditional Access Insights“, das mit Log Analytics arbeitet. Dort sieht man bspw. Uncovered Users (die noch von keiner Policy erfasst sind) oder Anomalien. Einrichtung erfordert Azure Monitor Logs und ein bisschen Klickarbeit, lohnt sich aber. – Azure AD Workbooks: Es gibt auch „Signin Analysis“ Workbooks, wo man z.B. nach App oder Location filtern kann – guter Überblick. – SIEM-Integration: Man kann Azure AD Logs ins SIEM (z.B. Microsoft Sentinel oder Splunk) schicken und dort Alarme definieren, z.B. „mehr als 5 Blocked signins in 10 min für gleichen User -> Alert an Admin“ oder „Anmeldung blockiert für VIP -> Ticket erzeugen“. Das ermöglicht proaktives Eingreifen. – Secure Score: behaltet im Secure Score die Identity-Bereich Punkte im Blick – sie steigen, wenn CA richtig eingesetzt wird. Wenn Score fällt (z.B. weil Policy entfernt), wär das ein Zeichen zu prüfen. Allgemein: Ein gewisses Grundrauschen an blockierten Versuchen ist normal (z.B. irgendwelche Bots probieren alte POP3 Logins – die werden halt geblockt). Interessant sind neue Muster: z.B. seit einer Policy-Änderung viele Blocks für legitime User? Dann muss man eventuell tunen. Also, ja es gibt Tools – aber man muss sie aktiv nutzen. „Funktioniert“ im Sinne von „Schwachstellen bleiben zu“ sieht man, wenn in den Logs z.B. Legacy Auth logins = 0 (Ziel erreicht), MFA rate = hoch etc. Und natürlich am Ausbleiben von Sicherheitsvorfällen. Keine News ist gute News. Trotzdem: Lieber wachsam bleiben und ab und zu Kontrollblicke in die Logs werfen oder automatische Reports abonnieren.

Damit haben wir die häufigsten Fragen abgedeckt, die in der Praxis rund um Conditional Access auftreten. Natürlich ist jedes Unternehmen anders – aber erfahrungsgemäß tauchen genau diese Punkte immer wieder auf. Jetzt sind Sie gewappnet, falls Ihr Chef oder Kollege mit ähnlichen Fragen um die Ecke kommt!

9. Persönliches Beratungsangebot

Security ist kein Produkt von der Stange – es braucht Erfahrung, Fingerspitzengefühl und Praxiswissen, um etwas wie Conditional Access optimal umzusetzen. Genau das biete ich Ihnen an: persönliche Beratung und Begleitung bei allen Themen rund um Microsoft 365 Security & Conditional Access.

Warum mit mir? Ich bin kein anonymer Dienstleister, der Aufträge an Junior-Teams weitergibt, sondern Ihr persönlicher Ansprechpartner von A bis Z. Mit über 30 Jahren Erfahrung (u.a. als Fachbuchautor und Berater für Microsoft 365) kenne ich die typischen Fallstricke – aber auch die cleveren Abkürzungen. Ich führe alle Leistungen selbst durch: von der Analyse über die technische Umsetzung bis zum Knowledge-Transfer. Das heißt für Sie: keine Wechsel der Ansprechperson, keine Blackbox. Sie haben immer mich am Telefon oder im Meeting, mit meinem vollen Engagement.

Mein Ansatz ist praxisorientiert und maßgeschneidert auf Ihre Organisation. Wir entwickeln gemeinsam ein Sicherheitskonzept, das zu Ihrem Geschäftsmodell passt – und setzen es dann schrittweise und ohne Betriebschaos um. Ich lege Wert darauf, komplexe Technik in verständliche Lösungen zu übersetzen (diesen Artikel haben Sie ja bis hierher gelesen – dann haben Sie einen Eindruck meines Stils). Locker im Ton, aber seriös in der Sache.

Wichtig: Ich verkaufe keine Managed Services im 24/7-Betrieb, sondern fokussiere mich auf Beratung, Implementation und Enablement Ihres Teams. Heißt: Ich befähige Ihre Administratoren, den neuen Sicherheitslevel selbstständig zu halten und weiterzuentwickeln. Natürlich lasse ich Sie danach nicht allein – auf Wunsch begleite ich Sie langfristig als externer Security Advisor, den Sie jederzeit hinzuziehen können (sei es für jährliche Audits, Updates zu neuen Features oder einfach als Second Opinion).

Meine Leistungen umfassen typischerweise: – Workshops & Analyse: Anforderungsaufnahme, Schwachstellenidentifikation, Lizenz-Check. – Konzept & Design: Erarbeitung einer Conditional-Access-Strategie inkl. Governance (angepasst an Firmengröße und Branche). – Implementierung: Technische Umsetzung in Ihrer Umgebung – möglichst erst in Test/Pilot, dann Produktion. Inkl. Dokumentation jeder Policy. – Schulung & Adoption: Training für Admins/Helpdesk, Kommunikationsempfehlungen für Endbenutzer (MFA-Rollout etc.). – Nachbetreuung: Monitoring der ersten Wochen, Fine-Tuning der Regeln, regelmäßige Review-Termine. Auf dem Laufenden halten zu relevanten Neuerungen (z.B. „Hey, es gibt ein neues Feature X, das eure Policies verbessern könnte – wollen wir das mal evaluieren?“).

Mein Versprechen: Ich gehe partnerschaftlich und mit Begeisterung an Ihr Projekt heran. Sie profitieren von Best Practices, ohne eigene lange Lernkurven durchlaufen zu müssen. Und ich nehme kein Blatt vor den Mund – wenn eine Idee nicht sinnvoll ist oder Risiken birgt, sage ich das. Das schätzen meine Kunden: Ehrlichkeit, Expertise und greifbare Ergebnisse.

Falls Sie also beim Lesen dieses Artikels dachten „Klingt toll, aber wer weiß, ob wir das alleine hinbekommen…“ – dann helfe ich Ihnen gern dabei. Egal ob Sie am Anfang stehen (MFA gerade erst Thema) oder schon fortgeschritten sind (Policies vorhanden, aber Audit im Nacken): Zusammen bringen wir Ihre Cloud-Security auf das nächste Level, ohne Panik und ohne unrealistische Versprechen.

Wie es weitergeht:

Wenn Sie Interesse an meiner Unterstützung haben, melden Sie sich einfach unverbindlich bei mir (Kontaktinfos auf dieser Website). Wir vereinbaren ein kostenloses Vorgespräch, in dem wir Ihre Situation grob skizzieren. Daraus erstelle ich Ihnen ein individuelles Angebot. Und keine Sorge: Ich dränge niemandem etwas auf – Sie sollen sich wohlfühlen mit der Entscheidung.

Ich freue mich darauf, persönlich mit Ihnen zusammenzuarbeiten und meine Expertise voll und ganz für Ihre Ziele einzusetzen!

10. Drei Beratungspakete

Um Ihnen einen Eindruck von typischen Projektumfängen, Leistungen und Kosten zu geben, habe ich drei Beratungspakete geschnürt. Diese Pakete sind erprobt und decken unterschiedliche Bedürfnisse ab – vom schnellen Kickstart bis zur umfassenden Enterprise-Begleitung. Jedes Paket ist ein Festpreis-Angebot auf Basis meines Tageshonorars, mit klar umrissenen Inhalten und Ergebnissen.

(Hinweis: Die tatsächliche Ausgestaltung passen wir natürlich auf Ihr Unternehmen an – die Pakete dienen als Orientierung.)

Paket S – Grundschutz & MFA-Einführung

Leistungen (Scope)	Aufwand	Preisformel	Zeitrahmen
Paket S – Grundschutz & MFA-Einführung: <br>• Bestandsaufnahme Ihrer Microsoft-365-Umgebung (Fokus Identity)<br>• Aktivierung von MFA für alle User (inkl. Planung der Registrierungskampagne)<br>• Umsetzung 2–3 Basis-Policies in Entra ID (z.B. MFA erzwingen, Legacy Auth blockieren, Notfallkonto einrichten)<br>• Kurze Administratoren-Schulung (MFA-Handling, CA-Overview)<br>• Dokumentation der eingerichteten Policies (ca. 5 Seiten PDF)	3–4 PT	3–4 PT × 1.500 € = 4.500–6.000 €	ca. 2 Wochen
Geeignet für: Unternehmen bis ~100 Benutzer, die noch kein MFA/CA haben und mit überschaubarem Aufwand einen soliden Basisschutz möchten.

Paket M – Erweiterte Access-Policies & Rollout

Leistungen (Scope)	Aufwand	Preisformel	Zeitrahmen
Paket M – Erweiterte Access-Policies & Rollout: <br>• Workshop zur Policy-Planung (Ermittlung individueller Anforderungen, z.B. Schutz sensibler Apps, BYOD-Regeln, Gastzugriff)<br>• Implementierung von ca. 10 Conditional-Access-Policies gemäß Best Practices (inkl. Geräte-Compliance, standortbasierte Regeln, Gastzugriff-Policy, risikobasierte MFA falls lizenziert)<br>• Einrichten von Governance-Artefakten: Policy-Register, Notfallprozess, Zuständigkeiten (RACI)<br>• Begleitung eines gestuften Rollouts: Pilotphase, Auswertung, dann Ausweitung auf gesamte Organisation<br>• Einweisung Helpdesk/IT in Fehlersuche (Sign-In Logs, What-If) und Unterstützung bei Benutzerkommunikation (Templates für Ankündigungen)<br>• Abschlussbericht mit KPI-Auswertung (MFA-Quote, Blocked Sign-ins)	6–8 PT	6–8 PT × 1.500 € = 9.000–12.000 €	ca. 4 Wochen
Geeignet für: Mittelständische Unternehmen 100–1.000 User, die bereits Basis-MFA haben oder mit Paket S gestartet sind und nun einen vollumfänglichen Conditional-Access-Schutz implementieren wollen (inkl. Gerät und Risiko).

Paket L – Governance & kontinuierliche Verbesserung (Enterprise)

Leistungen (Scope)	Aufwand	Preisformel	Zeitrahmen
Paket L – Governance & kontinuierliche Verbesserung: <br>• Umfassende Ist-Analyse & Risiko-Workshop (Einbezug Compliance/Revision, Bedrohungsmodell, branchenspezifische Anforderungen z.B. NIS2, BSI-Grundschutz)<br>• Entwicklung einer Zero-Trust-Roadmap für Identity (Phasenplanung für Policies, Integration mit anderen Security-Komponenten wie Defender, MCAS etc.)<br>• Implementierung aller benötigten CA-Richtlinien (typisch 15–20 Policies, inkl. Feintuning für Spezialfälle, z.B. Token Protection, Workload Identities sofern möglich)<br>• Aufbau eines Monitoring- und KPI-Frameworks: Dashboards, Alerting (z.B. in Sentinel oder Azure Monitor) für CA-Ereignisse, regelmäßige Reports ans Management<br>• Etablierung von Governance-Prozessen: Richtlinien für Policy-Lifecycle, Access Reviews (falls P2), Schulung eines internen CA-Verantwortlichen („Policy Champion“)<br>• Dokumentationspaket Enterprise: ausführliches Konzeptdokument, Betriebsleitfaden, Sicherheitsrichtlinie-Textbausteine für Zugriffssteuerung<br>• Langfristige Begleitung: In diesem Paket inklusive sind 2 Check-in-Termine in den Folgemonaten (zur Nachjustierung und Beratung bei neuen Anforderungen)	10–12 PT	10–12 PT × 1.500 € = 15.000–18.000 €	ca. 6–8 Wochen
Geeignet für: Größere Organisationen / regulierte Branchen, die Conditional Access auf höchstem Niveau implementieren möchten – inkl. Einbettung in Governance und laufende Optimierung. Ideal, wenn schon CA-Grundlagen bestehen, aber auf Enterprise-Standard gehoben werden sollen.

Hinweise: Alle Preise verstehen sich zuzüglich USt. und evtl. anfallender Reisekosten (bei vor-Ort-Terminen nach Absprache). Die Aufwände (PT = Personentage) sind Schätzungen auf Basis bisheriger Projekte – im Angebot werden diese transparent und fixiert. Sollte sich im Projekt herausstellen, dass der Umfang angepasst werden muss, sprechen wir das frühzeitig ab. Tagessatz in den Paketen kalkuliert mit 1.500 €/PT.

Wie Sie sehen, gibt es für jeden Bedarf ein passendes Paket – vom Quick Win bis zum Full-Blown-Projekt. Selbstverständlich können wir auch ein individuelles Paket schnüren, falls Ihre Anforderungen dazwischen liegen. Die Pakete dienen vor allem der Orientierung und Transparenz.

11. Abschluss

IT-Sicherheit ist kein Zustand, sondern ein Prozess. Mit der Implementierung von Conditional Access in Microsoft 365 haben Sie einen der wichtigsten Schritte hin zu einer modernen, Zero-Trust-basierten Sicherheitsarchitektur getan. Doch es gilt, dranzubleiben: Bedrohungslandschaften ändern sich, Geschäftsanforderungen entwickeln sich weiter – Ihre Access-Policies sollten das spiegeln.

Lassen Sie sich aber nicht entmutigen: Die Mühe lohnt sich. Wenn Sie heute auf Ihre Umgebung schauen, haben Sie wahrscheinlich bereits: – Weit über 90 % Ihrer Identitäten per MFA abgesichert – ein gewaltiger Sprung im Vergleich zu klassischem Passwortschutz. – Klare Regeln definiert, wer auf welche Cloud-Ressourcen zugreifen darf – und damit die Gefahr von zufälligen oder böswilligen Fehlgriffen massiv reduziert. – Eine Sichtbarkeit gewonnen, von welcher man früher nur träumen konnte: Sie sehen in Echtzeit Anmeldeversuche, können anomalien erkennen und reagieren, bevor Schaden entsteht. – Ihr Unternehmen nachweislich auf ein Niveau gebracht, das gängigen Compliance-Anforderungen entspricht („Stand der Technik“ gemäß DSGVO Art.32, ISO 27001 A.9 Zugriffskontrolle, etc.). Das auditorsichere Gefühl ist unbezahlbar.

Natürlich ist kein Sicherheitskonzept absolut. Aber mit Conditional Access haben Sie einen dynamischen Schutzwall eingezogen, der es Angreifern enorm schwer macht, unautorisiert in Ihr Microsoft-365-Universum einzudringen. Gleichzeitig haben Sie Ihren Kolleginnen und Kollegen gezeigt, dass Sicherheit und Benutzerfreundlichkeit kein Widerspruch sein müssen – man kann smart und flexibel steuern, ohne die Arbeit lahmzulegen.

Zum Abschluss noch ein Ausblick: Die Zukunft der Zugriffssicherheit wird weiterhin spannend. Themen wie Continuous Access Evaluation werden sich ausweiten, vielleicht werden Login-Sitzungen irgendwann in Echtzeit auf Risk-Changes reagieren. KI-gestützte Security Copilots könnten Admins Vorschläge machen („Hey, ich habe bemerkt, dass in Abteilung X niemand mehr extern arbeitet – Policy anpassen?“). Microsoft Entra entwickelt sich mit rasendem Tempo – man denke an die Integration von Identity Governance, Verified ID (dezentrale Identitäten) etc. Als Entscheidungsgeber oder Admin tun Sie gut daran, am Ball zu bleiben.

Doch keine Sorge: Sie müssen das Rad nicht täglich neu erfinden. Pflegen Sie eine Kultur der regelmäßigen Überprüfung und Verbesserung (das haben wir in Governance und Betrieb besprochen). Nehmen Sie sich z.B. zweimal im Jahr Zeit für ein kurzes Update-Meeting: Was gibt’s Neues von Microsoft? Passen unsere Policies noch? Diese Investition hält Ihr Sicherheitsniveau hoch und zeigt Angreifern die kalte Schulter.

Abschließend möchte ich betonen: Security ist Teamarbeit. Technik, Prozesse und Menschen müssen zusammenspielen. Sie haben mit Conditional Access einen großartigen technischen Enabler – setzen Sie ihn weise ein, schulen Sie die Menschen drumherum und bleiben Sie agil in den Prozessen. Dann werden Sie selbst zukünftigen Herausforderungen gelassen entgegensehen können.

Ich hoffe, dieser Artikel konnte Ihnen fundiertes Wissen und praktikable Tipps vermitteln – locker im Ton und dennoch auf den Punkt. Wenn Sie nun motiviert sind, Ihr Microsoft-365-Umfeld (weiter) zu hardenen: Packen wir’s an! Und falls Sie auf dem Weg doch mal Unterstützung oder einen Sparringspartner brauchen, wissen Sie ja, wo Sie mich finden (zwinker).

In diesem Sinne: Bleiben Sie sicher! Sie haben die Werkzeuge in der Hand, machen Sie das Beste draus. Viel Erfolg bei der Umsetzung von Conditional Access – Ihr Unternehmen wird es Ihnen danken.

 

Weitere Beiträge zum Thema Security und Compliance