NIST SP 800-63: los niveles de aseguramiento que miden 'suficientemente fuerte'

“Que el login sea seguro”

Daniel está en una reunión de planificación de una app nueva para clientes que permitirá mover dinero entre cuentas. La responsable de producto dice que el inicio de sesión tiene que ser “seguro pero que no moleste”. El responsable de cumplimiento dice que tiene que ser “lo bastante fuerte para el regulador”. La ingeniera que se sienta junto a Daniel pregunta qué significa cualquiera de las dos cosas en la práctica. Nadie sabe responder, porque “seguro” y “lo bastante fuerte” no son medidas. Entonces el responsable de cumplimiento abre la guía del regulador y lee una línea en voz alta: “IAL2 y AAL2”. De repente hay algo que todos pueden construir y comprobar.

Esa línea viene de NIST SP 800-63. Los artículos anteriores recorrieron protocolos, desde la pila principal de federación hasta los veteranos y la vanguardia. Saber qué protocolo usar, Kerberos, SAML, OIDC o FIDO2, te dice cómo funciona la identidad. No responde a la pregunta que de verdad hace quien es dueño del riesgo: ¿cuánta fuerza necesita esto? Lo bastante fuerte para un foro y lo bastante fuerte para un banco son cosas muy distintas, y hace falta un vocabulario preciso y compartido para especificarlas y compararlas.

NIST SP 800-63, las Directrices de Identidad Digital de Estados Unidos, se cita mucho más allá de ese país, por reguladores, auditores y equipos de compras, como la forma estándar de medir el aseguramiento de la identidad. Su movimiento central es negarse a un “nivel de seguridad” único y separar el aseguramiento en tres dimensiones independientes, cada una con un valor de 1 a 3. Un protocolo te dice qué es posible; un nivel de aseguramiento te dice qué se exige. Necesitas las dos cosas para convertir “construye algo seguro” en un diseño que puedas especificar, construir y defender en una auditoría.

Tres diales independientes

Las directrices se reparten en tres volúmenes, uno por dimensión: el 63A trata el alta y la verificación de identidad (IAL), el 63B la autenticación (AAL) y el 63C la federación (FAL). Están separados justamente porque las tres cosas se eligen por separado.

Cuánta seguridad tienes sobre quién es la persona (IAL), con cuánta fuerza se autentica (AAL) y con cuánta seguridad viaja una aserción federada (FAL) son tres preguntas distintas. Puedes necesitar una verificación de identidad fuerte con poca fricción al iniciar sesión, o justo lo contrario. Fundirlas en un solo “nivel” es el error que el estándar existe para evitar. Veamos cada dial y cómo conecta con algo de lo que ya hemos visto en el módulo.

IAL: verificar quién es la persona

El IAL responde a una pregunta que se hace una sola vez, en el alta: ¿cuánta confianza tenemos en que se trata de una persona real y concreta? Trata de la verificación de identidad (identity proofing), lo que haces una vez, al crear la cuenta, para atarla a un ser humano de verdad. No dice nada de cómo inicia sesión después.

El salto que importa es de IAL1 a IAL2, de “has escrito un nombre” a “hemos comprobado pruebas reales de que eres esa persona”. Es la verificación de identidad que protege las altas sensibles, y la razón por la que un especialista de telemedicina o el cliente de un banco pasan por comprobaciones de documento y de prueba de vida que un foro nunca pide. Un IAL más alto supone más fricción y más datos recogidos, así que solo se sube cuando el riesgo de una identidad falsa o equivocada lo justifica. En la app de Daniel, IAL2 es lo que impide que alguien abra una cuenta a nombre de un desconocido.

Cómo se verifica la identidad en la práctica

La verificación IAL2 tiene en la práctica tres pasos: reunir una prueba de identidad, como un documento oficial; validar que la prueba es auténtica; y comprobar que quien la presenta es su legítimo titular, cada vez más comparando un selfi con el documento mediante detección de vida que frena fotos impresas y deepfakes. Por el camino algo ha caído en desgracia: la verificación basada en conocimiento, preguntas como “¿cuál era tu dirección anterior?”, ya no se recomienda, porque años de filtraciones han hecho públicas esas respuestas. IAL3 añade un paso supervisado, en persona o en remoto con un operador formado mirando.

La verificación de identidad se ha convertido en una carrera armamentística. Las identidades sintéticas y los documentos generados con IA no paran de mejorar, así que el listón de “hemos verificado a un ser humano real y concreto” no deja de subir, y por eso la verificación se apoya cada vez más en señales que van más allá del propio documento.

AAL: con cuánta fuerza inicia sesión el usuario

El AAL responde a una pregunta que se hace en cada inicio de sesión: ¿con cuánta fuerza demuestra el usuario que vuelve que es él de verdad? Es el terreno de los artículos de factores de autenticación y de MFA, convertido en niveles.

