Für Institutionen, die an das SWIFT-Netzwerk angeschlossen sind, ist Kryptografie mittlerweile nicht mehr nur ein technisches Detail, sondern ein Thema der Unternehmensführung. Das SWIFT Customer Security Controls Framework (CSCF) verknüpft nun Ihre Schlüsselverwaltung, Verschlüsselung und Signatur direkt mit dem Vertrauen, das Ihre Geschäftspartner in Sie setzen.
Diese Veränderung ist von Bedeutung, da jeder SWIFT-Nutzer jährlich seine Sicherheitslage bestätigen muss. Der Status dieser Bestätigung ist für Geschäftspartner und Aufsichtsbehörden einsehbar, sodass schwache oder fehlende Kontrollmechanismen nicht in einem internen Prüfungsbericht verborgen bleiben. Eine unterlassene Bestätigung oder eine wesentliche Nichteinhaltung der Vorschriften wird zu einem Faktor, der darüber entscheidet, ob Korrespondenzbankbeziehungen fortgeführt werden.
In diesem Leitfaden wird erläutert, welche Anforderungen der CSCF stellt und warum die Kontrollmaßnahme 2.4 die kryptografische Landschaft verändert. Anschließend wird aufgezeigt, wie die Kontrollmaßnahmen den kryptografischen Funktionen zugeordnet sind und wie Sie Ihre Sicherheitslage nachweisen können.
Was ist das SWIFT-Rahmenwerk für Kundensicherheitskontrollen?
Das SWIFT Customer Security Controls Framework (CSCF) ist die Sicherheitsgrundlage, die SWIFT für jede Organisation in seinem Netzwerk veröffentlicht. SWIFT veröffentlicht jedes Jahr im Juli eine neue Version. Die Nutzer legen zwischen dem 1. Juli und dem 31. Dezember des folgenden Jahres eine Bescheinigung darüber vor. CSCF v2026 wurde Mitte 2025 veröffentlicht und gilt für das Bescheinigungsfenster 2026. Dies gibt den Instituten Zeit, etwaige Lücken zu schließen, bevor das Bescheinigungsfenster beginnt.
Das aktuelle Rahmenwerk, CSCFv2026, definiert 32 Kontrollmaßnahmen: 26 verbindliche und 6 empfohlene. Jede Kontrollmaßnahme ist anerkannten Standards zugeordnet, darunter ISO 27002, PCI DSS, SOC 2 und NIST CSF. Teams können die SWIFT-Verpflichtungen mit den Programmen abstimmen, die sie bereits durchführen.
Der Geltungsbereich erstreckt sich über die Messaging-Plattform selbst hinaus. Zu den betroffenen Parteien gehören:
- Alle SWIFT-Nutzer, unabhängig von der Art der Architektur, einschließlich derjenigen, die über einen Dienstanbieter Zugang zum Netzwerk haben.
- Dienstleistungsunternehmen und Outsourcing-Anbieter, die im Auftrag Dritter die Netzanbindung betreiben.
- Konzerngesellschaften, die einer gemeinsamen Bescheinigungspflicht unterliegen.
Jede dieser Parteien trägt ihre eigene Verantwortung für die Bestätigung, weshalb die kryptografische Kontrolle über die gesamte Verbindungskette hinweg nachweisbar sein muss.
Die große Änderung: Die Vorschrift 2.4 wird von einer Empfehlung zu einer verbindlichen Vorschrift
Die bedeutendste Änderung der letzten Zeit ist die Kontrollmaßnahme 2.4, „Sicherheit des Datenflusses im Backoffice“, die nun nicht mehr nur als Empfehlung, sondern als verbindliche Vorschrift gilt. Diese einzelne Änderung erweitert den Anwendungsbereich des Rahmenwerks weit über die SWIFT Secure Zone hinaus.
Was Control 2.4 benötigt
Kontrolle 2.4 wendet den in Anhang H dargelegten stufenweisen Geltungsbereich an. Der verbindliche Geltungsbereich in Version 2026 umfasst Brückenserver zwischen der sicheren Zone und den ersten Hops im Backoffice, Datenströme zwischen Brückenservern und der sicheren Zone, die nicht durchgehend geschützt sind, sowie neue direkte Datenströme. Für bestehende direkte Datenaustausche gilt weiterhin eine Empfehlung, wobei SWIFT vorläufig das Jahr 2028 als Meilenstein angibt. Für die Architekturtyp B findet Kontrolle 2.4 keine Anwendung.
Mit CSCF v2026 werden auch Kunden-Client-Konnektoren in den verbindlichen Anwendungsbereich aufgenommen. APIs, Middleware und Dateiübertragungs-Clients erfordern nun eine formale Zuordnung und Bewertung, wodurch ein Nutzer vom Architekturtyp B zum Typ A4 wechseln kann. Für viele Organisationen bedeutet dieser erweiterte Anwendungsbereich, dass ein unabhängiger Prüfer nun einen größeren Umfang an Aspekten begutachten muss.
Warum dies für den kryptografischen Schutz wichtig ist
Der kryptografische Schutz darf sich nicht mehr nur auf die SWIFT-eigenen Nachrichtenkomponenten beschränken. Die Verpflichtung gilt nun für die Daten selbst.
Die Institute müssen die Datenflüsse zwischen der Secure Zone und den Backoffice-Systemen erfassen. Anschließend müssen sie nachweisen, dass Finanznachrichten, Abgleichdateien und Referenzdaten auf ihrem gesamten Weg geschützt bleiben. In der Praxis bedeutet dies, dass Verschlüsselung und authentifizierte Identitätsprüfung auf einen wesentlich größeren Kreis interner Systeme als bisher ausgedehnt werden.
Wie sich die SWIFT-Anforderungen auf kryptografische Kontrollmaßnahmen abbilden lassen
Das Rahmenwerk ist zwar als Richtlinie formuliert, doch jede Verpflichtung lässt sich auf eine bestimmte kryptografische Funktion zurückführen. Durch diese schrittweise Betrachtung der Kontrollmaßnahmen werden abstrakte Anforderungen in einen Umsetzungsplan umgewandelt.
Verhindern Sie den Missbrauch von Zugangsdaten
Grundsatz 4, „Verhinderung der Kompromittierung von Zugangsdaten“, umfasst die Passwortrichtlinie (4.1) und die Multi-Faktor-Authentifizierung (4.2). Die auf dem „ Hardware “ basierende Generierung und Speicherung von SWIFT-bezogenen Schlüsseln und Zertifikaten entspricht der Kontrollmaßnahme 5.2, „Token-Management“, sodass private Schlüssel niemals ungeschützt auf Allzwecksystemen liegen.
Kontrollmaßnahme 2.4: Verschlüsselung des Datenflusses im Backoffice
Die Vorschrift 2.4 schreibt die Vertraulichkeit, Integrität und Authentizität der SWIFT-bezogenen Daten vor, die zwischen den „First Hops“ im Backoffice und den Komponenten der SWIFT-Infrastruktur ausgetauscht werden. Dieser Schutz gilt für den Datenfluss zwischen der Secure Zone und den Backoffice- oder Brückensystemen. Dies wird durch eine Verschlüsselung während der Übertragung gewährleistet, die auf verwalteten Zertifikaten basiert.
Angriffsfläche und Schwachstellen reduzieren
Prinzip 2, „Angriffsfläche und Schwachstellen reduzieren“, zielt darauf ab, die Gefährdung aller betroffenen Komponenten zu verringern. Zwei kryptografische Funktionen übernehmen dabei den Großteil der Arbeit:
- Zertifikatsbasierte Authentifizierung, die die Abhängigkeit von statischen oder gemeinsam genutzten Anmeldedaten verringert.
- software - und Konfigurationsdateien wurden vor der Bereitstellung signiert und überprüft, sodass ihre Integrität nachweisbar ist.
Bestandsaufnahme der kryptografischen Vermögenswerte und Datenflüsse
All dem liegt eine aktuelle Bestandsaufnahme der Datenströme und der jeweiligen kryptografischen Schutzmechanismen zugrunde. Diese Bestandsaufnahme bildet das Rückgrat der Nachweise, deren Vorlage ein unabhängiger Gutachter erwarten wird.
Der Nachweis: KYC-SA-Bescheinigung und unabhängige Bewertung
Die Einhaltung der Kontrollmaßnahmen ist nur die halbe Miete. Man muss dies auch nachweisen. Mit der jährlichen „Know Your Customer Security Attestation“ (KYC-SA) dokumentiert jede Partei ihre Compliance. Das „Independent Assessment Framework“ dient der Validierung dieser Bescheinigung. Seit 2021 muss die Bescheinigung durch eine unabhängige interne oder externe Bewertung untermauert werden, die mindestens alle anwendbaren obligatorischen Kontrollmaßnahmen abdeckt. Eine Selbstbescheinigung allein reicht nicht aus. Der Zeitraum läuft vom 1. Juli bis zum 31. Dezember.
Der Unterschied, der viele Teams ins Straucheln bringt, ist der zwischen Belegen und Richtlinien. Gutachter prüfen nachgewiesene Belege und nicht nur bloße Richtlinienerklärungen. Eine schriftliche Vorgabe, wonach Datenflüsse verschlüsselt werden müssen, hat kaum Gewicht, wenn keine Belege vorliegen, die dies in der Praxis belegen.
Um für eine Prüfung gerüstet zu sein, sollten Sie klare Antworten und Belege für Fragen wie die folgenden vorbereiten:
- Ihr Control 2.4-Datenflussverzeichnis und wie es auf dem neuesten Stand gehalten wird.
- HSM und Nachweise zur Schlüsselverwahrung für SWIFT-bezogene Schlüssel.
- Die Übereinstimmung Ihrer KYC-SA-Bescheinigung mit der tatsächlichen Konfiguration.
- Dokumentation unabhängiger Bewertungen und Festlegung des Umfangs.
- Abbildung der Zuständigkeitsbereiche von Servern und Middleware.
- Software sowie die Überprüfung der Signatur der Konfiguration.
Einrichtungen, die diese Nachweise auf Anfrage vorlegen können, durchlaufen das Bewertungsverfahren schneller und können ihre Qualitäten mit Zuversicht bestätigen.
Ausblick: Post-Quanten-Tauglichkeit für SwiftNet und Korrespondentennetzwerke
Die SWIFT-Compliance weist ebenfalls auf den Übergang in die Post-Quanten-Ära hin, da langlebige Finanzdaten die eigentliche Frist vorgeben. Nachrichten und Referenzdaten, die heute erfasst werden, könnten auch dann noch sensibel sein, wenn ein kryptografisch relevanter Quantencomputer auf den Markt kommt.
Das für diese Zielgruppe wichtigste Signal ist SwiftNet. Es wird erwartet, dass SwiftNet etwa im Jahr 2027 PQC-fähig sein wird, wobei das Migrationsfenster eher in Monaten als in Jahren gemessen wird. Mit mehr als 11.500 angeschlossenen Banken und Wertpapierhäusern, Marktinfrastrukturen und Unternehmen betrifft dieser Übergang das gesamte Korrespondenzbankensystem auf einen Schlag.
Diese Größenordnung führt zu einem Problem, bei dem das schwächste Glied die Schwachstelle darstellt. Kleinere Institute, die bei der Umstellung hinterherhinken, verursachen Risiken, die ein Korrespondenznetzwerk nicht unbemerkt auffangen kann, da sich das Risiko auf alle Partner ausbreitet, mit denen sie Nachrichten austauschen. Jetzt mit einer Bestandsaufnahme der kryptografischen Infrastruktur zu beginnen, ist der praktikable Weg, um bereit zu sein, wenn sich die Gelegenheit bietet.
Wie Keyfactor helfen Keyfactor
Jede der oben genannten Anforderungen lässt sich auf eine kryptografische Funktion zurückführen, und „ Keyfactor “ ordnet diesen Funktionen einen klaren Weg von der Anforderung bis zur Umsetzung zu.
- Keyfactor AgileSec erstellt den Datenfluss und das Inventar der kryptografischen Ressourcen, die als Grundlage für die Nachweise der Gutachter und die Post-Quantum-Planung dienen.
- EJBCA stellt HSM-gesicherte Schlüssel und Zertifikate zum Schutz von Zugangsdaten aus (Ziel 4) und verschlüsselt den Datenverkehr im Backoffice (Kontrollmaßnahme 2.4).
- Keyfactor SignServersoftware -Dateien und Konfigurationsdateien für SWIFT-bezogene Komponenten und Middleware.
- Keyfactor Command zentralisiert die Berichterstattung, in der kryptografische Kontrollmaßnahmen bestimmten CSCF-Kontrollnummern für den Prüfer zugeordnet werden, und verwaltet den Zertifikatslebenszyklus im Rahmen von Kontrolle 2.4.
Gemeinsam helfen Ihnen diese Tools dabei, die CSCF-Anforderungen bereits heute zu erfüllen und sich auf den bevorstehenden Übergang zu SwiftNet im Post-Quanten-Zeitalter vorzubereiten. Fordern Sie eine Demo an, um zu erfahren, wie „ Keyfactor “ die Einhaltung der SWIFT-Kryptografie-Vorgaben in Ihrer gesamten Umgebung unterstützt.
Haben Sie Fragen zum SWIFT-Rahmenwerk für Kundensicherheitskontrollen? Wir haben die Antworten.
Was ist das SWIFT Customer Security Controls Framework?
Das CSCF v2026 ist die Sicherheitsgrundlage, die SWIFT für jede Organisation in seinem Netzwerk veröffentlicht. Es definiert 32 Kontrollmaßnahmen – 26 verbindliche und 6 empfohlene –, die auf Standards wie ISO 27002, PCI DSS, SOC 2 und NIST CSF abgestimmt sind. SWIFT aktualisiert es jedes Jahr.
Wer muss die CSCF-Anforderungen erfüllen?
Die Einhaltung der Anforderungengilt für alle SWIFT-Nutzer, unabhängig von der Art der Architektur. Konnektivitätsanbieter und Outsourcing-Dienstleister fallen unter separate SWIFT-Programme, wobei die Verantwortung für die Bescheinigung beim Nutzer verbleibt, sodass die kryptografische Kontrolle über die gesamte Konnektivitätskette nachweisbar sein muss.
Was ist Control 2.4?
Control 2.4, „Back-Office-Datenflusssicherheit“, schreibt den Schutz von Finanznachrichten, Abgleichsdateien und Referenzdaten vor. Diese Daten fließen zwischen der SWIFT Secure Zone und Back-Office- oder Brückensystemen. Die Vorschrift hat sich von einer Empfehlung zu einer verbindlichen Vorgabe entwickelt und erweitert den Rahmen über die sichere Kerninfrastruktur hinaus.
Warum ist Control 2.4 für die Kryptografie von Bedeutung?
Das bedeutet, dass der kryptografische Schutz nicht mehr auf Komponenten der Marke SWIFT beschränkt sein darf. Institutionen müssen Datenflüsse zu Backoffice-Systemen erfassen und nachweisen, dass die Daten auf ihrem gesamten Weg verschlüsselt und authentifiziert bleiben.
Was ist die KYC-SA-Bescheinigung?
Die „Know Your Customer Security Attestation“ (KYC-SA) ist das jährliche Verfahren, bei dem jede Partei ihre Einhaltung der CSCF-Vorgaben dokumentiert. Die Validierung erfolgt im Rahmen des „Independent Assessment Framework“, wobei die Prüfer nachweisbare Belege und nicht nur bloße Grundsatzerklärungen erwarten.
Wie sollten sich Institute auf eine unabhängige SWIFT-Prüfung vorbereiten?
Bereiten Sie Nachweise für das Datenflussverzeichnis gemäß Kontrolle 2.4, HSM und Schlüsselverwahrung, die Richtigkeit der KYC-SA-Daten, die Dokumentation der unabhängigen Prüfung, die Erfassung des Anwendungsbereichs für Brückenserver und Middleware sowie die Überprüfung der Signatur vor. Wenn Sie diese Nachweise auf dem neuesten Stand halten, verkürzt sich die Dauer der Prüfung.
Inwiefern steht das CSCF im Zusammenhang mit der Post-Quanten-Bereitschaft?
Langlebige Finanzdaten setzen die Frist für einen quantensicheren Schutz. SwiftNet wird voraussichtlich um das Jahr 2027 herum PQC-fähig sein, wobei das Migrationsfenster mehrere Monate betragen wird. Der Aufbau eines kryptografischen Bestands ist nun der erste praktische Schritt.
Wie kann „ Keyfactor “ bei der Einhaltung der SWIFT-Vorgaben helfen?
„Keyfactor “ ordnet die kryptografischen Anforderungen von SWIFT bestimmten Lösungen zu: EJBCA für die HSM-gestützte Ausstellung und Verschlüsselung, Keyfactor Command für die kontrollbasierte Berichterstattung und das Zertifikatslebenszyklusmanagement, AgileSec für das kryptografische Inventar und SignServer für die Signierung von SWIFT-bezogenen software und Konfigurationen.
