Especificación de cumplimiento de PCI

Publicado: abril de 2021. Actualizado: agosto de 2026. Revisado por el equipo de Asesoría en Cumplimiento Normativo de Encryption Consulting.

Este artículo ofrece un análisis técnico detallado, a nivel de especificación, de los requisitos de PCI DSS en la capa criptográfica y de gestión de claves: selección de algoritmos y protocolos, el modelo de amenazas subyacente a cada control, las dependencias de custodia de claves y los patrones de implementación concretos. Si su equipo necesita la ruta de certificación completa, los niveles de comercio, los tipos de SAQ y la guía a nivel de programa, consulte nuestro artículo complementario, «Guía integral para lograr y mantener el cumplimiento de PCI DSS» , que abarca el programa de cumplimiento más amplio. Esta publicación está dirigida a los equipos de seguridad e ingeniería que ya saben que deben cumplir con la normativa y que ahora están diseñando los sistemas que deben superar la revisión técnica de un evaluador.

¿Qué especifica la norma PCI DSS en materia de criptografía?

La norma PCI DSS especifica que cualquier dato del titular de la tarjeta, ya sea en reposo o en tránsito, debe protegerse mediante criptografía robusta, definida por el Consejo de Estándares de Seguridad PCI (PCI SSC) como algoritmos y niveles de clave ampliamente probados, aceptados por la comunidad criptográfica internacional y libres de vulnerabilidades prácticas conocidas para el tamaño de clave utilizado. En la práctica, esto significa un mínimo de 112 bits de seguridad efectiva de clave, lo que descarta por completo DES, 3DES de clave única y RC4, y orienta a los implementadores hacia AES-256, RSA de 2048 bits o superior, y ECC de 224 bits o superior.

Algunos términos se repiten a lo largo de la especificación y de este artículo, por lo que conviene definirlos con precisión antes de continuar:

• PCI DSS (Estándar de seguridad de datos de la industria de tarjetas de pago): el estándar de seguridad técnica y operativa que mantiene el PCI SSC para cualquier organización que almacene, procese o transmita datos de tarjetas de pago.
• PAN (Número de Cuenta Principal): el número de tarjeta en sí, el elemento de datos específico que la mayoría de los controles criptográficos PCI DSS existen para proteger.
• CDE (Entorno de Datos del Titular de la Tarjeta): las personas, los procesos y la tecnología que almacenan, procesan o transmiten los datos de los titulares de tarjetas, además de cualquier sistema que pueda afectar la seguridad de esos datos.
• QSA (Evaluador de Seguridad Calificado): una persona certificada por el PCI SSC para realizar evaluaciones formales in situ del PCI DSS.
• ROC (Informe de Cumplimiento): el informe detallado que elabora un QSA documentando cómo se probó y validó cada requisito, obligatorio para los comerciantes de Nivel 1 y la mayoría de los proveedores de servicios.
• SAQ (Cuestionario de Autoevaluación): la herramienta de validación autodeclarada que utilizan los pequeños comerciantes en lugar de una auditoría completa dirigida por un QSA.

Los requisitos criptográficos de la especificación se dividen en tres problemas de ingeniería distintos: hacer ilegible el PAN almacenado (Requisito 3), proteger los datos del titular de la tarjeta en tránsito (Requisito 4) y autenticar a cada usuario que accede al CDE (Requisito 8). Cada uno tiene su propio modelo de amenazas y su propio algoritmo o protocolo, y las secciones siguientes los analizan en el orden en que normalmente se abordan en una revisión de arquitectura.

¿Qué algoritmos y protocolos requiere PCI DSS?

La norma PCI DSS exige el uso de AES-256 o un algoritmo de seguridad equivalente para proteger los datos de las cuentas almacenadas, y TLS 1.2 como versión mínima obligatoria del protocolo para los datos de los titulares de tarjetas en tránsito a través de redes públicas abiertas, siendo TLS 1.3 la versión preferida para cualquier implementación nueva. Si bien la norma en sí no especifica una versión de protocolo concreta, la guía del PCI SSC descarta SSL y las primeras versiones de TLS (TLS 1.0 y 1.1) por no cumplir ya con la definición de criptografía robusta.

Modelo de amenazas para datos en reposo y en tránsito

