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

De “qué protocolo” a “cuánto aseguramiento”

Los últimos dos artículos recorrieron protocolos — los veteranos y la vanguardia — y el próximo mira a la frontera. Este es el puente entre ellos. Saber qué protocolo usar (Kerberos, SAML, OIDC, FIDO2) responde cómo funciona la identidad. No responde la pregunta que un dueño de riesgo realmente hace: ¿qué tan fuerte debe ser esto? “Suficientemente fuerte” para un foro de discusión y “suficientemente fuerte” para un banco son muy distintos, y necesitas un vocabulario preciso y compartido para especificarlos y compararlos. Ese vocabulario es NIST SP 800-63.

NIST SP 800-63, las Digital Identity Guidelines de EE. UU., se referencia mucho más allá de EE. UU. — por reguladores, auditores y equipos de compras en todo el mundo — como la forma estándar de medir el aseguramiento de identidad. Su movimiento central es rechazar un único “nivel de seguridad” y en su lugar romper el aseguramiento en tres dimensiones independientes, cada una calificada de 1 a 3. Es el tejido conectivo normativo de todo este módulo: los protocolos son el cómo, NIST es el cuánto, y la frontera es donde el “cuánto” se vuelve continuo en lugar de decidido una vez.

Ese rol de puente es justo por lo que este artículo se ubica donde está — entre los protocolos concretos de los veteranos y la vanguardia y la mirada hacia adelante de la frontera. Un protocolo te dice lo que es posible; un nivel de aseguramiento te dice lo que se requiere. Necesitas ambos para convertir “construye algo seguro” en un diseño que puedas de verdad especificar, construir y defender en una auditoría.

Tres diales independientes

Las guías están organizadas en tres volúmenes, uno por dimensión — 63A (enrolamiento y prueba → IAL), 63B (autenticación → AAL) y 63C (federación → FAL) — precisamente porque los tres están pensados para elegirse por separado.

Pantalla completa

Tomemos cada dial por turno, y notemos cómo cada uno conecta con un protocolo o concepto de antes en el módulo.

IAL — Identity Assurance Level (prueba de identidad)

IAL responde una pregunta de una sola vez, en el momento del enrolamiento: ¿qué tan seguros estamos de que esta es una persona real y específica? Trata de la prueba de identidad — lo que haces una vez, cuando se crea una cuenta, para atarla a un humano real. No dice nada de cómo inicia sesión después.

El salto que importa es IAL1 → IAL2: de “escribiste un nombre” a “verificamos evidencia real de que eres esa persona”. Esta es la prueba de identidad que controla el onboarding sensible, y es por lo que un especialista de telesalud o un cliente de banco pasa por verificaciones de documento y liveness que un registro de foro nunca hace. Un IAL más alto significa más fricción y más datos recolectados — así que lo subes solo cuando el riesgo de una identidad falsa o equivocada lo justifica.

Cómo ocurre la prueba en la práctica

La prueba IAL2 en la práctica son tres pasos: recolectar evidencia de identidad (un ID gubernamental), validar que la evidencia es genuina, y verificar que la persona que la presenta es su dueño legítimo — cada vez más al hacer match de una selfie con el documento con detección de liveness para vencer fotos impresas y deepfakes. Nota lo que ha caído en desuso: la verificación basada en conocimiento (“¿cuál fue tu dirección anterior?”) ahora se desaconseja, porque años de brechas volvieron públicas esas respuestas. IAL3 agrega un paso supervisado — en persona, o remoto estrechamente supervisado por un operador entrenado. La realidad moderna es que la prueba es una carrera armamentista: las identidades sintéticas y los documentos generados por IA mejoran, así que el listón para “verificamos un humano real y específico” sigue subiendo — y por eso la prueba se apoya cada vez más en señales más allá del documento mismo.

AAL — Authenticator Assurance Level (autenticación)

AAL responde una pregunta que se hace en cada login: ¿qué tan fuerte el usuario que regresa prueba que es realmente él? Esta es la dimensión en la que viven nuestros artículos de factores de autenticación y MFA, ahora formalizada en niveles.

AAL3 es justo donde la vanguardia FIDO2/WebAuthn se gana su lugar: solo un autenticador resistente a phishing y atado a hardware supera ese listón, y por eso “passwordless, resistente a phishing” es la dirección a la que se mueven los sistemas de alto aseguramiento. Crucialmente, AAL es independiente de IAL — un usuario bien probado (IAL2) que solo usa una contraseña sigue siendo AAL1, y una cuenta anónima (IAL1) igual puede iniciar sesión con una llave hardware en AAL3. La fuerza de la prueba y la fuerza del login son preguntas distintas.

