Continuous Authentication im Online-Banking ist kein Sicherheits-Add-on, sondern eine Governance-Lücke nach dem Login

Ein Kunde meldet sich im Online-Banking an. Die starke Authentifizierung greift, das Gerät ist bekannt, die Sitzung beginnt ohne Auffälligkeiten. Aus Sicht des Instituts ist der kritische Moment zunächst vorbei. Im Tagesgeschäft zeigt sich später etwas anderes: einzelne verdächtige Transaktionen, steigende manuelle Prüfaufwände im Fraud-Team, gesperrte Sitzungen, die sich im Nachhinein als legitim erweisen, und Kunden, die zusätzliche Abfragen nicht nachvollziehen können.

Gerade deshalb wird das Risiko oft unterschätzt. Das System funktioniert scheinbar. Der Login ist sauber. Die Kontrollen sind dokumentiert. Doch viele aktuelle Angriffe zielen nicht mehr primär darauf, den Zugang formal zu brechen. Sie übernehmen legitime Sitzungen, erben vorhandenes Vertrauen oder bewegen den Kunden selbst dazu, einen riskanten Schritt zu bestätigen. Der Angriff verschiebt sich. Die Kontrolllogik bleibt häufig am alten Ort.

Die Debatte ist damit falsch gerahmt. Das Problem ist nicht, dass Banken zu wenig Authentifizierung haben. Das eigentliche Problem ist, dass sie Vertrauen zu früh abschließen. Im Online-Banking reicht es nicht, die Identität beim Einstieg festzustellen. Entscheidend ist, ob Verhalten, Kontext, Gerät und Transaktionsmuster auch fünf oder zehn Minuten später noch zu derselben Risikobewertung passen.

Continuous Authentication sollte deshalb nicht als technische Zusatzfunktion verstanden werden. Sie ist ein anderes Betriebsmodell für digitale Vertrauensentscheidungen. Nicht einmal prüfen und dann hoffen, sondern Vertrauen über die aktive Sitzung hinweg bewerten, begrenzen und bei Bedarf neu absichern.

Warum klassische Authentifizierung an der falschen Stelle sicher ist

Starke Erstauthentifizierung bleibt notwendig. Im Banking ist darüber nicht ernsthaft zu diskutieren. Aber sie adressiert vor allem den Eintrittspunkt, nicht die Dynamik danach. PSD2 und starke Kundenauthentifizierung haben die erste Hürde in vielen Märkten wirksam angehoben. Das war richtig. Es hat jedoch einen erwartbaren Nebeneffekt erzeugt: Angreifer investieren stärker in den Missbrauch legitimer oder scheinbar legitimer Sitzungen.

In der Praxis zeigt sich das in vertrauten Mustern. Credential Stuffing, wiederverwendete Passwörter aus früheren Datenabflüssen, Session Hijacking, Remote-Access-Malware und Social-Engineering-Angriffe zielen oft nicht auf den spektakulären Bruch der Login-Strecke. Sie zielen auf den Moment danach. Im Mobile Banking kommt hinzu, dass der Nutzer selbst Teil der Angriffsfläche wird, etwa wenn er einen Schritt bestätigt, dessen tatsächliche Bedeutung im Prozess nicht mehr klar erkennbar ist.

Der erste symptomatische Fehler in vielen Organisationen ist daher selten eine objektiv schwache Login-Strecke. Häufiger ist es ein Betriebsmodell, das nach erfolgreicher Anmeldung zu lange von Stabilität ausgeht. Eine Sitzung wird eröffnet, Timeouts sind definiert, einzelne Schwellenwerte existieren, doch dazwischen bleibt viel Vertrauen implizit. Der erste sichtbare Schaden ist dann oft nicht ein großer Vorfall, sondern operative Reibung: mehr False Positives, mehr Eskalationen zwischen IAM und Fraud, mehr Friktion für legitime Kunden.

Ein häufiger Irrtum besteht darin, diese Symptome jeweils lokal zu behandeln. Dann optimiert das IAM-Team den Zugang, das Fraud-Team schärft Regeln für Transaktionen, und das UX-Team versucht, die zusätzliche Reibung zu begrenzen. Die Koordination steigt. Die Entscheidungsgüte nicht unbedingt. Das eigentliche Defizit liegt nicht in einem einzelnen Kontrollpunkt, sondern in der fehlenden Steuerung von Vertrauen innerhalb der Sitzung.

