Conditional Access (CA) in Microsoft Entra ID ist weit mehr als „MFA für alle einschalten". Wer ernsthaft absichern will, denkt in Personas, schichtet Policies in Ringe, bindet Geräte-Compliance via Intune ein, schützt Tokens gegen Replay-Angriffe und stopft mit einer einzigen Regel über 97 Prozent der Credential-Stuffing-Angriffe zu. Dieser Artikel richtet sich an Admins, die den Einsteiger-CA-Artikel bereits kennen und ihr Policy-Framework professionell ausbauen wollen.

Voraussetzungen

Microsoft Entra ID P1 (mindestens) für alle CA-Policies außer risikobasierte – enthalten in Microsoft 365 E3 und Business Premium
Microsoft Entra ID P2 für risikobasierte Policies (Sign-in Risk, User Risk) – enthalten in Microsoft 365 E5
Microsoft Intune Lizenz für „Require Compliant Device": Intune muss als MDM-Autorität konfiguriert sein, mindestens eine Compliance Policy muss existieren
Break-Glass-Konto: mindestens ein Notfallkonto, das nicht synchronisiert und nicht MFA-pflichtig ist – vor jeder CA-Konfiguration bereitstellen
Rolle „Conditional Access Administrator" (Erstellen/Ändern) oder „Security Reader" (nur lesen) in Entra ID
Security Defaults deaktiviert: Security Defaults und Conditional Access sind inkompatibel – wer Security Defaults noch aktiv hat, muss diese zuerst abschalten
Optional: Log Analytics Workspace (Azure Monitor) für das CA Insights and Reporting Workbook und langfristige Log-Aufbewahrung

Schritt 1: Das Persona-Framework verstehen und Gruppen anlegen

Microsoft empfiehlt drei Kern-Personas. Jede Persona bekommt eigene CA-Policies mit unterschiedlich harten Controls:

Persona	Wer gehört dazu	Typische Controls
Admins	Alle Cloud- oder synced-Identitäten mit beliebiger Entra-ID- oder M365-Adminrolle. Gäste mit Adminrollen fallen nicht hier rein.	Phishing-resistentes MFA (FIDO2/WHfB/CBA), Compliant Device, kurze Session-Timeouts
Internals	Alle AD-synced Mitarbeiter ohne Adminrolle	MFA (TOTP oder Authenticator), App Protection für Mobile, Compliant Device optional
Guests	Alle Entra-B2B-Gastkonten, inkl. Gäste mit Adminrollen	MFA (über eigenen Tenant), eingeschränkte App-Zugriffe, keine Gerätebindung möglich

Lege im Entra Admin Center folgende Sicherheitsgruppen an, bevor du die ersten Policies erstellst:

# Empfohlene Gruppen-Benennungskonvention
CA-BreakGlass-Accounts          # Notfallkonten – aus ALLEN Policies ausschliessen
CA-Persona-Admins-Exclusion     # Temporaere Ausnahmen fuer Admin-Persona-Policies
CA-Persona-Internals-Exclusion  # Temporaere Ausnahmen fuer Internals-Persona-Policies
CA-TokenProtection-Pilot        # Pilotgruppe fuer Token-Protection-Rollout

Die Namenskonvention für Policies lautet: CA[NNN] - [Persona] - [Control] - [Scope], zum Beispiel CA001 - All Users - Block Legacy Authentication. Notfall-Policies beginnen mit EM: EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4]. Die Sequenznummer erlaubt Referenz im Gespräch, ohne die Policy öffnen zu müssen.

Schritt 2: Legacy-Auth blockieren – die wirksamste Einzelmaßnahme

Mehr als 97 Prozent aller Credential-Stuffing-Angriffe und mehr als 99 Prozent aller Password-Spray-Angriffe nutzen Legacy-Protokolle (IMAP, POP3, SMTP-Auth mit Basic Auth, Exchange ActiveSync ohne Modern Auth). Eine einzige Policy schließt dieses riesige Einfallstor.

