SWIFT CSP Mandatory vs Advisory Controls — CSCF v2025 Explained

The CSCF Structure — Three Objectives, Two Control Tiers

The SWIFT Customer Security Controls Framework (CSCF) is the technical backbone of the SWIFT Customer Security Programme (CSP). It defines the specific security controls that SWIFT-connected institutions must implement to protect their local SWIFT infrastructure, the data it processes, and the broader network from compromise.

CSCF v2025 organises its 32 controls — 25 mandatory and 7 advisory — under three security objectives:

Objective 1 — Secure Your Environment: Controls that protect the physical and logical security of the institution's SWIFT-related infrastructure. This includes network segmentation between the SWIFT secure zone and the general IT environment, operating system hardening, data flow encryption, and vulnerability management. This objective carries the largest number of controls and typically represents the most significant implementation effort.

Objective 2 — Know and Limit Access: Controls that govern who can access SWIFT-related systems and what they can do. This covers logical access control, multi-factor authentication, token and credential management, operator session security, and personnel vetting. These controls ensure that only authorised individuals can initiate, approve, or modify SWIFT transactions.

Objective 3 — Detect and Respond: Controls that ensure the institution can identify anomalous activity, investigate potential incidents, and respond effectively. This includes malware detection, logging and monitoring, intrusion detection, incident response planning, and cyber incident notification to SWIFT.

The two-tier structure — mandatory and advisory — is central to the framework's design. Mandatory controls represent the minimum security baseline that every SWIFT user must meet. Advisory controls represent best practices that SWIFT strongly recommends and may elevate to mandatory status in future CSCF versions.

The Mandatory Controls — By Objective

The 25 mandatory controls are distributed across all three objectives, with the heaviest concentration under Objective 1 (Secure Your Environment). Each control area may contain multiple sub-controls or implementation guidelines that define the specific technical and procedural requirements.

The controls marked with an "A" suffix (such as 2.4A, 6.5A, 7.3A, and 7.4A) were previously advisory controls that SWIFT elevated to mandatory status in prior CSCF versions. This pattern is important to note because it demonstrates SWIFT's consistent approach of using advisory controls as a staging area before making them mandatory. For the full CSCF documentation, refer to the official SWIFT Security Controls reference (requires myswift login).

The Advisory Controls — Why They Still Matter

The 7 advisory controls in CSCF v2025 are not required for attestation compliance, but they represent capabilities that SWIFT considers essential for a mature security posture. More importantly, advisory controls signal where SWIFT intends to raise the bar in future CSCF versions.

SOC Capability and Threat Intelligence

Several advisory controls address Security Operations Centre (SOC) capabilities, including real-time monitoring, threat intelligence integration, and proactive threat hunting within the SWIFT environment. While these are not mandatory today, institutions that invest in SOC capabilities gain significantly better visibility into potential compromise indicators — and position themselves ahead of likely future mandatory requirements.

Transaction Business Controls

Advisory controls in this area address transaction screening, confirmation of payment orders, and business-level controls that complement the technical security measures. These controls are particularly relevant for institutions processing high-value SWIFT messages, as they provide an additional layer of protection against fraudulent transactions that may bypass technical controls.

Advanced Authentication and Operator Accountability

Advisory controls around advanced authentication go beyond the mandatory MFA requirements, addressing areas such as biometric authentication, hardware security modules for operator credentials, and enhanced session recording. These represent the direction in which SWIFT is moving operator security requirements.

Which Controls Apply to Your Architecture Type?

Not all 25 mandatory controls apply equally to every institution. The applicable control set depends on the institution's SWIFT architecture type, which is determined by how the institution connects to the SWIFT network and where SWIFT-related components are deployed.

Most banks in Bangladesh, Singapore, Vietnam, and the Philippines operate under architecture types A1 or A2, meaning they have on-premises SWIFT infrastructure and are subject to the full or near-full mandatory control set. Understanding your architecture type is the first step in any SWIFT CSP assessment, as it directly determines the scope of controls that will be assessed.

Institutions that outsource parts of their SWIFT infrastructure to service bureaux (A3 or A4) have a smaller local control scope but must ensure that their service provider's attestation covers the controls that fall within the provider's responsibility. The institution remains ultimately accountable for its overall SWIFT security posture, regardless of the architecture type.

