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 die NIS2 Anforderungen an die Identitaetssicherheit verstehen wollen, sollten Sie den ersten Fehler vermeiden: NIS2 wie einen Microsoft-Konfigurationsleitfaden zu lesen. Das ist sie nicht. Die Richtlinie (EU) 2022/2555 definiert Pflichten für das Risikomanagement und Governance-Erwartungen auf EU-Ebene. Sie schreibt Teams nicht vor, Microsoft Entra Privileged Identity Management einzuführen, eine bestimmte Conditional-Access-Vorlage zu erzwingen oder in Active Directory eine konkrete Passwortlänge festzulegen.

Diese Unterscheidung ist wichtig, weil Identitätsteams trotzdem etwas Konkretes nachweisen müssen. Auch wenn NIS2 keine Microsoft-Produkte nennt, müssen AD- und Entra-Teams belegen können, dass privilegierter Zugriff kontrolliert ist, dass die Authentifizierung der Risikolage angemessen ist, dass Zugriffskontrollen tatsächlich in Produktion durchgesetzt werden und dass Monitoring Richtlinienverstöße oder Privilegien-Drift nachvollziehbar macht.

Dieser Artikel trennt vier Ebenen bewusst voneinander:

Genau diese Trennung macht den Unterschied zwischen einer belastbaren Bewertung und einem Compliance-Artikel, der den Text überdehnt.

Was verlangt NIS2 tatsächlich für die Identitaetssicherheit?

Auf der höchsten Ebene verpflichtet Artikel 21(1) der NIS2 die Mitgliedstaaten dazu 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 Produkt-Checkliste.

Identität taucht in Artikel 21(2) direkter auf. Für dieses Thema sind vor allem zwei Punkte entscheidend:

• Artikel 21(2)(i) nennt Strategien und Verfahren zur Bewertung der Wirksamkeit von Cybersicherheits-Risikomanagementmaßnahmen.
• Artikel 21(2)(j) nennt den Einsatz von Multi-Faktor-Authentifizierung oder Continuous Authentication, sichere Kommunikation und sichere Notfallkommunikationssysteme innerhalb der Einrichtung, soweit angemessen.

Wichtiger Kontext steht außerdem in Erwägungsgrund 89. Dort werden grundlegende Cyberhygiene-Praktiken wie Zero-Trust-Prinzipien, Software-Updates, Netzwerksegmentierung, Identity and Access Management und Nutzeraufklärung genannt. Dieser Erwägungsgrund ist keine versteckte Microsoft-Baseline. Er ist ein deutlicher Hinweis darauf, dass Identitäts-Governance, Authentifizierung und Zugriffsdisziplin zu den Grundlagen gehören, die Aufsichtsbehörden erwarten.

Die vorsichtige Lesart für Identitätsteams lautet deshalb: NIS2 schreibt kein einzelnes Herstellermuster vor, erwartet aber klar vertretbare, risikobasierte, überprüfbare Identitätskontrollen, die die Auswirkungen von Vorfällen reduzieren können.

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 in einer Prüfung nicht sauber nachweisen?“

Eine technisch sinnvolle Lesart sieht eher so aus:

Darum bleibt auch AD & Azure Compliance: NIS2, ISO 27001, CIS hilfreich. Dieser Beitrag mappt mehrere Rahmenwerke breiter. Der Artikel hier verengt die Fragestellung auf ein schwierigeres Problem: Was ein Identitätsteam in einer NIS2-orientierten Prüfung tatsächlich belegen können muss.

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

Beim Geltungsbereich entgleisen viele Compliance-Artikel.

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 mitgeprägt. Ein Team in Frankreich, Deutschland, Italien oder einem anderen Mitgliedstaat begegnet derselben EU-Basis, aber nicht zwingend derselben Aufsichtslogik, denselben Referenzdokumenten oder demselben Implementierungsablauf.

Zweitens stammen nicht alle technischen Details, die häufig mit NIS2 verbunden werden, direkt aus dem Richtlinientext. Die Durchführungsverordnung (EU) 2024/2690 legt technische und methodische Anforderungen für bestimmte Kategorien erfasster Einrichtungen nach Artikel 21(5) fest, etwa für DNS-Diensteanbieter, Cloud-Computing-Diensteanbieter, Rechenzentrumsdiensteanbieter, Managed Service Provider, Managed Security Service Provider und Vertrauensdiensteanbieter. Diese Verordnung ist wichtig, aber sie ist keine generische Abkürzung, die sich unverändert auf jede NIS2-pflichtige Organisation übertragen lässt.

Drittens fallen manche Einrichtungen zusätzlich unter spezifischere sektorale oder nationale Regelwerke. Eine belastbare NIS2-Identitätsprüfung muss deshalb drei Fragen klären, bevor sie beginnt:

