Conditional Access (CA) in Microsoft Entra ID ist mehr als „MFA für alle einschalten“. Ein belastbares Regelwerk ordnet Identitäten in Personas, bindet Geräte-Compliance über Intune ein, schützt Tokens gegen Wiederverwendung und blockiert Legacy-Authentifizierung. Diese Anleitung richtet sich an Administratoren, die den Einsteiger-CA-Artikel kennen und ihr Regelwerk ausbauen wollen.

Voraussetzungen

Microsoft Entra ID P1 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 als MDM-Autorität, mindestens eine Compliance Policy
Break-Glass-Konto: mindestens ein reines Cloud-Notfallkonto, das aus allen blockierenden CA-Policies ausgeschlossen ist. Wegen der verpflichtenden MFA für Admin-Portale meldet es sich per Passkey (FIDO2) oder Zertifikat an
Rolle „Conditional Access Administrator“ (Erstellen/Ändern) oder „Security Reader“ (nur lesen) in Entra ID
Security Defaults deaktiviert: Security Defaults und Conditional Access lassen sich nicht gleichzeitig nutzen; schalten Sie Security Defaults vorher ab
Optional: Log Analytics Workspace für das Workbook „Conditional Access Insights and Reporting“

Schritt 1: Das Persona-Framework verstehen und Gruppen anlegen

Microsoft empfiehlt drei Kern-Personas mit jeweils eigenen Policies:

Persona	Wer gehört dazu	Typische Controls
Admins	Cloud- oder synchronisierte Konten mit einer Admin-Rolle in Entra ID oder Microsoft 365, ohne Gäste	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

Legen Sie im Entra Admin Center folgende Sicherheitsgruppen an, bevor Sie die ersten Policies erstellen:

# Empfohlene Gruppen-Benennungskonvention
CA-BreakGlass-Accounts          # Notfallkonten, aus ALLEN Policies ausschließen
CA-Persona-Admins-Exclusion     # Temporäre Ausnahmen für Admin-Persona-Policies
CA-Persona-Internals-Exclusion  # Temporäre Ausnahmen für Internals-Persona-Policies
CA-TokenProtection-Pilot        # Pilotgruppe für Token Protection

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].

Verifizieren: Unter Entra ID > Gruppen existieren die vier Gruppen, CA-BreakGlass-Accounts enthält die Notfallkonten.

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

Nach Microsoft-Analyse nutzen mehr als 97 Prozent der Credential-Stuffing- und mehr als 99 Prozent der Password-Spray-Angriffe Legacy-Protokolle (IMAP, POP3, SMTP AUTH mit Basic Auth, Exchange ActiveSync ohne Modern Auth). Diese Protokolle können keine MFA.

Vor dem Aktivieren: Prüfen Sie die Anmeldeprotokolle auf Legacy-Auth. Drucker und Scan-to-Mail-Geräte nutzen oft SMTP mit Basic Auth und werden danach blockiert.

# Anmeldeprotokolle auf Legacy-Auth prüfen
# Pfad: entra.microsoft.com > Entra ID > Monitoring & health > Sign-in logs
# Spalte "Client App" hinzufügen (Columns-Button)
# Add filters > Client App > alle Legacy-Protokolle auswählen
# WICHTIG: Auch Tab "User sign-ins (non-interactive)" prüfen!
# 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, ältere Office-Clients ab)

# Access controls > Grant: Block access

# Enable policy: Report-only  <-- ERST nach Prüfung 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

Lassen Sie die Policy mindestens eine Woche im Report-Only-Modus laufen. Im Anmeldeprotokoll zeigt der Tab „Report-only“ je Ereignis das Ergebnis. Stellen Sie betroffene Geräte auf OAuth oder SMTP-Relay über einen Exchange-Online-Connector um (App-Kennwörter sind ebenfalls Legacy-Auth). Erst danach schalten Sie auf „On“.

Verifizieren: Im Anmeldeprotokoll zeigt der Tab „Report-only“ für CA001 bei Legacy-Anmeldungen „Report-only: Failure“, für moderne Clients „Not applied“. Nach dem Umschalten auf „On“ erscheinen Legacy-Versuche mit Fehlercode 53003.

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

