SWIFT Secure Zone: 6 Essential Design Rules for Control 1.1 (2026)

The SWIFT secure zone is the segmented part of the network in which a user’s Swift infrastructure lives — the messaging interface, the communication interface, the connectors and the jump servers used to reach them — separated from the general enterprise IT environment so that a compromise of an ordinary workstation cannot become a compromise of the systems that send payments. It is the subject of control 1.1, Swift Environment Protection, the first mandatory control in the Customer Security Controls Framework, and it is the architectural decision that most of the other controls depend on: what is in the zone is what 1.2, 2.2, 2.3, 2.7, 6.1 and 6.4 protect, and what is outside it is what 1.4 keeps away from the internet. This guide explains what CSCF v2026 requires of the secure zone, which components belong inside it by architecture type, the boundary controls that make it a zone rather than a diagram, how the 2026 customer-connector change reaches into it, and the design errors independent assessors find most often.

What control 1.1 requires

Control 1.1 Swift Environment Protection — the CSCF title, not “Restrict Internet Access”, which is the name of the principle above it — requires the user’s Swift infrastructure to be protected from potentially compromised elements of the general IT environment and the external environment by segregating it into a secure zone. The objective is containment: the general IT environment is assumed to be compromisable, and the zone is designed so that such a compromise does not reach the Swift components. Control 1.1 is mandatory and applies to architecture types A1, A2 and A3; type A4 users, whose Swift footprint is a customer connector, are covered by 1.5 Customer Environment Protection instead, and type B users, with no local Swift footprint, have no zone to build. Our guide to SWIFT architecture types explains the five types.

What belongs inside the SWIFT secure zone

The boundary controls that make it a zone

A SWIFT secure zone is defined by what crosses its boundary and how. Four boundary properties are what an assessor tests.

Two of these SWIFT secure zone boundaries changed in v2026. Control 2.4 became mandatory, so the back-office flows crossing the boundary are now assessed, with bridging servers and the flows between them in scope immediately and legacy direct flows still advisory under Appendix H. And customer client connectors became in-scope components of fourteen controls, which pulls the connector’s host into the protections — hardening, patching, privileged access, logging — that the zone components already carry. Our guide to CSCF v2026 covers both changes.

Designing the SWIFT secure zone

1. Inventory the Swift footprint first. Every interface, connector, HSM, jump server and the accounts on them. The zone is drawn around the inventory, not the other way round; an asset missing from the inventory is a component outside the zone.
2. Draw the flows before the firewall rules. Operator to jump server to component; component to Swift network; back office to bridging server to component; monitoring and backup out; time in. Each flow gets a source, destination, protocol, port and protection, and the firewall rules are derived from the list.
3. Put the jump server in the zone, not on the boundary. A jump server that is also a general-purpose admin box is a bridge, not a gate. It should be dedicated, hardened under 2.3, patched under 2.2, reached with MFA under 4.2, and logged under 6.4.
4. Keep operator PCs out and constrained. Operators reach the zone through the jump server from PCs that meet 1.4 — restricted or no general internet — and 2.6 for session protection. A zone with an operator PC inside it has imported the browsing risk it was built to exclude.
5. Treat the back office as external. Under 2.4 the flows are protected as if crossing an untrusted boundary: authenticated, integrity-protected, restricted to what the flow needs.
6. Document it as an architecture diagram with a flow table. The independent assessor’s first request is the diagram; the second is proof that the firewall implements it. Keep both current under change management (2.3 and the user’s own change process).

SWIFT secure zone design errors assessors find

• The zone exists on the diagram only. Firewall rules broader than the flow table, or an “any” rule for administration.
• Shared infrastructure. The Swift components on a virtualisation platform shared with general IT without the platform-level protections 1.3 requires.
• Undocumented flows. Monitoring agents, backup jobs and management tools that reach into the zone and were never in the flow table.
• Jump server bypass. A direct path from an administrator’s workstation to a zone component that “was left for emergencies”.
• Connector left outside. An A3 or A4 connector treated as ordinary middleware, outside the protections the CSCF now requires for it.

Each is a non-compliance on 1.1 or its dependent controls, and each is found by comparing the flow table with the actual rule base — which is why the independent assessment starts with the diagram. Our guide to SWIFT mandatory vs advisory controls lists the controls whose status makes those findings matter.

Frequently asked questions

What is the SWIFT secure zone?
The segmented network environment containing a user’s Swift infrastructure — messaging and communication interfaces, connectors, HSMs and the jump servers used to administer them — separated from the general IT environment as required by CSCF control 1.1 Swift Environment Protection.

Which architecture types need one?
A1, A2 and A3, which have a local Swift footprint. A4 users protect their customer connector environment under control 1.5 instead; type B users have no local footprint.

Are operator PCs inside the zone?
No. Operators connect from outside through a jump server inside the zone, and their PCs are constrained by 1.4 Restriction of Internet Access and 2.6 Operator Session Confidentiality and Integrity.

What changed for the secure zone in CSCF v2026?
Back-office flows crossing the boundary are now assessed under the mandatory 2.4, and customer client connectors became in-scope components of fourteen controls, extending the zone’s protections to the connector host.

What does the assessor ask for first?
The architecture diagram with the flow table, then evidence that the firewall or filtering implements exactly those flows. The gap between the two is where most 1.1 findings come from.

Where this leaves you

Build the SWIFT secure zone from the inventory and the flow table: components inside, operator PCs and general IT outside, a dedicated jump server as the only administrative path, back-office flows protected as external, and a firewall that implements the table and nothing more. Then keep the diagram true, because control 1.1 is assessed by comparing it with reality.

References

• Swift: Customer Security Programme — The programme page; CSCF v2026 control 1.1 and the architecture-type definitions are in the detailed description in the Knowledge Centre.

More on SWIFT CSP

• The SWIFT secure zone — you are here
• SWIFT architecture types: all five
• CSCF v2026: what changed
• SWIFT mandatory vs advisory controls
• SWIFT CSP attestation: five steps
• SWIFT CSCF: the independent assessment

The Secure Zone Architecture Diagram Template, the Network Segmentation and Secure Zone Policy, the Access Control and Operator Session Policy and the patch-management procedure for jump servers and operator PCs are in the SWIFT CSP Compliance Toolkit, or start with the free templates.