NIS2 in der Praxis: MFA, Zugriffskontrolle und Audit-Trails mit Authentik DSGVO-konform umsetzen

Inhaltsverzeichnis

• Sechs Monate NIS2UmsuCG: Wo die Umsetzung im Juni 2026 steht
• Was NIS2 konkret verlangt: Zugriffskontrolle und MFA in § 30 Abs. 2 BSIG
• Multi-Faktor-Authentifizierung nach § 30 Abs. 2 Nr. 10 mit Authentik umsetzen
• Zugriffskontrolle nach § 30 Abs. 2 Nr. 9: RBAC, Gruppen und applikationsbezogene Policies
• Audit-Trails und Nachweispflicht: Events, Aufbewahrung und Weiterleitung
• DSGVO-konform und souverän: Art. 32, Hosting in Deutschland und AVV
• Die ehrlichen Grenzen: Was ein IAM für NIS2 leistet und was nicht
• Schritt für Schritt: NIS2-relevante Identity-Bausteine in Authentik
• authhost: Managed Authentik auf deutscher Infrastruktur
• Fazit
• Quellen

Sechs Monate NIS2UmsuCG: Wo die Umsetzung im Juni 2026 steht

Das NIS2-Umsetzungsgesetz (NIS2UmsuCG) wurde am 5. Dezember 2025 im Bundesgesetzblatt verkündet und trat ohne Übergangsfrist am 6. Dezember 2025 in Kraft [1]. Seit dem 6. Juni 2026 ist es damit ein halbes Jahr in Geltung. Die deutsche Umsetzung erweitert den Kreis der betroffenen Einrichtungen erheblich: Statt der wenigen Tausend KRITIS-Betreiber des alten Rahmens fallen jetzt rund 29.500 Unternehmen unter das novellierte BSIG [1]. Laut Prognose des Regierungsentwurfs aus Dezember 2023 verteilen sich diese voraussichtlich auf etwa 8.250 besonders wichtige und 21.600 wichtige Einrichtungen über 18 Sektoren; diese Aufteilung ist eine Schätzung der Gesetzesbegründung, keine amtlich erhobene Ist-Zahl [2].

Die Praxis hinkt der Pflicht hinterher. Innerhalb von drei Monaten nach Inkrafttreten mussten sich betroffene Einrichtungen nach § 33 Abs. 1 BSIG beim BSI registrieren, also bis zum 6. März 2026; das Melde- und Informationsportal stand seit dem 6. Januar 2026 bereit [1]. Laut der Halbzeitbilanz, die BDO Anfang Juni 2026 veröffentlicht hat, waren zur Frist erst rund 11.500 Unternehmen registriert, etwa 38,5 Prozent. Bis Anfang April stieg die Quote auf rund 15.500 Einrichtungen, knapp über 50 Prozent [1]. Diese Zahlen sind eine BDO-Auswertung, keine auditierte BSI-Statistik, zeigen aber die Größenordnung der Lücke.

Für Entscheider ist das relevant, weil eine versäumte Registrierung aufsichtsrechtliche Folgen haben kann, unabhängig davon, ob jemals ein Sicherheitsvorfall eintritt. Wer die Registrierung nachholt, braucht parallel ein belastbares Risikomanagement. Genau hier setzen die technischen Mindestmaßnahmen an.

Was NIS2 konkret verlangt: Zugriffskontrolle und MFA in § 30 Abs. 2 BSIG

§ 30 Abs. 2 BSIG listet zehn Mindestmaßnahmen auf, die besonders wichtige und wichtige Einrichtungen nach dem Stand der Technik umsetzen müssen. Zwei davon sind unmittelbar Identity-Themen [3]:

Diese beiden Nummern setzen Artikel 21 Abs. 2 der NIS2-Richtlinie (EU) 2022/2555 in deutsches Recht um. Dort entspricht Buchstabe i der Sicherheit des Personals und den Konzepten für die Zugriffskontrolle, Buchstabe j der Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung sowie der gesicherten Sprach-, Video- und Textkommunikation [4][5].

Wichtig ist die Lesart: Das Gesetz fordert ein Konzept für die Zugriffskontrolle und die Verwendung von MFA, nicht ein bestimmtes Produkt oder eine bestimmte Technik. Es ist also kein Häkchen, das man mit dem Kauf einer Software setzt, sondern eine umgesetzte, dokumentierte und überprüfbare Architektur. Ein Identity-Provider ist das Werkzeug, mit dem sich diese Architektur technisch abbilden lässt, das Konzept dahinter müssen Sie selbst formulieren.