Reautenticación: el aseguramiento decae con el tiempo

AAL no trata solo del momento del login — también gobierna cuánto puede durar una sesión antes de que el usuario deba probarse de nuevo. Los niveles más altos exigen ventanas de reautenticación más cortas: AAL2 espera reautenticación del orden de cada 12 horas, o tras un periodo de inactividad (comúnmente 30 minutos), y AAL3 es aún más estricto. El razonamiento es que el aseguramiento decae — mientras más tiempo desde la última prueba, más débil la garantía de que la persona en el teclado sigue siendo el usuario autenticado. Esto es un anticipo callado de la evaluación continua de la frontera: NIST ya codifica la idea de que un login no es un hecho para siempre, solo a intervalos gruesos basados en tiempo en lugar de señales en vivo.

FAL — Federation Assurance Level (la assertion)

FAL aplica cuando la identidad está federada — cuando un proveedor de identidad responde por el usuario ante un relying party. Mide qué tan seguro viaja esa assertion:

FAL ata hilos de todo el módulo. El “bearer” de FAL1 es justo el riesgo del bearer token que seguimos marcando — la posesión equivale al uso. FAL2 agrega la confidencialidad de JWE. Y el holder-of-key de FAL3 es la misma idea de prueba de posesión que DPoP y mTLS de la frontera: atar la assertion a una clave para que una robada no valga nada. Leyendo FAL, puedes sentir todo el módulo conectándose — los niveles de aseguramiento son donde los protocolos se califican.

Combinar los diales para un caso de uso

Como los tres son independientes, diseñar para un caso de uso significa 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 prueba de identidad — quién eres realmente — ajusta el Identity Assurance Level de 1 a 3. La autenticación — qué tan fuerte lo pruebas en cada login — ajusta el Authenticator Assurance Level de 1 a 3. La federación — qué tan seguro se transmite la assertion — ajusta el Federation Assurance Level de 1 a 3. Los tres niveles elegidos se combinan en la postura de aseguramiento general que requiere el caso de uso, cada dial ajustado al riesgo de su propia dimensión.
  P[Prueba<br/>¿quién eres, realmente?] --> IAL[IAL 1–3]
  A[Autenticación<br/>¿qué tan fuerte, cada login?] --> AAL[AAL 1–3]
  F[Federación<br/>¿cómo viaja la assertion?] --> FAL[FAL 1–3]
  IAL --> POS[Postura de aseguramiento<br/>para este caso de uso]
  AAL --> POS
  FAL --> POS

Algunas posturas trabajadas:

• Un banco minorista: al menos IAL2 / AAL2. El dinero y la regulación exigen identidad verificada (IAL2) y MFA (AAL2); FAL aplica si los clientes llegan por federación, escalado a la sensibilidad.
• Un foro de discusión anónimo: IAL1 / AAL1 está bien. No hay razón para saber quién es realmente la persona, y una contraseña puede bastar — subir los diales agregaría fricción sin reducir riesgo.
• Beneficios gubernamentales o acceso privilegiado de admin: empujando hacia IAL3 / AAL3 — identidad verificada en persona y un autenticador hardware resistente a phishing, porque la suplantación es de alto impacto.

La disciplina es ajustar cada dial a su propio riesgo, no subir todo al máximo (que quema usuarios y presupuesto) ni dejar todo bajo (que invita al fraude). Ese es el valor entero de separar las dimensiones: fuerte donde importa, ligero donde no.

Un caso más sutil muestra la independencia en su punto más agudo: un servicio con conciencia de privacidad puede elegir deliberadamente IAL1 con un AAL alto — no desea saber quién eres realmente (prueba baja), pero igual quiere un login fuerte y resistente a phishing (autenticación alta). Saber menos del humano mientras lo autenticas fuertemente es una postura perfectamente coherente, y NIST incluso soporta la federación seudónima, donde el relying party aprende que hay un sujeto válido y bien autenticado sin recibir su identidad del mundo real. Si tu instinto era que “más identidad” y “login más fuerte” siempre suben juntos, este es el caso que lo rompe — y la razón de que los diales sean separados.

Cómo los diales mapean a la decisión de acceso

Los tres diales se alinean limpiamente con las etapas de acceso de los pilares IAAA, y por eso el modelo se siente natural una vez que los has visto:

• IAL trata de la identificación y el enrolamiento — establecer, una vez, que una persona real está detrás de la cuenta. Es la prueba que ocurre antes de que la cuenta se use.
• AAL trata de la autenticación — verificar, en cada acceso, que el sujeto que regresa es esa misma persona.
• FAL trata de cómo se transporta la assertion resultante cuando la autenticación se delega a un proveedor de identidad.

