Every institution connected to the Swift network must attest each year that its local Swift environment meets the mandatory controls of the Customer Security Controls Framework (CSCF), and counterparties and supervisors can see the result. The Customer Security Programme (CSP) exists because attackers who take over an institution's Swift infrastructure, or the operator and service accounts behind it, can send fraudulent payment messages that look legitimate to the rest of the network. This guide explains how the CSP and CSCF are structured, how architecture types decide scope, what the identity controls actually ask for, and how to run implementation, independent assessment and attestation without a December scramble. It is written for security, payments operations and compliance teams at banks, market infrastructures and corporates that use Swift, and for the internal auditors and external assessors who review them.
Key takeaways
- Attestation is annual and visible. Swift users attest in the KYC Security Attestation (KYC-SA) application between 1 July and 31 December, and results can be shared with counterparties and are visible to supervisors.
- The CSCF changes every July. Swift publishes a new version a year before it takes effect, new controls usually arrive as advisory first, and several have moved to mandatory over time.
- Architecture type sets your scope. Five architecture types (A1, A2, A3, A4 and B) decide which controls apply, and v2026 widened the scope for customer connectors such as middleware, API clients and file transfer tools.
- Identity controls carry most of the weight. Privileged OS accounts, MFA, logical access, token management and password storage are mandatory, and they apply to service accounts and connector credentials as much as to operators.
- Independent assessment is required. Every attestation must be supported by an assessment from a team independent of the first line, internal or external, under Swift's Independent Assessment Framework.
What it is and who it applies to
Swift launched the CSP after a series of fraud cases in which attackers used compromised local environments at member institutions to send unauthorised payment instructions. Swift describes the programme as mandatory: each user implements the CSCF controls on its own Swift footprint and attests its compliance level every year. Swift secures the central network; the CSP covers the part each customer owns and operates.
- Who: every Swift user with a BIC that connects to the network, whether directly, through a service bureau or through a group hub. Smaller users that only reach Swift through a browser interface still attest, but fewer controls apply.
- What is in scope: the local Swift infrastructure: messaging and communication interfaces, connectors, the jump servers and operator PCs used to reach them, the secure zone that surrounds them, and from v2026 the customer connectors and back-office flows that feed Swift.
- What is out of scope: the wider enterprise network and back-office applications, except where the CSCF explicitly reaches into them (for example back-office data flow security in control 2.4).
- Consequence of weak attestation: attestation data is visible to supervisors and to counterparties that are granted access, so a poor or missing attestation affects correspondent due diligence, not only the relationship with Swift. See the Financial Services Identity Security Guide.
Structure and key requirements
The CSCF is built on three objectives that Swift names Secure your environment, Know and limit access, and Detect and respond. Under these sit principles (restrict internet access and protect critical systems from the general IT environment, reduce attack surface and vulnerabilities, physically secure the environment, prevent compromise of credentials, manage identities and segregate privileges, detect anomalous activity, and plan for incident response and information sharing) and 32 numbered controls. Controls with an "A" suffix are advisory.
Annual cycle
- July, year N: Swift publishes the CSCF version that applies to attestations in year N+1. Swift says organisations get up to 18 months to prepare for new or changed controls.
- 1 July to 31 December, year N+1: the attestation window. The attestation must reflect compliance with at least the mandatory controls of the version in force.
- Any time: a non-compliant control is attested with a remediation date, and the attestation is updated once the control is met.
Control families
The table lists the control set as published in CSCF v2022, the last version for which we read a full control list, with the status changes that later versions are reported to have made. Always check the current CSCF document for the version you attest against.
| Control | Name | Status in v2022 | Notes |
|---|---|---|---|
| 1.1 | Swift Environment Protection | Mandatory | Secure zone segregation from the general IT environment |
| 1.2 | Operating System Privileged Account Control | Mandatory | Restrict and control admin and root accounts |
| 1.3 | Virtualisation Platform Protection | Mandatory | Hypervisors hosting Swift components |
| 1.4 | Restrict Internet Access | Mandatory | Operator PCs and secure zone systems |
| 1.5A | Customer Environment Protection | Advisory | Connector environments |
| 2.1 to 2.3 | Internal Data Flow Security, Security Updates, System Hardening | Mandatory | Patching and hardening of in-scope systems |
| 2.4A | Back-Office Data Flow Security | Advisory | Reported as mandatory from v2026 |
| 2.5A | External Transmission Data Protection | Advisory | Data leaving the secure zone |
| 2.6, 2.7 | Operator Session Confidentiality and Integrity, Vulnerability Scanning | Mandatory | |
| 2.8A | Critical Activity Outsourcing | Advisory | Service bureaux and outsourced operations |
| 2.9, 2.10 | Transaction Business Controls, Application Hardening | Mandatory | 2.9 became mandatory in v2022 |
| 2.11A | RMA Business Controls | Advisory | Relationship Management Application hygiene |
| 3.1 | Physical Security | Mandatory | |
| 4.1, 4.2 | Password Policy, Multi-Factor Authentication | Mandatory | Identity controls |
| 5.1, 5.2, 5.4 | Logical Access Control, Token Management, Physical and Logical Password Storage | Mandatory | Identity controls |
| 5.3A | Staff Screening Process | Advisory | |
| 6.1 to 6.4 | Malware Protection, Software Integrity, Database Integrity, Logging and Monitoring | Mandatory | |
| 6.5A | Intrusion Detection | Advisory | |
| 7.1, 7.2 | Cyber Incident Response Planning, Security Training and Awareness | Mandatory | |
| 7.3A, 7.4A | Penetration Testing, Scenario Risk Assessment | Advisory |
v2022 had 23 mandatory and 9 advisory controls. According to Elevate Consult's summary of CSCF v2026 (published by Swift in July 2025), v2026 keeps 32 controls with 26 mandatory and 6 advisory, up from 25 and 7 in v2025, and 14 of the 32 apply to customer connectors.
What changed in v2026
- Back-office data flow security (2.4): moved from advisory to mandatory. Institutions must protect the bridging servers between the secure zone and the first back-office hop, and the flows between them, using either end-to-end message protection or segmented protection of each hop. Assessment firms report that legacy direct flows stay advisory until a tentative 2028 milestone.
- Customer connectors: middleware, API consumers, file transfer clients and indirect connections through service providers are now in scope. Some users that attested as architecture type B may need to reclassify as A4, which brings more mandatory controls.
Architecture types
| Type | Typical footprint | Scope implication |
|---|---|---|
| A1 | User owns and runs both the messaging interface and the communication interface | Widest control set |
| A2 | User owns the messaging interface; a service provider hosts the communication interface | Most controls still apply |
| A3 | User runs a Swift connector application but no messaging or communication interface | Narrower, connector focused |
| A4 | Customer connector: middleware, file transfer or API client exchanging data with a service provider | Connector controls; expanded in v2026 |
| B | No Swift-specific local footprint; users reach a provider's service through a browser on a general purpose PC | Smallest control set |
Swift asks users to choose their type with its architecture decision tree. Getting the type wrong is the most expensive mistake in the programme because it misstates scope for every control.
Identity and NHI requirements
The fraud pattern the CSP was built against depends on stolen operator credentials and on accounts that can create and release messages. That is why the "Know and limit access" objective is the heart of the framework, and why its controls reach non-human identities as well as people.
- 1.2 Operating System Privileged Account Control: limit administrator and root accounts on secure zone systems to named, approved people, use them only for administration, and log their use. Built-in admin accounts and shared root logins are the usual findings. See the Privileged Access Management Guide.
- 4.1 Password Policy and 5.4 Physical and Logical Password Storage: apply to application, database and service account passwords as well as operators. Passwords in scripts, configuration files or connector property files fail 5.4. Store them in a vault or hardware security module and rotate them on a schedule. See the Secrets Management Guide.
- 4.2 Multi-Factor Authentication: required for interactive access to Swift-related applications and to the operating systems that host them, typically enforced at the jump server. Phishing-resistant factors are the stronger choice. See the Phishing-Resistant MFA Guide.
- 5.1 Logical Access Control: least privilege, need to know and segregation of duties (four-eyes on message creation and approval), with periodic recertification and prompt removal of leavers.
- 5.2 Token Management: hardware tokens and PKI devices used to sign or authenticate must be issued, tracked and revoked like any other credential.
- Connector and API credentials: with v2026 bringing customer connectors into scope, API keys, OAuth clients and certificates used by middleware to talk to Swift or a service bureau become CSCF evidence. Inventory them as machine identities with owners, scopes and rotation dates. See the Service Account Security Guide.
| Attack behaviour | ATT&CK | CSCF controls that address it |
|---|---|---|
| Logging in with stolen operator or admin credentials | T1078 Valid Accounts | 1.2, 4.1, 4.2, 5.1 |
| Harvesting passwords from files and scripts | T1552 Unsecured Credentials | 5.4, 2.3 |
| Moving from the corporate network into the secure zone | T1021 Remote Services | 1.1, 1.4, 4.2 |
| Altering payment messages in transit or in back-office files | T1565.002 Transmitted Data Manipulation | 2.1, 2.4, 2.9, 6.2 |
| Deleting traces to delay detection | T1070.004 File Deletion | 6.3, 6.4, 6.5A |
Implementation steps
- Confirm architecture type (April to June): run Swift's decision tree, include every connector, middleware and file transfer path, and document the rationale. If you attested as B, test whether v2026 connector scope moves you to A4.
- Map the footprint and flows: list every in-scope host, operator PC, jump server, HSM, connector and back-office first hop, and draw the data flows into and out of the secure zone. This map is the basis of control 2.4 and of the assessment scope.
- Gap assess against the next version: compare current controls with the CSCF version you will attest against, and also read the version published in July that will apply the following year, so advisory controls that will become mandatory get budget early.
- Fix identity first: remove shared and default admin accounts, put MFA on the jump server path, vault service account and connector secrets, and enforce four-eyes on message release. These controls fail most often and take longest to evidence.
- Segment and harden: place Swift components in a secure zone with filtered flows, no direct internet access, hardened builds and a patch cadence. Use a pilot change window and keep rollback images of interface servers before hardening changes.
- Turn on logging and transaction controls: forward OS, application and database logs to monitoring, reconcile sent messages against back-office records daily, and set business controls such as value and time-of-day thresholds.
- Exercise incident response: rehearse a fraudulent message scenario that includes contacting Swift, counterparties and the regulator, and freezing outbound traffic. See the Incident Response Guide.
- Assess, then attest (October to December): run the independent assessment early enough to remediate findings, then submit in KYC-SA before 31 December with remediation dates for anything not met.
Small versus large users: a small institution on architecture B or A4 can often meet the control set with a hardened connector host, vaulted credentials and an internal audit assessment. A large A1 user with several BICs and a group hub needs a dedicated Swift security owner, a separate admin forest or PAM tier for the secure zone, and usually an external certified assessor to cover multiple entities consistently.
Evidence and assessment
Swift requires an independent assessment every year to support the attestation, carried out as a Community Standard Assessment under the Independent Assessment Framework (IAF).
| Option | Who | Requirement | When it fits |
|---|---|---|---|
| Internal | Internal audit, risk office or another team independent of the first line (CISO) | No one assesses their own work or controls they designed | Mature second or third line with Swift knowledge |
| External | Swift CSP Certified External Assessor, or a non-certified firm with PCI DSS, ISO 27002 or NIST CSF assessment experience | Lead assessor holds an industry certification such as CISA | Smaller institutions, multi-BIC groups, first assessment |
| Mixed | Internal and external staff led by either | Same independence rules | Large groups sharing effort |
- Reuse: a prior assessment can be referenced only if the assessor agrees, the footprint has not materially changed and the new CSCF version adds no mandatory controls the earlier work did not cover. Swift says a previous assessment can be relied on only once, so reuse in one year means a full assessment the next.
- KYC-SA entries: naming the assessing department or firm is mandatory; naming the lead assessor is advisory.
- Evidence to keep: architecture decision record, network and data flow diagrams, privileged account lists and recertifications, MFA configuration, vault records for service credentials, patch and scan reports, log retention settings, and the assessor's report against each control.
Useful KPIs: percentage of mandatory controls fully compliant at 30 September; number of secure zone admin accounts per host; percentage of service and connector credentials vaulted and rotated within policy; median days to patch critical vulnerabilities on Swift hosts; daily message reconciliation exceptions closed within one business day; time from a CSCF release to a funded gap plan.
Mapping to other frameworks
| CSCF area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Related NHIMG guide |
|---|---|---|---|
| 1.1, 1.4 secure zone and internet restriction | PR.IR-01 | SC-7 | Network Segmentation Guide |
| 1.2, 5.1 privileged and logical access | PR.AA-05 | AC-2, AC-6 | Privileged Access Management Guide |
| 4.1, 4.2, 5.2, 5.4 credentials and MFA | PR.AA-01, PR.AA-03 | IA-2, IA-5 | MFA Guide |
| 2.1, 2.4, 2.5A data flows | PR.IR-01 | SC-8 | |
| 2.2, 2.7 patching and scanning | PR.PS-02, ID.RA-01 | RA-5 | Vulnerability Management Guide |
| 6.2, 6.3 software and database integrity | SI-7 | ||
| 6.4, 6.5A logging and intrusion detection | DE.CM-01, DE.CM-03 | AU-6, SI-4 | SIEM Guide |
| 7.1 incident response | RS.MA-01 | IR-4 | |
| 7.3A penetration testing | CA-8 | ||
| 2.8A outsourcing | GV.SC-07 | SR-3 | Third-Party Risk Management Guide |
Swift itself accepts assessors with PCI DSS, ISO 27002 or NIST CSF experience, which reflects the overlap. Institutions that already run the PCI DSS 4.0 Guide controls or a DORA programme (see the DORA Guide) can reuse much of the evidence, but the CSCF scope boundary and architecture type are specific to Swift and must be evidenced separately.
Common pitfalls
- Misclassified architecture: attesting as B while running middleware or API clients that exchange data with a bureau. Under v2026 this is the most likely reason for an attestation to be challenged.
- Shared admin and service accounts: one local administrator password across interface servers, or a connector service account with interactive logon rights. Both undermine 1.2 and 5.1 and give an attacker a single key.
- Secrets in connector configuration: plain text passwords and private keys in middleware property files or scheduled scripts, the same pattern seen when stolen DevOps secrets unlocked encrypted backups in the LastPass breach.
- MFA that stops at the VPN: MFA on remote access but not on the jump server or messaging interface, so a session hijack inside the network reaches Swift with a single factor.
- Self-assessment presented as independent: the team that runs the Swift platform assessing its own controls. Swift's independence rule excludes this.
- Attesting in late December: no time to remediate assessor findings, which leaves non-compliant controls visible to counterparties for the following year.
Practitioner checklist
- Record the CSCF version you will attest against this year and read the version Swift published in July for next year.
- Re-run the architecture decision tree, including every connector, middleware and API client, and document the result.
- Maintain a current diagram of the secure zone, bridging servers and back-office first hops for control 2.4.
- List every privileged OS account, operator account and service account in scope, with an owner and last recertification date.
- Enforce MFA on the jump server and messaging interface path, not only at remote access.
- Vault all connector, database and service credentials and rotate them on a defined schedule.
- Reconcile sent messages with back-office records daily and alert on out-of-hours or unusual value messages.
- Book the independent assessor by the end of the summer, confirm their independence, and plan for full reassessment after any reuse year.
- Submit the KYC-SA attestation with remediation dates well before 31 December.
Standards and references
- Swift: Customer Security Programme (CSP)
- Swift: Customer Security Controls Framework
- Swift: Independent Assessment
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- Deloitte: SWIFT Customer Security Programme 2022 whitepaper
- Foregenix: CSCF v2026 control 2.4A, from advisory to mandatory
- Elevate Consult: Swift CSP 2026
Related NHI Mgmt Group resources: Financial Services Identity Security Guide · FFIEC Cybersecurity Guidance Guide · Payment Fraud Guide · Sysmon Guide · Service Account Security Guide. This guide summarises the Swift Customer Security Programme and is not legal advice.