Los datos de los titulares de tarjetas almacenados son objetivo de ataques mediante la vulneración de bases de datos, el uso indebido por parte de personal interno, la exposición de copias de seguridad y registros, y el movimiento lateral desde un sistema de menor sensibilidad hacia el almacén de datos, por lo que el control debe sobrevivir a un atacante que ya tenga acceso de lectura a la capa de almacenamiento. Los datos en tránsito se enfrentan a un modelo de amenazas diferente: la interceptación de ataques de intermediario, los ataques de degradación de protocolo y las vulnerabilidades a nivel de cifrado, como POODLE y BEAST, que atacan específicamente a SSL y las primeras versiones de TLS. Una prueba QSA (Requisito 4) analizará si algún receptor aún acepta una versión de protocolo obsoleta, en lugar de simplemente confirmar que TLS esté habilitado en algún lugar de la pila.

Guía para la selección de algoritmos y protocolos

Para datos en reposo, generalmente se prefiere AES-256-GCM sobre el modo CBC para nuevas implementaciones porque proporciona cifrado autenticado, detectando manipulaciones y ocultando los datos, con un rendimiento comparable en CPU modernas con aceleración AES-NI. Para datos en tránsito, desactive SSL 2.0, SSL 3.0, TLS 1.0 y TLS 1.1 en todos los componentes del sistema que interactúen con el CDE, incluidos los balanceadores de carga internos y las integraciones heredadas de puntos de venta, y configure la preferencia de conjunto de cifrado para favorecer los conjuntos de secreto directo (basados ​​en ECDHE) sobre el intercambio de claves RSA estático. El PCI SSC señala NIST SP 800-52 como referencia para el endurecimiento de la configuración TLS.

Compromisos entre rendimiento e interoperabilidad

TLS 1.3 elimina varios intercambios de ida y vuelta de handshake heredados y descarta conjuntos de cifrado conocidos como débiles, lo que reduce tanto la latencia de conexión como el riesgo de configuración incorrecta, pero algunos terminales de punto de venta, SDK de pago y dispositivos integrados más antiguos todavía solo negocian TLS 1.2. Por eso, TLS 1.2 sigue siendo la base mínima práctica en lugar de TLS 1.3 directamente; una ruta de actualización gradual que retire el hardware TLS 1.2 según un cronograma definido es una decisión de arquitectura más realista que una transición inmediata. En cuanto al almacenamiento, la etiqueta de autenticación de AES-256-GCM agrega una pequeña sobrecarga fija por bloque que es insignificante en sistemas acelerados por hardware, pero puede importar en terminales de pago integrados con recursos limitados, razón por la cual esos dispositivos frecuentemente se tokenizan en el punto de captura en lugar de cifrarse localmente.

Ejemplo de implementación: un patrón común es la terminación TLS en un balanceador de carga o puerta de enlace API configurado para TLS 1.2 como mínimo y TLS 1.3 como preferido, con recifrado, no en texto plano, en el segmento interno entre la puerta de enlace y la capa de aplicación, de modo que los datos del titular de la tarjeta nunca se transmiten sin cifrar, ni siquiera dentro de la propia red de la organización.

¿Qué exigen las normas PCI DSS 3.5 a 3.7 para la gestión de claves?

Los requisitos 3.5, 3.6 y 3.7 exigen, respectivamente, que el PAN almacenado sea ilegible, que las claves que lo protegen estén protegidas contra la divulgación y el uso indebido, y que un ciclo de vida documentado rija cada clave desde su generación hasta su destrucción. La seguridad del cifrado depende de la gestión de claves que lo respalda, y este es el subrequisito que los evaluadores de seguridad de calidad (QSA) suelen señalar como problemático en las evaluaciones fallidas.

• Requisito 3.5 Requiere que el PAN se vuelva ilegible en cualquier lugar donde se almacene, utilizando criptografía robusta, truncamiento, tokens de índice con un relleno almacenado de forma segura o hash unidireccional de todo el PAN.
• Requisito 3.6 Requiere que las claves criptográficas utilizadas para proteger los datos de las cuentas almacenadas estén protegidas a su vez: cifradas con una clave de cifrado de claves independiente, almacenadas dentro de un dispositivo criptográfico seguro como un HSM, o divididas en componentes bajo doble control, con acceso restringido al menor número de custodios necesarios.
• Requisito 3.7 Requiere procedimientos documentados a lo largo de todo el ciclo de vida de las claves: generación de claves seguras, distribución segura, almacenamiento seguro, rotación al final de un criptoperiodo definido y eliminación o destrucción de claves comprometidas o caducadas. Asimismo, exige conocimiento compartido y control dual para las operaciones manuales de gestión de claves, y una confirmación firmada por parte de los custodios de sus responsabilidades.