Andere Nummern aus § 30 Abs. 2 BSIG berührt ein IAM nur am Rande: die Bewältigung von Sicherheitsvorfällen (Nr. 2), die Bewertung der Wirksamkeit der Risikomanagementmaßnahmen (Nr. 6) und kryptographische Verfahren (Nr. 8) [3]. Darauf kommen wir bei den Grenzen zurück.

Multi-Faktor-Authentifizierung nach § 30 Abs. 2 Nr. 10 mit Authentik umsetzen

In Authentik ist MFA keine globale Einstellung, sondern eine Stage in einem Flow. Die Authenticator Validation Stage prüft an einem definierten Schritt des Anmeldeflows einen zweiten Faktor. Unterstützt werden TOTP, WebAuthn/FIDO2/Passkeys, statische Recovery-Codes, SMS, E-Mail und Duo [8]. Welche dieser Verfahren an einem konkreten Schritt zulässig sind, steuert die Device-Class-Konfiguration der Stage. So lässt sich erzwingen, dass privilegierte Rollen ausschließlich phishing-resistente Passkeys nutzen, während für andere Gruppen auch TOTP zulässig bleibt.

Das deckt sich mit der Einordnung des BSI: Im NIS2-Infopaket zur Multi-Faktor-Authentisierung würdigt das BSI Passkeys als sehr sichere, phishing-resistente Authentisierung auf Basis kryptografischer Schlüsselpaare und empfiehlt für höhere Schutzstufen zwei Faktoren aus unterschiedlichen Kategorien. Passkeys werden aber weder in der NIS2-Richtlinie noch im BSIG erwähnt und sind nicht verpflichtend [7]. Authentik gibt Ihnen die Freiheit, das risikobasiert zu staffeln, statt einen Faktor für alle vorzuschreiben.

Brute-Force-Versuche fängt Authentik mit einer Drosselung ab: Wiederholte Fehlversuche werden mit exponentiellem Back-off verzögert, nach der Formel delay_seconds = factor * 2^(n-1) [8]. Dieser Schutz galt bereits für TOTP und statische Codes; mit Version 2026.5, veröffentlicht am 22. Mai 2026, wurde er auf E-Mail- und SMS-OTP erweitert [11][12]. WebAuthn und Duo werden nicht gedrosselt, und ein Faktor von 0 deaktiviert die Drosselung [8]. Wer eine bestehende Authentik-Instanz betreibt, sollte für die NIS2-Umsetzung mindestens auf 2026.5 aktualisieren, um diesen erweiterten Schutz mitzunehmen.

Wie sich Authentik bei der MFA gegen die großen US-Anbieter schlägt, zeigt der Vergleich Authentik vs. Entra ID sowie unsere Gegenüberstellung mit der Okta-Alternative Authentik.

Zugriffskontrolle nach § 30 Abs. 2 Nr. 9: RBAC, Gruppen und applikationsbezogene Policies

Zugriffskontrolle umfasst in Authentik zwei verschiedene Ebenen, die man sauber auseinanderhalten sollte.

Die erste Ebene ist die interne Administration über RBAC. Rollen bündeln Berechtigungen und werden Gruppen oder Nutzern zugewiesen; sie steuern, wer innerhalb von Authentik welche Objekte verwalten darf, etwa Nutzer anlegen, Flows bearbeiten oder Anwendungen anbinden. Authentik unterscheidet dabei globale und objektbezogene Berechtigungen [9]. Mit Version 2025.12 hat das Projekt das Modell vereinheitlicht: Berechtigungen werden seither ausschließlich über Rollen vergeben, direkte Nutzer-Berechtigungen entfallen und wurden bei der Migration in automatisch erzeugte Rollen überführt [13]. Das macht das Berechtigungsmodell konsistenter und damit auditierbarer, ein praktischer Pluspunkt für die Nachweisführung.

