Directrices de contraseñas del NIST 2026: Qué exige SP 800-63B-4

Las directrices de contraseñas del NIST en SP 800-63B-4 exigen que las contraseñas usadas como único factor de autenticación tengan al menos 15 caracteres. Muchos resúmenes presentan esa cifra como una recomendación, pero la secc. 3.1.1.2 la formula como un requisito.

Las directrices de SP 800-63B-4 (definitivas desde julio de 2025) fijan un mínimo de 15 caracteres para el inicio de sesión solo con contraseña y de 8 cuando la contraseña es uno de los factores de una autenticación multifactor (MFA). Prohíben las reglas de composición y los cambios periódicos, y exigen que los verificadores bloqueen las contraseñas filtradas, comunes y específicas del contexto.

Esta guía clasifica cada requisito de contraseña en SHALL, SHOULD y MAY con su número de sección, muestra qué cambió respecto a la Rev 3, corrige seis interpretaciones erróneas habituales y termina con una lista de verificación para la implementación.

Directrices de contraseñas del NIST: Qué es SP 800-63B-4 y a quién se aplica

NIST SP 800-63B-4 es el volumen dedicado a la autenticación de las Digital Identity Guidelines (SP 800-63-4) del NIST. El NIST publicó la versión final en julio de 2025, que sustituye a SP 800-63B de marzo de 2020. La norma está redactada para los sistemas de información del Gobierno de EE. UU., por lo que para las organizaciones de Europa y de otras regiones es una guía voluntaria y un punto de referencia para su propia política.

SP 800-63-4 consta de cuatro volúmenes: el documento principal, la verificación de identidad (63A), la autenticación (63B) y la federación (63C). Según la página de SP 800-63-4 del NIST, la revisión llevó casi cuatro años, con dos borradores públicos y cerca de 6000 comentarios públicos.

El alcance figura en el resumen. La guía «se centra en la autenticación de los sujetos que interactúan con los sistemas de información del Gobierno» y «no pretende restringir el desarrollo ni el uso de normas fuera de este propósito». Para las agencias federales de EE. UU. y sus proveedores de servicios de credenciales, los requisitos son normativos.

El NIST usa su propio vocabulario, distinto del que emplean los proveedores:

Requisitos de contraseñas del NIST: El mapa de SHALL, SHOULD y MAY

Los requisitos de contraseñas del NIST tienen tres niveles de obligatoriedad. SHALL y SHALL NOT marcan las reglas de conformidad obligatorias de la propia norma, SHOULD marca una recomendación que solo puede omitirse con un motivo y MAY marca una opción permitida. En SP 800-63B-4, las longitudes mínimas, la prohibición de las reglas de composición y de los cambios periódicos, la comprobación con la lista de bloqueo, la limitación de intentos y el hash con sal son todos SHALL.

Como método de trabajo, aplique la política de contraseñas SHALL-first (primero lo obligatorio): implemente cada requisito obligatorio antes que cualquier recomendado. El nivel 1 es la base SHALL, el nivel 2 es el refuerzo SHOULD y el nivel 3 son las concesiones MAY, que solo se adoptan cuando encajan con los usuarios. La tabla siguiente clasifica cada requisito de contraseña en esos niveles, con la sección en la que el NIST lo establece.

Construya la política empezando por las filas SHALL. Cada fila SHOULD que se omita necesita un motivo documentado, y las filas MAY son opciones que se pueden adoptar o descartar.

Qué cambió de SP 800-63B Rev 3 a Rev 4

La Rev 4 eleva el mínimo de las contraseñas de factor único a 15 caracteres (antes 8) y pasa dos recomendaciones de la Rev 3, la ausencia de reglas de composición y de cambios periódicos, de SHOULD NOT a SHALL NOT. Las preguntas frecuentes del NIST indican que ambas prácticas antes se desaconsejaban, pero se permitían. La comprobación con la lista de bloqueo, la prohibición de pistas y de KBA, el hash con sal y la limitación de intentos ya eran obligatorios en la Rev 3.

