Entra ID: Identitäten, Anmeldung und Notfallzugriff prüfen
Identitäten und Anmeldeschutz im Tenant zuerst einordnen.
Der Prüfauftrag
Für einen eigenen Microsoft-Entra-Tenant. Bestand und Nachweise zuerst erfassen; Änderungen über einen freigegebenen Pilot durchführen. Benötigte Rollen, Lizenzen und vorhandene Richtlinien vorab prüfen. Quellenstand: 09.11.2026.
Am Ende hast du:Eine dokumentierte Erstprüfung mit nachvollziehbaren Nachweisen und einer Liste offener Maßnahmen.
Beweisen statt vermuten.
Mit einem freigegebenen Testkonto eine erwartete Anmeldung und eine erwartete Sperre prüfen; die tatsächlich angewendeten Kontrollen in den Anmeldedetails nachvollziehen.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Zuständigkeit und aktuelle Entra-Konfiguration einschließlich Security Defaults und Conditional Access erfassen.
So belegst du es: Datierter Konfigurationsexport mit verantwortlicher Person und Prüfbereich.
Nachweis und nächsten Schritt notieren
Prüfen, ob MFA-Registrierung und tatsächlich erzwungener MFA-Schutz die vorgesehenen Benutzer und Administratoren abdecken.
So belegst du es: Registrierungsbericht sowie passende erfolgreiche und abgewiesene Testanmeldungen.
Nachweis und nächsten Schritt notieren
Für privilegierte Konten geeignete phishingresistente Methoden planen und deren tatsächliche Verwendung prüfen.
So belegst du es: Methodenrichtlinie und Anmeldedetails eines autorisierten Testkontos.
Nachweis und nächsten Schritt notieren
Legacy-Authentifizierung im Bestand identifizieren und die wirksame Sperre mit einem freigegebenen Negativtest belegen.
So belegst du es: Anmeldeauswertung und dokumentiertes Blockierungsergebnis; notwendige Migrationen separat erfassen.
Nachweis und nächsten Schritt notieren
Mindestens zwei cloudbasierte Notfallkonten mit unabhängigen, phishingresistenten Anmeldemitteln vorsehen und testen.
So belegst du es: Notfallkonzept und Testprotokoll; keine Geheimnisse im Prüfbericht.
Nachweis und nächsten Schritt notieren
Notfallkonten vor sperrenden Anmelderichtlinien schützen und jede Nutzung oder Änderung überwachen.
So belegst du es: Begründete Ausnahmen, funktionierender Alarm und dokumentierter Wiederherstellungstest.
Nachweis und nächsten Schritt notieren
Benutzerzustimmung zu Anwendungen begrenzen und einen geregelten Prüfweg für weitergehende Berechtigungen festlegen.
So belegst du es: Zustimmungsrichtlinie, zuständige Prüfpersonen und eine nachvollziehbare Beispielentscheidung.
Nachweis und nächsten Schritt notieren
Bereits erteilte Anwendungsberechtigungen auf Erforderlichkeit, verantwortliche Person und ungewöhnliche Zugriffe prüfen.
So belegst du es: Berechtigungsexport, begründete Freigaben und nachverfolgte Maßnahmen für Auffälligkeiten.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
MFA-Registrierung beweist keine durchgehende MFA-Erzwingung. Allgemeine MFA ist nicht automatisch phishingresistent. Security Defaults und individuelle Conditional-Access-Richtlinien sind alternative Betriebsmodelle; beim Wechsel keine Schutzlücke schaffen. Notfallkonten sind keine ungeschützten MFA-Ausnahmen. Diese Checkliste bestätigt weder einen kompromissfreien Tenant noch eine vollständige Härtung.
Microsoft Learn: Security defaults ↗Microsoft Learn: Emergency access accounts ↗Microsoft Learn: Authentication strengths ↗Microsoft Learn: Application consent management ↗Microsoft Learn: Review application permissions ↗Prüfbericht / Selbsteinschätzung
Entra ID: Identitäten, Anmeldung und Notfallzugriff prüfen · v2026.11 · 10.11.2026 ·
0/8 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Zuständigkeit und aktuelle Entra-Konfiguration einschließlich Security Defaults und Conditional Access erfassen.
Status: Offen
Erwarteter Nachweis: Datierter Konfigurationsexport mit verantwortlicher Person und Prüfbereich.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. Prüfen, ob MFA-Registrierung und tatsächlich erzwungener MFA-Schutz die vorgesehenen Benutzer und Administratoren abdecken.
Status: Offen
Erwarteter Nachweis: Registrierungsbericht sowie passende erfolgreiche und abgewiesene Testanmeldungen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Für privilegierte Konten geeignete phishingresistente Methoden planen und deren tatsächliche Verwendung prüfen.
Status: Offen
Erwarteter Nachweis: Methodenrichtlinie und Anmeldedetails eines autorisierten Testkontos.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Legacy-Authentifizierung im Bestand identifizieren und die wirksame Sperre mit einem freigegebenen Negativtest belegen.
Status: Offen
Erwarteter Nachweis: Anmeldeauswertung und dokumentiertes Blockierungsergebnis; notwendige Migrationen separat erfassen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Mindestens zwei cloudbasierte Notfallkonten mit unabhängigen, phishingresistenten Anmeldemitteln vorsehen und testen.
Status: Offen
Erwarteter Nachweis: Notfallkonzept und Testprotokoll; keine Geheimnisse im Prüfbericht.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Notfallkonten vor sperrenden Anmelderichtlinien schützen und jede Nutzung oder Änderung überwachen.
Status: Offen
Erwarteter Nachweis: Begründete Ausnahmen, funktionierender Alarm und dokumentierter Wiederherstellungstest.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Benutzerzustimmung zu Anwendungen begrenzen und einen geregelten Prüfweg für weitergehende Berechtigungen festlegen.
Status: Offen
Erwarteter Nachweis: Zustimmungsrichtlinie, zuständige Prüfpersonen und eine nachvollziehbare Beispielentscheidung.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Bereits erteilte Anwendungsberechtigungen auf Erforderlichkeit, verantwortliche Person und ungewöhnliche Zugriffe prüfen.
Status: Offen
Erwarteter Nachweis: Berechtigungsexport, begründete Freigaben und nachverfolgte Maßnahmen für Auffälligkeiten.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
MFA-Registrierung beweist keine durchgehende MFA-Erzwingung. Allgemeine MFA ist nicht automatisch phishingresistent. Security Defaults und individuelle Conditional-Access-Richtlinien sind alternative Betriebsmodelle; beim Wechsel keine Schutzlücke schaffen. Notfallkonten sind keine ungeschützten MFA-Ausnahmen. Diese Checkliste bestätigt weder einen kompromissfreien Tenant noch eine vollständige Härtung.