Normas de cumplimiento para gestores de contraseñas: Qué cambió en 2026

En 2026, el cumplimiento normativo del gestor de contraseñas consiste en demostrar el control sobre las credenciales. Estas normas de cumplimiento para gestores de contraseñas se solapan en algunos puntos, pero no se suman en una única política universal.

Los requisitos varían según el sector, la geografía, el alcance de los sistemas y el perímetro de la auditoría, por lo que ninguna certificación cubre por igual a todas las organizaciones. La aplicabilidad de cada marco depende del tipo de entidad, del alcance de los sistemas y los datos, de la jurisdicción, de los contratos y del riesgo. Esta guía ofrece un mapa de normas entre marcos, una solución al conflicto recurrente entre NIST y PCI sobre la rotación de contraseñas y una correspondencia de las passkeys que puede utilizar al redactar políticas.

Normas de cumplimiento para gestores de contraseñas: Situación en 2026

Las evidencias de cumplimiento son el conjunto de políticas, registros de configuración, rastros de aprobación, revisiones de accesos, logs y resultados de pruebas que demuestran que un control funciona según lo previsto, no solo que existe sobre el papel. Para los gestores de contraseñas, la base de 2026 es un ciclo de vida de credenciales gobernado: identidades únicas, acceso controlado a las bóvedas, autenticación robusta, cambios auditables, recuperación probada y una capa de políticas específica de cada marco.

En 2026 ninguna ley global reescribió por sí sola el cumplimiento normativo de los gestores de contraseñas. Lo que cambió es la combinación: 

• NIST (el Instituto Nacional de Estándares y Tecnología de EE. UU.) Rev. 4 se convirtió en la referencia técnica vigente para los autenticadores
• PCI DSS (Payment Card Industry Data Security Standard) v4.0.1 es la norma PCI en vigor
• DORA (el Reglamento de Resiliencia Operativa Digital de la UE) se aplica desde el 17 de enero de 2025
• NIS2 (la segunda Directiva de la UE sobre seguridad de las redes y sistemas de información) pasó a la fase de aplicación nacional
• Persiste la brecha entre la norma vigente de HIPAA (Health Insurance Portability and Accountability Act) y su actualización propuesta sobre autenticación multifactor (MFA)

Normas de cumplimiento para gestores de contraseñas por marco

La capa de gobernanza de credenciales (Credential Governance Overlay, CGO) relaciona cada marco con el control que exige, las evidencias que un auditor puede verificar y la función del gestor de contraseñas que hace operativo ese control. Para cada marco se indica qué exige y qué implica para la configuración de la bóveda. La tabla que aparece más abajo resume las evidencias que conviene conservar en cada caso.

NIST SP 800-63B Rev. 4

Para las contraseñas verificadas de forma centralizada, NIST SP 800-63B Rev. 4 fija un mínimo de 15 caracteres para la autenticación de un solo factor. El mínimo de 8 caracteres solo se aplica cuando la contraseña se utiliza exclusivamente como parte de la MFA. Los verificadores no deben imponer reglas de composición ni cambios periódicos, y deben comprobar las contraseñas nuevas frente a valores conocidos como comunes, previsibles o comprometidos.

Para un gestor de contraseñas, esto significa generar credenciales largas y únicas, permitir el autocompletado, permitir pegar cuando el autocompletado no está disponible, ejecutar la detección de credenciales comprometidas y proteger la autenticación en la bóveda con MFA.

ISO/IEC 27001:2022

ISO 27001 es la norma internacional para los sistemas de gestión de la seguridad de la información. Los controles del anexo A A.5.16 (gestión de identidades), A.5.18 (derechos de acceso), A.8.5 (autenticación segura) y A.8.24 (criptografía) se aplican a través del plan de tratamiento de riesgos y de la Declaración de Aplicabilidad, un documento que enumera qué controles se aplican y por qué. Estos controles se seleccionan mediante el tratamiento de riesgos; ISO no exige todos los controles del anexo A ni un gestor de contraseñas concreto.

En la práctica, esto apunta a un flujo de altas, cambios y bajas (joiner-mover-leaver), al control de acceso basado en roles (RBAC), a la MFA donde el riesgo lo requiera y a una encriptación y una gestión de claves documentadas.

SOC 2

SOC 2 es un marco de auditoría para organizaciones de servicios. Los Trust Services Criteria CC6.1-CC6.8 de AICPA son controles orientados a resultados que abarcan la arquitectura de accesos, el registro y la autorización, los cambios de acceso, la protección física, la eliminación segura, la protección del perímetro, la transferencia o retirada autorizada de información (CC6.7) y la defensa contra el malware. Los auditores verifican las evidencias adecuadas al perímetro del sistema, a los riesgos y a los controles seleccionados.

