Un cadre de référence qui continue de monter en exigence
Le réseau SWIFT occupe une position centrale dans les chaînes de paiement interbancaire, les opérations sur titres et la messagerie financière. Cette centralité en fait aussi une cible privilégiée. C’est pour répondre à ce risque que SWIFT a lancé, en 2016, son Customer Security Programme (CSP), à la suite d’une série d’attaques de grande ampleur visant des établissements connectés au réseau.
Au cœur de ce programme figure le Customer Security Controls Framework (CSCF) : un socle de contrôles de sécurité, obligatoires et recommandés, que chaque utilisateur SWIFT doit mettre en œuvre selon sa configuration. Le CSCF est révisé chaque année pour suivre l’évolution des menaces. La version 2026, publiée par SWIFT en juillet 2025, constitue la base de référence applicable pour le cycle d’attestation en cours.
Cet article propose une lecture sécurité et gouvernance du CSCF v2026 : sa structure, son caractère obligatoire, les changements introduits cette année, et leur articulation avec les enjeux actuels de fraude, de compromission d’accès et de résilience opérationnelle.
Le CSCF, socle du Customer Security Programme
Le CSCF ne se limite pas à une liste de mesures techniques. Il s’organise autour de trois objectifs de sécurité : sécuriser son environnement, connaître et limiter les accès, détecter et réagir. Ces objectifs se déclinent en sept principes de sécurité, eux-mêmes traduits en contrôles précis.
Les sept principes couvrent la restriction des accès Internet et la protection des systèmes critiques vis-à-vis de l’environnement IT général, la réduction de la surface d’attaque et des vulnérabilités, la sécurisation physique de l’environnement, la prévention de la compromission des identifiants, la gestion des identités et la séparation des privilèges, la détection des activités anormales sur les systèmes ou les enregistrements de transactions, et enfin la planification de la réponse aux incidents et le partage d’informations.
Les contrôles du CSCF s’appuient sur des standards internationaux reconnus, notamment NIST, ISO 27000 et PCI DSS. Chaque contrôle documente les risques qu’il vise à réduire, comme la soumission ou la modification non autorisée de transactions métier, ou le traitement de messages entrants altérés ou non autorisés.
Un cadre obligatoire, pas une bonne pratique optionnelle
Le point le plus important pour les établissements concernés est que le CSP est un dispositif obligatoire, et non un simple guide de bonnes pratiques. SWIFT indique que chaque utilisateur doit soumettre une attestation de sécurité annuelle confirmant son niveau de conformité aux contrôles obligatoires.
Cette attestation s’effectue via l’application KYC-Security Attestation (KYC-SA). Elle doit être soumise chaque année entre juillet et décembre, au plus tard le 31 décembre, puis renouvelée au moins une fois par an. Une nouvelle version des contrôles est mise à disposition dans l’application au début du mois de juillet. Les nouveaux entrants doivent attester avant leur mise en production sur le réseau.
Depuis 2021, l’attestation ne repose plus sur une simple auto-déclaration : elle doit être appuyée par une évaluation indépendante. SWIFT précise qu’une auto-évaluation réalisée sans revue indépendante est considérée comme non conforme dans l’application KYC-SA.
Les conséquences d’un défaut d’attestation ou de conformité ne sont pas seulement internes. Les résultats d’attestation sont visibles par les contreparties, lorsque l’accès est accordé, et par les superviseurs, via les applications KYC-SA et KYS. SWIFT se réserve le droit de signaler aux autorités de supervision les utilisateurs n’ayant pas attesté leur conformité à l’ensemble des contrôles obligatoires. En pratique, le statut de conformité influence donc directement les relations de correspondant bancaire.
Types d’architecture et périmètre applicable
Tous les utilisateurs SWIFT ne sont pas soumis au même périmètre de contrôles. Le CSCF distingue plusieurs types d’architecture, désignés A1, A2, A3, A4 et B, qui déterminent quels contrôles s’appliquent.
Les architectures A1 et A2 correspondent à des établissements exploitant leur propre interface de messagerie SWIFT — par exemple Alliance Access ou Alliance Lite2 — sur site : l’ensemble des contrôles obligatoires leur est applicable. Les architectures A3 et A4 concernent des configurations recourant à des connecteurs ou à des prestataires, avec un partage de responsabilités. L’architecture B correspond à l’absence de composant d’infrastructure SWIFT spécifique dans l’environnement de l’utilisateur.
Un point mérite d’être souligné : même lorsqu’un établissement s’appuie sur un prestataire (service bureau) pour sa connectivité, il reste responsable de sa propre attestation. Le recours à un tiers ne transfère pas la responsabilité de conformité.
Ce que change la version 2026 : vue d’ensemble
La version 2026 n’est pas une refonte du cadre. Elle s’inscrit dans une logique d’évolution incrémentale, mais introduit un changement structurant et plusieurs ajustements significatifs. Le CSCF v2026 comprend 32 contrôles, dont 26 obligatoires et 6 recommandés, l’un des contrôles auparavant recommandés passant en statut obligatoire.
La logique d’ensemble de cette version est claire : étendre la sécurité au-delà de la « secure zone » SWIFT, vers les couches d’intégration, les flux internes et les systèmes back-office. Les incidents récents ciblant de plus en plus les couches d’intégration et les flux de données internes plutôt que les seules plateformes de messagerie, le cadre cherche à couvrir l’ensemble du cycle de vie de la transaction, et non uniquement le périmètre.
Le changement structurant : le contrôle 2.4 devient obligatoire
Le changement le plus marquant du cycle 2026 est le passage du contrôle 2.4 (Back Office Data Flow Security) du statut recommandé au statut obligatoire. Ce basculement avait été annoncé à l’avance par SWIFT.
L’objectif de ce contrôle est d’assurer la confidentialité, l’intégrité et l’authenticité des données échangées entre les premiers points de contact du back-office (« first hops ») et les composants de l’infrastructure SWIFT, que ce soit dans des environnements sur site ou distants. Il vise à protéger contre les attaques de type « man-in-the-middle », les fuites ou altérations de données, et les accès non autorisés aux données en transit.
Concrètement, cette évolution étend le périmètre du CSCF au-delà de la seule zone sécurisée, vers les middlewares, les intégrations et les transferts de fichiers. Pour les architectures de type B, ce contrôle devient sans objet. Pour les autres, il impose de sécuriser des flux qui, historiquement, faisaient souvent l’objet d’une confiance implicite.
Connecteurs clients et reclassement possible en A4
La version 2026 rend obligatoire dans le périmètre la notion de « customer client connector ». Sont concernés les points terminaux qui se connectent indirectement à SWIFT via des prestataires : middlewares, consommateurs d’API, clients de transfert de fichiers.
Cette évolution a une conséquence pratique importante. Les définitions d’architecture sont adaptées de sorte que les ressources fournies par un prestataire entrent dans la définition d’une connexion de système à système. Un établissement qui utilise un connecteur client peut ainsi devoir être reclassé de l’architecture de type B vers le type A4. Ce reclassement élargit le périmètre d’évaluation et implique de nouvelles équipes et de nouveaux composants dans l’exercice d’attestation.
Ce point illustre une tendance de fond du CSCF : la prise en compte croissante des dépendances vis-à-vis des tiers, y compris lorsqu’ils n’exploitent pas directement l’infrastructure SWIFT de l’utilisateur.
Renforcement des exigences cryptographiques
La version 2026 précise et durcit plusieurs exigences cryptographiques. Elle introduit des tailles de clés minimales et de nouvelles exigences sur les algorithmes de chiffrement. De nouvelles exigences portent également sur les certificats PKI et les algorithmes de clés.
Deux points concrets ressortent pour les équipes techniques : le protocole TLS doit désormais être en version 1.2 ou supérieure, et SSH doit utiliser SSH2. Ces exigences visent à éliminer des protocoles et paramètres devenus insuffisants au regard de l’état de l’art.
Durcissement des systèmes et réduction de la surface d’attaque
Plusieurs évolutions renforcent le durcissement des systèmes. Pour le contrôle 2.3, le durcissement des machines Windows impose désormais de restreindre Windows Management Instrumentation (WMI) et PowerShell, deux composants fréquemment détournés lors d’attaques.
D’autres ajustements complètent ce volet. Lorsque cela est techniquement possible, les systèmes non-Windows situés dans une zone sécurisée ou hébergeant un connecteur client doivent disposer d’une protection anti-malware. Concernant la conteneurisation (contrôle 1.3), les conteneurs sont par défaut considérés comme co-hébergés, l’isolation restant acceptable si elle est justifiée par une analyse de risque. Enfin, les modules matériels de sécurité (HSM) de type Luna backup device entrent dans le périmètre des contrôles 3.1 et 5.4.
Le contrôle 2.9 peut par ailleurs désormais être satisfait en s’appuyant sur les données de SWIFT Universal Confirmation.
Sensibilisation, deepfakes et tests d’intrusion
La version 2026 fait évoluer deux contrôles liés au facteur humain et à la vérification de la sécurité. Pour le contrôle 7.2, la formation de sensibilisation à la sécurité doit désormais intégrer une sensibilisation aux technologies de deepfake, en complément des dispositifs existants. Cette évolution reflète la montée des risques de fraude reposant sur l’usurpation d’identité par synthèse audio ou vidéo.
Pour le contrôle 7.3A, SWIFT fournit désormais des indications sur le périmètre et les scénarios des tests d’intrusion. Trois scénarios sont proposés, qui doivent être couverts au cours d’un cycle de tests d’intrusion de trois ans. Cette précision oriente les tests vers des cas d’usage plus représentatifs des menaces réelles, plutôt que vers un exercice ponctuel et générique.
Cloud, virtualisation et reconnaissance des risques liés à l’IA
La version 2026 accompagne la modernisation des environnements de connectivité et d’hébergement. L’annexe G intègre de nouveaux schémas illustrant les modèles de responsabilité partagée pour les environnements cloud, en cohérence avec les pratiques de gouvernance IaaS et SaaS.
Sur le plan de la connectivité, SWIFT introduit une solution de VPN virtuel déployée sur la machine virtuelle du client (Alliance Connect Virtual on Premises), explicitement incluse dans le périmètre de plusieurs contrôles, dans le cadre d’une transition plus large vers des technologies SD-WAN prévue entre 2026 et 2028. Par ailleurs, certaines briques d’intégration comme Alliance Access Integration Platform (IPLA) et Swift Integration Layer (SIL) arrivent en fin de vie en 2026, tout en restant dans le périmètre jusqu’à cette échéance.
Enfin, sans imposer d’exigences spécifiques aux outils fondés sur l’IA, la version 2026 reconnaît formellement les risques associés. Les établissements utilisant l’IA à des fins de conformité, de supervision ou d’exploitation doivent appliquer les mêmes standards de confidentialité, d’intégrité et de disponibilité que pour les systèmes traditionnels.
Attestation et évaluation indépendante : le cœur du dispositif
Au-delà des contrôles techniques, la valeur du CSCF repose sur son mécanisme d’attestation. SWIFT organise la conformité autour d’un parcours en plusieurs étapes : comprendre les contrôles applicables, les mettre en œuvre, réaliser une évaluation indépendante, soumettre l’attestation, puis exploiter et partager les données CSP.
L’évaluation indépendante peut être réalisée en interne, par une fonction indépendante de la première ligne de défense (audit interne, risque, conformité), ou en externe, par un prestataire d’évaluation. Le cadre d’évaluation indépendante (Independent Assessment Framework, IAF) prévoit une « Community Standard Assessment » pour l’ensemble des utilisateurs. Le nom du département interne ou de la société externe ayant réalisé l’évaluation doit obligatoirement figurer dans l’attestation.
SWIFT propose un programme de certification des évaluateurs afin d’harmoniser les pratiques, tout en laissant la possibilité de recourir à des évaluateurs non certifiés disposant d’une expérience reconnue sur des standards tels que PCI DSS, ISO 27002 ou NIST. Dans certains cas, SWIFT peut exiger d’un établissement une évaluation externe spécifique afin de vérifier l’exactitude de son attestation.
Une évaluation antérieure peut, sous conditions, être réutilisée lors d’un nouveau cycle : l’évaluateur doit accepter de s’y référer, le périmètre SWIFT évalué ne doit pas avoir connu de changement significatif invalidant les conclusions précédentes, et la nouvelle version du CSCF ne doit pas introduire de contrôles obligatoires ou de modifications non couverts précédemment. Cette dernière condition est directement pertinente en 2026, compte tenu du passage du contrôle 2.4 en obligatoire.
Articulation avec les enjeux actuels : fraude, accès et résilience
La logique du CSCF v2026 recoupe plusieurs préoccupations majeures du secteur financier.
Sur la fraude, le renforcement des contrôles sur les flux back-office, la cryptographie et la détection d’anomalies vise directement à réduire les possibilités de soumission ou de modification frauduleuse de transactions sur des chaînes de paiement sensibles.
Sur la compromission d’accès, l’accent mis sur la gestion des identités, la séparation des privilèges, le durcissement des systèmes et la prévention de la compromission des identifiants répond à des vecteurs d’attaque récurrents, en particulier lorsque des accès privilégiés sont visés.
Sur la résilience, enfin, l’extension du périmètre aux connecteurs clients et aux dépendances de prestataires converge avec la logique portée par la réglementation européenne DORA, applicable depuis le 17 janvier 2025. DORA impose notamment une gestion structurée du risque lié aux prestataires TIC, un renforcement du contrôle des accès et des capacités de détection et de réponse. Sans se substituer l’un à l’autre, les deux cadres partagent une même orientation : sécuriser l’ensemble de la chaîne, y compris ses dépendances externes, et non le seul périmètre central.
Perspective Forum des Compétences
Le CSCF v2026 confirme une trajectoire engagée depuis plusieurs années : le référentiel SWIFT ne se limite plus à la protection de l’interface de messagerie, mais s’étend progressivement à l’ensemble des flux, des intégrations et des dépendances qui entourent les environnements de paiement.
Pour les banques et les assurances, trois enseignements se dégagent. D’abord, le changement le plus structurant de cette version — le passage du contrôle 2.4 en obligatoire et l’entrée des connecteurs clients dans le périmètre — élargit concrètement le champ de l’attestation vers le back-office et les tiers. Un établissement qui limitait son analyse à la zone sécurisée doit revoir son périmètre et, potentiellement, son type d’architecture.
Ensuite, la conformité au CSCF gagne à être traitée comme un processus continu plutôt que comme un exercice de fin d’année. La cartographie des flux, l’identification des dépendances, la préparation des preuves et la coordination entre équipes application, infrastructure, intégration et opérations demandent de l’anticipation, en particulier lorsque le périmètre s’élargit.
Enfin, l’attestation n’a de valeur que si elle reflète une réalité opérationnelle. L’évaluation indépendante, le durcissement effectif des systèmes et l’exploitation des résultats comptent davantage qu’une déclaration formelle. C’est à cette condition que le CSCF joue pleinement son rôle : non pas un exercice documentaire supplémentaire, mais un socle de sécurité pour des chaînes de paiement dont la compromission aurait des conséquences majeures.
Sources publiques utilisées
Cet article s’appuie principalement sur la documentation publique de SWIFT relative au Customer Security Programme et au Customer Security Controls Framework, ainsi que sur le règlement européen DORA :
- SWIFT, Customer Security Controls Framework (CSCF) v2026, publié en juillet 2025, et document comparatif CSCF v2026 / v2025.
- SWIFT, pages du Customer Security Programme : présentation du CSP, soumission de la Security Attestation (KYC-SA), réalisation de l’évaluation indépendante et Independent Assessment Framework.
- SWIFT, Customer Security Controls Policy et Independent Assessment Process Guidelines.
- Règlement (UE) 2022/2554 (DORA) relatif à la résilience opérationnelle numérique du secteur financier, applicable depuis le 17 janvier 2025, notamment ses dispositions relatives à la gestion du risque lié aux prestataires tiers de services TIC.