[Werbung] NIS2 und Zugriffskontrolle

NIS2 ist seit über einem Jahr in deutsches Recht überführt. Das NIS2UmsuCG gilt seit dem 6. Dezember 2025 ohne Übergangsfrist, mit einem grundlegend neu gestalteten BSI-Gesetz (BSIG). Die Pflichten sind konkret: Lieferkettensicherheit, Meldung von Sicherheitsvorfällen, persönliche Haftung der Leitungsorgane. Das Problem ist selten fehlendes Bewusstsein – es ist fehlende Umsetzung.

22 von 27 EU-Mitgliedstaaten haben die NIS2-Transposition abgeschlossen. Neben Deutschland sind Frankreich und die Niederlande bereits in die aktive Durchsetzung übergegangen; Belgien registriert betroffene Einrichtungen für die behördliche Aufsicht, Italien bereitet Organisationen auf bevorstehende Überprüfungen vor.

Laut einer Umfrage von CyberSmart vom April 2026 unter 670 betroffenen Unternehmensverantwortlichen in acht europäischen Ländern halten sich 84 % der Organisationen, die bereits aktiver Durchsetzung unterliegen, nicht für vollständig NIS2-konform – ein Wert, der sich in den vorangegangenen sechs Monaten kaum verändert hat.

Die Frage ist also nicht mehr ob, sondern wo man anfängt: Die Zugangsverwaltung ist oft einer der ersten umsetzbaren Schritte – weil sie schnell umsetzbar ist und sofort prüfbare Nachweise erzeugt.

Das eigentliche Problem: Fehlende Nachweise, nicht fehlende Maßnahmen

Hier scheitern die meisten Organisationen bei Vor-Audits – nicht, weil Maßnahmen fehlen, sondern weil Nachweise fehlen.

§ 38 BSIG gibt den zuständigen Behörden das Recht, Dokumentationen der umgesetzten Sicherheitsmaßnahmen anzufordern. „Wir haben eine Passwortrichtlinie“ ist keine Dokumentation. Dokumentation ist der Richtlinientext, die technische Maßnahme, die ihn durchsetzt, und ein Protokoll, das belegt, dass die Maßnahme aktiv war und Ereignisse erzeugt hat.

Was nicht protokolliert und exportierbar ist, existiert aus Sicht eines Auditors nicht.

Eine Passwortrichtlinie mag existieren. MFA mag aktiviert sein. Zugriffsüberprüfungen mögen stattfinden. Ohne einen dokumentierten Nachweis – wann diese Kontrollen angewendet wurden, wer sie überprüft hat, was widerrufen wurde – wird der Compliance-Nachweis erheblich schwieriger. Für Credential- und Zugangsverwaltung erwarten Auditoren konkret:

• schriftliche, versionierte und von der Geschäftsführung genehmigte Zugangskontrollrichtlinie
• technische Durchsetzungsnachweise wie MFA-Enrollment-Berichte
• exportierbare Zugriffsüberprüfungsaufzeichnungen
• ein Inventar privilegierter Konten mit Verantwortlichkeitsdokumentation
• Credential-Rotationsprotokolle für Dienstkonten und API-Schlüssel
• Offboarding-Aufzeichnungen mit Abschlusszeitstempeln.

Manuelle Prozesse liefern selten prüfungssichere Nachweise. Das Ziel ist ein System, das diese automatisch erzeugt — und genau das bestimmt, welche drei Bereiche zuerst angegangen werden sollten.

Warum Zugangsdaten nach wie vor der entscheidende Engpass sind

Der Verizon Data Breach Investigations Report 2026 (DBIR) stellt fest, dass die Ausnutzung von Schwachstellen gestohlene Zugangsdaten als häufigsten einzelnen initialen Angriffsvektor überholt hat und für 31 % der Sicherheitsverletzungen verantwortlich ist. Daraus zu schließen, Credential-Kontrollen zu deprioritisieren, wäre ein Fehler.

Wenn man über den initialen Zugriffsvektor hinausblickt, taucht Credential-Missbrauch in der gesamten Angriffskette in 39 % aller Sicherheitsverletzungen auf. Verizon bezeichnet dies ausdrücklich als "legitimen Mitigations-Engpass“ (legitimate mitigation chokepoint). Zugangsdaten öffnen nicht nur die Eingangstür – sie sind das Werkzeug, mit dem Angreifer sich im System bewegen, sobald sie drin sind. Das macht Credential-Kontrollen zu einer der wenigen Maßnahmen, die gleichzeitig den initialen Zugriff erschweren und die laterale Bewegung im Netz begrenzen.

