Wie sicher die Multi-Faktor-Authentifizierung für Administratoren wirklich ist, wird in fast jedem Microsoft-365- und Azure-Projekt diskutiert, das ich begleite. Push-Benachrichtigungen und Einmalcodes lassen sich längst aushebeln. Immer mehr Unternehmen fordern deshalb ausdrücklich phishing-resistente MFA, vor allem für privilegierte Zugänge. Genau dafür gibt es die Authentication Strengths. 2025 sind sie das Werkzeug, mit dem sich in Conditional Access (CA) klare Verhältnisse schaffen lassen.

Entra ID bringt drei vordefinierte Authentication Strengths mit

Authentication Strengths sind vordefinierte, aber erweiterbare Kriterien, nach denen Microsoft Entra ID die Qualität einer Anmeldung bewertet. Statt pauschal „MFA“ zu fordern, legt man in CA-Richtlinien fest, mit welchen starken Methoden ein Zugriff überhaupt möglich ist. Ab Werk stehen drei Stufen bereit:

  • „Multifactor authentication“: alle Methoden, die mindestens zwei Faktoren kombinieren, also auch schwächere wie SMS oder App-Push
  • „Passwordless MFA“: Methoden ohne Passwort, etwa FIDO2-Sicherheitsschlüssel, Windows Hello for Business oder Passkeys
  • „Phishing-resistant MFA“: nur Methoden, die Phishing-Angriffen standhalten, in erster Linie FIDO2 und zertifikatbasierte Authentifizierung

Für Adminzugänge ist „Phishing-resistant MFA“ die richtige Wahl. Welche Methoden dazugehören und worin sich die Stufen genau unterscheiden, erklärt Microsoft ausführlich in der Übersicht zu Authentication Strengths. In vielen Tenants, die ich mir ansehe, sind allerdings längst nicht alle passenden Methoden aktiviert, oder die Zuweisung ist zu großzügig.

Benutzerdefinierte Stärken legen fest, welche FIDO2-Schlüssel zählen

Mehr Spielraum geben benutzerdefinierte Authentication Strengths. Mit ihnen bestimmt man genau, welche FIDO2-Sicherheitsschlüssel (anhand ihrer AAGUIDs) oder welche Zertifikatstypen erlaubt sind. Im Entra-Portal geht man dazu auf Schutz → Authentifizierungsmethoden → Authentifizierungsstärken und legt eine neue Stärke mit den gewünschten Methoden und Geräte-IDs an. Das hilft, wenn aus Compliance-Gründen nur bestimmte Hardware zugelassen sein darf, zum Beispiel ausgewählte YubiKey-Modelle.

Auf diese Weise lässt sich für Break-Glass-Konten ein Notfallzugang einrichten, der ausschließlich mit eigens dafür vorgesehenen FIDO2-Keys funktioniert. Details dazu stehen im Beitrag Notfallzugriffskonten in Entra ID: Sicher umgesetzt 2024.

Conditional Access erzwingt die starke MFA über Verzeichnisrollen

Durchgesetzt wird die gewünschte Stärke anschließend in einer CA-Richtlinie. Über die Zuweisung Benutzer → Directory Roles erfasst man gezielt alle Mitglieder bestimmter Adminrollen. Zusammen mit der Gewährungseinstellung „Require authentication strength“ legt sich damit ein wirksames Sicherheitsnetz um die privilegierten Identitäten.

In meinen Projekten hat sich zunehmend folgende Kombination bewährt: Eine Richtlinie verlangt „Phishing-resistant MFA“ für Global Admin, Privileged Role Admin, Conditional Access Admin, Application Admin und Security Admin. Häufig kommt eine zweite CA-Richtlinie hinzu, die bei jeder PIM-Aktivierung (Privileged Identity Management) einen Authentifizierungskontext mit starker MFA fordert. Wie man das in Conditional Access technisch umsetzt, habe ich ausführlich in meinen Best Practices für Conditional Access beschrieben.

Für besonders heikle Aktionen, etwa das Löschen von Verzeichnisobjekten, gibt es seit einiger Zeit Protected Actions. Bestimmte Tätigkeiten in Entra ID sind dann nur nach einer zusätzlichen starken MFA möglich. Eine Übersicht findet ihr direkt bei Microsoft unter Advanced Authentication Strength Options.

