Nis2 Passwortanforderungen: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

NIS2 ist keine reine Passwortverordnung. Die Richtlinie verlangt ein belastbares Sicherheitsniveau für Netz- und Informationssysteme. Passwörter sind dabei nur ein Teil der Identitäts- und Zugriffssicherheit. Genau an dieser Stelle entstehen in der Praxis die meisten Fehlinterpretationen. Viele Organisationen suchen nach einer festen Mindestlänge, einer vorgeschriebenen Sonderzeichenquote oder einer starren Wechselpflicht. So einfach ist es nicht. NIS2 bewertet nicht nur, ob irgendwo eine Passwortregel existiert, sondern ob die Authentisierung im realen Betrieb Angriffe wirksam erschwert, Missbrauch erkennt und in ein funktionierendes Sicherheitsmanagement eingebettet ist.

Für betroffene Einrichtungen bedeutet das: Passwortanforderungen müssen risikobasiert definiert, technisch durchgesetzt, organisatorisch begleitet und regelmäßig überprüft werden. Ein PDF mit einer Passwortpolicy reicht nicht. Entscheidend ist, ob privilegierte Konten anders behandelt werden als Standardkonten, ob Fernzugriffe stärker abgesichert sind, ob kompromittierte Passwörter erkannt werden und ob Prozesse für Onboarding, Offboarding, Reset, Notfallzugriffe und Dienstkonten sauber geregelt sind.

Im Kern verlangt NIS2 Maßnahmen, die dem Stand der Technik entsprechen. Für Passwörter heißt das unter anderem: keine schwachen oder geleakten Kennwörter, keine Speicherung im Klartext, keine unsicheren Hashverfahren, Schutz gegen Online-Angriffe, Absicherung privilegierter Zugänge und sinnvolle Kombination mit Mehrfaktorverfahren. Wer sich an etablierten Vorgaben wie Nist Passwort Richtlinien oder Iso 27001 Passwortanforderungen orientiert, bewegt sich in der Regel deutlich näher an einer belastbaren Umsetzung als mit veralteten Komplexitätsdogmen.

Ein häufiger Denkfehler besteht darin, Passwortsicherheit isoliert zu betrachten. In realen Angriffen werden Passwörter nicht nur erraten. Sie werden aus Datenleaks übernommen, über Phishing abgegriffen, durch Passwort-Spraying getestet, über schwache Helpdesk-Prozesse zurückgesetzt oder aus schlecht geschützten Konfigurationsdateien extrahiert. Deshalb muss eine NIS2-konforme Passwortstrategie immer mit Zugriffskontrolle, Monitoring, Awareness, Logging und Incident Response zusammenspielen.

Besonders relevant ist die Frage nach der Angriffsoberfläche. Ein internes Fachverfahren mit wenigen Benutzern und ohne externen Zugriff hat ein anderes Risikoprofil als ein VPN-Gateway, ein O365-Tenant, ein Citrix-Portal oder ein Admin-Zugang zu Produktionssystemen. NIS2 verlangt keine Gleichbehandlung aller Konten, sondern angemessene Maßnahmen. Genau deshalb sind abgestufte Policies fachlich sauberer als eine einzige globale Regel für alle Identitäten.

Wer Passwortanforderungen unter NIS2 ernsthaft umsetzt, betrachtet mindestens folgende Ebenen:

• Qualität des Geheimnisses selbst: Länge, Sperrlisten, Wiederverwendung, Vorhersagbarkeit, Leaks
• Schutz des Authentisierungsvorgangs: MFA, Rate Limiting, Lockout-Strategien, sichere Übertragung, Logging
• Schutz der Speicherung und Verwaltung: Hashing, Salt, Secret Handling, Reset-Prozesse, Rollen- und Rechtekonzept

Damit wird klar: Die Frage lautet nicht nur, wie ein Passwort aussehen soll. Die eigentliche Frage lautet, wie Identitäten unter realen Angriffsbedingungen abgesichert werden. Genau dort trennt sich formale Compliance von belastbarer Sicherheit.

Eine belastbare Passwortpolicy entsteht nicht durch Copy-and-Paste aus alten Unternehmensrichtlinien. Sie muss aus dem Risiko abgeleitet werden. Das beginnt mit einer sauberen Kontenklassifizierung. Standardbenutzer, privilegierte Benutzer, technische Konten, Notfallkonten, externe Dienstleister und API-bezogene Secrets haben unterschiedliche Anforderungen. Wer alles mit derselben Regel behandelt, schafft entweder unnötige Reibung oder gefährliche Lücken.

