Hace unas semanas, mi compañero [Sergio Escarpa] explicaba en este mismo blog cuándo tiene sentido dar el paso de la VPN tradicional a ZTNA, y cuándo no. Dando por buena esa decisión, toca adentrarse en el lanzamiento y ejecución en sí mismos. Supongamos que ya está tomada, que el comité de dirección ha dicho que sí y que el presupuesto está aprobado. Lo que viene ahora es la parte que rara vez aparece en la diapositiva del kickoff: lo que sucede entre el “se migra” y el “ya está en producción”.
Y, para aportar perspectiva, un dato: en 2023, Gartner estimaba que menos del 1% de las grandes organizaciones tenía un programa Zero Trust maduro y medible, y preveía que la cifra subiría al 10% en 2026. Estamos en 2026, y la brecha sigue ahí: un informe reciente cifra en un 82% las organizaciones que consideran el Zero Trust esencial, pero solo un 17% lo ha implementado por completo. Entre el “se considera prioritario” y el “está en producción de extremo a extremo” se cuela una lista de problemas que se repiten proyecto tras proyecto. Vale la pena enumerarlos.
El problema casi nunca es la tecnología
Hay una observación recurrente entre quienes analizan estos despliegues, principalmente proveedores de SASE y firmas de análisis del sector, y es que buena parte de los proyectos ZTNA tiene muchos problemas para pasar del piloto. Y no suele ser por la tecnología, sino por el rollout. Cuando uno lo mira de cerca, el patrón se repite.
Empieza con el alcance. “Zero Trust en todo, en todas partes.” Suena bien en una presentación, pero luego aparece la realidad: las unidades de negocio se resisten a las nuevas restricciones, el equipo de seguridad recibe quejas por la experiencia de usuario, y surgen huecos de integración entre herramientas que ya estaban instaladas. El impulso se enfría. Y el riesgo que se quería reducir sigue exactamente donde estaba.
Zero Trust es tanto cultura y proceso como tecnología. Adoptarlo de verdad obliga a romper silos entre IT y seguridad, a reeducar a los usuarios y a rediseñar flujos de trabajo. No es un mero despliegue, es un viaje continuo, de afinado y ajuste permanente.
Otro factor percibido cuando se abordan estas arquitecturas es que casi nadie parte de cero. En un escenario greenfield se puede construir todo con mentalidad Zero Trust desde el primer día, limpio. Pero la inmensa mayoría de los clientes vive en brownfield: infraestructuras de años, a veces décadas, diseñadas sin ningún principio Zero Trust, arrastrando confianza implícita, sistemas legacy y vulnerabilidades heredadas. Meter ZTNA ahí se parece más a cirugía sobre un paciente despierto que a construir de cero.
Cuatro retos que sí tienen respuesta
Los puntos donde encallan los proyectos están bastante bien identificados, y todos tienen una salida contrastada, siendo estos los cuatro que más suelen aparecer:
- El dispositivo que no se controla. ZTNA funciona de maravilla con equipos corporativos, gestionados y con agente: control, verificación de postura, políticas según contexto. El modelo se rompe en cuanto se sale de ese jardín vallado. BYOD, IoT, dispositivos de terceros, proveedores… a menudo sin agente, sin MDM y con visibilidad casi nula. La respuesta madura no es “obligar a todos a poner un agente”, sino unificar en lugar de reemplazar: integrar los principios Zero Trust con los controles que ya están en funcionamiento (como NACs, firewalls, etc.) en vez de tirarlos a la basura. Es lo que se ha venido a llamar Universal ZTNA, y la palabra clave es unificar.
- La latencia, o cómo los usuarios sabotean la seguridad. Si se enruta el tráfico de forma que la experiencia se degrada, los usuarios buscarán la forma de saltarse el control. Es algo que casi siempre se observa. La seguridad que molesta se elude, no se cumple. Por eso el diseño de la ruta del tráfico, es decir, dónde se inspecciona y dónde está el punto de presencia más cercano, no es un detalle arquitectónico: es lo que determina si el despliegue sobrevive al primer mes o muere por abandono de los propios usuarios.
- La dependencia de proveedor. Adoptar un SASE completo casi siempre implica casarse con un único fabricante para funciones críticas: red y seguridad en la misma mano. Eso implica comodidad, pero hay que evaluar con frialdad su fiabilidad y su longevidad, y tener un plan B para el día que haya una caída global, porque es cuestión de cuándo y no de si se producirá o no.
- La cohabitación. Probablemente el reto más práctico y el que más se subestima. Durante meses convivirán la VPN antigua y el ZTNA nuevo, y ese periodo es precisamente cuando se abren grietas involuntarias. La receta es la misma que en casi todo lo que funciona: por fases. Un piloto en un perímetro reducido antes de generalizar, no un despliegue explosivo tipo big bang.
Y un último apunte, especialmente relevante para quien trabaja con el sector público español: nada de esto es ajeno al Esquema Nacional de Seguridad. El ENS ya contempla el control de acceso y la gestión de privilegios como medidas obligatorias en las categorías Media y Alta, y el propio CCN recomienda abordar Zero Trust de forma gradual, por fases. Dicho de otro modo: un despliegue ZTNA bien secuenciado no es solo buena ingeniería; es camino andado hacia la conformidad. Y no todo son obstáculos, porque el modelo también trae ventajas que antes eran directamente imposibles.
Lo que el SASE aporta y la VPN nunca pudo dar
Las ventajas de ZTNA frente a la VPN tradicional ya quedaron bien repasadas en el artículo anterior, y no vamos a repetirlas aquí. Pero hay una que merece párrafo propio, porque ha ganado peso desde entonces y conecta con uno de los riesgos más percibidos a día de hoy: la IA.
Cuando todo el tráfico pasa por una capa de inspección con identidad y contexto, se gana algo que con la VPN clásica era impensable: visibilidad y control sobre a qué servicios de IA acceden los usuarios y qué meten en ellos. Un SASE moderno puede aplicar detección de prompts, clasificación de temas y guardarraíles de acceso para gobernar cómo los empleados usan la IA generativa, e impedir que datos sensibles acaben en un servicio de IA público cualquiera, sin pasar ningún control.
Y no es un tema menor: IBM calculó que los incidentes de shadow AI añadieron unos 670.000 dólares al coste medio de una brecha. Cada vez que alguien pega un fragmento de código propietario o datos de cliente en un chatbot público, esa exposición ya ha ocurrido. La VPN no veía nada de eso: su trabajo era abrir un túnel y mirar para otro lado. El modelo Zero Trust, bien planteado, sí lo ve, y poder verlo es el primer paso para poder gobernarlo.
Bajando a tierra: Zero Trust en nuestra propia casa
Para abrir un poco el foco, es interesante destacar el despliegue de ZTNA en nuestra propia infraestructura casera, porque el mismo principio que a una empresa le cuesta millones y meses, un particular lo puede levantar en una tarde. Y, muchas veces, entenderlo “en pequeño” ayuda a entenderlo en grande.
Un ejemplo claro de esta aproximación es Tailscale. Aunque, antes de presentar la solución, conviene aclarar algo, porque es habitual ver ambos nombres comparados como si fueran alternativas: Tailscale y WireGuard no compiten entre sí. WireGuard es el protocolo de transporte, el túnel cifrado. Tailscale es lo que WireGuard deja fuera: el intercambio de claves, el descubrimiento de pares, el atravesar NATs. Dicho de otro modo, separa el plano de control del plano de datos. Los paquetes viajan directos entre dispositivos, cifrados de extremo a extremo; lo que se centraliza es solo la identidad, las claves y la política. Nada del tráfico real pasa por sus servidores.
¿Para qué sirve en casa? Imaginemos un servicio web ligero en nuestra LAN: una fototeca, una colección de libros, un panel de notas. Con Tailscale se puede llegar a él desde el móvil, estemos donde estemos, sin abrir un solo puerto del router. Y esa es la gran ventaja: desaparece el concentrador VPN expuesto a internet, ese OpenVPN que había que mantener parcheado al día y vigilar como un punto de entrada más. El servicio propio (la fototeca, los libros) seguimos manteniéndolo nosotros, claro; pero la puerta de acceso deja de ser una superficie de ataque abierta al mundo.
Lo interesante no es el “cómo”, sino el “qué” demuestra. Se puede definir que nuestro teléfono llegue a la fototeca pero no al panel de administración del router. Que el portátil de trabajo vea el entorno de desarrollo pero no nuestras cosas personales. Cada dispositivo, el acceso mínimo imprescindible. Eso es ZTNA. No la versión de folleto comercial, sino el principio de mínimo privilegio aplicado, de verdad, a nuestra LAN.
Y, por último, para aquellos a quienes les incomode que el plano de control sea propietario y esté alojado fuera, algo muy legítimo en entornos de alta seguridad, existe Headscale, una reimplementación open source de ese plano que se puede autoalojar. Control total, en nuestro propio hardware.
La moraleja, si es que hay una: Zero Trust no es un interruptor que se enciende el día de la puesta en producción. Es un dial que se va girando: se empieza con un alcance pequeño, se demuestra valor, se genera confianza interna, y se va ampliando. Los proyectos que llegan a buen puerto suelen compartir ese planteamiento; los que lo abordan como un despliegue cerrado, con fecha de fin, tienden a engrosar esa brecha entre el “se considera prioritario” y el “está en producción” con la que se abría el artículo. La buena noticia es que los obstáculos están identificados y las soluciones, contrastadas. Solo hay que asumir desde el principio que esto es una forma de operar, no un proyecto que se entrega. el principio que esto es una forma de operar, no un proyecto que se entrega.
Jose Ignacio Siles. Cybersecurity Architecture Team Manager, en Babel.