Nota lo que no está en la lista: la autorización. El aseguramiento de NIST responde “qué tan seguros estamos de quién es esto, y qué tan seguro lo establecimos” — no “qué puede hacer”. La autorización (los modelos xBAC, políticas y permisos del siguiente dominio) consume ese aseguramiento como entrada: una acción de alto valor puede requerir un AAL mínimo antes de proceder — la idea de step-up authentication, ahora con un nivel preciso atado. Los niveles de aseguramiento son la unidad en que se especifica “pruébate más antes de hacer esto”.

Por qué los niveles importan en la práctica

Los niveles de aseguramiento no son una taxonomía académica — son cómo la identidad se especifica y audita:

• Compras y RFPs declaran niveles requeridos (“la solución debe soportar AAL2”), convirtiendo un difuso “hazlo seguro” en un requisito verificable.
• Reguladores y auditores los referencian: un marco de control puede mandar un nivel para una clase de datos, y un evaluador puede verificarlo objetivamente.
• Las evaluaciones de riesgo usan los tres diales como una forma estructurada de razonar sobre una aplicación en lugar de discutir sobre “seguridad” en abstracto.
• Alineación internacional: los niveles de aseguramiento de eIDAS de la UE (bajo / sustancial / alto) mapean aproximadamente a este pensamiento, así que el modelo mental IAL/AAL/FAL viaja.

Por eso el estándar es el puente en este módulo: los protocolos veteranos y de vanguardia te dan los mecanismos, y NIST SP 800-63 te da la vara de medir para decir cuánto mecanismo exige un riesgo dado — el idioma compartido entre el ingeniero que lo construye y el dueño de riesgo que lo aprueba.

Más allá de NIST: cómo viaja el modelo

NIST SP 800-63 es guía de EE. UU., pero la forma de pensar es global, y otros marcos expresan la misma idea en su propio vocabulario:

• eIDAS (UE) define Niveles de Aseguramiento — bajo / sustancial / alto — para la identificación electrónica. No se dividen limpiamente en tres diales separados como NIST, pero “sustancial” y “alto” rastrean de cerca la región de IAL2/AAL2 e IAL3/AAL3, y el trabajo de la wallet de identidad digital de la UE está elevando su perfil.
• ISO/IEC 29115 ofrece un modelo internacional de cuatro niveles de aseguramiento de autenticación de entidades que precede y corre en paralelo al pensamiento de NIST.
• Reglas sectoriales y regionales — reguladores financieros, regímenes de privacidad de salud, programas de identidad gubernamental — frecuentemente referencian un nivel de aseguramiento en lugar de re-especificar controles, porque “debe cumplir AAL2” es mucho más preciso y auditable que “usa autenticación fuerte”.

La conclusión práctica: aunque un proyecto dado esté gobernado por eIDAS o una regulación local en lugar de NIST directamente, el modelo mental IAL/AAL/FAL igual funciona como lingua franca para razonar sobre el aseguramiento — que es justo por lo que vale aprenderlo como un estándar, no solo como un artefacto de NIST.

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

Las guías son documentos vivos, y la Revisión 4 (finalizada en 2025) señala hacia dónde se mueve el pensamiento de aseguramiento — vale conocerlo para no anclarte a la versión vieja:

• La resistencia a phishing pasa al centro. La guía más nueva se apoya más en autenticación resistente a phishing, reflejando que el phishing de credenciales y el bypass de MFA son ahora el ataque dominante, no solo las contraseñas débiles.
• Se abrazan los autenticadores sincronizables (passkeys). Las revisiones anteriores convivían incómodamente con las credenciales sincronizadas en la nube; la Rev 4 da guía más clara de dónde encajan las passkeys sincronizadas, reconociendo la realidad de FIDO2.
• El fraude, la equidad y la usabilidad ganan peso real. El estándar reconoce cada vez más que una prueba demasiado onerosa excluye a personas legítimas, y que se debe diseñar contra el fraude de identidad — el aseguramiento no trata solo de mantener fuera a los atacantes sino de dejar entrar a las personas correctas.
• Un empujón hacia el aseguramiento continuo y adaptativo al riesgo. El modelo de punto-en-el-tiempo se está suavizando hacia la evaluación continua — la misma dirección a la que corre la frontera.

No necesitas memorizar números de revisión, pero deberías conocer la trayectoria: hacia la resistencia a phishing, hacia las passkeys, y lejos de “el aseguramiento es un sello de una sola vez”.

El puente hacia la frontera