1. Fällt die Einrichtung in den Geltungsbereich von NIS2 und in welche Kategorie?
2. Gibt es zusätzlich spezifischere Unions- oder nationale Vorgaben?
3. Welche technischen Erwartungen kommen aus der Richtlinie selbst, welche aus Durchführungsakten und welche aus nationalen Leitfäden?

Ohne diese Disziplin entstehen Behauptungen wie „NIS2 verlangt PIM“ oder „NIS2 verlangt 12-stellige Passwörter“. Solche Aussagen lassen sich aus dem EU-Text allein technisch nicht sauber verteidigen.

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

NIS2 nennt weder Active Directory noch Microsoft Entra. Wenn Ihre Umgebung darauf basiert, sind sie aber offensichtliche Stellen, an denen Evidenz gesucht wird.

Privilegierter Zugriff

Eine reife Identitätsprüfung muss 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 typischerweise die Prüfung von:

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

Genau deshalb sind Privilegierter Zugriff Drift Active Directory: Warum Adminrechte nach Audits zurückkehren und Azure Privilegierter Zugriff: Zu Viele Globale Admins passende interne Referenzen. Sie beweisen NIS2-Konformität nicht. Sie zeigen Zustände im Identitätsbereich, die sich unter Aufsicht schwer verteidigen lassen.

Stärke der Authentifizierung

NIS2 räumt MFA oder Continuous Authentication klar einen Platz ein, aber die Formulierung „soweit angemessen“ bleibt wichtig. Ein vertretbares Identitätsprogramm muss daher erklären können:

• welche privilegierten Konten immer hinter MFA liegen
• welche administrativen Workflows und riskanten Anwendungen verstärkten Zugriffskontrollen unterliegen
• ob Legacy-Authentifizierungspfade noch offen sind
• ob der Tenant weiterhin nur auf Passwort-plus-Ausnahmen setzt

Microsoft-Dokumentation ist hier hilfreich, weil sie erklärt, was Conditional Access tatsächlich ist: eine Richtlinien-Engine, die Signale kombiniert und Zugriffsentscheidungen durchsetzt. Das macht sie zu Evidenz für einen Kontrollpfad, nicht zum Beweis, dass NIS2 Conditional Access als Produkt explizit vorgeschrieben hätte.

Genauso hilft Azure Identitätssicherheit: Warum MFA Allein Nicht Ausreicht, die technische Grenze korrekt zu formulieren: MFA ist wichtig, aber schlechte Rollengovernance, zu offene Gastzugriffe oder böswilliger App-Consent können weiterhin erhebliche Identitätsrisiken offenlassen.

Zugriffskontrolle, Gäste und App-Berechtigungen

Der Identitätsumfang in NIS2 reicht weiter als nur Mitarbeitenden-Logins. Zugriffskontrolle betrifft auch externe Nutzer, Anwendungszugriff und delegierte Autorität.

Ein technisches Team sollte nachweisen können:

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

Das sind keine abstrakten Themen. Microsoft dokumentiert, dass Application Permissions 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 überbreiten Consent zu reduzieren. Deshalb gehören Azure App-Registrierungen: Sicherheitsrisiken und OAuth Consent Phishing: Wie bösartige Apps Passwortdiebstahl umgehen zu einer seriösen NIS2-Identitätsbetrachtung, obwohl NIS2 selbst diese Produktnamen nie verwendet.

Welche Nachweise Sicherheitsteams vorlegen können sollten

Ein schwaches Identitäts-Compliance-Programm hat oft eine gute Richtlinie, aber kein belastbares Evidenzpaket. In einer NIS2-orientierten Prüfung müssen AD- und Entra-Teams aktuelle, prüfbare Nachweise zu den Kontrollen vorlegen können, die sie für wirksam halten.

Ein praktisches Evidenzpaket umfasst typischerweise:

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

Häufige Lücken zwischen schriftlicher Richtlinie und tatsächlich erzwungenen Identitätskontrollen

Die größten NIS2-Identitätsfehler entstehen meist nicht durch fehlende Richtlinienformulierung. Sie entstehen durch die Lücke zwischen dem, was eine Richtlinie behauptet, und dem, was Directory oder Tenant tatsächlich durchsetzen.

Typische Beispiele sind:

