Internet Security Auditors Blog

SWIFT CSCF 2026: Evolution, Key Updates, and What Your Organization Needs to Know

Written by Diego de la Horra | May 29, 2026 9:09:50 AM
The Customer Security Programme (CSP) is a security program published by SWIFT (Society for Worldwide Interbank Financial Telecommunication) in 2016 that defines a set of mandatory and advisory security controls (best practices recommended by SWIFT) to maintain security in the operational environments of SWIFT users, protecting international transactions between financial institutions, minimizing cyberattack risks, and limiting the impact of fraudulent transactions.

 The CSP establishes a series of security controls known as the Customer Security Controls Framework (CSCF), whose objective is to protect financial environments. The security controls defined by the CSCF are based on other international industry standards such as NIST, ISO 27000, and PCI DSS. These controls have evolved over the years, from 2016 to the latest published version, the 2026 release, which we will analyze by reviewing the main changes compared to the previous version, the 2025 edition, already covered in a previous article on the blog (https://blog.isecauditors.com/la-evolucion-de-la-seguridad-swift-claves-para-2025-parte-1). 

CSCF 2026

Published on July 1, 2025, the 2026 edition of the CSCF is composed of three objectives (environment protection, knowing and limiting access, and detection and response), seven security principles, and 32 security controls


Of the 32 security controls defined in this version, 26 are mandatory, while the remaining 6 are recommended to enhance the security level within the defined scope. These security controls help mitigate specific cybersecurity risks that SWIFT users must face. Within each security control, SWIFT documents the most common risks that the control is designed to mitigate. In this way, it prevents or minimizes unwanted and potentially fraudulent business consequences such as:
▪️Unauthorized submission or modification of business transactions.
▪️Processing of altered or unauthorized incoming SWIFT transactions. 
▪️Conducting business with unauthorized entities. 
▪️Confidentiality breaches (business data, systems, operator details, etc.). 
▪️Integrity breaches (business data, systems, operator details, etc.). 

The implementation of these security controls must be incorporated by organizations at the cybersecurity governance level and within their defined risk management program. 

 Changes for the 2026 Version 

 The 2026 version of the SWIFT CSCF introduces only a few changes compared to the previous edition, the 2025 release, with most of the existing security controls and guidelines remaining unchanged. All updates included in this new version are analyzed below: 

Mandatory nature of Control 2.4 – Back Office Data Flow Security

As announced last year, Control 2.4 Back Office Data Flow Security moves from being a recommended control to a mandatory one. For SWIFT type B architectures, this control becomes not applicable. 

 The objective of this control is to ensure the confidentiality, integrity, and authenticity of the data exchanged between the first back‑office hops and the components of the SWIFT infrastructure in on‑premise or remote environments, protecting against any Man‑in‑the‑Middle attack, data leakage or alteration, and unauthorized access to data in transit. 

 To do so, the data flows that must be taken into account are:
▪️Direct or indirect flows between components within the SWIFT infrastructure and the first back‑office hops, using one or more bridging servers, such as middleware servers, file transfer servers, or similar systems. 


▪️Flows to New HSMs.
▪️Direct Legacy flows (their protection is recommended).

To achieve this, the CSCF provides guidance recommending the implementation of the following security controls:

  1.  Inventory the data exchanged in direct or indirect flows. This ensures that the organization understands the type of data being transmitted (financial messages, references, reconciliation files, etc.) and through which channels. For example, documented inventories or tables, architecture diagrams, and data flow diagrams may be used. 
  2.  Assess the security of each flow in terms of confidentiality, integrity, and authenticity by reviewing all in‑scope flows and performing technical tests within the network, such as vulnerability scans, certificate reviews, and similar activities. 
  3.  Use secure, up‑to‑date, industry‑accepted protocols such as AES or ECDHE, applying appropriate key lengths based on industry best practices (a minimum acceptable security level of 112 bits for symmetric keys, 2048 bits for RSA asymmetric keys, or 256 bits for elliptic curve keys (ECC)). More information on cryptographic algorithms supported by secure protocols can be found in SWIFT’s cryptography guidance and best practices, published in article 5021566: https://www2.swift.com/knowledgecentre/kb_articles/5021566 
  4.  Protect credentials and private or cryptographic keys. They must be securely stored to maintain their confidentiality and integrity. KMS (Key Management System) solutions may be used to protect cryptographic keys throughout their lifecycle. 
  5.  Protect the data exchanged between the first back‑office hop and the components of the SWIFT infrastructure. 
                    ▫️Point‑to‑point protection through one of the following methods
                         (or a combination of both): 
                             ▪️A secure mechanism that protects data‑level integrity,
                                  confidentiality, and authentication, using, for example, local
                                  authentication (LAU) based on AES‑GCM, XML DSIG, or similar. 
                             ▪️A secure protocol that protects connection‑level integrity,
                                 confidentiality, and authentication, using, for example, LAU in
                                 combination with confidentiality protection (such as one‑way TLS
                                 where the sender validates the receiver), or authenticating API calls
                                 over TLS or mutual TLS. 
                   ▫️Protection at each point of the flow supported by one or more
                        interconnection servers between the first back‑office hops and the
                        SWIFT infrastructure components. To achieve this, two combined
                        mechanisms are defined: 
                            ▪️Use of secure mechanisms or protocols such as those mentioned
                                 above to protect each segment.
                            ▪️Securing the bridging servers.

For flows that are not properly protected, an action plan must be established, considering risk prioritization (supported by a Risk Analysis), in order to:
▪️Implement secure mechanisms or protocols offered by interfaces, connectors, or bridging servers. 
▪️Migrate legacy flows to secure mechanisms or protocols.
▪️Mitigate back‑office risks related to spoofing attacks or message injection through systems or via network connectivity safeguards. 

 As an additional note, the standard indicates that protecting Legacy flows will become mandatory in the 2028 version. These flows are currently classified as advisory, so their protection is considered a best practice at this stage.

Application of Security Controls to Customer Client Connectors

 As already stated in the 2025 version, many security controls will become mandatory for customer client connectors, meaning endpoints consuming APIs, middleware, or file‑transfer clients used to connect to a SWIFT connectivity provider, an outsourcing agent, or a remote Group Hub. This concept will be extended to cover client or server endpoints connected to a service provider or to SWIFT.

These systems will be mandatorily assessed under the following controls: 

▪️1.2 Privileged Account Control on Operating Systems 
▪️1.3 Protection of Virtualization or Cloud Platforms 
▪️1.4 Internet Access Restriction 
▪️2.2 Security Updates
▪️ 2.3 System Hardening
▪️ 2.6 Confidentiality and Integrity of Operator Sessions
▪️ 2.7 Vulnerability Scanning
▪️ 3.1 Physical Security
▪️ 4.1 Password Policy
▪️ 4.2 MFA Authentication
▪️ 5.1 Logical Access Control
▪️ 5.4 Password Repository Protection
▪️ 6.1 Malware Protection
▪️ 6.4 Logging and Monitoring 


These controls become mandatory for customer client connectors, no longer being considered best‑practice implementations.

Additionally, this change requires that some users who previously justified their architecture as type B must now evaluate it as type A4 when a customer client connector is used. 

Additional Clarifications

 Other minor changes included in the 2026 edition of the CSCF, which do not have a significant impact on the implementation or assessment of security controls within SWIFT environments, are as follows: 
▪️Update of the cryptography guidance and best practices in article 5021566: https://www2.swift.com/knowledgecentre/kb_articles/5021566 
▪️Inclusion of Alliance LSO/RSO accounts (Left Security Officer / Right Security Officer) as privileged accounts, which must comply with a set of additional security controls, along with new specifications to protect against the use of emergency or break‑glass accounts. 
▪️MFA requirement for privileged access by administrators managing firewalls from outside the environment. 
▪️Malware protection for non‑Windows systems located within the secure zone or hosting a customer client connector, recommending the use of EPP or EDR solutions. 
▪️Addition of SWIFT Universal Confirmation (UC) as an option for transaction validation or reconciliation beyond MT 900/MT 910 and MT 940/MT 950 when activity occurs outside business hours. 
▪️Validation of all downloadable software, both external and internal, to protect the integrity of all components within the SWIFT environment through checksum verification, release management processes, etc. 
▪️Clarification of terminology, such as bridging servers, first back‑office hop systems, customer client connectors, and the new Alliance Connect options, as well as updates to the included diagrams. 
▪️Other minor changes that do not have a major impact on SWIFT implementation or assessment. These minor updates can be found in the document published by SWIFT in its library. 

 Conclusions 

 The 2026 version of the Customer Security Controls Framework (CSCF) does not introduce a large number of major changes compared to the previous edition, but it does incorporate adjustments that are significant for the security of SWIFT environments, confirming the maturity of the framework and its evolution toward an increasingly strict and broader security landscape. 

 The main change in the 2026 edition is found in Control 2.4 Back Office Data Flow Security, which moves from being recommended to mandatory, protecting any flow between back‑office systems and SWIFT components, reducing the likelihood of security breaches and safeguarding information from its origin to the in‑scope components. For type B architectures, this security control becomes not applicable. 

 Similarly, new controls applicable to customer client connectors are introduced, expanding the scope of the framework and ensuring that these types of integrations comply with the same security standards. Fourteen of the 32 controls included in CSCF 2026 now apply to customer client connectors, improving security in these systems and covering aspects such as malware protection, multi‑factor authentication, secure configuration, and protection of passwords used for authentication in these components. 

 Finally, a series of minor changes have been introduced, including additional specifications within each CSCF security control, as well as clarifications that provide greater precision and consistency to the framework, facilitating its correct interpretation and implementation in SWIFT environments. 

 In summary, CSCF 2026 strengthens the confidentiality, integrity, and authenticity of transactional data exchanged between entities, with the aim of further reducing cybersecurity risks in SWIFT environments and minimizing the financial impact of fraudulent transactions. All of this is achieved through a continuous‑improvement approach, maintaining the same objectives, principles, and security controls from previous editions of the CSCF, while enhancing the defined controls, evaluating new vulnerabilities, threats, and attack vectors, and considering new safeguards to protect user environments. 

Referencias:
SWIFT Customer Security Controls Framework 2026: https://www2.swift.com/knowledgecentre/rest/v1/publications/cscf_dd/70.0/CSCF_v2026_202507015.pdf?logDownload=true

SWIFT Customer Security Controls Framework 2026 compared to v2025: https://www2.swift.com/knowledgecentre/rest/v1/publications/cscf_dd/70.0/CSCF_v2026_20250701_compared_to_v2025.pdf?logDownload=true


SWIFT glossary: https://www2.swift.com/knowledgecentre/publications/udic/18.0