Passwort Sicherheit Kritis: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

In kritischen Infrastrukturen ist ein Passwort kein isoliertes Benutzermerkmal, sondern ein möglicher Einstiegspunkt in Prozesse mit realen Auswirkungen auf Versorgung, Gesundheit, Produktion, Logistik oder öffentliche Sicherheit. Der Unterschied zu gewöhnlichen IT-Umgebungen liegt nicht nur in strengeren regulatorischen Anforderungen, sondern vor allem in der Schadensdimension. Ein kompromittiertes Administratorkonto in einer Office-Umgebung verursacht Aufwand. Ein kompromittiertes Konto in einer Leitwarte, in einem Krankenhausnetz oder in einer Energieumgebung kann Betriebsunterbrechungen, Manipulation von Steuerprozessen oder den Ausfall sicherheitsrelevanter Systeme nach sich ziehen.

Genau deshalb reicht es nicht, Passwortsicherheit auf Mindestlänge und Sonderzeichen zu reduzieren. In KRITIS zählt der gesamte Authentifizierungsprozess: Wie werden Passwörter erzeugt, verteilt, gespeichert, geprüft, rotiert, überwacht und im Incident behandelt? Ebenso entscheidend ist die Frage, welche Konten überhaupt passwortbasiert arbeiten dürfen und an welchen Stellen passwortlose oder mehrstufige Verfahren vorzuziehen sind. Wer nur auf Komplexitätsregeln schaut, übersieht die eigentlichen Angriffsflächen.

Typische Schwachstellen entstehen an Übergängen: zwischen Office-IT und OT, zwischen Dienstleistern und internen Teams, zwischen Altanlagen und modernen IAM-Prozessen, zwischen Notfallzugängen und regulären Betriebsaccounts. Gerade in KRITIS existieren häufig Legacy-Systeme, fest verdrahtete Servicekonten, gemeinsam genutzte Wartungszugänge und lange Lebenszyklen von Anwendungen. Dadurch entstehen Sonderfälle, die in Standardrichtlinien nicht sauber abgebildet werden.

Ein belastbares Verständnis beginnt mit einer nüchternen Einordnung: Passwörter sind nur ein Faktor in einer Verteidigungskette. Sie müssen gegen Online-Angriffe, Offline-Cracking, Wiederverwendung, Phishing, Insider-Missbrauch und Fehlkonfigurationen bestehen. Grundlagen zu Aufbau und Qualität sicherer Kennwörter finden sich unter Passwort Sicherheit Grundlagen und zur Einordnung technischer Mindestanforderungen unter Was Ist Ein Sicheres Passwort. In KRITIS reicht diese Basis jedoch nur dann aus, wenn sie in Betriebsprozesse übersetzt wird.

Die zentrale Frage lautet daher nicht: Ist ein Passwort stark? Die relevante Frage lautet: Ist der gesamte Umgang mit Identitäten unter Störungs-, Angriffs- und Notfallbedingungen robust genug? Genau an dieser Stelle trennt sich formale Compliance von echter Resilienz.

In der Praxis werden Passwörter in KRITIS selten durch reines Raten kompromittiert. Erfolgreiche Angriffe kombinieren meist mehrere Techniken: Informationsgewinnung, Passwort-Wiederverwendung, Phishing, Missbrauch schwacher Servicekonten, Auswertung alter Leaks und laterale Bewegung nach dem ersten Zugriff. Wer Passwortsicherheit ernsthaft bewerten will, muss diese Angriffsketten verstehen.

Ein häufiger Einstiegspunkt ist Credential Stuffing. Dabei werden bekannte Kombinationen aus Benutzername und Passwort aus früheren Datenlecks automatisiert gegen Portale, VPNs, OWA, Citrix, Fernwartungszugänge oder Cloud-Dienste getestet. Besonders gefährlich ist das in Organisationen, in denen Mitarbeitende private und berufliche Passwörter vermischen oder Dienstleister identische Kennwörter über mehrere Kundenumgebungen hinweg nutzen. Die Mechanik dahinter wird unter Was Ist Credential Stuffing und Passwort Wiederverwendung Risiko detailliert eingeordnet.

