SWIFT CSCF v2026: the mandatory controls and the attestation window

The attestation window for CSCF v2026 opened on 1 July 2026 and closes on 31 December 2026. Swift published the framework on 1 July 2025. It carries 32 security controls, 26 mandatory and 6 advisory, across three objectives and seven principles. One control changed side: 2.4 Back Office Data Flow Security is now mandatory. The wider change is that customer client connectors became mandatory in scope for fourteen controls. Both reach past the secure zone into middleware and file transfer, which is where the engineering work lands.

What CSCF v2026 changed against v2025

Swift publishes a CSCF version every July, a year before it takes effect. A new control or component arrives as advisory first, and users get up to 18 months to prepare before it binds. v2026 cashes in a change announced in v2025.

The total has been 32 controls since v2024; what moved is the boundary between mandatory and advisory.

Control 2.4 covers the data exchanged between a user's Swift infrastructure and the back-office systems that feed it. Swift activated the phased approach set out in Appendix H, so the mandatory part of the control this cycle is narrower than its title suggests. As a minimum it covers:

• the bridging servers that guard the flows between the secure zone and the back-office first hops, where the exchange is not protected end to end
• the flows between bridging servers, and between a bridging server and the secure zone, on the same condition
• the new direct flows introduced between the secure zone and the back-office first hop

Existing direct exchanges between a back-office first hop and either a bridging server or the secure zone stay advisory, with v2028 named as the tentative date for closing that gap. The age of a flow decides its status this cycle, which is an unusual attribute to record about a file transfer.

The second change is quieter and reaches further. An endpoint connecting to Swift indirectly through a service provider, such as an application consuming APIs, a middleware client or a file transfer client, counts as a customer client connector. It was advisory in v2025. In v2026 it is a mandatory in-scope component of controls 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1 and 6.4, and Swift states the consequence plainly: some users who attested as architecture type B have to attest as A4.

Architecture type decides which controls apply

Each user selects one of five reference architectures, and the components in scope follow from that choice. A1, A2 and A3 carry an identical control set, except that control 6.3 Database Integrity does not apply to A3. Fewer apply to A4, and fewer still to type B.

The line between A4 and B is the expensive one to cross. Control 1.1 Swift Environment Protection, the separated secure zone, applies to A1, A2 and A3 only, and A4 carries control 1.5 Customer Environment Protection instead. Type B is for a user with no Swift-specific infrastructure of its own. Moving from B to A4 brings a protected zone, a hardened connector, multi-factor authentication on operating system accounts and a logging obligation into scope.

Where the connection runs through an outsourcing agent, a service bureau, a Business Connect or a Lite2 Business Application provider, the framework requires that agent's architecture type and compliance results before you can finish your own attestation. Their answer sets your date, so ask in writing in the first weeks of the window and treat it as an input to your integration layer design.

How the attestation window works

Attestations go into the KYC-SA application between July and December each year. The v2026 control set became available in the application in early July 2026, and the deadline is 31 December 2026. A new user attests before going live on the network.

Self-attestation on its own does not meet the requirement. Every user must undergo a Community Standard Assessment, covering at minimum the mandatory controls that apply to their architecture, performed either internally by an independent department such as internal audit, or externally by an assessment provider. Both routes are equally valid to Swift as long as the assessment is independent.

An internal assessor sits outside the first line of defence: internal audit, the risk office or a team assembled for the purpose. Nobody assesses a control they designed. Swift certification is optional on both routes. A non-certified assessor needs assessment experience against a standard such as PCI DSS, ISO 27002 or NIST CSF, with a lead assessor holding an industry certification such as CISA. Naming the department or the company in the attestation is mandatory; naming the lead assessor is advisory.

There is a reliance path, and this is the cycle where it closes for most users. An assessor may rely on last year's assessment if the assessor agrees, if the in-scope footprint has not changed in a way that invalidates the earlier conclusions, and if the new CSCF adds no mandatory controls or changes the previous assessment did not cover. The third condition fails in v2026 for anyone whose 2025 assessment did not cover control 2.4 and the connector scope. Reliance is also capped at one cycle.

