Cómo las versiones 4.0 y 4.0.1 de la norma PCI DSS establecen nuevas reglas para el cifrado de los datos de los titulares de tarjetas y la gestión de claves

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.

What does PCI DSS require for protecting stored cardholder data?
Stored cardholder data must be rendered unreadable using strong cryptography, tokenization, or truncation. PCI DSS expects file, column, or field level encryption with independent key management layered on top of full disk encryption, not full disk encryption alone. That separation keeps a compromised host from automatically exposing the data it holds.

When did the future-dated PCI DSS v4.0.1 requirements become mandatory?
They became mandatory on March 31, 2025. The 51 requirements that were treated as best practice under v4.0 are now scored in every assessment, so the transition window has closed.

What does PCI DSS Requirement 12.3.3 cover?
Requirement 12.3.3 calls for a documented inventory of the cryptographic cipher suites and protocols in use. That inventory must be reviewed on a defined cadence of at least once every 12 months to identify deprecated or weakening algorithms before they become a vulnerability.

Does PCI DSS require multi-factor authentication for cardholder data?
Yes. PCI DSS v4.0.1 mandates multi-factor authentication for all access to the cardholder data environment, including remote and third-party vendor access. Certificate-based, phishing-resistant methods provide the strongest assurance.

What encryption is required for cardholder data in transit?
Cardholder data sent across open, public networks must use strong cryptography, meaning TLS 1.2 or higher. Primary account numbers must never be sent unprotected through end-user messaging technologies such as email or chat.

What key management controls does PCI DSS expect?
PCI DSS requires documented procedures covering key generation, distribution, storage, rotation, and retirement. Manual key operations must use dual control and split knowledge so no single person can compromise a key.

Is PCI DSS a law?
No. PCI DSS is a contractual standard rather than a statute, but non-compliance carries real commercial consequences, including fines from acquiring banks, higher per-transaction fees, and potential loss of the ability to accept card payments.

How should PCI DSS teams prepare for post-quantum cryptography?
Start with the cryptographic inventory that Requirements 4.2.1.1 and 12.3.3 already demand, then assess those algorithms against NIST’s published deprecation timelines. Because long-lived transaction data can be harvested now and decrypted later, planning the migration early protects data whose sensitivity outlasts today’s algorithms.