AAL3 es donde la vanguardia FIDO2 y WebAuthn se gana su sitio: solo un autenticador resistente al phishing y ligado al hardware supera ese listón, y por eso los sistemas de alto aseguramiento avanzan hacia el inicio de sesión sin contraseña y resistente al phishing. Y el AAL es independiente del IAL. Un usuario con la identidad bien verificada (IAL2) que solo usa contraseña sigue estando en AAL1, y una cuenta anónima (IAL1) puede iniciar sesión con una llave de hardware en AAL3. La fuerza de la verificación y la fuerza del inicio de sesión son preguntas distintas.

El aseguramiento se desgasta

El AAL no trata solo del momento del inicio de sesión. También fija cuánto puede durar una sesión antes de que el usuario tenga que volver a demostrar quién es. Los niveles altos exigen ventanas de reautenticación más cortas: AAL2 espera reautenticar más o menos cada 12 horas, o tras un periodo de inactividad (habitualmente 30 minutos), y AAL3 es todavía más estricto. La idea es que el aseguramiento se desgasta. Cuanto más tiempo pasa desde la última prueba, más débil es la garantía de que quien está ante el teclado sigue siendo quien se autenticó. NIST ya recoge que un inicio de sesión no es un hecho permanente, aunque lo haga con intervalos de tiempo gruesos en lugar de señales en vivo. La frontera lleva esa idea mucho más lejos.

FAL: con cuánta seguridad viaja la aserción

El FAL se aplica cuando la identidad está federada, cuando un proveedor de identidad responde por el usuario ante una parte que confía. Mide con cuánta seguridad llega esa aserción.

El FAL anuda hilos de todo el módulo. El “al portador” de FAL1 es el riesgo de los tokens bearer que no hemos dejado de señalar: tenerlo basta para usarlo. FAL2 añade la confidencialidad de JWE. Y el holder-of-key de FAL3 es la misma idea de prueba de posesión que DPoP y mTLS: atar la aserción a una clave para que una copia robada no valga nada. El FAL es donde se ponen nota los protocolos que vimos antes.

Combinar los diales para un caso de uso

Como los tres son independientes, diseñar para un caso de uso consiste en evaluar el riesgo de cada dimensión y elegir el nivel más bajo que lo cubra.

flowchart LR
  accTitle: Combinar IAL, AAL y FAL en una postura de aseguramiento
  accDescr: Tres preguntas independientes alimentan tres dimensiones de aseguramiento independientes. La verificación de identidad, quién eres de verdad, fija el Identity Assurance Level de 1 a 3. La autenticación, con cuánta fuerza lo demuestras en cada inicio de sesión, fija el Authenticator Assurance Level de 1 a 3. La federación, con cuánta seguridad se transmite la aserción, fija el Federation Assurance Level de 1 a 3. Los tres niveles elegidos se combinan en la postura de aseguramiento que exige el caso de uso, cada dial ajustado al riesgo de su propia dimensión.
  P[Verificación<br/>¿quién eres de verdad?] --> IAL[IAL 1-3]
  A[Autenticación<br/>¿con cuánta fuerza, cada vez?] --> AAL[AAL 1-3]
  F[Federación<br/>¿cómo viaja la aserción?] --> FAL[FAL 1-3]
  IAL --> POS[Postura de aseguramiento<br/>para este caso]
  AAL --> POS
  FAL --> POS

Un banco minorista, como la app de Daniel, necesita al menos IAL2 y AAL2. El dinero y la regulación piden identidad verificada y MFA, y el FAL entra si los clientes llegan por federación, ajustado a lo sensible de la aserción. Un foro de debate anónimo funciona con IAL1 y AAL1. No hay motivo para saber quién es de verdad la persona, una contraseña puede bastar, y subir los diales añadiría fricción sin reducir ningún riesgo. Las prestaciones públicas o el acceso de administración privilegiado empujan hacia IAL3 y AAL3, identidad verificada en persona y un autenticador de hardware resistente al phishing, porque una suplantación ahí hace mucho daño.

La disciplina consiste en ajustar cada dial a su propio riesgo, sin subirlo todo al máximo, que agota a los usuarios y al presupuesto, ni dejarlo todo bajo, que invita al fraude. Todo el valor de separar las dimensiones está ahí: fuerte donde importa, ligero donde no.

Un caso menos evidente muestra la independencia con más claridad. Un servicio preocupado por la privacidad puede elegir a propósito IAL1 con un AAL alto. No quiere saber quién eres de verdad, así que la verificación es baja, pero sí quiere un inicio de sesión fuerte y resistente al phishing. Saber poco de la persona y autenticarla con fuerza es una postura perfectamente coherente, y NIST incluso contempla la federación con seudónimo, en la que la parte que confía sabe que hay un sujeto válido y bien autenticado sin recibir su identidad real. Si tu intuición era que más identidad y un inicio de sesión más fuerte suben siempre juntos, este caso la rompe, y es la razón de que los diales vayan separados.

