Tiering-Modell für Administratorrollen in Microsoft Entra ID

Ein Tiering-Modell in Entra ID teilt Administratorrollen nach der Reichweite ihrer Rechte in Stufen ein. Für jede Stufe legst Du fest, mit welchem Konto, auf welchem Gerät und mit welcher Anmeldung ein Administrator arbeiten darf. Du bekommst die Herkunft des Begriffs, einen Vorschlag für drei Stufen und sieben Umsetzungsschritte, jeweils mit Fundstelle auf Microsoft Learn. Zielgruppe sind Administratoren und IT-Leitung in Microsoft 365-Tenants.

Die Zuordnung der Rollen zu den Stufen ist mein Vorschlag. Microsoft veröffentlicht keine Tabelle, die Entra-Rollen den Tiers 0, 1 und 2 zuordnet. Die Seite zu den Security Levels ordnet alle Entra-Administratorrollen pauschal der höchsten Stufe Privileged zu. Die Maßnahmen je Stufe stammen aus der Dokumentation von Microsoft und sind einzeln belegt.

Risiko und Haftung

Administratorrollen geben Zugriff auf Einstellungen und Daten des ganzen Tenants. Learn beschreibt, dass Global Administrators nahezu uneingeschränkten Zugriff haben und mit wenigen Ausnahmen alle Konfigurationseinstellungen Deiner Organisation lesen und ändern können (Empfehlungen für Microsoft Entra-Rollen). Ein übernommenes Konto mit dieser Rolle betrifft deshalb jeden Dienst im Tenant.

Microsoft ordnet den Schutz privilegierter Zugriffe in der Strategie für privilegierten Zugriff als vorrangig für jede Organisation ein. Ein Angreifer mit Kontrolle über privilegierte Konten kann alle anderen Sicherheitszusagen aushebeln (Privileged access: Strategy).

Für Verantwortliche stellt sich daraus eine Nachweisfrage. Art. 32 Abs. 1 DSGVO verlangt geeignete technische und organisatorische Maßnahmen für ein dem Risiko angemessenes Schutzniveau und nennt in Buchstabe d ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung ihrer Wirksamkeit.

Nach Abs. 4 müssen Verantwortliche und Auftragsverarbeiter Schritte unternehmen, damit unterstellte Personen mit Zugang zu personenbezogenen Daten diese nur auf Anweisung des Verantwortlichen verarbeiten, es sei denn, sie sind nach Unionsrecht oder dem Recht der Mitgliedstaaten dazu verpflichtet (Art. 32 DSGVO).

Die Norm nennt keine Technik, und welche Maßnahmen angemessen sind, hängt vom Risiko im Einzelfall ab. Aus meiner Sicht lassen sich genehmigte, befristete und protokollierte Rollenaktivierungen sowie regelmäßige Überprüfungen der Zuweisungen gut nachweisen.

Die Behebung besteht aus vier Schritten: Rollen nach Reichweite einstufen, Dauerrechte durch befristete Aktivierung ersetzen, Anmeldung und Gerät je Stufe festlegen und die Zuweisungen regelmäßig prüfen.

Tiering-Modell Entra ID und Enterprise Access Model: Herkunft und Einordnung

Das Tier-Modell stammt aus Active Directory. Es sollte unautorisierte Privilege Escalation (Rechteausweitung) in einer On-Premises-Umgebung eindämmen, also verhindern, dass sich ein Angreifer von niedrigen zu höheren Berechtigungen vorarbeitet (Enterprise access model).

Tier 0 umfasst nach Learn die Konten, Gruppen und Systeme, die das Active Directory mit seinen Domänen und Domain Controllers direkt oder indirekt verwalten (Securing privileged access for hybrid and cloud deployments).

Das Enterprise Access Model baut auf diesem Modell auf. Learn beschreibt die Änderungen als Weiterentwicklung des AD-Tier-Modells (Enterprise access model):

Tier 1 und Tier 2 sind damit aufgeteilt, Tier 0 ist größer geworden: Die Control Plane deckt die gesamte Zugriffssteuerung (Access Control) ab, nicht nur das Verzeichnis. Im Enterprise Access Model gilt eine Regel: Eine niedrigere Ebene darf eine höhere nicht kontrollieren können. Learn formuliert das als Hierarchie, die eine Rechteausweitung von unten nach oben verhindern soll.

