Elegir el modelo de MFA adecuado: marco de decisión por nivel de riesgo y restricciones
La mayoría de decisiones de MFA fallan por un motivo: los equipos eligen un método antes de definir el entorno.
Las empresas tienen múltiples tipos de usuario, realidades de dispositivo y niveles de riesgo. Un método que funciona bien para personal de oficina con portátiles gestionados puede fallar por completo para equipos de primera línea en terminales compartidos, contratistas en dispositivos no gestionados o flujos regulados que requieren evidencias de auditoría defendibles.
Este artículo te da un marco práctico para elegir el modelo de MFA por nivel de riesgo y restricciones, sin caer en “un método para todo el mundo” ni crear dispersión de excepciones.
Paso 1: Define tus niveles de riesgo (Nivel 0, Nivel 1, Nivel 2)
Empieza con un modelo simple por niveles:
- Nivel 0: Admins del IdP, herramientas de seguridad, infraestructura cloud, acceso a producción
- Nivel 1: Finanzas, RRHH, datos de clientes, sistemas clave de negocio
- Nivel 2: Apps generales de la plantilla y herramientas de menor riesgo
Esto importa porque la fuerza de MFA, los requisitos de recuperación y las expectativas de evidencia deben aumentar con el nivel. Si todos los niveles comparten el mismo flujo de recuperación o las mismas opciones de retroceso, el camino más débil se convierte en tu bypass de Nivel 0.
Relacionado: MFA para acceso privilegiado: riesgos, limitaciones y diseño de autenticación reforzada para administradores
Paso 2: Mapea restricciones antes de seleccionar métodos
Ahora identifica las restricciones que romperán suposiciones comunes de MFA:
Entornos compartidos y de primera línea
Si los usuarios rotan por terminales compartidos, prioriza higiene de sesión y cambio rápido de usuario.
Sin teléfonos personales
Si los teléfonos están restringidos, los métodos que dependen de smartphones personales colapsarán hacia excepciones.
Flotas no gestionadas o mixtas
Si contratistas y BYOD son habituales, necesitas señales de política (postura) y autenticación reforzada más fuerte para acciones de mayor riesgo.
Entornos regulados
Si la auditabilidad importa, debes planificar evidencias, logging y aplicación consistente.
Las restricciones determinan viabilidad. La viabilidad determina si tu programa se vuelve resiliente o se convierte en excepciones.
Paso 3: decide qué significa “resistente al phishing” por niveles
La resistencia al phishing es una propiedad que debes aplicar, no una etiqueta en la que esperas confiar.
Regla práctica:
- Nivel 0 y acciones de alto impacto deberían exigir MFA resistente al phishing por política.
- Los niveles inferiores pueden usar métodos transitorios, pero los retrocesos deben estar gobernados y acotados en el tiempo.
Paso 4: elige modelos de MFA por nivel (mapeo práctico)
Esto no es una receta universal. Es una plantilla de decisión.
Nivel 0 (privilegiadas/admin)
Objetivo: Minimizar riesgo de bypass y radio de impacto.
- Exigir métodos resistentes al phishing por defecto.
- Exigir autenticación reforzada para acciones sensibles.
- Mantener sesiones cortas y auditables.
- Usar verificación estricta en recuperación y resultados estrechos.
Evita:
- Aprobaciones push como control principal.
- OTP como retroceso en recuperación privilegiada.
- Capacidad amplia de override del helpdesk.
Nivel 1 (acceso sensible de negocio)
Objetivo: Reducir éxito de phishing manteniendo fluidez operativa.
- Preferir métodos resistentes al phishing cuando sea viable.
- Usar acceso condicional y autenticación reforzada basada en riesgo.
- Estandarizar métodos en sistemas core.
- Gobernar excepciones y medir su retirada.
Evita:
- Configuraciones de MFA inconsistentes a nivel de aplicación.
- Excepciones permanentes por sistemas heredados.
- Recuperación por canales débiles en apps sensibles.
Nivel 2 (plantilla general)
Objetivo: cobertura y adopción con un camino claro de migración.
- Permitir métodos transitorios con guardarraíles.
- Reducir prompts innecesarios con acceso condicional.
- Endurecer comportamientos de alto riesgo con autenticación reforzada.
- Monitorizar el uso de retrocesos y bloqueos.
Evita:
- “Todo el mundo puede usar SMS cuando sea incómodo”.
- Registro fragmentado entre aplicaciones.
Paso 5: Diseña autenticación reforzada y sesiones como parte de la elección de MFA
MFA no es solo una barrera de login. Es un sistema de políticas.
Patrones recomendados:
- Autenticación reforzada para acciones de alto impacto.
- Autenticación reforzada para sesiones anómalas.
- Sesiones cortas para acceso privilegiado.
- Flujos claros de cierre de sesión en terminales compartidos.
Esto reduce fatiga y también el impacto de una brecha.
Paso 6: Evalúa la recuperación antes de cerrar el modelo de MFA
Si eliges MFA sin diseñar recuperación, estás eligiendo tu camino más débil a ciegas.
Una decisión de MFA resiliente incluye:
- Reglas de evidencia de verificación por nivel.
- Reregistro como operación rutinaria.
- Límites de tasa y monitorización de abuso de recuperación.
- Resultados estrechos del helpdesk con trazas de auditoría.
- Caminos seguros para entornos con restricciones (primera línea/sin teléfono).
Si tu recuperación depende de enlaces de restablecimiento, SMS o acciones improvisadas del helpdesk, el método de MFA más fuerte no importará.
Paso 7: Haz la decisión medible (evita dispersión de excepciones)
Un marco de decisión solo sirve si se puede gobernar. Define las métricas que vas a seguir:
- Cobertura por nivel (qué porcentaje está protegido por qué método).
- Cobertura resistente al phishing para Nivel 0 y Nivel 1.
- Tasa de uso de retrocesos y su tendencia.
- Número de excepciones y tiempo hasta retirarlas.
- Eventos de recuperación e intentos de abuso.
- Volumen de bloqueos y tiempo para recuperar acceso.
Cuando las métricas se desvían, puedes corregir el programa antes de que las excepciones se vuelvan permanentes.
Conclusión: Elige MFA como programa de ciclo de vida, no como factor
El modelo de MFA adecuado es el que encaja con tus restricciones, reduce el éxito del phishing y se mantiene resiliente frente a la recuperación y la realidad operativa.
Empieza por niveles, mapea restricciones, aplica resistencia al phishing donde importa y diseña la recuperación como la superficie de control que hace el programa duradero.