Für Standardkonten ist heute eine längenorientierte Strategie mit Sperrlisten und MFA in vielen Umgebungen sinnvoller als starre Komplexitätsvorgaben. Die alte Logik aus Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen führt oft zu vorhersehbaren Mustern wie Sommer2024!, Firma123! oder Welcome!2025. Solche Passwörter sehen formal stark aus, sind aber praktisch schwach. Die technische Realität dahinter wird bei Passwort Laenge Oder Komplexitaet und Passwort Entropie Erklaert deutlich: Vorhersagbarkeit schlägt Zeichensatzvielfalt.

Für privilegierte Konten gelten strengere Maßstäbe. Admin-Zugänge zu Domain Controllern, Hypervisoren, Firewalls, Backup-Systemen, Cloud-Tenants oder OT-nahen Managementsystemen dürfen nicht nur auf ein starkes Passwort vertrauen. Hier sind MFA, getrennte Admin-Identitäten, eingeschränkte Nutzung, Protokollierung und idealerweise ein Privileged-Access-Management-Prozess Pflicht. Ein langes Passwort ohne zusätzliche Schutzmechanismen ist für solche Konten nicht ausreichend.

Technische Konten sind ein Sonderfall. Viele Unternehmen übersehen, dass Service-Accounts oft die schwächste Stelle im gesamten Authentisierungskonzept sind. Gründe dafür sind statische Kennwörter, fehlende Rotation, zu hohe Rechte, Klartextspeicherung in Skripten oder Konfigurationsdateien und fehlende Eigentümer. Unter NIS2 ist das besonders kritisch, weil kompromittierte Dienstkonten häufig lateral movement, Persistenz und unbemerkten Zugriff ermöglichen.

Eine saubere Ableitung der Anforderungen berücksichtigt mindestens vier Fragen: Welche Systeme werden geschützt, welche Auswirkungen hätte ein Missbrauch, wie wahrscheinlich ist ein Angriff und welche technischen Kontrollen existieren bereits? Ein extern erreichbares Login mit hoher Kritikalität und ohne MFA braucht deutlich strengere Maßnahmen als ein internes Low-Risk-System hinter mehreren Schutzschichten.

In der Praxis bewährt sich eine Policy-Matrix. Darin werden Kontotyp, Systemkritikalität, Exponierung, MFA-Pflicht, Passwortlänge, Sperrlisten, Reset-Verfahren, Monitoring und Rotationsregeln je Kategorie festgelegt. So entsteht keine theoretische Richtlinie, sondern ein umsetzbares Steuerungsinstrument. Diese Herangehensweise passt auch zu Passwort Richtlinien Unternehmen und Passwort Richtlinien Best Practice, weil sie technische Realität und Governance zusammenführt.

Ein weiterer Punkt ist die Benutzerfreundlichkeit. Schlechte Policies erzeugen Umgehungsverhalten. Wenn Passwörter zu oft geändert werden müssen, werden sie inkrementell angepasst. Wenn sie zu komplex sind, landen sie auf Zetteln, in Browsernotizen oder in unverschlüsselten Dateien. Wenn MFA nur für wenige Systeme gilt, weichen Angreifer auf schwächer geschützte Zugänge aus. Gute Passwortanforderungen reduzieren nicht nur Risiko, sondern auch Fehlverhalten.

Unter NIS2 ist deshalb nicht die strengste Regel automatisch die beste. Die beste Regel ist diejenige, die Angriffe realistisch erschwert, technisch sauber durchgesetzt wird und im Betrieb nicht systematisch umgangen wird.

In Audits und Pentests tauchen immer wieder dieselben Muster auf. Unternehmen haben eine Passwortpolicy, die auf dem Papier streng wirkt, aber reale Angriffe kaum stoppt. Das klassische Beispiel ist die erzwungene Komplexität bei gleichzeitig kurzer Mindestlänge. Ein Passwort wie P@ssw0rd! erfüllt viele Regeln und ist trotzdem trivial. Ebenso problematisch ist die starre 90-Tage-Wechselpflicht ohne Anlass. Sie erzeugt oft nur Passwortfolgen wie Winter2024!, Winter2025! oder Admin!01 zu Admin!02.

Diese Fehlannahmen halten sich hartnäckig, weil sie leicht messbar sind. Ein Auditor kann schnell prüfen, ob Sonderzeichen erzwungen werden oder ob ein Ablaufdatum gesetzt ist. Schwieriger ist die Bewertung, ob die Policy gegen reale Angriffsmethoden wirkt. Genau dort muss unter NIS2 der Fokus liegen. Angreifer arbeiten mit Passwortlisten, Leaks, Mustern, Wiederverwendung und Automatisierung. Wer nur formale Regeln prüft, bewertet die falsche Ebene.