Für Entra ID zählt eine Unterscheidung. Die Empfehlung für die ESAE-Architektur, den separaten administrativen Wald, hat Microsoft durch die Strategie für privilegierten Zugriff und den Rapid Modernization Plan ersetzt. ESAE gilt nur noch für Ausnahmefälle, etwa isolierte Umgebungen ohne Cloud-Dienste (ESAE retirement).

Das Tier-Modell selbst ist dagegen weiterentwickelt worden. Für On-Premises-Active-Directory empfiehlt dieselbe Seite weiterhin einen gestuften Ansatz mit dem Prinzip der geringsten Berechtigungen (Least Privilege). Gute Praktiken aus ESAE wie dedizierte Privileged Access Workstations (PAWs) und MFA für Administratorkonten bleiben ausdrücklich empfohlen.

In einem Tenant ist Entra ID das zentrale Identitätssystem (Identity Systems im Sinne von Learn), deshalb ordne ich es der Control Plane zu. In den FAQ der Seite Securing privileged access beantwortet Learn auch die Frage nach synchronisierten Administratorkonten: Konten der Tier 0 gehören zum lokalen Active Directory und werden in der Regel nicht mit Entra ID synchronisiert.

Für Konten, Geräte und Zugriffe definiert Microsoft außerdem drei Sicherheitsstufen: Enterprise, Specialized und Privileged (Privileged access security levels). Zur Stufe Privileged zählt Learn die Microsoft Entra-Administratorrollen und lokale AD-Gruppen wie Enterprise Admins, Domain Admins und Server Operators. Helpdesk- und Tech-Support-Rollen nennt die Seite bei Specialized. Als Beispiel für ein Einstufungskriterium nennt Learn einen möglichen Schaden von mehr als einer Million US-Dollar.

Learn ordnet damit alle Entra-Administratorrollen der höchsten Stufe zu. Aus meiner Sicht ist das für Rollen mit begrenzter Reichweite schwer umzusetzen. Deshalb unterscheide ich innerhalb der Entra-Rollen feiner.

Drei Stufen für Administratorrollen in Entra ID

Mein Vorschlag nutzt drei Stufen, die sich an Tier 0, Tier 1 und Tier 2 anlehnen. Stufe 0 entspricht der Control Plane, Stufe 1 der Management Plane und der Data/Workload Plane (Verwaltung einzelner Dienste im ganzen Tenant), Stufe 2 steht für Rollen, die Benutzer mit begrenzter Reichweite betreuen (Support und delegierte Verwaltung). Die Beschreibungen der Rollen stammen aus der Referenz der Entra-Rollenberechtigungen, die Einordnung ist meine.

Zur Begründung der Beispiele: Der Privileged Role Administrator verwaltet Rollenzuweisungen und alle Aspekte von PIM. Der Privileged Authentication Administrator kann Authentifizierungsmethoden jedes Benutzers einsehen, setzen und zurücksetzen, auch die von Administratoren. Der Authentication Administrator darf das für Nicht-Administratoren und einige weitere Rollen (Liste in Learn unter "Who can reset passwords"). Der Helpdesk Administrator setzt Kennwörter von Nicht-Administratoren und anderen Helpdesk Administratoren zurück.

Auch Rollen aus Stufe 1 und Stufe 2 tragen das Label PRIVILEGED, etwa Application Administrator, Security Administrator, User Administrator, Intune Administrator, Helpdesk Administrator, Password Administrator, Authentication Administrator und Global Reader (Referenz der Entra-Rollenberechtigungen; Privileged roles and permissions, das Label ist dort als Vorschau gekennzeichnet). Prüfe Deine Zuordnung deshalb gegen dieses Label.

Eine Folgerung aus der Grundregel, dass eine niedrigere Ebene eine höhere nicht kontrollieren darf, ist meine eigene Einschätzung und keine Aussage von Learn: Rollen, die Geräte, Richtlinien oder Schutzmechanismen einer höheren Stufe verwalten, stufst Du mindestens gleich hoch ein oder begrenzt ihren Zugriff. Ein Intune Administrator verwaltet auch die PAWs der Stufe 0, ein Security Administrator kann Protected Actions konfigurieren, die Berechtigungen der Stufe 0 schützen. Beide Rollen stehen in der Tabelle in Stufe 1 und sind deshalb ein Prüfpunkt bei der Einstufung.

