Das BSI hat den Passwortwechsel abgeschafft – aber nur unter einer Bedingung

Was ORP.4.A23 wirklich verlangt – und warum Kompromittierungserkennung keine Kür, sondern Voraussetzung ist.

Eine Szene, die sich in deutschen Unternehmen regelmäßig wiederholt: Der externe ISMS-Auditor fragt nach der Passwort-Richtlinie. Der IT-Leiter antwortet selbstbewusst: „Wir erzwingen keinen turnusmäßigen Wechsel mehr. Das BSI empfiehlt das seit 2020 nicht mehr." Der Auditor nickt — und stellt die Folgefrage: „Und wie erkennen Sie, ob ein Passwort kompromittiert wurde?"

Stille.

Denn genau hier liegt das Problem. Das BSI hat den Zwangswechsel tatsächlich abgeschafft — aber an eine klare Bedingung geknüpft, die in der Praxis erstaunlich oft ignoriert wird.

Was in ORP.4.A23 tatsächlich steht

Die entscheidende Änderung kam mit der Edition 2020 des IT-Grundschutz-Kompendiums. Der Baustein ORP.4 „Identitäts- und Berechtigungsmanagement" wurde überarbeitet. Die Anforderung ORP.4.A23 formuliert es unmissverständlich:

Drei Sätze — und der entscheidende Unterschied liegt in einem einzigen Wort. Die ersten beiden Sätze verwenden „SOLLTEN" — das sind Empfehlungen. Der dritte Satz verwendet „MÜSSEN" — das ist eine verbindliche Anforderung. Im BSI-Sprachgebrauch bedeutet MÜSSEN: ohne Wenn und Aber umzusetzen. Wer den Passwortwechsel abschafft, aber keine Kompromittierungserkennung einführt, erfüllt die Anforderung nicht.

Das ist kein interpretatorischer Spielraum. Es ist eine Pflicht.

Warum das BSI überhaupt umgesteuert hat

Die Abkehr vom Zwangswechsel hatte einen konkreten Hintergrund. Jahrelange Studien — unter anderem von NIST (SP 800-63B, 2017), dem britischen NCSC und dem BSI selbst — zeigten ein wiederkehrendes Muster: Erzwungene Passwortwechsel alle 60 oder 90 Tage führten dazu, dass Nutzer schwächere Passwörter wählten, Muster verwendeten (Sommer2024!, Herbst2024!, Winter2025!) oder Passwörter auf Post-its notierten.

Die Logik dahinter ist nachvollziehbar: Ein starkes, einzigartiges Passwort, das nicht kompromittiert ist, muss nicht gewechselt werden. Der Wechsel ist erst dann sinnvoll, wenn ein konkreter Anlass besteht — und der häufigste „valide Grund" ist eine erkannte Kompromittierung.

Das BSI hat also nicht gesagt: „Passwörter müssen nie mehr gewechselt werden." Es hat gesagt: „Wechselt nicht mehr blind nach Kalender — aber stellt sicher, dass ihr es merkt, wenn ein Passwort in falsche Hände gerät."

Die halbe Erfüllung – und warum sie nicht reicht

Viele Unternehmen haben den ersten Teil umgesetzt: Der erzwungene 90-Tage-Wechsel wurde aus dem Active Directory entfernt. Das ist der einfache Teil. Der zweite Teil — die Kompromittierungserkennung — ist deutlich seltener implementiert.

In der Praxis sieht man häufig eine von zwei Varianten:

Variante 1: Gar keine Erkennung. Der Zwangswechsel wurde entfernt, und das war es. Es gibt keinen Mechanismus, der prüft, ob Passwörter in Leaks aufgetaucht sind. Die Argumentation lautet oft: „Unsere Passwörter sind stark genug" — was die Frage der Kompromittierung völlig ignoriert.

Variante 2: Einmaliger Abgleich bei der Passwortvergabe. Tools wie Azure AD Password Protection oder ein haveibeenpwned-Abgleich prüfen zum Zeitpunkt der Passworterstellung, ob das gewählte Passwort in bekannten Leaks vorkommt. Das ist besser als nichts — aber es deckt nur den Moment der Erstellung ab. Was passiert, wenn das Passwort drei Monate später durch einen Infostealer abgegriffen wird? Oder wenn die Zugangsdaten eines Mitarbeiters bei einem Breach eines Drittanbieters auftauchen?

Die MÜSSEN-Anforderung in ORP.4.A23 verlangt nicht eine einmalige Prüfung. Sie verlangt „Maßnahmen, um die Kompromittierung zu erkennen" — und Kompromittierung ist ein kontinuierliches Risiko, kein einmaliges Ereignis.

Wo Dark Web Monitoring die Lücke schließt

Genau hier setzt Dark Web Monitoring an. Statt nur zum Zeitpunkt der Passworterstellung zu prüfen, überwacht ein kontinuierliches Monitoring die Quellen, in denen kompromittierte Zugangsdaten tatsächlich landen: Dark-Web-Marktplätze, Infostealer-Logs, Paste Sites, Telegram-Kanäle und Credential-Dumps.

Der Unterschied ist grundlegend:

• Einmaliger Check: Prüft bei der Passwortvergabe gegen historische Leaks. Erkennt keine neuen Kompromittierungen.
• Kontinuierliches Monitoring: Erkennt, wenn Zugangsdaten Ihrer Domain in neuen Leaks, Infostealer-Logs oder Credential-Dumps auftauchen — Tage, Wochen oder Monate nach der Passworterstellung.