Daneben bleibt Phishing einer der effektivsten Wege. In KRITIS-Umgebungen sind Angriffe oft zielgerichtet: gefälschte Wartungsanfragen, angebliche Störungsmeldungen, Lieferantenkommunikation oder interne Eskalationen. Das Ziel ist nicht nur das Passwort selbst, sondern oft auch die Session, der zweite Faktor oder ein Helpdesk-Reset. Technisch starke Passwörter helfen hier nur begrenzt, wenn Prozesse zur Verifikation von Identitäten schwach sind.

Offline-Angriffe spielen ebenfalls eine große Rolle. Sobald ein Angreifer Hashes aus einem kompromittierten System, Backup, Domain Controller oder einer Anwendungsdatenbank extrahiert, beginnt ein anderes Spiel. Dann zählt nicht mehr die Login-Rate-Limitierung, sondern die Widerstandsfähigkeit des Hash-Verfahrens, die Passwortqualität und die eingesetzte Hardware. Wer noch auf schnelle Hashes oder veraltete Verfahren setzt, verliert diesen Kampf. Relevante technische Hintergründe finden sich unter Passwort Hashing Erklaert, Argon2 Erklaert und Sha256 Passwort Unsicher.

• Online-Angriffe zielen auf Login-Oberflächen, VPNs, Webportale, Fernwartung und Cloud-Zugänge.
• Offline-Angriffe zielen auf Hashes aus Datenbanken, Backups, Speicherabbildern oder kompromittierten Hosts.
• Prozessangriffe zielen auf Helpdesk, Passwort-Reset, Notfallkonten, Dienstleisterzugänge und Freigabeworkflows.

Ein realistisches Bedrohungsmodell für KRITIS muss außerdem Insider-Risiken berücksichtigen. Gemeinsame Konten, unklare Verantwortlichkeiten, fehlende Vier-Augen-Prinzipien und schlecht dokumentierte Notfallzugänge schaffen ideale Bedingungen für Missbrauch, der im Nachhinein kaum sauber zugeordnet werden kann. Passwortsicherheit ist deshalb immer auch ein Thema von Nachvollziehbarkeit und Governance.

Die meisten Passwortprobleme in kritischen Infrastrukturen entstehen nicht aus Unwissen, sondern aus Zielkonflikten. Verfügbarkeit, Schichtbetrieb, externe Wartung, Altanwendungen und Zeitdruck führen dazu, dass unsaubere Lösungen toleriert werden. Genau diese Toleranz wird später zum Einfallstor.

Ein klassischer Fehler ist die Existenz gemeinsam genutzter Konten. Solche Konten werden oft mit Betriebsnotwendigkeit begründet: Schichtwechsel, Leitstand, Bereitschaft, Herstellerwartung oder Notfallbetrieb. Das Problem ist nicht nur die fehlende individuelle Zuordnung. Gemeinsame Konten werden seltener geändert, häufiger informell weitergegeben und fast nie sauber aus einem zentralen Lifecycle entfernt. Sobald ein externer Techniker, ein ehemaliger Mitarbeiter oder ein kompromittiertes Endgerät Zugriff hatte, bleibt die Unsicherheit bestehen.

Ebenso kritisch sind statische Servicekonten mit jahrelang unveränderten Passwörtern. In vielen Umgebungen laufen Dienste, geplante Tasks, Middleware, Datenbankverbindungen oder OT-nahe Integrationen mit fest hinterlegten Kennwörtern. Änderungen werden vermieden, weil Abhängigkeiten unklar sind oder Ausfälle befürchtet werden. Genau diese Konten sind für Angreifer attraktiv, weil sie oft hohe Berechtigungen besitzen, kaum überwacht werden und in Dokumentationen, Skripten oder Konfigurationsdateien auftauchen.

