Mit MFA und Conditional Access in Entra ID sichern Sie Ihren Microsoft-365-Tenant gegen Phishing, Password-Spray und Credential-Stuffing ab. Die Anleitung für IT-Admins im Mittelstand zeigt, wie Sie MFA für alle Nutzer erzwingen, vier Conditional-Access-Richtlinien anlegen, sie im Report-only-Modus risikofrei testen und ein Notfall-Konto gegen Aussperren absichern, 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
Hardware: zwei FIDO2-Sicherheitsschlüssel für die Break-Glass-Konten; für Admins ebenfalls FIDO2-Schlüssel oder Passkeys empfohlen. Ein Admin-Arbeitsplatz mit aktuellem Browser genügt, ein eigener Server ist nicht nötig

Hardware für diese Anleitung

Enthält Werbelinks

FIDO2-Sicherheitsschlüssel	Phishing-sicherer als Codes aus einer App. Immer zwei kaufen: einen für den Alltag, einen als Reserve an einem sicheren Ort.	Sicherheitsschlüssel bei Amazon (Werbelink)

Die Anleitung funktioniert mit jedem FIDO2-Schlüssel. * Werbelink

Schritt 1: Security Defaults und Conditional Access abgrenzen

Bevor Sie loslegen, entscheiden Sie sich 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 passen für sehr kleine Umgebungen ohne P1-Lizenz. Brauchen Sie Ausnahmen für ein Break-Glass-Konto, vertraute Standorte oder Risikobedingungen, benötigen Sie Conditional Access. Den Status finden Sie unter entra.microsoft.com → Entra ID → Overview → Properties → Manage security defaults.

Verifizieren: Unter Manage security defaults steht der Status, der zu Ihrer Entscheidung passt: für den Weg dieser Anleitung „Disabled“, sobald die erste Conditional-Access-Richtlinie aktiv ist. Unter Billing → Licenses ist Entra ID P1 (bzw. P2 für Schritt 7) vorhanden.

Schritt 2: Break-Glass-Konten anlegen und absichern

Ein Break-Glass-Konto (Notfall-Zugang) verhindert, dass Sie sich durch eine zu strenge Richtlinie aus dem Tenant aussperren. Legen Sie 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@IHRE-DOMAIN.onmicrosoft.com und breakglass2@IHRE-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 legen Sie 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

Notieren Sie die Id der Gruppe, Sie brauchen sie gleich zum Ausschließen.

Verifizieren: Beide Break-Glass-Konten melden sich in einem privaten Browserfenster mit ihrem FIDO2-Schlüssel an. Get-MgGroupMember -GroupId <Id> listet genau diese zwei Konten, und unter Roles and admins → Global administrator sind beide eingetragen.

Schritt 3: MFA-Methoden festlegen

Legen Sie zentral fest, welche MFA-Methoden Ihre 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 konfigurieren Sie unter entra.microsoft.com → Entra ID → Authentication methods → Policies. Aktivieren Sie mindestens Microsoft Authenticator und FIDO2. Planen Sie eine Registrierungsphase ein: Nutzer müssen ihre MFA-Methode registrieren, bevor Sie eine phishing-resistente Richtlinie erzwingen, sonst läuft die Anmeldung in den Fehler AADSTS53004.

Verifizieren: In der Methodenübersicht stehen Microsoft Authenticator und FIDO2 auf „Enabled“. Unter Authentication methods → User registration details sehen Sie, welche Nutzer bereits eine Methode registriert haben.

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 legen Sie eine gleichwertige 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

Ersetzen Sie GUID-DER-EMERGENCYACCESS-GRUPPE durch die Objekt-Id aus Schritt 2. Das Skript nutzt die integrierte Anforderung mfa, die GUI-Variante die Authentifizierungsstärke „Multifactor authentication“; beides verlangt MFA.

Verifizieren: Die Richtlinie CA001-Require-MFA-All-Users steht in der Richtlinienliste mit Status „Report-only“. Unter Users → Exclude ist die Gruppe EmergencyAccess eingetragen.

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 sie. Prüfen Sie 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 Sie blockieren

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

Verifizieren: In den Anmeldeprotokollen zeigt der Reiter Report-only bei Anmeldungen mit IMAP, POP3 oder SMTP-Auth für CA002-Block-Legacy-Auth das Ergebnis „Report-only: Failure“, bei modernen Clients „Not applied“.

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