Das Risiko liegt nicht im Event, sondern in der Laufzeit der Sitzung

Viele Banken behandeln Authentifizierung noch immer als punktuelle Entscheidung: Ein Nutzer ist drin oder nicht drin. Diese Logik war tragfähiger, als Sitzungen kurz waren, Kanäle begrenzt und digitale Journeys überschaubar. Sie ist weniger belastbar in einer Umgebung aus mobilen Endgeräten, App-Wechseln, langen Self-Service-Prozessen und hybriden Betrugsmustern, bei denen technische und psychologische Angriffe ineinandergreifen.

Was sich verändert hat, ist nicht nur die Technologie auf Angreiferseite. Auch die ökonomische Logik des digitalen Bankings hat sich verschoben. Institute sollen Sicherheit, geringe Abbruchraten, regulatorische Nachvollziehbarkeit und niedrige manuelle Bearbeitungskosten gleichzeitig liefern. Das führt zu einer unangenehmen Wahrheit: Wer jede Unsicherheit mit zusätzlicher Re-Authentifizierung beantwortet, schützt nicht automatisch besser. Er verlagert Kosten in den Support, erhöht Abbrüche und belastet die Kundenbeziehung. Wer dagegen zu lange auf dem ursprünglichen Vertrauenszustand beharrt, lädt Betrugsrisiken in die laufende Sitzung ein.

A common operating pattern is a clean separation between identity controls at login and transaction monitoring later in the process. Diese Trennung wirkt organisatorisch vernünftig, erzeugt aber in der Sitzung eine Grauzone. Dort fehlen gemeinsame Signale, gemeinsame Entscheidungsregeln und klare Verantwortlichkeit. Das ist kein reines Architekturthema. Es ist eine Governance-Frage.

Continuous Authentication ist deshalb vor allem eine Frage der laufenden Vertrauensbewertung. Nicht jeder Teil einer Sitzung sollte gleich behandelt werden. Ein unverändertes Nutzungsmuster auf bekanntem Gerät erfordert eine andere Reaktion als ein Kanalwechsel, ein ungewöhnlicher Gerätekontext oder ein Verhalten, das nicht zur bisherigen Session passt. Sicherheit und Nutzererlebnis stehen hier nicht grundsätzlich im Widerspruch. Sie hängen an der Qualität der laufenden Entscheidung.

Das Session Trust Operating Model ordnet eine Diskussion, die in vielen Banken verteilt geführt wird

Um diese Lücke systematisch zu adressieren, hilft kein weiterer isolierter Kontrollpunkt. Nötig ist ein Steuerungsrahmen, der Identität, Risiko, Fraud und Kundenerlebnis auf dieselbe operative Logik bringt. Dafür ist das Session Trust Operating Model nützlich. Es beschreibt nicht, welche Technologie eine Bank kaufen sollte. Es beschreibt, welche Entscheidungen ein Institut beherrschen muss, um Vertrauen über die gesamte Sitzung hinweg zu steuern.

Der Wert des Modells liegt in seiner Einfachheit. Es zwingt eine Organisation, die impliziten Annahmen offenzulegen, die heute oft auf mehrere Teams verteilt sind. In Strategiegesprächen ist das hilfreich, weil die Diskussion dadurch von Tools auf Entscheidungsqualität wechselt. Das Modell besteht aus vier Steuerungsfragen:

• Auslöser: Welche Ereignisse innerhalb einer aktiven Sitzung führen überhaupt zu einer neuen Vertrauensbewertung?
• Signale: Welche Verhaltens-, Geräte-, Kontext- und Risikohinweise werden zusammengeführt, und welche davon sind tatsächlich entscheidungsrelevant?
• Verantwortung: Wer entscheidet über Reaktionen auf Abweichungen — IAM, Fraud, Risk, Channel Owner oder ein gemeinsames Gremium?
• Reaktion: Welche Antwort ist in welchem Szenario angemessen — weiterlaufen lassen, still überwachen, Step-up auslösen oder Transaktionen begrenzen?

Was das Modell in der Bankpraxis sichtbar macht

Für große Institute mit komplexer Kanal- und Systemlandschaft liegt die Hauptschwierigkeit meist nicht im Mangel an Signalen. Das Problem ist ihre Zusammenführung. Historisch gewachsene IAM-Architekturen, separate Fraud-Systeme und produktbezogene Prozesslogiken erzeugen unterschiedliche Risikobilder für denselben Kundenmoment. Der Effekt ist bekannt: Koordinationskosten steigen, Reaktionen werden uneinheitlich, und niemand kann sauber erklären, warum ein Kunde an einer Stelle unterbrochen und an anderer Stelle durchgewinkt wurde.

