Mit MFA und Conditional Access in Entra ID sicherst du deinen Microsoft-365-Tenant gegen die häufigsten Angriffe ab: Phishing, Password-Spray und Credential-Stuffing. Diese Anleitung richtet sich an IT-Admins im Mittelstand und zeigt dir Schritt für Schritt, wie du Multi-Faktor-Authentifizierung für alle Nutzer erzwingst, vier praxiserprobte Conditional-Access-Richtlinien anlegst, sie im Report-only-Modus risikofrei testest und ein Notfall-Konto vor dem Aussperren absicherst. Du arbeitest wahlweise im Entra Admin Center oder per Microsoft Graph PowerShell.

Voraussetzungen

Rolle Conditional Access Administrator oder Global Administrator im Tenant
Entra ID P1 für Conditional Access (enthalten in Microsoft 365 E3/E5 und Business Premium)
Entra ID P2 / ID Protection für risikobasierte Richtlinien (Sign-in-Risk, User-Risk)
Microsoft Graph PowerShell SDK für den Skript-Weg: Install-Module Microsoft.Graph -Scope CurrentUser
Security Defaults sind deaktiviert, sobald eine Conditional-Access-Richtlinie aktiv ist – beides lässt sich nicht kombinieren
Ein Test-Benutzer ohne Adminrechte, um Richtlinien praktisch zu prüfen

Schritt 1: Security Defaults und Conditional Access abgrenzen

Bevor du loslegst, entscheide dich für ein Modell. Beides gleichzeitig geht nicht.

Merkmal	Security Defaults	Conditional Access
Lizenz	kostenlos (alle Tenants)	Entra ID P1 (P2 für Risiko)
MFA erzwingen	für alle, pauschal	granular per Richtlinie
Legacy-Auth blockieren	ja, fest	ja, konfigurierbar
Ausnahmen / Standorte	nein	ja (Benutzer, Apps, Standorte, Risiko)
Report-only-Test	nein	ja

Security Defaults sind für sehr kleine Umgebungen ohne P1-Lizenz sinnvoll. Sobald du Ausnahmen für ein Break-Glass-Konto, vertraute Standorte oder Risikobedingungen brauchst, führt kein Weg an Conditional Access vorbei. Den aktuellen Status findest du unter entra.microsoft.com → Entra ID → Übersicht → Properties → Manage security defaults.

Schritt 2: Break-Glass-Konten anlegen und absichern

Das wichtigste zuerst. Ein Break-Glass-Konto (Notfall-Zugang) verhindert, dass du dich durch eine zu strenge Richtlinie komplett aus dem Tenant aussperrst. Lege zwei reine Cloud-Konten an, die von restriktiven Richtlinien ausgenommen sind.

Microsoft 365 Admin Center → Users → Active users → Add user
Zwei Cloud-only-Konten erstellen, z. B. breakglass1@DEINE-DOMAIN.onmicrosoft.com und breakglass2@DEINE-DOMAIN.onmicrosoft.com
Lange, zufällige Kennwörter vergeben und sicher (offline, im Tresor) hinterlegen
Entra ID → Roles and admins → Global administrator → Add assignments – beiden Konten die Rolle zuweisen
Beide Konten mit FIDO2-Sicherheitsschlüssel oder zertifikatsbasierter Authentifizierung (CBA) absichern – nicht mit der Authenticator-App eines einzelnen Mitarbeiters
Beide Konten in einer dedizierten Gruppe EmergencyAccess zusammenfassen (für die Ausnahmen in den folgenden Richtlinien)

Die Gruppe legst du per Graph PowerShell so an:

# Mit den nötigen Scopes anmelden
Connect-MgGraph -Scopes 'Group.ReadWrite.All', 'User.Read.All'