Die Anmeldestärke ist nicht abgestuft. Microsoft empfiehlt phishing-resistente MFA mindestens für 14 Rollen, darunter auch Helpdesk Administrator, Password Administrator und Authentication Administrator (Require phishing-resistant MFA for administrators). Die Stufen unterscheiden sich bei Konto, Gerät, Genehmigung und Aktivierungsdauer:

Die Tabelle ist meine Empfehlung. Learn sieht für alle Entra-Administratorrollen die Stufe Privileged und damit eine PAW vor. Bei den Geräten liegen Stufe 1 und Stufe 2 in meinem Vorschlag bewusst darunter.

So setzt Du das Tiering-Modell in Entra ID um

Die Reihenfolge ist meine Empfehlung, die ich nach über 500 geprüften und gehärteten Tenants für praktikabel halte. Sie berücksichtigt die Lizenzvoraussetzungen:

Dokumentiere nach jeder Phase die Zuordnung von Rollen zu Stufen. Sie ist Deine Grundlage für Reviews und Nachweise.

Schritt 1: Bestandsaufnahme der Rollen

Öffne das Microsoft Entra Admincenter und gehe zu "Entra ID > Roles & admins > All roles". Dort zeigt die Spalte "Privileged" die Rollen mit dem PRIVILEGED-Label, die Spalte "Assignments" die Zahl der Zuweisungen. Ordne jede Rolle mit Zuweisungen einer Stufe zu und notiere die Konten.

Zwei Grenzwerte aus Learn helfen bei der Bewertung. Microsoft empfiehlt, die Rolle Global Administrator weniger als fünf Personen zuzuweisen. Bei fünf oder mehr Zuweisungen zeigt die Übersichtsseite eine Warnkarte. Privilegierte Rollenzuweisungen sollten unter zehn bleiben, darüber zeigt die Seite "Roles and administrators" eine Warnung (Empfehlungen für Entra-Rollen).

Wer die privilegierten Rollen per Skript auflisten will, nutzt in Microsoft Graph PowerShell Get-MgBetaRoleManagementDirectoryRoleDefinition -Filter "isPrivileged eq true".

Schritt 2: Notfallkonten und getrennte Cloud-Konten

Lege mindestens zwei Notfallzugänge (Break-Glass-Accounts) an. Learn empfiehlt Cloud-Konten auf der Domäne *.onmicrosoft.com, die weder föderiert noch synchronisiert sind und die Rolle Global Administrator dauerhaft tragen. Empfohlen ist ein Passkey (FIDO2), mit einer Methode, die Deine normalen Administratoren nicht nutzen (Manage emergency access accounts).

Nimm die Konten aus Conditional-Access-Richtlinien aus, die Anmeldungen blockieren oder einschränken, und teste die Anmeldung regelmäßig. Learn nennt als Beispiel vierteljährlich und mindestens alle 90 Tage. Jede Anmeldung der Konten sollte einen Alarm auslösen. Die Einrichtung beschreibe ich im Beitrag Break Glass Access-Application: Einrichtung und Absicherung.

Für die übrigen Administratoren gilt: mindestens ein normales Konto für E-Mail und Browser und ein eigenes Konto für Administrationsaufgaben. Learn nennt persönliche E-Mail-Adressen für Global-Administrator-Konten unzulässig und empfiehlt dedizierte Konten für jede Person mit administrativen Rechten (Securing privileged access for hybrid and cloud deployments). Wer Aufgaben mehrerer Stufen übernimmt, bekommt nach meiner Empfehlung je Stufe ein Konto, damit eine niedrigere Ebene keine höhere kontrolliert.

Die Administratorkonten für Entra-Rollen sollten reine Cloud-Konten sein. Wird ein synchronisiertes lokales Konto kompromittiert, kann das auch die Entra-Ressourcen betreffen (Empfehlungen für Entra-Rollen, Punkt 9; Microsoft 365 vor lokalen Angriffen schützen). Lokale Tier-0-Konten bleiben im Active Directory.

Schritt 3: Least Privilege und Administrative Units

Weise je Aufgabe die Rolle mit den geringsten Berechtigungen zu (Least Privilege). Die Seite Least privileged roles by task listet für jede Aufgabe die kleinste passende Rolle. Reicht keine eingebaute Rolle, kannst Du eine benutzerdefinierte Rolle anlegen.

