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.
Qu'est-ce que le cadre de contrôle de sécurité des clients SWIFT(CSCF) ?
Le CSCF v2026 est le référentiel de sécurité publié par SWIFT à l'intention de toutes les organisations de son réseau. Il définit 32 contrôles, dont 26 obligatoires et 6 recommandés, alignés sur des normes telles que ISO 27002, PCI DSS, SOC 2 et NIST CSF. SWIFT le met à jour chaque année.
Qui doit se conformer au CSCF ?
La conformité s'applique à tous les utilisateurs SWIFT, quel que soit le type d'architecture. Les fournisseurs de connectivité et les prestataires externalisés sont couverts par des programmes SWIFT distincts, et la responsabilité de l'attestation incombe à l'utilisateur ; par conséquent, le contrôle cryptographique doit pouvoir être démontré sur l'ensemble de la chaîne de connectivité.
Qu'est-ce que Control 2.4 ?
Control 2.4, intitulé « Sécurité des flux de données back-office », impose la protection des messages financiers, des fichiers de rapprochement et des données de référence. Ces données circulent entre la zone sécurisée SWIFT et les systèmes back-office ou de passerelle. Cette exigence, qui était auparavant recommandée, est désormais obligatoire, étendant ainsi le cadre au-delà de l'infrastructure sécurisée de base.
En quoi la norme Control 2.4 est-elle importante pour la cryptographie ?
Cela signifie que la protection cryptographique ne peut plus se limiter aux composants de la marque SWIFT. Les institutions doivent recenser les flux de données vers les systèmes de back-office et démontrer que les données restent chiffrées et authentifiées tout au long de leur parcours.
Qu'est-ce que l'attestation KYC-SA ?
L'attestationde sécurité « Know Your Customer » (KYC-SA) est le processus annuel par lequel chaque partie rend compte de sa conformité au CSCF. Elle est validée dans le cadre du dispositif d'évaluation indépendant, et les évaluateurs attendent des preuves concrètes plutôt que de simples déclarations de principe.
Comment les établissements doivent-ils se préparer à une évaluation indépendante SWIFT ?
Préparez les justificatifs relatifs à l'inventaire des flux de données du contrôle 2.4, aux modules de sécurité matérielle (HSM) et à la conservation des clés, à l'exactitude du KYC-SA, à la documentation relative à l'évaluation indépendante, à la cartographie du périmètre pour les serveurs relais et les intergiciels, ainsi qu'à la vérification des signatures. Le fait de maintenir ces justificatifs à jour permet de raccourcir la durée de l'évaluation.
Quel est le lien entre le CSCF et la préparation à l'ère post-quantique ?
La longue durée de vie des données financières fixe la date butoir pour la mise en place d'une protection quantique. SwiftNet devrait être compatible avec la cryptographie post-quantique (PQC) vers 2027, avec une période de migration de quelques mois. La constitution dès maintenant d'un inventaire cryptographique constitue la première étape concrète.
Comment Keyfactor peut-il vous aider à vous conformer aux exigences SWIFT ?
Keyfactor met en correspondance les exigences cryptographiques SWIFT avec des solutions spécifiques : EJBCA pour l'émission et le chiffrement basés sur des modules HSM, Keyfactor Command pour le reporting lié aux contrôles et la gestion du cycle de vie des certificats, AgileSec pour l'inventaire cryptographique, et SignServer pour la signature des fichiers « software » et des configurations liés à SWIFT.
