Qué es Zero Trust: arquitectura, principios e implementación práctica

Zero Trust es un modelo de seguridad que elimina la confianza implícita basada en la ubicación de red y exige verificación continua de cada acceso a recursos, independientemente de si la petición procede del interior o del exterior del perímetro corporativo. La publicación de referencia es NIST SP 800-207 (Zero Trust Architecture), complementada por el CISA Zero Trust Maturity Model v2 y los trabajos previos de Google (BeyondCorp) y Forrester (modelo original de John Kindervag, 2010). La premisa central se resume en la frase never trust, always verify: ningún usuario, dispositivo, aplicación o flujo de tráfico recibe acceso por el simple hecho de encontrarse dentro de un segmento "interno".

Lo esencial sobre Zero Trust

• Es una estrategia de arquitectura, no un producto que se compra empaquetado.
• Sustituye el perímetro de red por políticas dinámicas por sesión basadas en identidad, dispositivo y contexto.
• Se apoya en componentes existentes (IdP, MFA, EDR, microsegmentación, SIEM) coordinados por un policy engine central.
• La implementación realista es gradual, en 12 a 18 meses, priorizando identidad y dispositivo antes que aplicación y datos.
• Encaja con NIS2 artículo 21, ENS Real Decreto 311/2022, DORA capítulo II e ISO 27001:2022, cubriendo controles de acceso, segmentación y monitorización continua.

Por qué el perímetro tradicional dejó de funcionar

Durante dos décadas la seguridad corporativa se basó en una idea geográfica: dentro del firewall todo es de confianza, fuera todo es hostil. La realidad actual ha desmontado las cuatro asunciones que sostenían el perímetro.

La nube ha diluido el centro de datos. Los datos críticos viven en SaaS (Microsoft 365, Salesforce, Workday) y en IaaS (AWS, Azure, GCP) que no controlas a nivel de red. La movilidad y el BYOD han llevado a que los dispositivos legítimos se conecten desde redes domésticas, cafeterías o redes 5G que escapan al control corporativo. Las cadenas de suministro de software introducen código de terceros en tu núcleo. Y el lateral movement post-breach se ha convertido en la norma: una vez dentro, un atacante recorre la red interna porque toda la red era de confianza por defecto.

Zero Trust responde con un enfoque coherente: deja de definir la seguridad por dónde está el recurso y empieza a definirla por quién accede, con qué dispositivo, a qué recurso concreto y en qué contexto.

Los principios de Zero Trust según NIST 800-207

NIST SP 800-207 enumera siete principios ("tenets") que toda arquitectura Zero Trust debe respetar. No son opcionales y no se cumplen "casi": cada uno tiene implicaciones concretas en el diseño.

1. Toda fuente de datos y servicio de cómputo se considera un recurso. En Zero Trust, una impresora corporativa, un repositorio de código, un endpoint IoT o una función serverless son recursos con su propia política de acceso. Ejemplo práctico: una cámara IP de sala de reuniones tiene una política que solo permite tráfico saliente a su gestor en la nube y deniega cualquier conexión entrante desde la red interna.

2. Toda comunicación está cifrada y autenticada con independencia del segmento de red. No se asume que el tráfico interno sea seguro. mTLS entre microservicios, TLS 1.3 en el tráfico cliente-servidor y firma de tokens en cada llamada API son la norma, incluso en redes "privadas".

3. El acceso a recursos se concede por sesión. Un usuario que se autentica para acceder al correo no obtiene automáticamente acceso al ERP. Cada recurso requiere su propia evaluación. Esto rompe con la VPN clásica que tras la autenticación deja al usuario en una red plana.

4. El acceso se determina por una política dinámica. La política combina identidad del sujeto, estado del dispositivo (parches, EDR activo, disco cifrado), atributos del recurso (clasificación del dato), contexto (hora, ubicación, anomalías) y señales externas (threat intelligence). Ejemplo: un usuario con MFA pero con portátil sin parches recientes solo accede a aplicaciones de bajo riesgo.

5. La empresa monitoriza y mide el estado de integridad y postura de seguridad de todos los activos. Si el dispositivo cambia de estado durante la sesión (se desactiva el EDR, se conecta a una red sospechosa), la política reevalúa y puede revocar el acceso.

6. La autenticación y autorización de todos los recursos son estrictas y se aplican antes de permitir el acceso. MFA resistente a phishing (FIDO2, claves físicas), validación de tokens en cada hop, comprobación de scopes OAuth en cada llamada.