Einmalcodes und SMS schützen nicht gegen AitM-Phishing. Für Admins setzen Sie deshalb die Authentication Strength „Phishing-resistant MFA“ ein (FIDO2, Windows Hello for Business, zertifikatbasierte Authentifizierung).

# 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

# Enable policy: Report-only

Admins registrieren FIDO2-Schlüssel oder Windows Hello vor der Aktivierung, sonst sperren sie sich aus.

Verifizieren: Mit dem What-If-Tool (Conditional Access > Policies > What If) für einen Admin-Benutzer erscheint CA002 unter den angewendeten Policies; die Break-Glass-Konten tauchen dort nicht auf.

Schritt 4: Geräte-Compliance mit Intune erzwingen

„Require device to be marked as compliant“ lässt nur Geräte zu, die Intune als konform meldet (verschlüsselt, aktuelles Betriebssystem, kein Jailbreak usw.).

Kritischer Punkt: Ohne Intune Compliance Policy gelten alle Geräte als nicht konform und werden sofort gesperrt. Erstellen Sie die Compliance Policy in Intune (intune.microsoft.com), bevor Sie die CA-Kontrolle aktivieren.

Wie Sie Compliance Policies konfigurieren, 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 gilt: Report-Only, dann eine Pilotabteilung, dann schrittweise ausweiten. Die Übersicht unter intune.microsoft.com > Devices > Compliance zeigt, welche Geräte derzeit nicht konform wären.

Verifizieren: In der Compliance-Übersicht stehen alle Admin-Geräte auf „Compliant“; im Report-only-Tab der Anmeldungen zeigt CA003 für diese Geräte „Report-only: Success“.

Schritt 5: Token Protection im Report-Only testen

Token Protection ist ein Session-Control in CA, das Anmeldesitzungstokens kryptografisch an das Gerät bindet. Gestohlene Tokens lassen sich auf einem anderen Gerät nicht mehr verwenden.

Plattform-Unterstützung (Stand September 2026):

Plattform	Status	Mindestanforderung
Windows	Allgemein verfügbar (native Apps)	Windows 10+, Entra-joined/Hybrid-joined/Entra-registered; Windows Server 2019+ wenn Hybrid-joined
macOS	Allgemein verfügbar (native Apps)	macOS 14.0+, MDM-verwaltet, Enterprise SSO-Plugin oder Platform SSO
iOS/iPadOS	Allgemein verfügbar (native Apps)	iOS/iPadOS 16.0+, MDM-verwaltet, Enterprise SSO-Plugin
Browser-Apps	Preview, nur Windows und macOS	nur ausgewählte Web-Apps mit Zugriff auf Azure Resource Manager

Wichtig: Für Exchange, SharePoint und Teams wirkt Token Protection nur in nativen Apps. Greift die Policy bei Browser-Sitzungen oder nicht unterstützten Clients, werden Benutzer blockiert. Beginnen Sie deshalb mit Report-Only und einer kleinen Pilotgruppe.

Durchsetzbar für Exchange Online, SharePoint Online und Microsoft Teams, unter Windows zusätzlich für 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"

Lassen Sie die Policy mindestens zwei Wochen im Report-Only-Modus laufen. Erst wenn keine unerwarteten Treffer mehr erscheinen, aktivieren Sie sie für die Pilotgruppe und weiten sie schrittweise aus.

Verifizieren: Im Report-only-Tab der Pilotanmeldungen zeigt CA010 für Outlook, Teams und OneDrive-Client „Report-only: Success“; „Failure“ erscheint nur bei Browser-Sitzungen oder nicht registrierten Geräten.

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

Ein Tenant kann höchstens 240 CA-Policies enthalten, gezählt über alle Zustände (Report-Only, On, Off). Prüfen Sie den Bestand regelmäßig:

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

Aktivieren oder löschen Sie Policies, die dauerhaft im Report-Only-Modus liegen. Gelöschte Policies lassen sich innerhalb von 30 Tagen wiederherstellen (Soft-Delete).