Trate la bóveda como un componente dentro del perímetro del sistema auditado. Controle los administradores, las exportaciones, las integraciones y el registro de eventos, no solo las contraseñas.

PCI DSS v4.0.1

PCI DSS protege los datos de las tarjetas de pago. El requisito 8 regula la identificación y la autenticación en el entorno de datos del titular de la tarjeta (CDE), es decir, los sistemas y las personas que entran en el alcance de los datos de las tarjetas de pago. Según el requisito 8.3.6, las contraseñas o frases de contraseña que se usan como factores de autenticación deben tener al menos 12 caracteres, o al menos 8 si el sistema no admite 12.

Cuando una contraseña o frase de contraseña es el único factor de autenticación para el acceso de los usuarios, el requisito 8.3.9 exige cambiarla al menos cada 90 días o tomar decisiones de acceso automáticas basadas en un análisis dinámico de la postura de seguridad de la cuenta. El requisito solo puede marcarse como no aplicable cuando la MFA protege el acceso a todos los componentes del sistema dentro del alcance, o cuando el componente y la ruta de acceso cumplen las condiciones de factor único definidas por el PCI SSC. Las obligaciones de MFA se rigen por separado, en los requisitos 8.4.2-8.4.4, según la ruta de acceso.

Segmente las credenciales dentro del alcance de PCI, confirme si el requisito 8.3.9 se aplica antes de dar por hecho que no y compruebe qué requisito de MFA rige cada ruta de acceso.

HIPAA Security Rule

HIPAA protege la información sanitaria en EE. UU. La versión vigente de 45 CFR §164.312 exige control de acceso, identificación única de usuarios, un procedimiento de acceso de emergencia y autenticación de personas o entidades en los sistemas con información sanitaria protegida electrónica (ePHI). Una propuesta del HHS de 2025 añadiría la MFA con excepciones limitadas, pero ese requisito sigue siendo una propuesta, no una ley definitiva.

Utilice cuentas de bóveda individuales, mantenga los procedimientos de acceso de emergencia, restrinja el uso compartido de credenciales de ePHI y revise los accesos y los logs con regularidad.

NIS2

NIS2 es la directiva de la UE sobre seguridad de las redes y sistemas de información. El artículo 20 exige que los órganos de dirección aprueben y supervisen las medidas del artículo 21, y permite exigirles responsabilidades conforme al Derecho nacional aplicable. El artículo 21 exige medidas proporcionadas, entre ellas políticas de control de acceso, criptografía, ciberhigiene y MFA o autenticación continua cuando proceda. El artículo 34 obliga a los Estados miembros a fijar para las entidades esenciales multas administrativas máximas de al menos 10 millones de euros o el 2 % del volumen de negocio mundial, si esta cifra es superior.

Esto se traduce en un programa de gestión de riesgos aprobado por la dirección que abarque las revisiones de accesos, la formación, la respuesta a incidentes y la supervisión de proveedores.

DORA

DORA regula el riesgo de TIC de las entidades financieras de la UE incluidas en su ámbito y se aplica desde el 17 de enero de 2025. El artículo 9 exige políticas y controles de seguridad de las TIC, incluidos el acceso con mínimo privilegio, la autenticación robusta y la protección de las claves criptográficas. El artículo 10 trata los mecanismos de detección; el artículo 11, la continuidad de negocio de las TIC, la respuesta, la recuperación, las copias de seguridad y la restauración.

Trate la bóveda como un servicio de TIC: pruebe la recuperación, controle el acceso privilegiado, supervise las anomalías y evalúe el riesgo del proveedor de alojamiento.

RGPD

El RGPD es la ley general de protección de datos de la UE. El artículo 25 exige la protección de datos desde el diseño y por defecto. El artículo 32 exige una seguridad adecuada al riesgo, que incluya confidencialidad, resiliencia y una restauración probada. Ambos se enmarcan en el principio de responsabilidad proactiva: la organización debe poder demostrar el cumplimiento, no solo afirmarlo.

Documente los flujos de datos de la bóveda, los accesos, la telemetría, la recuperación, la conservación y las relaciones con encargados o subencargados del tratamiento.

Una empresa puede aplicar una política de bóveda de base única, pero debe superponer capas más estrictas por alcance allí donde PCI, la normativa del sector financiero, la legislación sanitaria, la legislación nacional de transposición de NIS2, los contratos o el apetito de riesgo interno exijan más. Así la política sigue siendo manejable sin tratar una base general de NIST como si prevaleciera legalmente sobre los sistemas con un alcance específico.