Die zweite Ebene ist der Anwendungszugriff. Welcher Nutzer welche angebundene Anwendung überhaupt erreicht, regeln applikationsbezogene Policies und die Gruppenmitgliedschaft. Eine Policy kann beispielsweise prüfen, ob ein Nutzer in der Gruppe „Finanzen" ist, bevor die Buchhaltungssoftware freigegeben wird. So entsteht ein nachvollziehbares Zugangssteuerungskonzept, das genau dem entspricht, was § 30 Abs. 2 Nr. 9 BSIG und Artikel 21 Abs. 2 Buchstabe i der NIS2-Richtlinie als Konzept für die Zugriffskontrolle verlangen [3][4].

Für regulierte Einrichtungen ist die Trennung dieser beiden Ebenen wichtig: Die Frage „Wer darf Authentik selbst verwalten?" ist eine andere als „Wer darf auf die ERP-Anwendung zugreifen?". Ein gutes Zugriffskonzept dokumentiert beide getrennt. Wie sich das gegen selbstgehostete Alternativen verhält, beleuchtet der Vergleich Authentik vs. Authelia vs. Keycloak.

Audit-Trails und Nachweispflicht: Events, Aufbewahrung und Weiterleitung

NIS2 und DSGVO verlangen nicht nur, dass Maßnahmen existieren, sondern dass ihre Wirksamkeit überprüfbar ist. Dafür braucht es Audit-Trails. Authentik protokolliert jedes Event und entfernt dabei Credentials aus den gespeicherten Daten; erfasst werden unter anderem der beteiligte Nutzer, der Zeitpunkt und die ausgeführte Aktion [10]. Anmeldungen, fehlgeschlagene Logins, Berechtigungsänderungen und administrative Eingriffe landen so in einem durchsuchbaren Event-Log.

Die Standard-Aufbewahrung beträgt 365 Tage und lässt sich in den System-Einstellungen anpassen [10]. Für die Nachweisführung über längere Zeiträume reicht ein einzelnes IAM-Log aber selten: Events lassen sich per Notification-Transport an lokale Ziele, E-Mail oder Webhook weiterleiten und damit in ein zentrales SIEM einspeisen, das die revisionssichere Langzeitaufbewahrung übernimmt [10].

Dieser Audit-Trail zahlt direkt auf DSGVO Art. 32 Abs. 1 Buchstabe d ein, der ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen fordert [6]. Wer protokolliert, wer wann auf was zugegriffen hat, kann diese Wirksamkeit belegen. Im Ernstfall liefert das Event-Log außerdem die Basis für die Incident-Analyse, die in eine NIS2-Meldung einfließt. Wie sich ein konkreter Vorfall mit Authentik eindämmen lässt, beschreibt unser Beitrag zur Sofort-Reaktion mit Authentik Account Lockdown.

DSGVO-konform und souverän: Art. 32, Hosting in Deutschland und AVV

NIS2 und DSGVO überschneiden sich beim Thema Sicherheit der Verarbeitung. DSGVO Art. 32 Abs. 1 verlangt technische und organisatorische Maßnahmen, die dem Risiko angemessen sind: unter anderem Pseudonymisierung und Verschlüsselung (Buchstabe a), die Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit (Buchstabe b), die rasche Wiederherstellung nach einem Vorfall (Buchstabe c) und das bereits genannte Verfahren zur regelmäßigen Überprüfung der Wirksamkeit (Buchstabe d) [6].

Ein Identity-Provider verarbeitet besonders sensible Daten: Identitäten, Anmeldedaten und vollständige Zugriffsprotokolle. Wo diese Daten liegen, ist deshalb keine Nebensache. Eine Authentik-Instanz auf Infrastruktur in Deutschland hält Identitäts- und Audit-Daten in einer EU-souveränen Umgebung, außerhalb der Reichweite des US-amerikanischen CLOUD Act. Für die organisatorische Seite gehört ein Auftragsverarbeitungsvertrag (AVV) dazu, der die Pflichten zwischen Einrichtung und Hoster regelt.

Ehrlich bleibt aber: DSGVO-Konformität ist keine reine Produkteigenschaft. Hosting in Deutschland und ein AVV adressieren die technischen und organisatorischen Maßnahmen, doch das Verzeichnis der Verarbeitungstätigkeiten, die Rechtsgrundlagen der Verarbeitung und die Wahrung der Betroffenenrechte bleiben Ihre Verantwortung. Eine souveräne Infrastruktur ist eine notwendige, keine hinreichende Bedingung.

