Conditional Access 2026: Microsoft Entra ID ist für viele Unternehmen die zentrale Anmeldung an Microsoft 365, Geschäftsanwendungen und Verwaltungsportalen. Angreifer benötigen heute häufig keinen offenen Netzwerkport mehr: Ein gestohlenes Konto oder eine übernommene Sitzung kann ausreichen, um sensible Daten zu erreichen. Conditional Access verbindet Benutzer, Zielanwendung, Geräteinformationen und weitere Signale mit kontrollierten Zugriffsentscheidungen. Eine falsche Konfiguration kann allerdings den gesamten Betrieb aussperren. Dieser Leitfaden zu Conditional Access 2026 erklärt, wie Sie eine robuste Baseline, risikobezogene Regeln und Notfallzugänge mit überprüfbarem Rollout organisieren.
Autor: Salman Dolatpanah Gortlar · GORTNET IT-Dienstleistungen ·
Conditional Access als Zugangskontrolle verstehen
Eine Conditional-Access-Policy besteht vereinfacht aus Zielidentitäten, Bedingungen, Zielressourcen und Zugriffskontrollen. Sie kann den Zugriff blockieren, eine Authentifizierungsstärke verlangen oder bestimmte Sitzungskontrollen aktivieren. Entscheidend ist die tatsächliche Auswertung zur Anmeldezeit und in unterstützten Szenarien bei späteren Risikoänderungen. Eine Policy wirkt nicht automatisch auf jeden technischen Dienst, nur weil dieser im selben Tenant betrieben wird.
Beschreiben Sie vor dem Erstellen die Geschäftsanforderung: Wer soll auf welche Anwendungen zugreifen dürfen, von welchen verwalteten Geräten und unter welchen Voraussetzungen? Je deutlicher dieser Zweck formuliert ist, desto leichter lassen sich Ausnahmen, Tests und Konflikte erklären. Vermeiden Sie ein undurchschaubares Netz sich überlappender Regeln, das nur ein einziger Administrator versteht.
Conditional Access 2026: Eine durchdachte MFA-Baseline
Microsoft empfiehlt eine Grundlage, die normale Benutzer und relevante Zielressourcen breit abdeckt. Für privilegierte Rollen können phishingresistente Authentifizierungsverfahren angemessen sein. Die passende Authentifizierungsstärke hängt von Risiko und verfügbaren Geräten ab. Eine klassische Push-MFA ist nicht identisch mit einer FIDO2-geschützten Anmeldung. Definieren Sie deshalb einen Standard für alltägliche Beschäftigte und strengere Anforderungen für besonders sensible administrative Workflows.
Planen Sie die Umstellung in Wellen, damit Mitarbeitende sichere Anmeldemethoden rechtzeitig registrieren können. Kontrollieren Sie, ob ältere Clients und nicht interaktive Anwendungen von den Anforderungen betroffen sind. Sensible geschäftliche Ausnahmen sollten einen Eigentümer und ein Enddatum haben. Ein dauerhaft ausgenommenes Team aus Bequemlichkeit schwächt eine ansonsten gute Baseline erheblich.
Report-only vor Enforcement einsetzen
Neue Richtlinien sollten in der Regel zunächst im Report-only-Modus laufen. Dadurch werden Anmeldeereignisse bewertet, ohne den normalen Benutzerzugriff sofort zu blockieren. Die entsprechenden Sign-in-Logs zeigen, welche Policies getroffen hätten und welche Zugriffskontrollen angewendet worden wären. Eine Policy darf erst dann produktiv aktiv werden, wenn repräsentative Benutzer und Anwendungen geprüft wurden.
Achten Sie darauf, dass Report-only keine perfekte Simulation der späteren realen Nutzung unter allen Umständen darstellt. Manche Abhängigkeiten zwischen Anwendungen oder besondere Sign-in-Bedingungen müssen zusätzlich praktisch getestet werden. Dokumentieren Sie erfolgreiche und potenziell blockierte Szenarien und stimmen Sie geplante Änderungen mit dem Helpdesk ab. Ein vermeintlich harmloser Regelwechsel kann SSO, Teams oder eine Fachanwendung an unerwarteter Stelle beeinträchtigen.
Mit dem What If Tool Richtlinienkonflikte erkennen
Microsofts Conditional-Access-What-If-Funktion ermöglicht die Simulation ausgewählter Anmeldebedingungen. Administratoren können Identität, Zielressource und weitere Kontextmerkmale wählen und sehen, welche Richtlinien möglicherweise greifen. Das hilft besonders bei komplexen Umgebungen mit Gästen, Administratoren, mobilen Geräten und Standortbedingungen. Die Ergebnisse sind jedoch nur so aussagekräftig wie die vollständig angegebenen Simulationsparameter.
Beachten Sie dokumentierte Grenzen: Die What-If-Auswertung berücksichtigt nicht zwangsläufig alle Service-Abhängigkeiten einer Anwendung. Eine Simulation für Teams ersetzt beispielsweise keine Prüfung abhängiger Exchange-Online-Funktionen. Für kritische Änderungen kombinieren Sie daher What If, Report-only-Auswertung und echte End-to-End-Tests mit repräsentativen Konten. Verwenden Sie keine produktiven Admin-Konten als alleinige Testgruppe.
Break-Glass-Konten vor Aussperrung schützen
Notfallkonten sollen Zugriff wiederherstellen, wenn normale Anmeldemethoden, Richtlinien oder Identitätsdienste gestört sind. Microsoft empfiehlt mindestens zwei separat verwaltete Emergency-Access-Accounts, die unabhängig von gewöhnlichen Benutzerkonten funktionieren. Sie sollten über starke, möglichst phishingresistente Anmeldemethoden verfügen und von Richtlinien ausgenommen sein, die ihren Zweck im Notfall verhindern würden.
Schützen Sie diese Accounts organisatorisch: Sichere Aufbewahrung der Zugangsmittel, eindeutig festgelegte Verantwortliche, Überwachung jeder Anmeldung und regelmäßige Funktionstests gehören dazu. Eine Ausnahme von einer Conditional-Access-Blockierregel ist keine Aufforderung zu schwacher Authentifizierung. Wählen Sie eine Notfallarchitektur, die auch bei Störung des normalen Identity Providers funktioniert. Ein Notfallkonto, das niemand mehr nutzen kann, erfüllt seinen Zweck nicht.
Geräte-Compliance und Zugriff auf SaaS-Daten
Conditional Access kann bei geeigneter Lizenz- und Geräteverwaltung verlangen, dass ein Endpoint als compliant gilt oder andere definierte Gerätebedingungen erfüllt. Damit lassen sich sensible Cloud-Dienste besser auf verwaltete Endpunkte beschränken. Voraussetzung ist, dass Gerätestatus, Richtlinien und die zugehörige Verwaltung zuverlässig gepflegt werden. Ein Gerät mit abgelaufenem Compliance-Status kann sonst unerwartet Geschäftsprozesse blockieren.
Definieren Sie technische Mindestbedingungen wie unterstützte Betriebssystemversion, Datenträgerverschlüsselung, Schutzsoftware und Patchstand. Testen Sie, wie Unternehmensgeräte, private Geräte und mobile Clients behandelt werden sollen. Geräte-Compliance beweist nicht, dass ein Endpunkt niemals kompromittiert wird; sie ergänzt Identitätskontrollen. Besonders schutzbedürftige Verwaltungsaufgaben können zusätzlich auf privilegierte Arbeitsstationen beschränkt werden.
Gäste und externe Dienstleister separat steuern
Externe Benutzer können eine wichtige Rolle bei Projekten und Supportleistungen spielen. Ihre Geräte werden jedoch nicht immer vom eigenen Unternehmen verwaltet. Erstellen Sie deshalb differenzierte Regeln für Gasttypen, Zielanwendungen und sichere Anmeldung. Die Microsoft-Dokumentation erläutert die Verwendung von Authentication Strengths für Gast- und externe Benutzer sowie Grenzen bei bestimmten externen Authentifizierungsmethoden.
Prüfen Sie regelmäßig, welche Gäste noch einen geschäftlichen Zweck erfüllen. Ein erfolgreicher MFA-Check ersetzt nicht die Überprüfung von SharePoint-Berechtigungen oder Einladungsprozessen. Dokumentieren Sie, wer einen externen Zugriff genehmigt hat, wie lange er bestehen soll und welches Team ihn bei Projektende entfernt. Sensible Verwaltungszugänge für Dienstleister benötigen zusätzliche Aufsicht.
Benutzerkonten von Workload Identities unterscheiden
Viele Cloud-Integrationen nutzen Service Principals oder Managed Identities statt menschlicher Konten. Policies, die sich auf Benutzer beziehen, gelten nicht automatisch für alle diese Workloads. Microsoft bietet dafür separate Möglichkeiten für Conditional Access bei Workload Identities, abhängig von Lizenz und Unterstützungsumfang. Die normale Benutzer-MFA-Policy ist kein Ersatz für die Kontrolle nicht interaktiver Berechtigungen.
Inventarisieren Sie App-Registrierungen, Zertifikate, Geheimnisse und API-Rechte. Entfernen Sie ungenutzte Anwendungen, begrenzen Sie Zugriffe auf notwendige Ressourcen und planen Sie Geheimnisrotation. Ein kompromittierter Service Principal kann weitreichende Auswirkungen haben, auch wenn sämtliche Mitarbeitende Passkeys verwenden. Identity Governance muss daher menschliche und technische Identitäten getrennt, aber koordiniert behandeln.
Anmelderisiken und sensible Aktionen
Mit entsprechenden Microsoft-Entra-Funktionen lassen sich Sign-in-Risiken in Zugriffsentscheidungen einbeziehen. Ein verdächtiger Anmeldeversuch kann stärkere Authentifizierung oder andere Schutzmaßnahmen auslösen. Das Modell ist nur dann hilfreich, wenn Administratoren wissen, welche Signale verwendet werden und wie Fehlalarme behandelt werden. Ein risikobasierter Block ohne klaren Helpdesk-Prozess führt sonst zu schwer nachvollziehbaren Sperren.
Definieren Sie für kritische Cloud-Rollen zusätzliche Anforderungen: phishingresistente Anmeldung, verwaltete Geräte, begrenzte Sitzungen und nachvollziehbare privilegierte Rollenzuweisungen. Prüfen Sie auch die Auswirkungen auf mobile Zugriffe, Browser-Sessions und Apps mit mehreren abhängigen Diensten. Eine einzelne strenge Regel ist keine vollständige Strategie gegen gestohlene Session-Tokens.
Logging, Monitoring und Änderungsmanagement
Nach dem Rollout sollten Sign-in-Logs, Audit-Logs und Änderungen an Richtlinien regelmäßig ausgewertet werden. Legen Sie Alarmfälle fest, etwa ungewöhnliche Änderungen an Ausnahmen, neue administrative Richtlinien oder wiederholte Sperren eines kritischen Geschäftsdienstes. Die Daten müssen zeitlich und fachlich in Verbindung gebracht werden. Eine einzelne Fehlanmeldung liefert keinen belastbaren Sicherheitsvorfall.
Richten Sie einen nachvollziehbaren Change-Prozess ein: Vor jeder Änderung wird festgehalten, warum sie nötig ist, welche Benutzer betroffen sind, wie getestet wird und welcher sichere Rückweg existiert. Bei großen Unternehmen unterstützen Vorlagen und strukturierte Policy-Pläne die Verwaltung. Die aktuell dokumentierten neuen Policy-Plans-Funktionen können je nach Stand als Preview gekennzeichnet sein und sollten nicht ohne Prüfung in verbindliche Betriebsprozesse übernommen werden.
30-Tage-Fahrplan für Unternehmen
Woche eins: Bestehende Richtlinien, Rollen, Login-Arten, Lizenzbedingungen und Notfallkonten erfassen. Woche zwei: Eine grundlegende Authentifizierungsstrategie sowie getrennte Regeln für privilegierte Konten entwerfen. Woche drei: Einstellungen im Report-only-Modus prüfen, What If verwenden und repräsentative Szenarien durchspielen. Woche vier: Stufenweise Aktivierung, Helpdesk-Kommunikation und fortlaufende Berichte organisieren.
Messen Sie den Anteil von Anmeldungen mit geeigneter Authentifizierungsstärke, ungeklärte dauerhafte Ausnahmen und die Zeit bis zur Behebung unerwarteter Policy-Blockaden. Ergänzen Sie eine quartalsweise Prüfung der Emergency-Access-Konten. Eine belastbare Sicherheitskennzahl zeigt die Wirksamkeit der Richtlinien, nicht nur deren Anzahl im Administrationsportal.
Häufige Fragen zu Conditional Access 2026
Muss jede Regel sofort aktiviert werden?
Nein. Report-only, What If und kontrollierte Testgruppen vermindern das Risiko unbeabsichtigter Zugriffsblockaden.
Sind Passkeys und Conditional Access dasselbe?
Nein. Passkeys sind eine Authentifizierungsmethode; Conditional Access entscheidet anhand definierter Bedingungen über den Zugriff.
Sollten Break-Glass-Konten von allen Richtlinien betroffen sein?
Sie müssen so konzipiert sein, dass sie im Notfall erreichbar bleiben und trotzdem durch starke Anmeldemethoden und Monitoring geschützt sind.
Greift eine Benutzerpolicy automatisch für Service Principals?
Nein. Technische Workload-Identitäten erfordern gesonderte Kontrollen und gegebenenfalls eigene Conditional-Access-Funktionen.
Fazit: Sichere Regeln ohne Betriebsblockaden
Ein gutes Konzept für Conditional Access 2026 ist nachvollziehbar, getestet und gegen Fehlkonfiguration abgesichert. Priorisieren Sie privilegierte Identitäten, vermeiden Sie unbegrenzte Ausnahmen und verifizieren Sie Änderungen in Report-only und im produktionsnahen Test. Die Qualität zeigt sich im täglichen Betrieb und im Notfall, nicht an der bloßen Anzahl von Regeln.
Über den Autor
Salman Dolatpanah Gortlar veröffentlicht bei GORTNET praxisorientierte Fachbeiträge zu Active Directory, Microsoft-Identitäten und IT-Sicherheit. Die hier beschriebenen Maßnahmen müssen an die konkrete Umgebung angepasst werden.
Passende GORTNET-Inhalte
Bei der technischen Prüfung und Einführung von Identitätsrichtlinien kann GORTNET unterstützen.
Quellen
- Microsoft: Conditional Access MFA Policy
- Microsoft: Emergency Access Accounts
- Microsoft: Conditional Access What If
- Microsoft: Conditional Access Policy Plans
Redaktionsstand 28. Oktober 2026. Lizenz- und Funktionsumfang können sich ändern; technische Angaben mit der aktuellen Microsoft-Dokumentation abgleichen.