Swift reserves the right to report users that hold no valid attestation or an expired one, that are not compliant with the mandatory controls, that did not perform an independent assessment, that connect through a non-compliant service provider, or that did not complete a Swift mandated external assessment on request. In Swift's words, the lack of compliance is "reported and made visible in a dedicated real-time application accessible by the customers' supervisor". Counterparties see attestation data when the attesting user grants them access.

The consequence Swift publishes is reporting, not disconnection. The pressure arrives through the supervisor who can see the status and through counterparties running third-party due diligence. If a mandatory control will not close by 31 December, the record takes a compliance level for that control with a remediation date, updated once the control is met. A missing attestation leaves a supervisor with the report Swift is entitled to make.

What an assessor asks for, and the order to fix things

The first thing that breaks is the inventory. Control 2.4 is written against back-office first hops and bridging servers, and most institutions cannot produce one list of which systems hand a payment instruction to the Swift environment and by what mechanism. The real list is always longer than the architecture diagram: an SFTP drop that predates the current team, a watched folder a batch job polls, a message queue, a script on a server nobody reboots. Scoping 2.4 is impossible until that list exists, and in a bank with a legacy core behind the messaging layer it takes weeks. Record two attributes per flow that nobody normally records: direction, and the year it was built, because a direct flow built from 2025 onwards is in mandatory scope while an older one is not.

The second thing that breaks is the zone boundary, which usually exists on the network diagram and not in the rule set. Control 1.1 asks that passwords and other authenticators usable inside the secure zone are not stored or used outside it. The authentication service is where this fails. If the directory that authenticates Swift operators sits in the general enterprise domain, it has to move into another zone with comparable controls, or be limited to filtering connections at the boundary while a second mechanism inside the zone enforces logical access. Either route is an identity project and runs on an identity project's timeline.

Third, multi-factor authentication fails on detail. A one-time-password application running on the same PC that takes the password is not a second factor under control 4.2, and the implementation guidance says so. v2026 also expects it on one authentication step for external privileged access used to manage the firewall protecting the secure zone or the customer client connectors, which is often the administrative path nobody instrumented.

Fourth, logging. Control 6.4 sets retention explicitly: messaging and communication interface application audit logs for no less than 12 months, operator PC, firewall and database audit logs for no less than 31 days, and audit logs on other in-scope components for no less than 12 months. Those interface logs also have to survive an administrator-level compromise of the enterprise, which means shipping them to a system whose administrators are different people.

The order that works is inventory, zone boundary, authentication, logging, evidence. Evidence is the part teams under-budget. An assessor works from configuration exports, firewall rule sets, an account list with the factors attached, retention settings and dated screenshots taken inside the cycle. A policy describing the intended state proves nothing about the running one, and six months of missing log retention cannot be promised away in December. The same integration seams that slow a core transformation slow this inventory.

What v2027 already tells you

Swift published CSCF v2027 on 10 July 2026, and users attest against it in the second half of 2027. It keeps 32 controls, 26 mandatory and 6 advisory, so no control changes side next year. What it adds is scope, and three items belong in a 2027 budget now:

1. A Secrets and Keys Vault, meaning any service holding credentials, API or SSH keys, or certificates and their private keys, becomes an in-scope component. It sits inside a protected zone under control 1.1 or 1.5, with its flows protected under 2.1, 2.4 and 2.6.
2. Microsegmentation is named in controls 1.1 and 1.5 as a way of meeting the zone objective, which gives a cloud or hybrid deployment a documented route a flat network never had.
3. An interactive-only user connecting to an outsourcing agent selects architecture type A4 rather than B, and takes compliance results from that agent. The type B population keeps shrinking.

Swift has also enriched the CSP FAQ to cover AI agents that generate or support business transactions, and expects a human in the loop where they manage them. Nothing there is testable yet, which is how every control in this framework arrives: on the record a year before it binds.

One thread runs in parallel for an EU institution. Article 28(3) of DORA requires a register of information covering all contractual arrangements for ICT services from third-party providers, reported at least yearly to the competent authority. A service bureau or a connectivity provider is one of those arrangements, and what it tells you for control 2.8 Outsourced Critical Activity Protection describes the same relationship as the register entry. The same people should produce both.