NIS2 Anforderungen an die Identitaetssicherheit: Was AD- und Entra-Teams nachweisen müssen

NIS2 Anforderungen an die Identitaetssicherheit: Beginnen Sie mit dem, was der Text tatsächlich sagt

Wenn Sie NIS2 Anforderungen an die Identitaetssicherheit verstehen wollen, besteht der erste Fehler darin, NIS2 wie einen Microsoft-Konfigurationsleitfaden zu lesen. Das ist sie nicht. Die Richtlinie (EU) 2022/2555 legt Risikomanagement-Pflichten und Governance-Erwartungen auf EU-Ebene fest. Sie schreibt Teams nicht vor, Microsoft Entra Privileged Identity Management einzuführen, eine bestimmte Conditional-Access-Vorlage durchzusetzen oder in Active Directory eine bestimmte Passwortlänge festzulegen.

Diese Unterscheidung ist wichtig, weil von Identitätsteams weiterhin erwartet wird, etwas Konkretes nachzuweisen. Auch wenn NIS2 keine Microsoft-Produkte nennt, müssen AD- und Entra-Teams zeigen, dass privilegierter Zugriff kontrolliert wird, dass die Authentifizierung dem Risiko angemessen stark ist, dass Zugriffskontrolle in der Produktivumgebung durchgesetzt wird und dass Monitoring Richtlinienverstöße oder Drift nachweisen kann.

Dieser Artikel hält vier Ebenen bewusst getrennt:

Genau diese Einordnung macht den Unterschied zwischen einer belastbaren Identitätsprüfung und einem Compliance-Artikel, der zu viel behauptet.

Was verlangt NIS2 tatsächlich für die Identitätssicherheit?

Auf höchster Ebene verpflichtet Artikel 21(1) der NIS2 die Mitgliedstaaten sicherzustellen, dass wesentliche und wichtige Einrichtungen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen treffen, um Risiken für die Sicherheit von Netz- und Informationssystemen zu beherrschen. Das ist eine risikobasierte Pflicht, keine Checkliste.

Identität taucht in Artikel 21(2) direkter auf. Für dieses Thema sind drei Punkte am wichtigsten:

• Artikel 21(2)(f) umfasst Strategien und Verfahren zur Bewertung der Wirksamkeit von Cybersicherheits-Risikomanagementmaßnahmen.
• Artikel 21(2)(i) umfasst Personalsicherheit, Zugriffskontrollstrategien und Asset-Management. Das ist der einzige Punkt in der Liste, der Zugriffskontrolle direkt nennt, und er ist der Ankerpunkt, auf den sich ein Identitätsteam berufen sollte.
• Artikel 21(2)(j) umfasst den Einsatz von Multi-Faktor-Authentifizierung oder Lösungen für kontinuierliche Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung, soweit angemessen.

NIS2 liefert außerdem wichtigen Kontext in Erwägungsgrund 89, der grundlegende Cyberhygiene-Praktiken wie Zero-Trust-Prinzipien, Software-Updates, Gerätekonfiguration, Netzwerksegmentierung, Identity and Access Management oder Nutzerbewusstsein aufzählt. Dieser Erwägungsgrund ist keine versteckte Microsoft-Baseline. Er ist ein deutliches Signal dafür, dass Identitäts-Governance, Authentifizierung und Zugriffsdisziplin zu dem gehören, was Regulierungsbehörden von Einrichtungen als grundlegende Sicherheitsarbeit erwarten.

Die vorsichtige Auslegung für Identitätsteams lautet: NIS2 schreibt kein einzelnes Herstellermuster vor, erwartet aber klar vertretbare Identitätskontrollen, die risikobasiert, überprüft und in der Lage sind, die Auswirkungen von Vorfällen zu reduzieren.

Wo Identity and Access Management in NIS2 einzuordnen ist

