Muchas organizaciones tratan MFA como una casilla de cumplimiento. En auditorías, ese enfoque se rompe rápido. Los auditores y los equipos de riesgo no solo quieren oír “MFA está habilitado”. Quieren saber:

• ¿Qué métodos se usan para accesos de alto riesgo?
• Si son resistentes al phishing cuando se requiere.
• ¿Cómo se gobiernan las excepciones?
• ¿Cómo se controla la recuperación?
• ¿Qué evidencias existen para demostrar todo lo anterior?

Este artículo explica los requisitos prácticos de evidencia para programas de MFA en empresas, cómo diseñar para auditabilidad y dónde los equipos aumentan el riesgo sin querer mediante recuperación débil y controles inconsistentes.

Relacionado: Autenticación passwordless en entornos regulados: auditabilidad, evidencias y control

Qué preguntan realmente los auditores sobre MFA

La pregunta superficial suele ser simple: “¿Exigís MFA?” Las preguntas de fondo no lo son.

Las auditorías suelen profundizar en:

• Cobertura: qué sistemas y tipos de usuario están protegidos.
• Nivel de garantía: qué factores se permiten y cuáles se restringen.
• Consistencia: si los controles están centralizados o fragmentados entre apps.
• Excepciones: quién puede saltarse MFA, en qué condiciones y durante cuánto tiempo.
• Recuperación: cómo se restaura el acceso y cómo se evita el abuso.
• Evidencias: logs que permitan reconstruir decisiones y resultados.

Si no puedes responder a eso, “MFA habilitado” tiene poco peso.

El problema de la evidencia: MFA no es un toggle, es un programa

Un programa empresarial de MFA genera evidencias en varias capas:

• Capa de identidad (usuario, rol, pertenencia a grupos).
• Capa de autenticador (tipo de método, estado de registro).
• Capa de política (acceso condicional, disparadores de autenticación reforzada).
• Capa de sesión (inicio, fin, timeout, revocación).
• Capa de recuperación (re-registro, overrides, acciones del helpdesk).

Las auditorías se complican cuando estas capas están repartidas entre aplicaciones con configuraciones inconsistentes.

Relacionado: Passwordless con SSO e IdP: patrones de despliegue para entornos empresariales

Qué registrar: el mínimo defendible de trazas de auditoría para MFA

Un conjunto práctico de “evidencia mínima viable” incluye:

1) Evidencia del autenticador

• Tipos de factor permitidos y usados (TOTP, push, FIDO2, passkeys, smartcards).
• Eventos de registro y re-registro.
• Cambios de factores (añadir/eliminar) y quién los aprobó.

2) Evidencia de política y autenticación reforzada

• Reglas de acceso condicional aplicadas en el inicio de sesión.
• Disparadores de autenticación reforzada (por qué se exigió prueba más fuerte).
• Resultados de comprobaciones de riesgo y clasificación de postura del dispositivo (cuando se use).

3) Evidencia de sesión

• Timestamps de inicio/fin de sesión.
• Caducidad de sesión y comportamiento de timeout.
• Marcadores de sesión privilegiada (si aplica).
• Revocaciones de emergencia durante incidentes.

4) Evidencia de excepciones

• ¿Qué excepciones existen, por qué y quién es responsable?
• Fechas de caducidad y plan de retirada.
• Controles compensatorios aplicados (restricciones de red, alcance limitado).

5) Evidencia de recuperación

• Solicitudes de recuperación y resultados concedidos.
• Evidencia usada para verificación (autoservicio vs asistida).
• Aprobaciones e identidad del agente (si es helpdesk).
• Eventos de rate limiting y patrones sospechosos.

Si tus logs no pueden reconstruir esto, las auditorías pasan a ser “narrativas” en lugar de basadas en evidencias.

Relacionado: Verificación de identidad en flujos de recuperación explicada: evidencias, niveles de riesgo y auditabilidad

Dónde falla el cumplimiento en la práctica: modos de fallo comunes en auditorías de MFA

Estos patrones suelen generar problemas en auditoría:

Debilidad 1: “MFA en todas partes”, pero factores débiles para accesos de alto riesgo

Una auditoría puede aceptar cobertura de MFA y, aun así, señalar riesgo si:

• El acceso privilegiado depende de OTP o aprobaciones push.
• Los métodos resistentes al phishing son opcionales en lugar de estar exigidos.
• Existe retroceso generalizado a SMS.

Debilidad 2: Excepciones que nunca caducan

Las excepciones son normales en la realidad empresarial. Las excepciones permanentes son un fallo de gobernanza. Los auditores suelen fijarse en:

• Si las excepciones tienen responsable.
• Si tienen fecha de caducidad.
• Si disminuyen con el tiempo.

Debilidad 3: Recuperación que debilita el control

Si MFA es fuerte, pero la recuperación usa enlaces de restablecimiento, defaults por email/SMS u overrides del helpdesk sin verificación consistente, el control se puede burlar. En términos de riesgo, la recuperación se convierte en la superficie de control efectiva.

Relacionado: Por qué los programas de passwordless y MFA fallan en la recuperación (la superficie de control que falta)

Debilidad 4: Políticas fragmentadas entre apps y el IdP

Si la configuración de MFA a nivel de aplicación entra en conflicto con la política del IdP, la evidencia se vuelve inconsistente. Esto es una causa frecuente de confusión en auditoría y de riesgo por mala configuración.

Responsabilidad ante brechas: qué cambia cuando MFA no es defendible

Esto no es asesoramiento legal, sino una observación práctica de riesgo: cuando ocurre un incidente, a las organizaciones se las suele evaluar por si los controles fueron razonables, aplicados y evidenciados.

En una investigación de brecha, las preguntas suelen pasar de “¿teníais MFA?” a:

• Si MFA estaba aplicado para el sistema y tipo de cuenta afectados.
• Si se permitían factores débiles como retroceso.
• Si había excepciones conocidas.
• Si recuperación o acciones de helpdesk habilitaron el compromiso.
• Si puedes mostrar trazas de auditoría que prueben decisiones de política.

La evidencia fuerte no evita incidentes. Reduce ambigüedad, mejora la respuesta y ayuda a demostrar control.

Checklist práctico de auditoría para programas de MFA

Usa este checklist para prepararte para auditorías y reducir el riesgo de incidentes:

1. ¿MFA está aplicado para accesos de Nivel 0 y Nivel 1?
2. ¿Se exigen métodos resistentes al phishing para cuentas de alto riesgo?
3. ¿Los logs capturan tipo de autenticador y disparadores de autenticación reforzada?
4. ¿Las excepciones tienen responsable, caducidad y métricas?
5. ¿Los flujos de recuperación están basados en evidencias y monitorizados para abuso?
6. ¿Las acciones del helpdesk son estrechas, aprobadas y plenamente auditables?
7. ¿Puedes reconstruir una decisión de inicio de sesión de extremo a extremo a partir de logs?

Si puedes responder afirmativamente, tu programa de MFA tiene muchas más probabilidades de resistir el escrutinio.

Conclusión: El cumplimiento es evidencia, no declaraciones

El cumplimiento de MFA no se logra “activando una opción”. Se logra aplicando los métodos adecuados para los accesos adecuados, gobernando excepciones, controlando recuperación y produciendo evidencias que aguanten auditorías y respuesta a incidentes.