Multi-Faktor-Authentifizierung (MFA) Multi-Factor Authentication (MFA)

Methoden, Richtlinien, Passwordless, TAP, SSPR und Graph-Automation für Microsoft Entra ID. Methods, policies, passwordless, TAP, SSPR, and Graph automation for Microsoft Entra ID.

Konzept Concept

MFA kombiniert mindestens zwei unabhängige Faktoren: etwas, das der Benutzer weiß, hat oder ist. In Entra ID ist MFA nicht nur eine Methode, sondern ein Rahmen aus Registrierungs-, Richtlinien- und Zugriffsentscheidungen. MFA combines at least two independent factors: something the user knows, has, or is. In Entra ID, MFA is not just a method but a framework of registration, policy, and access decisions.

Ein moderner MFA-Ansatz trennt drei Ebenen: welche Methoden grundsätzlich erlaubt sind, wer welche Methode nutzen darf und wann welche Stärke verlangt wird. A modern MFA approach separates three levels: which methods are generally allowed, who may use which method, and when which strength is required.

• Authentication Methods Policy legt Methoden und Zielgruppen fest.The authentication methods policy defines methods and target groups.
• Conditional Access bestimmt, wann MFA oder eine Authentication Strength gefordert wird.Conditional Access determines when MFA or an authentication strength is required.
• Security Info / Combined Registration steuern, wie Benutzer ihre Methoden registrieren.Security Info / combined registration controls how users register methods.

Methoden Methods

Authentication Methods Policy Authentication methods policy

Die Authentication Methods Policy ist die zentrale Stelle zur Steuerung moderner MFA- und Passwordless-Methoden. Jede Methode kann gezielt für Gruppen aktiviert, eingeschränkt oder ausgenommen werden. The authentication methods policy is the central place to control modern MFA and passwordless methods. Every method can be enabled, restricted, or excluded for specific groups.

• Methoden immer gruppenbasiert zuweisen und Ausnahmen bewusst dokumentieren.Always assign methods group-based and document exceptions consciously.
• Nicht jede Methode für jede Population freischalten; weniger ist meist sicherer.Do not allow every method for every population; less is usually safer.
• Hochprivilegierte Gruppen getrennt modellieren, damit stärkere Verfahren erzwungen werden können.Model highly privileged groups separately so stronger methods can be enforced.

Per-User MFA vs. CA MFA Per-user MFA vs. CA MFA

Migrationspfad Migration path

• Per-User MFA-Bestandsaufnahme exportieren.Export the current per-user MFA inventory.
• Gleichwertige CA-Baselines für dieselben Benutzerpopulationen definieren.Create equivalent CA baselines for the same user populations.
• Authentifizierungsmethoden in die moderne Policy überführen.Move authentication methods into the modern policy.
• Neue CA-Policies zuerst Report-only, dann gestaffelt aktivieren.Start new CA policies in report-only, then enable them in phases.
• Erst wenn CA greift, Per-User MFA schrittweise zurückbauen.Only after CA works should per-user MFA be phased out.

Registrierung Registration

Combined Registration bündelt MFA- und SSPR-Registrierung in einer Oberfläche unter mysignins.microsoft.com/security-info. Das reduziert Supportaufwand und beschleunigt die Einführung neuer Methoden. Combined registration consolidates MFA and SSPR registration in one experience under mysignins.microsoft.com/security-info. This reduces support effort and accelerates adoption of new methods.

• Benutzer frühzeitig informieren, welche Methode Standard werden soll.Inform users early which method should become the standard.
• Registration Campaign für Microsoft Authenticator nutzen, um Nutzer aktiv zur Registrierung zu führen.Use the registration campaign for Microsoft Authenticator to actively drive registration.
• MFA-Registrierung nicht gleichzeitig mit zu vielen anderen Sicherheitsänderungen erzwingen.Do not force MFA registration at the same time as too many other security changes.

Authentication Strengths Authentication strengths

Authentication Strengths verbinden Methodenpolitik mit Zugriffsanforderung. Sie sind der richtige Weg, wenn z. B. dieselbe Person für Standard-Apps Authenticator Push verwenden darf, für Admin-Portale aber nur FIDO2 oder WHfB. Authentication strengths connect method policy with access requirements. They are the right choice when the same person may use Authenticator push for standard apps but only FIDO2 or WHfB for admin portals.

