El Marco de controles de seguridad para clientes de SWIFT: Criptografía para la banca corresponsal

Para las instituciones conectadas a la red SWIFT, la criptografía se ha convertido en una cuestión de gobernanza, y no solo en un detalle técnico. El Marco de Controles de Seguridad para Clientes de SWIFT (CSCF) vincula ahora la gestión de claves, el cifrado y la firma directamente con la confianza que las contrapartes depositan en usted.

Este cambio es importante porque todos los usuarios de SWIFT deben certificar su nivel de seguridad cada año. El estado de la certificación es visible para las contrapartes y los organismos reguladores, por lo que los controles deficientes o inexistentes no quedan ocultos en un informe de auditoría interna. La falta de certificación o el incumplimiento sustancial se convierten en factores determinantes a la hora de decidir si se mantienen las relaciones de corresponsalía.

Esta guía explica cuáles son los requisitos del CSCF y por qué el Control 2.4 cambia el panorama criptográfico. A continuación, muestra cómo se corresponden los controles con las capacidades criptográficas y cómo demostrar tu nivel de seguridad.

Qué es el Marco de controles de seguridad para clientes de SWIFT

El Marco de Controles de Seguridad para Clientes de SWIFT (CSCF) es la base de referencia de seguridad que SWIFT publica para todas las organizaciones de su red. SWIFT publica una nueva versión cada mes de julio. Los usuarios deben presentar su declaración de conformidad con dicho marco entre el 1 de julio y el 31 de diciembre del año siguiente. La versión CSCF v2026 se publicó a mediados de 2025 y rige el plazo de declaración de conformidad de 2026. Esto da tiempo a las entidades para subsanar las deficiencias antes de que se abra el plazo de declaración de conformidad.

El marco actual, CSCFv2026, define 32 controles: 26 obligatorios y 6 recomendados. Cada control se corresponde con normas reconocidas, entre las que se incluyen la ISO 27002, la PCI DSS, la SOC 2 y el NIST CSF. Los equipos pueden adaptar las obligaciones de SWIFT a los programas que ya tienen en marcha.

El ámbito de aplicación va más allá de la propia plataforma de mensajería. Entre las partes incluidas en dicho ámbito se encuentran:

• Todos los usuarios de SWIFT, independientemente del tipo de arquitectura, incluidos aquellos que acceden a la red a través de un proveedor de servicios.
• Empresas de servicios y agentes de externalización que gestionan la conectividad por cuenta de terceros.
• Entidades del grupo sujetas a una obligación de certificación común.

Cada una de estas partes tiene su propia responsabilidad de certificar, por lo que el control criptográfico debe poder demostrarse a lo largo de toda la cadena de conectividad.

El gran cambio: la norma Control 2.4 pasa de ser de carácter orientativo a obligatorio

El cambio reciente más relevante es el Control 2.4, «Seguridad del flujo de datos en el back office», que ha pasado de ser de carácter recomendatorio a obligatorio. Este único cambio amplía el marco mucho más allá de la Zona Segura de SWIFT.

Requisitos de Control 2.4

El control 2.4 aplica el alcance por fases establecido en el apéndice H. La cobertura obligatoria en la versión 2026 incluye los servidores puente entre la zona segura y los primeros saltos del back office, los flujos entre los servidores puente y la zona segura que no están protegidos de extremo a extremo, y los nuevos flujos directos. Los intercambios directos heredados siguen siendo de carácter recomendatorio, y SWIFT indica un hito provisional para 2028. Para el tipo de arquitectura B, el control 2.4 no es aplicable.

La versión CSCF v2026 también incluye los conectores de cliente en el ámbito de aplicación obligatorio. Las API, el middleware y los clientes de transferencia de archivos requieren ahora una correspondencia y una evaluación formales, lo que puede hacer que un usuario pase del tipo de arquitectura B al A4. Para muchas organizaciones, ese alcance más amplio amplía lo que un evaluador independiente espera revisar.

Por qué es importante para la protección criptográfica

La protección criptográfica ya no puede limitarse a los componentes de mensajería de la marca SWIFT. Ahora, la obligación se aplica a los datos.