Drei Bereiche, in denen Nachweise typischerweise fehlen

Nicht verwaltete Dienstkonten und API-Schlüssel

Die meisten NIS2-Diskussionen zur Zugangsverwaltung konzentrieren sich auf menschliche Nutzer. Auditoren tun das zunehmend nicht mehr. Dienstkonten, API-Schlüssel, Datenbankverbindungsstrings und Deployment-Token sind nicht-menschliche Identitäten (Non-Human Identities, NHI) – und sie werden routinemäßig auf eine Weise verwaltet, die bei menschlichen Konten inakzeptabel wäre.

Eine typische mittelgroße Organisation hat mehr Dienstkonten als Mitarbeiterkonten. Die meisten teilen Passwörter, wurden nie rotiert und haben keinen dokumentierten Verantwortlichen. Diese Zugangsdaten liegen in .env-Dateien, CI/CD-Pipeline-Konfigurationen und gemeinsamen Laufwerken – genau dort, wo Angreifer nach dem initialen Zugriff suchen.

§ 30 Abs. 2 Nr. 9 BSIG verlangt, dass Zugangskontrollrichtlinien alle Konten mit Zugriff auf Netz- und Informationssysteme abdecken. „Alle Konten“ schließt Dienstkonten ein. In vielen Organisationen fallen sie jedoch außerhalb etablierter IAM-Prozesse: angelegt aus operativen Gründen, jahrelang aktiv, ohne dokumentierten Verantwortlichen. Das erzeugt eine Lücke zwischen formaler Richtlinie und tatsächlicher technischer Umgebung – genau die Art von Diskrepanz, die Auditoren suchen.

Auditoren werden fragen, wie nicht-menschliche Identitäten inventarisiert werden, wer für sie verantwortlich ist und wie Rotation durchgesetzt wird. Wenn ein Secret keinen dokumentierten Eigentümer in einem verwalteten System hat, existiert es für den Auditor nicht als kontrollierte Ressource.

Inaktive Konten und fehlerhafte Offboarding-Prozesse

Ein inaktives Konto (dormant account) existiert, verfügt über gültige Zugangsdaten und gehört jemandem, der keinen Zugriff mehr benötigt: einem ehemaligen Mitarbeiter, einem Auftragnehmer nach Projektende, einem Dienstleister, dessen Auftrag vor sechs Monaten abgeschlossen wurde. § 30 Abs. 2 Nr. 9 BSIG schreibt Lifecycle-Management als Bestandteil der Zugangskontrollrichtlinie vor – dormant accounts sind ein direkter Versagenspunkt.

Das Offboarding-Versagen ist fast nie böswillig – es ist ein Prozessfehler. HR schließt das Ticket, IT deaktiviert das Active-Directory-Konto, und niemand prüft, ob die Person auch direkten Datenbankzugriff, ein VPN-Zertifikat, einen AWS-IAM-Benutzer oder SSH-Schlüssel auf drei Produktionsservern hatte. Jedes davon ist ein separates Credential, das widerrufen werden muss. In den meisten Organisationen gibt es kein einziges System, das alle erfasst.

Auditoren suchen nach systemischen Schwachstellen, nicht nach einzelnen Fehlern. Ein wiederkehrendes Muster ist die Unfähigkeit nachzuweisen, dass alle zugehörigen Zugangsdaten widerrufen wurden, nachdem jemand die Organisation verlassen hat – besonders in Umgebungen, in denen Zugriffsrechte über Active Directory, Cloud-Plattformen, VPN-Systeme und intern verwaltete Anwendungen verteilt sind. Ein Offboarding-Prozess, der nur in E-Mail-Verläufen nachvollziehbar ist, ist aus Sicht des Auditors kein Prozess.

Lücken bei phishing-resistenter Multi-Faktor-Authentifizierung