Tabla: controles de cumplimiento del gestor de contraseñas por marco.

Resolver por alcance el conflicto de rotación de contraseñas entre NIST y PCI

No elija entre NIST y PCI de forma global. Aplique cada norma a las cuentas y los sistemas que regula. El alcance son las personas, los sistemas, los datos y los procesos a los que se aplica realmente un requisito determinado, y equivocarse en el alcance es una causa habitual de políticas de contraseñas contradictorias dentro de una misma organización.

NIST Rev. 4 establece que los verificadores no deben exigir cambios periódicos de contraseña. El requisito 8.3.9 de PCI DSS v4.0.1 crea una regla distinta cuando una contraseña o frase de contraseña es el único factor de autenticación para el acceso de los usuarios: cambiarla al menos cada 90 días o usar un análisis dinámico de la postura de seguridad para determinar el acceso. La regla puede no aplicarse cuando la MFA protege el acceso a todos los componentes dentro del alcance, conforme a las notas de aplicabilidad de PCI y a las directrices del PCI SSC. Por tanto, las dos normas solo entran en conflicto en las cuentas con contraseña de un solo factor que están dentro del alcance aplicable de PCI. No deben tratarse como un conflicto universal de políticas.

Aplique esta solución en tres pasos:

• Mantenga un inventario etiquetado de aplicaciones y cuentas que indique si cada una está dentro del CDE y si depende de una contraseña como único factor.
• En las cuentas de un solo factor dentro del alcance de PCI, confirme si la MFA cubre todos los componentes dentro del alcance antes de dar por hecho que el requisito 8.3.9 no se aplica. Si se aplica, imponga el cambio cada 90 días o la excepción permitida de análisis dinámico.
• Aplique el modelo de NIST (longitud, lista de bloqueo, sin reglas de composición y cambio tras un compromiso) a los sistemas ajenos a PCI en los que NIST sea la base de referencia.

Confirme el alcance definitivo y la correspondencia de excepciones con el evaluador de PCI de la organización antes de cambiar la política de cualquier cuenta dentro del alcance.

Relacionar las passkeys con los resultados de cada marco, no con etiquetas de cumplimiento

Una passkey (clave de acceso) es una credencial de clave pública FIDO2/WebAuthn que firma un desafío para un sitio web concreto en lugar de transmitir una contraseña reutilizable. Una passkey sincronizada está disponible en todos los dispositivos del usuario a través de un servicio de sincronización. Un autenticador vinculado a un dispositivo mantiene la clave en un único autenticador. Esa diferencia es relevante para los niveles de garantía de autenticación de NIST (AAL), que miden la confianza en un evento de autenticación.

NIST define tres niveles. AAL1 solo exige autenticación de un solo factor y admite una contraseña estándar. AAL2 y AAL3 son los niveles en los que la elección de la passkey cambia realmente lo que se puede afirmar.

Cuándo una passkey cumple AAL2

AAL2 exige dos factores de autenticación distintos o un autenticador multifactor que reúna los requisitos, y las aplicaciones deben ofrecer una opción resistente al phishing. Una passkey puede cumplir AAL2 cuando la implementación satisface esas condiciones.

Aquí importa la verificación del usuario: una credencial WebAuthn sin verificación del usuario es una autenticación criptográfica de un solo factor, no AAL2 de forma automática. En el caso de una passkey sincronizada, AAL2 exige además las salvaguardas del apéndice B y una MFA equivalente a AAL2 para acceder a la infraestructura de sincronización.

Por qué las passkeys sincronizadas no pueden alcanzar AAL3

AAL3 exige un autenticador resistente al phishing con una clave no exportable y dos factores distintos. Un autenticador vinculado a un dispositivo y no exportable es la opción pertinente en este caso. La sincronización hace que la clave de autenticación sea exportable, por lo que un autenticador sincronizado no puede cumplir el requisito de no exportabilidad de AAL3, por bien que funcione en AAL2.

Cómo afectan las passkeys a los demás marcos

En ISO 27001, SOC 2, NIS2, DORA, HIPAA y el RGPD, las passkeys pueden respaldar una autenticación segura y reducir la exposición al phishing, pero no sustituyen las revisiones de accesos, el RBAC, los controles de recuperación, el registro de eventos ni las garantías de los proveedores. En PCI DSS, la autenticación resistente al phishing puede influir en qué requisito de MFA se aplica a una ruta de acceso determinada, pero no supone una exención general de PCI. Confirme la correspondencia exacta con su evaluador.