Las entidades deben realizar un inventario de los flujos de datos entre la zona segura y los sistemas de back-office. A continuación, deben demostrar que los mensajes financieros, los archivos de conciliación y los datos de referencia permanecen protegidos independientemente del recorrido que sigan. En la práctica, esto significa que el cifrado y la autenticación de identidad se extienden a un conjunto mucho más amplio de sistemas internos que antes.

Cómo se corresponden los requisitos de SWIFT con los controles criptográficos

El marco se presenta como una política, pero cada obligación se traduce en una capacidad criptográfica concreta. Analizar los controles de esta forma permite convertir los requisitos abstractos en un plan de implementación.

Evitar que se vean comprometidas las credenciales

El principio 4, «Prevenir la vulneración de las credenciales», abarca la política de contraseñas (4.1) y la autenticación multifactorial (4.2). La generación y el almacenamiento de claves y certificados relacionados con SWIFT, respaldados por el sistema de gestión de claves ( Hardware), se ajustan al control 5.2, «Gestión de tokens», de modo que las claves privadas nunca quedan expuestas en sistemas de uso general.

Medida de control 2.4: cifrado del flujo de datos de las funciones administrativas

La norma Control 2.4 exige la confidencialidad, la integridad y la autenticidad de los datos relacionados con SWIFT que se intercambian entre los primeros nodos de back-office y los componentes de la infraestructura de SWIFT. Esta protección se aplica mientras los datos circulan entre la Zona Segura y los sistemas de back-office o de enlace. El cifrado en tránsito, respaldado por certificados gestionados, es el mecanismo que cumple con este requisito.

Reducir la superficie de ataque y las vulnerabilidades

El principio 2, «Reducir la superficie de ataque y las vulnerabilidades», tiene como objetivo reducir la exposición de los componentes incluidos en el ámbito de aplicación. Dos capacidades criptográficas asumen la mayor parte de la carga:

• Autenticación basada en certificados que reduce la dependencia de credenciales estáticas o compartidas.
• Los archivos « software » y de configuración están firmados y se han verificado antes de su implementación, por lo que su integridad es demostrable.

Inventario de activos criptográficos y flujos de datos

Todo lo anterior se basa en un inventario actualizado de los flujos de datos y de los mecanismos criptográficos que protegen cada uno de ellos. Ese inventario constituye la base de las pruebas que un evaluador independiente esperará ver.

Prueba de ello: certificación KYC-SA y evaluación independiente

Cumplir con los controles es solo la mitad del trabajo. También hay que demostrarlo. La Declaración de Seguridad «Conoce a tu cliente» (KYC-SA) anual es la forma en que cada parte deja constancia de su cumplimiento. El Marco de Evaluación Independiente es el mecanismo mediante el cual se valida dicha declaración. Desde 2021, la declaración debe ir acompañada de una evaluación independiente, ya sea interna o externa, que abarque al menos todos los controles obligatorios aplicables. La autodeclaración por sí sola no es suficiente. El plazo va del 1 de julio al 31 de diciembre.

La distinción que suele plantear dificultades a los equipos es la que existe entre las pruebas y las políticas. Los evaluadores analizan las pruebas demostradas, no solo las declaraciones de política. Una norma escrita que establezca que los flujos de datos están encriptados tiene poco peso si no se acompañan de pruebas que lo demuestren en la práctica.

Para estar preparado para la auditoría, elabora respuestas claras y aporta pruebas que las respalden para preguntas como las siguientes:

• Tu inventario de flujos de datos de Control 2.4 y cómo se mantiene actualizado.
• HSM y pruebas de custodia de claves para las claves relacionadas con SWIFT.
• La exactitud de tu declaración KYC-SA en comparación con la configuración real.
• Documentación de la evaluación independiente y decisiones sobre el alcance.
• Integración de la correspondencia de ámbitos entre el servidor y el middleware.
• Software y la verificación de la firma de la configuración.

Las instituciones que pueden presentar estas pruebas cuando se les solicitan superan la evaluación con mayor rapidez y acreditan sus resultados con confianza.

De cara al futuro: preparación para la era poscuántica de SwiftNet y las redes de corresponsales

El cumplimiento de las normas SWIFT también apunta hacia la transición poscuántica, ya que los datos financieros de larga duración marcan el plazo real. Los mensajes y los datos de referencia recopilados hoy en día podrían seguir siendo sensibles cuando aparezca un ordenador cuántico relevante desde el punto de vista criptográfico.

