Azure Payment HSM v2 desafía el modelo de hardware dedicado para la seguridad de pagos
Azure Payment HSM v2 entró en vista previa pública el 17 de septiembre, desafiando el modelo de hardware dedicado que aún respalda muchos sistemas de pago críticos.
Microsoft, Marvell y Utimaco construyeron el servicio a partir de tres capas distintas. Azure opera la plataforma gestionada, Marvell proporciona el hardware LiquidSecurity y Utimaco aporta su software Atalla Payments Module.
La combinación se dirige a bancos, procesadores de pagos, instituciones financieras y otros proveedores que gestionan cargas de trabajo de pagos reguladas. Admite funciones como la emisión de tarjetas, la traducción de PIN, la autenticación de pagos móviles y la gestión de claves criptográficas.
El cambio más importante afecta a las operaciones. Las organizaciones de pagos pueden conservar el control de las claves criptográficas sin instalar ni mantener módulos físicos de seguridad de hardware para pagos, o HSM, en sus propias instalaciones.
Esa promesa crea la tensión central en torno al lanzamiento. Los HSM de pagos protegen transacciones extremadamente sensibles, pero los controles que los rodean han exigido tradicionalmente dispositivos dedicados, equipos especializados y procedimientos de recuperación cuidadosamente gestionados.
Azure Payment HSM v2 traslada una mayor parte de esa responsabilidad operativa a un servicio en la nube. Su éxito dependerá de si las instituciones aceptan ese intercambio preservando al mismo tiempo el cumplimiento normativo, la compatibilidad de las aplicaciones, una latencia predecible y límites de control claros.
Azure Payment HSM v2 combina tres capas de seguridad
El nuevo servicio empaqueta criptografía de pagos especializada como infraestructura gestionada de Azure en lugar de una implementación de hardware operada por el cliente.
Según el anuncio de la vista previa pública, Azure Payment HSM v2 presta servicio inicialmente a clientes de West US y West Europe. El despliegue regional limitado establece un límite importante en torno al lanzamiento.
Se trata de una vista previa, no de una declaración de que el servicio esté listo para todos los sistemas de pagos de producción. Microsoft y sus socios aún necesitan pruebas de clientes, evidencia operativa y una disponibilidad más amplia antes de que la plataforma pueda respaldar planes de migración globales.
Un HSM es un dispositivo informático resistente a manipulaciones que genera, protege y utiliza claves criptográficas dentro de un perímetro de hardware protegido. Un HSM de pagos incorpora operaciones especializadas requeridas por las redes de tarjetas y los procesadores de pagos.
Estas operaciones incluyen proteger PIN, traducir bloques PIN, emitir credenciales de pago, validar datos de transacciones e intercambiar claves con socios de confianza. Se diferencian de las cargas de trabajo de cifrado general o gestión de certificados.
Marvell proporciona la base de hardware mediante su tecnología LiquidSecurity HSM. La empresa diseñó ese hardware para entornos de nube densos en los que múltiples cargas de trabajo aisladas requieren un alto rendimiento criptográfico.
Utimaco proporciona la capa específica para pagos mediante Atalla Payments Module. Ese software conserva las interfaces y funciones de pago asociadas a la consolidada familia de productos Atalla.
Microsoft expone después el sistema combinado a través de Azure como un servicio gestionado. Azure asume la responsabilidad de las funciones de infraestructura subyacentes que, de otro modo, las instituciones coordinarían entre equipos, instalaciones, redes y soporte de proveedores.
Las empresas afirman que los clientes conservan la soberanía sobre las claves criptográficas. En la práctica, la soberanía de las claves significa que el cliente controla el acceso y las políticas de las claves, mientras que el operador de la nube gestiona la infraestructura de apoyo.
Esta distinción importa porque la gestión operativa y la autoridad sobre las claves no son lo mismo. Un banco puede delegar el mantenimiento del hardware sin conceder necesariamente al proveedor permiso para utilizar sus claves de pago.
El servicio está diseñado para abordar requisitos de seguridad PCI, cumplimiento normativo, auditoría, rendimiento y operaciones. Sin embargo, un servicio diseñado para esos requisitos no hace automáticamente que cada implementación de cliente sea conforme.
El cumplimiento sigue siendo una tarea compartida. Las instituciones aún deben configurar aplicaciones, controles de acceso, redes, procedimientos, monitorización y evidencia de auditoría en torno al servicio.
Los socios también describen su combinación como una primicia del sector. Esa afirmación debe interpretarse de forma acotada, porque la criptografía de pagos gestionada ya existe en otros lugares.
La afirmación distintiva se refiere a esta arquitectura específica de múltiples proveedores. Combina software de pagos Atalla, hardware HSM en la nube de Marvell y operaciones de servicio de Azure dentro de una oferta gestionada.
Eso es más preciso que afirmar que Azure inventó la criptografía de pagos gestionada. AWS ya opera un servicio de criptografía de pagos, mientras que Microsoft ya ofrece un Azure Payment HSM anterior basado en hardware de Thales.
Lo que cambió es la arquitectura y el modelo de responsabilidades dentro de Azure. La nueva versión busca sustituir más trabajo con dispositivos gestionados por el cliente por un servicio operado desde la nube.
Por qué la criptografía de pagos permaneció cerca del hardware físico
Los HSM de pagos se resistieron a la migración a la nube porque sus interfaces, procedimientos de control y obligaciones de cumplimiento se desarrollaron en torno a infraestructura bancaria dedicada.
Los servicios criptográficos de propósito general se trasladaron a las nubes públicas hace años. Las organizaciones utilizan habitualmente sistemas gestionados para claves de cifrado, certificados, firmas digitales y secretos de aplicaciones.
La criptografía de pagos siguió una trayectoria más lenta. Los bancos no pueden sustituir un HSM de pagos por una bóveda de claves convencional porque los sistemas de pago requieren comandos especializados y controles operativos.
Las aplicaciones de pago suelen comunicarse mediante interfaces vinculadas a familias de HSM consolidadas. Migrar esas aplicaciones puede requerir más que transferir claves o seleccionar otra región de nube.
Una migración puede afectar formatos de mensajes, bloques de claves, procesos de auditoría, recuperación ante desastres, latencia y conexiones con socios externos de pago. Cada cambio puede ampliar el alcance de las pruebas.
Atalla ocupa un lugar importante en esa historia. Mohamed Atalla fundó Atalla Corporation en 1973 tras desarrollar tecnología para proteger PIN entre cajeros automáticos y sistemas bancarios.
La línea de productos pasó posteriormente por varios propietarios antes de que Utimaco la adquiriera en 2018. Sus interfaces permanecieron integradas en entornos de pago durante esas transiciones.
Marvell afirma que Atalla Payment Module permite que las aplicaciones existentes utilicen interfaces Atalla conocidas con el nuevo servicio. Esa afirmación de compatibilidad aborda un obstáculo importante para la modernización de la infraestructura de pagos.
El enfoque cambia el hardware bajo el software mientras conserva la lógica de pagos orientada a las aplicaciones. Se parece más a una migración de infraestructura que a una reescritura completa de la aplicación de pagos.
Esta distinción es fundamental para el caso de negocio. Un banco obtiene poco de una infraestructura gestionada si la migración lo obliga a sustituir software transaccional estable en toda su infraestructura de pagos.
Los socios afirman que los clientes pueden dirigir las aplicaciones Atalla existentes hacia Azure Payment HSM v2. Azure gestionaría entonces el escalado, la disponibilidad, las copias de seguridad, la restauración y el hardware subyacente.
Marvell ofrece un contexto útil en su relato sobre migración a la nube. Indica que un adaptador LiquidSecurity 2 puede gestionar hasta 100.000 pares de claves y superar un millón de operaciones criptográficas por segundo.
Estas cifras describen el adaptador subyacente, no un nivel de rendimiento garantizado para cada implementación de Azure Payment HSM v2. La latencia de las aplicaciones también dependerá de las redes, la configuración del servicio y el diseño de la carga de trabajo.
Las implementaciones tradicionales crean otro problema mediante la planificación de capacidad. Las instituciones suelen aprovisionar dispositivos físicos para la demanda máxima prevista, incluso cuando el tráfico medio se sitúa muy por debajo de ese nivel.
También deben organizar redundancia, administración segura, mantenimiento de firmware, capacidad de reserva, procedimientos de copia de seguridad y recuperación ante desastres. Estas responsabilidades continúan incluso cuando la demanda transaccional es estable.
La infraestructura a escala de nube promete un modelo diferente. El proveedor puede operar una flota de hardware compartida mientras mantiene entornos de clientes aislados y protección de claves respaldada por hardware.
Ese modelo puede mejorar la utilización y acortar los ciclos de aprovisionamiento. También puede concentrar la dependencia en el operador del servicio, su presencia regional y sus procedimientos de gestión de fallos.
Por tanto, la criptografía de pagos permaneció cerca del hardware físico por razones comprensibles. El nuevo servicio no hace que estas preocupaciones desaparezcan.
En cambio, Azure Payment HSM v2 intenta conservar un comportamiento de pagos familiar mientras transfiere el trabajo de infraestructura a Microsoft. Su atractivo se basa en reducir los cambios en el límite de las aplicaciones.
La presión recae sobre los HSM de pagos operados por los clientes
Azure Payment HSM v2 ejerce la mayor presión sobre las implementaciones en las que los clientes aún gestionan por sí mismos la capacidad, disponibilidad, mantenimiento y recuperación de los dispositivos.
Microsoft ya ofrece un servicio Azure Payment HSM basado en dispositivos Thales payShield 10K. Ese servicio incorpora dispositivos de pagos dedicados en centros de datos de Azure, pero mantiene una responsabilidad sustancial del cliente.
La guía del servicio existente de Microsoft describe el producto actual como un servicio bare-metal. Los clientes asumen el control administrativo tras el aprovisionamiento y siguen siendo responsables de la configuración del HSM.
El servicio existente puede colocar dispositivos directamente dentro de una red virtual del cliente. Las instituciones pueden implementar HSM emparejados para disponibilidad y utilizar herramientas de gestión de Thales para acceso remoto seguro.
Esta disposición respalda aplicaciones alojadas en la nube sin abandonar el modelo de dispositivos dedicados. Sin embargo, no elimina el modelo operativo asociado al hardware de pagos dedicado.
Microsoft afirma que el servicio existente no cuenta con una garantía específica de tiempo de actividad para el propio HSM de pagos. Se aplican los compromisos estándar de red de Azure, pero los clientes deben diseñar su propia disponibilidad de HSM.
Su guía de implementación exige múltiples dispositivos distribuidos en sellos de infraestructura separados. Los clientes también deben implementar equilibrio de carga, copias de seguridad de claves y una implementación regional alternativa para la recuperación ante desastres.
Ese es el modelo que Azure Payment HSM v2 desafía directamente. La nueva plataforma promete un servicio gestionado en lugar de hardware alojado que los clientes deben administrar.
Para los equipos de infraestructura, esto desplaza varias decisiones recurrentes hacia Microsoft. Entre ellas se encuentran añadir capacidad, sustituir equipos fallidos, mantener la plataforma y coordinar la restauración.
Para los equipos de seguridad, la decisión es más complicada. Deben determinar si el perímetro gestionado preserva el control, la evidencia, la separación de funciones y los procedimientos de gestión de claves requeridos.
Para los equipos de finanzas y compras, la comparación va más allá de la adquisición de dispositivos. La infraestructura dedicada conlleva costes de instalaciones, soporte, personal, redundancia y ciclo de vida.
No se publicó información sobre precios junto con el anuncio de la vista previa. Por tanto, los compradores aún no pueden realizar una comparación comercial completa basándose únicamente en el anuncio.
El riesgo de migración puede importar más que los costes directos de infraestructura. Una implementación de HSM estable puede estar en el centro de muchas aplicaciones de pagos y conexiones con socios.
Cambiar ese componente puede requerir una revisión exhaustiva de certificaciones y operaciones. Incluso las interfaces compatibles no eliminan todas las diferencias entre un dispositivo local y un endpoint remoto gestionado.
El lanzamiento también presiona la cartera anterior de servicios de Azure. Microsoft deberá explicar cuándo los clientes deberían elegir v2 en lugar del HSM de pagos basado en Thales.
Algunas organizaciones pueden preferir hardware dedicado y control administrativo directo. Otras pueden priorizar una menor gestión de infraestructura y una expansión más rápida.
Microsoft no ha descrito públicamente una ruta de retirada para el servicio existente. Los clientes no deben asumir que v2 sustituye de inmediato todas las arquitecturas actuales.
La coexistencia de ambos modelos podría convertirse en una característica. Azure podría admitir implementaciones dedicadas con controles estrictos junto con criptografía de pagos gestionada para clientes con distintos requisitos de riesgo.
La versión preliminar mostrará si esa segmentación es clara. Los límites confusos entre productos podrían ralentizar la adopción, especialmente cuando los equipos de cumplimiento necesitan mapas precisos de responsabilidades.
AWS Demuestra que la seguridad de pagos gestionada ya es un mercado competitivo
La competencia más amplia no es nube frente a ausencia de nube, sino qué modelo de nube ofrece un control, compatibilidad, evidencia de cumplimiento y simplicidad operativa aceptables.
AWS Payment Cryptography ya proporciona funciones criptográficas gestionadas para el procesamiento de pagos. Los clientes acceden a esas funciones sin adquirir instancias dedicadas de HSM de pagos.
El modelo de servicio de AWS admite participantes de pagos, incluidos emisores, adquirentes, procesadores, redes, conmutadores y facilitadores de pagos. AWS afirma que el servicio aborda los requisitos de PCI PIN, PCI P2PE y PCI DSS.
AWS expone operaciones de pago mediante API de servicio, herramientas de línea de comandos, kits de desarrollo de software y su consola de administración. Las solicitudes llegan a una flota gestionada de HSM validados por PCI.
Esa arquitectura ofrece una ruta de migración diferente. Las aplicaciones se integran con interfaces de AWS en lugar de recibir una versión gestionada de un límite de aplicación Atalla conocido.
Azure Payment HSM v2 parece hacer hincapié en la compatibilidad con entornos basados en Atalla. Ese enfoque podría atraer a instituciones que desean operaciones en la nube sin rediseñar comandos de pago establecidos.
Ninguno de los enfoques es superior en todos los casos. Un servicio centrado en API puede proporcionar una integración estrecha con la identidad en la nube, la monitorización, la automatización y las herramientas de aplicaciones.
Un servicio centrado en la compatibilidad puede reducir los cambios para organizaciones ya comprometidas con una interfaz de HSM de pagos concreta. También puede simplificar las transiciones híbridas que implican implementaciones Atalla existentes.
La elección depende del punto de partida del comprador. Una nueva plataforma de pagos puede evaluar API nativas de la nube sin arrastrar décadas de historial de integración.
Un gran procesador puede tener muchas aplicaciones, scripts, procedimientos y conexiones con socios configurados en torno a una familia de HSM existente. Preservar esas interfaces puede tener un valor significativo.
Thales también sigue siendo un factor competitivo importante. Sus sistemas payShield tienen una presencia considerable en entornos de pago, incluido el servicio Azure Payment HSM existente.
Un cliente ya estandarizado en Thales puede tener pocos motivos inmediatos para cambiar. Su personal, aplicaciones, ceremonias de claves y procesos de auditoría pueden ajustarse ya a esa plataforma.
Utimaco obtiene una nueva vía hacia las cargas de trabajo de pagos en la nube mediante la colaboración entre Marvell y Microsoft. El software Atalla ya no necesita permanecer inseparable de un dispositivo Atalla tradicional.
Marvell obtiene una carga de trabajo especializada para hardware ya posicionado en torno a la seguridad en la nube. La colaboración amplía LiquidSecurity más allá de los casos de uso generales de gestión de claves y firma.
Microsoft obtiene una respuesta más sólida frente a AWS en criptografía de pagos gestionada. También obtiene una forma de atender a los clientes de Atalla sin pedirles que adopten el actual modelo operativo basado en Thales.
Ese contexto competitivo limita la afirmación de ser el primero del sector. Lo primero no es una categoría de criptografía de pagos gestionada en la nube.
La primera afirmación más defendible se refiere a una combinación gestionada de estos tres proveedores y sus respectivas capas. Los compradores deberían evaluar el servicio resultante a través de capacidades medibles, no de la etiqueta.
Esas mediciones incluyen comandos de pago compatibles, disponibilidad regional, latencia de transacción, rendimiento, compromisos de disponibilidad, herramientas de migración y documentación de cumplimiento.
La compatibilidad con el intercambio de claves también importa. Las organizaciones de pagos intercambian con frecuencia claves entre instituciones, procesadores, redes y sistemas heredados mediante procedimientos estrechamente controlados.
Un servicio gestionado debe encajar en esas relaciones externas. No puede modernizar solo la parte interna de Azure e ignorar cómo los clientes intercambian y recuperan claves críticas.
La presión competitiva debería generar documentación más clara con el tiempo. Microsoft tendrá que mostrar cómo Azure Payment HSM v2 se compara con su servicio existente y las alternativas externas.
La infraestructura gestionada no elimina el riesgo de seguridad de pagos
El servicio reduce la administración del hardware, pero los clientes siguen siendo responsables de la seguridad de las aplicaciones, el diseño de acceso, las decisiones de migración y gran parte de su resultado de cumplimiento.
La palabra “gestionado” puede generar expectativas poco realistas. Describe qué parte opera la infraestructura, no una transferencia de todas las obligaciones de seguridad al proveedor.
Microsoft puede gestionar el hardware HSM mientras un cliente configura incorrectamente los permisos de las aplicaciones. Un cliente también puede exponer flujos de trabajo sensibles mediante controles operativos débiles fuera del límite del HSM.
La seguridad de pagos depende de toda la ruta de transacción. Esa ruta incluye aplicaciones, conexiones de red, identidades de operadores, procedimientos de intercambio de claves, monitorización y sistemas posteriores.
El HSM proporciona un entorno protegido para claves y operaciones criptográficas. No puede corregir lógica de negocio fraudulenta ni credenciales comprometidas en otras partes de la aplicación.
El estado de vista previa introduce incertidumbre adicional. El anuncio no proporciona un compromiso público de nivel de servicio, un calendario final de disponibilidad, una hoja de ruta regional completa ni una estructura pública de precios.
Tampoco identifica clientes de producción con nombre. El lanzamiento no incluyó resultados independientes de rendimiento ni estudios de caso de migración.
La ausencia de esos detalles es normal en una vista previa inicial. Sin embargo, las instituciones reguladas los necesitan antes de trasladar cargas de trabajo críticas de autorización o procesamiento de PIN.
La cobertura regional es otra restricción. West US y West Europe ofrecen dos puntos de partida, pero las instituciones multinacionales suelen requerir opciones más específicas de residencia y recuperación.
Un servicio puede admitir soberanía de datos solo cuando las regiones disponibles coinciden con los requisitos legales y operativos de una organización. Los planes de recuperación transfronteriza pueden enfrentarse a restricciones independientes.
Las empresas afirman que la plataforma tiene alta disponibilidad. Los posibles usuarios aún necesitan información específica sobre redundancia, dominios de fallo, comportamiento de mantenimiento, objetivos de restauración y conmutación por error regional.
La soberanía de las claves también requiere una validación cuidadosa. Los clientes deben establecer exactamente qué operaciones puede realizar Microsoft y qué controles permanecen exclusivamente bajo autoridad del cliente.
Deben examinar cómo las claves entran y salen del servicio, cómo se protegen las copias de seguridad y cómo funciona la recuperación de emergencia. Los procedimientos de retirada merecen la misma atención.
Las afirmaciones de compatibilidad requieren pruebas con aplicaciones reales. Una interfaz Atalla conocida no garantiza tiempos, comportamiento ante errores, comandos compatibles ni herramientas operativas idénticos.
La latencia de red puede adquirir importancia para sistemas de transacciones que antes accedían a un HSM dentro del mismo centro de datos. Incluso pequeños cambios pueden afectar a sistemas con objetivos estrictos de procesamiento.
Los equipos deberían probar las cargas de trabajo normales y las condiciones de fallo. El tráfico máximo, la pérdida de conexión, la limitación de solicitudes, los eventos de mantenimiento y las interrupciones regionales pueden revelar comportamientos distintos.
También deberían confirmar cómo el servicio genera evidencia de auditoría. Los equipos de cumplimiento necesitan documentación que relacione los controles del proveedor y del cliente con los requisitos PCI aplicables.
La alineación con PCI no elimina el alcance del cliente. Las organizaciones aún necesitan evaluadores cualificados para analizar su entorno completo y sus procedimientos operativos.
La concentración de proveedores presenta otra disyuntiva. Combinar tres proveedores especializados puede producir un servicio más sólido, pero también crea dependencias entre sus hojas de ruta y organizaciones de soporte.
Los clientes necesitarán una vía clara de escalamiento cuando un incidente cruce la plataforma Azure, el hardware Marvell y el software Utimaco. Una propiedad ambigua puede prolongar el tiempo de recuperación.
Estas preguntas no niegan el valor del servicio. Definen el trabajo necesario para convertir una arquitectura atractiva en una plataforma de pagos de confianza.
Tres señales determinarán lo que suceda después
La expansión regional, los resultados verificados de migración y los compromisos de nivel de producción mostrarán si Azure Payment HSM v2 transforma la infraestructura de pagos o sigue siendo una vista previa especializada.
La primera señal es la hoja de ruta de disponibilidad de Microsoft. Las regiones adicionales reforzarían el argumento para la implementación global, el procesamiento local y la recuperación ante desastres conforme a la normativa.
Una expansión lenta restringiría el servicio a cargas de trabajo más limitadas. También podría obligar a los clientes multinacionales a conservar HSM dedicados en mercados fuera de la cobertura inicial.
La segunda señal es la evidencia de migraciones de Atalla. Microsoft y Utimaco necesitan arquitecturas de referencia que muestren cómo las aplicaciones existentes se conectan, transfieren claves, manejan fallos y preservan los controles de auditoría.
Las implementaciones de clientes identificados tendrían más peso que las afirmaciones generales de compatibilidad. Mostrarían si las instituciones pueden modernizarse sin rediseñar aplicaciones de pago críticas.
La evidencia de rendimiento debería incluir mediciones a nivel de aplicación, no solo capacidad de hardware. Los compradores necesitan resultados de latencia y rendimiento bajo patrones de transacción realistas y condiciones regionales de red.
La tercera señal es el contrato de servicio de producción. La disponibilidad general debería aportar compromisos claros que cubran niveles de servicio, responsabilidades de soporte, comportamiento de recuperación, evidencia de cumplimiento y límites operativos.
Esos detalles determinarán si los clientes tratan v2 como infraestructura crítica. Los compradores regulados rara vez basan esa decisión únicamente en especificaciones de hardware.
Las respuestas de los competidores también merecen atención, pero son secundarias frente a la ejecución. AWS puede ampliar las operaciones compatibles, mientras que Thales puede reforzar las opciones de implementación dedicada o gestionada.
El desafío inmediato de Microsoft es demostrar que su nuevo modelo de responsabilidades funciona. La empresa debe operar la infraestructura sin debilitar el control del cliente sobre las claves de pago.
Para Marvell, la prueba se refiere a la economía del hardware en la nube y a un rendimiento predecible. Su plataforma LiquidSecurity debe admitir cargas de trabajo especializadas de pagos bajo condiciones operativas exigentes.
Para Utimaco, la prueba es la portabilidad del software. La compatibilidad con Atalla debe sobrevivir a la transición desde dispositivos conocidos hacia el entorno de servicio gestionado de Microsoft.
Los bancos y procesadores de pagos deberían comenzar con evaluaciones acotadas. Una carga de trabajo controlada puede revelar brechas de integración sin poner de inmediato en riesgo el tráfico central de autorizaciones.
Los equipos deberían documentar sus dependencias actuales de HSM antes de realizar pruebas. Ese inventario debería incluir comandos, formatos de clave, aplicaciones, intercambios con socios, objetivos de latencia y procedimientos de recuperación.
Después pueden comparar la vista previa con el servicio Azure existente, AWS Payment Cryptography y su infraestructura actual. El resultado relevante es el ajuste operativo, no una preferencia general por la nube.
Azure Payment HSM v2 ofrece a las organizaciones de pagos una nueva opción creíble para separar el control de las claves de las operaciones de hardware. No hace que esa separación sea automática ni esté exenta de riesgos.
La siguiente pregunta es práctica: ¿puede Microsoft documentar los controles, la disponibilidad y la ruta de migración con el nivel de detalle suficiente para que los clientes regulados confíen en el modelo administrado?
Las organizaciones que evalúen el servicio deberían vigilar esas tres señales antes de comprometer una ruta crítica de transacciones. Prueben el comportamiento regional, validen la compatibilidad con Atalla y exijan compromisos de producción precisos.
Si esos resultados se sostienen, Azure Payment HSM v2 presionará a las implementaciones dedicadas al hacer que la propiedad del hardware sea opcional para más cargas de trabajo de pagos. De no ser así, las instituciones mantendrán los dispositivos conocidos cerca de sus sistemas más sensibles.