Die ehrlichen Grenzen: Was ein IAM für NIS2 leistet und was nicht

Diese Einordnung ist der Kern des Beitrags: Ein sauber konfiguriertes, in Deutschland gehostetes Authentik adressiert § 30 Abs. 2 Nr. 9 und Nr. 10 BSIG sowie die Audit-Erwartung aus DSGVO Art. 32 technisch. Es ersetzt aber kein Compliance-Programm.

Konkret deckt ein Identity-Provider die folgenden Maßnahmen nicht ab [3]:

• Bewältigung von Sicherheitsvorfällen (Nr. 2) über die reine Account-Eindämmung hinaus: Playbooks, Rollen und Eskalationswege sind organisatorisch.
• Bewertung der Wirksamkeit (Nr. 6) als Prozess: Das Event-Log liefert Daten, die Bewertung selbst ist ein wiederkehrender Managementprozess.
• Kryptographische Verfahren (Nr. 8), Backup- und Krisenmanagement, Lieferkettensicherheit und Schulungen: eigene technische und organisatorische Maßnahmen.

Hinzu kommen die Meldepflichten nach § 32 BSIG: eine Erstmeldung oder Frühwarnung unverzüglich, spätestens innerhalb von 24 Stunden, eine Folgemeldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats [2]. Das ist ein Prozessthema, kein Produktfeature. Und schließlich tragen Geschäftsleitungen nach dem BSIG eine persönliche Verantwortung für die Risikomanagementmaßnahmen; bei Verstößen drohen besonders wichtigen Einrichtungen nach § 65 BSIG Bußgelder bis 10 Mio. EUR oder 2 Prozent des weltweiten Jahresumsatzes, wichtigen Einrichtungen bis 7 Mio. EUR oder 1,4 Prozent [2].

Die Botschaft ist nicht, dass ein IAM wenig leistet, sondern dass es das Richtige leistet: Es bildet zwei der zehn Mindestmaßnahmen technisch sauber ab und liefert die Audit-Grundlage für eine dritte. Das ist ein solider, abgrenzbarer Baustein in einem größeren Risikomanagement.

Schritt für Schritt: NIS2-relevante Identity-Bausteine in Authentik

Wer die Theorie in eine konkrete Konfiguration übersetzen will, geht in dieser Reihenfolge vor:

1. MFA verpflichtend machen. Fügen Sie eine Authenticator Validation Stage in den Authentifizierungs-Flow ein und legen Sie über die Device-Classes fest, welche Verfahren zulässig sind, etwa nur Passkeys für Administratoren [8].
2. Faktoren risikobasiert staffeln. Trennen Sie privilegierte Rollen von Standardnutzern und erzwingen Sie für erstere phishing-resistente Verfahren, wie es das BSI für höhere Schutzstufen empfiehlt [7].
3. RBAC aufräumen. Vergeben Sie administrative Berechtigungen ausschließlich über Rollen und Gruppen; ab 2025.12 ist das ohnehin der einzige Weg [13].
4. Anwendungszugriff über Policies binden. Knüpfen Sie den Zugriff auf jede angebundene Anwendung an Gruppenmitgliedschaft oder eine Policy, statt ihn pauschal zu öffnen [9].
5. Audit-Aufbewahrung und SIEM-Weiterleitung konfigurieren. Prüfen Sie die 365-Tage-Aufbewahrung und richten Sie einen Notification-Transport per Webhook in Ihr SIEM ein [10].
6. Auf 2026.5 aktualisieren. Damit erhalten Sie unter anderem das erweiterte OTP-Throttling und aktuelle Conditional-Access-Signale [11].

Jeder dieser Schritte ist dokumentierbar und damit Teil des nach NIS2 geforderten Konzepts. Wer Authentik mit anderen Open-Source-Lösungen vergleicht, findet weitere Entscheidungshilfen bei der Auth0-Alternative Authentik und der Keycloak-Alternative Authentik.

authhost: Managed Authentik auf deutscher Infrastruktur

