Cyber Essentials v3.3: die Microsoft 365 Auto-Fail-Checkliste

Das Cyber Essentials Fragenset hat sich am 27. April 2026 geändert. Die Danzell-Version führte etwas ein, das es im Programm zuvor nicht gab: Fragen, bei denen eine falsche Antwort die Bewertung sofort scheitern lässt, statt nur die Punktzahl zu senken. Mehrere davon treffen direkt auf Microsoft 365, und zwei davon erwischen Dinge, die die meisten Mandanten seit Jahren still mit sich herumtragen.

Wir sind selbst Cyber Essentials zertifiziert, daher ist dies aus der eigenen Durchführung heraus geschrieben und nicht aus dem Lesen der Spezifikation.

Dies ist eine Checkliste für die Zeit vor der Einreichung, kein Ersatz für das offizielle Fragenset von IASME.

Die Änderung, die viele erwischt

Zwei Dinge sind wichtiger als alles andere.

Fragen zur Multi-Faktor-Authentifizierung können Sie jetzt sofort durchfallen lassen. Früher war eine unvollkommene MFA-Lage etwas, das man erklärte. Jetzt gilt für die Konten im Geltungsbereich: bestanden oder nicht bestanden.

Es gibt eine formale Definition der Cloud-Dienste im Geltungsbereich. Das schließt die Lücke, mit der Organisationen argumentieren konnten, Microsoft 365 liege außerhalb der Bewertungsgrenze. Wenn Ihre Nutzer sich dort anmelden und es Organisationsdaten enthält, ist es im Geltungsbereich. Diese Diskussion ist beendet.

Zusammen bedeuten sie, dass die Bewertung jetzt in Bereiche hineinreicht, die früher unangetastet blieben.

Das ändert die Art der Arbeit. Eine Auto-Fail-Frage ist nichts, wozu man eine sorgfältige Antwort formuliert; entweder Sie können sie ehrlich bejahen oder nicht. Die Aufgabe wird zur Bestandsaufnahme statt zur Formulierung: eine Liste jeder Identität, die sich authentifizieren kann, womit sie sich authentifiziert und was brechen würde, wenn Sie daran etwas ändern. Diese Liste zu erstellen ist der größte Teil des Aufwands. Die Behebung geht meist schnell.

Die Reihenfolge, die einen Cyber Essentials Erfolg wiederholbar macht: zuerst erfassen, dann entscheiden, dann ändern, und die Nachweise aufbewahren.

Die beiden, die wirklich viele erwischen

Dienstkonten

Jeder Mandant hat sie. Das Konto, unter dem ein geplanter Export läuft. Das, mit dem sich eine Branchenanwendung authentifiziert. Das, das 2021 für eine Migration angelegt und nie abgeschaltet wurde.

Sie haben meist keine MFA, weil MFA das kaputt machen würde, was sie automatisieren. Das war tolerierbar, solange die Frage bewertet wurde. Jetzt ist es das nicht mehr.

Finden Sie sie, bevor Sie über sie diskutieren. Zwei Ansichten liefern Ihnen die Kandidatenliste schnell:

• Microsoft Entra Admin Center, Schutz, Authentifizierungsmethoden, Details zur Benutzerregistrierung. Zeigt jedes Konto und ob es MFA-fähig und registriert ist. Filtern Sie auf die Konten ohne registrierte Methode, und Sie sehen Ihr Risiko.
• Entra ID, Überwachung, Anmeldeprotokolle, gefiltert auf nicht-interaktive Benutzeranmeldungen. Automatisierung taucht hier auf, nicht im interaktiven Protokoll. Ein Konto mit Tausenden nicht-interaktiven Anmeldungen und ohne registrierte Methode ist ein Dienstkonto, wie auch immer es jemand genannt hat.

Dieselbe Liste liefert Microsoft Graph PowerShell als CSV:

Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object { -not $_.IsMfaRegistered } |
  Select-Object UserPrincipalName, IsAdmin, IsMfaCapable |
  Export-Csv .\no-mfa.csv -NoTypeInformation

Was zu tun ist, in der Reihenfolge der Präferenz:

1. Ersetzen Sie das Konto vollständig. Eine Workload-Identität oder verwaltete Identität ist die richtige Antwort für alles, was unbeaufsichtigt läuft. Keine interaktive Anmeldung, keine MFA-Frage, kein geteiltes Geheimnis in einer Konfigurationsdatei.
2. Wenn es ein Konto bleiben muss, entziehen Sie die Rechte zur interaktiven Anmeldung, grenzen Sie es mit Conditional Access eng ein und seien Sie in der Lage zu zeigen, was es kann und was nicht.
3. Dokumentieren Sie, warum es existiert. Ein Prüfer akzeptiert eine kontrollierte Ausnahme weit eher als ein Konto, das niemand erklären kann.