Administrative Units begrenzen eine Rolle auf einen Teil der Organisation. Learn nennt als Beispiel, die Helpdesk-Rolle an regionale Supportmitarbeiter zu delegieren, die dann nur Benutzer ihrer Region verwalten (Administrative units).

Dabei gelten Einschränkungen. Administrative Units lassen sich nicht verschachteln. Fügst Du eine Gruppe hinzu, verwaltet der Administrator die Gruppe selbst, aber nicht die Eigenschaften oder Kennwörter ihrer Mitglieder, solange diese nicht direkt Mitglied der Administrative Unit sind. Für jeden Administrator mit Rolle über eine Administrative Unit ist eine Lizenz Microsoft Entra ID P1 nötig, für die Mitglieder genügt Free.

Schritt 4: PIM, rollenzuweisbare Gruppen und befristete Rechte

Mit Privileged Identity Management machst Du Benutzer für eine Rolle berechtigt (eligible), statt sie dauerhaft zuzuweisen. Sie aktivieren die Rolle bei Bedarf für einen begrenzten Zeitraum, danach entfällt das Recht automatisch (Empfehlungen für Entra-Rollen, Punkt 2). Das Produkt beschreibe ich im Beitrag Privileged Identity Management.

Die Rolleneinstellungen findest Du unter "ID Governance > Privileged Identity Management > Microsoft Entra roles > Roles". Learn beschreibt folgende Einstellungen für die Aktivierung (Configure Microsoft Entra role settings in PIM):

Für Stufe 0 würde ich Genehmigung und einen Authentication Context mit phishing-resistenter Authentication Strength setzen, für Stufe 1 Begründung und phishing-resistente MFA.

Beachte die Lizenz. Für PIM brauchst Du Microsoft Entra ID P2 oder Microsoft Entra ID Governance für Benutzer mit berechtigten oder befristeten Zuweisungen und für Genehmigende (Lizenzgrundlagen). Microsoft 365 Business Premium enthält laut derselben Seite Entra ID P1, das deckt PIM nicht ab.

PIM warnt unter anderem vor Rollen, die außerhalb von PIM zugewiesen wurden, vor zu vielen Global Administrators und vor Konten in privilegierten Rollen ohne Anmeldung in einem einstellbaren Zeitraum (Security alerts for Microsoft Entra roles in PIM). Die Einstellungen liegen unter "Microsoft Entra roles > Alerts > Setting".

Wenn Du Rollen über Gruppen zuweist, lege dafür rollenzuweisbare Gruppen an. Die Eigenschaft isAssignableToRole lässt sich nur bei der Erstellung setzen und danach nicht mehr ändern, pro Tenant sind höchstens 500 solcher Gruppen möglich. Die Mitgliedschaft muss zugewiesen sein, dynamische Gruppen sind nicht erlaubt, Gruppen lassen sich nicht verschachteln, und zum Anlegen brauchst Du mindestens die Rolle Privileged Role Administrator (Use Microsoft Entra groups to manage role assignments).

Mit PIM für Gruppen aktivierst Du mehrere Rollen mit einer Aktivierung (Empfehlungen für Entra-Rollen, Punkt 8). Bei Gruppen, über die Benutzer in Entra-Rollen aufsteigen, empfiehlt Learn eine Genehmigung für berechtigte Mitgliedschaften (Seite zu rollenzuweisbaren Gruppen, siehe oben). Ohne Genehmigung könnten weniger privilegierte Administratoren Anmeldedaten zurücksetzen und die Zuweisung im Namen des Benutzers aktivieren.

Schritt 5: Anmeldung mit Authentication Strength und Protected Actions härten

Lege eine Conditional-Access-Richtlinie an, die für Verzeichnisrollen die Authentication Strength "Phishing-resistant MFA" verlangt. Die eingebaute Stärke erlaubt FIDO2-Sicherheitsschlüssel, Windows Hello for Business bzw. Plattform-Anmeldeinformationen und zertifikatsbasierte Authentifizierung (mehrstufig) (Authentication strengths). Conditional Access setzt eine Lizenz Microsoft Entra ID P1 voraus.

Registriere die Methoden vorher. Learn warnt, dass die Richtlinie ohne registrierte Methoden Dich aus dem Tenant aussperren kann. Starte im Modus Report-only, nimm die Notfallkonten aus und aktiviere die Richtlinie erst nach der Auswertung.

