Zurück zum Blog
    Identity & Security

    SSPR für Admins in Microsoft Entra ID: häufig falsch konfiguriert

    18. April 2026
    9 min Lesezeit
    Square IT AG
    SSPR für Admins in Microsoft Entra ID per PowerShell sauber konfigurieren

    Self-Service Password Reset (SSPR) ist eine sinnvolle Funktion in Microsoft Entra ID. Nutzer setzen ihr Passwort selbst zurück, der Helpdesk wird entlastet. Was viele übersehen: für Administratorkonten gelten andere Regeln. Microsoft erzwingt SSPR für Admins unabhängig von Ihren SSPR Policies und genau das ist in fast jedem Schweizer KMU Tenant falsch konfiguriert.

    Admin SSPR lässt sich nicht im Admin Center steuern

    Die SSPR Einstellungen unter Protection → Password reset betreffen nur Endnutzer. Für Administratoren gilt eine eigene, durchgesetzte Policy, die nur per PowerShell sichtbar und steuerbar ist.

    Was Microsoft für Admin Accounts erzwingt

    Sobald einem Konto eine privilegierte Rolle (Global Admin, Privileged Role Admin, Exchange Admin und über 35 weitere Rollen) zugewiesen ist, gilt:

    • SSPR ist automatisch aktiv, unabhängig von Ihrer SSPR Gruppen Policy.
    • Mindestens zwei Authentifizierungsmethoden müssen registriert sein.
    • Security Questions sind für Admins nicht erlaubt.
    • Eine Methode muss verifizierbar sein (z.B. Authenticator, Telefon, FIDO2).

    Das klingt nach „eingebaute Sicherheit". In der Praxis bedeutet es: viele Tenants haben Admins, die ihr Passwort per SMS oder Voice Call zurücksetzen können. Genau die Methoden, die als unsicher gelten.

    Warum die Default Konfiguration gefährlich ist

    SIM Swapping

    Angreifer übernehmen die Mobilnummer und resetten das Admin Passwort.

    Social Engineering

    Helpdesk wird ausgehebelt, weil Admins „ja sowieso" selbst zurücksetzen können.

    Keine Vier Augen Kontrolle

    Ein einzelner Angreifer kann den Tenant alleine übernehmen.

    Audit unsichtbar

    SSPR Resets sehen im Log wie legitime User Aktion aus.

    Empfehlung: SSPR für Admins deaktivieren oder härten

    Es gibt zwei saubere Wege. Welcher passt, hängt von Ihrer Organisationsgrösse und Ihrem Identity Konzept ab.

    Option A: vollständig deaktivieren

    Empfohlen für KMU mit wenigen Admins und klarer Helpdesk Struktur. Resets laufen kontrolliert über einen zweiten Admin.

    Option B: SSPR mit FIDO2 härten

    SSPR bleibt aktiv, aber als Methode sind nur Authenticator + FIDO2 / Passkeys zugelassen. SMS und Voice deaktiviert.

    SSPR Konfiguration prüfen und ändern: nur per PowerShell

    Die unternehmensweite SSPR Einstellung steckt in der MSOL Company Settings Policy. Im Entra Admin Center ist sie nicht sichtbar. Sie brauchen das Modul MSOnline (oder alternativ Microsoft.Graph).

    PowerShell: Modul installieren und verbinden
    # Modul installieren (einmalig, als Admin) Install-Module MSOnline -Scope CurrentUser # Mit dem Tenant verbinden (öffnet Login Fenster) Connect-MsolService

    1. Aktuellen SSPR Status prüfen

    PowerShell: Status anzeigen
    Get-MsolCompanyInformation | Select-Object \ SelfServePasswordResetEnabled, \ UsersPermissionToCreateGroupsEnabled, \ UsersPermissionToCreateLOBAppsEnabled

    Ist SelfServePasswordResetEnabled auf True und Sie haben keine explizite Konfiguration, läuft SSPR für Admins mit den Default Methoden. Handlungsbedarf.

    2. Option A: SSPR vollständig deaktivieren

    PowerShell: SSPR organisationsweit aus
    Set-MsolCompanySettings -SelfServePasswordResetEnabled $false # Verifizieren Get-MsolCompanyInformation | Select-Object SelfServePasswordResetEnabled

    Nach dieser Änderung können weder Admins noch normale Nutzer ihr Passwort selbst zurücksetzen. Stellen Sie sicher, dass Ihr Helpdesk Prozess steht, bevor Sie das in Produktion ausführen.

    3. Option B: SSPR aktiv lassen, Methoden härten

    Wenn Sie SSPR für Endnutzer behalten möchten, deaktivieren Sie die schwachen Methoden in der Authentication Methods Policy. Das geht entweder im Entra Admin Center (siehe unser Beitrag zu Authentication Policies in Entra ID) oder per Microsoft Graph PowerShell.

    PowerShell: SMS und Voice deaktivieren
    Install-Module Microsoft.Graph -Scope CurrentUser Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod" # SMS deaktivieren Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration \ -AuthenticationMethodConfigurationId "Sms" \ -BodyParameter @{ state = "disabled" } # Voice deaktivieren Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration \ -AuthenticationMethodConfigurationId "Voice" \ -BodyParameter @{ state = "disabled" }

    4. Break Glass Konten absichern

    Egal welche Option Sie wählen: mindestens zwei Break Glass Konten mit hinterlegten FIDO2 Keys sind Pflicht. Diese Konten sind aus Conditional Access ausgeschlossen und nutzen kein SSPR. Lagern Sie die Hardware Keys an einem sicheren Ort.

    Wichtig vor jeder Änderung

    Testen Sie zuerst mit einem dedizierten Test Admin Konto. Dokumentieren Sie den Vorher Nachher Stand. Ohne funktionierendes Break Glass Konto kein Rollout in Produktion.

    Checkliste: SSPR für Admins sauber konfiguriert

    MSOL Company Setting bewusst entschieden (an oder aus)

    SMS und Voice als Authentication Method deaktiviert

    Authenticator mit Number Matching erzwungen

    FIDO2 / Passkeys für alle Admins registriert

    Mindestens 2 Break Glass Konten mit Hardware Keys

    Conditional Access: phishing resistente MFA für Admin Rollen

    Sign in Logs und Audit Logs auf SSPR Events überwacht

    Konfiguration dokumentiert und versioniert

    Häufige Fehler in der Praxis

    • SSPR im Admin Center „deaktiviert" und denken, damit sei es auch für Admins aus. Falsch: das betrifft nur Endnutzer.
    • SMS bleibt als Methode aktiv, weil sie als Fallback bequem ist. Sicherheits Lücke Nummer eins.
    • Kein Break Glass Konto. Bei einem Lockout sperrt sich die IT selbst aus dem Tenant.
    • Keine Überwachung der SSPR Aktivität in den Audit Logs.
    • Änderungen nicht dokumentiert. Bei Audits oder Personalwechsel weiss niemand mehr, warum etwas so gesetzt ist.

    Admin Identitäten in Entra ID absichern?

    Wir prüfen Ihre SSPR Konfiguration, härten Admin Accounts mit FIDO2 und richten Break Glass Konten sauber ein. Inklusive Conditional Access und Audit Reporting.

    Identity & Security entdecken

    Fazit

    SSPR für Admins ist in den meisten Schweizer KMU Tenants ein blinder Fleck. Die Standardvorgabe von Microsoft öffnet eine Tür, die niemand bewusst geöffnet hat. Mit ein paar PowerShell Befehlen schliessen Sie diese Tür: entweder durch ein vollständiges Deaktivieren oder durch konsequentes Härten der zugelassenen Methoden. In Kombination mit Break Glass Konten und Conditional Access entsteht eine Admin Identität, die heutigen Angriffen standhält.

    SSPR
    Entra ID
    Admin Accounts
    PowerShell
    FIDO2
    Microsoft 365 Security
    Identity

    Wir verwenden Cookies

    Wir verwenden Cookies und ähnliche Technologien, um Ihnen das bestmögliche Erlebnis auf unserer Website zu bieten. Einige Cookies sind notwendig für die Funktionalität der Website, andere helfen uns bei der Analyse und Verbesserung.