DORA ist seit Anfang 2025 EU-weit in Kraft. Die Übergangsfrist, die eigentlich keine war, ist abgelaufen. Seit Monaten finden Audits statt. Die Muster, die sich in den Ergebnisberichten abzeichnen, beginnen sich zu wiederholen.

Sprechen wir darüber, wo DORA eine typische AD-Authentifizierungsarchitektur unter Druck setzt und wie SystoLOCK darauf reagiert. Wir gehen davon aus, dass Sie die Verordnung kennen, oder ein Compliance-Team haben, das das für Sie erledigt hat. Die interessante Frage ist nicht mehr, was DORA vorschreibt, sondern wie eine Infrastruktur aussehen muss, um das Audit zu bestehen.

Das Konto eines Händlers wird als verdächtig markiert. Die Zeit drängt: DORA-Meldepflichten für schwerwiegende Vorfälle laufen in Stunden, nicht Tagen, und der Bericht muss die Kontoaktivitäten lückenlos dokumentieren. Die erste Frage, die jeder Analyst stellt, ist immer dieselbe: Wo hat sich dieses Konto in den letzten acht Stunden angemeldet, mit welchem Authentifizierungsfaktor und von welchem Gerät aus?

In einer typischen AD-Umgebung vergehen Stunden, bis die Antwort zusammengesucht ist. Windows-Ereignisprotokolle auf Dutzenden von Servern, Entra-Anmeldeprotokolle, VPN-Protokolle, Jump-Host-Protokolle, Anwendungsprotokolle der Handelsplattform. Jedes in einem anderen Format. Mal UPN, mal SAMAccountName, mal eine interne Kennung, die erst gemappt werden muss. Die Zeit läuft.

Mit SystoLOCK im Authentifizierungspfad erzeugt jede Authentifizierung ein strukturiertes Ereignis, das mit dem AD-Prinzipal verknüpft ist und in dem der verwendete Faktor sowie der Status der Sicherheitsstufe erfasst werden. Der Verlauf stammt aus einer einzigen Quelle, da er über den SystoLOCK-Broker läuft – und nicht, weil die Windows-Ereignisprotokolle plötzlich kohärent geworden wären. Der Auditbericht lässt sich noch innerhalb des Vorfallsfensters erstellen, nicht erst im Nachgang.

DORA erwartet die strengsten Kontrollmaßnahmen dort, wo das Risiko am höchsten ist. In einem Finanzunternehmen ist dies der privilegierte Pfad: Administratoren des Zahlungsswitches, des Handelssystems, des Kernbankbuchs und von AD selbst. Die meisten Unternehmen verfügen über MFA am Perimeter und ein Passwort für den internen privilegierten Pfad: Der Prüfer muss das nicht lange suchen.

SystoLOCK unterscheidet auf Protokollebene nicht zwischen privilegierter und regulärer Authentifizierung. Dasselbe Faktor-Modell schützt die interaktive Anmeldung eines Administrators, dessen „RunAs“-Aufruf, dessen PowerShell-Remoting-Sitzung sowie dessen RDP-Verbindung zum Jump-Host. Es gibt keinen Fall, in dem der Schutz stillschweigend auf ein Passwort reduziert wird. Step-up-Richtlinien können für Vorgänge mit dem höchsten Risiko einen zusätzlichen Faktor vorschreiben, doch die Grundvoraussetzung ist über die gesamte Matrix hinweg einheitlich.

Das zählt weniger als Feature, mehr als Sicherheitseigenschaft: Der Prüfer kann keinen privilegierten Pfad finden, bei dem die Anmeldedaten schwächer sind als die Perimeter-MFA, da dieser Pfad im Deployment schlicht nicht existiert.

Cloud-abhängige MFA ist in Ordnung, solange die Cloud erreichbar ist. Für ein Finanzunternehmen, das während eines Ausfalls weiterhin Transaktionen abwickeln muss, ist die Frage der Ausfallsicherheit auf dem Authentifizierungspfad struktureller Natur. Die RTS macht dies für die Prüfung sichtbar. Die Antwort „Wir haben einen Failover-Plan“ ist nicht dasselbe wie eine Architektur, die keinen solchen benötigt.