• eine Least-Privilege-Richtlinie existiert, aber es gibt zu viele permanente Admins in Entra oder zu viele dauerhaft privilegierte Gruppen in AD
• eine MFA-Richtlinie existiert, deckt aber sensible Admin-Flows oder Legacy-Authentifizierungspfade weiterhin nicht wirksam ab
• eine Drittzugriffsrichtlinie existiert auf dem Papier, während Gast-Einladungseinstellungen oder Cross-Tenant-Zugriff zu offen bleiben
• ein quartalsweiser Access-Review-Prozess existiert, aber niemand kann aktuelle Evidenz vorlegen, dass Gast-, Gruppen- oder Rollenreviews tatsächlich durchgeführt wurden
• eine App-Governance-Richtlinie existiert, aber niemand kann aktuelle Service-Principal-Berechtigungen, app-only Grants oder Consent-Einstellungen nachweisen
• eine Audit- und Monitoring-Richtlinie nennt Kontrollen, aber niemand kann den aktuellen Zustand der AD-Audits oder die aktuelle Abdeckung der Entra audit logs belegen

Genau deshalb darf ein NIS2-Identitätsartikel nicht bei Governance-Slogans enden. Ein technisches Team muss einen tatsächlich erzwungenen Zustand nachweisen können, nicht nur eine geschriebene Absicht.

Frankreich- und ANSSI-Kontext

Weil dieser Artikel EU-first bleibt, gehört Frankreich in den Kontext und nicht in den normativen Kern.

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

Die vorsichtige Lesart ist geradlinig:

• ReCyF ist nicht die NIS2-Richtlinie selbst
• ReCyF ersetzt nicht die Lektüre der anwendbaren Rechtstexte
• in Frankreich ansässige Einrichtungen können es trotzdem als praktischen Referenzpunkt im Verhältnis zur nationalen Aufsicht nutzen
• Teams sollten den Stand der französischen Umsetzung und die ANSSI-Erwartungen als nationale Ebene behandeln, die zusätzlich zur EU-Richtlinie wirkt

In diesem Sinn ist ANSSI Active Directory Leitfaden: So setzen Sie die Sicherheitsempfehlungen praktisch um eine sinnvolle ergänzende Lektüre, aber kein Ersatz für die NIS2-Analyse.

Remediation

Noch vor der formalen Validierung sollten Teams konkrete Remediation für die Punkte anstoßen, die sie in einer Prüfung nicht verteidigen könnten. Praktisch bedeutet das, unnötige permanente Privilegien abzubauen, noch offene Legacy-Authentifizierungspfade zu schließen, die Governance von Gastzugriffen und Cross-Tenant-Zugriff zu härten, überprivilegierte Service Principals zu überprüfen und den korrigierten Zustand sauber zu dokumentieren.

Validierung nach der Remediation

Ein Identitätsprogramm, das einer NIS2-Prüfung standhalten soll, muss zeigen können, dass Lücken geschlossen wurden und nicht nur identifiziert sind.

Nach der Remediation sollten Teams vorlegen können:

1. aktualisierte Inventare privilegierter Zugriffe in AD und Entra
2. aktuelle Evidenz dafür, dass starke Authentifizierung dort gilt, wo die Organisation sie zugesagt hat
3. aktualisierte Einstellungen für Gäste, Cross-Tenant und App-Governance nach den Änderungen
4. aktuelle Audit-Evidenz dafür, dass Identitätsänderungen weiterhin sichtbar bleiben
5. eine überarbeitete Ausnahmenliste, die Restrisiko sauber von Drift oder Vernachlässigung trennt

In der Praxis sind die Maßnahmen, die die Verteidigungsfähigkeit einer Identitätslage am stärksten verbessern, oft dieselben: unnötige permanente Privilegien entfernen, noch offene Legacy-Zugriffe schließen, Gäste und Cross-Tenant-Zugriff prüfen, überprivilegierte Service Principals inventarisieren und anschließend die Exporte und Logs erneut ziehen, die als Evidenz dienen. Ziel ist nicht eine weitere Folie. Ziel ist der Nachweis, dass eine behauptete Kontrolle nach der Korrektur weiterhin real existiert.

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

Wie EtcSec hilft, für NIS2 relevante Identitätslücken zu messen

EtcSec sollte hier bewusst eng positioniert werden.

Es geht nicht darum zu behaupten, EtcSec „beweise NIS2-Konformität“. Es geht darum, dass EtcSec technische Identitätslücken messbar macht, die relevant werden, wenn ein Team nachweisen muss, 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 bei der schwierigeren Frage: Wenn wir behaupten, unsere Identitätskontrollen seien risikobasiert und wirksam umgesetzt, welche aktuelle technische Evidenz stützt diese Aussage?

Primärquellen

• Directive (EU) 2022/2555 (NIS2) — EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
• EUR-Lex-Rechtszusammenfassung zur Cybersicherheit von Netz- und Informationssystemen
• ANSSI: La directive NIS 2
• Microsoft Learn: What is Conditional Access?
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
• Microsoft Learn: What are Microsoft Entra audit logs?
• 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