Passwordless Passwordless

Microsoft Authenticator Passwordless Microsoft Authenticator passwordless

• Microsoft Authenticator in der Authentication Methods Policy aktivieren.Enable Microsoft Authenticator in the authentication methods policy.
• Combined Registration bereitstellen.Provide combined registration.
• Benutzer die Aktivierung von Phone sign-in in der App durchführen lassen.Let users enable phone sign-in in the app.
• Für Hochsicherheitszugriffe dennoch Authentication Strengths getrennt steuern.Still manage high-security access separately through authentication strengths.

FIDO2 / Passkeys FIDO2 / passkeys

• Methode für Pilotgruppe aktivieren.Enable the method for a pilot group.
• Gegebenenfalls Schlüsselhersteller oder AAGUIDs einschränken.Optionally restrict key vendors or AAGUIDs.
• Registrierung über Security Info oder passkey-fähige Flows zulassen.Allow registration through Security Info or passkey-capable flows.
• Für Administratoren ideal mit phishing-resistant CA-Policy kombinieren.Ideal for administrators when combined with a phishing-resistant CA policy.

Windows Hello for Business Windows Hello for Business

• WHfB ist gerätegebunden und eignet sich für verwaltete Windows-Endpunkte.WHfB is device-bound and well suited to managed Windows endpoints.
• Einführung mit Join-/Trust-Modell, TPM-Status und Gerätelebenszyklus abstimmen.Align rollout with the join or trust model, TPM state, and device lifecycle.
• Für Admins ideal, wenn separate Admin-Workstations oder Privileged Access Devices existieren.Excellent for admins if dedicated admin workstations or privileged access devices exist.

Number Matching Number matching

Number Matching schützt vor MFA-Fatigue-Angriffen. Der Benutzer bestätigt nicht nur per Approve, sondern muss die auf dem Sign-in angezeigte Zahl in der App eingeben. Number matching protects against MFA fatigue attacks. The user does not simply tap Approve but must enter the number shown on the sign-in screen into the app.

• Für Microsoft Authenticator Push-Benachrichtigungen ist Number Matching heute Standard.Number matching is the standard for Microsoft Authenticator push notifications today.
• Wearables wie Apple Watch oder Android Wear eignen sich dafür nicht.Wearables such as Apple Watch or Android Wear are not suitable for it.
• Zusätzlicher Kontext wie Standort oder App-Name erhöht Benutzerakzeptanz und Sicherheit.Additional context such as location or app name increases both usability and security.

Temporary Access Pass Temporary Access Pass

Temporary Access Pass (TAP) ist ein zeitlich begrenzter Bootstrap-Faktor. TAP wird vor allem für Onboarding, Recovery und die Registrierung von Passwordless-Methoden genutzt. Temporary Access Pass (TAP) is a time-limited bootstrap factor. It is mainly used for onboarding, recovery, and passwordless registration.

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"

$tap = @{
    isUsableOnce      = $true
    startDateTime     = "2026-06-11T08:00:00Z"
    lifetimeInMinutes = 60
}

New-MgUserAuthenticationTemporaryAccessPassMethod `
    -UserId "user@contoso.com" `
    -BodyParameter $tap

Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId "user@contoso.com" 

SSPR SSPR

Self-Service Password Reset (SSPR) gehört fachlich eng zu MFA, weil dieselben Registrierungs- und Verifikationsdaten genutzt werden. Für Hybridumgebungen ist Password Writeback der entscheidende Zusatz. Self-Service Password Reset (SSPR) is closely related to MFA because it uses the same registration and verification data. For hybrid environments, password writeback is the key extra capability.

• SSPR mit Combined Registration ausrollen, damit keine doppelte Benutzerführung entsteht.Roll out SSPR together with combined registration so users do not face duplicate experiences.
• Helpdesk und Security-Team müssen klar wissen, wann TAP statt Passwortreset genutzt wird.Helpdesk and security teams must clearly know when TAP should be used instead of a password reset.
• Bei Hybrid immer Writeback und Berechtigungen des Entra Connect-Kontos testen.In hybrid estates, always test writeback and the permissions of the Entra Connect account.

Berichte Reports