Ausgenommen werden sollten auch Dienstkonten (Service Accounts) und Service Principals, etwa das Synchronisierungskonto von Microsoft Entra Connect. Für Service Principals empfiehlt Learn Conditional Access für Workload Identities und für Skripte mit solchen Konten Managed Identities (Require phishing-resistant MFA for administrators).

Die Reihenfolge der Härtung erkläre ich im Beitrag Phishing-resistente MFA in Microsoft 365, allgemeine Richtlinien im Beitrag Conditional Access Best Practices.

Eine Einschränkung steht ausdrücklich bei Learn: Conditional-Access-Richtlinien unterstützen eingebaute Rollen. Für Rollenzuweisungen mit dem Geltungsbereich einer Administrative Unit und für benutzerdefinierte Rollen werden sie nicht durchgesetzt.

Setzt Du solche Rollen ein, richte die Conditional-Access-Richtlinie zusätzlich auf eine Gruppe mit den dedizierten Administratorkonten aus, statt nur auf Verzeichnisrollen. Nimm dafür eine rollenzuweisbare Gruppe mit zugewiesener Mitgliedschaft: Ihre Mitgliedschaft verwalten standardmäßig nur Privileged Role Administrators, Besitzer legst Du bewusst fest (Seite zu rollenzuweisbaren Gruppen aus Schritt 4). Das ist meine Empfehlung, Learn beschreibt diesen Fall nicht.

Protected Actions schützen unabhängig davon einzelne Berechtigungen. Sie hängen eine Conditional-Access-Richtlinie an eine Berechtigung, egal über welche Rolle der Benutzer sie erhalten hat. Das gilt nur für wenige Bereiche: die Verwaltung von Conditional-Access-Richtlinien, die Einstellungen für tenantübergreifenden Zugriff, das endgültige Löschen bestimmter Verzeichnisobjekte, benutzerdefinierte Netzwerkstandorte und die Verwaltung der Protected Actions selbst. Das Zurücksetzen von Kennwörtern nennt Learn in dieser Liste nicht.

Die Konfiguration erfordert die Rolle Conditional Access Administrator oder Security Administrator und eine Lizenz Microsoft Entra ID P1 (Protected actions). Der Ablauf hat eine feste Reihenfolge: erst Authentication Context und Richtlinie anlegen, dann die Protected Actions zuweisen, dann testen. Auch hier gehört ein Notfallkonto in die Ausnahme.

Die Richtlinie bei der PIM-Aktivierung greift nur beim Aktivieren einer Rolle. Protected Actions greifen nur, wenn jemand eine geschützte Aktion ausführt, und schützen die Berechtigung unabhängig von der Rolle.

Schritt 6: Admin-Geräte trennen

Learn beschreibt drei Geräteprofile: Enterprise, Specialized und Privileged. Die Privileged Access Workstation (PAW) ist die höchste Stufe für sehr sensible Rollen. Sie schränkt lokale Administratorrechte und Produktivitätsanwendungen ein und blockiert damit nach Learn den häufigsten Angriffsvektor für Phishing: E-Mail und Web-Browsing. Für Produktivität bekommen die Benutzer getrennte Accounts und Arbeitsplätze (Privileged access devices).

Dedizierte PAWs schützen laut Learn außerdem vor Credential Theft wie Keylogging, Pass-the-Hash und Pass-the-Ticket (Securing privileged access, Abschnitt zu dedizierten Arbeitsplätzen).

Specialized-Geräte entfernen die lokalen Administratorrechte und erlauben nur Anwendungen, die ein Administrator installiert hat. Enterprise-Geräte verlangen Verwaltung, Sicherheitsbaseline und Defender for Endpoint. Die Seite beschreibt die technische Umsetzung noch mit Windows 10. Prüfe deshalb die Einstellungen gegen das Windows-Szenario Deiner Geräte.

Die Geräteanforderung setzt Du in Conditional Access durch. Learn zeigt ein Beispiel mit zwei Richtlinien für Administratorrollen: Die erste verlangt für die Windows Azure Service Management API MFA und ein konformes Gerät, die zweite blockiert den Zugriff, außer das Gerät erfüllt den Filter device.extensionAttribute1 equals SAW (Filter for devices).