Dependencia de la gestión de claves: una columna de base de datos cifrada con AES-256 y con una clave almacenada en un archivo de configuración contiguo no ofrece prácticamente ninguna protección real y es un hallazgo habitual en las evaluaciones fallidas. Ni el control de ilegibilidad del Requisito 3.5 ni el control TLS del Requisito 4 tienen sentido sin la disciplina de custodia y ciclo de vida que imponen los Requisito 3.6 y 3.7 sobre las claves subyacentes. Centralizar dicho ciclo de vida mediante una plataforma dedicada a certificados y claves como CertSecure Manager proporciona a la organización calendarios de rotación obligatorios, responsabilidad del custodio e informes listos para auditoría, en lugar de una hoja de cálculo que registre manualmente la antigüedad de las claves.

¿Qué requisitos exige la norma PCI DSS para la autenticación multifactor?

La norma PCI DSS v4.0.1 exige la autenticación multifactor (MFA) para todo acceso al entorno de datos del titular de la tarjeta según el requisito 8.4.2 , no el 8.4.3, y este control se aplica completamente desde el 31 de marzo de 2025. Verificamos esto directamente para este artículo porque otras dos publicaciones sobre este tema discrepan en la cifra, y es importante que sea correcta para cualquiera que diseñe una arquitectura de control de acceso conforme a la especificación.

Los tres subrequisitos relacionados del Requisito 8.4 son fáciles de confundir, por lo que conviene distinguirlos con precisión:

• Requisito 8.4.1Autenticación multifactor (MFA) para todo acceso administrativo al CDE que no sea mediante consola. Esta medida se mantiene desde la versión 3.2.1 de PCI DSS y estuvo vigente durante años antes de la versión 4.0.
• Requisito 8.4.2: MFA para todos Acceso al CDE para todos los roles, desde cualquier ubicación, no solo acceso administrativo. Este es el principal control nuevo introducido en la versión 4.0, que se volvió obligatorio el 31 de marzo de 2025.
• Requisito 8.4.3Autenticación multifactor (MFA) para todo acceso remoto a la red que se origine fuera de la red de la entidad y que pueda llegar al CDE, abarcando tanto el acceso remoto del personal como el de terceros o proveedores. Este requisito existía antes de la versión 4.0 y se aclaró en lugar de introducirse por primera vez.

El requisito 8.5.1 funciona junto con el 8.4.2 y también se volvió obligatorio el 31 de marzo de 2025: las implementaciones de MFA deben resistir la elusión, excepto a través de un proceso de excepción documentado y evaluado en cuanto a riesgos, requerir al menos dos factores independientes, confirmar que todos los factores se completen correctamente antes de otorgar acceso y resistir ataques de repetición. Para la mayoría de las organizaciones, el trabajo práctico consiste en extender la MFA desde la población de administradores ya cubierta por el requisito 8.4.1 a todos los usuarios de aplicaciones, contratistas e integraciones de terceros que interactúan con el CDE, y luego documentar los controles anti-elusión que un evaluador solicitará específicamente que se muestren como evidencia.

¿Cómo protege la tokenización el PAN según la norma PCI DSS?

La tokenización protege el PAN reemplazándolo con un valor sustituto, un token, en el momento de la captura, y almacena el PAN real únicamente en una bóveda de tokens separada y de alcance restringido, de modo que ningún sistema posterior que acceda al token acceda al número de tarjeta real. El cifrado que preserva el formato (FPE) es la técnica que utilizan la mayoría de los esquemas de tokenización para mantener el token con la misma longitud y conjunto de caracteres que el PAN original, de manera que las bases de datos heredadas, los formatos de registro y las aplicaciones posteriores no necesiten realizar cambios de esquema para aceptarlo.

Mientras que el cifrado mantiene el valor del PAN recuperable, lo cual es importante cuando los sistemas posteriores, como la facturación recurrente o el procesamiento de contracargos, aún necesitan el número original, la tokenización elimina por completo el PAN real del entorno. Esto es lo que reduce el alcance de la evaluación PCI DSS, pero introduce una dependencia de que el repositorio de tokens sea accesible y esté disponible para cada sistema que necesite destokenizarlo. Además, la tokenización que conserva el formato agrega un viaje de ida y vuelta a la red por cada llamada de destokenización, lo cual es relevante con un alto volumen de transacciones.