# Sicherheitsgruppe fuer Break-Glass-Konten anlegen
New-MgGroup -DisplayName 'EmergencyAccess' `
  -MailEnabled:$false `
  -MailNickname 'EmergencyAccess' `
  -SecurityEnabled:$true

Notiere dir die Id der Gruppe – du brauchst sie gleich zum Ausschließen.

Schritt 3: MFA-Methoden festlegen

Lege zentral fest, welche MFA-Methoden deine Nutzer registrieren dürfen. Phishing-resistente Methoden sind klar zu bevorzugen.

Microsoft Authenticator: Push-Benachrichtigung mit Nummernabgleich, auch als Passwordless-Methode
FIDO2 / Passkeys: phishing-resistent, ideal für Admins und Break-Glass-Konten
Windows Hello for Business: integriert auf verwalteten Geräten
CBA (Certificate-Based Authentication): zertifikatsbasiert, ebenfalls phishing-resistent

Die Methoden konfigurierst du unter entra.microsoft.com → Entra ID → Authentication methods → Policies. Aktiviere mindestens Microsoft Authenticator und FIDO2. Plane eine Registrierungsphase ein: Nutzer müssen ihre MFA-Methode registrieren, bevor du eine phishing-resistente Richtlinie erzwingst, sonst läuft die Anmeldung in den Fehler AADSTS53004.

Schritt 4: Richtlinie 1 – MFA für alle Nutzer (Report-only)

Diese Richtlinie verlangt von allen Nutzern eine Multi-Faktor-Authentifizierung und nimmt nur die Break-Glass-Konten aus.

entra.microsoft.com → Entra ID → Conditional Access → Policies → New policy
Name: CA001-Require-MFA-All-Users
Assignments → Users: Include = All users; Exclude = Gruppe EmergencyAccess
Target resources: All resources (formerly All cloud apps)
Grant: Grant access → Require authentication strength → Multifactor authentication
Enable policy: auf Report-only stellen, dann Create

Per Graph PowerShell legst du dieselbe Richtlinie so an (Status enabledForReportingButNotEnforced = Report-only):

Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess', 'Application.Read.All'

$params = @{
  displayName = 'CA001-Require-MFA-All-Users'
  state       = 'enabledForReportingButNotEnforced'
  conditions  = @{
    users = @{
      includeUsers  = @('All')
      excludeGroups = @('GUID-DER-EMERGENCYACCESS-GRUPPE')
    }
    applications = @{ includeApplications = @('All') }
  }
  grantControls = @{
    operator        = 'OR'
    builtInControls = @('mfa')
  }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Ersetze GUID-DER-EMERGENCYACCESS-GRUPPE durch die Objekt-Id aus Schritt 2.

Schritt 5: Richtlinie 2 – Legacy-Authentifizierung blockieren

Legacy-Protokolle wie IMAP, POP3, SMTP-Auth und ältere Office-Clients unterstützen kein MFA. Über 97 % aller Credential-Stuffing- und über 99 % aller Password-Spray-Angriffe nutzen genau diese Protokolle. Prüfe vorher, welche Clients noch Legacy-Auth verwenden.

Entra ID → Monitoring & health → Sign-in logs
Spalte Client App einblenden und nach Legacy authentication clients filtern
Betroffene Nutzer und Dienste identifizieren und umstellen, bevor du blockierst

Dann die Richtlinie anlegen:

Conditional Access → Policies → New policy, Name: CA002-Block-Legacy-Auth
Users: Include = All users; Exclude = EmergencyAccess und benötigte Service-Konten
Target resources: All resources
Conditions → Client apps: nur Exchange ActiveSync clients und Other clients aktivieren
Grant: Block access
Enable policy: Report-only, dann Create

$params = @{
  displayName = 'CA002-Block-Legacy-Auth'
  state       = 'enabledForReportingButNotEnforced'
  conditions  = @{
    users = @{
      includeUsers  = @('All')
      excludeGroups = @('GUID-DER-EMERGENCYACCESS-GRUPPE')
    }
    applications = @{ includeApplications = @('All') }
    clientAppTypes = @('exchangeActiveSync', 'other')
  }
  grantControls = @{
    operator        = 'OR'
    builtInControls = @('block')
  }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Schritt 6: Richtlinie 3 – MFA außerhalb vertrauter Standorte

Diese Richtlinie verlangt MFA überall – außer aus deinem Firmennetz, dessen öffentliche IP-Bereiche du als vertrauten Standort definierst. Zuerst den Named Location anlegen.

Conditional Access → Named locations → IP ranges location
Name: Firmenstandort-HQ
IPv4-Bereich im CIDR-Format eintragen, z. B. 203.0.113.0/24 (nicht als Bereich 203.0.113.1-50)
Haken bei Mark as trusted location, dann Create

Dann die Richtlinie:

New policy, Name: CA003-Require-MFA-Untrusted-Locations
Users: Include = All users; Exclude = EmergencyAccess
Target resources: All resources
Conditions → Locations: Include = Any location; Exclude = All trusted locations
Grant: Require multifactor authentication
Enable policy: Report-only, dann Create

So greift MFA nur bei Anmeldungen außerhalb der vertrauten IP-Bereiche – im Büro arbeiten die Nutzer reibungslos weiter.

Schritt 7: Richtlinie 4 – MFA bei riskanten Anmeldungen (P2)

Diese Richtlinie benötigt Entra ID P2 / ID Protection. Sie verlangt MFA, sobald Entra ID eine Anmeldung als riskant einstuft (z. B. anonyme IP, ungewöhnlicher Standort).

New policy, Name: CA004-Require-MFA-Sign-in-Risk
Users: Include = All users; Exclude = EmergencyAccess
Target resources: All resources
Conditions → Sign-in risk: Haken bei High und Medium
Grant: Require authentication strength → Multifactor authentication
Enable policy: Report-only, dann Create

$params = @{
  displayName = 'CA004-Require-MFA-Sign-in-Risk'
  state       = 'enabledForReportingButNotEnforced'
  conditions  = @{
    users = @{
      includeUsers  = @('All')
      excludeGroups = @('GUID-DER-EMERGENCYACCESS-GRUPPE')
    }
    applications = @{ includeApplications = @('All') }
    signInRiskLevels = @('high', 'medium')
  }
  grantControls = @{
    operator        = 'OR'
    builtInControls = @('mfa')
  }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Hinweis: Die alten Legacy-Risk-Policies werden zum 01.10.2026 eingestellt. Setze risikobasierte Anforderungen daher direkt über Conditional Access um.

Schritt 8: Richtlinien testen und scharf schalten

Lass alle vier Richtlinien mindestens 5 bis 7 Arbeitstage im Report-only-Modus laufen. So erfasst du auch Wochenend-Automationen und Legacy-Jobs, die nur selten anlaufen.

Entra ID → Monitoring & health → Sign-in logs öffnen
Eine Anmeldung anklicken, Reiter Report-only – dort siehst du, welche Richtlinie gegriffen hätte
Auffällige Treffer prüfen: Wurden wichtige Service-Konten oder Legacy-Dienste unerwartet betroffen?
Ausnahmen anpassen, bis keine ungewollten Blockaden mehr auftreten

Erst dann auf On wechseln. Per PowerShell prüfst und aktivierst du eine Richtlinie so:

# Alle Richtlinien mit Status auflisten
Connect-MgGraph -Scopes 'Policy.Read.All'
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, Id, State

# Richtlinie scharf schalten (Report-only -> On)
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'
$policy = Get-MgIdentityConditionalAccessPolicy `
  -Filter "displayName eq 'CA001-Require-MFA-All-Users'"