Ein weiterer Dauerfehler ist die Überschätzung von Komplexitätsregeln. Ein Passwort wie Kesselhaus!2024 erfüllt viele formale Anforderungen und ist dennoch schwach, weil es organisationsnah, vorhersagbar und in Wortlisten leicht modellierbar ist. Dasselbe gilt für saisonale Muster, Standortnamen, Abteilungsbezüge und inkrementelle Änderungen wie Winter2024!, Winter2025! oder Admin!Q1. Solche Muster werden in Passwortlisten und Regelwerken moderner Cracking-Tools gezielt abgebildet. Beispiele für schlechte Muster finden sich unter Schwaches Passwort Beispiele.

Auch Passwortrotation wird häufig falsch umgesetzt. Wenn Richtlinien starre Wechselintervalle erzwingen, ohne Missbrauchslage und Kontotyp zu berücksichtigen, entstehen vorhersehbare Änderungen und Notizzettel unter Tastaturen. In sensiblen Bereichen kann Rotation sinnvoll sein, aber nur dann, wenn sie risikobasiert, technisch unterstützt und mit Erkennung kompromittierter Zugangsdaten kombiniert wird. Pauschale Wechselpflicht ohne Kontext produziert oft nur schlechtere Passwörter und mehr Supportaufwand.

Ein besonders unterschätzter Fehler ist die Vermischung von administrativen und alltäglichen Identitäten. Wer mit demselben Benutzerkontext E-Mails liest, im Internet recherchiert und gleichzeitig privilegierte Systeme verwaltet, erhöht die Angriffsfläche massiv. In KRITIS müssen privilegierte Konten getrennt, zweckgebunden und eng überwacht sein. Das betrifft besonders Passwort Fuer Admin Accounts sowie technische Konten mit erweiterten Rechten.

Ein starkes Passwort in KRITIS ist nicht einfach nur lang oder komplex. Es muss gegen reale Angriffsmodelle bestehen. Das bedeutet: ausreichend Länge, keine semantische Nähe zur Organisation, keine Wiederverwendung, keine bekannten Leaks, keine vorhersehbaren Transformationsmuster und eine saubere Trennung nach Kontotyp. Ein Passwort für ein internes Wiki ist anders zu bewerten als ein Passwort für einen Domänenadministrator, einen VPN-Zugang oder einen Break-Glass-Account.

Die Praxis zeigt, dass Länge meist mehr Sicherheitsgewinn bringt als künstliche Komplexität. Ein langes, zufällig erzeugtes Passwort oder eine robuste Passphrase mit hoher Unvorhersagbarkeit ist in der Regel widerstandsfähiger als ein kurzes Kennwort mit erzwungenen Sonderzeichen. Die technische Begründung liegt in der Suchraumgröße und in der Frage, wie gut sich menschliche Muster modellieren lassen. Vertiefungen dazu finden sich unter Passwort Laenge Oder Komplexitaet, Passwort Entropie Erklaert und Passphrase Vs Passwort.

Entscheidend ist jedoch der Kontext. Für privilegierte Konten sollten zufällig generierte, sehr lange Kennwörter Standard sein, idealerweise verwaltet über zentrale Systeme mit kontrollierter Ausgabe. Für Benutzerkonten mit menschlicher Eingabe kann eine starke Passphrase sinnvoll sein, sofern sie nicht aus naheliegenden Begriffen, Zitaten oder organisationsbezogenen Wörtern besteht. Für Servicekonten ist manuelle Merkbarkeit kein Ziel; dort zählt ausschließlich technische Robustheit und kontrollierte Verwaltung.

Ein häufiger Denkfehler besteht darin, Passwortstärke rein mathematisch zu betrachten. Entropie ist nützlich, aber nur dann, wenn die Annahmen zur Zufälligkeit stimmen. Ein Passwort wie Berlin!Leitwarte!2025 wirkt lang, ist aber für regelbasierte Angriffe deutlich leichter zu treffen als eine echte Zufallsfolge. Moderne Angreifer arbeiten nicht blind, sondern mit Wortlisten, Mutationsregeln, Kontextwissen und Leaks. Deshalb müssen Passwortprüfungen immer auch verbotene Muster, bekannte Breach-Daten und organisationsspezifische Begriffe einbeziehen.