Ein durchgerechnetes Beispiel: Ein Finanzexport läuft nächtlich unter einem lizenzierten Konto mit einem Passwort in einer geplanten Aufgabe. Die richtige Antwort verschiebt ihn auf eine App-Registrierung mit Zertifikatsanmeldeinformationen und nur den Graph-Berechtigungen, die der Export braucht, und entfernt damit Konto und Passwort zugleich. Wenn die Anwendung das noch nicht kann, behalten Sie das Konto, blockieren Sie die interaktive Anmeldung, schränken Sie es per Conditional Access auf diesen einen Dienst ein und halten Sie die ausgleichende Maßnahme fest.

Der typische Fehler ist, diese Konten erst in der Woche der Einreichung zu entdecken. Es sind immer mehr, als man erwartet.

Freigegebene Postfächer

Das ist die Sache, die viele überrascht. Ein freigegebenes Postfach soll überhaupt keine aktivierte Anmeldung haben. Der Zugriff soll an benannte Benutzer delegiert werden, die ihre eigene MFA haben.

In der Praxis haben viele Mandanten freigegebene Postfächer mit einem aktivierten zugrunde liegenden Konto und einem Passwort, das irgendjemand kennt, vor Jahren angelegt, damit ein Telefon oder ein Scanner Mail versenden konnte. Das ist ein Konto mit Passwort und ohne MFA, das Organisationsdaten enthält, und das neue Fragenset hat dazu eine klare Meinung.

Prüfen Sie jedes freigegebene Postfach auf eine aktivierte Anmeldung:

Connect-ExchangeOnline
Connect-MgGraph -Scopes 'User.Read.All'
Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
  ForEach-Object { Get-MgUser -UserId $_.ExternalDirectoryObjectId -Property UserPrincipalName,AccountEnabled } |
  Where-Object { $_.AccountEnabled } |
  Select-Object UserPrincipalName

Bei allem, was zurückkommt, muss die Anmeldung blockiert werden, im Entra Admin Center unter Benutzer oder mit Update-MgUser -UserId <upn> -AccountEnabled:$false. Delegieren Sie den Zugriff mit Add-MailboxPermission für Vollzugriff und Add-RecipientPermission für Senden als, sodass jede Aktion an diesem Postfach zu einer Identität mit eigener MFA gehört.

Wenn etwas wirklich unbeaufsichtigt Mail versenden muss, ist das ein Problem der Anwendungsberechtigungen und nicht ein Problem des Postfachpassworts. Verschieben Sie es auf eine App-Registrierung mit eng gefassten Mail-Berechtigungen oder auf einen Empfangsconnector, der auf eine bekannte statische Adresse beschränkt ist. Wo die einfache SMTP-Authentifizierung noch aktiviert ist, schließt Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled $true sie pro Postfach, und die entsprechende Einstellung an Set-TransportConfig schließt sie organisationsweit. Prüfen Sie zuerst, was jedes Gerät unterstützt: ein Multifunktionsgerät, das still das Scannen an E-Mail einstellt, ist eine Support-Warteschlange, für die Ihnen niemand dankt.

Der Rest der Checkliste

Jedes Benutzerkonto mit einer Lizenz hat MFA. Nicht „wir haben eine Richtlinie". Prüfen Sie die Durchsetzung, einschließlich der Konten, die seit dem Verfassen der Richtlinie angelegt wurden, der Gäste und aller, die von Conditional Access ausgenommen sind. Lesen Sie die Ausnahmen jeder einzelnen Richtlinie gezielt, denn dort lebt die Abweichung: eine Projektgruppe, die 2024 für zwei Wochen hinzugefügt wurde, ein Lieferantenkonto, eine Verzeichnisrolle, die die Regel still umgeht.

Gastkonten sind erfasst. Gäste authentifizieren sich in ihrem Heimatmandanten, sodass ihre MFA womöglich anderswo erfüllt wird, und die mandantenübergreifenden Zugriffseinstellungen entscheiden, ob Ihr Mandant dieser Aussage vertraut. Sie müssen keine bestimmte Wahl treffen, aber Sie müssen wissen, welche Sie getroffen haben.

Notfallkonten sind eine dokumentierte Ausnahme. Notfallzugangskonten sind erlaubt. Von Ihnen wird erwartet, dass Sie sie kontrollieren und überwachen: zwei reine Cloud-Konten, ausgenommen von den Richtlinien, die alle aussperren könnten, Anmeldeinformationen aufgeteilt und physisch verwahrt, und eine Warnung, die in dem Moment auslöst, in dem sich eines von beiden anmeldet. Die aktuelle Empfehlung bevorzugt eine phishing-resistente Methode statt eines Passworts allein, prüfen Sie das also, wenn das Paar einige Jahre alt ist.

Administrative Konten sind von den täglich genutzten Konten getrennt. Ein Administrator, der aus derselben Identität heraus E-Mail liest, ist ein Befund, der nur auf seinen Anlass wartet. Wo die Lizenzierung es zulässt, gibt Ihnen zeitlich begrenzte Rechteerhöhung über Privileged Identity Management die Trennung und gleich einen fertigen Nachweis, wer wann welche Rolle innehatte.

Ältere Authentifizierung ist abgeschaltet. Wenn die einfache Authentifizierung noch irgendetwas erreichen kann, stimmt die MFA-Antwort in der Praxis nicht. Filtern Sie die Anmeldeprotokolle auf die Client-App „Andere Clients" und sehen Sie, was erscheint. Die meisten älteren Protokolle in Exchange Online sind längst abgeschaltet; die SMTP-Authentifizierung ist die, die überlebt, weil etwas Operatives davon abhängt.