Lizenz, Updates und revisionssichere Audit-Logs selbst zu stemmen, ist für KMU ohne eigenes SOC aufwendig, gerade unter dem Zeitdruck der NIS2-Umsetzung. authhost betreibt Ihre dedizierte Authentik-Instanz als Managed Service auf Infrastruktur in Deutschland und hält sie auf dem aktuellen Release-Stand. Identitäts- und Audit-Daten bleiben in EU-souveräner Umgebung, ein Auftragsverarbeitungsvertrag (AVV) ist inklusive, was die technischen und organisatorischen Maßnahmen nach DSGVO Art. 32 adressiert. Was in jeder Instanz steckt, zeigt die Funktionsübersicht; die Tarife starten ab 34,90 EUR pro Monat (Pläne und Preise).

Ehrlich bleibt: authhost ist nicht für jeden die richtige Wahl, und ein Managed-IAM ist kein NIS2-Zertifikat. Es deckt Zugriffskontrolle und MFA technisch ab und liefert die Audit-Grundlage, ersetzt aber nicht Ihr Compliance-Programm aus Registrierung, Meldewesen und Leitungspflichten. Wer ohnehin eigene Ops mit der nötigen Update-Disziplin hat, braucht dafür keinen Managed-Service. Die Testphase läuft sieben Tage und setzt eine Kreditkarte voraus.

→ Pläne und Preise ansehen | → Sieben Tage testen

Fazit

Sechs Monate nach Inkrafttreten des NIS2UmsuCG ist die Umsetzungslücke groß: Zur Frist am 6. März 2026 hatten laut BDO erst rund 38,5 Prozent der etwa 29.500 betroffenen Unternehmen die BSI-Registrierung erledigt. Für die zehn Mindestmaßnahmen aus § 30 Abs. 2 BSIG sind Zugriffskontrolle (Nr. 9) und Multi-Faktor-Authentifizierung (Nr. 10) die beiden Identity-Themen, die sich mit einem sauber konfigurierten Authentik technisch abbilden lassen, ergänzt um Audit-Trails, die auf DSGVO Art. 32 einzahlen.

Entscheidend ist die ehrliche Abgrenzung: Ein IAM ist ein solider, abgrenzbarer Baustein, kein vollständiges NIS2-Programm. Backup, Lieferkette, Schulungen, das Meldewesen nach § 32 und die Leitungspflichten bleiben eigene Aufgaben. Wer die beiden Identity-Maßnahmen ohne eigenen Lizenz- und Betriebsaufwand sauber umsetzen will, bekommt sie als Managed Authentik auf deutscher Infrastruktur, mit AVV und EU-souveräner Datenhaltung.

Jetzt Managed Authentik testen →

Quellen

1. BDO: Sechs Monate NIS-2-Umsetzungsgesetz, NIS-2 in Deutschland (Halbzeitbilanz, Registrierungsquote 38,5 %): bdo.de
2. OpenKRITIS: NIS2-Umsetzungsgesetz in Deutschland (Sektoren, Kategorien, §§ 28/30/32/65, Bußgelder): openkritis.de
3. § 30 BSIG (2025): Risikomanagementmaßnahmen, Nr. 1 bis 10: gesetze-im-internet.de
4. Artikel 21 NIS2-Richtlinie (EU) 2022/2555, Risikomanagementmaßnahmen Buchst. a bis j: buzer.de
5. NIS2-Richtlinie (EU) 2022/2555, EUR-Lex CELEX:32022L2555 (Originaltext): eur-lex.europa.eu
6. Artikel 32 DSGVO, Sicherheit der Verarbeitung (technische und organisatorische Maßnahmen): dsgvo-gesetz.de
7. BSI: NIS-2-Infopaket Multi-Faktor-Authentisierung und kontinuierliche Authentifizierung: bsi.bund.de
8. Authentik: Authenticator Validation Stage (MFA-Verfahren, Device-Classes, Throttling): docs.goauthentik.io
9. Authentik: About access control / RBAC (Rollen, Berechtigungen, Gruppen): docs.goauthentik.io
10. Authentik: Events / Audit-Logging (erfasste Felder, Aufbewahrung 365 Tage, Weiterleitung): docs.goauthentik.io
11. Authentik Release Notes 2026.5 (Throttling E-Mail/SMS-OTP, Account Lockdown, Conditional Access): docs.goauthentik.io
12. Authentik Blog: Version 2026.5 is here (Release-Datum 22. Mai 2026): goauthentik.io
13. Authentik Blog: Version 2025.12 (RBAC, Berechtigungen ausschließlich über Rollen): goauthentik.io