IAM & NIS2: Was müssen Unternehmen wirklich tun?

Identity and Access Management, kurz IAM, war lange vor allem ein Effizienz- und Compliance-Thema. Mit NIS2 ist es endgültig zur Frage der betrieblichen Resilienz geworden. Denn die europäische Richtlinie verlangt von betroffenen Unternehmen nicht bloß „mehr IT-Sicherheit“, sondern ein belastbares Risikomanagement für Netz- und Informationssysteme, klare Verantwortlichkeiten des Managements und wirksame Prozesse für Prävention, Erkennung, Reaktion und Wiederherstellung. Genau hier wird IAM zu einem zentralen Baustein. NIS2 gilt EU-weit für 18 kritische bzw. besonders wichtige Sektoren. In Deutschland ist das nationale Umsetzungsgesetz seit dem 6. Dezember 2025 in Kraft.

Warum IAM unter NIS2 so relevant ist

Viele Sicherheitsvorfälle beginnen nicht mit hochkomplexen Zero-Day-Exploits, sondern mit Identitäten: kompromittierte Benutzerkonten, zu weitreichende Berechtigungen, fehlende Mehrfaktorauthentifizierung, unkontrollierte Dienstkonten oder mangelhafte Offboarding-Prozesse. NIS2 fordert angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen. Dazu gehören unter anderem Risikoanalysen, Incident Handling, Business Continuity, Supply-Chain-Sicherheit, Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Systemen sowie Verfahren zur Bewertung der Wirksamkeit von Cybersecurity-Maßnahmen. Ein belastbares IAM stützt nahezu jeden dieser Punkte, weil es den Zugriff auf Systeme, Daten, Admin-Rechte und sensible Prozesse kontrollierbar macht.

Unternehmen sollten deshalb aufhören, IAM nur als Verzeichnisdienst oder Benutzerverwaltung zu betrachten. Unter NIS2 ist IAM ein Kontrollsystem für digitale Vertrauensbeziehungen. Es entscheidet darüber, wer worauf zugreifen darf, unter welchen Bedingungen, mit welcher Nachvollziehbarkeit und wie schnell riskante Zugriffe wieder entzogen werden können. Wer diesen Bereich vernachlässigt, schafft Angriffsflächen genau dort, wo NIS2 robuste Steuerung verlangt.

Der häufigste Denkfehler: NIS2 ist kein reines Dokumentationsprojekt

Viele Organisationen starten mit Richtlinien, Excel-Listen und einer Gap-Analyse. Das ist notwendig, aber nicht ausreichend. NIS2 verlangt keine bloße Papier-Compliance, sondern nachweisbare Wirksamkeit. Management-Gremien müssen die Cybersicherheitsmaßnahmen billigen, deren Umsetzung überwachen und können bei Pflichtverletzungen verantwortlich gemacht werden. Damit verlagert sich die Diskussion von „Haben wir eine Policy?“ zu „Funktioniert unser Sicherheitsmodell im Alltag tatsächlich?“

Für IAM bedeutet das konkret: Ein Unternehmen ist nicht deshalb gut aufgestellt, weil irgendwo ein Berechtigungskonzept existiert. Entscheidend ist, ob privilegierte Zugriffe wirklich begrenzt sind, ob Joiner-Mover-Leaver-Prozesse sauber laufen, ob verwaiste Accounts erkannt werden, ob Admin-Sitzungen kontrolliert werden und ob Berechtigungen regelmäßig rezertifiziert werden. NIS2 erhöht den Druck, diese Punkte operationalisierbar und prüfbar zu machen.

Was Unternehmen wirklich tun müssen

1. Betroffenheit und Kritikalität sauber bestimmen

Am Anfang steht nicht die Technologie, sondern die Einordnung. Unternehmen müssen prüfen, ob sie unter NIS2 als wesentliche oder wichtige Einrichtung fallen. Die Richtlinie erweitert den Anwendungsbereich deutlich und erfasst neben klassischen KRITIS-Bereichen unter anderem auch digitale Infrastrukturen, Anbieter öffentlicher elektronischer Kommunikationsdienste, Rechenzentrumsdienste, Post- und Kurierdienste, Abfallwirtschaft, bestimmte Hersteller kritischer Produkte, öffentliche Verwaltung und weitere Sektoren. Wer die eigene Betroffenheit falsch bewertet, steuert am Risiko vorbei.