Update-MgIdentityConditionalAccessPolicy `
  -ConditionalAccessPolicyId $policy.Id `
  -State 'enabled'

Schalte die Richtlinien einzeln und gestaffelt scharf, nicht alle auf einmal – so lassen sich Auswirkungen leichter zuordnen.

Troubleshooting

Problem: Du bist komplett ausgesperrt. Melde dich mit einem Break-Glass-Konto an, das von allen restriktiven Richtlinien ausgenommen ist. Prüfe danach die zuletzt geänderte Richtlinie unter Audit logs.
Problem: Nutzer bekommt AADSTS53004. Die phishing-resistente MFA-Methode ist noch nicht registriert. Plane eine Registrierungsphase mit einer schwächeren Anforderung, bevor du die strenge Richtlinie erzwingst.
Problem: Directory Sync oder Forms-Sync schlägt fehl. Service-Principals und Sync-Konten sind nicht ausgenommen. Nimm die betroffenen Konten in den Ausschlüssen der MFA-Richtlinie auf.
Problem: Geräte gelten nie als compliant. Require compliant device setzt Intune-Enrollment voraus. Ohne Intune ist kein Gerät compliant – dann blockiert die Richtlinie alles.
Problem: Named Location greift nicht. Prüfe das IP-Format. Nutze CIDR (203.0.113.0/24), keine Bereichsangaben wie 203.0.113.1-50.
Problem: PowerShell verweigert das Erstellen. Der Scope fehlt. Verbinde mit Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess', nicht nur mit Policy.Read.All.
Problem: Richtlinie hat keine Wirkung. Prüfe den State. Korrekt sind enabledForReportingButNotEnforced (Report-only), enabled (On) und disabled (Off) – kein anderer Wert.