Ein gutes Beispiel ist Credential Stuffing. Wenn Benutzer dasselbe Passwort mehrfach verwenden, hilft die beste interne Komplexitätsregel wenig. Ein bereits kompromittiertes Passwort wird einfach gegen andere Dienste getestet. Die eigentliche Gegenmaßnahme ist nicht nur eine stärkere Zeichenregel, sondern die Kombination aus Leak-Prüfung, MFA, Anomalieerkennung und Sensibilisierung gegen Wiederverwendung. Mehr dazu bei Was Ist Credential Stuffing und Passwort Wiederverwendung Risiko.

Ein weiterer Irrtum ist die Annahme, dass Account-Lockout allein ausreichend schützt. Zu aggressive Sperrmechanismen können selbst zum Problem werden, etwa wenn Angreifer gezielt Konten sperren und damit Helpdesk-Last oder Betriebsstörungen erzeugen. Zu schwache Sperrmechanismen wiederum lassen Password Spraying zu. Die richtige Balance hängt von Exponierung, Benutzerzahl, Kritikalität und vorhandenen Zusatzkontrollen ab.

Auch die Passwortlänge wird oft missverstanden. Länge ist stark, aber nicht isoliert. Ein langes, aber vorhersehbares Passwort aus Firmenname, Jahreszahl und Sonderzeichen ist kein gutes Geheimnis. Umgekehrt kann eine gut gewählte Passphrase deutlich robuster sein als ein kurzes komplexes Passwort. Die Unterschiede werden bei Passphrase Vs Passwort und Was Ist Ein Sicheres Passwort deutlich.

Besonders kritisch sind Policies, die nur den Benutzer in die Pflicht nehmen, aber technische Schwächen ignorieren. Wenn Passwörter mit SHA-256 ohne adaptive Kostenfaktoren gespeichert werden, ist die Policy praktisch unterlaufen. Wenn Login-Endpunkte keine Rate Limits haben, wird Online-Raten erleichtert. Wenn Reset-Links zu lange gültig sind oder Helpdesk-Prozesse schwach authentisieren, ist die Passwortstärke zweitrangig.

Die häufigsten Scheinsicherheiten in Unternehmen sind:

• kurze Mindestlängen mit erzwungenen Sonderzeichen statt längenorientierter Regeln
• regelmäßige Passwortwechsel ohne konkreten Sicherheitsanlass
• fehlende Sperrlisten für bekannte, geleakte oder unternehmensnahe Passwörter
• keine MFA-Pflicht für privilegierte oder extern erreichbare Zugänge
• starke Policy auf dem Papier, aber schwache Reset-, Helpdesk- oder Service-Account-Prozesse

Wer NIS2 ernst nimmt, ersetzt formale Scheinsicherheit durch messbare Wirksamkeit. Das bedeutet: reale Angriffspfade analysieren, Policies anpassen, technische Kontrollen ergänzen und Wirksamkeit regelmäßig testen. Genau das unterscheidet eine lebende Sicherheitsmaßnahme von einer bloßen Richtlinie.

Passwortanforderungen sind wertlos, wenn die technische Basis unsauber ist. In Pentests zeigt sich regelmäßig, dass Anwendungen zwar komplexe Passwörter verlangen, diese aber intern mit ungeeigneten Verfahren speichern oder Login-Endpunkte kaum absichern. Unter NIS2 ist das nicht vertretbar. Die sichere Behandlung von Passwörtern beginnt bei der Speicherung und endet nicht beim Eingabefeld.

Passwörter dürfen niemals reversibel gespeichert werden. Auch symmetrische Verschlüsselung ist für Passwortspeicherung das falsche Modell, weil Authentisierung keinen Klartextzugriff erfordert. Stattdessen werden adaptive Passwort-Hashverfahren eingesetzt. Geeignet sind heute vor allem Argon2id, bcrypt oder in bestimmten Umgebungen scrypt. Verfahren wie SHA-1 oder SHA-256 allein sind für Passwortspeicherung ungeeignet, weil sie zu schnell sind und Offline-Angriffe massiv begünstigen. Die Unterschiede sind bei Passwort Hashing Erklaert, Argon2 Erklaert und Sha256 Passwort Unsicher technisch gut nachvollziehbar.