Ejemplo de implementación: una pasarela de pago normalmente tokeniza el PAN en el momento de la captura y almacena únicamente el token en su propia base de datos, manteniendo la bóveda de tokens como el único sistema dentro del alcance completo de PCI DSS. Un sistema de facturación local heredado que debe conservar el PAN real para los cargos recurrentes suele recurrir al cifrado de datos transparente o a nivel de columna con AES-256, respaldado por una clave protegida por HSM, ya que reemplazar el PAN con un token alteraría su lógica de facturación.

¿Qué requisitos de HSM se aplican a la custodia de llaves?

Un módulo de seguridad de hardware (HSM) es la solución práctica que la mayoría de las organizaciones que cumplen con la normativa satisfacen con el requisito 3.6 sobre "dispositivos criptográficos seguros": un dispositivo dedicado y a prueba de manipulaciones que genera, almacena y utiliza claves criptográficas sin exponerlas en texto plano a la aplicación o al sistema operativo. FIPS 140-3 es el estándar de validación actual con el que se evalúan los HSM, y las QSA exigen cada vez más el almacenamiento de claves validado por FIPS en lugar de bóvedas de claves basadas en software para entornos de alto valor.

Generalmente, las organizaciones eligen entre HSM locales, que ofrecen el máximo control y son comunes cuando los requisitos contractuales lo exigen, y HSM como servicio alojado en la nube , que elimina el costo de capital y la sobrecarga de la ceremonia de claves físicas, al tiempo que proporciona almacenamiento de claves validado por FIPS. Ejemplo de implementación: la bóveda de tokenización de un procesador de pagos almacena su clave maestra de cifrado dentro de un clúster de HSM, y cada llamada de generación o destokenización de tokens se firma o descifra dentro del perímetro del HSM, por lo que la clave en sí nunca sale del hardware validado.

¿Qué requisitos de PCI DSS rigen la criptografía y la gestión de claves?

La tabla que aparece a continuación relaciona cada número de requisito relevante para la criptografía y la gestión de claves con lo que abarca y el control técnico que normalmente lo satisface, lo que resulta útil como referencia rápida durante una revisión de la arquitectura.

Requisito	Lo que cubre	Control técnico típico
3.5	Renderizar el PAN almacenado ilegible	Cifrado, tokenización o truncamiento AES-256
3.6	Proteja las claves utilizadas para proteger los datos de la cuenta almacenados.	Almacenamiento de claves respaldado por HSM, claves de cifrado de claves, control dual
3.7	Documentar y hacer cumplir el ciclo de vida completo de la llave.	Criptoperíodos definidos, rotación automatizada, aprobación del custodio.
4.2.1	Proteja los datos de los titulares de tarjetas durante su transmisión a través de redes públicas.	TLS 1.2 como mínimo, TLS 1.3 preferido, sin SSL ni versiones anteriores de TLS.
8.4.1	Autenticación multifactor para el acceso administrativo al CDE sin necesidad de consola	Autenticación multifactor en todas las consolas de administración y servidores intermedios.
8.4.2	Autenticación multifactor para todos los accesos al CDE, cualquier rol, cualquier ubicación.	La autenticación multifactor (MFA) se aplica en cada punto de autenticación de CDE.
8.4.3	Autenticación multifactor para acceso remoto originado fuera de la red de la entidad.	VPN o puerta de enlace de acceso remoto MFA, incluido el acceso de terceros

¿En qué consiste el proceso de validación de cumplimiento de PCI DSS?

La validación PCI DSS sigue la misma secuencia de evaluación técnica independientemente del nivel del comercio, aunque la profundidad de las pruebas en cada etapa difiere según el volumen de transacciones y la ruta de validación (ROC dirigida por QSA frente a SAQ autoevaluada).

1. Confirmar el alcance de CDE. Mapea cada sistema, proceso y segmento de red que almacena, procesa o transmite datos de titulares de tarjetas, o que podría afectar su seguridad. La segmentación es la forma más eficaz de reducir este alcance.
2. Inventariar activos criptográficos. Elabore una lista precisa de cada algoritmo, protocolo, certificado y clave en el CDE antes de decidir qué medidas correctivas tomar; no se puede proteger lo que no se ve.
3. Pruebe los controles criptográficos y de gestión de claves específicamente conforme a los requisitos 3, 4 y 8. Verifique la representación de PAN, la configuración TLS, la custodia de claves y la cobertura de MFA según la especificación, no según lo que parezca seguro.
4. Primero, hay que subsanar las deficiencias más graves. El almacenamiento sin cifrar del número de cuenta principal (PAN), las versiones obsoletas de TLS y la falta de autenticación multifactor (MFA) en el acceso al entorno de datos certificados (CDE) son, sistemáticamente, los hallazgos de evaluación más graves.
5. Validación formal completa. Los comerciantes con menor volumen de transacciones completan el SAQ correspondiente; los comerciantes de Nivel 1 y la mayoría de los proveedores de servicios se someten a una evaluación in situ dirigida por un QSA, que genera un Informe de Cumplimiento (ROC).
6. Presentar la Declaración de Cumplimiento (AOC) al banco adquirente, respaldado por la SAQ o la ROC.
7. Mantener una validación continua. Los análisis trimestrales de ASV, las pruebas de penetración anuales y un ejercicio anual de confirmación del alcance evitan que los controles criptográficos se desvíen silenciosamente entre las evaluaciones formales.