Bevor du die Policy aktivierst: Prüfe die Sign-in-Logs auf Legacy-Auth-Nutzung. Drucker, Multifunktionsgeräte und ältere Scan-to-Mail-Setups senden oft per SMTP Basic Auth – die werden nach Aktivierung geblockt.

# Sign-in Logs auf Legacy-Auth pruefen
# Pfad: entra.microsoft.com > Entra ID > Monitoring & health > Sign-in logs
# Spalte "Client App" hinzufuegen (Columns-Button)
# Add filters > Client App > alle Legacy-Protokolle auswaehlen
# WICHTIG: Auch Tab "User sign-ins (non-interactive)" pruefen!
# Alternativ: Workbook "Sign-ins using legacy authentication" nutzen

Policy-Konfiguration im Entra Admin Center (entra.microsoft.com > Entra ID > Conditional Access > Policies > New policy):

# CA001 - All Users - Block Legacy Authentication
# Assignments > Users:
#   Include: All users
#   Exclude: CA-BreakGlass-Accounts (PFLICHT)

# Target Resources > Resources: All resources

# Conditions > Client apps: Configure = Yes
#   Haken setzen NUR bei:
#   [x] Exchange ActiveSync clients
#   [x] Other clients
#   (deckt IMAP, POP3, SMTP Auth Basic, EAS, aeltere Office-Clients ab)

# Access controls > Grant: Block access

# Enable policy: Report-only  <-- ERST nach Pruefung auf "On" setzen!

Alternativ per Microsoft Graph PowerShell:

Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'