Für AD- und Entra-Teams lautet die praktische Frage nicht: „Welche Microsoft-Funktion verlangt NIS2?" Die praktische Frage lautet: „Welche Ziele der Identitätssicherheit könnten wir bei einer Prüfung nur schwer nachweisen?"

Eine nützliche technische Lesart sieht so aus:

Auch hier bleibt AD & Azure Compliance: NIS2, ISO 27001, CIS hilfreich. Dieser Beitrag ordnet mehrere Rahmenwerke breiter zu. Der Artikel, den Sie gerade lesen, verengt die Frage auf ein schwierigeres Problem: was ein Identitätsteam bei einer NIS2-artigen Prüfung tatsächlich nachweisen kann.

Warum der Geltungsbereich zählt: NIS2, Sektorregeln und nationale Umsetzung

Beim Geltungsbereich gehen viele Compliance-Artikel in die Irre.

Erstens ist NIS2 eine Richtlinie und kein unmittelbar selbstvollziehender Produktstandard. Die Mitgliedstaaten setzen sie in nationales Recht um, und die Aufsichtserwartungen werden durch diese nationale Umsetzung geprägt. Ein Team in Frankreich, Deutschland, Italien oder einem anderen Mitgliedstaat sollte dieselbe EU-Basis erwarten, aber nicht zwangsläufig dieselbe Aufsichtsverpackung, dieselben Referenzmaterialien oder denselben Umsetzungsablauf.

Zweitens stammt nicht jedes technische Detail, das häufig mit NIS2 verbunden wird, direkt aus dem Richtlinientext. Die Durchführungsverordnung (EU) 2024/2690 der Kommission, angenommen am 17 October 2024 nach Artikel 21(5), Unterabsatz 1, legt technische und methodische Anforderungen für eine abschließende Liste von Kategorien erfasster Einrichtungen fest: DNS-Diensteanbieter, TLD-Namenregister, Cloud-Computing-Diensteanbieter, Rechenzentrumsdiensteanbieter, Anbieter von Content-Delivery-Networks, Managed Service Provider, Managed Security Service Provider, Anbieter von Online-Marktplätzen, von Online-Suchmaschinen und von Plattformen für soziale Netzwerke sowie Vertrauensdiensteanbieter. Diese Verordnung ist hochrelevant, ist aber keine generische Abkürzung, die sich unverändert auf jede NIS2-pflichtige Organisation anwenden lässt.

Für Einrichtungen, die in diesen Geltungsbereich fallen, ist der Anhang bei Identitätsthemen deutlich präskriptiver als die Richtlinie selbst. Sein Punkt 11 behandelt Zugriffskontrolle und wird von der Kommission Artikel 21(2) Buchstaben (i) und (j) zugeordnet: Punkt 11.2.3 verlangt, dass Zugriffsrechte in geplanten Abständen überprüft und die Ergebnisse dokumentiert werden, Punkt 11.3 verlangt Richtlinien für privilegierte Konten und Systemadministrationskonten einschließlich starker Authentifizierung wie Multi-Faktor-Authentifizierung, und Punkt 11.7 verlangt mehrere Authentifizierungsfaktoren oder Mechanismen zur kontinuierlichen Authentifizierung, soweit angemessen, wobei die Stärke der Authentifizierung der Einstufung des zugegriffenen Assets entsprechen muss.

Drittens fallen manche Einrichtungen zusätzlich unter sektorspezifische oder nationale Regelwerke. Eine ernsthafte NIS2-Identitätsprüfung braucht deshalb vor ihrem Start drei Prüfschritte:

1. Fällt die Einrichtung in den Geltungsbereich von NIS2, und in welche Kategorie?
2. Ist die Einrichtung zusätzlich von spezifischeren Unions- oder nationalen Texten erfasst?
3. Welche technischen Erwartungen stammen aus der Richtlinie selbst, welche aus Durchführungsakten und welche aus nationalen Leitlinien?

