En enero de 2026, el FBI puso en marcha la Operación Winter SHIELD, y su primera medida recomendada dice: desplegar métodos resistentes al phishing, «llaves de seguridad conformes con FIDO2 o passkeys vinculadas al dispositivo», para la autenticación, el acceso remoto y los sistemas críticos (FBI). La guía de implementación de NIS2 de ENISA dice lo mismo para las VPN y los sistemas de administración: «siempre que sea posible, utilice MFA resistente al phishing» (ENISA, junio de 2025). La propia documentación de Microsoft describe ahora el MFA por SMS y por aplicación de autenticación como «propenso a ataques de phishing remotos» (“prone to remote phishing attacks”) (Microsoft).
Si su acceso remoto es un concentrador VPN que comprueba los inicios de sesión por RADIUS, probablemente ya habrá notado el problema: no hay ningún sitio donde enchufar una passkey. Esta entrada explica por qué es así, cuáles son las tres opciones realistas y contra qué no protege cada una de ellas.
Qué hace realmente una passkey
Una passkey es una credencial WebAuthn: un par de claves generado en el dispositivo del usuario y registrado para un sitio web concreto. Cuando el usuario inicia sesión, el navegador pide al dispositivo que firme un desafío enviado por el sitio, y la firma cubre el origen de la página que el navegador está mostrando realmente. El sitio comprueba que el origen incluido en la firma es el suyo. Una página de inicio de sesión falsa en otro dominio obtiene una firma para el origen equivocado, y el sitio real la rechaza. El usuario no tiene que fijarse en nada, porque la comprobación la hace el navegador (W3C WebAuthn).
Eso es lo que las normas entienden por resistente al phishing. La definición vigente del NIST es «la capacidad del protocolo de autenticación para impedir la divulgación de secretos de autenticación … sin depender de la vigilancia del solicitante» (“without relying on the vigilance of the claimant”), y es explícita sobre qué no supera la prueba: las contraseñas, los códigos de un solo uso, las aprobaciones push y todo aquello que el usuario tenga que teclear son «no resistentes al phishing» (NIST SP 800-63B-4, 2025). La CISA ordena los métodos del mismo modo: FIDO/WebAuthn y PKI en lo más alto, después los códigos de un solo uso y el push con coincidencia de números (number matching), después el push sin ella y, por último, el SMS (CISA).
Dos aspectos de cómo una passkey cumple esa definición importan para una VPN. La protección procede de un navegador o cliente de plataforma que sabe con qué origen está hablando, y de un desafío y una firma que viajan dentro del propio protocolo de inicio de sesión.
Por qué una VPN con RADIUS no tiene dónde ponerla
RADIUS, el protocolo que la mayoría de las pasarelas VPN usan para preguntar a un servidor de autenticación «¿es válido este inicio de sesión?», se diseñó para módems de acceso telefónico. Un Access-Request lleva un nombre de usuario y una contraseña oculta con un flujo de clave MD5, o una respuesta CHAP. Si el servidor quiere algo más, envía un Access-Challenge cuyo texto la pasarela «PUEDE mostrar» (“MAY display”) al usuario, que entonces teclea una respuesta que vuelve en el campo de la contraseña (RFC 2865). Ese es todo el vocabulario: cadenas que ha escrito una persona. No hay ningún campo para una aserción WebAuthn firmada, ningún origen sobre el que firmar porque un cliente VPN no tiene página, y ningún agente de usuario que lo haga cumplir.
Así que, por sí solos, ninguno de estos productos puede ofrecer passkeys para el inicio de sesión en la VPN:
- MikroTik RouterOS: solo cliente RADIUS, sin SAML ni OIDC (documentación de MikroTik).
- WireGuard: autentica a los pares mediante claves públicas estáticas y no tiene ningún inicio de sesión de usuario, así que ninguna de las opciones de abajo le es aplicable; allí el problema es la distribución de claves (wireguard.com).
- OpenVPN Access Server: con RADIUS, LDAP o PAM el segundo factor es un código basado en el tiempo, y solo su modo SAML puede delegar el inicio de sesión en un navegador (documentación de OpenVPN).
FortiGate, Palo Alto GlobalProtect y Cisco Secure Client sí ofrecen passkeys en el inicio de sesión de la VPN, y los tres lo hacen de la misma manera: el cliente VPN abre un navegador, el navegador inicia sesión en un proveedor de identidad SAML, la passkey se usa allí y el IdP comunica a la pasarela que el usuario es válido. FortiClient lo hace con la opción «external browser as user agent» (navegador externo como agente de usuario), Cisco ASA 9.17 y posteriores lanzan el navegador del sistema precisamente por este motivo, y GlobalProtect incrusta una vista de navegador en el cliente (Fortinet, Duo para Cisco ASA, Palo Alto). La propia vía RADIUS de Microsoft lo dice sin rodeos: la extensión NPS no puede hacer coincidencia de números, y MS-CHAPv2 no puede transportar un código basado en el tiempo (Microsoft).
La passkey nunca toca RADIUS. El trabajo lo hace el navegador, y la pasarela se fía de la palabra del IdP.
Las tres opciones realistas
1. Poner un proveedor de identidad SAML delante de la VPN y usar passkeys allí
Esta vía ofrece resistencia al phishing en sentido estricto para los inicios de sesión de los usuarios en la VPN y, si su pasarela y sus clientes la admiten, es la respuesta correcta para la parte del problema que pasa por el navegador.
Lo que cuesta: un proveedor de identidad que admita passkeys y la licencia que lo acompaña, versiones de cliente lo bastante recientes para SAML con navegador externo, un despliegue de passkeys a todos los usuarios de la VPN y un proceso de recuperación para los dispositivos perdidos. Lo que deja sin cubrir: todos los sistemas que no pueden hacer SAML, incluido el inicio de sesión de administrador del propio cortafuegos en muchos equipos, MikroTik, WireGuard y cualquier cosa que inicie sesión sin navegador.
2. Certificados
La autenticación con certificado de cliente (EAP-TLS en la VPN, o certificados de máquina en el dispositivo) es el otro método que el NIST considera resistente al phishing, mediante lo que denomina vinculación de canal (channel binding) (NIST). No hay nada que el usuario tenga que teclear ni nada que retransmitir.
Lo que cuesta: una autoridad de certificación, el alta de cada dispositivo, una renovación y una revocación que funcionen de verdad, y alguien que se haga cargo de todo ello. La CISA describe el MFA basado en PKI como un método que exige «prácticas de gestión de identidades muy maduras» y señala que no cuenta con un soporte amplio (CISA). Y un certificado de máquina demuestra qué dispositivo se conectó, no quién estaba sentado delante.
3. Mantener RADIUS y añadir una aprobación en el teléfono que muestre el inicio de sesión
La tercera vía deja la pasarela y el servidor RADIUS exactamente como están y añade un segundo paso en la ruta RADIUS: su servidor RADIUS comprueba primero la contraseña y, solo cuando acepta el inicio de sesión, el usuario recibe una solicitud de aprobación en su teléfono. La solicitud indica el servicio, la cuenta y la dirección IP de origen, y el inicio de sesión solo prospera si el usuario la aprueba. Esto es lo que hace el auth-proxy de Notakey; la guía de configuración lo recorre paso a paso para FreeRADIUS, NPS y el User Manager de MikroTik.
Es la vía más barata de desplegar, porque en la pasarela no cambia nada salvo el destino al que envía RADIUS, y funciona en cualquier pasarela que compruebe los inicios de sesión por RADIUS, incluidas las que nunca hablarán SAML. Es también la vía que más cuidado exige al describirla.
Lo que detiene. Una contraseña filtrada, rociada o crackeada ya no es un inicio de sesión. FortiBleed, la campaña de 2026 contra las VPN de FortiGate, no necesitó más que eso (nuestro análisis). La interceptación de SMS y el SIM swap no son aplicables, porque no hay código. El push-bombing metió a los atacantes en las VPN de Cisco y Uber en 2022: enviaron avisos de aprobación hasta que alguien tocó «sí» (Cisco Talos, Uber). Aquí se topa con una tarjeta que muestra qué cuenta está iniciando sesión en qué servicio y desde dónde, y con un limitador de frecuencia en el servidor (cómo).
Lo que no detiene. No detiene una retransmisión en tiempo real, en la que un portal VPN falso reenvía el inicio de sesión real de la víctima y la víctima aprueba su propia sesión en la conexión del atacante. La tarjeta de aprobación muestra la dirección IP de origen, así que la retransmisión es visible para un usuario que se fije, pero la protección depende de que el usuario se fije, y la definición del NIST excluye exactamente ese tipo de dependencia. La aprobación push no es resistente al phishing en el sentido de la CISA, con o sin coincidencia de números, y así lo decimos en nuestra página de seguridad en lugar de apropiarnos de la etiqueta.
Cómo fueron realmente las brechas
Conviene contrastar las opciones con la forma en que realmente se vulneraron las VPN y los accesos remotos, y no con un modelo de amenazas.
| Incidente | Cómo entró el atacante | Qué opción lo habría detenido |
|---|---|---|
| Colonial Pipeline, 2021 | Una cuenta VPN heredada con contraseña y sin segundo factor (testimonio) | Cualquiera de las tres |
| Change Healthcare, 2024 | Un portal de acceso remoto Citrix sin MFA (testimonio) | Cualquiera de las tres |
| FortiBleed, 2026 | Contraseñas de FortiGate rociadas, filtradas y crackeadas (FBI/USSS) | Cualquiera de las tres |
| Cisco, Uber, 2022 | Contraseña robada y, después, avisos push hasta que uno fue aceptado | Passkeys, certificados; una aprobación legible muestra el aviso que nadie inició |
| Scattered Spider, 2023 | Páginas de SSO falsas, SIM swaps y push-bombing contra VPN y correo web (CISA AA23-320A) | Passkeys y certificados, por completo; la aprobación hace visible la retransmisión |
| 0ktapus, 2022 | Páginas de Okta falsas que retransmitían contraseñas y códigos de un solo uso en tiempo real (Cloudflare) | Solo passkeys y certificados |
En tres de los seis no hizo falta esquivar ningún MFA: no había MFA. La lectura honesta de la tabla es que la mayor parte del daño se sigue produciendo en el salto entre «solo contraseña» y «cualquier segundo factor», y que la diferencia entre una aprobación legible y una passkey importa sobre todo para las cuentas que un atacante decidido retransmitirá en tiempo real.
Cómo decidir
- Cuentas de administrador del cortafuegos y de la pasarela. Son las cuentas a las que apuntó FortiBleed, y las que Winter SHIELD dice que hay que priorizar. Si la interfaz de administración admite llaves FIDO2 o un inicio de sesión SAML con passkeys, úselos. Si solo habla RADIUS, una aprobación en el teléfono en el inicio de sesión del administrador es mucho mejor que una contraseña sola, y sobre todo mejor que una compartida.
- VPN de usuarios en una pasarela capaz de hacer SAML con navegador externo. Ponga las passkeys en el proveedor de identidad. Es la respuesta estricta, y hoy está disponible en FortiGate, GlobalProtect y Cisco.
- VPN de usuarios en equipos que solo hablan RADIUS, como MikroTik o concentradores heredados. La elección está entre certificados y una aprobación en el teléfono. Los certificados ganan en resistencia al phishing si ya opera una PKI. Si no, una aprobación legible hace que una contraseña sola deje de ser un inicio de sesión y sustituye hoy mismo los códigos SMS y los avisos push a ciegas, y más adelante podrá seguir trasladando a passkeys los inicios de sesión que pasan por el navegador.
- Elija lo que elija, mire la ruta completa. La intrusión en Cisco de 2022 empezó con una cuenta personal de Google que sincronizaba una contraseña de trabajo; la VPN fue el segundo paso. Poner MFA en la VPN y no en el correo web o el escritorio remoto solo desplaza al atacante a la puerta de al lado.
Notakey cubre la tercera vía, y decimos con claridad qué lugar ocupa en la escala de la CISA. Si su pasarela habla RADIUS, la guía de 2FA para VPN le lleva a una primera aprobación en el teléfono en una tarde, y el appliance se ejecuta en su propia infraestructura o en nuestra nube. Pruebe la demo en vivo para ver cómo es una aprobación legible en su propio teléfono, o solicite una demostración y le propondremos un piloto que cubra sus inicios de sesión de VPN, de administración del cortafuegos y de escritorio remoto.