Das folgende Diagramm zeigt, wie Rollen, PIM, Authentifizierungsstärken und Notfallzugänge zusammenwirken:

flowchart TD
    User["Admin-Benutzer"] --> PIM["PIM-Rollenaktivierung"]
    PIM --> CA1["CA-Richtlinie: Directory Roles"]
    CA1 --> AuthStrength["Phishing-resistant MFA"]
    PIM --> CA2["CA-Richtlinie: Authentifizierungskontext"]
    CA2 --> AuthStrength
    BreakGlass["Break-Glass-Konto mit FIDO2"] --> CA1
    AuthStrength --> Zugriff["Admin-Zugriff gewährt"]

Abbildung: Authentifizierungsstärken mit CA für Adminrollen, PIM und Notfallzugang

Beim Rollout fallen vor allem alte Tools und Skripte aus

Zu den größten Hürden gehören Legacy-Tools, die den Device-Code-Flow oder unsichere Anmeldeverfahren verwenden. Sobald „Phishing-resistant MFA“ Pflicht ist, funktionieren sie von einem Moment auf den anderen nicht mehr. Das trifft vor allem ältere PowerShell-Module wie MSOnline oder AzureAD (siehe Hinweise zur Migration) und Admin-Tools ohne Unterstützung für FIDO2 oder Zertifikate. Auch die Anmeldung per Gerätecode ist für die betroffenen Konten dann gesperrt.

Aus der Praxis: Bevor man den Schutz auf alle Adminrollen ausdehnt, sollte man die wichtigsten Skripte und Tools mit vorübergehend zugewiesenen Testrollen (!) durchprobieren. Die meisten Probleme tauchen dabei sofort auf, und man kann gezielt Alternativen schaffen.

Meist fährt man mit einer schrittweisen Einführung am besten: zuerst eine Pilotgruppe wie die Security Admins, dann Awareness und Supportprozesse, erst danach die übrigen Rollen. Für PowerShell-Verbindungen lohnt sich fast immer der Wechsel auf das Microsoft Graph PowerShell SDK mit modernen Authentifizierungsmethoden (Migration auf Graph).

Ob der eigene Tenant den Device-Code-Flow für privilegierte Konten schon blockiert, sieht man im Entra-Portal unter Schutz → Conditional Access → Authentifizierungsstärken und in den CA-Richtlinien. Alternativ sucht man in den Sign-in-Logs nach fehlgeschlagenen Anmeldungen.

Auch Break-Glass-Konten lassen sich mit FIDO2 sauber absichern

Klassische Break-Glass-Konten sind oft eine Schwachstelle. Sie werden von CA-Richtlinien ausgenommen und sind dadurch unter Umständen nur dürftig geschützt. Mit eigens dafür vorgesehenen FIDO2-Keys und einer benutzerdefinierten Authentifizierungsstärke erreichen inzwischen auch Notfallzugänge ein hohes Schutzniveau und bleiben CA-konform, ganz ohne Benutzername und Passwort oder SMS. Wie das im Einzelnen funktioniert, steht in Notfallzugriffskonten in Entra ID: Sicher umgesetzt 2024.

Wer bei Rollout und Wiederherstellung vollständig auf Passkeys setzen möchte, findet in Passkeys in Entra ID: Praxis-Rollout und Stolpersteine Hinweise zur Umsetzung und zu typischen Fallstricken.

Ohne Authentication Strengths bleiben Adminkonten unnötig angreifbar

Wer 2025 Adminkonten noch ohne gezielt definierte Authentication Strengths betreibt, riskiert ohne Not, dass sie über Phishing oder veraltete Tools kompromittiert werden. CA, PIM, Protected Actions und benutzerdefinierte Stärken lassen sich inzwischen zuverlässig in der Breite einsetzen, verlangen aber, dass man die eigene Toollandschaft modernisiert. In immer mehr Umgebungen erlebe ich, dass eine saubere Trennung von Alltags- und Adminidentitäten, gut abgesicherte Notfallzugänge und ein klarer Migrationspfad für PowerShell heute zur Grundausstattung gehören. Wer schrittweise vorgeht und die Stolperfallen kennt, bringt seinen Tenant auf den Stand der Microsoft-Empfehlungen und schützt ihn zugleich vor Angriffen, die längst alltäglich sind.