In der Praxis bedeutet das: Wenn ein Mitarbeiter sein (starkes, einzigartiges) Firmenpasswort auf einem privaten Gerät verwendet, das von einem Infostealer wie RedLine oder Lumma infiziert wird, landen die Zugangsdaten auf einem Dark-Web-Marktplatz — oft innerhalb von Stunden. Ein einmaliger haveibeenpwned-Check zum Zeitpunkt der Passworterstellung erkennt das nicht. Kontinuierliches Monitoring schon.

Ein professionelles Dark Web Monitoring liefert dabei nicht nur die Information „E-Mail-Adresse wurde gefunden", sondern auch den Kontext: Welcher Dienst war betroffen? Handelt es sich um einen Klartext-Leak oder einen Hash? Stammen die Daten aus einem Infostealer-Log mit Session-Cookies? Diese Informationen bestimmen die Reaktion — von einem gezielten Passwort-Reset bis zur vollständigen Session-Invalidierung und Forensik.

Moderne Monitoring-Lösungen integrieren sich per Webhook oder SIEM-Anbindung in bestehende Incident-Response-Prozesse: Ein Fund löst automatisch ein Ticket aus, das SOC wird benachrichtigt, und der betroffene Account kann gezielt zurückgesetzt werden — nicht pauschal alle 90 Tage, sondern genau dann, wenn es einen konkreten Anlass gibt. Genau das, was ORP.4.A23 verlangt.

Der ehrliche Teil: Dark Web Monitoring ist Frühwarnung, kein Vollschutz

Kein seriöser Anbieter behauptet, dass Dark Web Monitoring jede Kompromittierung in Echtzeit erkennt. Zwischen dem Moment, in dem ein Infostealer Zugangsdaten abgreift, und dem Zeitpunkt, an dem diese Daten auf einem Marktplatz oder in einem Dump auftauchen, vergeht Zeit — manchmal Stunden, manchmal Tage, in seltenen Fällen Wochen.

Aber diese Latenz ändert nichts an der grundsätzlichen Wirksamkeit. Die Alternative — kein Monitoring — bedeutet, dass die Kompromittierung möglicherweise erst bei einem erfolgreichen Angriff erkannt wird. Die Frage ist nicht „perfekte Erkennung oder keine Erkennung", sondern „Frühwarnung mit Handlungsfenster oder Blindflug".

Für eine belastbare Abdeckung empfiehlt sich ein Multi-Provider-Ansatz: Verschiedene Monitoring-Dienste haben Zugang zu unterschiedlichen Quellen. Kein einzelner Anbieter sieht alles. Ergänzend sollte auch Brand-Mention-Monitoring eingesetzt werden — also die Überwachung, ob der Firmenname, die Domain oder spezifische Marken in Dark-Web-Foren im Kontext von Angriffen oder Datenverkäufen erwähnt werden.

Warum das auch für den Nachweis zählt

ORP.4.A23 ist nicht nur eine technische Anforderung — sie ist auch eine dokumentationspflichtige. In einem ISMS-Audit nach ISO 27001 oder einer BSI-Grundschutz-Zertifizierung muss nachgewiesen werden, dass Maßnahmen zur Kompromittierungserkennung existieren, dokumentiert und wirksam sind.

Das bedeutet konkret: Es reicht nicht, zu sagen „Wir haben Dark Web Monitoring". Es muss dokumentiert sein, welche Domains überwacht werden, wie häufig geprüft wird, wie Funde eskaliert werden und welche Reaktionsmaßnahmen definiert sind. Ein regelmäßiger Report — idealerweise automatisiert — schafft den Nachweis, dass die Anforderung nicht nur initial umgesetzt, sondern kontinuierlich gelebt wird.

Dieser Nachweis wird zunehmend auch jenseits des IT-Grundschutzes relevant. Die NIS-2-Richtlinie (Art. 21) verlangt von betroffenen Unternehmen „Konzepte in Bezug auf die Sicherheit der Lieferkette" und „Bewältigung von Sicherheitsvorfällen" — und die Fähigkeit, kompromittierte Zugangsdaten zu erkennen, bevor sie für einen Angriff genutzt werden, fällt unmittelbar in beide Kategorien.

Fazit

Das BSI hat den Passwortwechsel nicht abgeschafft. Es hat ihn an eine Bedingung geknüpft: Die Kompromittierung muss erkennbar sein. Wer den turnusmäßigen Wechsel entfernt, ohne eine kontinuierliche Erkennung einzuführen, erfüllt ORP.4.A23 nicht — und steht im Audit schlecht da.

Dark Web Monitoring ist nicht die einzige Maßnahme, die diese Lücke schließt — aber es ist die naheliegendste. Es liefert den konkreten, dokumentierbaren Mechanismus, den die Anforderung verlangt: eine Maßnahme, die Kompromittierung erkennt und einen gezielten Wechsel auslöst.

Wenn Sie wissen möchten, ob Zugangsdaten Ihres Unternehmens bereits im Dark Web kursieren, erstellen wir Ihnen einen kostenlosen Report über die letzten 24 Monate.

Jetzt kostenlosen Report anfordern — und die MÜSSEN-Anforderung aus ORP.4.A23 mit konkreten Daten untermauern.