SystoLOCK wird vor Ort betrieben, in derselben Domäne, in der die Authentifizierung stattfindet. Im Authentifizierungspfad ist kein Cloud-Dienst enthalten. Selbst wenn Entra ausfällt, das WAN nicht erreichbar ist oder beim Anbieter der Cloud-MFA ein eigener Vorfall auftritt, läuft die Authentifizierung weiter. Das ist kein Hochverfügbarkeitsversprechen und keine Disaster-Recovery-Geschichte. Es ist eine Eigenschaft des Betriebsorts.

Ein Techniker eines Drittanbieters benötigt um 02:00 Uhr Zugang, weil etwas brennt. Die DORA-Vorschriften für Drittanbieter sehen vor, dass die Authentifizierung dieses Technikers Kontrollen unterliegt, die mindestens ebenso streng sind wie die des Finanzinstituts selbst. In der Praxis bedeutet dies in der Regel, dass entweder das Institut dem Personal des Anbieters Zugangsdaten und Sicherheitsfaktoren ausstellt oder dass das Institut die MFA-Verfahren des Anbieters übernimmt und diese überprüft. Die zweite Option ist schwieriger zu rechtfertigen.

SystoLOCK kann Faktoren für Lieferantenkonten unter denselben Kontrollmechanismen wie für Mitarbeiterkonten ausstellen, mit demselben Prüfpfad und demselben Lebenszyklus. Es gibt kein paralleles Identitätssystem, keinen separaten MFA-Broker und keinen vertraglichen Sonderweg. Die Frage des Prüfers zur Drittanbieter-Authentifizierung hat dieselbe Antwort wie die zur Mitarbeiter-Authentifizierung, weil es dieselbe Infrastruktur ist.

Jede regulierte Umgebung verfügt über Notfallkonten. Den lokalen Administrator auf dem Domänencontroller. Das Break-Glass-Konto für den Fall, dass Active Directory selbst nicht erreichbar ist. Das Vendor-Support-Konto, das laut Dokumentation nur der Bereitschaftstechniker kennen sollte. Die Anforderungen von DORA an den Identitätslebenszyklus machen diese Konten transparent: Wer darf sie nutzen, wie wird die Nutzung überwacht und wie sieht der Wiederherstellungsplan aus, wenn die letzte Person, die die Anmeldedaten kannte, das Unternehmen verlässt?

Dies ist der einzige Punkt, bei dem SystoLOCK nicht für jede Variante eine eindeutige Antwort bereithalten kann. Das Produkt unterstützt passwortlose Notfallzugriffe mit Sicherheitsfaktorverwahrung, bei der der Sicherheitsfaktor in einem versiegelten Umschlag oder einem Tresor aufbewahrt wird und das Protokollereignis dem jeder anderen Authentifizierung entspricht. Für das echte Szenario „AD selbst ausgefallen“ braucht es weiterhin einen Notfallpfad außerhalb von SystoLOCK, denn in diesem Szenario ist per Definition alles, was SystoLOCK benötigt, nicht mehr verfügbar. SystoLOCK reduziert die Passwortfläche erheblich, aber ein kleiner Rest bleibt bewusst bestehen, und ein kompetenter Prüfer wird erwarten, dass dieser dokumentiert und kontrolliert ist.

DORAs Beitrag zur Authentifizierungsdebatte ist einfach: Die Aussage „Wir haben MFA“ einer ernsthaften Prüfung nicht mehr standhält. Der Prüfer fragt, wo in der Infrastruktur die MFA vorhanden ist, um welche Art es sich handelt und was an den Stellen geschieht, an denen sie fehlt. Für eine lokale AD-Infrastruktur, die kritische Funktionen ausführt, ist SystoLOCK das einzige uns bekannte Produkt, mit dem jede Antwort auf diese Frage dieselbe ist.

NIS2 war das Aufwärmen. DORA hat weniger Geduld.