La señal más importante para este público es SwiftNet. Se prevé que SwiftNet sea compatible con la PQC (cifrado de campo cuántico) alrededor de 2027, con un plazo de migración que se mide en meses, más que en años. Con más de 11 500 entidades bancarias y de valores, infraestructuras de mercado y empresas conectadas, esa transición afecta de golpe a todo el ecosistema de corresponsales.

Esa magnitud genera un problema de «eslabón más débil». Las entidades más pequeñas que se quedan rezagadas en la migración generan una exposición que una red de corresponsales no puede absorber discretamente, ya que el riesgo se propaga a todas las partes con las que intercambian mensajes. Empezar ahora mismo a realizar un inventario criptográfico es la forma más práctica de estar preparados para cuando se abra la ventana de oportunidad.

Cómo Keyfactor ayudarte Keyfactor

Cada una de las obligaciones anteriores se traduce en una capacidad criptográfica, y Keyfactor establece una correspondencia entre dichas capacidades y un camino claro desde el requisito hasta su implementación.

• Keyfactor AgileSec crea el flujo de datos y el inventario de activos criptográficos que sirven de base para las pruebas de los evaluadores y la planificación poscuántica.
• EJBCA emite claves y certificados respaldados por HSM para la protección de credenciales (Objetivo 4) y cifra los flujos de datos de las funciones administrativas (Control 2.4).
• Keyfactor SignServer archivos « software » y de configuración para los componentes y el middleware relacionados con SWIFT.
• Keyfactor Command centraliza la elaboración de informes que asocian los controles criptográficos a números de control específicos del CSCF para el evaluador, y gestiona el ciclo de vida de los certificados en el marco del Control 2.4.

En conjunto, estas herramientas te ayudan a cumplir con el CSCF en la actualidad y a prepararte para la futura transición poscuántica a SwiftNet. Solicitar una demo Descubre cómo « Keyfactor » garantiza el cumplimiento de los requisitos criptográficos de SWIFT en todo tu entorno.

¿Tienes alguna pregunta sobre el Marco de controles de seguridad para clientes de SWIFT? Tenemos las respuestas.

What is the SWIFT Customer Security Controls Framework?
The CSCF v2026 is the security baseline SWIFT publishes for every organization on its network. It defines 32 controls, 26 mandatory and 6 advisory, mapped to standards such as ISO 27002, PCI DSS, SOC 2, and NIST CSF. SWIFT updates it each year.

Who has to comply with the CSCF?
Compliance applies to all SWIFT users regardless of architecture type. Connectivity providers and outsourcing agents are covered by separate SWIFT programs, and attestation responsibility stays with the user, so cryptographic control has to be provable across the full connectivity chain.

What is Control 2.4?
Control 2.4, Back Office Data Flow Security, requires protecting financial messages, reconciliation files, and reference data. This data flows between the SWIFT Secure Zone and back-office or bridging systems. It has moved from advisory to mandatory, extending the framework beyond core secure infrastructure.

Why does Control 2.4 matter for cryptography?
It means cryptographic protection can no longer stop at SWIFT-branded components. Institutions must inventory data flows to back-office systems and demonstrate that data stays encrypted and authenticated wherever it travels.

What is KYC-SA attestation?
Know Your Customer Security Attestation (KYC-SA) is the annual process where each party records its CSCF compliance. It is validated through the Independent Assessment Framework, and assessors expect demonstrated evidence rather than policy statements alone.

How should institutions prepare for a SWIFT independent assessment?
Prepare evidence for the Control 2.4 data flow inventory, HSM and key custody, KYC-SA accuracy, independent assessment documentation, scope mapping for bridging servers and middleware, and signing verification. Keeping this evidence current shortens assessment.

How does the CSCF connect to post-quantum readiness?
Long-lived financial data sets the deadline for quantum-safe protection. SwiftNet is expected to become PQC-enabled around 2027, with a migration window measured in months. Building a cryptographic inventory now is the practical first step.

How can Keyfactor help with SWIFT compliance?
Keyfactor maps SWIFT cryptographic requirements to specific solutions: EJBCA for HSM-backed issuance and encryption, Keyfactor Command for control-mapped reporting and certificate lifecycle management, AgileSec for cryptographic inventory, and SignServer for signing SWIFT-related software and configuration.