Limitaciones

La especificación es precisa, pero no cubre todo lo que necesita una implementación real. Algunas limitaciones que conviene señalar directamente:

• Superar una evaluación es una certificación en un momento determinado. Una desviación en la configuración o un nuevo sistema no contemplado en el alcance después de la firma del ROC o el AOC puede hacer que una organización vuelva a incumplir el cumplimiento de inmediato.
• Encriptar el PAN no lo excluye automáticamente del ámbito de aplicación. Un sistema que aún almacena datos de cuenta cifrados generalmente permanece dentro del alcance; solo la tokenización que elimina por completo el PAN real tiende a reducir el alcance.
• Los controles compensatorios requieren rigor documentado, no conveniencia. Cada una requiere un análisis de riesgos formal y la aprobación de un QSA, y si se usan de forma laxa, se convierten en una manera de evitar solucionar la deficiencia subyacente.
• El estándar evoluciona. Este artículo refleja la norma PCI DSS v4.0.1 a fecha de agosto de 2026. Una futura revisión v5.0 podría modificar los requisitos o los plazos, por lo que conviene verificar la norma publicada vigente antes de tomar decisiones sobre la arquitectura.
• La interpretación de QSA puede variar en cuestiones de alcance límite. Involucrar a su QSA desde el principio en la toma de decisiones sobre la arquitectura evita tener que rehacer el trabajo más adelante.

¿Qué recomendaría Encryption Consulting?

Nuestra postura, tras haber participado en revisiones de arquitectura criptográfica para organizaciones que van desde comercios regionales hasta bancos nacionales, es que la mayoría de los programas criptográficos PCI DSS no superan la evaluación no por la falta de un control, sino porque se añadieron de forma improvisada en lugar de diseñarse desde el principio de acuerdo con la especificación. A continuación, detallamos lo que haríamos, en orden.

Empiece con un inventario criptográfico real. Antes de elegir entre cifrado y tokenización o auditar la configuración TLS, cree un inventario preciso de cada conjunto de cifrado, protocolo, certificado y clave que tenga contacto con el CDE.

Centralizamos la gestión del ciclo de vida de claves y certificados. Implementamos CertSecure Manager para brindar a las organizaciones calendarios de rotación obligatorios, responsabilidad del custodio y visibilidad centralizada, abordando directamente los hallazgos de los Requisitos 3.6 y 3.7 que aparecen con mayor frecuencia en las evaluaciones fallidas. Para las claves maestras que protegen bóvedas de tokenización o cifrado masivo, generalmente recomendamos el almacenamiento validado según FIPS 140-3 a través de HSM locales o HSM como servicio , según la madurez operativa y la infraestructura existente.

Ampliar la autenticación multifactor (MFA) de forma deliberada, no solo técnica. Cumplir con la letra del requisito 8.4.2 es sencillo; cumplir con la intención de evitar la elusión del requisito 8.5.1 exige mayor rigor. Ayudamos a nuestros clientes a documentar cada excepción legítima a la MFA, vincularla a un control compensatorio y eliminar las elusiones informales que se acumulan con el tiempo.

Trate los datos de los titulares de tarjetas almacenados en la nube con la misma disciplina de custodia que los datos locales. Nuestros servicios de protección de datos en la nube extienden la arquitectura de cifrado y custodia de claves respaldada por HSM a entornos en la nube e híbridos, de modo que las bóvedas de tokenización o los almacenes de datos cifrados alojados en la nube cumplen con los mismos estándares de gestión de claves que una implementación local.