What Changed in CSCF v2025 vs v2024

SWIFT follows an annual update cycle for the CSCF, publishing each new version approximately six months before the attestation deadline. This gives institutions time to assess the impact of any changes, implement new or modified controls, and complete their independent assessment before the 31 December submission deadline.

The Advisory-to-Mandatory Elevation Pattern

The most consequential changes in any CSCF version are controls that move from advisory to mandatory status. This elevation pattern is how SWIFT gradually raises the security baseline across the entire SWIFT community. The pattern is deliberate: SWIFT introduces a control as advisory, giving institutions one to two years to implement it, and then elevates it to mandatory once sufficient adoption has been achieved.

CSCF v2025 maintains 25 mandatory and 7 advisory controls, with no new elevations in this cycle. However, the implementation guidance for several existing controls has been refined, particularly in the areas of:

Software Integrity (6.2): Updated guidance on integrity verification for SWIFT software components and related third-party dependencies, reflecting the growing threat of supply-chain attacks targeting financial infrastructure.

Operator Session Security (5.1): Enhanced expectations around session timeout configurations, privileged session monitoring, and the segregation of operator accounts used for SWIFT administration versus day-to-day operations.

Penetration Testing (7.3A): Clarified scope requirements to ensure that penetration tests cover the full SWIFT secure zone perimeter, including virtualisation layers and any back-office connectivity points.

For institutions that were compliant with CSCF v2024, the transition to v2025 should be manageable — but the updated guidance does require a review of existing implementations to ensure they meet the refined expectations. Institutions should not assume that last year's assessment evidence will be sufficient without review.

Common Control Failures in APAC Assessments

Based on EIC's 15+ SWIFT CSP assessments across Bangladesh, Singapore, Malaysia, Vietnam, the Philippines, Bahrain, and Nepal, we consistently observe the same categories of control failures. These are not obscure edge cases — they represent systematic gaps that affect a significant proportion of institutions in the region.

1. Incomplete SWIFT Infrastructure Inventory

Control 2.6 (Operator Confidentiality and Integrity) and the broader Secure Your Environment controls depend on a complete, accurate inventory of all SWIFT-related hardware and software components. In practice, many institutions maintain an incomplete or outdated inventory that fails to capture all components within the SWIFT secure zone — including virtualisation hosts, backup systems, and network devices that carry SWIFT traffic. Without a complete inventory, it is impossible to verify that all components are hardened, patched, and monitored.

2. Network Segmentation Gaps

Control 1.1 (SWIFT Environment Protection) requires that the SWIFT secure zone be logically and, where applicable, physically segregated from the institution's general IT network. This is one of the most frequently failed controls. Common issues include overly permissive firewall rules between the secure zone and the general network, shared infrastructure components (such as DNS or NTP servers) that bridge the two zones, and insufficient monitoring of traffic crossing the segmentation boundary.

3. Weak Operator Session Security

Controls 4.2 (Multi-Factor Authentication) and 5.1 (Logical Access Control) require robust operator authentication and session management. In APAC assessments, we frequently find shared operator accounts, excessively long session timeouts, and MFA implementations that do not cover all access paths to the SWIFT environment — particularly for administrative access to underlying operating systems and virtualisation platforms.

4. Generic Penetration Tests

Control 7.3A (Penetration Testing) requires that penetration tests specifically target the SWIFT secure zone and its boundary controls. Many institutions commission general-purpose penetration tests that cover the broader corporate network but do not specifically scope or test the SWIFT environment. A generic penetration test that does not cover the secure zone perimeter, operator workstations, and SWIFT-specific application interfaces will not satisfy this control. EIC's CREST-accredited penetration testing service includes SWIFT-specific test scenarios designed to satisfy this control requirement.

5. Generic Incident Response Plans

Control 7.1 (Cyber Incident Response Planning) requires an incident response plan that specifically addresses SWIFT-related cyber incidents — including scenarios such as fraudulent message injection, operator credential compromise, and malware targeting SWIFT components. Many institutions maintain a general IT incident response plan that does not include SWIFT-specific scenarios, escalation procedures, or SWIFT notification requirements. The plan must also be tested through tabletop exercises or simulations, which many institutions have not conducted for SWIFT-specific scenarios.