7. La empresa recopila la máxima información posible sobre el estado actual de los activos, la infraestructura de red y las comunicaciones, y la utiliza para mejorar la postura de seguridad. Telemetría continua hacia SIEM y UEBA. La detección no es un módulo añadido, es el combustible que alimenta el policy engine.

Componentes de la arquitectura Zero Trust

NIST define un núcleo lógico de tres componentes que toda implementación Zero Trust orquesta, más una serie de subsistemas de soporte que aportan las señales necesarias para tomar decisiones.

Núcleo de decisión: PE, PA, PEP

• Policy Engine (PE): el cerebro. Recibe la petición, evalúa la política contra todas las señales disponibles (identidad, dispositivo, riesgo, contexto) y emite una decisión de conceder, denegar o exigir paso adicional.
• Policy Administrator (PA): el ejecutor. Traduce la decisión del PE en una sesión concreta (genera tokens, configura túneles, programa reglas en el PEP).
• Policy Enforcement Point (PEP): el punto donde la política se materializa frente al tráfico real. Puede ser un proxy ZTNA, un sidecar de microservicio, un agente en el endpoint, un broker de identidad o una combinación.

Subsistemas de soporte

• Identity Provider (IdP) con MFA y autenticación adaptativa: la identidad es el primer plano de control. Sin un IdP fuerte (Entra ID, Okta, Ping, Auth0, Keycloak) y MFA resistente a phishing, el resto del modelo se cae.
• Device trust y posture: MDM (Intune, Jamf, Kandji), EDR (CrowdStrike, SentinelOne, Microsoft Defender, ESET) y agentes de cumplimiento que emiten señales en tiempo real sobre el estado del dispositivo.
• Microsegmentación: a nivel de red (VLAN, SDN), de workload (políticas L7 entre cargas) y de aplicación (mTLS entre servicios). Reduce el blast radius cuando algo se compromete.
• SASE / SSE: convergencia de capacidades de red y seguridad en una plataforma cloud. SASE añade SD-WAN, SSE es el subconjunto enfocado a seguridad (SWG, CASB, ZTNA, DLP, FWaaS).
• Continuous monitoring: SIEM (Splunk, Sentinel, Elastic, Wazuh) y UEBA para detección de anomalías de comportamiento. Alimenta de vuelta al policy engine.
• Data security: clasificación, DLP, cifrado y gestión de claves. Sin saber qué datos tienes, no puedes proteger los recursos correctos.

ZTNA vs VPN tradicional

ZTNA (Zero Trust Network Access) es el componente que en muchas organizaciones reemplaza progresivamente a la VPN como puerta de entrada al acceso remoto. La diferencia no es cosmética.

Cuándo migrar de VPN a ZTNA: cuando la mayor parte del acceso es a aplicaciones web o APIs, cuando se quiere reducir el blast radius del acceso de contratistas, cuando se aborda un proyecto SASE/SSE.

Cuándo coexistir: aplicaciones legacy que requieren protocolos no encapsulables (algunos clientes de bases de datos pesados, sistemas industriales con protocolos de tiempo real), administración de bajo nivel de infraestructura on-premise, fases iniciales de migración donde no todo está listo para publicar vía ZTNA.

Fases de implementación realista (12-18 meses)

Una de las trampas más habituales es intentar abordar Zero Trust como un proyecto monolítico. La implementación realista es gradual, por dominios de control, y prioriza ganancias rápidas.

Fase 0: línea base (semanas 1 a 4)

Inventario actualizado de usuarios, dispositivos, aplicaciones y flujos de datos. Mapa de identidades privilegiadas. Diagnóstico contra el CISA Zero Trust Maturity Model. Definición del estado objetivo a 12 y 24 meses. Sin esto, cualquier decisión técnica se construye sobre suposiciones.

Fase 1: identidad (meses 1 a 4)

Es la fase de mayor retorno. Consolidación en un IdP único, despliegue de MFA resistente a phishing (FIDO2) en todos los accesos, eliminación de cuentas compartidas, separación de cuentas privilegiadas, autenticación adaptativa basada en riesgo, integración SSO de las aplicaciones SaaS clave. Quick win habitual: bloquear los protocolos de autenticación legacy en Microsoft 365.

Fase 2: dispositivo (meses 3 a 6)

Inscripción de todos los endpoints en MDM, despliegue de EDR moderno, definición de device posture (cifrado de disco, parches, EDR activo, no jailbreak). Integración de la señal de postura en el IdP para condicionar accesos. Trampa habitual: olvidar dispositivos no corporativos (BYOD de directivos, contratistas) que terminan siendo el agujero.

Fase 3: aplicación (meses 5 a 10)