Las preguntas frecuentes de implementación del NIST enumeran los nuevos requisitos de contraseña, y SP 800-63B Rev 3 (2020) confirma la redacción anterior. La tabla compara ambos textos.

La Rev 4 también añade requisitos para los autenticadores sincronizables, como las passkeys sincronizadas (apéndice B), y una definición de autenticador resistente al phishing (secc. 3.2.5); ambos figuran en el registro de cambios del NIST (apéndice E). En una política redactada según la Rev 3, la longitud mínima, las reglas de composición y la caducidad son lo primero que hay que cambiar.

Seis interpretaciones erróneas de las reglas de contraseñas del NIST

En los resúmenes de SP 800-63B-4 circulan seis errores: tratar los 15 caracteres como opcionales, citar 8 como mínimo general, confundir los límites de 100 y 10 intentos, dar por prohibidos los SMS, exigir que se permita pegar en lugar de los gestores de contraseñas y presentar como novedad la comprobación con la lista de bloqueo. Cada fila indica el requisito real y la sección que lo establece.

Longitud, caracteres y listas de bloqueo: Qué deben comprobar los verificadores

Los verificadores deben exigir 15 caracteres para el inicio de sesión solo con contraseña, contar cada punto de código Unicode como un carácter, renunciar a las reglas de composición y comparar cada contraseña nueva completa con una lista de bloqueo de valores filtrados, comunes y específicos del contexto. Cuando se rechaza una contraseña, el verificador debe explicar el motivo y orientar sobre cómo elegir una segura.

La regla de longitud tiene dos niveles. Una contraseña usada como único factor necesita 15 caracteres. Una contraseña que solo se usa como parte de una autenticación multifactor puede tener menos de 15, pero necesita al menos 8 (secc. 3.1.1.2). Puede fijarse un único mínimo de 15 para todas las vías, porque el NIST lo permite y así la orientación a los usuarios se reduce a una sola cifra.

Más allá del mínimo, los verificadores deberían aceptar al menos 64 caracteres y deben verificar la contraseña completa, sin truncarla. Cada punto de código Unicode cuenta como un carácter. Cuando se acepta Unicode, debería aplicarse la normalización NFC antes del hash, porque el NIST advierte de que algunos endpoints representan ciertos caracteres de forma distinta, lo que puede impedir la autenticación.

Los juegos de caracteres son abiertos: los verificadores deberían aceptar todos los caracteres ASCII imprimibles, el espacio y Unicode. No deben imponer otras reglas de composición, como exigir combinaciones de tipos de caracteres (secc. 3.1.1.1 y 3.1.1.2). El apéndice A explica el motivo: los usuarios «responden de forma muy previsible a los requisitos que imponen las reglas de composición», de modo que password se convierte en Password1 y luego en Password1!. El artículo de Passwork sobre por qué las reglas de composición fallan en la práctica analiza ese comportamiento y el cálculo de la entropía.

Cuando un usuario establece o cambia una contraseña, el verificador debe compararla con una lista de bloqueo de valores de uso común, previsibles o comprometidos. La comparación abarca la contraseña completa, no fragmentos ni palabras contenidas en ella. La lista puede nutrirse de tres fuentes:

• contraseñas de corpus de filtraciones anteriores
• palabras de diccionario
• palabras específicas del contexto, como el nombre del servicio, el nombre de usuario y sus derivados

Si la contraseña figura en la lista, el verificador debe exigir otra, indicar el motivo del rechazo y orientar sobre cómo elegir una contraseña segura. La orientación es más importante tras un rechazo, porque disuade de hacer modificaciones triviales a una contraseña de la lista.

El tamaño tiene un límite. El NIST afirma que «las listas de bloqueo excesivamente grandes aportan poco beneficio de seguridad adicional, porque la lista de bloqueo se usa para defenderse de ataques en línea, que ya están limitados por los requisitos de limitación de intentos». El objetivo es una lista lo bastante amplia para frenar las contraseñas que un atacante adivinaría antes de alcanzar el límite de intentos (SHOULD).