También explica un error de diseño frecuente: tocar el dial equivocado. Si están robando cuentas en el inicio de sesión, es un problema de AAL. Añade MFA o resistencia al phishing; pedir más documentos de identidad no ayudará. Si los estafadores abren cuentas falsas, es un problema de IAL. Refuerza la verificación; obligar a todo el mundo a usar llaves de hardware no ayudará. Saber a qué dial pertenece un riesgo es la mitad de arreglarlo bien. Subir la fricción en un dial que no es el origen del riesgo cuesta usabilidad y adopción sin comprar seguridad real. Los usuarios honestos sufren mientras el hueco de verdad sigue abierto.

Cómo encajan los diales en la decisión de acceso

Los tres diales coinciden con las etapas de los pilares IAAA, y por eso el modelo resulta natural en cuanto los ves. El IAL trata de la identificación y el alta, de establecer una vez que hay una persona real detrás de la cuenta. El AAL trata de la autenticación, de comprobar en cada acceso que el sujeto que vuelve es esa misma persona. El FAL trata de cómo viaja la aserción resultante cuando la autenticación se delega en un proveedor de identidad.

Lo que falta en la lista es la autorización. El aseguramiento de NIST responde a cuánta seguridad tenemos sobre quién es y con qué seguridad lo establecimos, no a qué puede hacer. La autorización, los modelos, políticas y permisos del siguiente dominio, usa ese aseguramiento como dato de entrada. Una acción de alto valor puede exigir un AAL mínimo antes de seguir adelante, que es la idea de la autenticación escalonada con un nivel preciso. En la app de Daniel, consultar el saldo puede valer con el nivel actual de la sesión, mientras que añadir un beneficiario nuevo exige una comprobación AAL2 reciente.

Por qué importan los niveles en la práctica

Los niveles de aseguramiento no son una taxonomía académica. Son la forma en que la identidad se especifica y se audita. Los pliegos y las RFP indican niveles concretos (“la solución debe soportar AAL2”), lo que convierte un vago “hazlo seguro” en un requisito que se puede comprobar. Los reguladores y los auditores se refieren a ellos: un marco de control puede exigir un nivel para un tipo de datos, y un evaluador puede verificarlo de forma objetiva. Los análisis de riesgo usan los tres diales como una forma estructurada de razonar sobre una aplicación en lugar de discutir de “seguridad” en abstracto. Es justo lo que pasó en la reunión de Daniel: en cuanto el requisito fue IAL2 y AAL2, producto, cumplimiento e ingeniería hablaban de lo mismo.

Más allá de NIST

NIST SP 800-63 es una guía estadounidense, pero la forma de pensar es global, y otros marcos expresan la misma idea con sus palabras. eIDAS, en la UE, define niveles de seguridad, bajo, sustancial y alto, para la identificación electrónica. No se separan en tres diales como hace NIST, pero “sustancial” y “alto” quedan cerca de la zona de IAL2/AAL2 e IAL3/AAL3, y el trabajo de la UE sobre la cartera de identidad digital les está dando más protagonismo. ISO/IEC 29115 ofrece un modelo internacional de cuatro niveles de aseguramiento de la autenticación, anterior y paralelo al de NIST. Y las normas sectoriales y regionales, desde los reguladores financieros hasta los regímenes de privacidad sanitaria y los programas públicos de identidad, suelen remitir a un nivel de aseguramiento en lugar de volver a detallar controles, porque “debe cumplir AAL2” es mucho más preciso y auditable que “usa autenticación fuerte”.

Así que, aunque un proyecto se rija por eIDAS o por una norma local y no directamente por NIST, el modelo de IAL, AAL y FAL sigue funcionando como idioma común para razonar sobre el aseguramiento.

Revisión 4: hacia dónde va el estándar

Las directrices son documentos vivos, y la Revisión 4, cerrada en 2025, muestra hacia dónde va el pensamiento sobre el aseguramiento. La resistencia al phishing pasa al centro, porque el phishing de credenciales y los ataques que se saltan el MFA, y no solo las contraseñas débiles, son hoy los ataques dominantes. Los autenticadores sincronizables, es decir, las passkeys, se aceptan; las revisiones anteriores encajaban mal con credenciales sincronizadas en la nube, y la Rev 4 aclara dónde caben, reconociendo la realidad de FIDO2. El fraude, la equidad y la usabilidad pesan de verdad: el estándar reconoce cada vez más que una verificación demasiado pesada deja fuera a gente legítima, y que el aseguramiento consiste tanto en dejar entrar a quien debe como en dejar fuera a los atacantes. Y el modelo de un momento concreto se suaviza hacia una evaluación continua y adaptada al riesgo.