• Benutzerkonten: lange, einzigartige Passphrasen oder zufällige Kennwörter, keine Wiederverwendung, keine Organisationsbezüge.
• Privilegierte Konten: sehr lange, zufällige Kennwörter, getrennte Identitäten, MFA, kontrollierte Ausgabe und Protokollierung.
• Service- und Maschinenkonten: nicht merkbar, zentral verwaltet, dokumentierte Abhängigkeiten, definierte Rotationsprozesse.

Wer Passwortqualität messen will, sollte nicht nur auf einen simplen Score vertrauen. Ein technischer Blick auf Prüfverfahren, lokale Bewertung und Grenzen automatischer Einschätzungen ist unter Passwort Checker Wie Funktioniert Das und Passwort Checker Limitierungen sinnvoll. In KRITIS muss die Bewertung immer mit organisatorischem Kontext kombiniert werden.

Die Qualität eines Passworts ist nur die halbe Miete. Sobald Zugangsdaten serverseitig unsauber verarbeitet oder gespeichert werden, kippt das gesamte Sicherheitsmodell. In KRITIS ist das besonders kritisch, weil Anwendungen oft lange betrieben, selten modernisiert und über Jahre mit gewachsenen Altkomponenten erweitert werden. Genau dort finden sich noch immer schwache Hash-Verfahren, fehlende Salts, proprietäre Konstruktionen oder sogar reversible Speicherung.

Passwörter dürfen niemals im Klartext gespeichert werden. Ebenso unzureichend ist die Verwendung schneller Hashfunktionen wie SHA-1 oder SHA-256 ohne adaptive Kostenparameter. Solche Verfahren sind für Integrität nützlich, aber nicht für Passwortspeicherung. Der Grund ist einfach: Angreifer können Milliarden Kandidaten pro Sekunde testen, insbesondere mit GPU-beschleunigten Setups. Sobald Hashes exfiltriert wurden, entscheidet die Rechenökonomie des Angreifers über die Erfolgschance. Genau deshalb sind adaptive Verfahren wie Argon2id oder bcrypt Stand der Technik. Hintergrundwissen dazu liefern Bcrypt Erklaert und Salting Passwoerter.

Ein Salt sorgt dafür, dass identische Passwörter nicht zu identischen Hashes führen und vorberechnete Tabellen an Wert verlieren. Ein Pepper ergänzt dieses Modell, indem ein zusätzlicher geheimer Wert außerhalb der Datenbank gehalten wird. Das erhöht den Aufwand für Angreifer, ersetzt aber keine saubere Hashfunktion. Kritisch ist, dass Salt und Pepper korrekt implementiert und betrieblich beherrscht werden. Ein Pepper in derselben Konfigurationsdatei wie die Datenbank-Credentials bringt kaum Mehrwert.

In Audits tauchen immer wieder dieselben Schwächen auf: Legacy-Webanwendungen mit MD5, interne Tools mit selbstgebauten Hashroutinen, Exportfunktionen mit Klartextpasswörtern, Passwort-Reset-Mechanismen mit unsicheren Tokens oder Logdateien, in denen Zugangsdaten versehentlich landen. Solche Befunde sind in KRITIS nicht nur technische Mängel, sondern potenzielle Melde- und Haftungsthemen.

Ein Minimalstandard für moderne Passwortspeicherung umfasst adaptive Hashes, individuelle Salts, sichere Parameterwahl, Schutz vor Timing-Leaks, saubere Reset-Prozesse und eine Migrationsstrategie für Altbestände. Wenn eine Anwendung noch alte Hashes enthält, muss beim nächsten erfolgreichen Login eine transparente Rehash-Logik greifen. Ein typischer Ablauf sieht so aus:

1. Benutzer meldet sich mit Passwort an
2. System erkennt altes Hashformat
3. Passwort wird gegen alten Hash verifiziert
4. Bei Erfolg wird sofort ein neuer Hash mit aktuellem Verfahren erzeugt
5. Alter Hash wird ersetzt und Versionierung aktualisiert
6. Ereignis wird revisionssicher protokolliert