Für die IAM-Praxis heißt das: Zunächst muss klar sein, welche Systeme, Anwendungen, Identitäten und Administrationsdomänen in den Geltungsbereich fallen. Ohne Scope-Definition bleibt jede Zugriffskontrolle Stückwerk.

2. Identitäten inventarisieren – vollständig, nicht selektiv

Der zweite Schritt ist ernüchternd, aber zwingend: Unternehmen brauchen Transparenz über alle Identitäten. Gemeint sind nicht nur Mitarbeiterkonten, sondern auch externe Dienstleister, Partnerzugänge, Maschinenidentitäten, Service Accounts, API-Schlüssel, lokale Administratorkonten und privilegierte technische Benutzer. Gerade diese technischen Identitäten entziehen sich in vielen Umgebungen der Governance und stellen deshalb ein überdurchschnittliches Risiko dar.

Wer NIS2 ernst nimmt, muss eine belastbare Identitätsinventur etablieren. Dazu gehören die Zuordnung zu Eigentümern, die Klassifizierung nach Kritikalität, die Dokumentation von Berechtigungsumfängen und die Frage, ob die Identität tatsächlich noch benötigt wird. Ohne diese Basis lassen sich weder Least Privilege noch Rezertifizierungen oder forensische Nachvollziehbarkeit sinnvoll umsetzen.

3. Starke Authentifizierung als Mindeststandard etablieren

NIS2 nennt ausdrücklich Multi-Faktor-Authentifizierung und sichere Kommunikationsmittel als geeignete Maßnahmen. MFA ist damit keine optionale „Best Practice“ mehr, sondern in vielen betroffenen Umgebungen faktisch Standard. Besonders relevant ist dies für privilegierte Konten, Remote-Zugriffe, Cloud-Administration, VPN-Zugänge, Administrationsportale und kritische Geschäftsanwendungen.

Unternehmen sollten MFA deshalb risikobasiert priorisieren. Zuerst müssen alle administrativen und extern erreichbaren Zugänge abgesichert werden. Danach folgen sensible interne Systeme, Identitätsprovider, E-Mail-Zugänge und zentrale Fachanwendungen. Wichtig ist, MFA nicht nur technisch zu aktivieren, sondern Ausnahmen hart zu steuern und regelmäßig zu überprüfen. Ein einziger ungeschützter Altzugang kann das gesamte Modell entwerten.

4. Privilegierte Rechte radikal neu ordnen

Privileged Access Management ist unter NIS2 kein Luxusprojekt, sondern Kern der Risikoreduktion. Admin-Rechte, Domänenkonten, Notfallzugänge, Root-Konten und hochprivilegierte Cloud-Rollen müssen gesondert behandelt werden. In vielen Unternehmen wurden diese Rechte historisch vergeben, selten dokumentiert und kaum rezertifiziert. Genau diese Struktur ist mit NIS2 schwer vereinbar.

Notwendig sind daher getrennte Admin-Identitäten, konsequente Vergabe nach Need-to-know und Least-Privilege-Prinzip, zeitlich begrenzte Rechte, Freigabeprozesse für Eskalationen, Passwort- bzw. Secret-Vaulting für technische Konten und eine manipulationssichere Protokollierung privilegierter Aktivitäten. Wer privilegierte Zugriffe nicht sauber unter Kontrolle hat, wird weder Audits noch Incident Response überzeugend bestehen.

5. Den Lebenszyklus von Berechtigungen automatisieren

NIS2 fordert organisatorische und technische Maßnahmen, die im Betrieb wirksam bleiben. Genau daran scheitern manuelle Berechtigungsprozesse. Wenn Benutzer bei Eintritt, Rollenwechsel oder Austritt verzögert angepasst werden, entstehen Überberechtigungen und Schattenzugriffe. Das betrifft besonders große, heterogene und international verteilte Organisationen.

Deshalb sollten Joiner-Mover-Leaver-Prozesse technisch unterstützt oder möglichst automatisiert werden. Neue Mitarbeiter erhalten nur rollenbasierte Startrechte. Rollenwechsel führen zu einer Neubewertung, nicht zu kumulierten Berechtigungen. Beim Offboarding werden Konten, Tokens, Zertifikate, VPN-Zugänge und administrative Rechte unmittelbar entzogen. Diese Prozessdisziplin ist keine reine HR-Schnittstelle, sondern eine sicherheitskritische Pflicht.