Una passkey refuerza la autenticación, pero el cumplimiento sigue dependiendo de quién puede registrarla, cómo se revoca el acceso, cómo funciona la recuperación y qué evidencias se conservan. Una passkey sincronizada en una herramienta interna de bajo riesgo y una passkey vinculada a un dispositivo que protege una cuenta de administrador dentro del alcance de PCI satisfacen requisitos de política muy distintos, aunque ambas se llamen «passkeys».

Implementar la capa de gobernanza de credenciales

La CGO traduce el mapa de normas en cinco capas operativas, cada una con su propia acción y su propio rastro de evidencias. Un problema habitual en las auditorías es no poder demostrar el ciclo de vida de las credenciales.

• Ciclo de vida de las identidades. Conecte la bóveda a una fuente de identidades autorizada. Apruebe el acceso antes de concederlo, ajústelo cuando cambie el rol y retírelo en la baja. El acceso a la bóveda de un contratista que se marcha debe revocarse el día en que termina el contrato, no en el siguiente ciclo de nóminas. Conserve los registros de aprobación y de retirada de accesos.
• Política de autenticadores. Separe las rutas de un solo factor, de MFA y resistentes al phishing. Permita contraseñas largas generadas y el autocompletado, compruebe si las contraseñas nuevas están comprometidas y aplique una política diferenciada a las cuentas privilegiadas y a las que están dentro del alcance de PCI, como una cuenta de administrador dentro del CDE. Conserve las configuraciones de las políticas y los resultados de las comprobaciones.
• Acceso a las bóvedas. Utilice cuentas individuales, roles con mínimo privilegio, bóvedas segmentadas y acceso de terceros limitado en el tiempo. Conserve las matrices de acceso, los registros de revisión y los eventos de exportación o uso compartido.
• Evidencias y supervisión. Envíe los eventos de acceso a credenciales a un log revisable o a un sistema de gestión de información y eventos de seguridad (SIEM). Revise las anomalías, las exportaciones y los cambios de rol. Conserve los registros de las investigaciones, no solo los logs sin procesar.
• Resiliencia y privacidad. Pruebe los procedimientos de recuperación de la bóveda, copia de seguridad, acceso de emergencia y gestión de claves. Conserve los resultados de las pruebas, las aprobaciones de recuperación y las decisiones sobre riesgos.

El registro de auditoría más sólido de un gestor de contraseñas demuestra el ciclo de vida de una credencial: aprobada, emitida, utilizada, revisada, revocada y recuperable en condiciones controladas.

Convertir los controles en evidencias operativas con Passwork

Un producto debe evaluarse según ese modelo de evidencias, no según un distintivo de cumplimiento. Los controles de gestión de accesos de Passwork pueden ayudar a poner en práctica varias capas de la CGO, aunque ninguna herramienta satisface un marco por sí sola: permisos basados en grupos de Active Directory (AD) y LDAP, permisos granulares por bóveda, carpeta y contraseña, inicio de sesión único (SSO) mediante SAML, autenticación de dos factores (2FA) compatible con YubiKey y registro de auditoría de la actividad de lectura, escritura, uso compartido y exportación.

En relación con la CGO: la integración con AD/LDAP y el RBAC respaldan el ciclo de vida de las identidades, y los permisos segmentados de las bóvedas respaldan el mínimo privilegio. Los registros de auditoría respaldan la capa de evidencias. La elección entre una implementación autoalojada o en la nube respalda las decisiones de residencia de datos propias de cada alcance.

Nada de esto hace que una organización cumpla la normativa por sí solo. Proporciona al equipo de seguridad la configuración y los registros necesarios para respaldar ese trabajo, que aún debe adaptarse al alcance y a las políticas de la propia organización.

Aplicar en la práctica estas normas de cumplimiento para gestores de contraseñas

En 2026, el cumplimiento normativo del gestor de contraseñas se reduce a cuatro pasos: 

• Inventariar las cuentas y los sistemas 
• Etiquetar el alcance normativo al que pertenece cada uno
• Relacionar la capa de gobernanza de credenciales con el control aplicable más estricto
• Comprobar si el rastro de evidencias resiste una revisión 

Estas normas de cumplimiento para gestores de contraseñas coinciden en los resultados, no en un único requisito de producto.

Utilice un programa de gestión de contraseñas para convertir la política de credenciales en un control que el equipo de seguridad pueda operar y los auditores puedan verificar. Empiece esta semana por el inventario de cuentas y, como siguiente paso, consulte la guía sobre cómo usar un gestor de contraseñas.

Preguntas frecuentes