04/11/2025
Cybersecurity Insights
SWIFT CSP : Les évolutions du référentiel pour 2026
Comme chaque année, SWIFT actualise son standard CSCF et apporte son lot de nouveautés. Il peut s’avérer complexe pour les clients SWIFT de suivre ces évolutions et les impacts potentiels sur leur architecture. A ce titre, l’année 2026 s’annonce marquante avec des changements significatifs, notamment pour les clients SWIFT historiquement basés sur une architecture de type B.
Dans une logique proactive, nous vous proposons ici quelques clés de lecture associées aux changements fondamentaux apportés par le CSCF v2025 et v2026.
La fin annoncée des architectures de type B
La grande nouveauté du CSCF v2025 a été l’introduction du « customer client connector » et le changement d’architecture pour la grande majorité des clients SWIFT précédemment évalués sur la base d’une architecture de type B et dorénavant évalués sur la base d’une architecture de type A4 (avec quelques spécificités).
Si vous êtes dans ce cas, vous devriez déjà avoir constaté dans votre KYC SWIFT que votre architecture est désormais indiquée comme étant « A4 ». Les mesures à appliquer pour cette nouvelle architecture restent recommandées en 2025 et les clients SWIFT concernés peuvent choisir de s’évaluer sur la base d’une architecture de type B pour cette année, mais cela ne sera plus possible en 2026.
Qu'est ce que le customer client connector et quels sont ses impacts sur les architectures B ?
Défini pour la première fois dans le CSCF v2025, le customer client connector (ou CCC dans la suite de cet article) fait référence à un client de transfert de fichier, un middleware ou un composant consommant une API. Un CCC est utilisé par un client SWIFT pour se connecter à un fournisseur d’accès SWIFT (outsourcing agent, remote Group Hub, …).
Historiquement, les architectures de type B utilisaient dans la majorité des cas un client de transfert de fichiers afin de transmettre les messages contenant les transactions à un partenaire connecté à SWIFT (Diapason, CEGID, Kyriba, etc). Avant le CSCF v2025, les seuls composants considérés dans le périmètre de l’évaluation étaient les postes bureautiques du client SWIFT ainsi que l’interface de gestion des transactions mis à disposition par le partenaire.
Dorénavant et sur la base de la définition du CCC ci-dessus, si vous êtes client SWIFT et que vous disposez d’un client de transfert de fichiers vers votre partenaire, ce client est considéré comme votre CCC (voir schéma ci-dessous):
Afin de simplifier l’identification du CCC, vous pouvez considérer que le CCC correspond au premier composant sous votre responsabilité tel que vu par votre fournisseur d’accès à SWIFT.
Si vous avez un doute sur votre architecture ou sur les composants, n’hésitez pas à vous rapprocher de votre fournisseur d’accès à SWIFT. Les équipes ALMOND peuvent aussi vous accompagner dans l’identification des composants et des exigences applicables spécifiquement à votre contexte.
Vous pouvez également utiliser les schémas d’architecture fournis dans le CSCF SWIFT :
Il faut noter que certains clients qui étaient au préalable considérés comme architecture de type B le resteront. Il s’agit des clients qui n’ont pas d’échange applicatif avec leur fournisseur d’accès SWIFT et qui réalisent la totalité de leurs opérations SWIFT via une saisie manuelle des transactions dans une interface qui leur est mise à disposition. Ce cas particulier reste minoritaire car seulement envisageable lorsque le nombre d’opérations à réaliser est très faible.
Exigences applicables au customer client connector
Si vous faites partie des clients qui ont désormais un customer client connector, votre architecture évolue et vous devez vous évaluer sur la base d’une architecture de type A4. Cependant les mesures applicables à un CCC ne sont pas identiques à celles applicables à un customer connector (serveur de transfert de fichier).
Vous trouverez ci-dessous les mesures obligatoires (en vert) et recommandées (en orange) à appliquer sur un CCC en 2026:
Attention, dans le schéma ci-dessus vous trouverez uniquement les mesures applicables au CCC et qui pourraient globalement avoir un impact sur celui-ci. D’autres mesures peuvent s’appliquer de manière obligatoires ou recommandées à d’autres composants dans votre périmètre (postes bureautiques, serveurs bridging, …) ou à des processus connexes (vérifications à l’embauche, revues RMA, …).
Le passage en architecture de type A4 et l’intégration au périmètre du CCC a donc un fort impact pour les clients SWIFT précédemment en architecture de type B.
Notamment par :
- L’ajout au périmètre de nouveaux composants :
- L’applicatif du CCC
- Le serveur et la couche OS du CCC
- La couche de virtualisation ou le cloud qui héberge le CCC
- Les pares-feux chargés de protéger le CCC
- L’ajout de nouvelles mesures jusqu’alors non appliquées dans le cadre d’une architecture de type B :
- 1.2 : Contrôle des comptes OS à privilège
- 1.3 : Sécurité de la couche de virtualisation ou cloud
- 2.7 : Scan de vulnérabilité
A noter également que certains contrôles comme la 4.2 sur l’authentification multi facteur n’étaient applicables qu’à l’interface permettant d’effectuer les signatures des transactions SWIFT et que désormais ces contrôles vont également s’appliquer à la connexion au CCC et à la couche de virtualisation sous-jacente. Il est donc important de s’assurer en détail que l’ensemble des mesures sont bien appliquées sur ces nouveaux composants.
Ces changements étant parmi les plus importants depuis la création du CSCF, Almond recommande fortement à ses clients d’anticiper l’évaluation 2026 et propose une approche en deux temps (voir ci-dessous).
La mesure 2.4 a été délibérément omise de la liste ci-dessus et détaillée dans la suite de l’article. En effet, cette mesure préalablement recommandée s’appliquera de manière obligatoire en 2026 pour tous les types d’architecture.
Sécurité des flux de données Back-Office
Recommandées depuis maintenant plusieurs années, la mesure 2.4 devient officiellement obligatoire à partir de 2026.
A noter que cette mesure s’appliquera en deux temps, cette approche est détaillée dans l’annexe H du CSCF v2025 et v2026, dont nous allons faire la synthèse ci-après.
Afin d’expliciter la mesure 2.4, il est important de définir certains termes :
- Back Office : Systèmes responsables de la logique métier et de la génération des transactions.
- Serveurs Bridging : Serveurs de transfert de fichiers ou autre middleware utilisés pour l’échange de données entre les systèmes Back Office et les composants SWIFT.
Il est parfois difficile d’identifier clairement les serveurs bridging qui n’apparaissent pas forcément sur les diagrammes fonctionnels. Vous trouverez ci-dessous un schéma de base permettant de faciliter votre compréhension des composants du périmètre.
Le schéma ci-dessous se base sur une architecture A4 avec un customer client connector, mais vous pouvez remplacer ce customer client connector par votre zone sécurisée SWIFT pour les architectures de type A4 avec customer connector et pour les autres types d’architecture qui disposent d’une telle zone (A3, A2 et A1) :
Progressivement et à partir de 2026, la mesure 2.4 nécessite :
- De mettre en place du chiffrement de données de bout en bout entre les systèmes Back Office et les composants SWIFT et d’assurer ainsi:
- Le non rejeu des messages SWIFT
- L’authentification des deux parties (Back Office et composant SWIFT)
- La confidentialité et l’intégrité des messages SWIFT
- OU si le chiffrement des données n’est pas en place :
- d’ajouter dans le périmètre les serveurs bridging sur l’ensemble des exigences applicables
- de sécuriser l’ensemble des nouveaux flux entre les systèmes Back Office, les serveurs bridging et les composants SWIFT (protocoles sécurisés, algorithmes robustes, …)
- De formaliser un plan de sécurisation des flux historiques d’ici 2028
L'approche d'Almond
Almond réalise des évaluations de conformité SWIFT CSP depuis leur mise en place en 2021 et accompagne ses clients aux évolutions du standard chaque année depuis.
Afin de préparer au mieux les clients SWIFT, Almond propose la mise à disposition d’experts SWIFT certifiés disposant des connaissances nécessaires pour identifier le périmètre ainsi que les mesures applicables.
2026 s’annonce comme une année forte en termes de changements et comme toujours, Almond prône l’anticipation via une méthodologie d’évaluation en deux étapes :
- Une évaluation à blanc dès janvier ou février 2026 permettant d’obtenir la visibilité sur le périmètre, le niveau de conformité avec le CSCF v2026 et de démarrer la collecte de preuves ou d’éventuelles remédiations si des non conformités sont constatées;
- Une évaluation finale planifiée dès que les éléments de preuves et les actions de remédiations sont prêts. Souvent plus légère que l’évaluation à blanc si celle-ci a déjà été réalisée, car les évaluateurs se baseront en partie sur les constats réalisés lors de l’évaluation à blanc.
À noter que de nombreux clients SWIFT restent persuadés qu’ils doivent attendre juillet de l’année en cours pour réaliser l’évaluation indépendante SWIFT. Il est vrai que le KYC n’ouvre qu’à partir de juillet mais il est tout à fait possible d’attester de sa conformité en juillet sur la base d’une évaluation réalisée dès janvier et sur la base de la version CSCF de l’année en cours, et ce tant qu’aucun changement majeur n’a eu lieu entre temps.
N’hésitez donc pas à nous contacter dès le début d’année afin de planifier votre évaluation.
Conclusion
Le CSCF est un framework complet, reprenant des exigences connues et éprouvées dans d’autres référentiels, permettant aux RSSI et à leurs équipes de traiter ces sujets de manière transverse, et non pas seulement pour se mettre en conformité avec le CSP. D’autres mesures sont en revanche orientées SWIFT, avec leurs spécificités, afin de répondre au mieux aux différents risques identifiés pour chaque thème de la sécurité.
Le CSP n’est donc pas une contrainte, il s’agit d’un recueil de bonnes pratiques issu de différents référentiels et standards en la matière. La plupart de ces mesures sont déjà mises en place par les clients avant même de commencer l’évaluation, car la gouvernance de la sécurité impose de les considérer dans la politique de l’entreprise.
Des nouveautés font leur apparition chaque année, qu’il faut analyser et considérer au cas par cas, selon son contexte et une étude d’opportunité doit logiquement en découler. Ces dispositions doivent être considérées afin de mettre toutes les chances de son côté dans le cadre de la réalisation des activités relatives à l’évaluation CSP. L’objectif principal de SWIFT à travers cette démarche est de promouvoir les actions permettant de gagner en maturité sur le thème de la cybersécurité, mais également de générer et maintenir la confiance entre toutes les parties prenantes de la chaîne d’utilisateurs et de prestataires utilisant des services fournis par SWIFT.
Lors des évaluations 2025, Almond a pu constater que de nombreux clients SWIFT n’étaient pas préparés à l’application des mesures et/ou à la fourniture d’éléments de preuve sur les composants apparaissant dans le périmètre SWIFT de cette année (customer client connector ou serveurs bridging).
Comme toujours l’anticipation est le maître mot et Almond encourage l’ensemble des clients SWIFT à analyser leur périmètre en amont de l’évaluation indépendante annuelle ou de réaliser une évaluation à blanc afin d’identifier les écarts.
Avec ces évolutions, il apparaît clairement que SWIFT cherche à étendre petit à petit le périmètre couvert par les mesures de sécurité. Bien que pertinent d’un point de vue sécurité, ces changements peuvent avoir un fort impact pour les clients SWIFT, notamment ceux disposant de peu de ressources IT et Sécurité.
Almond se positionne en conseil pour ces clients afin de réduire le périmètre et de trouver des solutions innovantes leur permettant de traiter les risques.
