La cuenta atrás ha terminado, al igual que el periodo de gracia. La norma PCI DSS v4.0.1 se publicó en junio de 2024 como una versión de mantenimiento de la v4.0 (marzo de 2022), que incluía 64 requisitos nuevos o actualizados, de los cuales 51 tenían una fecha de entrada en vigor futura. Esos 51 requisitos pasaron a ser obligatorios el 31 de marzo de 2025.
Ese plazo convirtió la criptografía de la norma PCI DSS de un elemento de la hoja de ruta en un requisito operativo en vigor. Para los comerciantes, los proveedores de servicios y los evaluadores de seguridad cualificados (QSA) que los evalúan, el cifrado y la gestión de claves ocupan ahora un lugar central en cualquier conversación sobre los datos de los titulares de tarjetas. Si tus controles se diseñaron según la antigua línea de base, esa discrepancia ya es un posible fallo de auditoría a la espera de aparecer.
Esta guía describe los controles criptográficos que rigen los datos de los titulares de tarjetas según la versión 4.0.1, qué aspectos comprueban los evaluadores y cómo crear un programa que cumpla tanto este requisito como el siguiente.
Por qué la criptografía ha pasado a ocupar un lugar central en la norma PCI DSS
La norma PCI DSS es una norma contractual, no una ley. La aceptas a través de tu banco adquirente y de las entidades emisoras de las tarjetas, por lo que su cumplimiento es de carácter comercial y no legal. El incumplimiento puede acarrear multas por parte de los adquirentes, comisiones más elevadas por transacción y, en el peor de los casos, la pérdida total del derecho a aceptar tarjetas.
La criptografía tiene un gran peso en todo esto, ya que es la forma en que se protegen los datos de los titulares de tarjetas, independientemente de dónde se almacenen o por dónde circulen. La actualización a la versión 4.0 elevó el listón y la versión 4.0.1 aclaró la redacción relativa al cifrado, la gestión de claves, la autenticación y la visibilidad criptográfica; de ahí que tantos de los nuevos requisitos obligatorios se refieran a estas áreas.
La determinación del alcance suele ser el primer escollo al que se enfrentan las organizaciones. Si se evalúa erróneamente qué sistemas almacenan, procesan o transmiten datos de cuentas, todos los controles criptográficos posteriores heredan ese error. Definir correctamente el alcance es la base sobre la que se sustenta todo lo demás.
Los requisitos que rigen la criptografía de la norma PCI DSS
Seis áreas de control interrelacionadas definen cómo deben protegerse los datos de los titulares de tarjetas según las versiones 4.0 y 4.0.1. Cada una de ellas es independiente, y juntas constituyen la columna vertebral de un programa defendible. A continuación se explica qué requiere cada una y por qué es importante.
Protección de los datos de las cuentas almacenados (Requisitos 3.5 a 3.6)
Los datos de los titulares de tarjetas almacenados deben hacerse ilegibles mediante criptografía de alta seguridad, tokenización o truncamiento. No es admisible almacenar un número de cuenta principal (PAN) sin cifrar.
El cifrado completo del disco por sí solo no es suficiente en muchos entornos. La estrategia más sólida consiste en superponer el cifrado a nivel de archivo, columna o campo al cifrado del disco, manteniendo la gestión de claves independiente de los controles de acceso propios del sistema operativo. Esa separación garantiza que un host comprometido no exponga automáticamente los datos que contiene.
Gestión de las claves criptográficas a lo largo de su ciclo de vida (Requisitos 3.6 a 3.7)
La seguridad del cifrado depende de la solidez de las claves que lo sustentan, por lo que la norma PCI DSS exige procedimientos documentados que abarquen todo el ciclo de vida de las claves: generación, distribución, almacenamiento, rotación y retirada. Cada etapa debe contar con un proceso definido y repetible.
En lo que respecta a las operaciones manuales con claves, la norma exige un control dual y una división de la información. Ninguna persona por sí sola debe poder reconstruir o hacer un uso indebido de una clave. Esta es una de las áreas que los evaluadores examinan con mayor detenimiento, por lo que la documentación debe coincidir con lo que realmente ocurre en la práctica.
Cifrado de los datos de los titulares de tarjetas durante su transmisión (Requisitos 4.1 a 4.2)
Los datos de las tarjetas que circulan por redes públicas y abiertas deben protegerse con criptografía sólida, lo que significa que los algoritmos y la solidez de las claves deben cumplir ciertos requisitos mínimos (siendo 112 bits el tamaño mínimo de la clave). Por ejemplo, la versión 1.2 de « TLS » se convierte en el mínimo práctico que esperan los evaluadores. Los protocolos antiguos y las configuraciones poco seguras son precisamente lo que esta actualización pretende eliminar.
Hay una norma relacionada que se suele pasar por alto fácilmente: el PAN nunca debe enviarse sin protección a través de canales de mensajería para usuarios finales, como el correo electrónico o el chat. Mantener un inventario de las claves y los certificados de confianza utilizados para proteger el PAN durante su transmisión permite que este control sea verificable, en lugar de basarse en su mera suposición.
Autenticación del acceso al entorno de datos del titular de la tarjeta (Requisitos 8.4 a 8.5)
Ahora, todo acceso al entorno de datos de los titulares de tarjetas (CDE) requiere una autenticación multifactorial, y el método más seguro es la autenticación multifactorial basada en certificados y resistente al phishing. Esto se aplica tanto al acceso remoto como al acceso de proveedores externos, no solo al personal interno.
El mandato ampliado del MFA (autenticación multifactorial) del Requisito 8 es una de las deficiencias más habituales de cara a 2026. Muchas organizaciones han cubierto los inicios de sesión administrativos, pero han dejado de lado las cuentas de servicio, las conexiones de proveedores o determinados sistemas CDE. Subsanar esas deficiencias es ahora imprescindible.
Creación de un inventario de conjuntos de cifrado criptográfico (Requisitos 4.2.1.1 y 12.3.3)
No se puede proteger lo que no se ve, por lo que la versión 4.0.1 exige un inventario de los conjuntos de cifrado y los protocolos en uso, que debe revisarse con una periodicidad definida de, al menos, una vez cada 12 meses. Esta revisión permite detectar los algoritmos obsoletos o con vulnerabilidades antes de que lo hagan un atacante o un evaluador.
Esta es otra de las deficiencias más mencionadas de cara a 2026. Un inventario criptográfico es fácil de describir, pero realmente difícil de mantener manualmente, sobre todo en entornos híbridos y multinube.
Protección de las páginas y los scripts de pago (Requisitos 6.4.3 y 11.6.1)
Los scripts que se ejecutan en las páginas de pago deben estar autorizados, registrados y sujetos a supervisión para detectar posibles manipulaciones. Esto amplía el concepto de integridad del código al navegador, donde los ataques de skimming se dirigen cada vez más al proceso de pago.
La solución práctica consiste en utilizar scripts firmados y autorizados, junto con un sistema de detección de manipulaciones. De este modo, se aplica la disciplina de la firma de código a los flujos que se encuentran en contacto directo con los datos de los titulares de tarjetas.
Lo que realmente preguntan los auditores y evaluadores
Las pruebas de preparación para la auditoría en las versiones 4.0 y 4.0.1 se convierten en una lista de comprobación que puedes utilizar para realizar una autoevaluación hoy mismo. Repasa cada uno de estos puntos antes de que lo haga un evaluador:
- ¿Se han cerrado y documentado los 51 requisitos con fecha futura, y no solo se han planificado?
- ¿Se documenta la gestión de claves de principio a fin, con un sistema de doble control y de distribución de conocimientos?
- ¿Cubre MFA todas las vías de acceso al CDE, incluidos el acceso remoto y el de los proveedores?
- ¿Existe algún inventario criptográfico actualizado de conjuntos de cifrado, protocolos, claves y certificados?
- ¿Podéis presentar la cadena de certificaciones de los proveedores de servicios para cada uno de los proveedores incluidos en el ámbito de aplicación?
- ¿Se han validado la segmentación y el alcance para garantizar que los límites del CDE sean válidos?
- ¿Cada frecuencia definida por la entidad y cada control de enfoque personalizado cuenta con un análisis de riesgo específico, documentado y actualizado que lo respalde?
Si hay alguna respuesta que no esté clara, ahí es donde hay que centrarse en primer lugar. Los evaluadores se basan en las pruebas, por lo que la documentación que refleje controles reales y en funcionamiento tiene mucho más peso que la mera intención.
Preparar los datos de las tarjetas para el futuro: el horizonte poscuántico
El inventario criptográfico que elabores para el PCI DSS cumple una doble función. La misma visibilidad que exigen los requisitos 4.2.1.1 y 12.3.3 constituye la base para identificar los algoritmos vulnerables a los ataques cuánticos en todo tu entorno.
El plazo está más cerca de lo que parece. En 2024, el NIST ultimó las primeras normas criptográficas poscuánticas (FIPS 203, 204 y 205, agosto de 2024) y publicó un calendario de transición que deja en desuso, para 2030, algoritmos de clave pública ampliamente utilizados, como RSA y la criptografía de curva elíptica, con el objetivo de su prohibición total en 2035. Los datos de pago con un largo periodo de conservación están expuestos a ataques del tipo «recoger ahora, descifrar más tarde», en los que un atacante captura hoy el tráfico cifrado para descifrarlo una vez que se disponga de un ordenador cuántico.
Esto hace que los datos de transacciones de larga duración sean una preocupación actual, no futura. Un inventario criptográfico bien gestionado se convierte en la lista de materiales criptográficos (CBOM), que sirve de base para una migración ordenada hacia la criptografía poscuántica.
Cómo « Keyfactor » es compatible con la criptografía y la gestión de claves de la norma PCI DSS
Keyfactor se corresponde directamente con cada área de control de la norma PCI DSS, por lo que puedes pasar de los requisitos a las capacidades sin necesidad de combinar varias herramientas puntuales.
- Keyfactor AgileSec: detecta y cataloga conjuntos de cifrado, protocolos, claves y algoritmos para cumplir con el requisito 12.3.3 de inventario y evaluar el riesgo criptográfico.
- EJBCA: emite los certificados necesarios para el cifrado de los datos almacenados y de la transmisión, así como para la autenticación multifactorial (MFA) basada en certificados del CDE.
- SignServer: firma y protege los scripts de las páginas de pago, lo que permite aplicar controles de integridad en los flujos relacionados con los datos de los titulares de tarjetas.
- Keyfactor Command: ofrece una gestión documentada y automatizada del ciclo de vida de las claves y los certificados, desde su generación hasta su retirada, con el registro de auditoría que esperan los auditores.
Detrás de estos productos, el plano de control de confianza « Keyfactor » actúa como un único sistema de registro para todos los activos criptográficos y las identidades de los dispositivos. Funciona en un bucle continuo que supervisa, analiza, asigna, coordina y gestiona las claves y los certificados en toda la infraestructura bancaria central, de pagos y de banca abierta, de modo que la documentación que solicite cualquier marco normativo provenga de un único lugar.
Conclusión: un programa, no un proyecto
La criptografía de la norma PCI DSS es ahora una capacidad operativa, no una iniciativa puntual de corrección. Los 51 requisitos con fecha de entrada en vigor futura son obligatorios, y los controles que los sustentan —el cifrado, la gestión de claves, la autenticación multifactorial (MFA) y el inventario criptográfico— solo conservan su valor cuando se aplican de forma continua.
La buena noticia es que esa misma base también cumple el siguiente requisito. Un inventario criptográfico actualizado que cumpla con la versión 4.0.1 es también el punto de partida para tu migración poscuántica. Créalo una vez, gestionalo de forma continua, y cada nueva exigencia se convertirá en una simple actualización en lugar de una emergencia.
¿Estás listo para saber cuál es la situación actual de tu entorno de datos de titulares de tarjetas? Solicitar una demo Descubre cómo Keyfactor te ayuda a realizar un inventario, automatizar y gestionar la criptografía necesaria para cumplir con la norma PCI DSS.
¿Tienes dudas sobre la criptografía de la norma PCI DSS? Tenemos las respuestas.
¿Qué exige la norma PCI DSS para proteger los datos almacenados de los titulares de tarjetas?
Los datos almacenados de los titulares de tarjetasdeben hacerse ilegibles mediante criptografía robusta, tokenización o truncamiento. La norma PCI DSSexige un cifrado a nivel de archivo, columna o campo con una gestión independiente de claves, además del cifrado completo del disco, y no solo el cifrado completo del disco. Esa separación evita que un host comprometido exponga automáticamente los datos que contiene.
¿Cuándo entraron en vigor los requisitos de la norma PCI DSS v4.0.1 con fecha futura?
Entraron en vigorel 31 de marzo de 2025. Los 51 requisitos que se consideraban «buenas prácticas» en la versión 4.0 ahora se evalúan en cada auditoría, por lo que el plazo de transición ha finalizado.
¿Qué abarca el requisito 12.3.3 de la norma PCI DSS?
El requisito 12.3.3 exige disponer de un inventario documentado de los conjuntos de cifrado y los protocolos criptográficos en uso. Dicho inventario debe revisarse con una periodicidad definida, como mínimo una vez cada 12 meses, para identificar los algoritmos obsoletos o que presentan debilidades antes de que se conviertan en una vulnerabilidad.
¿Exige la norma PCI DSS la autenticación multifactorial para los datos de los titulares de tarjetas?
Sí. La norma PCI DSS v4.0.1 exige la autenticación multifactorial para todos los accesos al entorno de datos de los titulares de tarjetas, incluidos los accesos remotos y los de terceros proveedores. Los métodos basados en certificados y resistentes al phishing ofrecen la mayor garantía.
¿Qué tipo de cifrado se requiere para los datos de los titulares de tarjetas en tránsito?
Los datos de los titulares de tarjetas que se envían a través de redes públicas abiertas deben utilizar una criptografía sólida, es decir, la norma « TLS » 1.2 o superior. Los números de cuenta principales nunca deben enviarse sin protección a través de tecnologías de mensajería para usuarios finales, como el correo electrónico o el chat.
¿Qué controles de gestión de claves exige la norma PCI DSS?
La norma PCI DSS exige procedimientos documentados que abarquen la generación, distribución, almacenamiento, rotación y retirada de claves. Las operaciones manuales con claves deben seguir el principio de doble control y división de conocimientos, de modo que ninguna persona por sí sola pueda comprometer una clave.
¿Es la norma PCI DSS una ley?
No. La norma PCI DSS es una norma contractual y no una ley, pero su incumplimiento conlleva consecuencias comerciales reales, como multas impuestas por los bancos adquirentes, comisiones más elevadas por transacción y la posible pérdida de la capacidad de aceptar pagos con tarjeta.
¿Cómo deben prepararse los equipos de PCI DSS para la criptografía poscuántica?
Empiece por el inventario criptográfico que ya exigen los requisitos 4.2.1.1 y 12.3.3, y a continuación evalúe esos algoritmos según los plazos de obsolescencia publicados por el NIST. Dado que los datos de transacciones de larga duración pueden recopilarse ahora y descifrarse más adelante, planificar la migración con antelación protege los datos cuya sensibilidad perdura más allá de los algoritmos actuales.