Das ist wichtig, weil Teams sonst Behauptungen aufstellen wie „NIS2 verlangt PIM" oder „NIS2 verlangt 12-stellige Passwörter." Keine der beiden Aussagen ist haltbar: Die Richtlinie nennt kein Produkt, und selbst die Durchführungsverordnung stellt Multi-Faktor-Authentifizierung als Beispiel für starke Authentifizierung dar und nicht als benannte Produktvorgabe.

AD- und Entra-Kontrollen, die NIS2-Identitätsziele häufig unterstützen

NIS2 nennt weder Active Directory noch Microsoft Entra. Wenn Ihre Umgebung sie jedoch einsetzt, sind sie naheliegende Stellen, an denen Evidenz gesammelt wird.

Privilegierter Zugriff

Eine ausgereifte Identitätsprüfung sollte zeigen können, welche Nutzer und Gruppen effektiven administrativen Zugriff On-Premises und in Entra besitzen, wie dieser Zugriff gewährt wurde und ob er noch gerechtfertigt ist.

Das bedeutet in der Regel die Überprüfung von:

• direkter und verschachtelter Mitgliedschaft in privilegierten AD-Gruppen
• Principals mit DCSync-äquivalenten Rechten
• delegierten Rechten auf sensiblen AD-Objekten, insbesondere dort, wo GenericAll, WriteDACL oder WriteOwner Eskalationspfade schaffen
• permanenten gegenüber berechtigten Entra-Rollenzuweisungen
• Konten, die trotz Inaktivität oder Ownership-Drift privilegiert bleiben

Genau deshalb sind Privilegierter Zugriff Drift Active Directory und Azure Privilegierter Zugriff: Zu Viele Globale Admins relevante interne Referenzen zu diesem Thema. Sie beweisen NIS2-Konformität nicht von sich aus. Sie zeigen die Art von Identitätszuständen, die ein Team unter NIS2-Prüfung nur schwer verteidigen könnte.

Stärke der Authentifizierung

NIS2 räumt MFA oder kontinuierlicher Authentifizierung klar einen Platz im Kontrollset ein, aber „soweit angemessen" bleibt wichtig. Ein vertretbares Identitätsprogramm sollte deshalb erklären können:

• welche privilegierten Konten immer hinter MFA liegen
• welche risikoreichen Anwendungen und Admin-Workflows stärkeren Zugriffskontrollen unterliegen
• ob Legacy-Authentifizierungspfade weiterhin offen sind
• ob der Tenant sich nur auf Passwort-plus-Ausnahme-Muster verlässt

Microsofts eigene Dokumentation ist hier hilfreich, weil sie erklärt, was Conditional Access tatsächlich ist: Es „bringt Signale zusammen, um Entscheidungen zu treffen und organisatorische Richtlinien durchzusetzen", und Microsoft beschreibt es inzwischen als seine Zero-Trust-Policy-Engine. Dieselbe Seite fügt ein für die Evidenz wichtiges Detail hinzu: Conditional Access wird durchgesetzt, nachdem die Erstfaktor-Authentifizierung abgeschlossen ist. Das macht es zur Evidenz für einen Kontrollpfad, nicht zum Beweis, dass NIS2 Conditional Access ausdrücklich als Produkt vorgeschrieben hätte.

Ebenso hilft Azure Identitätssicherheit: Warum MFA Allein Nicht Ausreicht, die technische Grenze korrekt einzuordnen: MFA ist wichtig, aber schlechte Rollen-Governance, offener Gastzugriff oder böswilliger App-Consent können weiterhin erhebliche Identitätsrisiken offenlassen.

Zugriffskontrolle, Gastzugriff und App-Berechtigungen

Der Identitätsumfang unter NIS2 reicht weiter als der Mitarbeiter-Login. Zugriffskontrolle betrifft auch externe Nutzer, Anwendungszugriff und delegierte Befugnisse.

Ein technisches Team sollte zeigen können:

