Le cadre de référence SWIFT relatif aux contrôles de sécurité des clients : la cryptographie dans le cadre des relations de correspondance bancaire

Pour les institutions connectées au réseau SWIFT, la cryptographie est désormais un enjeu de gouvernance, et non plus seulement un détail technique. Le cadre de contrôle de sécurité des clients SWIFT (CSCF) lie désormais directement la gestion de vos clés, le chiffrement et la signature à la confiance que vos contreparties vous accordent.

Ce changement est important car chaque utilisateur du réseau SWIFT doit attester chaque année de son niveau de sécurité. Le statut de cette attestation est visible par les contreparties et les autorités de régulation ; ainsi, les contrôles insuffisants ou absents ne restent pas cantonnés à un rapport d'audit interne. L'absence d'attestation ou une non-conformité significative devient un facteur déterminant pour le maintien des relations de correspondance.

Ce guide explique les exigences du CSCF et pourquoi le contrôle 2.4 modifie le paysage cryptographique. Il montre ensuite comment les contrôles correspondent aux capacités cryptographiques et comment démontrer votre niveau de conformité.

Qu'est-ce que le cadre de contrôle de sécurité des clients SWIFT ?

Le cadre de contrôle de sécurité des clients SWIFT (SWIFT Customer Security Controls Framework, CSCF) constitue la norme de sécurité de référence que SWIFT publie à l’intention de toutes les organisations de son réseau. SWIFT publie une nouvelle version chaque année au mois de juillet. Les utilisateurs doivent attester de leur conformité à cette norme entre le 1er juillet et le 31 décembre de l’année suivante. La version CSCF v2026 a été publiée mi-2025 et régit la période d’attestation de 2026. Cela laisse aux institutions le temps de combler leurs lacunes avant l’ouverture de la période d’attestation.

Le référentiel actuel, le CSCFv2026, définit 32 mesures de contrôle : 26 obligatoires et 6 recommandées. Chaque mesure de contrôle est mise en correspondance avec des normes reconnues, notamment l'ISO 27002, la norme PCI DSS, la norme SOC 2 et le NIST CSF. Les équipes peuvent ainsi aligner leurs obligations SWIFT sur les programmes qu'elles mettent déjà en œuvre.

Le champ d'application va au-delà de la plateforme de messagerie elle-même. Les parties concernées sont les suivantes :

• Tous les utilisateurs SWIFT, quel que soit le type d'architecture, y compris ceux qui accèdent au réseau par l'intermédiaire d'un fournisseur de services.
• Les prestataires de services et les sous-traitants qui assurent la connectivité pour le compte de tiers.
• Entités du groupe soumises à une obligation commune de certification.

Chacune de ces parties a la responsabilité de certifier la validité de la transaction, c'est pourquoi le contrôle cryptographique doit pouvoir être vérifié sur l'ensemble de la chaîne de connectivité.

Le grand changement : la norme Control 2.4 passe d'une recommandation à une obligation

Le changement récent le plus important concerne la mesure de contrôle 2.4, « Sécurité des flux de données back-office », qui passe du statut de recommandation à celui d'obligation. À lui seul, ce changement étend le champ d'application du cadre bien au-delà de la « SWIFT Secure Zone ».

Configuration requise pour Control 2.4

La mesure de contrôle 2.4 s'applique selon le calendrier de mise en œuvre défini à l'annexe H. La couverture obligatoire dans la version v2026 inclut les serveurs relais entre la zone sécurisée et les premiers sauts du back-office, les flux entre les serveurs relais et la zone sécurisée qui ne sont pas protégés de bout en bout, ainsi que les nouveaux flux directs. Les échanges directs hérités restent à titre indicatif, SWIFT ayant indiqué une échéance provisoire fixée à 2028. Pour l'architecture de type B, la mesure de contrôle 2.4 n'est pas applicable.

La version 2026 de la norme CSCF rend également obligatoires les connecteurs client. Les API, les intergiciels et les clients de transfert de fichiers doivent désormais faire l'objet d'un mappage et d'une évaluation formels, ce qui peut faire passer un utilisateur du type d'architecture B au type A4. Pour de nombreuses organisations, cette portée élargie étend l'étendue des éléments qu'un évaluateur indépendant est censé examiner.

Pourquoi est-ce important pour la protection cryptographique ?

La protection cryptographique ne peut plus se limiter aux composants de messagerie de la marque SWIFT. Cette obligation s'applique désormais aux données elles-mêmes.

Les établissements doivent recenser les flux de données entre la « Secure Zone » et les systèmes de back-office. Ils doivent ensuite démontrer que les messages financiers, les fichiers de rapprochement et les données de référence restent protégés tout au long de leur parcours. Concrètement, cela signifie que le chiffrement et l'authentification s'étendent à un ensemble de systèmes internes bien plus large qu'auparavant.

Correspondance entre les exigences SWIFT et les contrôles cryptographiques

Ce cadre s'apparente à une politique, mais chaque obligation se traduit par une fonctionnalité cryptographique spécifique. En passant ainsi en revue les contrôles, on transforme des exigences abstraites en un plan de mise en œuvre.

Empêcher la compromission des identifiants

Le principe n° 4, « Prévenir la compromission des identifiants », couvre la politique relative aux mots de passe (4.1) et l'authentification multifactorielle (4.2). La génération et le stockage, assurés par la solution « Hardware », des clés et certificats liés à SWIFT correspondent au contrôle n° 5.2, « Gestion des jetons », de sorte que les clés privées ne soient jamais exposées sur des systèmes à usage général.

