NIS 2 Zugriffskontrolle nach Artikel 21(2)(i)+(j)
Artikel 21(2)(i) nennt Konzepte für die Zugriffskontrolle. Artikel 21(2)(j) nennt Multi-Faktor-Authentifizierung. CIR §11 deckt beide gemeinsam in sieben Unterabschnitten. Diese Seite geht durch die breitere Policy-, Admin- und Identitätspflicht. Die eigene MFA-Seite deckt §11.7.
Die Kurzfassung
Zugriffskontrolle steht in Punkt (i) und (j) von Artikel 21(2). Punkt (i) nennt 'Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen'. Punkt (j) nennt 'Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation'. Beides gilt für jede wesentliche und wichtige Einrichtung in der EU.
CIR (EU) 2024/2690 §11 deckt beide Buchstaben gemeinsam ab, unter dem Titel 'Zugriffskontrolle (Artikel 21 Absatz 2 Buchstaben i und j der Richtlinie (EU) 2022/2555)'. §11 zerlegt die Pflicht in sieben Unterabschnitte: das Konzept selbst, Rechtemanagement, privilegierte Konten, Systemverwaltungssysteme, Identifizierung, Authentifizierung und Multi-Faktor-Authentifizierung. Diese Seite geht durch §11.1 bis §11.6. Für §11.7 siehe die eigene MFA-Seite.
Deutschland setzt die Konzeptpflicht in §30 Abs. 2 Nr. 9 BSIG um und die MFA-Pflicht in §30 Abs. 2 Nr. 10 BSIG. Die deutsche Umsetzungsbasis ist IT-Grundschutz ORP.4 'Identitäts- und Berechtigungsmanagement'.
info.accessControl.legalAnchor.directiveI.label
info.accessControl.legalAnchor.directiveI.quote
info.accessControl.legalAnchor.directiveI.context
info.accessControl.legalAnchor.directiveJ.label
info.accessControl.legalAnchor.directiveJ.quote
info.accessControl.legalAnchor.directiveJ.context
CIR (EU) 2024/2690, Anhang §11
Zugriffskontrolle (Artikel 21 Absatz 2 Buchstaben i und j der Richtlinie (EU) 2022/2555).
CIR §11 hat sieben Unterabschnitte: §11.1 Konzept für die Zugriffskontrolle, §11.2 Management von Zugangs- und Zugriffsrechten, §11.3 privilegierte Konten und Systemverwaltungskonten, §11.4 Systemverwaltungssysteme, §11.5 Identifizierung, §11.6 Authentifizierung, §11.7 Multi-Faktor-Authentifizierung. Diese Verordnung bindet DNS-Anbieter, Cloud, Rechenzentren, Managed Service Provider und die übrigen im Anhang genannten Sektoren direkt.
§30 Abs. 2 Nr. 9 und Nr. 10 BSIG (Deutschland)
Konzepte für die Zugriffskontrolle und für das Management von Anlagen. […] Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung.
Deutschland teilt den EU-Punkt (i)+(j) in zwei BSIG-Nummern. §30 Abs. 2 Nr. 9 trägt Zugriffskontrolle und Asset Management. §30 Abs. 2 Nr. 10 trägt MFA und sichere Kommunikation. Die Substanz ist dieselbe EU-Regel.
Konzept und Rechtemanagement
Schriftlich festhalten, wie Zugang (logisch und physisch) für Personal, Besucher, Anbieter und Dienstleister funktioniert. Rechte vergeben, ändern und entziehen nach Geschäftsbedarf: Kenntnis-nur-wenn-nötig, Nutzung-nur-wenn-nötig, Funktionstrennung. Jedes Recht ist einer namentlich genannten Person zugeordnet. Entzug erfolgt bei Beschäftigungsänderung, nicht im Wochenrhythmus. Dritter-Zugang (Besucher, Anbieter) wird nachgehalten.
Privilegierte und Admin-Konten
Admin-Konten bekommen starke Identifizierung, Authentifizierung und Autorisierung. Ausschließlich dedizierte Administrationskonten, nur für Installation, Konfiguration, Verwaltung und Wartung. Admin-Rechte sind individuell zugeschnitten und beschränkt. Systemverwaltungssysteme liegen in einem eigenen logischen Netz, getrennt von Anwendungsnetzen, Zugriff über Authentifizierung und Verschlüsselung.
Identifizierung und Authentifizierung
Identitätslebenszyklus: eindeutige Kennungen, jede Kennung einer Person zugeordnet, Überwachung und Protokollierung über den Lebenszyklus. Authentifizierungsverfahren passen zur Zugriffskontrolle: Passwortstärke skaliert mit Asset-Klassifizierung, Änderungsverfahren, Sperre nach Fehlversuchen, Sitzungs-Timeouts, getrennte Anmeldedaten für privilegierte Konten.
Kenntnis-nur-wenn-nötig, Nutzung-nur-wenn-nötig, Funktionstrennung
CIR §11.2 nennt alle drei. Kenntnis-nur-wenn-nötig: nur wer die Daten braucht, bekommt sie. Nutzung-nur-wenn-nötig: Rechte passen zur Aufgabe, nicht zum Titel. Funktionstrennung: keine einzelne Person darf dasselbe Recht vergeben, nutzen und prüfen können. Wenn Ihre AD-Gruppen 'IT' und 'alle anderen' heißen, haben Sie keines der drei umgesetzt.
Privilegiert ist nicht einfach normal mit mehr Rechten
CIR §11.3 und §11.4 ziehen die Latte speziell für Admin-Konten höher. Starke Identifizierung. MFA steht schon in §11.3 selbst, nicht erst in §11.7. Dedizierte Konten ausschließlich für Admin-Arbeit. Systemverwaltungssysteme im eigenen Netz. Der Punkt: ein kompromittiertes Admin-Konto kompromittiert alles, also bekommen Admin-Konten ein eigenes Regime.
BSI / IT-Grundschutz ORP.4
Die deutsche Umsetzungsbasis ist der IT-Grundschutz-Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'. ORP.4 deckt Identitätslebenszyklus, rollenbasierte Rechte, Trennung privilegierter Konten, Passwortregeln und Prüfzyklus ab. Nach §44 Abs. 2 BSIG erfüllt eine Grundschutz-Umsetzung die NIS 2-Pflichten in Deutschland.
ENISA Technical Implementation Guidance
Die ENISA Technical Implementation Guidance zu CIR (EU) 2024/2690 geht jeden §11 Unterabschnitt operativ durch und bildet ihn auf ISO/IEC 27001:2022 (A.5.15 bis A.5.18, A.8.2 bis A.8.5) und NIST CSF 2.0 (PR.AA) ab. Eine bestehende ISO 27001-Umsetzung deckt einen Großteil von §11 bereits ab.
Nationale Umsetzungsgesetze
Jeder Mitgliedstaat setzt Artikel 21(2)(i) und (j) in eigenes Recht um (Niederlande: Cyberbeveiligingswet, Österreich: NISG, Belgien: NIS2-Wet). Die Pflichten sind identisch, weil die Richtlinie einen EU-weiten Standard setzt. Unterschiedlich ist, welchen Grundlagen-Standard die nationale Aufsicht heranzieht.
Wir haben AD-Gruppen, also haben wir Zugriffskontrolle.
Ein Anfang, aber nicht das Ziel. CIR §11.2 verlangt ein dokumentiertes Rechtekonzept, Rechte auf namentlich genannte Personen, ein Entzugsverfahren an die Beschäftigung gekoppelt und ein Audit-Log über Vergabe und Entzug. AD-Gruppen geben den Mechanismus. Sie liefern nicht das Konzept, das Personenregister oder das Joiners-Movers-Leavers-Verfahren, das der Auditor sehen will.
Unsere Admins arbeiten administrativ aus ihrem normalen Konto mit sudo oder 'Als Administrator ausführen'.
Nicht unter CIR §11.3.2. Der Text verlangt 'dedizierte Administrationskonten', die ausschließlich für Installation, Konfiguration, Verwaltung und Wartung genutzt werden. Das normale Konto eines Admins ist für Mail, Kalender und Excel. Ein getrenntes Admin-Konto mit eigener MFA ist für die privilegierte Arbeit. Vermischung bedeutet: eine Phishing-Mail kompromittiert die Admin-Rolle.
Wir gleichen die Zugriffsrechte jeden Montag morgens ab.
Nah dran, aber nicht das, was §11.2 verlangt. Die Entzugspflicht greift mit der Beschäftigungsänderung, nicht im Kalenderzyklus. Wer am Dienstag austritt, hat am Mittwoch keinen Zugriff mehr. Bei Rollenwechseln im Haus, besonders bei privilegierten, ist die Änderung unmittelbar. Ein Wochenrhythmus ist in Ordnung für die Prüfung, nicht für den Entzug selbst.
Typische Aufstellung im 50-250-Personen-Mittelstand: Active Directory oder Entra ID für Identitäten, AD-Gruppen für Anwendungszugriff, ein HR-System, das Onboarding-Tickets an die IT erzeugt. Der Mechanismus steht meistens. Die §11-Lücken liegen an drei Stellen.
Was Praktiker zuerst aufdecken: ein schriftliches Rechtekonzept (die meisten haben einen Entwurf, wenige eine aktuelle unterschriebene Fassung), dedizierte Administrationskonten (die meisten Admins arbeiten noch mit sudo aus dem Tageskonto) und ein Joiners-Movers-Leavers-Verfahren, das IT-getrieben statt HR-getrieben ist (so dass das Konto eines Externen liegen bleibt, weil HR die IT nie informiert hat). Diese drei Punkte schließen den größten Teil der §11-Lücke.
Unser ACC-Modul deckt §11.1 (Sie hinterlegen oder entwerfen das Zugriffskonzept, die Leitung zeichnet es ab), §11.2 (ein Rechteregister mit namentlich genannten Nutzern), §11.3 (Inventar privilegierter Konten mit getrennter Authentifizierungs-Evidenz) und §11.5 sowie §11.6 (Identitätsquellen-Log gegen Ihren IdP). Die §11.4-Trennung der Systemverwaltungssysteme wird als Architekturentscheidung mit Evidenz dokumentiert.
Für §11.7 MFA siehe die eigene MFA-Seite und ihren Evidenz-Pfad. Das Audit-Log, das die Plattform automatisch führt (Freigaben, Aufgabenstatus, Änderungsverlauf), deckt das ab, was ein Auditor zu Prüfzyklus und Leitungsentscheidung sehen will.
- Richtlinie (EU) 2022/2555 (NIS 2), Artikel 21(2)(i) und (j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Durchführungsverordnung (EU) 2024/2690 (CIR), Anhang §11 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI-Gesetz (BSIG), §30 Abs. 2 Nr. 9 und Nr. 10 in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes
- IT-Grundschutz-Kompendium, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance zu CIR (EU) 2024/2690 (Stand Mai 2026)