Publicación de aplicaciones internas mediante ZTNA en lugar de VPN. SSO obligatorio para SaaS. Revisión de permisos OAuth concedidos a aplicaciones de terceros. Inicio de la microsegmentación entre workloads críticos. Quick win: jubilar la VPN para el 70 por ciento de los casos de uso, dejando un nicho residual.

Fase 4: dato (meses 8 a 14)

Clasificación de datos críticos. DLP en correo, endpoints y SaaS. Cifrado de datos en reposo con gestión de claves controlada. Etiquetado de información (Microsoft Purview, equivalentes) integrado con políticas de acceso. Es la fase más larga porque exige descubrir qué información sensible existe realmente.

Fase 5: monitorización y respuesta (continua, intensifica meses 10 a 18)

SIEM con casos de uso específicos Zero Trust (accesos fuera de patrón, escalada de privilegios, anomalías de postura). UEBA. Integración con SOAR para respuestas automatizadas (revocación de sesión, aislamiento de endpoint). Ejercicios de purple team para validar la detección.

Trampas comunes: tratar Zero Trust como proyecto de un solo equipo (es transversal), comprar un producto "Zero Trust" sin haber hecho la fase 0, ignorar el cambio cultural (los usuarios verán más fricción inicial), olvidar las aplicaciones legacy en la planificación.

Casos de uso de alto ROI

No todas las iniciativas Zero Trust generan retorno igual. Estos son los casos donde el coste-beneficio es más claro a corto plazo.

Acceso remoto de contratistas y terceros. Es el caso con mayor retorno típico. Publicar aplicaciones específicas vía ZTNA en lugar de dar VPN a cada contratista reduce drásticamente la superficie y simplifica la rotación. Auditable por sesión.

Protección de crown jewels (PII, propiedad intelectual, datos regulados). Aislar las aplicaciones que tratan datos críticos detrás de políticas Zero Trust estrictas, con MFA reforzada, restricciones por dispositivo gestionado y registro detallado. Es además un argumento defendible ante DPO y reguladores.

Reducción de superficie post-M&A. Tras una fusión o adquisición, integrar las redes es lento y arriesgado. Publicar las aplicaciones clave de la entidad adquirida vía ZTNA permite acceso controlado desde el día uno sin abrir túneles de red entre las dos organizaciones.

Cumplimiento NIS2 y ENS. Ambas normativas exigen control de acceso, segmentación y monitorización continua. Zero Trust no es una mención literal en el articulado, pero los controles que pide encajan directamente con la arquitectura.

Encaje con NIS2, ENS, DORA, ISO 27001

Zero Trust no es un requisito normativo nominal, pero los controles que materializa son los que las principales normativas europeas y estándares internacionales exigen.

Para preparación de auditoría, consulta la guía paso a paso de auditoría NIS2 y la guía completa de ISO 27001.

Vendor landscape 2026

El ecosistema Zero Trust en 2026 está poblado por proveedores que cubren ángulos distintos. Esta sección describe capacidades técnicas sin endorsar comercialmente: la elección depende del punto de partida, del stack existente y de las prioridades.

• Zscaler ZPA: pionero en ZTNA puro, foco en publicación de aplicaciones y SSE de gran escala.
• Palo Alto Prisma Access: SASE completo con NGFW heredado del fabricante. Tracción en organizaciones que ya operan Palo Alto en perímetro.
• Cloudflare Zero Trust: red global propia, ZTNA, SWG, CASB y protección de aplicaciones públicas integradas. Curva rápida, fuerte en cloud-first.
• Microsoft Entra + Entra Internet Access / Private Access: ventaja de integración nativa para entornos Microsoft 365.
• Cisco Duo: foco en MFA y device trust, pieza de identidad que muchas organizaciones añaden primero.
• Okta: IdP independiente con ecosistema amplio. Habitual en organizaciones SaaS-first.
• JumpCloud: directorio cloud para entornos mixtos, atractivo para pymes que no quieren operar Active Directory.
• Twingate y Tailscale: ZTNA y mesh basados en WireGuard. Aproximación developer-friendly, despliegue rápido.

La regla práctica: empezar por identidad (IdP + MFA), añadir device trust, y solo después decidir el proveedor de ZTNA/SSE.

Métricas para medir madurez Zero Trust

La CISA Zero Trust Maturity Model v2 define cinco pilares (Identidad, Dispositivo, Red, Aplicación y Carga de Trabajo, Datos) con cuatro niveles de madurez por pilar: Traditional, Initial, Advanced, Optimal. Es el marco de referencia para autoevaluación y para defender el roadmap ante dirección.

KPIs operativos recomendados para reporting trimestral a comité de dirección:

