SWIFT CSP 2027 adds no new mandatory controls, but it widens what your independent assessor will examine. Institutions that treat 2027 as a quiet year may find at attestation time that a shared vault, a vendor portal or a payment control has moved into scope.
Swift published version 2027 of its Customer Security Controls Framework (CSCF) on 10 July 2026. It governs attestations submitted between July and December 2027, which leaves less than a year to find and close gaps. This guide covers the changes that matter most for SWIFT CSP compliance and what to do about each one.
CSCF v2027 keeps the same 32 controls: 26 mandatory and 6 advisory, with no advisory control promoted. Instead, Swift adds secrets and key vaults to scope, narrows Architecture B, and raises expectations for patching, payment controls and penetration testing. The SWIFT CSP 2026 changes, including mandatory Control 2.4, are now the baseline.
| Change | What It Means | Most Affected |
|---|---|---|
| Secrets and Keys Vaults in scope | Vaults holding Swift credentials, keys or certificates must meet the same standard as Swift components | Institutions using a shared enterprise vault |
| Architecture B narrowed | Users who only connect to an outsourcing agent’s application must attest as A4 | Outsourcing agent and service bureau customers |
| Control 2.2 Security Updates | Patch faster, prioritize by exploitability and risk, and use compensating mitigations when patching is delayed | All users |
| Control 2.9 Transaction Business Controls | Time windows alone do not meet the control; limits, monitoring or additional approval must also be considered | 24/7 operations and service bureau users |
| Control 7.3A Penetration Testing (advisory) | Earlier tests count for up to four years (up from three); depth must match risk | All users |
| Controls 4.1 and 6.4 | Failed-login alerting at a defined threshold; HSM and connector logs explicitly covered | All users |
The biggest change in v2027 has no new control number. Swift introduces the Secrets and Keys Vault (SKV) as an in-scope component across most mandatory controls. An SKV is any tool or service that stores and manages:
Whether dedicated or shared across the enterprise, the vault must be protected to the same standard as the Swift components it serves, including placement in a protected zone, hardening, multi-factor authentication under Control 4.2 and, for cloud or outsourced vaults, Control 2.8.
If Swift-related credentials, keys or certificates are stored in an enterprise-wide vault or privileged access management (PAM) platform, assess whether that platform meets the applicable CSCF control objectives. A shared enterprise vault may be used if it is secured appropriately; a dedicated Swift vault is one possible implementation approach, not a universal requirement imposed by the framework.
Inventory the repositories holding Swift-related secrets, keys and certificates, identify the applicable CSCF controls, and document how each repository and its underlying infrastructure meet those controls.
Architecture B is the type for users with no local Swift footprint in scope. v2027 tightens who can use it:
Outsourcing agent users: CSCF v2026 already required some users previously attesting as Architecture B to move to A4 when their setup included a customer client connector. CSCF v2027 explicitly clarifies that users who only interactively access an application exposed by an outsourcing agent must select A4, not B, and obtain compliance results from that agent to support their own attestation.
Architecture B remains available for interactive-only users accessing applications exposed by a Swift connectivity provider, their Group Hub or Swift itself, where the applicable architecture criteria are met.
Moving from B to A4 brings more controls into scope, including Control 1.5 Customer Environment Protection. Our guide to SWIFT architecture types explains how each type is defined.
If you rely on an outsourcing agent’s portal, confirm your architecture type now rather than at attestation time.
Control 2.2 Security Updates adds recommendations addressing the rapid emergence and evolution of AI-driven cyber threats, including advanced systems often referred to as Frontier AI. Swift recommends accelerating vulnerability prioritisation and remediation, applying security updates more rapidly, prioritising vulnerabilities according to exploitability and risk, and implementing compensating mitigations when timely patching is not feasible.
The CVSS-based reference timelines are not new in v2027. In the absence of established internal processes and deployment timelines, v2026 already recommended applying critical updates (CVSS 9.0 or above) within one month of release and high-severity updates (CVSS 7.0–8.9) within three months.
Review whether vulnerability prioritisation reflects exploitability and risk, and document how urgent remediation and compensating-mitigation decisions are made.
Control 2.9 Transaction Business Controls is clarified in v2027 to better define expectations for outbound transaction activity across different operating models and committed business service availability windows.
Committed business service availability: Institutions should define transaction controls in line with their committed business service availability and operating model, rather than assume a single conventional business-hours schedule.
Layered controls: Time restrictions alone do not necessarily meet the control objective. Depending on the risk and operating model, institutions should consider transaction limits, monitoring, reconciliation or additional approval.
24/7 operations: Institutions should consider appropriate controls that limit, monitor or require additional approval of transactions. The appropriate combination depends on the institution’s normal business activity and risk exposure.
Risk-based thresholds: Transaction thresholds may take account of factors such as transaction amount, normal transaction behaviour and risk exposure. The chosen measures should address the risk of fraudulent outbound activity during normal operating periods as well as outside them.
Be ready to show how you rank vulnerabilities, not only how fast you patch, and test whether your controls would stop a fraudulent payment sent inside the business window.
Control 7.3A remains advisory. CSCF v2027 clarifies how comprehensive penetration-testing coverage can be achieved over time through an overall programme, rather than requiring every in-scope component to be actively tested during each individual exercise.
Four-year lookback: The programme may rely on previous testing exercises that are no more than four years old at the time of attestation submission, including relevant Red Team or Threat-Led Penetration Testing (TLPT) exercises. These exercises must effectively cover all or part of the infrastructure in scope; age alone does not demonstrate adequate coverage.
Risk-based testing: Testing scope, depth and frequency should reflect risk exposure. Internet-exposed components generally warrant more testing attention than deeply nested components.
Significant changes: Testing is expected following significant changes affecting Swift-related in-scope components, such as the introduction of new servers, operating systems, virtualisation or cloud technologies, or material network changes. Testing is typically conducted at least every two years, subject to applicable regulations and risk exposure.
Maintain a multi-year testing programme that maps relevant tests to the in-scope components they actually cover, records test dates and findings, and identifies when further testing is required.
v2027 also tightens several existing controls. The full list is available through Swift’s Customer Security Programme page.
Control 6.4 Logging and Monitoring: CSCF v2027 clarifies that the Hardware Security Module (HSM) is in scope of this control following completion of the HSM migration. Messaging-interface, communication-interface and connector application audit logs must be retained for at least 12 months and sufficiently protected against enterprise administrator-level compromise. Other identified in-scope component audit logs also have a 12-month minimum. Operator-PC, firewall and database audit logs have a minimum retention period of 31 days, with longer retention recommended for certain categories to support investigations.
Two future developments are worth tracking, but neither should be interpreted as a confirmed blanket requirement taking effect in 2028.
Legacy back-office data flows: CSCF v2026 had already established a phased approach under Control 2.4, making specified protections mandatory while leaving certain legacy direct data exchanges advisory. That version identified 2028 as a tentative target for bringing the remaining legacy flows into scope as mandatory. CSCF v2027 clarifies the role of the back-office first hop, the bridging server and the flows that require protection. Institutions should map and assess the affected flows now, while treating the 2028 date as tentative.
Swift Digital Ledger: CSP expectations and guidance for the Digital Ledger initiative will be developed progressively. Integration into a future CSCF version is targeted for v2028; this should not be read as confirmation that a complete set of mandatory Digital Ledger controls has already been finalised.
AI agentic operators: CSCF v2027 introduces the AI agentic operator concept in its glossary and refers to related CSP FAQ guidance. Agents involved in generating or supporting business transactions should be appropriately secured and governed, with human-in-the-loop controls ensured by design when involved in managing those transactions.
Use the following checklist to assess readiness for CSCF v2027 and prepare for the attestation window from July through December 2027.
Inventory Secrets and Keys Vaults (SKVs). Identify every vault, key store, certificate repository and privileged access management (PAM) platform that stores Swift-related credentials, API keys, SSH keys, certificates or private keys. Determine which CSCF controls apply to each repository and its underlying infrastructure, including outsourcing requirements where relevant. Confirm that shared enterprise vaults are appropriately secured; a dedicated Swift-only vault is not universally required.
Validate your architecture classification. Confirm your architecture type against your actual connectivity model. If users interactively access an application exposed by an outsourcing agent, select Architecture A4 rather than B and obtain the relevant compliance results from the agent to support your attestation. Confirm that operator PCs and other in-scope components receive the applicable protections.
Review vulnerability management and patching practices. Prioritise vulnerabilities according to exploitability and risk, establish documented remediation timelines, and define compensating mitigations where timely patching is not feasible. Where internal processes and timelines are not established, consider Swift’s existing CVSS-based reference targets: critical vulnerabilities (CVSS 9.0 or above) within one month and high-severity vulnerabilities (CVSS 7.0–8.9) within three months. Review whether your process can respond more rapidly to emerging AI-driven threats.
Evaluate Control 2.9 transaction business controls. Assess whether your controls can detect or prevent fraudulent outbound payments during normal operating periods as well as outside them. Do not rely on time windows alone. Depending on your operating model and risk exposure, consider transaction limits, monitoring, reconciliation and additional approval. For 24/7 operations, document how the selected measures support the control objective.
Maintain a risk-based, multi-year penetration-testing programme. Map testing activities to the relevant in-scope components and maintain evidence of scope, test dates, findings and remediation. Control 7.3A remains advisory, but its guidance permits reliance on previous testing exercises no more than four years old at attestation submission, provided they effectively cover the relevant infrastructure. Typically, testing is conducted at least every two years, and following significant changes affecting Swift-related in-scope components, subject to applicable regulations and risk exposure.
Verify logging, retention and failed-authentication alerting. Confirm that messaging-interface, communication-interface and connector application audit logs are retained for at least 12 months and protected against enterprise administrator-level compromise. Apply the relevant retention periods to other in-scope components; operator-PC, firewall and database audit logs have a minimum 31-day retention period, with longer retention recommended for certain categories. Ensure invalid authentication attempts are logged and alerts are generated at a defined threshold. Swift recommends five consecutive failed attempts; this is not a universal mandatory threshold.
Map legacy back-office flows and track future Swift guidance. Identify the back-office first hops, bridging servers and data flows covered by the phased approach under Control 2.4. Verify that the protections already required under the v2026 framework are implemented, assess the remaining legacy flows and prioritise remediation according to risk. The tentative v2028 target for specified legacy flows was already identified in v2026; monitor subsequent Swift guidance for confirmation of timing and scope. Also track developing CSP guidance for the Digital Ledger and AI agentic operators rather than treating future target dates as finalised mandatory requirements.
Recommended next step: Assign an accountable owner and target date to each action, record supporting evidence, and track outstanding gaps through remediation and attestation preparation.
CSCF v2027 is a scoping year. Institutions that wait for a new mandatory control before acting may find their scope has grown without one. Starting the vault inventory and architecture review now leaves time to remediate before the July 2027 window opens. The SWIFT Continuous Assurance Program keeps institutions attestation-ready year-round, not only in the final months of the cycle.
This FAQ seeks to answer some of the most common questions and confusions about this topic.
No. The framework still has 32 controls, 26 mandatory and 6 advisory, and no advisory control becomes mandatory. The changes come through wider scope and clearer expectations within existing controls.
CSCF v2027 applies to attestations submitted between July and December 2027. Attestations submitted in the 2026 cycle are still made against CSCF v2026.
The addition of the Secrets and Keys Vault (SKV) as an in-scope component. Any vault or key store holding credentials, keys or certificates used by Swift components must now be protected to the same standard as those components.
Interactive-only users can, provided the application is exposed by a Swift connectivity provider, their Group Hub or Swift itself. Users who connect through an application exposed by an outsourcing agent must attest as A4 and obtain compliance results from that agent.
Control 7.3A remains advisory. v2027 lets earlier tests, including Red Team and TLPT exercises, count if they are no more than four years old at submission, up from three, and expects testing depth to match risk exposure.