Zu einem sauberen Hashing gehört immer ein individueller Salt pro Passwort. Dadurch werden gleiche Passwörter nicht zu gleichen Hashes und vorberechnete Tabellen verlieren ihren Wert. Ein zusätzlicher Pepper kann das Risiko bei Datenbankkompromittierung weiter senken, wenn er getrennt und sicher verwaltet wird. Entscheidend ist aber, dass Salt und Kostenfaktoren korrekt implementiert und regelmäßig überprüft werden. Viele Altanwendungen scheitern genau hier.

Ebenso wichtig ist die Prüfung gegen Sperrlisten. Ein Passwort kann formal lang und komplex sein und trotzdem bereits millionenfach in Leaks auftauchen. Solche Kennwörter müssen bei der Vergabe blockiert werden. Gute Sperrlisten enthalten nicht nur bekannte Leaks, sondern auch triviale Muster, Firmenbezug, Produktnamen, Saisonwörter und lokale Kontexte. Ein Unternehmen namens Nordwerk sollte Varianten wie Nordwerk2025!, Nordwerk#1 oder N0rdwerk! zuverlässig erkennen und ablehnen.

Der Login-Prozess selbst braucht Schutz gegen Online-Angriffe. Dazu gehören Rate Limiting, adaptive Verzögerungen, IP- und Verhaltensanalyse, Schutz gegen Enumeration, saubere Fehlermeldungen und nachvollziehbares Logging. Ein Login darf nicht verraten, ob Benutzername oder Passwort falsch war. Ebenso darf die Antwortzeit keine Rückschlüsse auf gültige Konten oder interne Prüfpfade zulassen. Solche Details sind in der Praxis relevant, weil sie Angreifern bei Automatisierung und Vorselektion helfen.

Ein technisch sauberer Authentisierungsstack umfasst typischerweise:

1. Passwortannahme mit Mindestlänge und Sperrlistenprüfung
2. sichere Übertragung ausschließlich über TLS
3. serverseitige Verarbeitung ohne Logging des Klartexts
4. Hashing mit Argon2id oder bcrypt und individuellem Salt
5. Rate Limiting und Monitoring am Login-Endpunkt
6. MFA-Prüfung abhängig von Risiko, Rolle und Zugriffspfad
7. revisionssichere Protokollierung sicherheitsrelevanter Ereignisse

In vielen Umgebungen liegt die Schwäche nicht in der Hauptanwendung, sondern in Nebenpfaden: Legacy-Portale, VPN-Appliances, Drucker-Webinterfaces, Backup-Konsolen, Hypervisor-Logins, lokale Admin-Konten oder Self-Service-Portale. Unter NIS2 muss die Passwortsicherheit systemübergreifend betrachtet werden. Ein einzelner schwacher Einstiegspunkt kann die gesamte Policy entwerten.

Besonders kritisch sind Offline-Szenarien. Wenn eine Passwortdatenbank kompromittiert wird, entscheidet die Qualität des Hashings darüber, ob aus einem Vorfall ein Massenkompromiss wird. Genau deshalb ist der Unterschied zwischen Online- und Offline-Angriffen so wichtig. Bei Online-Angriffen bremsen Rate Limits und MFA. Bei Offline-Angriffen zählt fast nur noch die Stärke des Passworts und die Qualität des Hashings. Mehr dazu bei Online Vs Offline Cracking.

Unter NIS2 ist die Diskussion über Passwortanforderungen ohne MFA unvollständig. Passwörter bleiben ein zentrales Element, aber sie dürfen nicht die einzige Barriere für kritische Zugänge sein. Besonders für privilegierte Konten, Remote Access, Cloud-Administrationszugänge, E-Mail-Postfächer mit Reset-Funktion und Systeme mit hoher Verfügbarkeit oder hohem Schadenspotenzial ist Mehrfaktor-Authentisierung faktisch Standard.

In der Praxis ist jedoch nicht jede MFA gleich stark. SMS-basierte Verfahren sind besser als gar kein zweiter Faktor, aber anfälliger als App-basierte TOTP-Verfahren oder hardwaregestützte FIDO2-Authentisierung. Für besonders kritische Umgebungen sollte phishing-resistente MFA bevorzugt werden. Das ist vor allem dann relevant, wenn Angreifer gezielt auf Administratoren, Helpdesk oder externe Dienstleister gehen.

Ein häufiger Fehler besteht darin, MFA nur für VPN oder einzelne Cloud-Dienste zu aktivieren, während interne Admin-Zugänge, Hypervisoren, Backup-Systeme oder Management-Interfaces ungeschützt bleiben. Angreifer nutzen genau solche Lücken. Wenn ein kompromittiertes Passwort intern ohne zweiten Faktor ausreicht, ist die Schutzwirkung der Gesamtarchitektur deutlich geringer als angenommen. Die Einordnung zwischen Faktoren und Verfahren wird bei Multi Factor Authentication Erklaert und 2fa Vs Mfa klar.