Diese Richtlinie verlangt MFA überall außer aus Ihrem Firmennetz, dessen öffentliche IP-Bereiche Sie als vertrauten Standort (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.

Verifizieren: Unter Named locations steht Firmenstandort-HQ mit Häkchen bei „Trusted“. Eine Testanmeldung über das Mobilfunknetz zeigt im Reiter Report-only für CA003 „Report-only: User action required“, eine Anmeldung aus dem Büro „Not applied“.

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. Setzen Sie risikobasierte Anforderungen daher direkt über Conditional Access um.

Verifizieren: Die Richtlinie CA004-Require-MFA-Sign-in-Risk steht auf „Report-only“. Unter ID Protection → Risky sign-ins sind riskante Anmeldungen sichtbar; für sie zeigt der Reiter Report-only die Richtlinie CA004 als zutreffend.

Schritt 8: Richtlinien testen und scharf schalten

Lassen Sie alle vier Richtlinien mindestens 5 bis 7 Arbeitstage im Report-only-Modus laufen, damit auch seltene Wochenend-Automationen und Legacy-Jobs erfasst werden.

Entra ID → Monitoring & health → Sign-in logs öffnen
Eine Anmeldung anklicken, Reiter Report-only: Dort sehen Sie, 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üfen und aktivieren Sie 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'

Schalten Sie die Richtlinien einzeln und gestaffelt scharf, nicht alle auf einmal. So lassen sich Auswirkungen leichter zuordnen.

Verifizieren: Get-MgIdentityConditionalAccessPolicy zeigt für die scharf geschaltete Richtlinie State = enabled. Der Test-Benutzer wird bei der nächsten Anmeldung von außerhalb nach dem zweiten Faktor gefragt, ein Break-Glass-Konto meldet sich weiterhin an.

Troubleshooting

Problem: Sie sind komplett ausgesperrt. Melden Sie sich mit einem Break-Glass-Konto an, das von allen restriktiven Richtlinien ausgenommen ist. Prüfen Sie danach die zuletzt geänderte Richtlinie unter Audit logs.
Problem: Nutzer bekommt AADSTS53004. Die phishing-resistente Methode ist nicht registriert. Registrierungsphase mit schwächerer Anforderung vorschalten (Schritt 3).
Problem: Directory Sync oder Forms-Sync schlägt fehl. Service-Principals und Sync-Konten sind nicht ausgenommen. Nehmen Sie die betroffenen Konten in die Ausschlüsse 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üfen Sie das IP-Format. Nutzen Sie CIDR (203.0.113.0/24), keine Bereichsangaben wie 203.0.113.1-50.
Problem: PowerShell verweigert das Erstellen. Der Scope fehlt. Verbinden Sie sich mit Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess', nicht nur mit Policy.Read.All.
Problem: Richtlinie hat keine Wirkung. Prüfen Sie den State. Korrekt sind enabledForReportingButNotEnforced (Report-only), enabled (On) und disabled (Off) – kein anderer Wert.

Häufige Fragen

Ist für MFA zwingend Entra ID P1 nötig?

Für die pauschale MFA-Erzwingung über Security Defaults nicht, sie sind kostenlos. Granulare Richtlinien mit Ausnahmen, Standorten oder Report-only-Test erfordern Entra ID P1, risikobasierte Richtlinien P2.

Was passiert mit Security Defaults, wenn Conditional Access aktiv wird?

Nein. Sobald eine Conditional-Access-Richtlinie aktiv ist, müssen die Security Defaults deaktiviert sein. Planen Sie den Umstieg so, dass durchgehend mindestens eine MFA-Richtlinie greift.

Warum 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 der Report-only-Test laufen?

Mindestens 5 bis 7 Arbeitstage; sonst übersehen Sie seltene Wochenend-Jobs, Batch-Läufe oder Legacy-Dienste, die beim Scharfschalten plötzlich blockiert sind.

Welche Client-Apps müssen für Legacy-Auth blockiert werden?

Unter Conditions → Client apps aktivieren Sie Exchange ActiveSync clients und Other clients; sie decken IMAP, POP3, SMTP-Auth und ältere Office-Versionen ab.

Lässt sich Conditional Access komplett per PowerShell verwalten?

Ja, mit dem Microsoft Graph PowerShell SDK: New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy und Update-MgIdentityConditionalAccessPolicy. Komplexe Bedingungen übergeben Sie als Hashtable über -BodyParameter.

Fazit

Security Defaults abgegrenzt, zwei Break-Glass-Konten abgesichert, MFA-Methoden festgelegt und vier Richtlinien angelegt: MFA für alle, Legacy-Auth blockieren, MFA außerhalb vertrauter Standorte, MFA bei riskanten Anmeldungen. Nach dem Report-only-Test schalten Sie gestaffelt scharf. Halten Sie die Ausnahmen minimal und prüfen Sie sie regelmäßig.

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.