Häufige Fragen

Brauche ich für MFA zwingend Entra ID P1?

Für die pauschale MFA-Erzwingung über Security Defaults nein – das ist kostenlos. Sobald du granulare Conditional-Access-Richtlinien mit Ausnahmen, Standorten oder Report-only-Test willst, brauchst du Entra ID P1. Risikobasierte Richtlinien erfordern P2.

Was passiert mit Security Defaults, wenn ich Conditional Access aktiviere?

Sobald eine Conditional-Access-Richtlinie aktiv ist, müssen die Security Defaults deaktiviert werden – beides lässt sich nicht parallel betreiben. Plane den Umstieg so, dass durchgehend mindestens eine MFA-Richtlinie greift.

Warum brauche ich zwei Break-Glass-Konten?

Zwei Konten geben Redundanz: Fällt eine Methode aus (verlorener FIDO2-Schlüssel, abgelaufenes Zertifikat), bleibt der zweite Zugang. Beide sind reine Cloud-Konten mit Global-Admin-Rolle und von restriktiven Richtlinien ausgenommen.

Wie lange sollte ich im Report-only-Modus testen?

Mindestens 5 bis 7 Arbeitstage. Ein Tag reicht nicht, weil seltene Wochenend-Jobs, Batch-Läufe oder Legacy-Dienste sonst übersehen werden und beim Scharfschalten plötzlich blockiert sind.

Welche Client-Apps muss ich für Legacy-Auth blockieren?

Unter Conditions → Client apps aktivierst du Exchange ActiveSync clients und Other clients. Diese beiden decken die Legacy-Protokolle wie IMAP, POP3, SMTP-Auth und ältere Office-Versionen ab.

Kann ich Conditional Access komplett per PowerShell verwalten?

Ja. Mit dem Microsoft Graph PowerShell SDK und den Cmdlets New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy und Update-MgIdentityConditionalAccessPolicy erstellst, liest und aktualisierst du Richtlinien skriptgesteuert. Komplexe Bedingungen übergibst du als Hashtable über -BodyParameter.

Fazit

Mit dieser Anleitung hast du MFA und Conditional Access in Entra ID sauber aufgesetzt: Du hast Security Defaults von Conditional Access abgegrenzt, zwei Break-Glass-Konten als Notfall-Zugang abgesichert, MFA-Methoden festgelegt und vier Richtlinien angelegt – MFA für alle, Legacy-Auth blockieren, MFA außerhalb vertrauter Standorte und MFA bei riskanten Anmeldungen. Der Report-only-Modus hat dir erlaubt, alles risikofrei zu testen, bevor du gestaffelt scharf geschaltet hast. Halte die Ausnahmen minimal und prüfe sie regelmäßig, damit deine Sicherheitslage stabil bleibt.

Weiterführende Anleitungen und Quellen

Offizielle Microsoft-Dokumentation: Microsoft Entra Conditional Access Overview, Block legacy authentication with Conditional Access und Manage emergency access admin accounts.