Gerade in KRITIS darf eine Passwortdatenbank nie isoliert betrachtet werden. Backups, Replikate, Testsysteme, Entwicklerkopien und Migrationsarchive sind oft die eigentliche Schwachstelle. Wer nur die Produktionsdatenbank absichert, aber alte Dumps unverschlüsselt auf Fileshares liegen lässt, hat das Problem nicht gelöst.

Die kritischsten Passwortobjekte in KRITIS sind nicht die normalen Benutzerkonten, sondern privilegierte Identitäten, technische Konten und Notfallzugänge. Genau hier entstehen die größten Schäden, wenn Kontrolle, Rotation und Nachvollziehbarkeit fehlen. Ein Domänenadmin, ein Hypervisor-Root, ein Firewall-Admin, ein Datenbank-Superuser oder ein Herstellerkonto für Fernwartung haben eine völlig andere Risikoklasse als ein Standardbenutzer.

Privilegierte Konten müssen grundsätzlich von Alltagskonten getrennt werden. Keine E-Mail, kein Webzugriff, keine Office-Nutzung im selben Sicherheitskontext. Idealerweise existieren dedizierte Admin-Workstations, segmentierte Zugangswege und eine starke Bindung an MFA. Zusätzlich müssen Kennwörter solcher Konten lang, zufällig und zentral verwaltet sein. Manuelle Kenntnis sollte auf das notwendige Minimum reduziert werden.

Servicekonten sind schwieriger, weil sie oft tief in Prozesse eingebettet sind. Viele Ausfälle nach Passwortänderungen entstehen nicht durch die Änderung selbst, sondern durch fehlende Transparenz über Abhängigkeiten. Vor jeder Rotation muss klar sein, welche Dienste, Skripte, Tasks, APIs, Datenbankverbindungen und Drittprodukte betroffen sind. Ohne diese Sicht wird aus einer Sicherheitsmaßnahme schnell ein Betriebsproblem. Deshalb gehören Servicekonten in ein Inventar mit Eigentümer, Zweck, Berechtigungen, Abhängigkeiten, letzter Rotation und Notfallverfahren.

Break-Glass-Konten verdienen besondere Aufmerksamkeit. Sie sind für den Ausnahmefall gedacht, etwa bei Ausfall des IAM, Verlust regulärer Admin-Zugänge oder Störungen in der MFA-Infrastruktur. Genau deshalb werden sie oft zu selten geprüft. Ein Notfallkonto, dessen Passwort in einem veralteten Tresor liegt, dessen Gültigkeit unbekannt ist oder dessen Nutzung nicht alarmiert wird, ist kein Sicherheitsnetz, sondern ein blinder Fleck.

Ein belastbarer Workflow für solche Konten umfasst technische und organisatorische Kontrollen:

• Jedes privilegierte Konto besitzt einen klaren Eigentümer, dokumentierten Zweck und definierte Freigabewege.
• Jede Nutzung von Break-Glass-Zugängen erzeugt sofortige Alarmierung, Protokollierung und nachgelagerte forensische Prüfung.
• Servicekonten werden inventarisiert, regelmäßig überprüft und nur mit minimal notwendigen Rechten betrieben.

Wo möglich, sollten privilegierte Kennwörter über spezialisierte Systeme für Passwortverwaltung und Zugriffskontrolle ausgegeben werden. Ergänzend sind Themen wie Identity Access Management Passwort, Single Sign On Sicherheit und Passwort Management Tools Unternehmen relevant. In KRITIS ist jedoch entscheidend, dass Komfort nie über Nachvollziehbarkeit und Segmentierung gestellt wird.

Richtlinien sind in KRITIS nur dann wirksam, wenn sie technisch umsetzbar, auditierbar und mit dem Betrieb vereinbar sind. Papierregeln wie „mindestens zwölf Zeichen, alle 90 Tage ändern“ wirken auf den ersten Blick sauber, scheitern aber oft an realen Prozessen. Gute Passwortvorgaben definieren nicht nur Anforderungen an Zeichenlänge, sondern den gesamten Lebenszyklus von Identitäten und Geheimnissen.