• Porcentaje de cuentas con MFA resistente a phishing activado.
• Porcentaje de aplicaciones internas publicadas vía ZTNA frente a VPN.
• Porcentaje de cargas de trabajo críticas con microsegmentación L7 activa.
• Porcentaje de dispositivos corporativos con postura validada y EDR activo.
• MTTD (mean time to detect) y MTTR (mean time to respond) en incidentes de acceso.
• Porcentaje de accesos privilegiados auditados con grabación de sesión.

Preguntas frecuentes

¿Zero Trust es producto o estrategia?

Es una estrategia de arquitectura. Los productos (ZTNA, IdP, EDR, microsegmentación) son piezas que materializan la estrategia, pero ningún producto por sí solo entrega Zero Trust. Comprar una caja etiquetada como "Zero Trust" sin la fase 0 y sin alineación de procesos es un anti-patrón frecuente.

¿Hay que tirar la VPN para empezar?

No. La migración realista es de meses y la coexistencia VPN + ZTNA durante 12 a 18 meses es normal. La pregunta correcta es: ¿qué casos de uso puedo mover ya a ZTNA y cuáles seguirán necesitando VPN durante un tiempo? El objetivo intermedio razonable es jubilar la VPN para el 70 a 80 por ciento de los casos en la primera oleada.

¿Cuánto cuesta implementar Zero Trust?

Depende del punto de partida. Una organización con IdP moderno, MFA generalizado y EDR ya desplegado puede acometer Zero Trust con coste incremental moderado (licencias ZTNA, esfuerzo de proyecto). Una organización sin esas bases parte de coste mayor. La regla de oro: el grueso del gasto suele ir a personas y proyecto, no a licencias.

¿Una pyme puede hacer Zero Trust?

Sí. Las pymes parten incluso con ventaja: menos sistemas legacy, menos complejidad organizativa. Una pyme puede llegar a un nivel Initial-Advanced del modelo CISA en 6 a 9 meses combinando un IdP cloud con MFA, EDR en endpoints y un ZTNA ligero. Consulta también la guía de ciberseguridad para pymes.

¿Zero Trust elimina el firewall?

No. El firewall sigue siendo necesario para tráfico que no encaja en ZTNA (egreso a Internet, tráfico OT/IoT, segmentación de red base). Lo que cambia es su rol: deja de ser el control principal y pasa a ser un control de defensa en profundidad.

¿ZTNA es lo mismo que SASE?

No. ZTNA es un componente, SASE (Secure Access Service Edge) es la convergencia de varios servicios de red y seguridad en la nube (SD-WAN, ZTNA, SWG, CASB, FWaaS, DLP). SSE es el subconjunto de SASE centrado en seguridad. Una organización puede empezar con ZTNA puro sin comprometerse a un SASE completo.

¿Cuánto tarda ver retorno?

Los primeros retornos visibles aparecen en 3 a 6 meses con la fase de identidad: reducción de incidentes de phishing y compromiso de credenciales. El retorno completo en términos de reducción de blast radius y de superficie de ataque se consolida entre los meses 12 y 18, cuando ZTNA, microsegmentación y monitorización están maduros.

Recursos relacionados

• Auditoría de ciberseguridad para empresas: guía completa
• Auditoría NIS2 paso a paso
• ISO 27001 explicada: certificación, controles y proceso
• Qué es EDR: detección y respuesta en endpoints
• Qué es PKI: infraestructura de clave pública
• Qué es ingeniería social
• Qué es bastionado de redes y sistemas

Implementación Zero Trust con Secra

En Secra acompañamos a organizaciones B2B en el diseño y despliegue de arquitecturas Zero Trust con un enfoque pragmático y por fases. En 4 semanas entregamos un roadmap personalizado con:

• Assessment inicial contra CISA Zero Trust Maturity Model v2 sobre los cinco pilares, con identificación de nivel actual y nivel objetivo realista a 12 y 24 meses.
• Diseño de arquitectura de referencia adaptada a tu stack actual (Microsoft, Google, AWS, Azure, on-premise, híbrido) y a las restricciones operativas y regulatorias.
• Plan de implementación fase por fase con priorización por retorno, esfuerzo y dependencias, integrado con tus iniciativas existentes de NIS2, ENS o ISO 27001.
• Soporte de ejecución opcional para acompañar al equipo interno durante las fases más sensibles (identidad, microsegmentación, jubilación de VPN).

Si tu organización está evaluando un proyecto Zero Trust, una migración SASE/SSE o necesita estructurar el roadmap antes de hablar con proveedores, contacta con Secra y agendamos una sesión inicial sin compromiso.