MFA on-premise: guía completa de autenticación multifactor self-hosted (2026)
La autenticación en la nube es el camino de menor resistencia para la mayoría de las organizaciones. Se implementa más rápido, no hay infraestructura que mantener, y cuando algo falla a las 2 de la madrugada, es problema de otro. Para buena parte de las empresas, esa concesión resulta perfectamente aceptable.
Para el resto —las que operan bajo GDPR, DORA, NIS2, PCI DSS o HIPAA, las que gestionan redes air-gapped en defensa o infraestructuras críticas, aquellas cuyos auditores de cumplimiento hacen preguntas incómodas sobre dónde residen realmente los datos de autenticación—, el cálculo cambia. Cuando los usuarios se autentican en sistemas que contienen datos de titulares de tarjetas o información sanitaria protegida electrónica, los datos de autenticación suelen quedar sujetos a requisitos estrictos de cumplimiento y residencia de datos. En una implementación de MFA en la nube, esos datos salen de su red. En una implementación on-premise, no.
Esta guía explica cómo funciona la arquitectura de MFA on-premise, por qué sigue siendo necesaria en 2026 para las organizaciones con restricciones estrictas de cumplimiento o aislamiento de red, y cómo se compara con las alternativas en la nube y en nube privada. Para conocer las especificidades del producto Protectimus —precios, especificaciones de implementación, tokens compatibles y demo—, consulte la página Protectimus On-Premise MFA Platform.
Índice
- Por qué la MFA on-premise importa en 2026
- MFA on-premise frente a MFA en la nube frente a nube privada
- Cómo funciona la MFA on-premise de Protectimus
- Funciones empresariales: clustering, HA, AD multidominio
- Métodos de MFA compatibles
- Qué servicios se pueden proteger
- Requisitos de implementación
- Casos de uso por sector y cumplimiento
- Preguntas frecuentes
- Conclusión
Respuesta rápida
La MFA on-premise es una arquitectura de autenticación self-hosted en la que el motor de validación de OTP, la base de datos de usuarios, las semillas de los tokens y los registros de auditoría se ejecutan enteramente dentro de su propia infraestructura: servidores físicos, entornos virtualizados o nube privada. Ninguna solicitud de autenticación sale de su red.
Esta guía explica por qué los sectores regulados siguen eligiendo este modelo en 2026, cómo funciona la arquitectura, qué protege y cómo se compara con las alternativas basadas en la nube.
Para conocer las especificidades del producto Protectimus —precios, tokens compatibles, especificaciones de implementación y demo—, consulte
Protectimus On-Premise MFA Platform →
Datos clave
99,9% de los ataques bloqueados con MFA
Microsoft informa que la MFA bloquea más del 99,9% de los ataques de compromiso de cuentas, el control individual de mayor impacto contra las intrusiones basadas en credenciales. (Microsoft Digital Defense Report)
$4,4 millones de coste medio por brecha en 2025
El coste medio global de una brecha de datos alcanzó los $4,44 millones en 2025, mientras que en las organizaciones de EE. UU. tocó un máximo histórico de $10,22 millones (IBM Cost of a Data Breach Report 2025)
22% de las brechas por abuso de credenciales
El abuso de credenciales fue el vector de acceso inicial en el 22% de las brechas; el 88% de los ataques de tipo Basic Web Application implicaron credenciales robadas. (Verizon 2026 Data Breach Investigations Report)
Ventajas clave
La autenticación permanece on-premise
Toda la validación de OTP, las semillas de los tokens y los registros de auditoría se ejecutan dentro de su propia red. Sin dependencia externa para procesar la autenticación.
Clustering de alta disponibilidad
Las implementaciones en producción usan una arquitectura multinodo en clúster (normalmente 3 o más nodos) con balanceo de carga y replicación de base de datos.
Active Directory multidominio
Soporte nativo para entornos de Active Directory multidominio, con gestión centralizada de la autenticación desde una única instancia de la plataforma.
Amplia cobertura de servicios
Protege AD, puertas de enlace VPN, aplicaciones federadas mediante ADFS, el inicio de sesión de Windows y RDP, OWA, y aplicaciones web personalizadas.
Cobertura de cumplimiento
Ayuda a cumplir PCI DSS v4.0, HIPAA, NIST SP 800-63B, SOC 2, ISO 27001, GDPR, DORA y NIS2.
Capacidad air-gapped
Funciona sin conectividad a internet tras la implementación, la única arquitectura viable para entornos clasificados y de sistemas de control industrial (ICS).
Por qué la MFA on-premise importa en 2026
La respuesta honesta es que la mayoría de las organizaciones no la eligen por voluntad propia: son las restricciones las que las empujan hacia ella al hacer inviable la MFA en la nube.
GDPR trata los datos de los eventos de autenticación —nombres de usuario, marcas de tiempo, direcciones IP, resultados de validación— como datos personales. Enrutarlos a través de un proveedor de autenticación en la nube crea una relación de tratamiento de datos que exige un DPA, una evaluación de seguridad y, potencialmente, una evaluación de impacto de la transferencia. DORA clasifica los servicios de autenticación como servicios TIC, lo que somete a los proveedores de MFA en la nube a sus requisitos de gestión de riesgos de terceros. El artículo 21 de. NIS2 incluye las dependencias de la infraestructura de autenticación en el alcance de la evaluación de riesgos de la cadena de suministro.
Para las entidades financieras, los proveedores sanitarios y los operadores de infraestructuras críticas, mantener la autenticación dentro de la propia organización suele simplificar las revisiones de cumplimiento y reducir la exposición al riesgo de terceros.
Las redes air-gapped son la restricción más difícil de sortear. Los sistemas gubernamentales clasificados, los entornos de contratistas de defensa sujetos a ITAR o CMMC, las redes de sistemas de control industrial y determinadas infraestructuras de trading financiero normalmente no pueden enrutar las solicitudes de autenticación a APIs externas. On-premise es la única arquitectura que funciona en estos casos.
MFA on-premise frente a MFA en la nube frente a nube privada
Factor | On-Premise | MFA en la nube | Nube privada |
Ubicación de los datos de autenticación | Sus servidores | Infraestructura del proveedor | Su tenant en la nube |
Soporte air-gapped | Sí | No | Depende |
Requiere conectividad externa | No | Sí | Sí (proveedor cloud) |
Latencia | LAN, predecible | Depende de internet | Depende de internet |
HA / clustering | Autogestionado (se recomiendan 3 nodos) | Gestionado por el proveedor | Autogestionado |
Alcance de auditoría de terceros | Ninguno | Evaluación completa del proveedor | El proveedor cloud entra en el alcance |
Tiempo de implementación | Días | Horas | De horas a días |
La nube privada combina muchas de las ventajas de la MFA on-premise con la flexibilidad operativa de la infraestructura en la nube. Los datos de autenticación permanecen dentro del entorno de nube dedicado de la organización en lugar de en una plataforma SaaS compartida, mientras que el proveedor de nube subyacente sigue formando parte del alcance de la evaluación de cumplimiento y riesgos. Para las organizaciones que ya ejecutan cargas de trabajo reguladas en AWS o Azure con la cobertura contractual adecuada, ofrece un equilibrio entre control y flexibilidad operativa.
Cómo funciona la MFA on-premise de Protectimus
La plataforma tiene tres capas funcionales:
Motor de autenticación.El motor de validación de OTP implementa los estándares OATH TOTP, HOTP y OCRA. Las solicitudes de autenticación llegan vía RADIUS, DSPA o API. El motor valida el OTP contra la semilla del token almacenada localmente y devuelve un resultado de aprobado o rechazado. El material de la semilla nunca sale de su infraestructura, ni en el momento del aprovisionamiento ni en el de la validación.
Capa de integración.Protocolos, plugins y componentes de integración que conectan los sistemas protegidos con el motor de autenticación:
- RADIUS— puertas de enlace VPN, controladores de acceso de red, Wi-Fi y otros sistemas basados en RADIUS
- DSPA—autenticación basada en OTP para Active Directory, directorios LDAP y servicios conectados
- ADFS plugin— acceso federado a Microsoft 365, SharePoint, Salesforce y otras aplicaciones conectadas a través de ADFS
- Windows Credential Provider— protección del inicio de sesión de Windows y RDP, incluido el soporte de autenticación sin conexión
- Plugins de aplicaciones web e integraciones API: Outlook Web App,Roundcube, aplicaciones web personalizadas y servicios integrados mediante API REST o SDK
Capa de gestión y auditoría. La integración con Active Directory, directorios LDAP y otras fuentes de datos de usuarios mantiene sincronizadas las cuentas de forma automática. Los registros de eventos de autenticación —cada intento, marca de tiempo, resultado— permanecen locales. El portal de autoservicio gestiona el registro de tokens, la sincronización y la sustitución de dispositivos sin intervención del administrador.
Funciones empresariales: clustering, alta disponibilidad, AD multidominio
Las implementaciones de MFA on-premise en producción suelen usar una arquitectura multinodo en clúster con balanceo de carga y replicación de base de datos, de modo que la autenticación siga funcionando si un nodo falla. La configuración mínima viable de alta disponibilidad son tres nodos (para el quórum), con un balanceador de carga por delante y replicación de base de datos maestro-esclavo por detrás.
El soporte de Active Directory multidominio permite la integración con entornos empresariales complejos que contienen múltiples dominios o estructuras de directorio. La sincronización LDAP puede configurarse en directorios independientes manteniendo a la vez una gestión centralizada de la autenticación desde una única instancia de la plataforma.
La Protectimus On-Premise MFA Platform admite implementaciones en clúster con múltiples nodos de plataforma, balanceo de carga con HAProxy y bases de datos PostgreSQL replicadas. Consulte la arquitectura de implementación completa, los requisitos del sistema y el cronograma de despliegue enProtectimus On-Premise MFA Platform →
Métodos de MFA compatibles
Método | Resistencia al phishing | Sin conexión | Recuperación autónoma |
Alta | Sí | Sí (copia en la nube) | |
Alta | Sí | No (lo sustituye el administrador) | |
Media | No | N/A | |
Baja-media | No | N/A | |
Baja-media | No | N/A | |
Media | No | Sí (copia en la nube) |
Para los entornos donde no se permiten dispositivos móviles —plantas de fabricación, instalaciones seguras, redes clasificadas—, los tokens hardware OATH TOTP suelen ser el segundo factor preferido. Al estandarizarse en OATH, los tokens son portables entre proveedores: un token OATH TOTP de un proveedor funciona con cualquier otro motor de validación compatible con OATH.
Protectimus ofrece cuatro modelos de token hardware para estos escenarios, incluidas tarjetas NFC programables y tokens SHA-256 de semilla fija. Vea todas las opciones de token hardware →
Los métodos basados en TOTP (app autenticadora y tokens hardware) son operativamente la opción más sólida para la mayoría de las implementaciones empresariales on-premise. Ambos generan códigos localmente sin conectividad a internet. Ambos producen códigos de 30 segundos que resultan inútiles para un atacante que los intercepte después de que hayan caducado.
Qué servicios se pueden proteger
Active Directory, LDAP y bases de datos. Con Protectimus DSPA, la MFA on-premise protege las cuentas de directorio a nivel de directorio, extendiendo la protección al inicio de sesión de Windows, RDP, el acceso VPN, OWA y cualquier aplicación vinculada a AD. La segmentación basada en grupos permite empezar por las cuentas privilegiadas antes de ampliar la cobertura. Protectimus implementa la MFA a nivel de directorio mediante DSPA (Dynamic Strong Password Authentication) →
Puertas de enlace VPN vía RADIUS. Cubre Cisco ASA, Cisco Firepower, Fortinet, Palo Alto, Check Point, Juniper y la mayoría de las puertas de enlace VPN compatibles con RFC 2865. El requisito de red principal es el puerto UDP 1812 de entrada desde la puerta de enlace. Para un ejemplo práctico, vea MFA para Cisco AnyConnect →
ADFS y aplicaciones federadas. Un plugin se integra como proveedor de autenticación adicional en el flujo de ADFS, habilitando la protección MFA para todos los servicios federados enrutados a través de ADFS: Microsoft 365, SharePoint, Salesforce y otros. Vea la integración con ADFS →
Inicio de sesión de Windows y RDP. A Windows Credential Provider protects desktop and server logons, with offline validation support via one-time backup codes for workstations that cannot reach the authentication server. See MFA para el inicio de sesión de Windows y RDP →
Outlook Web App y aplicaciones web. Integración con OWA para Exchange 2013-2019. Roundcube mediante plugin. Aplicaciones web personalizadas mediante API REST o SDK. Vea la integración con OWA → y la integración con Roundcube →
Requisitos de implementación
Las plataformas de MFA on-premise tienen requisitos de hardware modestos: unos pocos núcleos de CPU y varios GB de RAM por nodo suelen bastar para el propio motor de autenticación. El almacenamiento escala principalmente en función de la retención de los registros de auditoría.
Un despliegue estándar de un solo dominio —un bosque AD, una puerta de enlace VPN, estaciones de trabajo estándar— es alcanzable en uno o dos días, incluyendo las pruebas piloto. El tiempo de despliegue completo depende después del número de integraciones y del enfoque de registro (portal de autoservicio o aprovisionamiento masivo por CSV).
La infraestructura RADIUS existente, incluidas Cisco ISE y FreeRADIUS, suele poder conservarse integrando la nueva plataforma de autenticación como una capa de proxy RADIUS con cambios mínimos de configuración.
Para conocer las especificaciones exactas de implementación de Protectimus (CPU, RAM, almacenamiento, SO y bases de datos compatibles, cronograma de despliegue paso a paso), consulte Protectimus On-Premise MFA Platform →
Casos de uso por sector y cumplimiento
Sector | Motor de cumplimiento | Notas |
Servicios financieros | PCI DSS v4.0, SOX, DORA | Tokens hardware para entornos regulados y de alta seguridad; DSPA para AD |
Salud | HIPAA, HITECH | Tokens hardware para flujos de EVV y MFA en estaciones de trabajo clínicas compartidas |
Gobierno / defensa | NIST 800-63B, FISMA, CMMC | Implementaciones air-gapped y soporte de tokens hardware |
Energía / infraestructura crítica | NERC CIP, NIS2 | MFA on-premise y tokens hardware para entornos ICS y OT aislados |
Telecomunicaciones | NIS2 | MFA para infraestructura de red de telecomunicaciones distribuida y multisitio |
El Requisito 8.4.2 de PCI DSS v4.0 exige MFA para todo acceso remoto al entorno de datos de titulares de tarjetas, sin excepciones. DORA convierte a los proveedores de autenticación en la nube en proveedores TIC externos que requieren una diligencia debida formal. Las salvaguardas técnicas de HIPAA (45 CFR §164.312)exigen controles de acceso para los sistemas ePHI; HHS recomienda explícitamente la MFA para el acceso remoto.OATH TOTP se usa ampliamente para respaldar los requisitos de autenticación AAL2 de NIST SP 800-63B.
Preguntas frecuentes
¿Qué es la MFA on-premise y en qué se diferencia de la MFA en la nube?
La MFA on-premise ejecuta toda la pila de autenticación —motor de OTP, base de datos de usuarios, semillas de los tokens, registros de auditoría— en sus propios servidores. La MFA en la nube envía las solicitudes de autenticación a la infraestructura de un proveedor para su procesamiento. La experiencia del usuario final es idéntica: un aviso de segundo factor. La diferencia está en dónde ocurre el procesamiento y si se requiere conectividad externa. On-premise valida los OTP localmente sin llamadas salientes. La MFA en la nube deja de funcionar si la API del proveedor no está disponible.
¿Por qué los sectores regulados prefieren la MFA on-premise en 2026?
Por tres razones. Primero, la residencia de datos: el RGPD, DORA y PCI DSS imponen requisitos sobre dónde se procesan los datos de autenticación; la MFA on-premise los mantiene totalmente bajo control de la organización. Segundo, las redes air-gapped: los entornos clasificados y de infraestructuras críticas no pueden enrutar solicitudes a APIs externas; on-premise es la única arquitectura que funciona. Tercero, la sencillez de la auditoría: no tener un procesador de autenticación de terceros significa que no hay evaluación de seguridad de proveedor dentro del alcance de las auditorías de cumplimiento.
¿Puede la MFA on-premise de Protectimus funcionar en redes air-gapped?
Sí. Toda la validación de OTP se realiza contra semillas de tokens almacenadas localmente. No se realiza ninguna llamada saliente durante la autenticación. La plataforma funciona sin conectividad a internet tras la implementación inicial. Los tokens hardware preaprovisionados admiten implementaciones air-gapped totalmente aisladas.
¿Cuáles son los requisitos de hardware para implementar MFA on-premise?
El mínimo recomendado por nodo es: CPU de 2 núcleos, 8 GB de RAM, 20 GB de almacenamiento, Linux o Windows. Las implementaciones HA en producción suelen usar un clúster de 3 nodos con un balanceador de carga. Los mismos requisitos de implementación se aplican a entornos físicos, virtuales y de nube privada, incluidos AWS y Azure.
¿La MFA on-premise admite clustering y alta disponibilidad?
Sí. El mínimo recomendado es un clúster de 3 nodos con balanceo de carga HAProxy y replicación de base de datos primaria-réplica. El failover automático enruta las solicitudes a los nodos operativos si uno queda no disponible. Un número de nodos superior a tres aumenta tanto el rendimiento como la tolerancia a fallos.
¿Qué servicios puede proteger la MFA on-premise?
Active Directory mediante DSPA, puertas de enlace VPN y otros servicios mediante RADIUS, aplicaciones federadas mediante el plugin de ADFS, el inicio de sesión de estaciones de trabajo Windows y RDP mediante Windows Credential Provider, Outlook Web App, Roundcube y aplicaciones web personalizadas mediante API REST.
¿La MFA on-premise cumple con el RGPD, DORA, PCI DSS y HIPAA?
On-premise es la postura de cumplimiento más sólida para los marcos con requisitos de residencia de datos. El Requisito 8.4.2 de PCI DSS v4.0 puede satisfacerse mediante OATH TOTP a través de RADIUS y otros componentes de integración. El cumplimiento del RGPD se refuerza al eliminar la dependencia de un procesador de autenticación externo. Los requisitos de riesgo de terceros TIC de DORA no se aplican a la infraestructura alojada internamente. Las salvaguardas técnicas de HIPAA se satisfacen con registros de autenticación conservados localmente.
¿Cuánto tiempo lleva implementar la Protectimus On-Premise MFA Platform?
Un entorno estándar de un solo dominio —un bosque AD, una puerta de enlace VPN, estaciones de trabajo estándar— es alcanzable en uno o dos días, incluyendo las pruebas piloto. El despliegue completo depende del número de integraciones y del enfoque de registro. El portal de autoservicio y el aprovisionamiento masivo por CSV reducen significativamente la carga del administrador durante el despliegue. Contacte con Protectimus para evaluar su entorno específico.
Conclusión
La MFA on-premise no es la opción adecuada para todas las organizaciones. Sin restricciones regulatorias de residencia de datos ni requisitos de aislamiento de red, la MFA en la nube es más rápida y operativamente más sencilla.
Para las organizaciones donde esas restricciones son reales —donde la salida de datos de autenticación de la red genera exposición de cumplimiento, donde la arquitectura air-gapped hace imposibles las llamadas a APIs externas—, on-premise es la única arquitectura que funciona. La Protectimus On-Premise MFA Platform cubre la implementación completa para este escenario: DSPA para Active Directory, RADIUS para VPN, ADFS para aplicaciones federadas, Windows Credential Provider para las estaciones de trabajo.