In der Praxis sollten Richtlinien mindestens zwischen Benutzerkonten, privilegierten Konten, Servicekonten, Notfallkonten und externen Zugängen unterscheiden. Jede dieser Klassen braucht eigene Vorgaben zu Länge, Erzeugung, Rotation, MFA, Speicherung, Ausgabe, Monitoring und Incident Response. Eine einzige globale Passwortregel für alle Konten ist in KRITIS fachlich zu grob.

Für Verzeichnisdienste wie Active Directory ist die Passwort-Policy nur ein Teil des Schutzes. Lockout-Schwellen, Fine-Grained Password Policies, Tiering, geschützte Admin-Gruppen, LAPS-ähnliche Mechanismen für lokale Administratoren, Kerberos-Härtung und die Reduktion alter Protokolle sind mindestens ebenso wichtig. Wer nur die Standard-Domain-Policy anpasst, aber privilegierte Konten nicht separat behandelt, verfehlt das eigentliche Risiko. Vertiefend relevant sind Active Directory Passwort Policy und Passwort Richtlinien Best Practice.

Regulatorische Anforderungen wie NIS2 oder ISO 27001 geben einen Rahmen vor, ersetzen aber keine technische Ausgestaltung. Entscheidend ist, dass Kontrollen nachweisbar funktionieren: keine Standardpasswörter in Betrieb, keine unkontrollierten Shared Accounts, definierte Onboarding- und Offboarding-Prozesse, sichere Reset-Verfahren, MFA für kritische Zugänge, regelmäßige Überprüfung privilegierter Rechte und dokumentierte Ausnahmebehandlungen. Wer Ausnahmen zulässt, muss sie begründen, befristen und kompensieren.

Besonders wichtig ist die Verbindung von Richtlinie und Realität. Wenn eine Anlage aus technischen Gründen kein modernes Verfahren unterstützt, darf das nicht im Graubereich bleiben. Dann braucht es dokumentierte Kompensationsmaßnahmen: Netzsegmentierung, Jump Hosts, enges Monitoring, Zugriff nur über dedizierte Admin-Systeme, zusätzliche Freigaben und verkürzte Prüfintervalle. In KRITIS ist die saubere Behandlung von Ausnahmen oft sicherheitsrelevanter als die Standardregel selbst.

Für die organisatorische Einbettung sind außerdem Nis2 Passwortanforderungen, Iso 27001 Passwortanforderungen und Passwort Richtlinien Unternehmen wichtige Bezugspunkte. Entscheidend bleibt jedoch die technische Durchsetzung im Alltag.

Passwortsicherheit ist kein einmaliges Projekt. In KRITIS muss sie kontinuierlich überprüft werden, weil sich Konten, Systeme, Dienstleister und Bedrohungen laufend ändern. Ein gutes Audit betrachtet nicht nur Richtliniendokumente, sondern reale technische Zustände. Dazu gehören Passwortalter, Konten ohne Eigentümer, deaktivierte aber noch nutzbare Accounts, fehlende MFA-Bindung, Servicekonten mit interaktiver Anmeldung, lokale Admin-Passwörter, Passwortspeicher in Skripten und Konfigurationsdateien sowie Hinweise auf Wiederverwendung.

Technische Audits sollten immer zwischen Online- und Offline-Risiken unterscheiden. Online wird geprüft, ob Login-Oberflächen gegen Brute Force, Password Spraying und Enumeration geschützt sind. Offline wird bewertet, wie widerstandsfähig gespeicherte Hashes und exportierte Geheimnisse gegen Cracking sind. Ergänzend ist zu prüfen, ob bekannte kompromittierte Passwörter blockiert werden und ob Passwortänderungen gegen Breach-Datenbanken oder interne Sperrlisten validiert werden.

Monitoring muss auf Missbrauchsmuster ausgerichtet sein. Einzelne Fehlanmeldungen sind selten aussagekräftig. Relevant sind verteilte Fehlversuche über viele Konten, geografisch unplausible Logins, Anmeldungen außerhalb üblicher Wartungsfenster, Nutzung privilegierter Konten auf untypischen Hosts, plötzliche Authentifizierungserfolge nach vielen Fehlschlägen oder parallele Sessions mit identischer Identität. Solche Muster deuten oft auf Password Spraying Angriff, gestohlene Zugangsdaten oder missbrauchte Notfallkonten hin.