• wie Gastzugriff eingeschränkt wird
• wer Gäste einladen darf
• ob Cross-Tenant-Zusammenarbeit eng gesteuert oder weitgehend offen bleibt
• wie App-Berechtigungen und Consent kontrolliert werden
• ob überprivilegierte Enterprise Apps regelmäßig überprüft werden

Das sind keine abstrakten Anliegen. Microsoft dokumentiert, dass Anwendungsberechtigungen app-only Zugriff gewähren können und dass User- oder Admin-Consent steuert, wie Anwendungen Zugriff auf geschützte Ressourcen erhalten. Microsoft dokumentiert außerdem, wie sich User-Consent-Einstellungen einschränken lassen, um böswilligen oder zu breiten Consent zu reduzieren. Deshalb gehören Azure App-Registrierungen: Sicherheitsrisiken und OAuth Consent Phishing: Wie Bösartige Apps Passwortdiebstahl Umgehen zu einer ernsthaften NIS2-Identitätsbetrachtung, obwohl NIS2 selbst diese Produktnamen nie verwendet.

Nachweise, die Sicherheitsteams vorlegen können sollten

Ein schwaches Identitäts-Compliance-Programm hat meist eine Richtliniensammlung, aber kein Evidenzpaket. Bei einer NIS2-orientierten Prüfung sollten AD- und Entra-Teams aktuelle, überprüfbare Nachweise für die Kontrollen vorlegen können, die sie als durchgesetzt bezeichnen.

Ein praktisches Evidenzpaket umfasst in der Regel:

Hier helfen auch Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden, Active Directory-Sicherheit auditieren: praktische Checkliste und AD-Sicherheitsüberwachung: Event-IDs und SIEM, um Framework-Sprache in operative Prüfschritte zu übersetzen.

Häufige Lücken zwischen geschriebener Richtlinie und durchgesetzten Identitätskontrollen

Die risikoreichsten NIS2-Identitätsfehler entstehen meist nicht durch fehlende Richtlinienformulierungen. Sie entstehen durch die Lücke zwischen dem, was die Richtlinie besagt, und dem, was Directory und Tenant tatsächlich durchsetzen.

Häufige Beispiele sind:

• eine schriftliche Least-Privilege-Richtlinie bei gleichzeitig zu vielen permanenten Admins in Entra oder zu vielen dauerhaft privilegierten Gruppen in AD
• eine MFA-Richtlinie, die sensible Admin-Abläufe oder Legacy-Authentifizierungspfade weiterhin nicht wirksam abdeckt
• eine Drittzugriffsrichtlinie, die auf dem Papier existiert, während Gast-Einladungseinstellungen oder Cross-Tenant-Zugriff zu offen bleiben
• ein vierteljährlicher Access-Review-Prozess ohne aktuellen Nachweis, dass Gast-, Gruppen- oder Rollenreviews tatsächlich durchgeführt wurden
• eine App-Governance-Richtlinie, die existiert, wobei aber niemand aktuelle Service-Principal-Berechtigungen, app-only Grants oder Consent-Einstellungen vorlegen kann
• eine Audit- und Monitoring-Richtlinie, die Kontrollen benennt, wobei aber niemand die aktuelle AD-Auditierung oder die aktuelle Entra-Audit-Abdeckung nachweisen kann

Deshalb darf ein NIS2-Identitätsartikel nicht mit Governance-Slogans enden. Ein technisches Team muss den tatsächlich durchgesetzten Zustand zeigen können, nicht nur die geschriebene Absicht.

Frankreich- und ANSSI-Kontext

Da dieser Artikel EU-first ausgerichtet ist, gehört Frankreich in den Kontext und nicht in den normativen Kern.

Die offizielle NIS2-Seite der ANSSI erklärt, dass sie während der gesamten nationalen Umsetzung kommunizieren wird, dass künftige wesentliche und wichtige Einrichtungen ermutigt werden, schon jetzt einen NIS2-konsistenten Sicherheitsansatz zu beginnen, und dass ANSSI seit 17 March 2026 das Référentiel Cyber France (ReCyF) als Arbeitsdokument zur Verfügung stellt. ANSSI erklärt außerdem, dass ReCyF in diesem Stadium standardmäßig nicht verpflichtend ist und dem in Artikel 14 des französischen Résilience-Gesetzentwurfs genannten Cybersicherheits-Rahmen entspricht.