Die Windows Azure Service Management API deckt nach Learn auch das Microsoft Entra Admincenter ab. Die Zielanwendung "Microsoft Admin Portals" umfasst laut Learn "Exchange Admin Center", "Azure portal", "Microsoft Office 365 Portal" und "Microsoft 365 Security And Compliance Center" (Conditional Access: Zielressourcen).

Schritt 7: Sensible Objekte schützen und regelmäßig prüfen

Restricted Management Administrative Units (RMAU) schützen bestimmte Objekte vor Änderungen durch alle, die nicht ausdrücklich dafür eingetragen sind. Eine RMAU eignet sich laut Learn für die Konten der Geschäftsführung samt Geräten, für Objekte, die nur Administratoren eines bestimmten Landes verwalten sollen, und für Sicherheitsgruppen sensibler Anwendungen. Die Restricted Management Administrative Units sind damit die Ergänzung zu den normalen Administrative Units aus Schritt 3 (Restricted management administrative units).

Selbst ein Global Administrator darf Objekte in einer RMAU nicht ändern, solange er sich nicht selbst einer Rolle mit dem Geltungsbereich der RMAU zuweist. Das ist ein auditierbares Ereignis. Eine RMAU legst Du im Microsoft Entra Admincenter unter "Entra ID > Roles & admins > Admin units" mit dem Schalter "Restricted management administrative unit" an.

Für die Planung gelten diese Grenzen der RMAU:

Plane außerdem wiederkehrende Access Reviews für Administratorrollen ein. Learn nennt als Gründe, dass Konten kompromittiert werden und Personen beim Teamwechsel unnötige Rechte ansammeln (Empfehlungen für Entra-Rollen, Punkt 4). Wie Du Access Reviews einrichtest, steht im Beitrag Access Reviews in Entra ID.

Prüfe dabei auch die Rollenzahl aus Schritt 1, die PIM-Warnungen aus Schritt 4 und die Notfallkonten aus Schritt 2. Aus meiner Sicht können die Ergebnisse Teil des Verfahrens nach Art. 32 Abs. 1 Buchstabe d DSGVO sein.

Typische Fehler bei der Einführung

Diese Fehler ergeben sich aus den Hinweisen und Warnungen in der Dokumentation von Microsoft:

FAQ zu Tiering-Modell und Administratorrollen in Entra ID

Was ist ein Tiering-Modell in Entra ID?

Ein Tiering-Modell ordnet Administratorrollen nach der Reichweite ihrer Rechte in Stufen und legt je Stufe Konto, Gerät und Anmeldung fest. Das Konzept stammt aus dem AD-Tier-Modell. Microsoft hat es zum Enterprise Access Model mit Control Plane, Management Plane und Data/Workload Plane weiterentwickelt.

Ersetzt das Enterprise Access Model das Tier-Modell?

Nach Learn baut das Enterprise Access Model auf dem AD-Tier-Modell auf und erweitert es. Abgelöst hat Microsoft die ESAE-Architektur durch die Strategie für privilegierten Zugriff. Für lokale Active-Directory-Umgebungen empfiehlt Learn weiter einen gestuften Ansatz.

Welche Lizenz brauche ich?

Conditional Access, Authentication Strengths und Protected Actions setzen Microsoft Entra ID P1 voraus. Für PIM brauchst Du P2 oder Microsoft Entra ID Governance. Administrative Units und RMAUs benötigen P1 für jeden Administrator der Einheit. Business Premium enthält P1, aber kein PIM.

Fazit: Administratorrollen nach Reichweite einstufen und absichern

Ein Tiering-Modell für Entra ID besteht aus einer nachvollziehbaren Zuordnung von Rollen zu Stufen und aus Maßnahmen, die mit der Stufe strenger werden. Microsoft hat das Konzept weiterentwickelt, und die Grundregel bleibt: Eine niedrigere Ebene darf eine höhere nicht kontrollieren können.

Beginne mit Bestandsaufnahme, Notfallkonten und getrennten Cloud-Konten, bevor Du PIM und Geräteregeln einführst. Im Microsoft 365 Hardening Check prüfe ich Rollen, Break-Glass-Konten und die MFA-Abdeckung Deiner Administratoren. Zusätzlich gibt es die Hardening-Checkliste als PDF. Allgemeine Härtungsschritte für den Microsoft 365-Tenant beschreibt der Beitrag Microsoft 365 Sicherheit: Den Tenant in der richtigen Reihenfolge härten.