In mittleren Organisationen wird das Thema oft zuerst sichtbar, wenn digitale Kanäle wachsen und mobile Nutzung zur Norm wird. Die ursprüngliche Login-Logik war für stabile, kurze Interaktionen gebaut. Später entstehen längere Journeys, mehr Self-Service und mehr Abhängigkeit von App-basierten Prozessen. Dann häufen sich Beschwerden über unerwartete Unterbrechungen oder Sicherheitsmaßnahmen, die auf legitime Nutzer unnötig streng wirken. The first symptom is rarely a board-level security alarm, but a steady rise in exceptions, reviews, and customer irritation.

Regulatorisch verschärft sich die Lage ebenfalls. PSD2, SCA und eine allgemein strengere Erwartung an nachweisbare Kontrolle im Finanzsektor verschieben den Maßstab. Gefordert ist nicht nur dokumentierte Sicherheit, sondern operationalisierte Sicherheit. Auch europäische Vorgaben zu Resilienz und Governance, etwa rund um DORA, erhöhen den Druck auf nachvollziehbare Zuständigkeiten, Integrität der Prozesse und belastbare Reaktionsfähigkeit. Wer Vertrauen nur am Login dokumentieren kann, aber nicht in der Sitzung steuern kann, hat eine Lücke zwischen formaler Kontrolle und operativer Kontrolle.

Im letzten Drittel dieser Entwicklung wird auch die Infrastrukturfrage relevant. Plattformen wie Nevis werden dort interessant, wo Institute eine konsistente Vertrauenslogik über komplexe digitale Umgebungen hinweg operationalisieren müssen, ohne in eine vollständige IAM-Neuordnung auf einmal gezwungen zu werden. Entscheidend ist dabei weniger ein einzelnes Produktmerkmal als die Fähigkeit, Sicherheitsentscheidung, Nutzerfluss und regulatorische Anforderungen in einem gemeinsamen Kontrollrahmen zusammenzuführen.

Vier Fragen, die ein Institut intern belastbar beantworten können sollte

Ob eine Bank beim Thema Continuous Authentication substanziell vorankommt, zeigt sich nicht an einer Roadmap-Folie. Es zeigt sich an der Qualität ihrer internen Antworten. Diese Fragen sind deshalb nützlich, weil sie schnell offenlegen, ob das Institut das Sitzungsrisiko tatsächlich steuert oder nur den Einstieg optimiert.

• Können wir klar benennen, welche Ereignisse während einer aktiven Sitzung heute eine neue Vertrauensbewertung auslösen?
• Können wir erklären, wer über Reaktionen auf abweichendes Verhalten entscheidet und nach welcher Logik diese Entscheidung erfolgt?
• Wissen wir, an welchen Stellen wir legitime Kunden mit unnötiger Friktion belasten, weil Signale isoliert statt im Zusammenhang bewertet werden?
• Können wir für zentrale digitale Journeys belegen, wie Vertrauen, Betrugsprävention und Nutzererlebnis gemeinsam gesteuert werden?

Die strategische Konsequenz liegt jenseits des Logins

Der Markt behandelt Authentifizierung noch häufig als Eintrittskontrolle. Für Online-Banking reicht diese Sicht nicht mehr aus. Das Problem ist nicht der fehlende starke Login. Das Problem ist die fehlende Governance des Vertrauens danach. Je stärker Angriffe in legitime Sitzungen hineinwandern, desto weniger genügt eine Sicherheitsarchitektur, die nur am Anfang streng ist.

Für CISOs, IAM-Verantwortliche und IT-Leitungen folgt daraus eine nüchterne Priorität: Nicht jede Bank braucht sofort eine neue Großarchitektur. Aber jede Bank braucht ein belastbares Modell dafür, wie Vertrauen während einer Sitzung beobachtet, neu bewertet und angepasst wird. Wer das nicht als Steuerungsproblem begreift, wird weiter in lokalen Optimierungen arbeiten, während Risiko, Reibung und manuelle Kosten gemeinsam steigen.

Die strategische Frage lautet deshalb nicht, ob der Login stark genug ist. Sie lautet, ob Ihr Institut noch erklären kann, warum einer aktiven Sitzung weiterhin vertraut wird.