Die vorsichtige Lesart ist unkompliziert:

• ReCyF ist nicht die NIS2-Richtlinie selbst
• ReCyF ersetzt nicht die Lektüre der anwendbaren Rechtstexte
• in Frankreich ansässige Einrichtungen können es dennoch als praktischen Aufsichts-Referenzpunkt nützlich finden
• Teams sollten den Stand der französischen Umsetzung und die Aufsichtserwartungen als nationalen Kontext behandeln, der zusätzlich zur EU-Richtlinie greift

Das macht den ANSSI Active Directory Leitfaden: Die Sicherheitsempfehlungen praktisch umsetzen zu einer hilfreichen ergänzenden Lektüre, aber nicht zu einem Ersatz für die NIS2-Analyse.

Validierung nach der Remediation

Ein NIS2-bereites Identitätsprogramm muss nachweisen, dass Lücken geschlossen wurden, nicht nur, dass sie identifiziert wurden.

Nach der Remediation sollten Teams zeigen können:

1. aktualisierte Inventare privilegierter Zugriffe für AD und Entra
2. aktuelle Nachweise, dass starke Authentifizierungskontrollen dort gelten, wo die Organisation sie zugesagt hat
3. aktualisierte Einstellungen für Gäste, Cross-Tenant und App-Governance nach den Änderungen
4. aktuelle Audit-Nachweise, dass Identitätsänderungen weiterhin sichtbar sind
5. eine aktualisierte Ausnahmenliste, die Restrisiko klar von Drift oder Vernachlässigung unterscheidet

Genau dieser Validierungsschritt unterscheidet eine einmalige Framework-Übung von einer Prüfung, die auch den nächsten Audit-Zyklus übersteht.

Wie EtcSec hilft, NIS2-Identitätslücken zu messen

EtcSec sollte hier eng positioniert werden.

Es geht nicht darum, dass EtcSec „NIS2-Konformität beweist." Es geht darum, dass es hilft, technische Identitätslücken zu messen, die oft relevant sind, wenn ein Team nachweisen will, dass Zugriff, Authentifizierung, Privilegien-Governance und Monitoring tatsächlich durchgesetzt werden.

Beispiele sind:

• EXCESSIVE_PRIVILEGED_ACCOUNTS
• PRIVILEGED_ACCOUNT_STALE
• DANGEROUS_GROUP_NESTING
• DCSYNC_CAPABLE
• ACL_GENERICALL
• CA_NO_MFA_REQUIREMENT
• PA_PIM_NOT_ENABLED
• GUEST_INVITATION_UNRESTRICTED
• B2B_CROSS_TENANT_OPEN
• AZ_SECURITY_DEFAULTS_DISABLED

Diese Findings begründen keine rechtliche Vermutung. Sie helfen einem Sicherheitsteam, eine schwierigere Frage zu beantworten: Wenn wir sagen, unsere Identitätskontrollen seien risikobasiert und durchgesetzt, welche aktuelle Evidenz stützt diese Aussage?

Primärquellen

• Directive (EU) 2022/2555 (NIS2) — EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
• Cybersecurity of network and information systems — EUR-Lex legal summary
• ANSSI: La directive NIS 2
• Microsoft Learn: Microsoft Entra Conditional Access, the Zero Trust policy engine
• Microsoft Learn: What is Privileged Identity Management?
• Microsoft Learn: Learn about the audit logs in Microsoft Entra ID
• Microsoft Learn: Overview of permissions and consent in the Microsoft identity platform
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Restrict guest access permissions in Microsoft Entra ID
• Microsoft Learn: What are access reviews?
• Microsoft Learn: Advanced security audit policy settings