Privilegierte Konten brauchen mehr als nur MFA. Sie sollten getrennt von Alltagskonten geführt werden. Ein Benutzer darf nicht gleichzeitig E-Mails lesen, im Web surfen und Domain-Admin-Rechte mit derselben Identität verwenden. Solche Mischkonten erhöhen das Risiko durch Phishing, Token-Diebstahl und Session-Hijacking massiv. Saubere Trennung, Just-in-Time-Vergabe, Sitzungsprotokollierung und eingeschränkte Reichweite sind hier entscheidend.

Risikobasierte Zugriffskontrolle bedeutet außerdem, Kontextsignale zu nutzen. Ein Login aus einem bekannten Unternehmensnetz mit verwaltetem Gerät und normalem Zeitfenster ist anders zu bewerten als ein Zugriff aus einem neuen Land, über ein unbekanntes Gerät oder zu ungewöhnlicher Uhrzeit. Solche Signale ersetzen kein Passwort, aber sie helfen, zusätzliche Prüfungen auszulösen oder riskante Anmeldungen zu blockieren.

Auch Notfallkonten verdienen besondere Aufmerksamkeit. In vielen Unternehmen existieren Break-Glass-Accounts mit statischen Kennwörtern, die selten geprüft werden. Genau diese Konten sind in Krisensituationen wertvoll und deshalb hochkritisch. Sie brauchen starke, dokumentierte Schutzmaßnahmen, sichere Verwahrung, regelmäßige Tests und klare Freigabeprozesse. Ein Notfallkonto ohne Kontrolle ist kein Sicherheitsnetz, sondern ein versteckter Angriffsweg.

Ein belastbares Modell für NIS2-nahe Umgebungen sieht typischerweise so aus: Standardkonten mit langen Passwörtern und MFA für externe Zugriffe, privilegierte Konten immer mit MFA und separater Identität, technische Konten mit Secret-Management statt manueller Passwortpflege, Notfallkonten mit Sonderprozess und engmaschiger Kontrolle. Diese Differenzierung ist kein Luxus, sondern notwendige Risikosteuerung.

Die meisten Passwortprobleme entstehen nicht in der Richtlinie, sondern in heterogenen Umgebungen. Active Directory, Entra ID, VPN-Lösungen, Fachanwendungen, Linux-Systeme, Netzwerkgeräte und Legacy-Anwendungen folgen oft unterschiedlichen Regeln. Genau dadurch entstehen Inkonsistenzen, die Angreifer ausnutzen. Unter NIS2 muss die Passwortsicherheit über diese Grenzen hinweg konsistent gedacht werden.

Im Active Directory sind klassische Default-Policies oft nicht ausreichend. Eine globale Mindestlänge von acht Zeichen mit Komplexitätszwang und periodischem Ablauf ist technisch leicht aktivierbar, aber fachlich veraltet. Besser ist eine differenzierte Umsetzung über Fine-Grained Password Policies, getrennte Admin-Konten, Tiering, LAPS für lokale Administratorkonten, Schutz privilegierter Gruppen und ergänzende Kontrollen gegen Spraying und Kerberoasting-nahe Risiken. Wer sich tiefer mit der operativen Ebene beschäftigt, landet schnell bei Active Directory Passwort Policy.

In Microsoft-365- und Entra-ID-Umgebungen verschiebt sich der Fokus stärker auf Conditional Access, MFA, Risk-Based Sign-In Detection und Passwortschutz gegen bekannte schwache Kennwörter. Hier ist es besonders wichtig, dass Cloud- und On-Prem-Regeln nicht gegeneinander arbeiten. Wenn On-Prem schwache Passwörter zulässt, aber Cloud-seitig strengere Kontrollen gelten, entstehen Synchronisations- und Benutzerprobleme. Umgekehrt kann eine starke Cloud-Konfiguration durch schwache Legacy-Protokolle oder unsichere Hybridpfade unterlaufen werden.

VPN-Systeme sind ein klassisches Hochrisikoziel. Sie sind extern erreichbar, oft breit bekannt und für Angreifer ein direkter Einstieg in interne Netze. Ein VPN ohne MFA ist in NIS2-relevanten Umgebungen kaum vertretbar. Zusätzlich sollten Rate Limits, Geoblocking wo sinnvoll, Device Trust, Logging und Alarmierung auf ungewöhnliche Muster aktiv sein. Besonders problematisch sind Altgeräte oder Appliances mit eingeschränkten Policy-Möglichkeiten. Dort muss notfalls über vorgelagerte Schutzmechanismen kompensiert werden.

