La contraseña por sí sola ya no es un límite seguro. Las credenciales se roban por phishing, se reutilizan en distintos servicios, se venden en listas de filtraciones y se prueban automáticamente en pantallas de inicio de sesión expuestas. Por eso el segundo factor se ha convertido en un requisito fundamental de la arquitectura de seguridad moderna.
Sin embargo, añadir MFA no debería significar poner un servicio de validación separado delante de cada aplicación o trasladar por completo el momento más crítico de la autenticación a una nube de terceros. El coste de licencia continuo por usuario, la dependencia de un servicio externo, los distintos paneles de gestión y la estructura de política fragmentada, con el tiempo, complican la seguridad en lugar de simplificarla.
El problema mayor es el enfoque de MFA uniforme. No todas las aplicaciones cargan con el mismo riesgo, no todos los usuarios acceden desde el mismo contexto, no todas las sesiones empiezan con el mismo nivel de confianza. Para un wiki corporativo, TOTP puede ser suficiente; el acceso a los servidores de producción y al domain controller debe pedir TOTP en cada inicio de sesión y no debe permitir el atajo de dispositivo de confianza. Una aplicación de intranet de bajo riesgo, por su parte, no debería ralentizar al usuario con pantallas de código innecesarias en cada inicio de sesión.
La función del MFA no es poner obstáculos continuos al usuario, sino elevar el nivel de confianza cuando el riesgo aumenta. Para ello, las decisiones de validación deben tomarse según la aplicación, el grupo de usuarios, el estado del dispositivo, la ubicación, el riesgo de la sesión y la sensibilidad del recurso accedido.
El MFA no debe ser una dependencia de nube separada; debe ser una parte local, escalonada y auditable de la propia política de acceso de la organización.
Tres tipos de factor bajo un único motor de política — todos operan en la plataforma que ya posee.
TOTP, SMS y correo electrónico OTP funcionan todos con el mismo modelo de configuración de MFA. Los administradores determinan desde un único lugar qué métodos estarán disponibles en general, cuáles son obligatorios para un servicio y cuáles puede elegir el usuario — sin entrar en consolas de proveedor separadas y sin pagar una tarifa de MFA por usuario.
Cada servicio o grupo de servicios declara su propio requisito de MFA: sin MFA, cualquier factor, un método concreto o una combinación de factores encadenados. Las aplicaciones de intranet de bajo riesgo permanecen sin fricción; las interfaces de administración de alto riesgo imponen requisitos más fuertes; las intermedias no tienen que sobreprotegerse para estar seguras.
Cuando la política lo permite, el usuario puede marcar su dispositivo como de confianza en el momento del MFA y omitir el segundo factor durante un periodo configurable — 30 días por defecto. La confianza está ligada al dispositivo, no a la red; y puede revocarse tanto desde la consola del administrador como desde la propia página de perfil del usuario.
La evaluación continua de confianza monitoriza cada sesión activa. Si la IP del operador cambia de país, si la puntuación de confianza del endpoint baja o si el comportamiento se vuelve anómalo, el gateway puede imponer un nuevo challenge de MFA sin reiniciar al usuario desde la página de inicio de sesión.
Tres canales de entrega de factores, más la política y las herramientas de recuperación a su alrededor.
Contraseñas de un solo uso basadas en tiempo estándar, compatibles con Google Authenticator, Microsoft Authenticator, Authy, 1Password, Bitwarden, Yubico Authenticator, FreeOTP y cualquier otra aplicación RFC 6238. El registro funciona mediante un código QR renderizado en el lado del servidor; la clave secreta compartida se almacena cifrada, no se registra en logs y nunca se muestra en la consola del administrador. El algoritmo, el número de dígitos y la ventana de validez se configuran por perfil.
Códigos OTP entregados por SMS a través del proveedor de SMS con capacidad HTTP que ya usa — Twilio, Vonage, Infobip, MessageBird, la API de un operador local o su propio gateway interno. La plataforma compone el mensaje, llama al endpoint HTTP configurado y hace seguimiento de la entrega; no se interpone ningún revendedor de SMS entre sus usuarios y los códigos que necesitan.
Códigos OTP entregados a la dirección de correo electrónico verificada del usuario. La página de inicio de sesión muestra la dirección solo en forma enmascarada (por ejemplo, y***@example.com); así, un atacante que haya robado la contraseña no puede averiguar el correo de destino. Útil como canal de recuperación y para flujos de validación de bajo riesgo.
En el momento del registro se entregan a los usuarios de TOTP códigos de respaldo de un solo uso — se almacenan cifrados, se muestran una vez y se consumen cuando el usuario pierde el acceso a su teléfono. Cada código consumido se marca como 'usado' y no vuelve a aceptarse; los códigos restantes pueden regenerarse por el usuario o el administrador.
Los administradores mapean los requisitos de MFA por servicio, grupo de servicios o resultado (outcome). Un servicio concreto puede exigir cualquier factor, un factor concreto o una cadena — por ejemplo, TOTP en el inicio de sesión más una validación SMS fresca para las operaciones de transferencia de dinero. La matriz está versionada, es auditable, y un cambio en un único lugar se propaga a todos los sitios donde se aplica.
Cuando un único factor no es suficiente, los servicios pueden exigir dos o más factores en un orden definido — por ejemplo, TOTP al inicio de la sesión más un código de correo electrónico o SMS fresco cuando se invoca una operación sensible. La cadena está orientada por política y es configurable; los usuarios ven el paso adicional solo cuando el riesgo lo requiere.
Un usuario que ya ha completado TOTP para una sesión rutinaria puede recibir un nuevo challenge dentro de la sesión cuando alcanza un recurso más sensible. La elevación está orientada por política, no es un nuevo inicio de sesión; la sesión continúa y el usuario solo completa el challenge adicional sin perder el contexto, las ventanas abiertas ni el trabajo en curso.
Los usuarios registran TOTP, regeneran códigos de respaldo, gestionan dispositivos de confianza y verifican sus correos electrónicos o números de teléfono — sin abrir un ticket de soporte, a través de una única página de perfil. Los administradores conservan la autoridad para forzar el reregistro cuando se requiere autenticación, revocar dispositivos de confianza o reiniciar factores.
La infraestructura que convierte el MFA de una casilla de verificación en una capa de autenticación defendible.
Las claves secretas TOTP, los códigos de respaldo y los tokens de dispositivo de confianza se almacenan cifrados con claves gestionadas por la plataforma; se mantienen separados de los datos de sesión y de política. Los operadores administradores ven los metadatos (estado de registro, último uso, número de dispositivos de confianza) pero nunca la propia clave secreta.
Cada canal OTP mantiene su propio contador de intentos — entradas TOTP erróneas, entradas de código SMS erróneas, entradas de código de correo electrónico erróneas — y cuando se superan los umbrales configurables, el canal se bloquea. El bloqueo se coordina con la capa más amplia de login-attack-protection de la plataforma; así, un único usuario no puede probar un segundo factor mientras hace fuerza bruta sobre el primero al mismo tiempo.
Las direcciones de correo electrónico, los números de teléfono y los nombres de authenticator se muestran siempre en forma enmascarada al usuario final en la UI de validación. Un atacante que conoce la contraseña pero no posee el segundo factor no puede leer el destino ni redirigirlo — y alguien que mira por encima del hombro de otra persona tampoco puede recopilar los detalles de registro.
La longitud del código (6, 8 o más), los separadores de agrupación (123-456 o 123456), la ventana de validez en segundos y el tiempo de espera para reenvío se configuran por perfil de MFA. Los flujos sujetos a cumplimiento pueden exigir códigos más largos y ventanas más cortas; los flujos rutinarios permanecen amigables con códigos estándar de 6 dígitos y 60 segundos.
Los usuarios pueden solicitar el reenvío cuando el código original no llega — sujeto a un tiempo de espera configurable que impide usar el mecanismo de reenvío como herramienta de bombardeo SMS. Los límites de tasa se rastrean junto con los contadores de intentos por canal y aparecen en los logs de auditoría.
Cada intento de MFA — exitoso, fallido, reenviado, bloqueado — se registra con marca de tiempo, IP de origen, user agent, canal y la decisión que tomó el motor de política. El flujo de auditoría se alimenta al destino de streaming SIEM de la plataforma; así, los equipos de seguridad pueden correlacionar las anomalías de MFA con el resto de la telemetría.
Domain controllers, bases de datos de producción, la propia consola de administración de la plataforma — estos imponen la cadena más fuerte disponible. Un patrón común es TOTP al inicio de la sesión más una validación SMS fresca cuando se invoca una operación destructiva; para los sistemas de mayor impacto no se habilita el atajo de dispositivo de confianza.
Los sistemas de transferencia de dinero y conciliación pueden exigir MFA encadenado — TOTP en el inicio de sesión más un OTP fresco en el momento de la operación — para que un único factor robado no pueda generar movimiento de dinero. La política de step-up mantiene la fricción en el límite de la operación, no en cada carga de página.
Los usuarios sin un escritorio fijo o un portátil de confianza se autentican con SMS OTP a través del gateway de SMS de la organización, y con correo electrónico OTP cuando la fiabilidad del SMS es débil. El enmascaramiento del destinatario y el bloqueo por canal mantienen el flujo seguro incluso cuando el mismo teléfono sirve a un turno.
Los auditores buscan MFA en cada ruta de acceso privilegiado a los sistemas dentro del alcance. El requisito de política por servicio lo expresa con claridad para el auditor — sin levantar el mismo muro delante de los servicios internos de bajo riesgo.
Tres métodos, un único motor de política, sin nube de MFA de terceros — configurado por servicio y por riesgo. Le guiaremos por una instalación en vivo sobre sus propias aplicaciones.