Conditional Access Templates 2025

Warum wir (wieder) über Conditional Access (Bedingter Zugriff) sprechen müssen

Innerhalb von Microsoft‑365 verschiebt sich der Fokus gerade spürbar weg von klassischen Perimeterschutz‑Konzepten hin zu Identitäts‑basierter Sicherheit.

Spätestens mit den März‑/April‑Updates 2025 hält Microsoft Unternehmen den Spiegel vor: Neue Microsoft‑managed Conditional Access Policies begrenzen Device‑Code‑Flows und blockieren veraltete Authentifizierungsverfahren automatisiert, ohne dass Admins erst eigene Regeln bauen müssen.

Gleichzeitig hat das Produktteam die Conditional Access Templates überarbeitet, damit wir bewährte Zero‑Trust‑Regeln in wenigen Minuten ausrollen können – exakt abgestimmt auf Unternehmensgröße, Lizenzstatus und Risikoprofil.

Kurzum: Wer sein Tenant 2025 noch mit Security Defaults „absichert“, lässt unnötig Angriffsfläche liegen und riskiert zusätzlich Mehrarbeit, wenn später individuelle Policies nachgezogen werden müssen.

Was ist Conditional Access?

Conditional Access (CA) ist Microsofts Policy‑Engine, die Anmelde‑ und Sitzungs­signale sammelt, bewertet und basierend darauf den Zugriff erlaubt, einschränkt oder blockiert – Kernbestandteil jeder Zero‑Trust‑Strategie. Die Evaluation erfolgt in zwei Phasen: Phase 1 sammelt Kontext (z. B. Standort, Gerätestatus), Phase 2 erzwingt die definierten Kontrollen.

Schlüsselkomponenten

• Assignments (Benutzer, Gruppen, Rollen, Apps) definieren das Wer und Was.
  
• Conditions (Gerätekonformität, Standort, Risiko) beschreiben das Wie der Anmeldung.
  
• Grant/Session Controls legen das Ob und Wie lange fest – z. B. MFA erzwingen oder Uploads in Teams blockieren.
  
• Policy Mode: Report‑Only, On, Off – wobei Report‑Only keine Live‑Sperre auslöst, aber Telemetrie liefert.

Neu 2025 – Templates & Microsoft-Policies

Conditional Access Templates 2025

Die überarbeiteten Templates gruppieren Richtlinien erstmals nach Schutz­zielen (Identity Protection, Secure Cloud Apps, Baseline Zero Trust) und starten standardmäßig im Report‑Only‑Modus, um Fehlalarme vor Produktiv­schaltung sichtbar zu machen.

Microsoft‑Managed Policies

Seit März 2025 liefert Microsoft vorkonfigurierte, schreibgeschützte Policies aus, die zum Beispiel Legacy‑Authentifizierung oder Device‑Code‑Flows blockieren. Admins dürfen nur ausschließen oder den Modus wechseln, nicht aber löschen oder umbenennen.

Template‑Familien im Detail

Die Vorlagen orientieren sich weiterhin an Signal → Decision → Enforcement, bauen also auf die gleichen Kernelemente wie manuell erstellte Policies auf, bleiben aber deutlich lesbarer.

Von der Vorlage zur produktiven Richtlinie

Schritt‑für‑Schritt

1. Rollen prüfen
   Nur Conditional Access Administrator oder Security Administrator dürfen Templates deployen. Wer PIM nutzt, sollte die Rolle erst just‑in‑time aktivieren.
   
2. Vorlage auswählen und Duplikat anlegen
   Templates lassen sich nicht bearbeiten; erstelle deshalb sofort eine Kopie. So bleibt die Referenz erhalten, falls Microsoft später Änderungen pusht.
   
3. Report‑Only aktiv halten (min. 7 Tage)
   Achte vor allem auf Service‑Konten: Skripte, Connect‑Sync‑Accounts und Automationen können sonst unerwartet scheitern.
   
4. Break‑Glass‑Konten ausschließen
   Mindestens zwei Konten mit Cloud‑only‑Kennwort und phish‑resistenter MFA bleiben von allen Policies ausgenommen – die letzte Rettung bei Fehlkonfiguration.
   