Legacy-Systeme sind oft der härteste Teil der Umsetzung. Manche Anwendungen unterstützen keine langen Passwörter, keine modernen Hashverfahren oder keine MFA. Solche Systeme dürfen nicht stillschweigend weiterlaufen, als wäre das akzeptabel. Es braucht dokumentierte Restrisiken, kompensierende Maßnahmen und einen klaren Migrationspfad. Kompensationen können Segmentierung, Jump Hosts, vorgeschaltete Authentisierung, Zugriff nur aus Admin-Netzen oder enges Monitoring sein. Dauerhafte Ausnahmezustände sind unter NIS2 schwer zu rechtfertigen.

Besondere Aufmerksamkeit verdienen lokale Konten auf Servern, Appliances und Clients. In vielen Umgebungen existieren identische oder schwach variierte lokale Admin-Passwörter. Das ist ein klassischer Hebel für laterale Bewegung. Lösungen wie LAPS oder vergleichbare Secret-Rotation-Mechanismen reduzieren dieses Risiko erheblich. Gleiches gilt für Standardpasswörter auf Netzwerkgeräten, Druckern, USV-Systemen oder OT-Komponenten.

Ein realistischer Härtungsansatz für gemischte Umgebungen umfasst:

• zentrale Policy-Steuerung, wo technisch möglich, und dokumentierte Ausnahmen mit Kompensation
• separate Regeln für Standard-, Admin-, Service- und Notfallkonten
• MFA für externe und privilegierte Zugänge ohne Ausnahmen aus Bequemlichkeit
• Abschaltung oder Isolierung von Legacy-Systemen mit unzureichender Passwortunterstützung
• regelmäßige technische Überprüfung statt Vertrauen in Konfigurationsdokumente

Gerade in hybriden Infrastrukturen zeigt sich, ob Passwortanforderungen wirklich gelebt werden. Eine gute Richtlinie ist nur dann belastbar, wenn sie in AD, Cloud, VPN, Fachanwendungen und Randgeräten konsistent umgesetzt und kontrolliert wird.

Viele Sicherheitsprogramme konzentrieren sich auf die Passworterstellung und übersehen die Prozesse rundherum. In realen Vorfällen sind jedoch Passwort-Reset, Helpdesk-Verifikation, Offboarding und Service-Accounts häufig die eigentlichen Schwachstellen. Ein Angreifer muss kein starkes Passwort knacken, wenn ein Helpdesk es nach einer schwachen Identitätsprüfung zurücksetzt.

Reset-Prozesse müssen deshalb wie sicherheitskritische Funktionen behandelt werden. Sicherheitsfragen mit öffentlich recherchierbaren Antworten sind ungeeignet. E-Mail-basierte Resets sind nur so stark wie das E-Mail-Konto selbst. SMS-Resets sind anfällig für Umleitungen und Social Engineering. Besser sind kurzlebige, einmalige Reset-Token, zusätzliche Verifikation bei erhöhtem Risiko und revisionssichere Protokollierung. Besonders bei privilegierten Konten sollte ein Reset nie ein einfacher Self-Service-Vorgang sein.

Helpdesk-Prozesse sind ein klassisches Ziel für Social Engineering. Angreifer sammeln Vorabinformationen aus sozialen Netzwerken, Datenleaks oder Firmenwebseiten und geben sich dann als Mitarbeiter aus. Wenn der Helpdesk nur nach Personalnummer, Geburtsdatum oder Abteilungsname fragt, ist die Hürde niedrig. Unter NIS2 muss die Identitätsprüfung im Support belastbar sein. Das kann über Rückrufverfahren, definierte Freigabeketten, Ticketbindung, bekannte Geräte oder zusätzliche organisatorische Kontrollen erfolgen.

Offboarding ist ein weiterer neuralgischer Punkt. Verlassene Konten, nicht deaktivierte Zugänge externer Dienstleister, vergessene API-Secrets oder weiterlaufende Service-Accounts sind in Audits regelmäßig zu finden. Solche Konten umgehen jede Passwortpolicy, weil sie organisatorisch aus dem Blick geraten. Ein sauberer Offboarding-Prozess muss Identitäten, Gruppenmitgliedschaften, Tokens, Sessions, VPN-Zugänge, lokale Konten und hinterlegte Secrets vollständig erfassen.