Al elegir una contraseña, hay dos solicitudes prohibidas. Los verificadores no deben permitir que un suscriptor almacene una pista visible para un solicitante no autenticado, ni deben solicitar autenticación basada en conocimiento (KBA) o preguntas de seguridad.

Cambios de contraseña, limitación de intentos y almacenamiento

Los verificadores no deben exigir cambios periódicos de contraseña, pero deben forzar un cambio ante evidencia de compromiso. Los intentos fallidos consecutivos se limitan a 100 por autenticador, y las contraseñas almacenadas deben guardarse con sal y hash, con una sal de al menos 32 bits. Estas reglas figuran en las secc. 3.1.1.2 y 3.2.2.

Cambios. La caducidad por calendario desaparece, y las preguntas frecuentes del NIST señalan que en la Rev 3 los cambios periódicos rutinarios «antes se desaconsejaban, pero se permitían». Se exige un cambio forzado cuando hay evidencia de que el autenticador se ha comprometido. El NIST no define esa evidencia, así que debe hacerlo la política interna. El aviso del propio suscriptor y la coincidencia de una contraseña existente con un corpus de filtraciones son dos desencadenantes prácticos, y ambos son decisiones de política, no eventos definidos por el NIST.

Limitación de intentos. Un verificador debe limitar los intentos fallidos consecutivos sobre un mismo autenticador a un máximo de 100 «deshabilitando ese autenticador», y un autenticador deshabilitado debe volver a vincularse a la cuenta antes de funcionar de nuevo (secc. 3.2.2, 4.1). El límite es un máximo, y se permiten límites más bajos. Para evitar que los atacantes bloqueen a usuarios legítimos, un verificador puede añadir una prueba de detección de bots, una espera que aumenta de 30 segundos hasta una hora o señales basadas en el riesgo. Compare el comportamiento de bloqueo del IdP con la redacción «deshabilitando». Los secretos de activación, como un PIN que nunca sale del dispositivo, siguen otra regla: al menos 4 caracteres (6 recomendados) y no más de 10 intentos fallidos consecutivos (secc. 3.2.10).

Almacenamiento. Las contraseñas deben guardarse con sal y hash mediante un esquema de hash de contraseñas adecuado, y la sal debe tener al menos 32 bits y elegirse de forma que se minimicen las colisiones entre cuentas. Los verificadores deberían usar un esquema aprobado de la última SP 800-132 o de la guía actualizada del NIST, fijar el factor de coste tan alto como sea viable y aumentarlo con el tiempo. También deberían añadir un hash con clave, con una clave secreta almacenada por separado de los hashes, idealmente en un módulo de seguridad de hardware o en un entorno de ejecución de confianza. El NIST ya no enumera algoritmos concretos porque los requisitos de almacenamiento cambian con rapidez.

El papel de las contraseñas en AAL1, AAL2 y AAL3

La autenticación solo con contraseña se permite únicamente en AAL1, y por eso la regla de los 15 caracteres se aplica en ese nivel. En AAL2, la contraseña debe combinarse con un autenticador físico, y los verificadores deben ofrecer una opción resistente al phishing. AAL3 exige un autenticador criptográfico con una clave privada no exportable, y la contraseña solo se admite como factor adicional.

Los valores proceden de las secc. 2.1 a 2.3 de la norma del NIST. Siguen tres observaciones.

1. El mínimo de 15 caracteres está ligado al uso como factor único. Las preguntas frecuentes del NIST indican que el aumento se aplica a las contraseñas «utilizadas como único factor de autenticación en AAL1».
2. Las contraseñas no son resistentes al phishing (secc. 3.1.1). En AAL2, los verificadores deben ofrecer al menos una opción resistente al phishing (secc. 2.2.2). La resistencia al phishing exige autenticación criptográfica, y los autenticadores que implican introducir manualmente un resultado, como los códigos OTP y fuera de banda, no cumplen ese requisito (secc. 3.2.5). La guía de Passwork sobre cómo funcionan las passkeys explica la parte criptográfica.
3. Los autenticadores sincronizables, como las passkeys sincronizadas, pueden servir para AAL2 si se cumplen los requisitos del apéndice B. No deben usarse en AAL3: la sincronización implica que la clave privada es exportable, y AAL3 exige una clave no exportable (secc. 2.3.2).