$params = @{
    displayName = 'CA001 - All Users - Block Legacy Authentication'
    state = 'enabledForReportingButNotEnforced'  # Report-Only
    conditions = @{
        users = @{
            includeUsers = @('All')
            excludeGroups = @('<GUID-der-BreakGlass-Gruppe>')
        }
        applications = @{ includeApplications = @('All') }
        clientAppTypes = @('exchangeActiveSync', 'other')
    }
    grantControls = @{
        operator = 'OR'
        builtInControls = @('block')
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Lass die Policy mindestens eine Woche im Report-Only-Modus laufen. Im Entra-Anmeldeprotokoll erscheint pro Ereignis ein Tab „Report-only" mit dem Ergebnis. Identifiziere betroffene Geräte und stelle sie auf OAuth/Modern Auth oder App-Passwörter um – dann erst auf „On" schalten.

Schritt 3: Phishing-resistentes MFA für Admins einrichten

Normale MFA (TOTP, SMS) schützt nicht gegen Adversary-in-the-Middle-Phishing. Für die Admin-Persona setzt du deshalb Authentication Strength: Phishing-resistant MFA ein. Dieser Wert umfasst FIDO2-Sicherheitsschlüssel, Windows Hello for Business und Certificate-based Authentication.

# CA002 - Admins - Require Phishing-Resistant MFA - All apps
# Assignments > Users:
#   Include: Directory roles > [alle privilegierten Rollen auswaehlen]
#   Exclude: CA-BreakGlass-Accounts, CA-Persona-Admins-Exclusion

# Target Resources: All resources

# Access controls > Grant:
#   [x] Require authentication strength > Phishing-resistant MFA
#       (umfasst: FIDO2, Windows Hello for Business, Certificate-based Auth)

# Enable policy: Report-only

Stelle sicher, dass Admins ihre FIDO2-Schlüssel oder WHfB-Geräte vor der Aktivierung registriert haben – sonst sperren sie sich selbst aus.

Schritt 4: Geräte-Compliance mit Intune erzwingen

„Require device to be marked as compliant" ist eine der wirkungsvollsten Kontrollen – sie stellt sicher, dass nur Geräte Zugriff erhalten, die Intune als compliant meldet (verschlüsselt, aktuelles OS, kein Jailbreak usw.).

Kritischer Punkt: Ohne eine bestehende Intune Compliance Policy gelten alle Geräte als non-compliant. Die Folge: Sofortsperrung aller Geräte – auch bereits eingeschriebener. Erstelle die Compliance Policy in Intune (intune.microsoft.com) bevor du die CA-Kontrolle aktivierst.

Gute Nachricht: Die Intune-Enrollment-Erfahrung wird durch „Require compliant device" nicht blockiert. Neue Geräte können sich trotz aktiver Policy bei Intune einschreiben. Wie du Compliance Policies in Intune konfigurierst, zeigt die Anleitung Intune und Windows Autopilot: Geräte ausrollen.

# CA003 - Admins - Require Compliant Device - All apps
# Voraussetzung: Intune Compliance Policy MUSS existieren!
#
# Assignments > Users:
#   Include: Directory roles > [Admin-Rollen]
#   Exclude: CA-BreakGlass-Accounts, CA-Persona-Admins-Exclusion
#
# Target Resources: All resources
#
# Access controls > Grant:
#   [x] Require device to be marked as compliant
#   ODER: Require Microsoft Entra hybrid joined device
#   Grant control: Require one of the selected controls
#
# Enable policy: Report-only

Für Internals empfiehlt sich ein gestaffelter Rollout: zuerst Report-Only, dann nur für eine Pilotabteilung aktivieren, dann schrittweise ausweiten. Die Intune-Geräte-Compliance-Übersicht unter intune.microsoft.com > Devices > Compliance zeigt, welche Geräte derzeit non-compliant wären.

Schritt 5: Token Protection im Report-Only testen

Token Protection ist ein CA-Session-Control, der Primary Refresh Tokens (PRTs) kryptografisch an das ausstellende Gerät bindet. Gestohlene Tokens lassen sich nicht mehr von einem anderen Gerät einlösen – die Token-Replay-Falle schnappt zu.

Plattform-Unterstützung (Stand Juni 2026):

Plattform	Status	Mindestanforderung
Windows	Generally Available	Windows 10+, Entra-joined/Hybrid-joined/Entra-registered; Windows Server 2019+ wenn Hybrid-joined
macOS	Preview	macOS 14.0+, MDM-verwaltet, Enterprise SSO-Plugin oder Platform SSO
iOS/iPadOS	Preview	iOS/iPadOS 16.0+, MDM-verwaltet, Enterprise SSO-Plugin
Browser-Apps	Nicht unterstützt	Token Protection gilt nur für native Applikationen

Wichtig: Token Protection unterstützt ausschließlich native Applikationen. Wird die Policy auf Browser-Apps angewendet oder auf nicht unterstützte Clients, werden Nutzer hart geblockt. Starte deshalb immer mit Report-Only und einer kleinen Pilotgruppe.

Unterstützte Apps: Exchange Online, SharePoint Online, Microsoft Teams; unter Windows zusätzlich Azure Virtual Desktop und Windows 365.

# CA010 - Pilot - Token Protection - Exchange/SharePoint/Teams
# Assignments > Users:
#   Include: CA-TokenProtection-Pilot (kleine Testgruppe, z.B. 5-10 Admins)
#   Exclude: CA-BreakGlass-Accounts
#
# Target Resources > Select apps:
#   - Office 365 Exchange Online
#   - Office 365 SharePoint Online
#   - Microsoft Teams
#
# Access controls > Session:
#   [x] Require token protection for sign-in sessions
#
# Enable policy: Report-only

# Auswertung:
# Anmeldeprotokolle > Tab "Report-only" pruefen
# Spalte "Token protection" hinzufuegen

Lass die Policy mindestens zwei Wochen im Report-Only-Modus laufen. Prüfe im Anmeldeprotokoll unter dem Tab „Report-only", ob Blockierungen für Browser-Sessions oder nicht unterstützte Clients auftauchen würden. Erst wenn keine unerwarteten Treffer mehr erscheinen, aktiviere die Policy für die Pilotgruppe und weite sie schrittweise aus.

Schritt 6: Den Policy-Bestand überblicken und aufräumen

Das Hard-Limit liegt bei 240 CA-Policies pro Tenant, gezählt über alle Zustände – Report-Only, On und Off. Report-Only-Policies zählen gegen dieses Limit! Prüfe regelmäßig deinen Bestand:

Connect-MgGraph -Scopes 'Policy.Read.All'
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, Id | Sort-Object State

Policies, die du nicht mehr benötigst oder die dauerhaft im Report-Only-Modus schlafen, solltest du entweder aktivieren oder löschen. Gelöschte Policies lassen sich innerhalb von 30 Tagen wiederherstellen (Soft-Delete).

Seit Februar 2025 rollt Microsoft automatisch Microsoft-verwaltete Policies in Tenants aus – initial im Report-Only-Modus. Admins haben mindestens 45 Tage Prüfzeit, bevor die Policy automatisch auf „On" wechselt. Behalte den Tenant deshalb im Blick und prüfe regelmäßig neu hinzugefügte Policies.

Empfohlene Deployment-Reihenfolge

Microsoft empfiehlt drei Phasen für den gestaffelten Rollout:

Phase	Zeitraum	Maßnahmen	Lizenz
Phase 1	Woche 1–2	Legacy-Auth blockieren, MFA-Registrierungsseite absichern, Phishing-resistentes MFA für Admins	Entra P1
Phase 2	Woche 2–3	MFA für alle User und Gäste, App Protection für Mobile, Compliant Device für Admins	Entra P1 + Intune
Phase 3	Woche 3–4	Risk-based Policies (Sign-in/User Risk), Token Protection, Device Code Flow blockieren	Entra P2

Troubleshooting / Typische Fehler

Alle Geräte nach „Require Compliant Device" gesperrt: Keine Intune Compliance Policy vorhanden. Erstelle zuerst eine Compliance Policy in Intune, warte bis Geräte den Status „compliant" erhalten, dann erst CA aktivieren. Im Report-Only-Modus lässt sich das vorab prüfen.
Nutzer nach Token Protection hart geblockt: Token Protection gilt nur für native Apps. Browser-Sessions oder nicht unterstützte Clients werden geblockt. Report-Only-Logs prüfen, betroffene Apps aus dem Scope nehmen oder die Policy vorerst auf Windows-native-Apps beschränken.
Drucker/MFPs senden nach Legacy-Auth-Block keine Mails mehr: Gerät nutzt SMTP mit Basic Auth. Lösung: Gerät auf OAuth/Modern Auth umstellen, SMTP Relay über Microsoft 365 konfigurieren oder ein dediziertes App-Passwort einrichten.
Break-Glass-Konto vergessen auszuschließen: Bei fehlerhafter Policy kann der gesamte Admin-Zugriff verloren gehen. Recovery erfordert Microsoft Support. Vor jeder Policy-Aktivierung prüfen: Ist CA-BreakGlass-Accounts in den Exclusions?
Gäste mit Adminrollen werden nicht von Admin-Persona-Policies erfasst: Die Admin-Persona schließt Gäste explizit aus – auch wenn diese Adminrollen tragen. Für B2B-Admins separate Policy erstellen oder in die Gäste-Persona-Policy aufnehmen.
240-Policy-Limit erreicht: Report-Only- und Off-Policies zählen mit. Nicht mehr benötigte Policies löschen (30-Tage-Soft-Delete). What-If-Tool und Reporting Workbook zur Konsolidierung nutzen.
Microsoft-verwaltete Policy unerwartet aktiviert: Microsoft setzt automatisch ausgerollte Policies nach mindestens 45 Tagen Report-Only auf „On". Audit Logs und Benachrichtigungen im Entra Admin Center regelmäßig prüfen.
Security Defaults noch aktiv: CA-Policies greifen nicht, solange Security Defaults aktiv sind. In Entra ID unter „Properties" deaktivieren, bevor CA konfiguriert wird.

Häufige Fragen

Brauche ich Entra P2 für Token Protection?

Nein. Token Protection ist eine CA-Session-Control und erfordert nur Microsoft Entra ID P1. Entra P2 wird erst für risikobasierte Policies (Sign-in Risk, User Risk) benötigt.

Werden Geräte blockiert, während sie sich bei Intune einschreiben?

Nein. Microsoft hat diese Ausnahme explizit eingebaut: Die Intune-Enrollment-Erfahrung wird durch „Require device to be marked as compliant" nicht blockiert, damit der First-Time-Enrollment-Flow funktioniert. Das Problem tritt auf, wenn bereits eingeschriebene Geräte plötzlich als non-compliant gelten, weil noch keine Intune Compliance Policy existiert.

Im Entra-Anmeldeprotokoll die Spalte „Client App" hinzufügen. Legacy-Protokolle erscheinen als „Exchange ActiveSync", „IMAP", „POP3", „SMTP" oder „Other clients". Modern Auth erscheint als „Browser" oder „Mobile Apps and Desktop clients". Unbedingt auch den Tab „User sign-ins (non-interactive)" prüfen – dort tauchen Hintergrunddienste und ältere Clients auf, die im interaktiven Tab nicht sichtbar sind.

Kann ich Token Protection für Gastkonten aktivieren?

In der Regel nicht sinnvoll. Token Protection setzt voraus, dass das Gerät bei Entra ID registriert ist und ein Primary Refresh Token ausstellt. B2B-Gäste nutzen ihre eigenen Tenants und Geräte, sodass Token Protection für Gäste typischerweise nicht greift.

Was passiert, wenn ich eine CA-Policy lösche?

Gelöschte Policies können innerhalb von 30 Tagen (Soft-Delete-Zeitraum) wiederhergestellt werden. Nach 30 Tagen ist die Policy permanent verloren. Policies, die du nicht mehr brauchst, aber eventuell noch einmal benötigst, kannst du stattdessen auf „Off" setzen.

Was ist Exclusion Drift und wie verhindere ich ihn?

Exclusion Drift entsteht, wenn Nutzer dauerhaft aus Policies ausgeschlossen bleiben – oft wegen kurzfristiger Helpdesk-Tickets, die niemand schließt. Vergib Ausschlüsse nur temporär mit dokumentiertem Ablaufdatum und nutze Microsoft Entra ID Access Reviews, um regelmäßig zu prüfen, wer noch ausgeschlossen ist.

Wie viele Personas brauche ich mindestens?

Microsoft empfiehlt drei Kern-Personas (Admins, Internals, Guests). In kleinen Organisationen kannst du mit zwei beginnen: Admins und alle anderen. Weitere optionale Personas für spätere Stufen: Developers/DevOps, Externals (Nicht-Gäste-Partner) und Service Accounts als Workload Identities.

Fazit

Ein reifes Conditional-Access-Framework ist kein einmaliges Projekt, sondern ein lebendiges System. Der Weg führt vom einfachen MFA-Einschalten über Persona-basierte Rings, Geräte-Compliance und Token Protection bis hin zu risikobasierter Auswertung. Der schnellste Return on Investment liegt beim Legacy-Auth-Block: eine Policy, die in weniger als einer Stunde konfiguriert und getestet ist, schließt den Hauptangriffsvektor für Credential-Stuffing und Password Spray. Nutze für jede neue Policy konsequent den Report-Only-Modus, schließe Break-Glass-Konten aus allen Policies aus und halte den Policy-Bestand unter dem 240er-Limit. Wer Entra ID P2 hat, kann in Phase 3 mit risikobasierten Policies weitermachen – das Fundament dafür legt dieses Framework. Mehr zur Benutzerverwaltung in Entra findest du in der Anleitung Entra ID: Benutzer, Gruppen und Lizenzen verwalten.

Weiterführende Anleitungen und Quellen

Quellen: Microsoft Learn: Plan Your Microsoft Entra Conditional Access Deployment · Microsoft Learn: Block legacy authentication with Conditional Access · Microsoft Learn: How Token Protection Enhances Conditional Access Policies · Microsoft Learn: Conditional Access architecture and personas · Microsoft Tech Community: New Microsoft-managed policies (2025)