Service-Accounts sind besonders heikel, weil sie oft nicht interaktiv genutzt werden und deshalb selten Aufmerksamkeit bekommen. In der Praxis finden sich dort lange Laufzeiten, fehlende Rotation, übermäßige Rechte und Klartextkennwörter in Skripten, geplanten Tasks oder Deployment-Pipelines. Unter NIS2 ist das ein ernstes Problem, weil kompromittierte Service-Accounts oft unbemerkt bleiben und tief in kritische Prozesse eingebunden sind.

Ein robuster Workflow für Service-Accounts umfasst eindeutige Eigentümer, dokumentierten Zweck, minimale Rechte, Rotation, sichere Secret-Speicherung, Monitoring und regelmäßige Rezertifizierung. Wo möglich, sollten statische Passwörter durch Managed Identities, Kerberos, Zertifikate oder Vault-basierte Secret-Ausgabe ersetzt werden. Je weniger Menschen ein Service-Passwort kennen oder manuell handhaben, desto geringer die Angriffsfläche.

Auch Joiner-Mover-Leaver-Prozesse müssen mit Passwortsicherheit verzahnt sein. Rollenwechsel ohne Rechtebereinigung führen zu schleichender Privilegienakkumulation. Externe Dienstleister erhalten oft temporäre Zugänge, die nie wieder entzogen werden. Solche organisatorischen Defizite sind unter NIS2 nicht bloß Verwaltungsfehler, sondern konkrete Sicherheitsrisiken mit direkter technischer Wirkung.

Wer Passwortanforderungen nur am Login-Bildschirm misst, übersieht die eigentlichen Einfallstore. Saubere Workflows rund um Reset, Support, Lebenszyklus und technische Konten sind oft wichtiger als eine zusätzliche Sonderzeichenregel.

Unter NIS2 reicht es nicht, gute Absichten zu haben. Maßnahmen müssen nachweisbar sein. Für Passwortanforderungen bedeutet das, dass nicht nur Richtlinien dokumentiert, sondern auch technische Durchsetzung, Wirksamkeit und Ausnahmen belegt werden müssen. Genau hier scheitern viele Organisationen: Die Policy existiert, aber niemand kann zeigen, welche Systeme tatsächlich davon erfasst sind, wo Ausnahmen bestehen und ob die Kontrollen funktionieren.

Ein belastbares Audit betrachtet mehrere Ebenen gleichzeitig. Zuerst die Governance: Gibt es eine freigegebene Richtlinie, Rollen, Verantwortlichkeiten und definierte Ausnahmen? Danach die technische Umsetzung: Sind Mindestlängen, Sperrlisten, MFA, Hashing und Login-Schutz in den relevanten Systemen aktiv? Anschließend die Wirksamkeit: Werden schwache Passwörter erkannt, kompromittierte Kennwörter blockiert, verdächtige Login-Muster alarmiert und privilegierte Zugriffe nachvollziehbar protokolliert?

Messbarkeit entsteht durch konkrete Kennzahlen. Dazu gehören etwa der Anteil privilegierter Konten mit MFA, die Zahl der Konten ohne Eigentümer, die Anzahl von Service-Accounts ohne Rotation, die Quote blockierter schwacher Passwörter, die Abdeckung von Passwortschutz in kritischen Anwendungen oder die Zeit bis zur Deaktivierung beim Offboarding. Solche Kennzahlen sind deutlich aussagekräftiger als die bloße Existenz einer Richtlinie.

Technische Prüfungen sollten nicht nur Konfigurationen lesen, sondern reale Tests einschließen. Dazu gehören kontrollierte Passwort-Audits gegen Hashbestände, Prüfungen auf Standardkennwörter, Tests von Lockout- und Rate-Limit-Verhalten, Review von Reset-Prozessen und Simulationen von Helpdesk-Social-Engineering. Natürlich müssen solche Prüfungen sauber freigegeben und kontrolliert erfolgen. Der Punkt ist: Nur getestete Kontrollen sind belastbare Kontrollen.

Bei Passwort-Audits ist Vorsicht geboten. Ziel ist nicht, Benutzer bloßzustellen, sondern systemische Schwächen sichtbar zu machen. Wenn ein signifikanter Anteil von Hashes mit gängigen Listen oder regelbasierten Angriffen schnell aufgelöst werden kann, ist die Policy oder ihre Durchsetzung unzureichend. Solche Erkenntnisse sind besonders wertvoll, wenn sie mit Maßnahmen wie Sperrlisten, Awareness und MFA verknüpft werden. Wer tiefer in die operative Prüfung einsteigen will, findet bei Passwort Audit Durchfuehren und Passwort Schwachstellen Im Unternehmen die passenden Themenfelder.