No hace falta memorizar números de revisión, pero sí conocer la dirección: hacia la resistencia al phishing y las passkeys, y lejos del aseguramiento como un sello que se pone una vez.

El puente hacia la frontera

Ese último punto lleva al siguiente artículo. El modelo de NIST es, en su forma clásica, un aseguramiento establecido en un momento concreto. Verificas la identidad una vez (IAL), te autenticas al iniciar sesión (AAL), la aserción viaja (FAL) y se concede el acceso. La frontera aprieta justo en ese “momento concreto”: la evaluación continua del acceso, los tokens atados al emisor y la identidad efímera de las cargas de trabajo preguntan si el aseguramiento sigue siendo válido ahora mismo, en lugar de fiarse de un nivel fijado hace minutos u horas. Aprende aquí a medir el aseguramiento en un momento, y después mira cómo el sector aprende a medirlo una y otra vez.

Resumen

NIST SP 800-63 es el vocabulario para especificar cuánta fuerza necesita la identidad.

1. Define tres diales independientes, cada uno de 1 a 3, que se ajustan por separado al riesgo de cada caso y nunca se funden en un único “nivel”.
2. El IAL (verificación) mide cuánta seguridad tienes sobre quién es la persona: autodeclarado, pruebas verificadas o en persona con pruebas fuertes. Es una pregunta de una sola vez, en el alta.
3. El AAL (autenticación) mide con cuánta fuerza lo demuestra en cada inicio de sesión: un factor, MFA o hardware resistente al phishing como FIDO2. Un AAL más alto también implica ventanas de reautenticación más cortas.
4. El FAL (federación) mide con cuánta seguridad viaja la aserción: al portador, cifrada o holder-of-key. FAL3 es la misma idea de prueba de posesión que DPoP.
5. Se combinan según el riesgo: la banca en torno a IAL2 y AAL2, un foro en torno a IAL1 y AAL1, el acceso de alto valor hacia IAL3 y AAL3, e incluso IAL1 con un AAL alto cuando quieres un inicio de sesión fuerte sin saber quién es el usuario. Arregla cada riesgo con el dial al que pertenece.
6. La autorización usa el aseguramiento como dato de entrada, así que las acciones sensibles pueden exigir un nivel mínimo. El modelo viaja fuera de Estados Unidos (eIDAS, ISO 29115) y avanza hacia la evaluación continua.

Ejercicios prácticos

Están pensados para hacerse, no solo para leerse.

1. Puntúa un servicio que uses. Elige una app en la que inicies sesión y estima su IAL, su AAL y su FAL. ¿Qué pruebas pidió en el alta? ¿Qué te pide al iniciar sesión? Si entras a través de otro proveedor, ¿cómo se protege esa aserción?
2. Elige el dial. Para cada problema, di si es de IAL, AAL o FAL y cuál es el arreglo: cuentas falsas inundando el alta; credenciales robadas por phishing que se reutilizan; una aserción federada interceptada y reutilizada en otra parte que confía.
3. Diseña una postura. Especifica IAL, AAL y FAL para un juego infantil, una app para operar en bolsa y una consola de administración interna de la infraestructura de producción. Justifica cada dial según su riesgo.
4. Defiende la independencia. Alguien dice: “Ponlo todo en nivel 3 y listo”. Da el argumento, en dos frases, de por qué subir todos los diales al máximo suele ser una mala decisión.
5. Relaciónalo con un protocolo. Tu diseño pide AAL3 y FAL3. Nombra un autenticador concreto que cumpla AAL3 y un mecanismo de aserción concreto que cumpla FAL3, y relaciona cada uno con un protocolo de antes en el módulo.
6. Traduce la norma. Una norma dice que un servicio que maneja historiales clínicos debe cumplir “IAL2/AAL2 con reautenticación”. Enumera los pasos concretos de verificación, el requisito de inicio de sesión y cada cuánto, más o menos, tiene que reautenticarse el usuario, y relaciona cada requisito con algo que describieron los artículos anteriores.

Tres preguntas para ponerte a prueba

1. Explica por qué el IAL y el AAL son independientes, con un ejemplo de cuenta con IAL alto y AAL bajo y otro de cuenta con IAL bajo y AAL alto.
2. ¿De qué protege FAL3 (holder-of-key) que no cubra FAL1 (al portador), y qué tecnología de la frontera encarna la misma idea?
3. Un regulador exige “IAL2 y AAL2” para una aplicación. Conviértelo en requisitos concretos y construibles para la verificación de identidad y para el inicio de sesión.