Los códigos por SMS y por voz forman una categoría aparte. La autenticación fuera de banda a través de la red telefónica es un autenticador restringido. La organización debe evaluar y aceptar el riesgo, ofrecer al menos una alternativa no restringida, informar adecuadamente a los suscriptores y mantener un plan de migración (secc. 3.1.3.3, 3.2.9).

Cómo aplicar las directrices de contraseñas del NIST: Una implementación SHALL-first

Una implementación SHALL-first configura cada requisito obligatorio antes que cualquier recomendado. Inventaríe cada sistema que verifica contraseñas, fije el mínimo de 15 caracteres, elimine las reglas de composición y de caducidad, active la comprobación con la lista de bloqueo, confirme la limitación de intentos, audite el código propio, ofrezca autenticación resistente al phishing y documente las excepciones en un registro.

1. Inventaríe todos los puntos en los que se verifica una contraseña: directorio, IdP, VPN, aplicaciones para clientes y aplicaciones internas. Las obligaciones del NIST recaen en el verificador, así que cada sistema que comprueba una contraseña necesita su propia fila.
2. Fije la longitud mínima. Use 15 caracteres en todas las vías solo con contraseña y decida el mínimo para las vías con MFA: el NIST permite 8 en ellas, y una única regla de 15 para ambas simplifica la política y la orientación a los usuarios.
3. Elimine las reglas de composición de la política de contraseñas del directorio, de la política del IdP y del código de las aplicaciones.
4. Elimine la caducidad por calendario. Mantenga el cambio forzado ante evidencia de compromiso y documente qué lo desencadena.
5. Active la comprobación con la lista de bloqueo al establecer y al cambiar contraseñas, incluidas las palabras específicas del contexto, como el nombre del servicio y el nombre de usuario. El mensaje de rechazo debe indicar el motivo y ofrecer orientación. Si el directorio no puede hacer esta comprobación de forma nativa, el requisito sigue recayendo en el verificador, así que compruebe qué puede hacer el IdP.
6. Compruebe la limitación de intentos: como máximo 100 fallos consecutivos por autenticador. Aplique un límite más bajo y retardos progresivos donde el negocio pueda asumirlos, y compare el comportamiento de bloqueo con la redacción del NIST «deshabilitando ese autenticador».
7. Audite las aplicaciones propias. Deberían aceptar 64 caracteres o más, Unicode y espacios, permitir pegar y el autocompletado, no truncar nunca y almacenar las contraseñas con sal y hash mediante un esquema actual. Suprima los filtros de caracteres especiales pensados para frenar la inyección SQL: el apéndice A señala que una contraseña sin hash nunca se envía íntegra a una base de datos, por lo que esos filtros son innecesarios.
8. Ofrezca autenticación resistente al phishing para el acceso privilegiado y remoto. Las contraseñas no son resistentes al phishing, y los verificadores de AAL2 deben ofrecer al menos una opción resistente al phishing.
9. Documente las excepciones. Un contrato o un marco de cumplimiento puede seguir exigiendo otra cosa, como la rotación periódica de contraseñas. Registre cada excepción con el requisito, el motivo, un responsable y una fecha de revisión.

El papel del gestor de contraseñas en una política según SP 800-63B-4

SP 800-63B-4 exige que los verificadores permitan los gestores de contraseñas y el autocompletado, y el NIST señala que los gestores aumentan la probabilidad de usar contraseñas más seguras, sobre todo con generadores. Un gestor de contraseñas cubre las credenciales que el proveedor de identidad no verifica. No cambia la forma en que el directorio o el IdP verifican las contraseñas, que sigue siendo una tarea de configuración independiente.