Wichtig ist auch die Behandlung von Ausnahmen. Legacy-Systeme, externe Plattformen oder Spezialanwendungen werden oft von Standardregeln ausgenommen. Solche Ausnahmen müssen dokumentiert, genehmigt, befristet und mit kompensierenden Maßnahmen versehen sein. Eine Ausnahme ohne Eigentümer und ohne Review ist faktisch eine dauerhafte Schwachstelle.

Nachweisbarkeit bedeutet am Ende, dass eine Organisation auf Fragen wie diese belastbar antworten kann: Welche Passwortregeln gelten wo? Welche Konten sind besonders geschützt? Welche Systeme unterstützen keine modernen Anforderungen? Wie werden Leaks, Wiederverwendung und schwache Kennwörter erkannt? Wie schnell werden Risiken behoben? Wer diese Fragen nur mit Verweisen auf Richtliniendokumente beantwortet, ist operativ nicht ausreichend aufgestellt.

Eine gute Zielarchitektur ist weder maximal restriktiv noch unnötig kompliziert. Sie reduziert reale Risiken, ist technisch betreibbar und lässt sich auditierbar steuern. Für viele Unternehmen ergibt sich ein Muster, das sich in der Praxis bewährt: längenorientierte Passwortregeln, Sperrlisten gegen bekannte schwache und kompromittierte Kennwörter, MFA für externe und privilegierte Zugänge, adaptive Hashverfahren, saubere Reset-Prozesse, Secret-Management für technische Konten und regelmäßige Wirksamkeitsprüfungen.

Für Standardbenutzerkonten sind Mindestlängen im Bereich moderner Empfehlungen sinnvoll, kombiniert mit der Ablehnung geleakter und kontextbezogener Passwörter. Eine starre periodische Änderung sollte nicht pauschal erzwungen werden, sondern an Ereignisse geknüpft sein: Verdacht auf Kompromittierung, Datenleck, Rollenwechsel, unsicherer Speicherort oder technische Migration. Das reduziert Benutzerfrust und verhindert triviale Inkrementmuster.

Für privilegierte Konten sollte die Zielarchitektur deutlich strenger sein. Separate Admin-Identitäten, MFA ohne Ausnahme, eingeschränkte Nutzungswege, Protokollierung, Session-Kontrolle und möglichst keine direkte Internet-Exponierung sind hier Standard. Wo möglich, sollten privilegierte Zugriffe über Jump Hosts, Bastion-Systeme oder PAM-Lösungen geführt werden. Ein Admin-Passwort allein darf nie die letzte Verteidigungslinie sein.

Technische Konten gehören in ein zentrales Secret-Management. Statische Kennwörter in Skripten, CI/CD-Variablen ohne Schutz oder Konfigurationsdateien auf Fileshares sind nicht tragbar. Besser sind Vault-Lösungen, kurzlebige Secrets, automatische Rotation und klare Eigentümer. Für lokale Administratorkonten auf Endpunkten und Servern sind individuelle, rotierende Kennwörter Pflicht, nicht ein gemeinsames Team-Passwort.

Auch die Benutzerseite muss sauber unterstützt werden. Passwortmanager reduzieren Wiederverwendung und fördern lange, einzigartige Kennwörter. In vielen Umgebungen ist das deutlich wirksamer als immer neue Komplexitätsregeln. Ergänzend helfen Awareness-Maßnahmen gegen Phishing, Passwort-Sharing und unsichere Speicherung. Themen wie Passwort Manager Sicherheit, Security Awareness Passwoerter und Login Sicherheit Erhoehen greifen genau diese operative Ebene auf.

Eine pragmatische Zielarchitektur lässt sich in einem einfachen Sollbild zusammenfassen:

Standardkonten:
- lange Passwörter
- Sperrlisten gegen Leaks und triviale Muster
- MFA für externe Zugriffe
- Änderung bei Risikoereignissen statt starrer Frist

Privilegierte Konten:
- separate Identitäten
- MFA immer
- eingeschränkte Nutzungspfade
- enges Logging und Review

Service-Accounts:
- Secret-Management
- Rotation
- minimale Rechte
- dokumentierte Eigentümer

Legacy-Systeme:
- kompensierende Maßnahmen
- Segmentierung
- Migrationsplan
- dokumentierte Ausnahmen

Genau diese Kombination aus Technik, Prozess und Governance macht Passwortanforderungen unter NIS2 belastbar. Nicht die einzelne Regel entscheidet, sondern die Qualität des gesamten Workflows. Wer nur an der Mindestlänge dreht, aber Reset, Service-Accounts und MFA offenlässt, verbessert die Lage kaum. Wer dagegen die gesamte Identitätskette absichert, reduziert das Risiko spürbar und nachvollziehbar.