Ihre Nachweise zum Patchstand der Geräte sind exportierbar. Das Programm interessiert sich für den Zustand der Geräte, und die Antwort muss aus etwas kommen, das Sie zeigen und nicht nur behaupten können. Intune kann das liefern, und den Nachweis aus Intune zu erbringen ist eine eigene Übung, die sich lohnt, bevor Sie sie brauchen. Was Sie wollen, ist ein datierter Export von Build- und Update-Konformität pro Gerät, nicht ein Screenshot eines Dashboards, das nächste Woche anders aussieht.

Ihre Geltungsbereichsbeschreibung entspricht der Realität. Mit der formalen Definition von Cloud-Diensten ist eine ungenaue Grenze jetzt ein glattes Nichtbestehen statt einer Diskussion. Gehen Sie die Liste der Dienste durch, bei denen sich Ihre Leute mit einer Arbeitsidentität anmelden, einschließlich derer, die eine Abteilung eingeführt hat, ohne jemandem Bescheid zu sagen.

Machen Sie das in der richtigen Reihenfolge

Führen Sie die Bestandsaufnahme durch, bevor Sie irgendetwas anfassen. Die Versuchung ist, Anmeldungen schon beim Finden zu blockieren, und so bleibt ein geplanter Rechnungslauf an einem Freitagnachmittag still stehen.

Die Reihenfolge, die funktioniert:

1. Erfassen Sie jedes Konto: Benutzer, Dienstkonten, freigegebene Postfächer, Gäste.
2. Stellen Sie für jedes fest, wofür es da ist und ob etwas davon abhängt.
3. Entscheiden Sie für jedes den Zielzustand.
4. Ändern Sie sie kontrolliert und achten Sie darauf, was bricht.
5. Erfassen Sie die Nachweise unterwegs, denn Sie werden sie nächstes Jahr wieder brauchen.

Planen Sie ungefähr sechs Wochen ein. Herauszufinden, wofür ein rätselhaftes Konto genutzt wird, dauert am längsten, und Conditional-Access-Richtlinien im Nur-Bericht-Modus lassen Sie eine Verschärfung messen, bevor sie jemanden trifft.

Bewahren Sie die Nachweise als datierten Export pro Kontrolle auf statt als Ordner voller Screenshots: der Bericht mit den Registrierungsdetails, die Conditional-Access-Richtlinien mit sichtbaren Ausnahmen, der Anmeldestatus der freigegebenen Postfächer, das Notfallverfahren, der Export zur Gerätekonformität und eine Notiz pro Ausnahme.

Cyber Essentials wird jährlich erneuert, sodass Sie alles, was Sie als Einmalsache bauen, in zwölf Monaten neu bauen. Es als etwas Wiederholbares zu bauen ist der Unterschied zwischen zwei Wochen und einem Nachmittag beim nächsten Mal.

Wo das anschließt

Das Nachweisproblem und das Sicherheitsproblem sind dasselbe Problem aus zwei Blickrichtungen. Unsere Route Microsoft 365 Sicherheit und Konformität deckt die Sicherheitslage ab, und ISO-Konformität und Auditbereitschaft deckt die Nachweiskette ab. Wir haben zuvor über die Zuordnung von Microsoft 365 Einstellungen zu Cyber Essentials und ISO 27001 geschrieben, und diese Zuordnung gilt weiterhin; geändert hat sich die Folge, wenn man sie falsch umsetzt.

Die Kontenhygiene überschneidet sich fast vollständig mit der Arbeit an Eintritten, Wechseln und Austritten, sodass Ihnen die saubere Ausführung der Microsoft 365 Offboarding-Checkliste einen Teil davon abnimmt.

Wo EtherInsights ansetzt

Diese Nachweise jährlich von Hand über einen Mandanten hinweg zusammenzutragen ist genau die Art von Arbeit, die aufgeschoben wird, bis sie dringend ist. EtherInsights gibt es zum Teil aus diesem Grund. Es berichtet über Identitäten und MFA-Abdeckung, Geräte- und Intune-Zustand sowie die Mandantenkonfiguration an einer Stelle, sodass aus der Bestandsaufnahme ein Bericht wird, den Sie nächstes Jahr erneut ausführen und mit diesem hier vergleichen können.

Für Managed-Service-Provider ist die Vervielfachung der Punkt: dieselbe Checkliste über zwanzig Mandanten sind zwanzig Bestandsaufnahmen, und die Konten, die in einem durchfallen, sehen im nächsten meist identisch aus. Sie als wiederholbaren Bericht auszuführen ist das, was die jährliche Erneuerung überstehbar macht, und Microsoft 365 Sicherheit und Konformität ist der Ort, an dem Sicherheitslage und Nachweise zusammenkommen.

Microsoft 365 Sicherheit und Konformität entdecken, um zu sehen, wie Sicherheitslage, Nachweise und die jährliche Neubewertung an einem Ort zusammenkommen.