Dos grupos de credenciales quedan fuera de la configuración del verificador: las cuentas en sistemas SaaS y de proveedores que la organización no verifica por sí misma, y las credenciales compartidas o privilegiadas que ninguna política de contraseñas del directorio cubre. Ambos necesitan contraseñas largas, aleatorias y únicas.

Passwork respalda este uso con cuatro funciones:

• Un generador de contraseñas integrado en la interfaz web, la extensión del navegador y las aplicaciones móviles y de escritorio. Aplica las reglas definidas por la organización y ayuda a los usuarios a crear una contraseña única para cada servicio.
• Un panel de seguridad que informa de la robustez de las contraseñas (según la longitud y la diversidad de caracteres), su antigüedad (marca las contraseñas sin cambiar durante 180 días o más) y el riesgo de compromiso, como las contraseñas que siguen accesibles para usuarios cuyo acceso se revocó. Los administradores pueden filtrar por bóveda, carpeta, usuario y categoría de amenaza.
• Una política de bloqueo para la autenticación local, configurable por el administrador, con un número máximo de intentos fallidos, un intervalo de tiempo y una duración del bloqueo. Rige el inicio de sesión propio de la bóveda y es independiente del límite de intentos que aplica el verificador según la secc. 3.2.2.
• Inicio de sesión con passkeys (WebAuthn), TOTP, SSO mediante SAML o LDAP/AD, además de un registro de actividad de las acciones de usuarios, administradores y del sistema que puede exportarse a sistemas SIEM.

La marca de antigüedad es una señal de revisión, no una regla de caducidad. La secc. 3.1.1.2 prohíbe exigir cambios periódicos de las contraseñas que comprueba el propio verificador, y la plataforma no cambia eso.

Conclusión

Las directrices de contraseñas del NIST en SP 800-63B-4 se resumen en una política breve: una longitud mínima, sin reglas de composición, sin calendario de caducidad, con comprobación mediante lista de bloqueo, limitación de intentos y hash con sal. Aplique la política de contraseñas SHALL-first antes de dedicar esfuerzo a las filas SHOULD.

Empiece con tres cambios. Fije 15 caracteres en todas las vías solo con contraseña y elimine las reglas de composición y de caducidad. Añada la comprobación con la lista de bloqueo allí donde se establezcan contraseñas. Ofrezca autenticación resistente al phishing a los usuarios privilegiados. Las credenciales de sistemas que quedan fuera de la política de contraseñas del IdP siguen necesitando valores largos y únicos, y su lugar es un gestor de contraseñas.

Consulte la robustez, la antigüedad y el riesgo de compromiso de las contraseñas de todas las bóvedas en un solo panel. Inicie una prueba gratuita de Passwork y compruebe el estado de sus credenciales compartidas.

Preguntas frecuentes

Brecha de seguridad de Northflank: Qué rotar tras el incidente

Northflank pidió a sus clientes que dieran por descifradas todas las variables de entorno. Railway advirtió de que algunas podrían haberlo sido, y Huntress detectó tokens de M365 robados reutilizados en 79 organizaciones. Qué comunicó cada uno y qué rotar.

PassworkPasswork Team

Gestión de accesos en NIS2: Lo que cinco expertos corregirían primero

De la política a la práctica: ¿quién tuvo acceso a qué, con la aprobación de quién, durante cuánto tiempo y puede demostrarse? Cinco responsables de ciberseguridad hablan de los controles de acceso más difíciles de llevar a la práctica y de las evidencias que necesitan las organizaciones para demostrar que funcionan.

PassworkPasswork Team

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

El NIST dice que no se roten nunca. PCI DSS aún puede exigirlo cada 90 días. Esta guía relaciona nueve marcos de cumplimiento y las passkeys con los controles de la bóveda y muestra cómo resolver el conflicto según el alcance.

PassworkAlex Muntyan