The SWIFT Customer Security Controls Framework (CSCF) v2024 introduced several specific changes to enhance the cybersecurity posture of SWIFT users, with a particular emphasis on third-party risk management, clarifications to existing controls, and alignment with evolving threats and regulatory requirements (e.g., EU’s DORA and NIS2). Released in July 2023 for implementation by December 31, 2024, this version builds on CSCF v2023 with refinements rather than a complete overhaul. Below are the detailed, specific changes to CSCF v2024 based on available information up to February 20, 2025:
Key Changes in CSCF v2024
Control 2.8 – Outsourced Critical Activity Protection Becomes Mandatory
- Change: Previously an advisory control, Control 2.8 is now mandatory across all architecture types (A1, A2, A3, A4, and B).
- Details: This control requires SWIFT users to ensure that outsourced critical activities (e.g., services provided by third parties like cloud providers or managed service providers) meet the same security standards as in-house operations. Users must demonstrate:
- Service Level Agreements (SLAs) and Non-Disclosure Agreements (NDAs) with third parties.
- Registration of SWIFT infrastructure providers in the SWIFT Shared Infrastructure Programme (SIP) or Lite2 application directories.
- Information security risk assessments for all SWIFT-related third parties, in addition to financial due diligence.
- Rationale: Reflects the growing trend of outsourcing and cloud adoption in the financial sector, addressing vulnerabilities in third-party ecosystems amid increasing regulatory scrutiny.
Control 2.4A – Back Office Data Flow Security (Phased Approach)
- Change: Remains an advisory control, but updated with specific enhancements to prepare for its eventual transition to mandatory status (planned for future versions).
- Details:
- Requires detailed documentation of data flows between back-office systems and the SWIFT secure zone, including a table listing each flow and its security measures.
- Specifies four acceptable security methods for data transmission (e.g., end-to-end encryption, segmented flow protection).
- Introduces identification and securing of “bridging servers” that connect back-office systems to the secure zone.
- Rationale: Aims to reduce risks in back-office integration (e.g., core banking or ERP systems) where transactions originate, especially as APIs become more prevalent.
Control 2.3 – System Hardening
- Change: Enhanced with specific clarifications and additions.
- Details:
- Now explicitly includes USB port protection policies to prevent unauthorized device access.
- Strengthens guidance on application whitelisting to ensure only approved software runs on SWIFT systems.
- Rationale: Addresses physical and software-based attack vectors, reflecting the need for robust endpoint security.
Control 2.9 – Transaction Business Controls
- Change: Updated to provide flexibility in implementation.
- Details:
- Business controls (e.g., transaction monitoring to detect anomalies) can now be performed outside the secure zone, rather than being strictly confined within it.
- Rationale: Accommodates operational realities where transaction validation may occur in back-office systems, balancing security with practicality.
Control 3.1 – Physical Security
- Change: Minor refinements to recommendations.
- Details:
- Adds guidance on secure disposal of devices (e.g., hard drives, tokens) to prevent data leakage.
- Includes recommendations for token security to protect authentication hardware.
- Rationale: Strengthens physical security measures to complement digital controls.
- Control 1.3 – Virtualisation/Cloud Platform Clarification
- Change: Scope explicitly extended.
- Details:
- Clarifies that this control covers cloud platform infrastructure, ensuring virtualized or cloud-based SWIFT environments are adequately protected.
- Rationale: Aligns with the shift toward cloud-based deployments, ensuring consistent security standards.
Additional Refinements
- Scope and Terminology Updates:
- The “Scope of Security Controls” section aligns definitions for SWIFT Secure Zone, Customer Secure Zone, and co-hosting components, clarifying expectations for non-SWIFT systems within a secure zone.
- Minor corrections in control titles (e.g., Control 5.4 in the Security Controls Summary Table) and statements (e.g., Control 5.2 aligned with its objective) for consistency.
- Appendix A (Risk Driver Summary Matrix): Adjusted for Controls 2.1 and 2.4A to reflect updated risk drivers.
Context and Implications
- Total Controls: CSCF v2024 maintains 32 controls—25 mandatory and 7 advisory—consistent with v2023, but with Control 2.8’s promotion increasing the mandatory count for all architectures.
- Focus on Third-Party Risk: The shift of Control 2.8 to mandatory status highlights SWIFT’s priority on securing third-party relationships, driven by incidents where outsourced services were exploited.
- No Major Overhaul: Unlike some prior years (e.g., v2023 introduced new mandatory Control 1.5 for A4 architectures), v2024 focuses on incremental improvements, giving users stability while preparing for future mandates like 2.4A.
- Compliance Deadline: Users must attest compliance with v2024 by December 31, 2024, supported by an independent assessment (internal or external).
Why These Changes?
The updates reflect:
- Evolving Threats: Increased sophistication of supply chain attacks and reliance on third parties.
- Regulatory Alignment: Compatibility with frameworks like DORA (Digital Operational Resilience Act) and NIS2 in the EU, which emphasize third-party oversight.
- Community Feedback: Clarifications (e.g., USB policies, transaction controls outside secure zones) address practical implementation challenges reported by users.
In summary, CSCF v2024 refines the framework with a strong focus on third-party risk (Control 2.8), practical adjustments (Controls 2.3, 2.9, 3.1), and preparatory steps for back-office security (Control 2.4A), ensuring SWIFT users remain resilient against current and emerging cyber threats by the end of 2024.
