*Autor: Eirik Salmi, System Analyst bei **Passwork*** **Wenn ein Angreifer Ihr Netzwerk mit einem legitimen Benutzernamen und Passwort betritt, welche Kontrolle hält ihn auf?** Für die meisten Finanzinstitute ist die ehrliche Antwort: Nichts fängt es sofort auf. Der Angreifer sieht aus wie ein autorisierter Benutzer. Er bewegt sich lateral, eskaliert Berechtigungen und kartiert kritische Systeme durchschnittlich 186 Tage lang, bevor der Einbruch überhaupt erkannt wird – und weitere 55 Tage, um ihn einzudämmen – laut **IBM**s [Cost of a Data Breach Report](https://www.ibm.com/reports/data-breach) (2025). Bis dahin ist der operative Schaden angerichtet und die regulatorische Uhr hat bereits begonnen zu ticken. Am 17. Januar 2025 trat der [Digital Operational Resilience Act (DORA)](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) in der gesamten EU in Kraft. Artikel 9 der Verordnung macht die Sicherheit von Anmeldedaten zu einer verbindlichen Kontrolle für Finanzrisiken, mit aufsichtsrechtlichen Konsequenzen für Institute, die diesen Anforderungen nicht nachkommen. Die Frage ist nicht mehr, ob Ihre Authentifizierungshaltung den Best Practices entspricht. Es geht darum, ob sie dem Gesetz entspricht – und ob Sie es beweisen können. Dieser Artikel beleuchtet die spezifischen Anforderungen von Artikel 9, die das Management von Anmeldedaten regeln, erklärt, warum ein kompromittiertes Passwort ein Versagen der operativen Resilienz im Rahmen von **DORA** darstellt, und skizziert die praktischen Kontrollen, die diese Lücke schließen. ## Die Bedrohung, gegen die DORA entwickelt wurde Gestohlene Anmeldedaten sind 2025 der größte initiale Zugangsvektor und machen 22 % aller Datenpannen aus, laut **Verizon**s [Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/). Für Finanzinstitute belaufen sich die branchenspezifischen Kosten dieser Exposition laut **IBM**s Cost of a Data Breach Report im Durchschnitt auf 5,56 Millionen US-Dollar pro Vorfall – ein Rückgang von 6,08 Millionen US-Dollar im Jahr 2024, aber immer noch die zweithöchsten aller Branchen weltweit. Die Angebotsseite des Diebstahls von Anmeldedaten wurde vollständig industrialisiert. Initial Access Broker verkaufen verifizierten Zugriff auf Unternehmensnetzwerke für durchschnittlich 2.700 US-Dollar, wobei 71 % der Angebote privilegierte Anmeldedaten enthalten – vorkonfigurierter Zugriff, der keine technischen Fähigkeiten zur Ausnutzung erfordert, laut **Rapid7**-Forschung. Infostealer wie **Lumma**, **RisePro**, **StealC**, **Vidar** und **RedLine** automatisieren die Erfassung von Anmeldedaten im großen Stil. **IBM** X-Force-Daten zeigen, dass ihre Verbreitung über Phishing im Jahr 2024 im Jahresvergleich um 84 % zugenommen hat, und Daten aus 2025 deuten auf eine noch steilere Entwicklung hin. **DORA**s Artikel 9 existiert genau, um diese Kette zu unterbrechen. Die Verordnung spiegelt eine dokumentierte, anhaltende Bedrohung für die operative Kontinuität der europäischen Finanzmärkte wider. ## Was DORA Artikel 9 tatsächlich verlangt [Artikel 9 von DORA](https://www.digital-operational-resilience-act.com/Article_9.html) – mit dem Titel „Schutz und Prävention“ – ist Teil des durch Artikel 6 vorgeschriebenen ICT-Risikomanagement-Frameworks. Er legt spezifische technische und verfahrenstechnische Verpflichtungen fest, die Finanzinstitute implementieren müssen. Zwei Bestimmungen sind für das Management von Anmeldedaten direkt relevant. * **Artikel 9(4)(c)** verlangt von Finanzinstituten, „Richtlinien zu implementieren, die den physischen oder logischen Zugriff auf Informations- und ICT-Assets auf das beschränken, was für legitime und genehmigte Funktionen und Aktivitäten erforderlich ist.“ Dies ist das Prinzip der geringsten Rechte, das als rechtliche Verpflichtung formuliert ist. * **Artikel 9(4)(d)** geht weiter und verlangt von den Instituten, „Richtlinien und Protokolle für starke Authentifizierungsmechanismen, basierend auf relevanten Standards und dedizierten Kontrollsystemen, sowie Schutzmaßnahmen für kryptografische Schlüssel zu implementieren, wobei Daten basierend auf den Ergebnissen genehmigter Datenklassifizierungs- und ICT-Risikobewertungsprozesse verschlüsselt werden.“ Wenn man diese Sprache in operative Begriffe übersetzt: MFA ist obligatorisch. Der Verweis auf „relevante Standards“ deutet direkt auf FIDO2/WebAuthn hin – den derzeit am weitesten verbreiteten Authentifizierungsstandard, der gegen Adversary-in-the-Middle (AiTM)-Phishing-Kits resistent ist, welche SMS- und TOTP-basierte MFA in Echtzeit umgehen können. Das Management kryptografischer Schlüssel ist eine regulatorische Anforderung. Privileged Access Management (PAM)-Tools werden in der Verordnung nicht explizit genannt – aber die von ihnen bereitgestellten Kontrollen entsprechen genau den Anforderungen von Artikel 9. Sitzungsaufzeichnung, Just-in-Time (JIT)-Zugriffsverwaltung und die Speicherung privilegierter Anmeldedaten sind genau die „dedizierten Kontrollsysteme“, die die Verordnung beschreibt. Institute, die diese Kontrollen nicht implementiert haben, stehen vor einer Compliance-Lücke, auf die Aufsichtsbehörden reagieren können. Die European Banking Authority (**EBA**) und die Regulatory Technical Standards der **ESMA** unter **DORA** liefern zusätzliche Spezifikationen zu den Anforderungen an das ICT-Risikomanagement und verstärken die Grundlage von Artikel 9 mit branchenspezifischen Implementierungsrichtlinien. ## Kompromittierung von Anmeldedaten als Versagen der operativen Resilienz Der erklärte Zweck von **DORA** ist es, sicherzustellen, dass Finanzinstitute ICT-Störungen widerstehen, darauf reagieren und sich davon erholen können. Eine Kompromittierung von Anmeldedaten sieht aus dieser Perspektive völlig anders aus als aus der Perspektive eines Sicherheitsvorfalls. Bei einer durchschnittlichen Verweildauer von 186 Tagen führt eine kompromittierte Anmeldeinformation nicht zu einem diskreten Sicherheitsereignis. Sie führt zu einer anhaltenden, unsichtbaren Bedrohung der operativen Kontinuität – ein Angreifer bewegt sich lateral, eskaliert Berechtigungen und kartiert kritische Systeme, während er als legitimer Benutzer erscheint. Es ist eine direkte Bedrohung für die operative Kontinuität, die **DORA** schützen soll. Der Einbruch in [das französische nationale Bankenregister](https://www.bleepingcomputer.com/news/security/data-breach-at-french-bank-registry-impacts-12-million-accounts/) im Januar 2026 machte die Mechanismen greifbar. Ein Angreifer erlangte die Anmeldedaten eines einzelnen Beamten mit Zugriff auf Ficoba – die interministerielle Datenbank, die Aufzeichnungen über jedes in Frankreich eröffnete Bankkonto enthält. Mit nur diesem einen Konto griff der Angreifer auf Daten von 1,2 Millionen Bankkonten zu und extrahierte diese, einschließlich IBANs, Namen und Adressen der Kontoinhaber sowie Steuernummern. Das betroffene System wurde offline genommen, die Abläufe im Register wurden unterbrochen und der Vorfall wurde der französischen Datenschutzbehörde **CNIL** gemeldet. Der Angriff erforderte keine technischen Raffinessen. Unter **DORA** würde ein Vorfall dieses Ausmaßes bei einem Finanzinstitut unter Artikel 19 Meldepflichten auslösen – eine erste Benachrichtigung innerhalb von 4 Stunden nach Klassifizierung (und spätestens 24 Stunden nach Erkennung), ein Zwischenbericht innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats. ## Die Dimension Dritter: Anbieter-Anmeldedaten sind Ihre Anmeldedaten Kapitel V von **DORA** legt Finanzinstituten explizite Verpflichtungen in Bezug auf das ICT-Risiko von Dritten auf. Der Compliance-Perimeter endet nicht bei den eigenen Systemen des Instituts. Der [Santander-Einbruch](https://www.bleepingcomputer.com/news/security/snowflake-account-hacks-linked-to-santander-ticketmaster-breaches/) im Mai 2024 ist der europäische Referenzpunkt. Angreifer nutzten von **Snowflake**-Mitarbeitern gestohlene Anmeldedaten, um auf eine Datenbank mit Kunden- und Mitarbeiterdaten in Spanien, Chile und Uruguay zuzugreifen. Die Anmeldedaten waren Monate zuvor durch Infostealer-Malware, die Workstations von Auftragnehmern infizierte, geerntet worden. Keines der kompromittierten **Snowflake**-Konten hatte Multi-Faktor-Authentifizierung aktiviert. Der Einstiegspunkt lag nicht bei **Santander**. Es war die schwache Authentifizierungshaltung eines Anbieters – und sie legte Daten eines der größten europäischen Banken offen, ohne dass ein einziger Exploit geschrieben werden musste. Unter **DORA** steht ein Finanzinstitut, dessen kritischer ICT-Anbieter einen Anmeldedaten-basierten Einbruch erleidet, direkt unter regulatorischer Beobachtung. Institute müssen vertraglich gleichwertige Authentifizierungsstandards von ihren Anbietern verlangen und die Einhaltung dieser Anforderungen prüfen. Eine Lücke in der Passwortrichtlinie eines Anbieters ist nicht allein das Problem des Anbieters – es ist die regulatorische Haftung des Finanzinstituts. ## Aufbau eines DORA-konformen Anmeldedaten-Managements Die Erfüllung der Anforderungen von Artikel 9 erfordert ein strukturiertes Programm in vier Bereichen. * **Implementieren Sie zuerst Phishing-resistente MFA.** FIDO2/WebAuthn-basierte Authentifizierung – Hardware-Sicherheitsschlüssel, Passkeys, Plattform-Authentifikatoren. SMS- und TOTP-basierte Einmalpasswörter sind gegen aktuelle Angriffstechniken nicht ausreichend. Erzwingen Sie Phishing-resistente MFA für alle Benutzer, mit besonderer Strenge bei privilegierten Konten und Fernzugriffspfaden. * **Erzwingen Sie den Zugriff nach dem Prinzip der geringsten Rechte.** JIT-Provisionierung – die Gewährung von erhöhten Zugriffsrechten nur für die Dauer einer bestimmten Aufgabe – eliminiert die stehenden Berechtigungen, die den Diebstahl von Anmeldedaten so schädlich machen. Deaktivieren Sie Konten sofort nach der Abmeldung. Ruhende Konten gehören zu den häufigsten und am besten vermeidbaren Angriffsvektoren. * **Speichern Sie alle Anmeldedaten.** Service-Account-Passwörter, API-Schlüssel und privilegierte Anmeldedaten müssen in einem verschlüsselten, zugriffskontrollierten Anmeldedaten-Tresor gespeichert werden. Manuelles Anmeldedaten-Management im großen Stil ist operativ nicht praktikabel und liefert keine Audit-Spur. Ein Business-Passwort-Manager