6. Rezertifizierungen und Segregation of Duties verbindlich machen

Viele Unternehmen wissen nicht, welche Fachbereiche welche Rechte tatsächlich freigeben. Noch weniger wissen sie, welche kritischen Kombinationen von Berechtigungen existieren. Unter NIS2 reicht diese Intransparenz nicht mehr aus. Unternehmen müssen nachvollziehbar zeigen können, dass Rechte fachlich begründet, regelmäßig überprüft und bei Bedarf korrigiert werden.

Regelmäßige Access Reviews sind deshalb Pflichtprogramm. Besonders wichtig sind Rezertifizierungen für privilegierte Konten, besonders sensible Fachanwendungen und externe Zugänge. Ergänzend sollten Unternehmen Konflikte im Sinne von Segregation of Duties identifizieren, etwa wenn dieselbe Person Bestellungen anlegen, freigeben und verbuchen kann oder gleichzeitig operative und kontrollierende Rechte besitzt. Solche Berechtigungskonflikte sind nicht nur Compliance-Risiken, sondern reale Missbrauchs- und Manipulationsvektoren.

7. IAM mit Monitoring und Incident Response verzahnen

NIS2 enthält konkrete Vorgaben zur Meldung erheblicher Sicherheitsvorfälle. Unternehmen müssen Frühwarnmechanismen, Meldewege und Reaktionsprozesse organisatorisch und technisch vorbereiten. In Deutschland stellt das BSI hierfür inzwischen auch ein Portal bereit; erhebliche Vorfälle müssen dort gemeldet werden.

Für IAM folgt daraus: Identitätsbezogene Ereignisse müssen in das Security Monitoring einfließen. Dazu gehören verdächtige Anmeldeversuche, unmögliche Reiseprofile, ungewöhnliche Nutzung privilegierter Konten, Massenänderungen an Rechten, Deaktivierung von MFA, verdächtige Token-Nutzung oder neu angelegte Schattenadministratoren. IAM darf also nicht isoliert betrieben werden, sondern muss eng mit SIEM, SOC, Incident Response und Forensik verbunden sein.

Was man jetzt verstehen muss

NIS2 macht Cybersicherheit zur Führungsaufgabe. Das ist keine rhetorische Floskel, sondern explizite Governance-Vorgabe. Management Bodies müssen Maßnahmen billigen, deren Umsetzung überwachen und Schulungen absolvieren. Für die Unternehmensleitung bedeutet das: IAM-Defizite sind nicht nur technische Schulden, sondern Governance-Risiken.

Deshalb sollte die Geschäftsleitung drei Fragen sofort beantworten können: Erstens, welche Identitäten haben Zugriff auf unsere kritischen Prozesse? Zweitens, wie kontrollieren wir privilegierte Rechte tatsächlich? Drittens, wie schnell können wir riskante Zugänge entziehen oder Missbrauch erkennen? Wer diese Fragen nicht belastbar beantworten kann, hat kein reifes NIS2-Programm.

Fazit: NIS2 verlangt keine Perfektion, aber belastbare Kontrolle

Unternehmen müssen für NIS2 nicht jedes IAM-Problem auf einen Schlag lösen. Sie müssen aber in kurzer Zeit von gewachsenen Einzelmaßnahmen zu einem gesteuerten, risikoorientierten und auditierbaren Zugriffsmodell kommen. Entscheidend sind klare Zuständigkeiten, vollständige Transparenz über Identitäten, starke Authentifizierung, konsequente Steuerung privilegierter Rechte, automatisierte Lifecycle-Prozesse, regelmäßige Rezertifizierungen und die Anbindung an Monitoring und Incident Response.

IAM ist damit nicht bloß ein Unterstützungsprozess für NIS2. Es ist einer der wirksamsten Hebel, um die Anforderungen der Richtlinie technisch und organisatorisch in den Betrieb zu übersetzen. Unternehmen, die jetzt nur Policies formulieren, werden später unter Realbedingungen scheitern. Unternehmen, die Identitäten, Rechte und Zugriffe systematisch kontrollieren, schaffen dagegen genau das, was NIS2 im Kern fordert: Resilienz.