5. Benannte Standorte hinterlegen
   In 2025 lassen sich nicht nur IP‑Ranges, sondern auch “trusted device signal” und Network Location conditions kombinieren. So bleibt zum Beispiel der Firmenstandort von MFA‑Pflichten befreit, ohne dass Heim‑VPN‑Zugriffe durchrutschen.
   
6. Testgruppen sukzessive erweitern
   Starte mit IT‑Team, dann Führungskräfte, dann alle User. Monitor und Sign‑In‑Logs liefern Impact‑Analyse in Echtzeit.
   
7. Policy aktivieren (On)
   Erst wenn keine signifikanten Errors oder User‑Beschwerden mehr auftauchen.

Stolperfallen & Best Practices

• Security Defaults abschalten: Templates und Security Defaults schließen sich weiter gegenseitig aus. Ein schleichender Wechsel führt zu nicht reproduzierbaren Ausnahmen.
  
• Namens­konventionen: Ein Präfix wie CA-BL-v1-RequireMFA-AllUsers erleichtert späteres Reporting und automatisierte Dokumentation.
  
• Service Accounts umstellen: Legacy‑Auth‑Block kann Cron‑Jobs killen – Managed Identity ist der sauberste Weg.
  
• Least Privilege für Break‑Glass: Die Notfall‑Konten brauchen keine globale Admin‑Rolle, wenn ein dediziertes Recovery‑Runbook existiert.
  
• Monitoring automatisieren: Mit Azure Log Analytics oder Defender for Cloud Apps lassen sich sign‑in‑Patterns korrelieren und Risky‑User‑Alerts schneller triagieren.

KI‑Turbo: Der Conditional Access Agent

Seit Frühjahr 2025 testet Microsoft den Conditional Access Optimization Agent im Rahmen von Security Copilot. Die Idee: Ein KI‑Agent analysiert kontinuierlich Sign‑In‑Logs, erkennt Redundanzen, schlägt Optimierungen vor und kann Policy‑Drift automatisch korrigieren. In ersten Previews wurden pro Tenant über 700 Tsd. Anmeldungen ausgewertet, um verwaiste Regeln zu identifizieren.

Das klingt nach Overkill, doch rechnet man interne Audit‑Aufwände gegen die Copilot‑Tarifierung (Stichwort Security Compute Units), wird schnell klar: Ab 250+ Mitarbeitern lohnt sich das Experiment messbar – zumal der Agent seine Vorschläge in Git‑ähnliche Pull‑Requests übersetzt, die sich versioniert ausrollen lassen.

Lizenzierung & Voraussetzungen

• Microsoft‑managed Policies stehen allen Entra ID‑Lizenzen zur Verfügung
  – aber einige der neuen Templates erfordern P1/P2‑Features:
  
• Microsoft Entra ID P1 für Basis‑CA, P2 für Risiko‑Signale & Identity Protection.
• Reporterstellung erfordert Azure Monitor / Log Analytics Workspace.
• Security Copilot mit Optimization Agent wird separat lizenziert.

Fazit – Zero Trust zum Anfassen

Mit den überarbeiteten Conditional Access Templates liefert Microsoft 2025 das fehlende Bindeglied zwischen Security Defaults und einer vollumfänglichen Zero‑Trust‑Architektur. Selbst kleine IT‑Teams können jetzt in wenigen Stunden Policies deployen, die früher Tage gedauert hätten. Wer den Prozess strukturiert angeht – Vorlage klonen, Report‑Only, gestafferte Aktivierung – minimiert Risiken und baut gleichzeitig ein solides Fundament für KI‑gestützte Optimierungen.

Nächste Schritte:

1. Templates testen, Report‑Only aktiv lassen
2. Break‑Glass‑Konten verifizieren
3. Security Defaults deaktivieren
4. Monitoring automatisieren
5. Copilot‑Pilotgruppe für den Optimization Agent anmelden

So hebst du dein Tenant auf das Sicherheitsniveau, das Microsoft künftig voraussetzt – und zwar ohne die typische Trial‑and‑Error‑Odyssee.