Ein praxisnaher Audit-Workflow kann so aussehen:

1. Inventarisierung aller Kontotypen und Authentifizierungswege
2. Abgleich mit Richtlinien und Soll-Zustand
3. Technische Prüfung von Passwortspeicherung, Hashing und Reset-Prozessen
4. Analyse privilegierter Konten, Servicekonten und externer Zugänge
5. Kontrolle auf bekannte Leaks, Wiederverwendung und schwache Muster
6. Bewertung von Monitoring, Alarmierung und Incident-Playbooks
7. Priorisierung nach Auswirkung auf Betrieb und Kritikalität

Wichtig ist, dass Audits nicht nur Mängel sammeln, sondern umsetzbare Maßnahmen priorisieren. Ein veraltetes Hashverfahren in einer isolierten Altanwendung ist anders zu behandeln als ein gemeinsam genutztes VPN-Konto ohne MFA für externe Wartung. Gute Audits bewerten technische Schwere, Ausnutzbarkeit, Reichweite und betriebliche Folgen gemeinsam. Für strukturierte Prüfungen ist Passwort Audit Durchfuehren ein naheliegender Bezugspunkt.

Die beste Passwortregel scheitert, wenn die operativen Workflows unsauber sind. In KRITIS müssen Prozesse so gestaltet sein, dass sie auch unter Zeitdruck, im Schichtbetrieb und im Störungsfall funktionieren. Das betrifft insbesondere die Erzeugung neuer Kennwörter, die sichere Ausgabe an berechtigte Personen, die Rotation technischer Konten, den Passwort-Reset und den Umgang mit vermuteter Kompromittierung.

Bei der Erstellung neuer Passwörter sollte Zufall Standard sein. Menschlich erfundene Kennwörter sind fast immer schwächer als angenommen. Für Benutzerkonten kann ein kontrollierter Generator mit klaren Mindestparametern genutzt werden, für privilegierte und technische Konten sind lange Zufallswerte Pflicht. Die Ausgabe darf nicht über ungesicherte Kanäle erfolgen. Passwörter gehören nicht in Ticketsysteme, unverschlüsselte E-Mails, Chatverläufe oder Excel-Listen. Wenn eine temporäre Übermittlung nötig ist, muss sie kanalgetrennt, zeitlich begrenzt und nachvollziehbar erfolgen. Ergänzend relevant ist Passwort Sicher Uebertragen.

Rotation muss risikobasiert erfolgen. Nicht jedes Konto braucht denselben Zyklus. Für privilegierte Konten kann eine häufigere oder ereignisbasierte Rotation sinnvoll sein, etwa nach Personalwechsel, Dienstleisterwechsel, Incident, Wartungseinsatz oder Verdacht auf Offenlegung. Für Servicekonten ist Rotation nur dann sicher, wenn Abhängigkeiten bekannt und Tests vorbereitet sind. Blindes Ändern ohne Vorprüfung ist in KRITIS fahrlässig.

Besonders heikel ist der Passwort-Reset. Viele Organisationen härten die Login-Seite, lassen aber den Reset-Prozess offen. Ein Angreifer braucht dann kein Passwort zu knacken, sondern nur den Helpdesk zu überzeugen oder schwache Identitätsprüfungen auszunutzen. Deshalb müssen Reset-Verfahren mehrstufig, dokumentiert und für kritische Konten besonders restriktiv sein. Kein Reset privilegierter Konten ohne starke Verifikation, kein Versand neuer Kennwörter im Klartext, keine Freigabe allein auf Basis leicht beschaffbarer Personendaten.

Wenn ein Passwort kompromittiert sein könnte, zählt Geschwindigkeit. Ein Incident-Workflow muss klar definieren, wer sperrt, wer rotiert, wer abhängige Systeme prüft, wer Logs sichert und wer Folgezugriffe bewertet. Gerade bei privilegierten Konten reicht ein Passwortwechsel allein oft nicht aus, weil Session-Tokens, persistente Zugänge, API-Keys oder implantierte Mechanismen bestehen bleiben können.