Mesure de contrôle n° 2.4 : chiffrement des flux de données du back-office

La norme Control 2.4 exige la confidentialité, l'intégrité et l'authenticité des données liées à SWIFT échangées entre les premiers relais back-office et les composants de l'infrastructure SWIFT. Cette protection s'applique lors de la circulation des données entre la zone sécurisée et les systèmes back-office ou de passerelle. Le chiffrement en transit, assuré par des certificats gérés, est le mécanisme qui permet de satisfaire à cette exigence.

Réduire la surface d'attaque et les vulnérabilités

Le principe n° 2, « Réduire la surface d'attaque et les vulnérabilités », vise à limiter l'exposition des composants concernés. Deux fonctionnalités cryptographiques assument l'essentiel de cette tâche :

• Une authentification par certificat qui réduit le recours aux identifiants statiques ou partagés.
• Les fichiers « software » et de configuration ont été signés et vérifiés avant le déploiement, ce qui permet de garantir leur intégrité.

Inventaire des actifs cryptographiques et des flux de données

À la base de tout ce qui précède se trouve un inventaire à jour des flux de données et des mécanismes cryptographiques qui protègent chacun d'entre eux. Cet inventaire constitue la pierre angulaire des éléments probants qu'un évaluateur indépendant s'attendra à voir.

La preuve : attestation KYC-SA et évaluation indépendante

Se conformer aux contrôles ne représente que la moitié du travail. Il faut également le prouver. L’attestation annuelle de sécurité « Know Your Customer » (KYC-SA) permet à chaque partie de consigner sa conformité. Le cadre d’évaluation indépendant sert à valider cette attestation. Depuis 2021, l’attestation doit s’appuyer sur une évaluation indépendante, interne ou externe, couvrant au moins l’ensemble des contrôles obligatoires applicables. L’auto-attestation seule ne suffit pas. La période d’attestation s’étend du 1er juillet au 31 décembre.

La distinction qui pose problème aux équipes réside dans la différence entre les preuves et les directives. Les évaluateurs examinent les preuves concrètes, et non pas uniquement les déclarations de principe. Une norme écrite stipulant que les flux de données sont chiffrés n'a que peu de poids si elle n'est pas étayée par des éléments concrets démontrant que cela est effectivement le cas.

Pour être prêt pour l'audit, préparez des réponses claires et des pièces justificatives pour des questions telles que :

• Votre inventaire des flux de données Control 2.4 et la manière dont il est tenu à jour.
• HSM et preuves relatives à la conservation des clés liées au réseau SWIFT.
• La conformité de votre attestation KYC-SA par rapport à la configuration réelle.
• Documentation relative à l'évaluation indépendante et décisions concernant le champ d'application.
• Mise en correspondance des périmètres du serveur et des intergiciels.
• Software et la vérification de la signature de la configuration.

Les établissements capables de fournir ces justificatifs sur simple demande passent plus rapidement les étapes de l'évaluation et obtiennent leur certification en toute confiance.

Perspectives d'avenir : préparation à l'ère post-quantique pour SwiftNet et les réseaux de correspondants

La conformité SWIFT souligne également la nécessité d'une transition post-quantique, car ce sont les données financières à longue durée de vie qui fixent la véritable échéance. Les messages et les données de référence enregistrés aujourd'hui pourraient encore présenter un caractère sensible lorsque fera son apparition un ordinateur quantique capable de contourner les systèmes de chiffrement actuels.

Le signal le plus important pour ce public est SwiftNet. SwiftNet devrait prendre en charge la cryptographie post-quantum (PQC) vers 2027, avec une période de migration qui se comptera en mois plutôt qu’en années. Avec plus de 11 500 établissements bancaires et de valeurs mobilières, infrastructures de marché et entreprises connectés, cette transition touche d’un seul coup l’ensemble de l’écosystème des correspondants.

Cette ampleur engendre un problème lié au « maillon faible ». Les établissements de plus petite taille qui prennent du retard dans la migration créent une exposition qu'un réseau de correspondants ne peut absorber sans heurts, car le risque se propage à tous les interlocuteurs avec lesquels ils échangent des messages. Commencer dès maintenant à dresser un inventaire cryptographique est le moyen le plus pragmatique de se préparer pour le moment où l'opportunité se présentera.

Comment Keyfactor vous aider

Chacune des obligations ci-dessus correspond à une capacité cryptographique, et le document « Keyfactor » établit un lien clair entre ces capacités, de l'exigence à la mise en œuvre.

• Keyfactor AgileSec met en place le flux de données et l'inventaire des actifs cryptographiques qui servent de base aux preuves des évaluateurs et à la planification post-quantique.
• EJBCA émet des clés et des certificats sécurisés par un HSM pour la protection des identifiants (Objectif 4) et crypte les flux de données du back-office (Contrôle 2.4).
• Keyfactor SignServer fichiers de signature software et de configuration pour les composants et les intergiciels liés à SWIFT.
• Keyfactor Command centralise la production de rapports qui associent les contrôles cryptographiques à des numéros de contrôle CSCF spécifiques à l'intention de l'évaluateur, et gère le cycle de vie des certificats dans le cadre du contrôle 2.4.

Ensemble, ces outils vous aident à vous conformer dès aujourd’hui aux exigences du CSCF et à vous préparer à la transition post-quantique vers SwiftNet qui s’annonce. Demander une démo Découvrez comment « Keyfactor » assure la conformité cryptographique SWIFT dans l’ensemble de votre environnement.

Vous avez des questions sur le cadre de contrôle de sécurité des clients SWIFT ? Nous avons les réponses.

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.