Für Rollouts sollten Sie nicht nur registered / not registered betrachten, sondern auch die Qualität der registrierten Methoden. Eine Population mit 95 % SMS ist formal registriert, aber noch nicht modern abgesichert. For rollouts, do not look only at registered / not registered; also measure the quality of the registered methods. A population with 95% SMS is formally registered, but not yet modernized.

PowerShell & Graph PowerShell & Graph

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","UserAuthenticationMethod.ReadWrite.All"

# List all registered methods for a user
Get-MgUserAuthenticationMethod -UserId "user@contoso.com"

# List phone methods
Get-MgUserAuthenticationPhoneMethod -UserId "user@contoso.com"

# Remove an obsolete phone method
Remove-MgUserAuthenticationPhoneMethod `
    -UserId "user@contoso.com" `
    -PhoneAuthenticationMethodId "3179e48a-750b-4051-897c-87b9720928f7"

# List FIDO2 methods
Get-MgUserAuthenticationFido2Method -UserId "user@contoso.com" 

GET https://graph.microsoft.com/v1.0/users/user@contoso.com/authentication/methods
GET https://graph.microsoft.com/v1.0/users/user@contoso.com/authentication/phoneMethods
GET https://graph.microsoft.com/v1.0/users/user@contoso.com/authentication/fido2Methods

POST https://graph.microsoft.com/v1.0/users/user@contoso.com/authentication/temporaryAccessPassMethods
Content-Type: application/json

{
  "isUsableOnce": true,
  "startDateTime": "2026-06-11T08:00:00Z",
  "lifetimeInMinutes": 60
}

Für tenantweite Methodenrichtlinien sind zusätzlich Graph-Endpunkte unter /policies/authenticationMethodsPolicy relevant. Änderungen dort sollten wie Infrastruktur-Code versioniert werden. For tenant-wide method policies, Graph endpoints under /policies/authenticationMethodsPolicy are also relevant. Changes there should be versioned like infrastructure code.

Troubleshooting Troubleshooting

FIDO2 Security Key Deep DiveFIDO2 security key deep dive

FIDO2 ist die praktisch wichtigste phishing-resistente Methode für portable Hardware-Token und Roaming Passkeys. Für Entra-Designs zählen dabei nicht nur WebAuthn-Unterstützung und Benutzererlebnis, sondern vor allem AAGUID-Allowlist, Attestation, Recovery-Prozess und Lifecycle für verlorene Schlüssel.FIDO2 is the most important phishing-resistant method in practice for portable hardware tokens and roaming passkeys. For Entra designs, WebAuthn support and user experience matter—but AAGUID allow lists, attestation, recovery, and lost-key lifecycle matter even more.

• AAGUID-Allowlist nur nach Labortest und Lieferkettenprüfung erweitern.Extend the AAGUID allow list only after lab testing and supply-chain validation.
• Self-Service-Registrierung über Security Info oder passkey-fähige Flows bereitstellen.Provide self-service registration through Security Info or passkey-capable flows.
• Mindestens zwei Schlüssel für hochprivilegierte Konten einplanen: Primär- und Backup-Schlüssel.Plan at least two keys for highly privileged accounts: a primary and a backup key.
• Troubleshooting immer mit Browser-Version, USB/NFC-Treiber, Security Info und AAGUID beginnen.Start troubleshooting with browser version, USB or NFC drivers, Security Info, and the AAGUID every time.

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.AuthenticationMethod"
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2"
Get-MgUserAuthenticationFido2Method -UserId "admin@contoso.com"

Microsoft Authenticator Deep DiveMicrosoft Authenticator deep dive

Microsoft Authenticator ist zugleich die am weitesten verbreitete MFA-Methode und die häufigste Brücke zu Passwordless. Architektonisch sollten Sie Push, Number Matching, Passwordless/Phone Sign-in und TOTP klar getrennt betrachten, weil Sicherheitsniveau, Supportaufwand und Benutzererlebnis unterschiedlich sind.Microsoft Authenticator is both the most widely deployed MFA method and the most common bridge to passwordless. Architecturally, treat push, number matching, passwordless or phone sign-in, and TOTP separately because security level, support effort, and user experience differ.