§ 30 Abs. 2 Nr. 10 BSIG schreibt MFA oder kontinuierliche Authentifizierung vor. Die Orientierungshilfen des BSI machen deutlich, dass dies jeden privilegierten Zugriff und jeden Fernzugriff auf kritische Systeme umfasst. SMS-OTP reicht für diese Kontexte nicht mehr aus: NIST SP 800-63B (Abschnitt 5.2.10) klassifiziert es ausdrücklich als eingeschränkten Authentikator (restricted authenticator) und verweist auf SIM-Swapping- und SS7-Abfangrisiken. Phishing-resistente MFA – FIDO2/WebAuthn, Hardware-Sicherheitsschlüssel oder zertifikatsbasierte Authentifizierung – ist der Standard, der einer Prüfung standhält.

Die MFA-Abdeckung ist selten vollständig. Auditoren konzentrieren sich zunehmend auf Ausnahmen: privilegierte Administratoren, Legacy-Anwendungen oder gemeinsam genutzte Betriebskonten, die stärkere Authentifizierungskontrollen umgehen. Diese Ausnahmen erfordern sowohl kompensierende Kontrollen als auch eine dokumentierte Begründung – ohne beides existieren sie für den Auditor als unkontrolliertes Risiko.

Eine zentrale Kontrollinstanz

Alle drei Bereiche haben einen gemeinsamen Nenner: das Fehlen eines Systems, das Zugangsdaten erfasst, Zugriffsrichtlinien durchsetzt und exportierbare Nachweise erzeugt. Eine zentrale Passwort- und Secrets-Management-Plattform konsolidiert diese Kontrollen – Credential-Speicherung mit Verantwortlichkeitsdokumentation pro Secret, RBAC mit AD/LDAP-Integration für Lifecycle-Management, phishing-resistente MFA auf den Vault-Zugriff und ein Audit-Log, das jede Aktion mit Zeitstempel erfasst. Die quartalsweise Zugriffsüberprüfung wird zum Berichtsexport, nicht zur manuellen Übung.

Passwork ist ein Beispiel für eine Lösung, die diesen Ansatz durch selbst gehostetes Deployment, RBAC, AD/LDAP-Integration, WebAuthn-Unterstützung und exportierbare Audit-Logs umsetzt.

Passwork ist ein selbst gehosteter Passwort- und Secrets-Manager für Unternehmensumgebungen – mit AES-256-Verschlüsselung, RBAC, AD/LDAP-Integration und exportierbaren Audit-Logs. Erfahren Sie, wie er auf die Anforderungen des § 30 BSIG einzahlt: passwork.pro/nis2

Wo anfangen

Ein Auditor fragt nicht, ob Sicherheitsmaßnahmen existieren. Er fragt, ob sie nachweisbar sind. IBMs Cost of a Data Breach Report 2025 zeigt: Organisationen, die Vorfälle schneller eindämmen, zahlen im Schnitt deutlich weniger als die globalen Durchschnittskosten von 4,44 Millionen US-Dollar – und sie wissen durchgängig, wo ihre Zugangsdaten liegen und wer darauf Zugriff hat.

Die schwierigeren NIS2-Anforderungen – Lieferkettensicherheit, Incident Response, Governance auf Leitungsebene – brauchen Zeit. Credential-Management nicht. Es ist der Bereich, in dem sich technische Kontrollen, operative Prozesse und prüfbare Nachweise in wenigen Wochen aufbauen lassen:

• Dienstkonten inventarisieren und unter Verwaltung bringen
• Den Rückstand inaktiver Konten abbauen
• Phishing-resistente MFA für privilegierten und Remote-Zugriff durchsetzen
• Logging-Infrastruktur aufbauen, die diese Maßnahmen in exportierbare Nachweise verwandelt

Diese Arbeit schließt den Credential-Engpass, der in 39 % aller Sicherheitsverletzungen über die gesamte Angriffskette hinweg auftritt.

Passwork ist ein selbst gehosteter Passwort- und Secrets-Manager für Unternehmensumgebungen – AES-256-Verschlüsselung, RBAC, AD/LDAP-Integration und exportierbare Audit-Logs inklusive. Erfahren Sie, wie er auf die Anforderungen des § 30 BSIG einzahlt: passwork.pro/nis2

Dieser Beitrag ist eine Werbeanzeige und stammt von einem Content-Partner. Die Anzeige wurde nicht vom heise Software-Team oder einer anderen heise-Redaktion verfasst oder nachbearbeitet und spiegelt möglicherweise nicht deren Meinung wider.

Aufmachergrafik enthält KI-generierte Elemente von Google Gemini.