Incident bei Passwortverdacht:
- Konto sofort sperren oder Zugriff einschränken
- Betroffene Sessions und Tokens invalidieren
- Passwort bzw. Geheimnis kontrolliert neu setzen
- Verwandte Konten und Wiederverwendung prüfen
- Logins, Rechteänderungen und laterale Bewegung analysieren
- Ursache feststellen: Phishing, Leak, Malware, Insider, Fehlprozess
- Kompensationsmaßnahmen und Lessons Learned dokumentieren

Wo möglich, sollte Passwortschutz durch zusätzliche Faktoren ergänzt werden. Für kritische Zugänge sind Multi Factor Authentication Erklaert und eine saubere Trennung von Rollen und Systemen unverzichtbar. Passwörter bleiben relevant, aber sie dürfen nicht die einzige Barriere sein.

Viele KRITIS-Betreiber stehen vor demselben Problem: Die Zielarchitektur ist klar, aber die Ist-Umgebung besteht aus Altlasten, Herstellerabhängigkeiten und Betriebszwängen. Deshalb braucht Passwortsicherheit einen realistischen Härtungsplan in Stufen. Nicht jede Schwachstelle lässt sich sofort beseitigen, aber fast jede lässt sich kurzfristig entschärfen.

Als Sofortmaßnahmen eignen sich die Entfernung gemeinsam genutzter Konten, die Aktivierung von MFA für externe und privilegierte Zugänge, die Sperrung bekannter Standardpasswörter, die Prüfung auf kompromittierte Kennwörter, die Inventarisierung von Servicekonten und die Absicherung von Reset-Prozessen. Parallel sollten alle administrativen Konten getrennt und auf dedizierte Arbeitsplätze verlagert werden. Schon diese Schritte reduzieren die Angriffsfläche deutlich.

In der zweiten Stufe geht es um Struktur: Einführung oder Ausbau zentraler Passwortverwaltung, saubere Rollenmodelle, technische Durchsetzung differenzierter Richtlinien, Härtung von Active Directory, Segmentierung von Admin-Zugängen, Alarmierung bei Nutzung kritischer Konten und regelmäßige Audits. Für viele Organisationen ist außerdem die Frage relevant, wann klassische Passwörter durch stärkere Verfahren ergänzt oder ersetzt werden sollten. Themen wie Zero Trust Authentifizierung und Passwortlos Authentifizieren gewinnen hier an Bedeutung, insbesondere für hochkritische Verwaltungszugänge.

Langfristig sollte die Zielarchitektur darauf ausgerichtet sein, dass Passwörter nur noch dort existieren, wo sie technisch notwendig sind, und dass ihre Nutzung streng kontrolliert, protokolliert und kontextabhängig bewertet wird. Dazu gehören starke Identitätsprüfung, risikobasierte Zugriffskontrolle, Just-in-Time-Privilegien, Secrets-Management für Maschinenidentitäten, durchgängige Protokollierung und belastbare Notfallverfahren.

Entscheidend ist die Reihenfolge. Wer zuerst kosmetische Passwortregeln verschärft, aber gemeinsam genutzte Admin-Konten, unkontrollierte Dienstleisterzugänge und schwache Reset-Prozesse bestehen lässt, investiert an der falschen Stelle. In KRITIS zählt nicht die formale Schärfe einer Policy, sondern die Reduktion realer Angriffswege. Gute Passwortsicherheit ist deshalb immer eine Kombination aus Technik, Prozessdisziplin, Verantwortlichkeit und kontinuierlicher Überprüfung.

Am Ende gilt: Ein starkes Passwort ist kein Sicherheitskonzept. Ein belastbarer Workflow für Identitäten, privilegierte Zugriffe, technische Konten und Notfälle dagegen schon. Genau dort entscheidet sich, ob eine KRITIS-Organisation Angriffe nur dokumentiert oder tatsächlich beherrscht.