Das SWIFT-Rahmenwerk für Kundensicherheitsmaßnahmen: Kryptografie im Korrespondenzbankgeschäft

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.

What is the SWIFT Customer Security Controls Framework?
The CSCF v2026 is the security baseline SWIFT publishes for every organization on its network. It defines 32 controls, 26 mandatory and 6 advisory, mapped to standards such as ISO 27002, PCI DSS, SOC 2, and NIST CSF. SWIFT updates it each year.

Who has to comply with the CSCF?
Compliance applies to all SWIFT users regardless of architecture type. Connectivity providers and outsourcing agents are covered by separate SWIFT programs, and attestation responsibility stays with the user, so cryptographic control has to be provable across the full connectivity chain.

What is Control 2.4?
Control 2.4, Back Office Data Flow Security, requires protecting financial messages, reconciliation files, and reference data. This data flows between the SWIFT Secure Zone and back-office or bridging systems. It has moved from advisory to mandatory, extending the framework beyond core secure infrastructure.

Why does Control 2.4 matter for cryptography?
It means cryptographic protection can no longer stop at SWIFT-branded components. Institutions must inventory data flows to back-office systems and demonstrate that data stays encrypted and authenticated wherever it travels.

What is KYC-SA attestation?
Know Your Customer Security Attestation (KYC-SA) is the annual process where each party records its CSCF compliance. It is validated through the Independent Assessment Framework, and assessors expect demonstrated evidence rather than policy statements alone.

How should institutions prepare for a SWIFT independent assessment?
Prepare evidence for the Control 2.4 data flow inventory, HSM and key custody, KYC-SA accuracy, independent assessment documentation, scope mapping for bridging servers and middleware, and signing verification. Keeping this evidence current shortens assessment.

How does the CSCF connect to post-quantum readiness?
Long-lived financial data sets the deadline for quantum-safe protection. SwiftNet is expected to become PQC-enabled around 2027, with a migration window measured in months. Building a cryptographic inventory now is the practical first step.

How can Keyfactor help with SWIFT compliance?
Keyfactor maps SWIFT cryptographic requirements to specific solutions: EJBCA for HSM-backed issuance and encryption, Keyfactor Command for control-mapped reporting and certificate lifecycle management, AgileSec for cryptographic inventory, and SignServer for signing SWIFT-related software and configuration.