Una conexión más apunta hacia adelante. El modelo de NIST es, clásicamente, aseguramiento establecido en un punto en el tiempo — pruebas una vez (IAL), te autenticas en el login (AAL), la assertion se transmite (FAL), y se otorga el acceso. La frontera a la que pasamos a continuación empuja justo sobre ese “punto en el tiempo”: la evaluación continua de acceso, los tokens atados al emisor y la identidad de carga de trabajo de vida corta preguntan “¿este aseguramiento sigue siendo válido ahora mismo?” en lugar de confiar en un nivel fijado hace minutos u horas. El propio NIST evoluciona hacia un pensamiento continuo y adaptativo al riesgo. Así que lee los niveles de aseguramiento como el suelo firme sobre el que la frontera construye: primero aprende a medir el aseguramiento en un momento, luego observa al campo aprender a re-medirlo continuamente.

Recapitulación

NIST SP 800-63 es el vocabulario para especificar qué tan fuerte debe ser la identidad:

1. Tres diales independientes, cada uno de 1 a 3 — los ajustas por separado al riesgo de un caso de uso, nunca como un único “nivel” combinado.
2. IAL (prueba): qué tan seguro estás de quién es la persona — 1 autodeclarado, 2 evidencia verificada, 3 presencial con evidencia fuerte. Una pregunta de una sola vez, de enrolamiento.
3. AAL (autenticación): qué tan fuerte lo prueba en cada login — 1 factor único, 2 MFA, 3 hardware resistente a phishing (FIDO2). El hogar de los factores y el MFA.
4. FAL (federación): qué tan seguro viaja la assertion — 1 bearer, 2 cifrada, 3 holder-of-key. FAL3 es la misma idea de prueba de posesión que DPoP.
5. Combina por riesgo: banca ≈ IAL2/AAL2, un foro ≈ IAL1/AAL1, acceso de alto valor → IAL3/AAL3 — fuerte donde importa, ligero donde no, y el dial correcto para el riesgo correcto, incluso un IAL1-con-AAL-alto deliberado cuando quieres un login fuerte pero ningún conocimiento de quién es el usuario.
6. El aseguramiento decae y la autorización lo consume: un AAL más alto significa ventanas de reautenticación más cortas, y las acciones sensibles pueden requerir un nivel mínimo (step-up) — el aseguramiento es la unidad que pide la autorización.
7. Es el puente: los protocolos son el cómo, los niveles de aseguramiento son el cuánto, el modelo viaja (eIDAS, ISO 29115), y la frontera es donde el “cuánto” se vuelve continuo. Aprende a medir el aseguramiento en un momento aquí, luego observa al campo aprender a re-medirlo continuamente después.

Ejercicios prácticos

Estos son prácticos — hazlos, no solo los leas:

1. Califica un servicio que uses (caso de uso). Elige una app a la que inicies sesión y estima su IAL, AAL y FAL. ¿Qué evidencia recolectó al registrarte (IAL)? ¿Qué requiere en el login (AAL)? Si “inicias sesión con” un proveedor, ¿cómo se protege esa assertion (FAL)?
2. Elige el dial (caso de uso). Para cada problema, nombra si es un asunto de IAL, AAL o FAL y el arreglo: cuentas falsas inundando el registro; credenciales phisheadas y reusadas; una assertion federada interceptada y reusada en otro relying party.
3. Diseña una postura (caso de uso). Especifica IAL/AAL/FAL para: un juego infantil; una app de trading de acciones; una consola interna de admin para infraestructura de producción. Justifica cada dial contra su riesgo.
4. Defiende la independencia (caso de uso). Un stakeholder dice “solo pon todo en nivel 3”. Da el argumento de dos frases de por qué poner todos los diales al máximo suele ser la decisión equivocada.
5. Mapea a un protocolo (caso de uso). Tu diseño pide AAL3 y FAL3. Nombra un autenticador concreto que cumpla AAL3 y un mecanismo de assertion concreto que cumpla FAL3, y conecta cada uno de vuelta a un protocolo de antes en el módulo.
6. Traduce la regulación (caso de uso). Una regla dice que un servicio que maneja expedientes de salud debe cumplir “IAL2/AAL2 con reautenticación”. Lista los pasos concretos de prueba (IAL2), el requisito de login (AAL2), y aproximadamente cada cuánto debe reautenticarse el usuario — luego mapea cada requisito a algo que los artículos anteriores describieron.

Tres preguntas para autoevaluarte

1. Explica por qué IAL y AAL son independientes, con un ejemplo de una cuenta de IAL-alto/AAL-bajo y una de IAL-bajo/AAL-alto.
2. ¿De qué protege FAL3 (holder-of-key) que FAL1 (bearer) no, y qué tecnología de la frontera encarna la misma idea?
3. Un regulador requiere “IAL2 y AAL2” para una aplicación. Tradúcelo en requisitos concretos e implementables para la prueba de identidad y para el login.