Considere la validación como un proceso continuo, no anual. Nuestros servicios de asesoría en cumplimiento combinan el trabajo con PCI DSS con el panorama regulatorio más amplio al que se enfrentan muchos clientes, incluyendo DORA y NIS2, de modo que los controles criptográficos creados para PCI DSS cumplen con mandatos superpuestos en lugar de tener que ser rediseñados para cada uno. Si se encuentra en las primeras etapas de este proceso, el primer paso más efectivo es una evaluación de brechas con respecto a los Requisitos 3, 4 y 8 específicamente, ya que es ahí donde el costo de cometer errores es mayor.

Conclusión

La especificación criptográfica de PCI DSS es más específica y precisa de lo que podrían sugerir los 12 requisitos del estándar: algoritmos robustos y TLS 1.2+ para datos en tránsito, un ciclo de vida de gestión de claves documentado según los requisitos 3.6 y 3.7, autenticación multifactor (MFA) para todo el acceso a CDE según el requisito 8.4.2, y una elección deliberada entre cifrado y tokenización para PAN almacenado. Si se cumplen estos cuatro requisitos y se respaldan con la custodia de claves protegida por HSM, la mayoría de las pruebas que realiza un QSA a nivel técnico se realizan automáticamente.

Nada de esto sustituye una validación rigurosa: análisis trimestrales, pruebas de penetración anuales y el hábito de tratar la capa criptográfica como una arquitectura dinámica, en lugar de una implementación puntual. Si desea una segunda opinión sobre el cumplimiento de sus controles criptográficos con la especificación, nuestros servicios de asesoramiento en cifrado pueden ayudarle a identificar las deficiencias y priorizar las medidas correctivas.

Preguntas frecuentes

¿La obligatoriedad de la autenticación multifactor (MFA) para todo el acceso al entorno de datos del titular de la tarjeta (CDE) según la norma PCI DSS corresponde al requisito 8.4.2 o al 8.4.3? Se trata del requisito 8.4.2. Este requisito exige la MFA para todo acceso al entorno de datos del titular de la tarjeta, para cualquier rol y desde cualquier ubicación, y se aplica desde el 31 de marzo de 2025. El requisito 8.4.3 es un control independiente y más específico que exige la MFA específicamente para el acceso remoto a la red desde fuera de la red de la entidad.

¿Requiere PCI DSS un algoritmo de cifrado específico? PCI DSS no especifica un algoritmo obligatorio, pero exige criptografía robusta con una clave efectiva de al menos 112 bits. AES-256 es el estándar de facto para el almacenamiento de datos de cuentas, ya que se reconoce explícitamente como criptografía robusta y ofrece un buen rendimiento en hardware.

¿Se requiere tokenización o basta con el cifrado? Ninguna de las dos opciones es obligatoria individualmente; el requisito 3.5 de PCI DSS acepta el cifrado, la tokenización, el truncamiento o el hash unidireccional para que el PAN sea ilegible. Generalmente, se prefiere la tokenización cuando el objetivo es reducir el alcance, ya que eliminar el PAN real de un sistema puede dejarlo fuera del alcance de la evaluación, mientras que el almacenamiento cifrado generalmente no lo hace.

¿Es necesario almacenar las claves PCI DSS en un HSM? El requisito 3.6 no menciona específicamente los HSM, pero exige que las claves estén protegidas mediante una serie de métodos, incluido el almacenamiento "dentro de un dispositivo criptográfico seguro". Un HSM validado según FIPS 140-3 es la forma más común en que las organizaciones cumplen con este requisito, y las QSA esperan cada vez más hardware validado por FIPS para la custodia de claves de alto valor, en lugar de bóvedas de claves basadas en software.

¿En qué se diferencia este artículo de la guía general de cumplimiento de PCI DSS de EC? Este artículo ofrece un análisis exhaustivo, a nivel de especificación, de la criptografía y la gestión de claves, dirigido a equipos de seguridad e ingeniería que diseñan sistemas conforme a la norma. Nuestra guía complementaria, «Guía completa para lograr y mantener el cumplimiento de PCI DSS» , abarca todo el programa de certificación: niveles de comercio, tipos de SAQ y el proceso completo para obtener un AOC.

Referencias

• Documento estándar PCI DSS v4.0.1, Consejo de Estándares de Seguridad PCI
• Ahora es el momento de adoptar los requisitos futuros de PCI DSS v4.x, Blog de PCI SSC
• Requisitos de autenticación multifactor (MFA) de PCI DSS 4.0: Lo que necesita saber, Schellman
• Autenticación multifactor PCI DSS versión 4.0, BDO
• Migración desde SSL y TLS temprano, suplemento informativo de PCI SSC
• Biblioteca de documentos PCI SSC