Microsoft-verwaltete Policies legt Microsoft im Report-Only-Modus an und schaltet sie frühestens 30 Tage später auf „On“, angekündigt zwei Wochen vorher im Message Center. Schließen Sie dort die Notfallkonten aus.

Verifizieren: Der Befehl listet alle Policies mit State enabled, enabledForReportingButNotEnforced oder disabled; die Gesamtzahl ((Get-MgIdentityConditionalAccessPolicy).Count) liegt deutlich unter 240, jede Policy trägt ein CA- oder EM-Präfix oder ist Microsoft-verwaltet.

Empfohlene Deployment-Reihenfolge

Bewährt hat sich ein Rollout in drei Phasen:

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. Siehe Schritt 4.
Nutzer nach Token Protection hart geblockt: Browser-Sitzung oder nicht unterstützter Client. Betroffene Apps oder Plattformen aus dem Scope nehmen.
Drucker/MFPs senden nach Legacy-Auth-Block keine Mails mehr: Gerät nutzt SMTP AUTH mit Basic Auth. Lösung: Gerät auf OAuth umstellen oder SMTP-Relay über einen Exchange-Online-Connector einrichten. App-Kennwörter funktionieren hier nicht.
Break-Glass-Konto vergessen auszuschließen: Eine fehlerhafte Policy kann alle Admins aussperren; dann hilft nur der Microsoft-Support. Vor jeder Aktivierung prüfen, ob CA-BreakGlass-Accounts ausgeschlossen ist.
Gäste mit Adminrollen werden nicht von Admin-Persona-Policies erfasst: Die Admin-Persona schließt Gäste aus. Für B2B-Admins eine eigene Policy anlegen.
240-Policy-Limit erreicht: Report-Only- und Off-Policies zählen mit. Nicht benötigte Policies löschen und ähnliche zusammenführen.
Microsoft-verwaltete Policy unerwartet aktiviert: Siehe Schritt 6; Policy prüfen und bewusst auf „On“ oder „Off“ setzen.
Security Defaults noch aktiv: Unter Entra ID > Übersicht > Eigenschaften > Sicherheitsstandards verwalten abschalten, bevor Sie CA aktivieren.

Häufige Fragen

Brauche ich Entra P2 für Token Protection?

Nein, Entra ID P1 genügt. P2 ist nur für risikobasierte Policies nötig.

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

Nein. Die Ersteinrichtung bei Intune ist von der Kontrolle ausgenommen.

Über die Spalte „Client App“ im Anmeldeprotokoll (siehe Schritt 2). Modern Auth erscheint dort als „Browser“ oder „Mobile Apps and Desktop clients“, alles andere ist Legacy. Prüfen Sie auch die nicht interaktiven Anmeldungen.

Kann ich Token Protection für Gastkonten aktivieren?

In der Regel nicht sinnvoll. Es setzt ein im eigenen Tenant registriertes Gerät voraus, das Gäste nicht haben.

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

Sie lässt sich 30 Tage lang wiederherstellen. Policies, die Sie eventuell wieder brauchen, setzen Sie besser auf „Off“.

Was ist Exclusion Drift und wie verhindere ich ihn?

Befristet gedachte Ausschlüsse bleiben dauerhaft bestehen. Vergeben Sie Ausschlüsse mit dokumentiertem Ablaufdatum und prüfen Sie die Ausnahmegruppen regelmäßig mit Access Reviews (Entra ID Governance bzw. P2).

Wie viele Personas brauche ich mindestens?

Drei (Admins, Internals, Guests). Kleine Organisationen beginnen mit zwei: Admins und alle anderen. Später kommen bei Bedarf Developers, Externals und Workload Identities hinzu.

Fazit

Ein CA-Regelwerk wächst schrittweise von MFA über Personas, Geräte-Compliance und Token Protection bis zu risikobasierten Policies (P2). Starten Sie jede neue Policy im Report-Only-Modus und schließen Sie die Break-Glass-Konten aus allen blockierenden Policies aus. Zur Benutzerverwaltung siehe 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)