MFA para Cisco AnyConnect: guía completa para proteger el acceso VPN en 2026
Cisco AnyConnect gestiona el acceso remoto de millones de usuarios empresariales, pero no cuenta con una función nativa para exigir la autenticación de dos factores. El cliente envía las credenciales al servidor de autenticación que tenga configurado el dispositivo ASA o Firepower. Si ese servidor solo valida el nombre de usuario y la contraseña, la sesión de VPN se abre tanto con credenciales robadas como con las legítimas.
Según el Informe de investigaciones sobre filtraciones de datos de Verizon de 2026 y varios avisos sobre ransomware de la CISA, el compromiso de las VPN sigue siendo uno de los principales vectores de acceso inicial del ransomware observados en las campañas de 2024 a 2026, incluidas las operaciones vinculadas a Akira, LockBit y Black Basta. La forma de ataque rara vez es sofisticada: se roban credenciales mediante phishing o programas de robo de información, se identifica la puerta de enlace AnyConnect, se autentica y se establece la persistencia. La única barrera fiable es un segundo factor de autenticación que no se pueda reutilizar junto con las credenciales robadas.
En esta guía te explicamos cómo configurarla autenticación multifactorial (MFA) en Cisco AnyConnect mediante autenticación basada en RADIUS, qué métodos de autenticación hay disponibles, cómo funciona la implementación tanto en entornos en la nube como locales, y qué marcos de cumplimiento admite la arquitectura.
Si quieres una visión general independiente del proveedor sobre la implementación de MFA en FortiGate, Palo Alto, SonicWall, OpenVPN y otras puertas de enlace, echa un vistazo a la solución Protectimus MFA para VPN.
Respuesta rápida: la MFA de Cisco AnyConnect se implementa configurando el dispositivo ASA o Firepower para reenviar las solicitudes de autenticación a un servidor RADIUS. El Protectimus RADIUS Server se sitúa entre el ASA y la plataforma de autenticación de Protectimus: recibe la solicitud por el puerto UDP 1812, valida la credencial principal contra su directorio y verifica el OTP con la plataforma Protectimus antes de devolver un Access-Accept o Access-Reject al ASA. Los usuarios se autentican con la app Protectimus SMART OTP, un token hardware o un OTP entregado por chatbot, normalmente introduciendo el OTP en un segundo campo de desafío.
Índice
- Por qué Cisco AnyConnect necesita MFA en 2026
- Cómo funciona la MFA para Cisco AnyConnect
- Métodos de MFA compatibles
- Guía de configuración paso a paso
- Opciones de implementación: nube frente a on-premise
- Protectimus frente a Cisco Duo para AnyConnect
- Cumplimiento y casos de uso
- Solución de problemas habituales
- Preguntas frecuentes
- Conclusión
Datos clave
99,9% de los ataques bloqueados con MFA
Microsoft 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 2026
IBM 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)
87% de los siniestros de ransomware comienzan por el acceso remoto
Coalition El Cyber Claims Report de Coalition encontró que los servicios de acceso remoto sirvieron como punto de entrada en el 87% de los siniestros de ransomware, y los compromisos de VPN por sí solos fueron responsables del 73% de las intrusiones en las que se identificó un vector de entrada.
Ventajas clave
Integración basada en RADIUS
Cisco AnyConnect no tiene MFA nativa: la aplicación del segundo factor requiere un servidor RADIUS que gestione la autenticación en nombre del dispositivo ASA o Firepower.
Cero cambios del lado del cliente
El Protectimus RADIUS Server actúa de proxy entre el ASA (UDP 1812) y la plataforma Protectimus; no hace falta modificar el cliente AnyConnect ni la configuración del túnel VPN.
6 métodos de segundo factor
Segundos factores admitidos: app TOTP (Protectimus SMART), tokens hardware (Slim NFC, TWO, FLEX, SHARK), OTP por chatbot vía Telegram/Viber/Facebook, SMS, correo electrónico.
Nube o totalmente on-premise
Disponibles tanto la implementación en la nube (SaaS) como la totalmente on-premise; la opción on-premise no requiere conectividad externa y admite entornos air-gapped.
Despliegue granular por grupos
La MFA puede limitarse a perfiles de conexión o grupos de usuarios específicos mediante la asignación de AAA server group y atributos de filtro RADIUS.
Lista para auditorías
La implementación ayuda a las organizaciones a cumplir los requisitos de MFA de PCI DSS v4.0, HIPAA, NIST SP 800-63B, SOC 2 e ISO 27001.
Por qué Cisco AnyConnect necesita MFA en 2026
La autenticación de AnyConnect solo con contraseña es un vector de acceso inicial documentado para el ransomware: las credenciales de VPN robadas se comercializan y explotan activamente a gran escala.
La cadena de robo de credenciales para el acceso VPN está industrializada. El malware de tipo infostealer —RedLine, Lumma, Vidar y similares— ataca específicamente las credenciales guardadas en el navegador y los archivos de configuración del cliente VPN. Las credenciales recolectadas se empaquetan junto con el nombre de host de la puerta de enlace VPN asociada y se venden en cuestión de horas. Un atacante que compra un lote de credenciales de un endpoint comprometido en su organización ya dispone de la dirección del servidor AnyConnect, el usuario y la contraseña. La autenticación de dos factores para Cisco AnyConnectes el único control que hace que esas credenciales dejen de ser utilizables.
El Cyber Claims Report de Coalition encontró que los servicios de acceso remoto sirvieron como punto de entrada en el 87% de los siniestros de ransomware, y los compromisos de VPN por sí solos fueron responsables del 73% de las intrusiones de ransomware en las que se identificó un vector de entrada, frente al 38% en 2023 y el 66% en 2024. El aumento no es casual. Los operadores de ransomware se han decantado por el acceso inicial basado en identidad precisamente porque genera menos ruido que la explotación de vulnerabilidades y escala de forma más eficiente con herramientas automatizadas.
Los patrones de ataque específicos que apuntan a entornos AnyConnect:
Credential stuffing.El análisis de Verizon sobre registros de proveedores SSO encontró que el credential stuffing representó el 19% de todos los intentos de autenticación en una mediana diaria. El mismo patrón se aplica a las puertas de enlace VPN. Los ataques se ejecutan a baja velocidad para evitar los disparadores de bloqueo, probando de forma continua listas de credenciales filtradas contra el endpoint de AnyConnect.
Fuerza bruta. Las puertas de enlace Cisco ASA y Firepower con políticas de bloqueo de cuentas débiles o por defecto son escaneadas de forma continua. CISA ha emitido varias alertas centradas específicamente en campañas de credential stuffing por parte de actores respaldados por estados contra la infraestructura VPN de Cisco ASA.
Robo de tokens de sesión mediante AiTM. En las implementaciones que usan MFA basada en push, kits de herramientas adversary-in-the-middle como Tycoon2FA capturan los tokens de sesión en tiempo real durante la autenticación. Los códigos basados en TOTP, que caducan cada 30 segundos, son considerablemente más resistentes porque la ventana de reutilización es extremadamente limitada: un TOTP capturado no sirve de nada antes de poder reutilizarlo.
Recolección por infostealer. Un único endpoint comprometido puede exfiltrar credenciales VPN guardadas, archivos XML de perfil de Cisco AnyConnect y, en implementaciones con MFA basada en push, cookies de sesión válidas durante horas o días. La 2FA de Cisco AnyConnect basada en TOTP limita la ventana de exposición al paso de tiempo del token.
Ninguno de estos patrones de ataque exige al atacante romper el cifrado, explotar una vulnerabilidad de software ni invertir recursos significativos. Solo requieren una credencial válida. Aplicar MFA en Cisco AnyConnect elimina las credenciales estáticas como primitiva de ataque viable.
Cómo funciona la MFA para Cisco AnyConnect
La MFA de Cisco AnyConnect funciona a través del protocolo RADIUS: el dispositivo ASA o Firepower reenvía las solicitudes de autenticación a un servidor RADIUS externo que se encarga de la verificación del segundo factor.
Cisco ASA y Firepower no admiten de forma nativa TOTP, HOTP ni autenticación push. Su framework AAA se basa en RADIUS y LDAP. Añadir MFA RADIUS a AnyConnect implica desplegar un servidor RADIUS intermediario que acepta solicitudes del ASA, realiza tanto la validación de la credencial principal como la verificación del OTP, y devuelve una respuesta RADIUS estándar de Access-Accept o Access-Reject.
Flujo de autenticación:
- El usuario abre Cisco AnyConnect e introduce sus credenciales (usuario + contraseña)
- El ASA o Firepower reenvía la solicitud de autenticación al Protectimus RADIUS Server por el puerto UDP 1812
- El RADIUS Server reenvía la credencial principal al directorio configurado (Active Directory, LDAP o almacén local) para la validación del primer factor
- Si la credencial principal se valida, el RADIUS Server solicita el segundo factor de autenticación y, al recibirlo, reenvía el OTP a la plataforma de autenticación Protectimus para su validación
- La plataforma Protectimus valida el OTP contra el token registrado del usuario y devuelve el resultado (correcto/incorrecto)
- El RADIUS Server envía un Access-Accept o Access-Reject al ASA
- El ASA concede o deniega el túnel VPN
Formatos de introducción de credenciales:
Formato challenge-response: el ASA valida primero la contraseña principal y luego emite un RADIUS Access-Challenge solicitando el OTP en un campo secundario. Ofrece una experiencia de usuario más limpia y se usa habitualmente en las implementaciones modernas de MFA para AnyConnect, incluidas las integraciones de Protectimus, pero requiere tener habilitado el soporte de challenge-response en el perfil de conexión del ASA.
Formato combinado: algunas implementaciones RADIUS admiten la autenticación combinada, en la que el usuario introduce[password][OTP] como una única credencial, por ejemplo, P@ssw0rd!459812. El RADIUS Server separa los últimos 6 dígitos como OTP. No aparece ningún segundo campo en el cliente AnyConnect. Es la configuración más sencilla y funciona con todas las versiones de AnyConnect.
Compatibilidad con Cisco Firepower (FTD):
La integración RADIUS se aplica de igual forma a Firepower Threat Defense cuando gestiona el acceso remoto VPN de AnyConnect. Ruta de configuración en Firepower Management Center: Remote Access VPN → Connection Profiles → AAA → RADIUS Server Group. La configuración de puerto y secreto compartido es idéntica a la del ASA.
Cisco ISE:
Para las organizaciones que usan Cisco ISE como infraestructura AAA, Protectimus se integra mediante un proxy RADIUS estándar. ISE reenvía las solicitudes de autenticación al Protectimus RADIUS Server, que gestiona la verificación del OTP y devuelve el resultado a ISE para la evaluación de políticas.
Métodos de MFA compatibles
Protectimus admite seis métodos de entrega del segundo factor para Cisco AnyConnect: app TOTP, tokens hardware, OTP por chatbot, SMS, correo electrónico y notificaciones push, cada uno con distintas características de seguridad y operativa.
App Protectimus SMART OTP
La Protectimus SMART OTP app genera códigos OATH TOTP en Android e iOS. Funciones clave para el entorno empresarial: copia de seguridad en la nube para la recuperación autónoma del token tras la pérdida del dispositivo, protección con PIN y biometría a nivel de app, e intervalos de tiempo configurables (30, 60, 90 segundos y múltiplos hasta 3000 segundos). La copia de seguridad en la nube reduce la carga del servicio de soporte durante la sustitución de dispositivos: los usuarios restauran sus propios tokens sin intervención del administrador.
Tokens OTP hardware
Para entornos donde no se permiten dispositivos móviles —instalaciones seguras, plantas de fabricación, redes air-gapped u organizaciones con restricciones estrictas de BYOD—, Protectimus ofrece cuatro modelos de hardware token:
| Token | Formato | Intervalo de tiempo | Interfaz | Descripción |
| Protectimus Slim NFC | Tarjeta de crédito | 30/60 s | NFC | Token reprogramable en formato tarjeta, compatible con NFC |
| Protectimus TWO | Llavero | 30/60 s | Ninguna | Token hardware SHA-1 estándar para implementaciones OTP tradicionales con semilla fija |
| Protectimus FLEX | Llavero | 30s | NFC | Token llavero reprogramable para implementaciones empresariales flexibles |
| Protectimus SHARK | Llavero | 30s | Ninguno | Token hardware SHA-256 para organizaciones que necesitan algoritmos criptográficos de mayor solidez en implementaciones a gran escala |
Los cuatro modelos usan el estándar OATH TOTP y se aprovisionan desde la consola de administración de Protectimus. Los modelos programables con NFC (Slim NFC, FLEX) pueden reprogramarse mediante un smartphone Android con NFC, lo que permite a administradores o usuarios sustituir la clave secreta sin reemplazar el token físico.
Protectimus BOT (entrega de OTP por chatbot)
Códigos OTP entregados mediante chatbot en Telegram, Viber o Facebook Messenger. El usuario recibe un código de duración limitada en su cuenta de mensajería vinculada. Requiere conexión a internet en el dispositivo del usuario, pero elimina la necesidad de instalar una app autenticadora aparte. Adecuado para usuarios sin gestión corporativa de dispositivos o en entornos BYOD donde el aprovisionamiento de apps está limitado.
SMS OTP
Contraseñas de un solo uso entregadas por SMS. Protectimus admite la integración con proveedores de SMS personalizados mediante SMPP, lo que permite enrutar los mensajes a través de la infraestructura SMS existente. Nivel de seguridad menor que la app TOTP o el token hardware, pero adecuado como método de respaldo para determinados grupos de usuarios.
Email OTP
Entrega de OTP por correo electrónico. El nivel de seguridad más bajo —las propias cuentas de correo son objetivo del robo de credenciales—, pero ofrece una opción de respaldo para usuarios sin acceso móvil.
Autenticación push
Se envían notificaciones push al dispositivo móvil del usuario para su aprobación, en lugar de exigir la introducción manual del OTP. Los usuarios confirman o rechazan el intento de inicio de sesión directamente en la app Protectimus SMART. No obstante, este método de autenticación puede seguir siendo vulnerable a la fatiga de MFA y a los ataques de push bombing.
Resumen comparativo:
| Método | Resistencia al phishing | Funciona sin conexión | Recuperación autónoma | Dispositivo necesario |
| Aplicación SMART OTP | Alto | Sí | Sí (copia en la nube) | Smartphone |
| Token físico | Alto | Sí | No (lo sustituye el administrador) | Token de hardware |
| BOT (Telegram/Viber) | Medium | No | N/A | Smartphone |
| SMS | Medio | No | N/A | Teléfono móvil |
| Correo electrónico | Bajo-Medio | No | N/A | Acceso al correo |
| Push | Medio | No | Sí (copia de seguridad en la nube) | Smartphone |
Para las implementaciones de 2FA en Cisco VPN en particular, los métodos basados en TOTP —app SMART y tokens hardware— son la opción operativamente más adecuada. Ambos funcionan sin conexión (los códigos OTP se generan localmente en el dispositivo y no requieren conectividad a internet por parte del usuario) y ambos resisten la captura de tokens mediante AiTM gracias a la ventana de caducidad de 30 segundos.
Guía de configuración paso a paso
Configurar la MFA de Cisco AnyConnect con Protectimus requiere cuatro etapas: configuración de la plataforma o servicio Protectimus, configuración del RADIUS Server, configuración AAA en ASA/Firepower y registro de usuarios.
Paso 1: Configurar la plataforma o el servicio en la nube de Protectimus
Regístrese en protectimus.compara el servicio en la nube, o instale la Protectimus On-Premise Platformen su infraestructura. En la plataforma:
- Cree un Resource que represente la integración con AnyConnect VPN
- Anote su API URL,Login, y API Key, necesarios para configurar el RADIUS Server
Paso 2: Instalar y configurar el Protectimus RADIUS Server
Si utiliza el servicio en la nube de Protectimus, instale el Protectimus RADIUS Server en un host Linux (recomendado) o en un servidor Windows accesible desde el ASA. Para las implementaciones on-premise, el RADIUS Server se instala junto con la plataforma Protectimus.
Edite el archivo de configuración radius.yml. Este es un ejemplo de configuración básica de radius.yml:
auth:
providers:
- LDAP
- PROTECTIMUS_OTP
re-enter-otp: true
principal-normalization: true
protectimus-api:
login: your-api-login
api-key: your-api-key
url: https://api.protectimus.com/
resource-id: your-resource-id
radius:
secret: your-shared-secret
clients:
- name: cisco-asa
secret: your-shared-secret
ips:
- 192.168.1.100/32 # ASA outside interface IP
auth-port: 1812
listen-address: 0.0.0.0
ldap:
base: dc=example,dc=com
urls:
- ldap://192.168.1.10:389
username: admin@example.com
password: your-ldap-password
principal-attribute: userPrincipalName
Este ejemplo muestra una configuración básica de LDAP + OTP para la MFA de Cisco AnyConnect. Las implementaciones reales pueden requerir ajustes adicionales según los proveedores de autenticación, el modo OTP en línea, los atributos RADIUS o la integración con Active Directory de su entorno.
La documentación completa de configuración del Protectimus RADIUS Server está disponible en la guía Protectimus RADIUS 2FA.
Inicie el servicio del servidor RADIUS. Confirme que está escuchando en UDP 1812. Verifique que las reglas del firewall permiten UDP 1812 y 1813 (accounting) desde la IP del ASA hacia el RADIUS Server.
Paso 3: Configurar el AAA Server Group en Cisco ASA
En Cisco ASDM, vaya a: Configuration → Remote Access VPN → AAA/Local Users → AAA Server Groups:
- Haga clic en Add dentro de la sección AAA Server Groups.
- Especifique el nombre del AAA Server Group (por ejemplo, protectimus) y establezca Protocol en RADIUS.
- Configure los parámetros del grupo:
- Accounting Mode—Single
- Reactivation Mode—Depletion
- Dead Time—10
- Max Failed Attempts—3
- Haga clic en OK.
- Seleccione el AAA Server Group recién creado.
- En la sección Servers in the Selected Group, haga clic en Add.
- Configure los parámetros del servidor RADIUS:
- Interface Name — interfaz utilizada para comunicarse con el Protectimus RADIUS Server
- Server Name or IP Address — dirección IP del Protectimus RADIUS Server
- Timeout —10 segundos (auméntelo si los usuarios necesitan más tiempo para introducir los códigos OTP)
- Server Authentication Port—1816
- Server Accounting Port—1815
- Retry Interval —10 segundos
- Server Secret Key — debe coincidir con el secreto configurado en el Protectimus RADIUS Server
- Haga clic en OK.
Para Cisco Firepower via FMC , vaya a:
Objects → Object Management → RADIUS Server Group → Add Group.
Añada un nuevo RADIUS Server Group. Los parámetros son idénticos.
Paso 4: Configurar la conexión VPN de AnyConnect
En Cisco ASDM, abra:
Wizards → VPN Wizards → AnyConnect VPN Wizard
- Configura el perfil de conexión:
- Especifica elnombre del perfil de conexión
- Selecciona lainterfaz de acceso a la VPN
- Configura los protocolos VPN:
- Activa SSL
- Activa IPsec
- Selecciona o genera un certificado de dispositivo
- Añade la imagen del cliente AnyConnect (*.pkg).
- En la secciónpaso Métodos de autenticación:
- Selecciona el archivoprotectimusgrupo de servidores AAA
- En lapaso de configuración de SAML:
- Estableceel método de autenticaciónenAAA
- Selecciona laprotectimusGrupo de servidores AAA
- Salir deel servidor SAMLconfigurado enNinguno
- Configura el conjunto de direcciones IP de los clientes.
- Configura los ajustes de DNS.
- ActivaExcluir el tráfico VPN de la traducción de direcciones de red.
- ActivaPermitir Web Launch.
- Revisa el resumen de la configuración y haz clic enFinalizar.
Paso 5: Registrar usuarios
Añada usuarios a la plataforma Protectimus de forma manual, mediante importación CSV o mediante sincronización LDAP con Active Directory. Asigne tokens a los usuarios manualmente o active el Self-Service Portal para que los usuarios puedan registrarse y gestionar sus propios tokens. Realice pruebas de autenticación con un grupo piloto antes de una implementación más amplia.
Opciones de implementación: nube frente a on-premise
La MFA de Protectimus para Cisco AnyConnect está disponible como servicio SaaS en la nube o como plataforma totalmente on-premise; ambas opciones admiten la integración RADIUS completa y el conjunto completo de funciones.
Implementación en la nube
El servicio en la nube solo requiere el componente RADIUS Server desplegado localmente. El RADIUS Server se comunica con la API del servicio Protectimus Cloud para validar los OTP. No se necesita infraestructura de plataforma en el lado del cliente.
Requisitos técnicos para la implementación en la nube:
- Un servidor Linux o Windows para el componente RADIUS Server
- Acceso HTTPS saliente desde el RADIUS Server hasta api.protectimus.com
- Entrada UDP 1812/1813 desde el ASA hasta el RADIUS Server
Implementación on-premise
La Plataforma Protectimus On-Premise funciona íntegramente dentro de tu infraestructura. En ningún momento salen datos de autenticación de tu red.
Requisitos técnicos:
Componente | Requisito |
CPU | 2 núcleos como mínimo |
RAM | 8 GB como mínimo |
Almacenamiento | Mínimo 20 GB de espacio en disco |
Sistema operativo | Linux (principal), Windows |
Configuración HA | Clúster opcional de 3 nodos con HAProxy |
Balanceo de carga | Se recomienda balanceador para implementaciones HA |
Comparación de implementaciones:
Factor | Nube | On-premise |
Infraestructura necesaria | Solo RADIUS Server | Protectimus On-Premise Platform (incluye RADIUS Server) |
Tiempo hasta la primera autenticación | Normalmente, unas horas | Normalmente, unas horas tras preparar la infraestructura |
Mantenimiento de la plataforma | A cargo de Protectimus | Autogestionado |
Residencia de datos | Nube de Protectimus | Totalmente dentro de su red |
Soporte air-gapped | No | Sí |
HA / agrupación en clústeres | Gestionado por Protectimus | Autogestionado (se recomiendan 3 nodos) |
Implementación de una nube privada | No | Nube privada de AWS/Azure/VMware |
Para entornos que operan bajo los requisitos del entorno de datos de titulares de tarjetas de PCI DSS, HIPAA, FISMA o cualquier marco donde se evalúe la residencia de los datos de autenticación durante la auditoría, la implementación on-premise es la opción arquitectónicamente adecuada.
Protectimus frente a Cisco Duo para AnyConnect
Tanto Protectimus como Cisco Duo se integran con Cisco AnyConnect mediante RADIUS y admiten segundos factores basados en TOTP; las diferencias arquitectónicas están en el modelo de implementación, la disponibilidad de tokens hardware y los requisitos de conectividad externa.
Esta sección describe diferencias técnicas objetivas. La elección adecuada depende de los requisitos de infraestructura específicos de su organización.
Arquitectura de integración
Ambas soluciones usan RADIUS como vía principal de integración para SSL VPN e IPSec VPN en AnyConnect. Duo ofrece además una integración basada en SAML que habilita un aviso interactivo de registro y autenticación para inicios de sesión VPN vía navegador (cliente AnyConnect 4.6+). La vía RADIUS, utilizada por ambas soluciones, cubre todos los tipos de conexión de AnyConnect sin diferencias adicionales de configuración.
Implementación on-premise y conectividad externa
Protectimus On-Premise se ejecuta como una plataforma totalmente autónoma. Una vez implementada, no requiere conectividad externa para validar las solicitudes de autenticación: toda la verificación de OTP ocurre dentro de su red.
El componente on-premise de Duo (Duo Authentication Proxy) reenvía las solicitudes de autenticación a la infraestructura en la nube de Duo para su procesamiento. Las solicitudes de autenticación pasan por los servidores de Duo incluso en configuraciones “on-premise”. Para organizaciones con requisitos de aislamiento de red, entornos air-gapped o marcos de cumplimiento que restringen la salida de datos de autenticación, esta es una distinción arquitectónica relevante.
Soporte de tokens hardware
Protectimus ofrece cuatro modelos de token OTP hardware disponibles directamente: Slim NFC, TWO, FLEX y SHARK. Todos admiten el estándar OATH TOTP. Los modelos con NFC admiten la reprogramación del token mediante un smartphone Android. Duo admite tokens hardware compatibles con OATH de proveedores externos, pero no ofrece su propia línea de tokens hardware.
Integración con el ecosistema Cisco
La integración directa de Duo con Cisco ISE, Cisco Umbrella y Cisco SecureX proporciona una aplicación de políticas más estrecha para las organizaciones que ya operan dentro del stack de seguridad de Cisco. Protectimus se integra con Cisco ISE mediante un proxy RADIUS estándar, pero no cuenta con conectores dedicados para otros componentes de la plataforma Cisco.
Comparación objetiva:
Factor | Protectimus | Cisco Duo |
Integración de RADIUS con AnyConnect | Sí | Sí |
Compatibilidad con SAML y solicitudes web interactivas | No | Sí |
Compatibilidad con tokens de hardware | 4 modelos de tokens de hardware (clásicos y programables) | Compatible con tokens OATH de otros fabricantes |
In situ, sin dependencias externas | Sí | No (necesita Duo Cloud) |
Compatibilidad con entornos aislados físicamente | Sí | No |
Portal de inscripción autoservicio | Sí | Sí |
Integración con Cisco ISE | A través de un proxy RADIUS | Integración nativa |
Integración con el ecosistema de Cisco (ISE, Umbrella, SecureX) | Integración estándar basada en RADIUS | Integración nativa |
Cumplimiento y casos de uso
La MFA de Cisco AnyConnect mediante Protectimus aborda directamente los requisitos obligatorios de segundo factor de PCI DSS v4.0, HIPAA, NIST SP 800-63B, SOC 2 e ISO 27001.
PCI DSS v4.0
El Requisito 8.4.2 exige MFA para todo acceso administrativo no consola y para todo acceso remoto a la red originado fuera del entorno de datos de titulares de tarjetas. Las conexiones VPN de AnyConnect a sistemas dentro del alcance de PCI DSS quedan sujetas a este requisito sin excepción. La implementación TOTP de Protectimus satisface el Requisito 8.4.2; la implementación on-premise responde a las consideraciones de residencia de datos relevantes para los auditores de PCI DSS que evalúan la ubicación de la infraestructura de autenticación.
HIPAA
Las salvaguardas técnicas de la HIPAA Security Rule (45 CFR §164.312) exigen controles de acceso y autenticación para los sistemas que contienen información sanitaria protegida electrónica. La guía de HHS recomienda explícitamente la MFA para el acceso remoto a sistemas ePHI. Para las organizaciones sanitarias que usan AnyConnect para acceder a sistemas clínicos, aplicar la Cisco AnyConnect MFA es coherente con las expectativas de auditoría actuales de HHS.
NIST SP 800-63B
En el nivel de garantía de autenticador 2 (AAL2), NIST exige un mecanismo de autenticación multifactor que use un autenticador aprobado de tipo “algo que usted tiene”. OATH TOTP satisface AAL2. Los tokens hardware satisfacen AAL2 sin condiciones adicionales; la app Protectimus SMART OTP con protección por PIN o biometría también satisface AAL2. Las organizaciones que operan bajo FedRAMP o FISMA se remiten directamente a NIST 800-63B para los requisitos de autenticación de acceso remoto.
SOC 2
Las auditorías SOC 2 Type II evalúan los controles de acceso lógico bajo el Common Criteria 6.1 (CC6.1). La MFA aplicada en el acceso remoto por VPN —con política documentada, evidencia de implementación y registros de auditoría— satisface CC6.1 y es evidencia de auditoría estándar en las evaluaciones SOC 2.
ISO 27001
El control A.9.4.2 del Anexo A (procedimientos seguros de inicio de sesión) aborda la solidez de la autenticación para el acceso a sistemas. La MFA en el acceso remoto por VPN es evidencia estándar para este control en las auditorías de certificación ISO 27001.
Casos de uso por sector:
Sector | Motivación para el cumplimiento | Notas de implementación |
Servicios financieros | PCI DSS v4.0, SOX | Implementación local; tokens físicos para el acceso privilegiado |
Sanidad | HIPAA, HITECH | Implementación local; aplicación SMART + token físico como alternativa |
Gobierno / Defensa | NIST 800-63B, FISMA | Implementación local; compatibilidad con entornos aislados |
Energía / Infraestructuras críticas | NERC CIP, NIS2 | Implementación local; compatible con tokens de hardware |
Servicios profesionales | SOC 2 Tipo II | Implementación en la nube o en tus propias instalaciones |
Solución de problemas habituales
La mayoría de los fallos de autenticación de MFA en Cisco AnyConnect se deben a cuatro causas raíz: conectividad RADIUS, discrepancia del secreto compartido, deriva del reloj del OTP y configuración incorrecta de atributos AAA.
Fallos de conectividad RADIUS
Confirme que el UDP 1816 está abierto desde la interfaz externa o interna del ASA (según dónde esté ubicado el RADIUS Server) hasta la IP del RADIUS Server. test aaa-server authentication protectimus host <ip> username <user> password <password> desde la CLI del ASA para determinar si el fallo se produce entre el ASA y RADIUS o entre RADIUS y la API de Protectimus. Revisa los registros del servidor RADIUS para ver los códigos de motivo de rechazo y los errores de conectividad de la API.
Discrepancia del secreto compartido
El secreto compartido en la configuración del servidor AAA del ASA debe coincidir exactamente con el valor del secreto en la configuración de clientes del RADIUS Server; distingue mayúsculas y minúsculas, sin espacios en blanco al final. Una discrepancia suele manifestarse como un timeout o una respuesta ERROR en lugar de un Access-Reject explícito, porque el ASA no puede descifrar una respuesta firmada con un secreto distinto.
Deriva de tiempo del OTP
La validación TOTP depende del tiempo. Una deriva del reloj superior a 30 segundos entre el host del RADIUS Server y el token provocará fallos de OTP. Verifique que el NTP está configurado y sincronizándose en el host del RADIUS Server. Por defecto, la plataforma Protectimus admite una ventana de ±1 intervalo de tiempo (validando el OTP anterior y el siguiente además del actual), lo que ofrece 90 segundos de tolerancia; esto no compensa una deriva de reloj sostenida. Si es necesario, la ventana de tolerancia a la deriva de tiempo puede ampliarse en la configuración de la plataforma o del servicio en la nube de Protectimus, aunque esto no debe sustituir a una sincronización de tiempo correcta.
Tiempo de espera de autenticación durante la introducción del OTP
El tiempo de espera por defecto del servidor AAA del ASA suele ser de 10-12 segundos. Sin embargo, valores de tiempo de espera cortos pueden interrumpir la autenticación antes de que los usuarios tengan tiempo de introducir un código OTP, especialmente al usar SMS, correo electrónico o entrega por chatbot. Si los usuarios experimentan fallos de autenticación relacionados con el tiempo de espera, aumente ese valor en la configuración del servidor AAA a 60 segundos o más. Para la entrega por SMS o correo electrónico, es más adecuado un rango de 90 a 120 segundos, dada la posible latencia de entrega.
Preguntas frecuentes
¿Cómo habilito la MFA en Cisco AnyConnect?
Cisco AnyConnect no tiene un motor de MFA integrado: la aplicación del segundo factor requiere configurar el ASA o Firepower para usar un servidor RADIUS externo para la autenticación AAA. El proceso con Protectimus: instalar y configurar el Protectimus RADIUS Server en un host Linux o Windows accesible desde el ASA; crear un AAA server group en ASDM o FMC que apunte a la IP del RADIUS Server por el puerto UDP 1816; asignar ese server group al perfil de conexión de AnyConnect en Authentication; registrar a los usuarios en la plataforma Protectimus con su tipo de token. La primera autenticación con MFA aplicada suele lograrse en 2-4 horas para una implementación estándar de un solo dominio. La guía completa de configuración está en protectimus.com/guides/cisco-anyconnect/.
¿Admite Cisco AnyConnect apps autenticadoras TOTP como Google Authenticator?
Cisco AnyConnect es agnóstico respecto a TOTP: pasa las credenciales al servidor RADIUS, que se encarga de validar el OTP. Funciona cualquier app compatible con OATH TOTP, incluidas Google Authenticator, Microsoft Authenticator y Protectimus SMART OTP. La diferencia funcional para implementaciones empresariales está en las capacidades de gestión. Protectimus SMART OTP admite copia de seguridad en la nube para la recuperación autónoma del token, protección con PIN y biometría, e intervalos de tiempo configurables más allá de los 30 segundos por defecto. Google Authenticator y Microsoft Authenticator no exponen API de gestión ni admiten la configuración del intervalo de tiempo, lo que limita su utilidad en implementaciones a gran escala donde importan la recuperación de tokens y la visibilidad para auditoría.
¿Puedo usar tokens OTP hardware con la VPN de Cisco AnyConnect?
Sí. Los tokens hardware OATH TOTP se integran con AnyConnect vía RADIUS de forma idéntica a los tokens software: el usuario introduce el OTP de 6 dígitos que muestra el token como segundo paso tras introducir su contraseña y usuario de VPN. Protectimus ofrece cuatro modelos de token hardware: Slim NFC (token programable en formato tarjeta de crédito con soporte NFC), TWO (llavero, sin NFC), FLEX (token hardware NFC programable en formato llavero) y SHARK (token hardware TOTP SHA-256 en formato llavero, no programable). Todos usan el estándar OATH TOTP, admiten intervalos de 30 segundos (opcionalmente 60) y se gestionan desde la consola de administración de Protectimus. Los tokens hardware son operativamente adecuados para entornos donde los dispositivos móviles están prohibidos, para trabajadores de campo sin acceso fiable a smartphones, o para roles de alta seguridad que necesitan un autenticador físico independiente del dispositivo principal del usuario.
¿En qué se diferencia la MFA de Protectimus para Cisco AnyConnect de Cisco Duo?
Ambas se integran vía RADIUS y admiten segundos factores basados en TOTP para AnyConnect. La principal diferencia arquitectónica está en la implementación on-premise: Protectimus On-Premise procesa todas las solicitudes de autenticación dentro de su infraestructura sin necesitar conectividad externa. El Authentication Proxy de Duo reenvía cada solicitud de autenticación a la infraestructura en la nube de Duo, lo que significa que las implementaciones on-premise de Duo requieren acceso saliente a internet hacia los servidores de Duo. Para entornos con requisitos de aislamiento de red o redes air-gapped, esta distinción es relevante. En cuanto a los tokens hardware, Protectimus ofrece cuatro modelos de suministro directo; Duo depende de dispositivos compatibles con OATH de terceros. Duo ofrece una integración más estrecha con el conjunto más amplio de seguridad de Cisco —ISE, Umbrella, SecureX— para las organizaciones estandarizadas en el ecosistema Cisco.
¿Cumple la MFA de Protectimus para Cisco AnyConnect con PCI DSS, HIPAA, NIST?
Sí. La implementación de TOTP vía RADIUS satisface los requisitos de MFA de los principales marcos de cumplimiento. El Requisito 8.4.2 de PCI DSS v4.0 exige MFA para todo acceso remoto al entorno de datos de titulares de tarjetas; OATH TOTP vía RADIUS satisface este requisito. Las salvaguardas técnicas de HIPAA exigen controles de acceso para los sistemas ePHI; la MFA en el acceso VPN se recomienda explícitamente en la guía actual de HHS. NIST SP 800-63B AAL2 exige un autenticador de tipo “algo que usted tiene”; OATH TOTP satisface AAL2, y los tokens hardware ofrecen la garantía AAL2 más sólida. SOC 2 CC6.1 (controles de acceso lógico) e ISO 27001 A.9.4.2 (procedimientos seguros de inicio de sesión) quedan cubiertos por una MFA documentada y aplicada en el acceso remoto. La opción de implementación on-premise es especialmente relevante cuando los auditores de cumplimiento evalúan la residencia y el lugar de procesamiento de los datos de autenticación.
¿Se puede aplicar la MFA solo a determinados grupos de usuarios de Cisco AnyConnect?
Sí, mediante varios métodos de configuración. A nivel del ASA, cada perfil de conexión (tunnel group) puede tener asignado un AAA server group distinto, lo que permite que perfiles específicos apliquen MFA RADIUS mientras otros usan autenticación local o de Active Directory. Dentro de la plataforma Protectimus, las políticas basadas en grupos permiten aplicar la MFA a grupos de usuarios concretos mientras se aplican políticas de autenticación diferentes a otros grupos. Esta flexibilidad respalda los despliegues por fases, comenzando la aplicación de la MFA con las cuentas privilegiadas y el personal de TI antes de extenderla a todos los usuarios.
¿Qué ocurre si un usuario pierde su token OTP o su smartphone?
La recuperación depende del método de autenticación. Para los usuarios de la app Protectimus SMART OTP con copia de seguridad en la nube activada, el usuario restaura su token en un dispositivo de sustitución a través del portal de autoservicio de Protectimus sin intervención del administrador. En caso de pérdida de un token hardware, un administrador desactiva el token perdido en la consola de administración de Protectimus y aprovisiona uno de sustitución. En situaciones urgentes, un administrador puede desactivar temporalmente la MFA para una cuenta de usuario concreta; esta acción está limitada en el tiempo, requiere autorización del administrador y queda registrada en el log de auditoría de Protectimus. Se recomienda encarecidamente activar el portal de autoservicio y la copia de seguridad en la nube en la app SMART antes del despliegue, para minimizar la dependencia del servicio de soporte en los escenarios habituales de sustitución de dispositivos.
¿Admite Protectimus Cisco AnyConnect con implementación on-premise?
Sí. La Protectimus On-Premise Platform se instala en servidores Linux o Windows dentro de su infraestructura: hardware físico, VMware on-premise o entornos de nube privada como AWS o Azure. Requisitos mínimos: CPU de 2 núcleos, 8 GB de RAM, 200 GB de almacenamiento. Para alta disponibilidad, se admite un clúster mínimo de 3 nodos con balanceo de carga HAProxy, con replicación maestro-esclavo entre nodos. En ningún momento salen datos de autenticación de su red: la validación de OTP, la gestión de usuarios y el registro de auditoría se realizan localmente. La implementación on-premise es adecuada para organizaciones sujetas a HIPAA, a los requisitos del entorno de datos de titulares de tarjetas de PCI DSS, a los marcos NIST 800-63B/FISMA, o a cualquier entorno donde los requisitos de aislamiento de red o residencia de datos limiten el uso de servicios de autenticación externos.
Conclusión
Cisco AnyConnect es un cliente VPN de acceso remoto fiable. Su seguridad en 2026 depende por completo de los controles de autenticación que el ASA o Firepower apliquen antes de conceder un túnel. La autenticación solo con contraseña en una puerta de enlace VPN expuesta a internet es un vector de acceso inicial documentado para los operadores de ransomware, y uno que escala de forma eficiente con herramientas automatizadas de prueba de credenciales.
La vía de integración RADIUS es técnicamente sencilla. El Protectimus RADIUS Server se instala en horas, la configuración AAA del ASA requiere un recorrido de diez minutos en ASDM, y el resultado es una autenticación de dos factores aplicada en Cisco AnyConnect para cada usuario y cada perfil de conexión, sin cambios en el cliente AnyConnect, en la configuración del túnel VPN ni en la infraestructura de directorio existente.
Decisiones clave antes de la implementación: nube o on-premise (lo determinan los requisitos de soberanía de datos y aislamiento de red), método de autenticación (app TOTP para la mayoría de los entornos, tokens hardware donde los dispositivos móviles están restringidos) y secuencia de despliegue (por fases, por perfil de conexión o grupo de usuarios, para gestionar la carga de registro y el impacto en el soporte).
Para organizaciones sujetas a PCI DSS, HIPAA, NIST 800-63B, o que operan en entornos con requisitos de aislamiento de red, la implementación on-premise es la opción arquitectónicamente adecuada. Para implementaciones empresariales estándar sin restricciones regulatorias de residencia de datos, la implementación en la nube ofrece un camino más rápido hacia la MFA aplicada en Cisco AnyConnect con menor sobrecarga operativa.
¿Listo para añadir MFA a su implementación de Cisco AnyConnect? Contacte con Protectimus para hablar sobre su entorno ASA o Firepower, confirmar la compatibilidad RADIUS con su infraestructura AAA existente y solicitar una demostración técnica.