• Passwordless erfordert aktivierte Microsoft-Authenticator-Methode plus Gerätebindung im Phone Sign-in.Passwordless requires the Microsoft Authenticator method to be enabled and the device to be bound for phone sign-in.
• App-Name und Standortkontext sollten in der Benutzerkommunikation erklärt werden, damit verdächtige Prompts schneller erkannt werden.Explain app name and location context in user communication so suspicious prompts are recognized faster.
• TOTP bleibt wertvoll als Fallback, sollte aber nicht die strategische Zielmethode für Admins sein.TOTP remains valuable as a fallback, but it should not be the strategic end-state for admins.

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.AuthenticationMethod"
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator"
Get-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId "user@contoso.com"

Certificate-Based AuthenticationCertificate-based authentication

Certificate-Based Authentication (CBA) ist für hochregulierte Szenarien, Smartcard-nahe Designs und starke Passwordless- oder MFA-Flows besonders wertvoll. Erfolgreiche CBA-Projekte hängen weniger von der Portal-Konfiguration ab als von sauberer PKI, eindeutigen Mapping-Regeln, CRL-Erreichbarkeit und der Bindungsstrategie zwischen Zertifikat und Benutzer.Certificate-Based Authentication (CBA) is especially valuable for highly regulated scenarios, smart-card-like designs, and strong passwordless or MFA flows. Successful CBA projects depend less on portal clicks and more on clean PKI, unambiguous mapping rules, CRL reachability, and the binding strategy between certificate and user.

• PKI-Grundlagen: vertrauenswürdige Root/Issuing CAs, saubere EKUs, nachvollziehbare Sperrprozesse, hochverfügbare CRL/AIA-Pfade.PKI basics: trusted root and issuing CAs, clean EKUs, traceable revocation processes, and highly available CRL or AIA paths.
• CBA in Entra zuerst mit wenigen Pilotzertifikaten und klaren Mapping-Prioritäten testen.Test CBA in Entra with a small set of pilot certificates and clear mapping priorities first.
• CRL-Validierung ist keine Nebensache: Wenn Sperrlisten nicht erreichbar sind, leidet die Benutzeranmeldung oder das Vertrauen in die Lösung.CRL validation is not optional: if revocation lists are unavailable, user sign-in or trust in the solution suffers.
• Für privilegierte Rollen CBA mit Conditional Access und Authentication Strengths koppeln.For privileged roles, couple CBA with Conditional Access and authentication strengths.

Connect-MgGraph -Scopes "Policy.Read.All"
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/organization/certificateBasedAuthConfiguration"
Get-MgAuditLogSignIn -Filter "authenticationRequirement eq 'multiFactorAuthentication'"

OATH-Token-ManagementOATH token management

OATH bleibt relevant, wenn Smartphones nicht zulässig sind, Fertigungsumgebungen spezielle Anforderungen haben oder ein robuster Fallback benötigt wird. Operativ unterscheiden sich Hardware- und Software-OATH stark: Hardware lebt von sauberem Seed-Management, Software-OATH von sicherer Secret-Provisionierung und Benutzereinweisung.OATH remains relevant when smartphones are not allowed, factory environments have special requirements, or a robust fallback is needed. Operationally, hardware and software OATH differ significantly: hardware lives from clean seed management, while software OATH depends on secure secret provisioning and user education.

upn,serialNumber,secretKey,timeInterval,manufacturer,model
user1@contoso.com,FT-100023,BASE32SECRET123456,30,Feitian,c200
user2@contoso.com,YK-500044,BASE32SECRET789012,30,YubiKey,Series5

• CSV-Importdateien für Hardware-OATH streng wie Geheimnisse behandeln, da sie Seed-Material enthalten.Treat CSV import files for hardware OATH as secrets because they contain seed material.
• Software-OATH nur über vertrauenswürdige Registrierungswege bereitstellen und Secret-Reset-Prozess dokumentieren.Provide software OATH only through trusted registration paths and document the secret reset process.
• Graph deckt Software-OATH-Inventar besser ab als Hardware-Seed-Lifecycle; Portal und betriebliche Doku bleiben wichtig.Graph covers software OATH inventory better than hardware-seed lifecycle; the portal and operational documentation remain important.

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"
Get-MgUserAuthenticationMethod -UserId "user@contoso.com"
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/users/user@contoso.com/authentication/softwareOathMethods"