--- url: 'https://www.corbado.com/es/blog/pci-dss-4-0-autenticacion-passkeys' title: 'Autenticación en PCI DSS 4.0: Passkeys' description: 'Descubre cómo la autenticación con passkeys cumple con los requisitos de MFA de PCI DSS 4.0, aumenta la seguridad y simplifica el cumplimiento para los comercios que manejan datos de titulares de tarjetas.' lang: 'es' author: 'Vincent Delitz' date: '2025-07-15T13:24:24.445Z' lastModified: '2026-03-27T07:04:13.394Z' keywords: 'pci dss, pci, autenticación pci, pci ssc, passkeys, cumplimiento pci' category: 'Passkeys Strategy' --- # Autenticación en PCI DSS 4.0: Passkeys ## 1. Introducción El panorama digital está en constante evolución y, con él, la sofisticación y la frecuencia de las ciberamenazas siguen aumentando. Los datos de las tarjetas de [pago](https://www.corbado.com/passkeys-for-payment) siguen siendo un objetivo principal para los actores maliciosos, lo que hace que unos estándares de [seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) robustos sean esenciales para cualquier organización que los maneje. El Estándar de [Seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) de Datos para la Industria de Tarjetas de [Pago](https://www.corbado.com/passkeys-for-payment) (PCI DSS) ha servido durante mucho tiempo como el punto de referencia para proteger los datos de los titulares de tarjetas. Su última iteración, [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) 4.0, representa un importante [paso adelante](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf), abordando directamente las amenazas modernas a través de, entre otras mejoras, requisitos de [autenticación](https://www.corbado.com/es/glossary/jwks) sustancialmente reforzados. A medida que las organizaciones abordan estas nuevas demandas, las tecnologías emergentes ofrecen soluciones prometedoras. Las passkeys, basadas en los estándares de la Alianza [FIDO](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc) (Fast Identity Online) y el protocolo WebAuthn, están a la vanguardia de esta nueva ola de [autenticación](https://www.corbado.com/es/glossary/jwks). Ofrecen un enfoque [sin contraseñas](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) y resistente al [phishing](https://www.corbado.com/glossary/phishing) y mejoran la forma en que se asegura el acceso a los datos sensibles. **Este artículo analiza los cambios críticos que introduce PCI DSS 4.0, especialmente en lo que respecta a la autenticación segura**, explora las capacidades de la [autenticación](https://www.corbado.com/es/glossary/jwks) con passkeys y proporciona una hoja de ruta para aprovechar esta tecnología para lograr y mantener el cumplimiento. Esta exploración nos lleva a dos preguntas importantes para las organizaciones que navegan por esta nueva frontera: 1. **Autenticación**: _Ahora que PCI DSS 4.0 eleva el listón de la autenticación, ¿cómo pueden las organizaciones cumplir eficazmente estos nuevos y estrictos requisitos sin sobrecargar a los usuarios o a los equipos de seguridad?_ 2. **Passkeys y cumplimiento de PCI**: _¿Pueden las tecnologías emergentes como las passkeys satisfacer los controles de autenticación de PCI DSS 4.0, mejorar la seguridad y la eficiencia operativa?_ Este artículo tiene como objetivo proporcionar respuestas, guiando a los profesionales técnicos hacia un futuro más seguro y conforme a las normativas. ## 2. Entendiendo PCI DSS y los cambios a la versión 4.0 Para apreciar el papel de las passkeys en el panorama actual de cumplimiento, es crucial entender el marco de [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) y la significativa evolución que marca la versión 4.0. ### 2.1 ¿Qué es el Estándar de Seguridad de Datos para la Industria de Tarjetas de Pago (PCI DSS)? El [Estándar de Seguridad de Datos de PCI](https://www.pcisecuritystandards.org/standards/) es un estándar global de [seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) de la información diseñado para proteger los datos de [pago](https://www.corbado.com/passkeys-for-payment). Se aplica a todas las entidades que almacenan, procesan o transmiten datos de titulares de tarjetas, abarcando a comercios, procesadores, adquirentes, emisores y proveedores de servicios. El estándar fue [desarrollado por las principales marcas de tarjetas de pago](https://en.wikipedia.org/wiki/Payment_Card_Industry_Security_Standards_Council) (American Express, Discover [Financial Services](https://www.corbado.com/passkeys-for-banking), JCB International, [MasterCard](https://www.corbado.com/blog/mastercard-passkeys) y [Visa](https://www.corbado.com/blog/visa-passkeys)), quienes formaron el [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) Security Standards Council (PCI SSC) el 7 de septiembre de 2006 para gestionar su evolución continua. [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) consiste en un conjunto completo de [requisitos técnicos y operativos](https://www.pcisecuritystandards.org/standards/), formando una base para proteger los datos de pago a lo largo de su ciclo de vida. ### 2.2 El PCI Security Standards Council (PCI SSC) y su misión El [PCI SSC](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) opera como un [foro global](https://www.pcisecuritystandards.org/), reuniendo a los [stakeholders](https://www.corbado.com/blog/passkeys-stakeholder) de la industria de [pagos](https://www.corbado.com/passkeys-for-payment) para desarrollar e impulsar la adopción de estándares de seguridad de datos y recursos para [pagos](https://www.corbado.com/passkeys-for-payment) seguros en todo el mundo. Más allá de PCI DSS, el Consejo gestiona una [serie de estándares](https://en.wikipedia.org/wiki/Payment_Card_Industry_Security_Standards_Council) que abordan diversos aspectos de la seguridad de los pagos. Su misión es mejorar la seguridad de los datos de las cuentas de pago a nivel mundial mediante el desarrollo de estándares y servicios de apoyo que [impulsen la educación, la concienciación y la implementación efectiva](https://www.researchgate.net/publication/385008508_Achieving_PCI-DSS_Compliance_in_Payment_Gateways_A_Comprehensive_Approach) por parte de los [stakeholders](https://www.corbado.com/blog/passkeys-stakeholder). ### 2.3 Evolución a PCI DSS 4.0: Impulsores y objetivos clave Los [Estándares PCI DSS 4.0](https://www.commerce.uwo.ca/pdf/PCI-DSS-v4_0.pdf), lanzados oficialmente en marzo de 2022, [con una revisión menor posterior (v4.0.1) para abordar los comentarios de los stakeholders](https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf), marcan la actualización más significativa del estándar en años. El principal impulsor de esta evolución fue la necesidad de abordar el panorama de ciberamenazas cada vez más sofisticado y el cambiante entorno tecnológico dentro de la industria de [pagos](https://www.corbado.com/passkeys-for-payment). Los objetivos principales de PCI DSS 4.0 son: - **Satisfacer las necesidades de seguridad en evolución de la industria de pagos:** Asegurar que el estándar siga siendo eficaz contra las amenazas actuales y emergentes, como el [phishing](https://www.corbado.com/glossary/phishing) basado en IA. - **Promover la seguridad como un proceso continuo:** Cambiar el enfoque del cumplimiento en un momento dado a una [disciplina de seguridad continua](https://www.fortra.com/resources/guides/pci-dss-4-compliance). - **Mejorar los métodos y procedimientos de validación:** Aumentar el rigor y la consistencia de las evaluaciones de cumplimiento. - **Añadir flexibilidad y admitir metodologías adicionales:** Permitir a las organizaciones más libertad en cómo logran los objetivos y resultados de seguridad. ### 2.4 Cambios principales en la versión 4.0: Enfoque en los resultados de seguridad, seguridad continua, implementación personalizada y plazos de transición [PCI DSS 4.0 introduce](https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf) varios cambios fundamentales que impactan en cómo las organizaciones abordan el cumplimiento: **Enfoque en los resultados de seguridad frente a los controles prescriptivos** Un cambio fundamental es el paso de controles principalmente prescriptivos a un énfasis en los resultados de seguridad. El propio estándar detalla esta flexibilidad: > _Sección 8: Enfoques para implementar y validar PCI DSS_ > > Para apoyar la flexibilidad en cómo se cumplen los objetivos de seguridad, existen dos > enfoques para implementar y validar PCI DSS. > > El Enfoque Personalizado se centra en el Objetivo de cada requisito de PCI DSS, > permitiendo a las entidades implementar controles para cumplir con el Objetivo declarado > del requisito de una manera que no sigue estrictamente el requisito definido. Este cambio significa que mientras PCI DSS 3.2.1 ofrecía instrucciones detalladas sobre _qué_ hacer, la versión 4.0 permite a las organizaciones más flexibilidad en _cómo_ cumplen los requisitos. Las empresas pueden implementar los controles que mejor se adapten a su entorno, siempre que puedan demostrar que estos controles logran los objetivos de seguridad establecidos. Esto es particularmente relevante para adoptar tecnologías innovadoras como las passkeys, que podrían no haber encajado bien en las descripciones de control más antiguas y rígidas. Sin embargo, esta flexibilidad viene con la expectativa de que las organizaciones realicen evaluaciones de riesgo exhaustivas y justifiquen claramente sus metodologías de control elegidas. **Seguridad continua (Business-as-Usual)** Otro principio clave en PCI DSS 4.0 es la promoción de la seguridad como un proceso continuo, como parte de las operaciones habituales (BAU, por sus siglas en inglés). El estándar detalla esto en la Sección 5: > _Sección 5: Mejores prácticas para implementar PCI DSS en los procesos de negocio > habituales_ > > Una entidad que implementa procesos de negocio habituales... está tomando medidas para > asegurar que los controles de seguridad... continúen implementándose correctamente y > funcionando adecuadamente como parte normal del negocio. > > Algunos requisitos de PCI DSS están destinados a actuar como procesos BAU al monitorear > los controles de seguridad para garantizar su eficacia de forma continua. Este énfasis en los procesos de "business-as-usual" (BAU) significa que las organizaciones deben integrar la seguridad en sus actividades rutinarias. Se trata de fomentar una cultura en la que la seguridad no sea una ocurrencia tardía o una carrera anual, sino una parte integral de las operaciones, asegurando un monitoreo continuo, evaluaciones regulares y posturas de seguridad adaptativas para garantizar la protección sostenida de los datos de los titulares de tarjetas. Para las implementaciones de passkeys, esto se traduce en una vigilancia continua para monitorear su efectividad, los patrones de adopción de los usuarios y cualquier amenaza emergente, haciendo de la seguridad un esfuerzo sostenido en lugar de un ejercicio de cumplimiento puntual. **Implementación personalizada y análisis de riesgos específico** Una nueva característica significativa en PCI DSS 4.0 es la opción formalizada para la [implementación personalizada](https://blog.pcisecuritystandards.org/pci-dss-v4-0-compensating-controls-vs-customized-approach), que está intrínsecamente vinculada a una rigurosa evaluación de riesgos. El estándar exige esta conexión en el Requisito 12.3.2: > _Requisito 12.3.2: Apoyar la seguridad de la información con políticas y programas > organizacionales_ > > Se realiza un análisis de riesgos específico para cada requisito de PCI DSS que la > entidad cumple con el enfoque personalizado, para incluir... evidencia documentada... > aprobación por parte de la alta dirección, y la realización del análisis de riesgos > específico al menos una vez cada 12 meses. Esta opción formalizada permite a las organizaciones cumplir los objetivos de seguridad utilizando nuevas tecnologías y controles innovadores adaptados a sus entornos únicos, en lugar de adherirse estrictamente a métodos prescriptivos. Sin embargo, como subraya la cita, esta flexibilidad se basa en la realización de un análisis de riesgos específico para cada control personalizado. Este análisis debe estar documentado, aprobado por la alta dirección y revisado anualmente. Un asesor externo (Asesor de Seguridad Calificado o QSA) valida luego estos controles personalizados revisando el enfoque documentado de la organización, incluido el análisis de riesgos, y desarrollando procedimientos de prueba específicos. Esta vía es un habilitador clave para soluciones como las passkeys, permitiendo a las organizaciones aprovechar sus características de seguridad avanzadas de manera efectiva, siempre que puedan demostrar mediante una evaluación de riesgos que su enfoque cumple con los objetivos de seguridad. La capacidad de personalizar la implementación, respaldada por un análisis de riesgos robusto, refleja la comprensión de que la rápida evolución tanto de las amenazas como de las tecnologías defensivas hace que los controles rígidos y prescriptivos sean menos adaptables con el tiempo. **Plazos de transición** PCI DSS 3.2.1 permaneció activo junto con la v4.0 hasta el 31 de marzo de 2024, fecha en la que fue retirado. Los nuevos requisitos introducidos en PCI DSS 4.0 se consideraron mejores prácticas hasta el 31 de marzo de 2025. Después de esta fecha, estos nuevos requisitos se vuelven obligatorios para todas las evaluaciones. Este enfoque por fases proporcionó a las organizaciones una ventana para comprender, planificar e implementar los cambios. Estos cambios en conjunto señalan un enfoque más maduro, adaptable y centrado en el riesgo para la seguridad de las tarjetas de pago, preparando el escenario para la adopción de mecanismos de autenticación más fuertes y modernos. ## 3. Hay mucho en juego: Implicaciones del incumplimiento de PCI DSS El incumplimiento de los requisitos de PCI DSS no es un mero descuido; conlleva consecuencias significativas y multifacéticas que pueden afectar gravemente la estabilidad financiera, la situación legal y la reputación de una organización. ### 3.1 Sanciones económicas La consecuencia más directa del incumplimiento es la imposición de [sanciones económicas](https://www.securitycompass.com/blog/pci-non-compliance-fees/). Estas multas suelen ser impuestas por los bancos adquirentes y los procesadores de pagos, no directamente por el [PCI SSC](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys). Las sanciones pueden ser sustanciales, oscilando entre [$5,000 y $100,000 por mes](https://www.ixopay.com/blog/5-consequences-of-pci-noncompliance), dependiendo del volumen de transacciones procesadas (que determina el nivel del comercio, por ejemplo, Nivel 1 para más de 6 millones de transacciones anuales frente a Nivel 4 para menos de 20,000 transacciones de [e-commerce](https://www.corbado.com/passkeys-for-e-commerce)) y la duración y gravedad del incumplimiento. Por ejemplo, un comercio de Nivel 1 que no cumpla durante varios meses es más propenso a enfrentar sanciones en el extremo superior de este rango, mientras que las empresas más pequeñas de Nivel 4 podrían incurrir en multas más cercanas a los $5,000 mensuales. Es crucial entender que estas multas pueden ser una [carga mensual recurrente](https://www.ixopay.com/blog/5-consequences-of-pci-noncompliance). Esta presión financiera persistente, potencialmente agravada por el [aumento de las comisiones por transacción](https://www.securitycompass.com/blog/pci-non-compliance-fees/) que los procesadores de pagos pueden cobrar a las empresas no conformes, significa que el coste acumulado del _incumplimiento_ supera con creces la inversión necesaria para _lograr y mantener el cumplimiento_. Esto replantea el cumplimiento no como un mero centro de costes, sino como una inversión crítica para la mitigación de riesgos. Invertir en medidas de seguridad robustas, incluida una autenticación fuerte como las passkeys, se convierte en una decisión financieramente prudente para evitar estos costes mayores, a menudo impredecibles y potencialmente paralizantes. ### 3.2 Repercusiones legales y normativas Más allá de las multas directas, el incumplimiento puede llevar a serios desafíos legales, especialmente si resulta en una filtración de datos. Los clientes cuyos datos se ven comprometidos pueden iniciar demandas, y las marcas de tarjetas también pueden tomar acciones legales. Un estado de incumplimiento puede hacer considerablemente más fácil para los demandantes demostrar negligencia por parte de la organización, lo que podría llevar a costosos acuerdos y sentencias. ### 3.3 Daño a la reputación y pérdida de la confianza del cliente Quizás una de las consecuencias más perjudiciales, aunque menos cuantificable, es el daño a la reputación de una organización. Un solo fallo de cumplimiento, particularmente uno que conduce a una filtración de datos, puede erosionar gravemente la confianza del cliente. Una vez perdida, esta confianza es difícil de recuperar, lo que a menudo resulta en la pérdida de clientes, la pérdida de negocio frente a la competencia y un daño a largo plazo a la imagen de la marca. Las violaciones repetidas o graves pueden incluso llevar a la [revocación de los privilegios de procesamiento de pagos de una organización](https://www.securitycompass.com/blog/pci-non-compliance-fees/) por parte de las marcas de tarjetas o los bancos adquirentes, cortando efectivamente su capacidad para aceptar pagos con tarjeta. Esto subraya la importancia de ver el cumplimiento no solo como un requisito técnico, sino como un componente fundamental de la confianza en la marca y la continuidad del negocio. ### 3.4 Costes de compensación por filtración de datos Si el incumplimiento contribuye a una filtración de datos, la organización probablemente será responsable de costes de compensación sustanciales, además de las multas y los honorarios legales. Estos costes pueden incluir proporcionar a los clientes afectados servicios como el monitoreo de crédito gratuito, [seguro](https://www.corbado.com/passkeys-for-insurance) contra el robo de identidad y el reembolso de cargos fraudulentos o comisiones de servicio. Además, el coste de reemitir las tarjetas de pago comprometidas, estimado entre $3 y $5 por tarjeta, puede escalar rápidamente a millones de dólares para brechas que afectan a un gran número de titulares de tarjetas. Por el contrario, si una organización sufre una brecha mientras cumple plenamente con PCI DSS, las multas asociadas pueden reducirse o incluso eliminarse, ya que el cumplimiento demuestra la debida diligencia y un compromiso con la seguridad, en lugar de negligencia. La variedad de posibles resultados negativos destaca que el cumplimiento de PCI DSS es un aspecto indispensable de las operaciones comerciales modernas para cualquier entidad involucrada en el ecosistema de las tarjetas de pago. ## 4. Controles de autenticación reforzados de PCI DSS 4.0: Una mirada más cercana al Requisito 8 El Requisito 8 de PCI DSS siempre ha sido una piedra [angular](https://www.corbado.com/blog/angular-passkeys) del estándar. Con la versión 4.0, sus estipulaciones se han fortalecido significativamente, reflejando el papel crítico de una autenticación robusta para prevenir el acceso no autorizado a datos sensibles de titulares de tarjetas y a los sistemas que los procesan. ### 4.1 Resumen del Requisito 8: Identificar y autenticar el acceso a los componentes del sistema El objetivo principal del Requisito 8 es asegurar que cada individuo que accede a los componentes del sistema dentro del Entorno de Datos de Titulares de Tarjetas (CDE) o conectado a él pueda ser identificado de forma única y autenticado de manera robusta. Esto es importante para mantener la integridad y seguridad de los datos de los titulares de tarjetas, previniendo el acceso no autorizado y asegurando que todas las acciones puedan ser rastreadas hasta un usuario específico y conocido, estableciendo así la responsabilidad individual. ### 4.2 Mandatos reforzados de Autenticación Multifactor (MFA) Una evolución importante en PCI DSS 4.0 es la expansión y fortalecimiento de los requisitos de Autenticación Multifactor (MFA): - **MFA universal para el acceso al CDE:** A diferencia de PCI DSS 3.2.1, que principalmente exigía MFA para el acceso administrativo y todo el acceso remoto al CDE, la versión 4.0 requiere MFA para _todo_ el acceso al CDE. Esto incluye el acceso de administradores, usuarios generales y proveedores externos, independientemente de si el acceso se origina desde dentro o fuera de la red. Esta expansión significativa subraya el reconocimiento del [PCI SSC](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) de la MFA como un control de seguridad fundamental.\ El estándar especifica estos requisitos: > _Extractos del Requisito 8_ > > "8.4.1 Se implementa MFA para todo el acceso no de consola al CDE para el personal > con acceso administrativo."  > > "8.4.3 Se implementa MFA para todo el acceso remoto que se origine fuera de la red > de la entidad y que pueda acceder o impactar el CDE."  - **Requisitos de los factores:** Las implementaciones de MFA deben usar al menos dos de los tres tipos de factores de autenticación reconocidos: - Algo que sabes (p. ej., contraseña, PIN) - Algo que tienes (p. ej., un dispositivo token, [tarjeta inteligente](https://www.corbado.com/es/glossary/tarjeta-inteligente) o un dispositivo que contiene una passkey) - Algo que eres (p. ej., datos biométricos como una huella dactilar o reconocimiento facial). Crucialmente, estos factores deben ser independientes, lo que significa que la compromisión de un factor no compromete a los otros. - **Integridad del sistema MFA:** Los sistemas MFA deben estar diseñados para resistir ataques de repetición (donde un atacante intercepta y reutiliza datos de autenticación) y deben conceder acceso solo después de que todos los factores de autenticación requeridos hayan sido validados con éxito. - **Sin omisión no autorizada:** La MFA no debe poder ser omitida por ningún usuario, incluidos los administradores, a menos que la dirección conceda una excepción específica y documentada por instancia y por un período de tiempo limitado. - **La autenticación resistente al phishing como excepción:** PCI DSS 4.0 también introduce orientación adicional sobre los factores de autenticación resistentes al [phishing](https://www.corbado.com/glossary/phishing), que pueden, en algunos casos, cumplir la intención de la MFA. > _Extractos del Requisito 8_ > > "Este requisito no se aplica a... cuentas de usuario que solo se autentican con > factores de autenticación resistentes al phishing." — Notas de aplicabilidad a 8.4.2 >  > > "Autenticación resistente al phishing... Ejemplos de autenticación resistente al > phishing incluyen [FIDO2](https://www.corbado.com/glossary/fido2)." — Apéndice G, Definición del glosario > de Autenticación Resistente al Phishing  Las implicaciones de la autenticación resistente al phishing, como se destaca en estos extractos, se explorarán más a fondo en la siguiente sección (4.3). ### 4.3 Énfasis en la autenticación resistente al phishing PCI DSS 4.0 pone un notable énfasis en el uso de métodos de autenticación resistentes al phishing. Esta es una respuesta directa a la prevalencia y el éxito de los ataques de phishing para comprometer las credenciales tradicionales. - **Autenticación resistente al phishing como alternativa/complemento a la MFA:** - Un desarrollo crítico bajo el Requisito 8.4.2 es que los métodos de autenticación resistentes al phishing pueden usarse [_en lugar de_ la MFA tradicional](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance) para todo el acceso no administrativo al CDE que se origine desde dentro de la red de la entidad. Esta es una disposición significativa para tecnologías como las passkeys, que son inherentemente resistentes al phishing. Señala que el PCI SSC considera que estos métodos avanzados proporcionan un nivel de seguridad comparable o incluso superior a algunas combinaciones de MFA tradicionales para este caso de uso específico. - **Sin embargo, para el acceso administrativo al CDE (Requisito 8.4.1) y para todo el acceso remoto que se origine desde fuera de la red de la entidad hacia el CDE (Requisito 8.4.3), aunque la autenticación resistente al phishing es muy recomendable, [_debe combinarse con al menos otro factor de autenticación_](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance) para cumplir con el requisito de MFA.** Esta distinción requiere un enfoque matizado para la implementación de passkeys, potencialmente una estrategia por niveles donde las passkeys por sí solas son suficientes para los usuarios internos generales, pero las passkeys combinadas con otro factor se utilizan para escenarios de acceso de mayor riesgo. - **Reconocimiento de FIDO y perspectivas de expertos:** El estándar menciona específicamente la autenticación basada en [FIDO](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc) (que sustenta las passkeys) como un método preferido para lograr la MFA, en gran parte debido a sus robustas características de resistencia al phishing. Se compartieron más ideas sobre este tema en el episodio del podcast del PCI SSC "Coffee with the Council", "Passwords Versus Passkeys: A Discussion with the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance)" ([https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance)). En el podcast, Andrew Jamieson, VP Distinguished Standards Architect en PCI SSC, enfatizó el valor de estas tecnologías: > "Quisiera reiterar que creo que la autenticación resistente al phishing es una gran > tecnología. Es algo que puede resolver muchos de los problemas que tenemos con las > contraseñas. Y sugeriría encarecidamente que, cuando la gente estudie qué > tecnologías va a implementar para la autenticación, eche un vistazo a la > autenticación resistente al phishing y lo que puede aportar, pero entendiendo > también que es un poco diferente a lo que la gente está acostumbrada y analizando > cómo pueden integrarla de forma correcta y segura en su arquitectura de > autenticación general." Megan Shamas, Chief Marketing Officer de la Alianza [FIDO](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc) (ver [Liderazgo de FIDO](https://fidoalliance.org/overview/leadership/)), destacó el cambio fundamental que estas tecnologías representan y la necesidad de que las políticas se adapten: > "Es fundamentalmente distinto a lo que estamos acostumbrados con contraseñas más > factor, factor, factor, y hemos hecho evolucionar la tecnología y ahora la gente > necesita también hacer evolucionar sus requisitos y sus políticas en consecuencia. Y > eso realmente ayudará a las organizaciones a tomar el camino correcto para > deshacerse de la autenticación vulnerable al phishing." Esta perspectiva conjunta subraya el movimiento de la industria hacia métodos de autenticación más seguros y modernos. ### 4.4 Nuevos requisitos de contraseñas y frases de contraseña (si se usan) Aunque PCI DSS 4.0 impulsa fuertemente hacia la MFA y los métodos resistentes al phishing, también endurece los requisitos para las contraseñas y frases de contraseña si todavía están en uso: - **Mayor longitud y complejidad:** La longitud mínima de la contraseña ha aumentado de siete caracteres en la v3.2.1 a 12 caracteres en la v4.0 (o al menos 8 caracteres si el sistema no admite 12). Las contraseñas también deben incluir una mezcla de caracteres numéricos y alfabéticos. - **Frecuencia de cambio de contraseña:** Las contraseñas deben cambiarse al menos cada 90 días si son el _único_ factor utilizado para la autenticación (es decir, no se aplica MFA a esa cuenta para ese acceso). Este requisito puede omitirse si se implementa MFA para el acceso, o si la organización emplea una autenticación continua y basada en riesgos que evalúa dinámicamente el acceso en tiempo real. El fortalecimiento significativo de las reglas de contraseñas, junto con los mandatos de MFA ampliados y el claro respaldo a los enfoques resistentes al phishing, señala una dirección estratégica del PCI SSC: reducir sistemáticamente la dependencia de las contraseñas como mecanismo de autenticación principal o único. Las contraseñas han sido reconocidas durante mucho tiempo como un eslabón débil en la seguridad, y PCI DSS 4.0 busca activamente mitigar sus riesgos inherentes haciendo que su uso independiente sea más estricto y menos atractivo, al tiempo que promueve alternativas más fuertes y modernas. Para ilustrar claramente estos cambios, la siguiente tabla compara aspectos clave de la autenticación entre PCI DSS 3.2.1 y 4.0: **Tabla 1: Diferencias clave en la autenticación: PCI DSS 3.2.1 vs. 4.0** | Característica | PCI DSS 3.2.1 | PCI DSS 4.0 | | :---------------------------------------- | :--------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **MFA para acceso al CDE** | Obligatoria para acceso administrativo no de consola y todo acceso remoto al CDE. | Obligatoria para [**todo** el acceso al CDE](https://drata.com/blog/pci-dss-v4-0) (administrativo, no administrativo, interno, remoto). | | **Longitud de contraseña (mínima)** | 7 caracteres (numéricos y alfabéticos). | 12 caracteres (numéricos y alfabéticos); 8 si el sistema no admite 12. | | **Frecuencia de cambio de contraseña** | Cada 90 días. | Cada 90 días [**si la contraseña es el único factor**](https://www.securitymetrics.com/blog/password-updates-and-requirements-in-pci-4); puede ser más largo si se usa MFA o autenticación basada en riesgos. | | **Énfasis en la resistencia al phishing** | Limitado, abordado principalmente a través de la concienciación general sobre seguridad. | Fuerte énfasis; la autenticación resistente al phishing puede reemplazar la MFA para ciertos accesos internos al CDE (Req 8.4.2). Se menciona explícitamente FIDO. | | **Uso de Passkeys/FIDO** | No abordado explícitamente como método principal. | La autenticación basada en FIDO se cita como un método de MFA preferido. A los métodos resistentes al phishing (como las passkeys) se les asignan roles específicos para cumplir los requisitos de MFA. | Este mayor enfoque en la autenticación en PCI DSS 4.0 establece una dirección clara para que las organizaciones reevalúen sus estrategias actuales y exploren soluciones más resilientes como las passkeys. ## 5. Passkeys: el futuro de la autenticación resistente al phishing Basadas en los estándares de la Alianza FIDO, las passkeys ofrecen una alternativa fundamentalmente más segura y fácil de usar que las contraseñas tradicionales e incluso algunas formas de MFA heredadas. ### 5.1 ¿Qué son las passkeys? (Estándares FIDO, WebAuthn) Una passkey es una credencial digital que permite a los usuarios iniciar sesión en sitios web y aplicaciones sin necesidad de introducir una contraseña. Se basan en los estándares [FIDO2](https://www.corbado.com/glossary/fido2), un conjunto de especificaciones abiertas desarrolladas por la Alianza FIDO. WebAuthn es un estándar del World Wide Web Consortium (W3C) que permite a los navegadores y aplicaciones web realizar una autenticación fuerte y resistente al phishing utilizando pares de claves criptográficas. Esencialmente, las passkeys son una implementación de estos estándares [FIDO2](https://www.corbado.com/glossary/fido2), aprovechando WebAuthn para las interacciones en entornos web. Reemplazan las contraseñas tradicionales con claves criptográficas únicas almacenadas de forma segura en el dispositivo de un usuario, como un smartphone, un ordenador o una llave de seguridad de hardware. ### 5.2 Cómo funcionan las passkeys: Criptografía, vinculación a dispositivos, biometría/PIN La seguridad de las passkeys se basa en la [criptografía de clave pública](https://www.corbado.com/es/blog/webauthn-pubkeycredparams-credentialpublickey). Cuando un usuario registra una passkey en un servicio (el "[relying party](https://www.corbado.com/glossary/relying-party)" o RP), se genera un par de claves criptográficas único: - Una **clave privada**, que se almacena de forma segura en el dispositivo del usuario. Esta clave puede residir dentro de un módulo de seguridad de hardware (p. ej., un TPM o [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)). La clave privada nunca abandona este almacenamiento seguro (excepto en el caso de las passkeys sincronizadas, como se detallará más adelante). - Una **clave pública**, que se envía y almacena en el [relying party](https://www.corbado.com/glossary/relying-party) (el sitio web o servicio de aplicación) y se asocia con la cuenta del usuario. Durante la autenticación, el proceso es el siguiente: 1. El [relying party](https://www.corbado.com/glossary/relying-party) envía un "desafío" único (un dato aleatorio) al dispositivo del usuario. 2. Para desbloquear y usar la clave privada, el usuario realiza una [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) local en su dispositivo. Esto generalmente implica usar un identificador biométrico (como una huella dactilar o un escaneo facial), introducir un PIN del dispositivo o dibujar un patrón. Es importante destacar que estos datos biométricos o PIN nunca abandonan el dispositivo del usuario y no se transmiten al relying party. 3. Una vez desbloqueada, la clave privada en el dispositivo firma el desafío recibido del relying party. 4. Este desafío firmado (la "aserción") se envía de vuelta al relying party. 5. El relying party utiliza la clave pública almacenada correspondiente a ese usuario para verificar la firma en la aserción. Si la firma es válida, la autenticación es exitosa. Existen principalmente dos tipos de passkeys: - **Passkeys sincronizadas:** Estas passkeys se pueden sincronizar entre los dispositivos de confianza de un usuario utilizando gestores de credenciales basados en la nube como el Llavero de iCloud de Apple o el [Administrador de contraseñas de Google](https://www.corbado.com/es/blog/como-usar-administrador-de-contraseñas-google). Esto proporciona comodidad, permitiendo que una passkey creada en un dispositivo se use en otro dispositivo propiedad del mismo usuario dentro del mismo ecosistema. - **Passkeys vinculadas a un dispositivo:** Estas passkeys están vinculadas a un autenticador físico específico, como una [llave de seguridad](https://www.corbado.com/es/blog/mejores-llaves-seguridad-hardware-fido2) de hardware USB (p. ej., [YubiKey](https://www.corbado.com/glossary/yubikey)) o una aplicación en un teléfono particular. La passkey no abandona este dispositivo específico. Esta base criptográfica y el proceso de [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) del usuario local proporcionan beneficios de seguridad inherentes que abordan directamente muchos vectores de ataque comunes. ### 5.3 Beneficios de seguridad inherentes: Resistencia al phishing, sin secretos compartidos, protección contra el credential stuffing y la toma de control de cuentas (ATO) El diseño de las passkeys ofrece varias ventajas de seguridad sobre los métodos de autenticación tradicionales: - **Resistencia al phishing:** Este es un beneficio fundamental. Las passkeys están vinculadas criptográficamente al origen específico del sitio web (el Relying Party ID o RP ID) para el que fueron creadas. Si un usuario es engañado para visitar un sitio de phishing falso que imita a uno legítimo, el navegador o el sistema operativo reconocerán que el dominio actual no coincide con el RP ID asociado a la passkey. Como resultado, la passkey simplemente no funcionará y la autenticación fallará. Esto traslada la carga de identificar los intentos de phishing del usuario humano, a menudo falible, a los robustos protocolos de seguridad de la propia tecnología. - **Sin secretos compartidos:** Con las passkeys, no hay un "secreto compartido" como una contraseña que sea conocida tanto por el usuario como por el servidor, y que pueda ser robada. La clave privada, que es el componente crítico para la autenticación, nunca abandona el dispositivo seguro del usuario. La clave pública, almacenada por el servidor, está matemáticamente vinculada a la clave privada pero no puede usarse para derivar la clave privada o para suplantar al usuario. Esto significa que incluso si el servidor de un relying party es vulnerado y se roban las claves públicas, son inútiles para los atacantes sin las claves privadas correspondientes. - **Protección contra el Credential Stuffing y los ataques de repetición:** Los ataques de [Credential Stuffing](https://www.corbado.com/glossary/credential-stuffing), donde los atacantes usan listas de nombres de usuario y contraseñas robados para intentar acceder a varias cuentas, se vuelven ineficaces porque no hay contraseñas que robar y reutilizar. Además, cada autenticación con passkey implica un mecanismo único de desafío-respuesta. La firma generada por la clave privada es específica para el desafío recibido en esa sesión de inicio de sesión en particular, lo que hace imposible que un atacante intercepte una aserción de autenticación y la reproduzca más tarde para obtener acceso no autorizado. - **Reducción significativa del riesgo de Toma de Control de Cuentas (ATO):** Al neutralizar eficazmente el phishing, eliminar los secretos compartidos y prevenir los ataques de [Credential Stuffing](https://www.corbado.com/glossary/credential-stuffing) y de repetición, las passkeys reducen drásticamente los principales vectores de ataque utilizados para la toma de control de cuentas. Dado que los atacantes no pueden obtener o usar indebidamente las credenciales de autenticación del usuario, la probabilidad de una ATO exitosa se desploma. Este cambio fundamental de la autenticación basada en el conocimiento (lo que un usuario sabe, como una contraseña) a una combinación de autenticación basada en la posesión (lo que un usuario tiene: su dispositivo con la clave segura) y basada en la inherencia o en el conocimiento local (lo que un usuario es a través de la [biometría](https://www.corbado.com/es/blog/biometria-conocimiento-pagador-enlace-dinamico), o lo que sabe localmente a través de un PIN de dispositivo) rompe fundamentalmente las cadenas de ataque que dependen de comprometer secretos compartidos utilizables de forma remota. A diferencia de muchas medidas de seguridad que añaden fricción, las passkeys a menudo mejoran la experiencia del usuario al ofrecer inicios de sesión más rápidos y sencillos sin la necesidad de recordar contraseñas complejas, un doble beneficio que puede impulsar la adopción y mejorar la postura de seguridad general. ## 6. Cerrando la brecha: Cómo las passkeys satisfacen los controles de autenticación de PCI DSS 4.0 Las sólidas características de seguridad inherentes a las passkeys se alinean notablemente bien con los controles de autenticación reforzados exigidos por PCI DSS 4.0, particularmente los descritos en el Requisito 8. Las passkeys no solo cumplen estos requisitos, sino que a menudo superan la seguridad proporcionada por los métodos tradicionales. ### 6.1 Abordando directamente los criterios de MFA y resistencia al phishing del Requisito 8 Las passkeys satisfacen inherentemente los principios básicos de la Autenticación Multifactor tal como se define en PCI DSS 4.0: - **Naturaleza multifactorial:** Un evento de autenticación con passkey generalmente combina "algo que tienes" (el dispositivo físico que contiene la clave privada, como un smartphone o una [llave de seguridad](https://www.corbado.com/es/blog/mejores-llaves-seguridad-hardware-fido2) de hardware) con "algo que eres" (un dato biométrico como una huella dactilar o un escaneo facial utilizado para desbloquear la passkey en el dispositivo) o "algo que sabes" (un PIN o patrón del dispositivo). Estos factores son independientes; comprometer un PIN de dispositivo, por ejemplo, no compromete inherentemente la clave criptográfica si el dispositivo en sí permanece seguro. - **Resistencia al phishing:** Como se ha discutido ampliamente, las passkeys son resistentes al phishing por diseño debido a su naturaleza criptográfica y su vinculación al origen. La clave privada nunca se expone al relying party ni se transmite por la red, y la passkey solo funcionará en el dominio legítimo para el que se registró. Esto se alinea directamente con el fuerte énfasis de PCI DSS 4.0 en mitigar las amenazas de phishing. - **Resistencia a la repetición:** Cada autenticación con passkey implica un desafío criptográfico único del servidor, que luego es firmado por la clave privada. La firma resultante es válida solo para ese desafío y sesión específicos, lo que la hace resistente a los ataques de repetición. Esto cumple con el Requisito 8.5, que exige que los sistemas MFA prevengan dichos ataques. ### 6.2 Superando la seguridad tradicional basada en contraseñas En comparación con las contraseñas tradicionales, las passkeys ofrecen un modelo de seguridad muy superior. Las contraseñas son vulnerables a una multitud de ataques: phishing, ingeniería social, [credential stuffing](https://www.corbado.com/glossary/credential-stuffing) debido a la reutilización de contraseñas, ataques de fuerza bruta y robo de bases de datos vulneradas. Las passkeys eliminan estas vulnerabilidades al eliminar por completo el secreto compartido (la contraseña) de la ecuación. La autenticación se basa en una prueba criptográfica de posesión de una clave privada, que a su vez está protegida por la seguridad local del dispositivo, en lugar de en un secreto que puede ser fácilmente robado o adivinado. ### 6.3 La perspectiva del PCI SSC sobre las passkeys El [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) Security Standards Council ha reconocido el potencial de la tecnología de passkeys. Las ideas del podcast del PCI SSC ["Coffee with the Council"](https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance) que presenta una discusión con la Alianza FIDO proporcionan claridad sobre su postura: - Para el acceso no administrativo al Entorno de Datos de Titulares de Tarjetas (CDE) desde _dentro_ de la red de la entidad (Requisito 8.4.2), el PCI SSC indica que los métodos de autenticación resistentes al phishing como las passkeys pueden usarse _en lugar de_ la MFA tradicional. Este es un reconocimiento significativo de la fortaleza de las passkeys. - Para el acceso administrativo al CDE (Requisito 8.4.1) y para cualquier acceso remoto a la red (Requisito 8.4.3), aunque se recomiendan las passkeys (como autenticación resistente al phishing), _deben usarse junto con otro factor de autenticación_ para satisfacer el requisito de MFA. Esto sugiere un enfoque basado en el riesgo donde los escenarios de acceso de mayor privilegio o mayor riesgo exigen una capa adicional. - El PCI SSC está desarrollando activamente guías, como preguntas frecuentes, para ayudar a las organizaciones a comprender cómo [implementar passkeys](https://www.corbado.com/es/blog/tutorial-passkeys-como-implementar-en-aplicaciones-web) de manera conforme y reconoce que las passkeys representan un cambio fundamental con respecto al pensamiento tradicional basado en contraseñas. - Además, la documentación de PCI DSS 4.0 hace referencia explícita a la autenticación basada en FIDO como un método preferido, aunque no obligatorio, para implementar MFA, lo que subraya su alineación con los objetivos del estándar. Esta posición permite a las organizaciones desplegar passkeys estratégicamente. Para la amplia base de usuarios no administrativos que acceden al CDE internamente, un [inicio de sesión con passkey](https://www.corbado.com/es/blog/mejores-practicas-inicio-sesion-passkeys) sin fricciones puede cumplir con los requisitos de cumplimiento. Para los administradores y usuarios remotos, las passkeys proporcionan una base sólida y resistente al phishing para una solución de MFA. ### 6.4 Tipos de passkeys, independencia de factores y atestación: Navegando las expectativas de los QSA para el Requisito 8 Aunque las passkeys ofrecen una mejora de seguridad significativa, los Asesores de Seguridad Calificados (QSA) de PCI DSS examinarán su implementación, especialmente para escenarios de acceso de alto riesgo como el acceso administrativo al CDE (Requisito 8.4.1), para garantizar que se cumplan los verdaderos principios de la autenticación multifactor. Las consideraciones clave incluyen el tipo de passkey, la independencia de los factores de autenticación y el uso de la [atestación](https://www.corbado.com/es/glossary/attestation). #### 6.4.1 Passkeys sincronizadas vs. vinculadas a un dispositivo: Como ya hemos discutido, las passkeys vienen en dos formas principales: - _Passkeys sincronizadas:_ Se sincronizan entre los dispositivos de confianza de un usuario a través de servicios en la nube como el Llavero de iCloud de Apple o el [Administrador de contraseñas de Google](https://www.corbado.com/es/blog/como-usar-administrador-de-contraseñas-google). Ofrecen comodidad, ya que una passkey creada en un dispositivo se puede usar en otro. - _Passkeys vinculadas a un dispositivo:_ Están vinculadas a un autenticador físico específico, como una [llave de seguridad](https://www.corbado.com/es/blog/mejores-llaves-seguridad-hardware-fido2) de hardware USB (p. ej., [YubiKey](https://www.corbado.com/glossary/yubikey)) o el hardware seguro de un teléfono específico. La clave privada no abandona este dispositivo específico. #### 6.4.2 Independencia de factores y escrutinio de los QSA PCI DSS exige que los factores de MFA sean independientes, lo que significa que la compromisión de un factor no compromete a los otros. Una passkey generalmente combina "algo que tienes" (el dispositivo con la clave privada) y "algo que sabes/eres" (el PIN del dispositivo local o la [biometría](https://www.corbado.com/es/blog/biometria-conocimiento-pagador-enlace-dinamico) para desbloquear la clave). Con las passkeys sincronizadas, aunque son muy seguras contra muchos ataques, algunos QSA pueden plantear preguntas sobre la independencia absoluta del factor de "posesión" para el acceso administrativo (Requisito 8.4.1). La preocupación es que si la cuenta en la nube del usuario (p. ej., Apple ID, cuenta de Google) que sincroniza las passkeys se ve comprometida, la clave privada podría ser clonada en un dispositivo controlado por un atacante. Esto podría llevar a algunos asesores a considerar que una passkey sincronizada, en contextos de alto riesgo, podría no cumplir con la interpretación estricta de dos factores totalmente independientes si el mecanismo de sincronización en sí no está protegido de forma robusta con su propia MFA fuerte. Las directrices de [NIST](https://www.corbado.com/blog/nist-passkeys), por ejemplo, reconocen las passkeys sincronizadas como compatibles con [AAL2](https://www.corbado.com/blog/nist-passkeys), mientras que las passkeys vinculadas a dispositivos pueden cumplir con [AAL3](https://www.corbado.com/blog/nist-passkeys), que a menudo implican claves no exportables. - **Entendiendo los indicadores del autenticador de WebAuthn:** Durante una ceremonia de WebAuthn (que sustenta las passkeys), los autenticadores informan ciertos indicadores. Dos importantes son: - **uv=1 (Usuario Verificado):** Este indicador señala que el usuario verificó con éxito su presencia ante el autenticador localmente, generalmente usando un PIN de dispositivo o [biometría](https://www.corbado.com/es/blog/biometria-conocimiento-pagador-enlace-dinamico). Esta [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) actúa como uno de los factores de autenticación: "algo que sabes" (PIN) o "algo que eres" (biometría). - **up=1 (Usuario Presente):** Este indicador confirma que el usuario estuvo presente e interactuó con el autenticador durante la ceremonia (p. ej., tocando una llave de seguridad). Aunque es crucial para probar la intención del usuario y prevenir ciertos ataques remotos, la presencia del usuario en sí misma generalmente no se considera un factor de autenticación separado e independiente para satisfacer el requisito multifactorial de la MFA. Es una característica de seguridad importante, pero normalmente no cuenta como un segundo _factor_ por sí sola. - **El papel de las passkeys vinculadas a dispositivos y las llaves de seguridad de hardware:**\ Para el acceso administrativo (Requisito 8.4.1) y otros escenarios de alta seguridad, las passkeys vinculadas a dispositivos almacenadas en llaves de seguridad de hardware ofrecen un argumento más sólido para la independencia de factores. Dado que la clave privada está diseñada para no abandonar nunca el token de hardware, el factor "algo que tienes" está protegido de manera más robusta contra la clonación mediante ataques basados en software o la compromisión de cuentas en la nube. Esto las convierte en una opción preferida para muchas organizaciones que buscan satisfacer las estrictas expectativas de los QSA para la MFA administrativa. #### 6.4.3 Atestación para la verificación del autenticador La [atestación](https://www.corbado.com/es/glossary/attestation) es una característica de WebAuthn en la que el autenticador proporciona información verificable sobre sí mismo (p. ej., su marca, modelo, estado de certificación, si está respaldado por hardware) al relying party (su servidor FIDO) durante el proceso de registro de la passkey. - **Por qué es importante para PCI DSS:** La [atestación](https://www.corbado.com/es/glossary/attestation) puede proporcionar evidencia crucial a los QSA de que los autenticadores que se utilizan cumplen con las políticas de seguridad de la organización y son genuinamente lo que dicen ser (p. ej., una llave de seguridad de hardware certificada). Esto puede ser particularmente importante al demostrar la fortaleza y la independencia de los factores de autenticación. - **Recomendación:** Para accesos de alta seguridad como el acceso administrativo al CDE, se recomienda encarecidamente el uso de passkeys en [llaves de seguridad de hardware](https://www.corbado.com/es/blog/mejores-llaves-seguridad-hardware-fido2) que admitan una atestación robusta. Esto permite a la organización hacer cumplir políticas sobre tipos de autenticadores aceptables y proporcionar una prueba más sólida de cumplimiento. En la práctica, para evitar fricciones en la auditoría para el Requisito 8.4.1, muchas empresas optan por emitir passkeys vinculadas a dispositivos en llaves de seguridad de hardware que ofrecen fuertes garantías de protección de claves y, potencialmente, atestación. ### 6.5 Mapeo de passkeys a las subcláusulas del Requisito 8 Para ilustrar claramente cómo las passkeys cierran la brecha y satisfacen los controles detallados en el Requisito 8, la siguiente tabla mapea características específicas de las passkeys y sus características a las subcláusulas relevantes, indicando su idoneidad para diferentes escenarios. | Subcláusula Req. 8 | Característica de la passkey | Cómo la passkey cumple/supera | ¿Sincronizada OK? | ¿Vinculada a dispositivo OK? | | :---------------------------------- | :----------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------- | :--------------------------- | | 8.2 (ID de usuario) | ID de usuario único a través de passkey | Cada passkey es única para el registro de un usuario en un servicio. Las claves privadas no se comparten. Permite la responsabilidad individual. | ✅ | ✅ | | 8.3.x (Contraseñas) | Reemplazo de contraseñas | Si las passkeys reemplazan completamente las contraseñas para una ruta de acceso, los controles específicos de contraseñas (longitud, complejidad, rotación, historial) se vuelven N/A para esa ruta, simplificando el cumplimiento de esos controles. | ✅ | ✅ | | 8.4.1 (MFA administrativa) | Factor resistente al phishing (Dispositivo + Local) | La passkey sirve como un factor fuerte y resistente al phishing. (Escrutinio del QSA sobre la independencia de factores para passkeys sincronizadas). | ⚠️ | ✅ | | 8.4.2 (MFA no de consola) | Autenticación resistente al phishing (Dispositivo + Local) | La autenticación resistente al phishing (como las passkeys) puede usarse _en lugar de_ la MFA tradicional para este escenario. | ✅ | ✅ | | 8.4.3 (MFA remota) | Factor resistente al phishing (Dispositivo + Local) | La passkey sirve como un factor fuerte y resistente al phishing para acceder a la red. (Escrutinio del QSA sobre la independencia de factores para passkeys sincronizadas). | ⚠️ | ✅ | | 8.5.1 (Resistencia a la repetición) | Desafío/Respuesta único | Cada inicio de sesión genera una firma única vinculada a un desafío del servidor, evitando la reutilización de datos de autenticación interceptados. | ✅ | ✅ | | 8.5.x (Independencia de factores) | Factores locales distintos (Dispositivo+Local) | La clave criptográfica en el dispositivo y la biometría/PIN local son independientes. La operación criptográfica solo procede después de una verificación de usuario local exitosa. (La independencia de factores para claves sincronizadas puede ser cuestionada por los QSA en escenarios de alto riesgo). | ⚠️ | ✅ | | Resistencia al phishing (General) | Seguridad central (Vinculación al origen, Sin secretos, Criptografía PK) | Diseñada fundamentalmente para resistir ataques de phishing al garantizar que la passkey solo funcione en el sitio legítimo y que no se transmita ningún secreto que pueda ser robado. | ✅ | ✅ | Este mapeo demuestra que las passkeys no son solo un ajuste teórico, sino una solución práctica y robusta para satisfacer las avanzadas demandas de autenticación de PCI DSS 4.0. ## 7. Conclusión: Adoptando las passkeys para una autenticación robusta El panorama de la seguridad de los pagos es complejo y está en evolución. PCI DSS 4.0 refleja esta realidad, estableciendo un listón más alto para los controles de seguridad, particularmente en el ámbito de la autenticación. A medida que las organizaciones se esfuerzan por cumplir con estas nuevas y más estrictas demandas, las passkeys —basadas en los estándares FIDO/WebAuthn— emergen no solo como una solución conforme, sino como una tecnología transformadora preparada para redefinir el acceso seguro. A lo largo de este análisis, dos preguntas centrales han guiado nuestra exploración: 1. **Ahora que PCI DSS 4.0 eleva el listón de la autenticación, ¿cómo pueden las organizaciones cumplir eficazmente estos nuevos y estrictos requisitos sin sobrecargar a los usuarios o a los equipos de seguridad?** La evidencia sugiere firmemente que las organizaciones pueden cumplir eficazmente los requisitos de autenticación de PCI DSS 4.0 adoptando estratégicamente soluciones de Autenticación Multifactor (MFA) resistentes al phishing como las passkeys. Estas tecnologías equilibran inherentemente una seguridad robusta y verificada criptográficamente con experiencias de usuario significativamente mejoradas y, a menudo, más rápidas. Además, la permisión de PCI DSS 4.0 para "implementaciones personalizadas" faculta a las organizaciones para adaptar tales soluciones avanzadas a sus entornos y perfiles de riesgo específicos, superando un enfoque único para todos. La propia guía del PCI SSC facilita aún más esto, permitiendo un cumplimiento simplificado para un gran segmento de usuarios mientras se reservan enfoques más estratificados para el acceso administrativo y remoto de mayor riesgo. 2. **¿Pueden las tecnologías emergentes como las passkeys no solo satisfacer los robustos controles de autenticación de PCI DSS 4.0, sino también ofrecer beneficios tangibles más allá del mero cumplimiento, como una mayor seguridad y una mejor eficiencia operativa?** La respuesta es un claro sí. Las passkeys son demostrablemente capaces de satisfacer los controles de autenticación centrales dentro del Requisito 8 de PCI DSS 4.0, incluidos sus criterios de MFA, resistencia al phishing y resistencia a la repetición. Sin embargo, su valor se extiende más allá del mero cumplimiento. El diseño inherente de las passkeys —eliminando los secretos compartidos y vinculando la autenticación a orígenes específicos— reduce drásticamente el riesgo de ataques de phishing exitosos y tomas de control de cuentas, lo que conduce a reducciones tangibles en las pérdidas relacionadas con el fraude. Operacionalmente, el abandono de las contraseñas se traduce en menos tickets de soporte técnico relacionados con contraseñas, ahorrando costes y liberando recursos de TI. Los usuarios se benefician de una experiencia de inicio de sesión más simple, rápida y menos frustrante, lo que puede mejorar la productividad y la satisfacción del cliente. Además, donde las contraseñas se reemplazan por completo por passkeys para rutas de acceso específicas, se elimina la carga de auditoría para los controles específicos de contraseñas, lo que podría agilizar los esfuerzos de cumplimiento en esas áreas. El camino hacia un ecosistema de pagos verdaderamente seguro es continuo. PCI DSS 4.0 establece nuevos hitos, y la autenticación con passkeys proporciona un vehículo poderoso para alcanzarlos. Se recomienda encarecidamente a las organizaciones que procesan, almacenan o transmiten datos de titulares de tarjetas que evalúen y comiencen a planificar la [adopción de passkeys](https://www.corbado.com/es/blog/caso-negocio-adopcion-passkeys). No se trata simplemente de adherirse a la última iteración de un estándar; se trata de adoptar un enfoque de autenticación más seguro, eficiente y centrado en el usuario que se alinee con el futuro de la [identidad digital](https://www.corbado.com/es/blog/digital-credentials-api). Al implementar estratégicamente las passkeys, las empresas pueden fortalecer sus defensas contra las amenazas en evolución, proteger los valiosos datos de pago y generar una mayor confianza con sus clientes en un mundo cada vez más digital.