Zero Trust: por qué confiar menos es una buena idea

Jan 7, 2026 | Categories: Arquitectura, Seguridad | Tags: Zero Trust, ZTNA, Arquitectura de seguridad, Identidad, Contexto, Acceso

Pasé varios años vendiendo e implementando soluciones de ZTNA. Mucho VMware, bastante Microsoft, algo de Fortinet. Buenos productos, sólidos, bien pensados, con buena ingeniería atrás. Lo difícil casi nunca fue la tecnología, fue explicar qué estábamos tratando de resolver.

Cada tanto me tocaba dar alguna charla sobre Zero Trust, o Arquitectura Zero Trust, o Zero Trust Network Architecture, dependiendo del público y del slide deck de turno. Si había suerte, después aparecía algún cliente diciendo que quería “implementar Zero Trust”, y yo le preguntaba entre otras cosas, qué problema estaba tratando de resolver. A veces la conversación se ponía interesante: acceso remoto, identidades, movimiento lateral, estrategia de seguridad. Bien. Otras veces la respuesta era un silencio incómodo, o algo como: “quiero implementar Zero Trust para estar seguro” y no mucho más que eso.

Zero Trust se volvió una casilla más para tildar en presentaciones de cumplimiento o de estrategias de ciberseguridad. Y los vendedores —me incluyo sin culpa— muchas veces no ayudamos. Lo vendimos como si fuera un appliance, con un discurso de “comprás esto, desplegás aquello, integrás con no sé qué, y listo”. He visto quienes con tres meses de proyecto, un par de migraciones dolorosas, te prometen que ya tenés Zero Trust. Como si fuera una certificación que te llega por correo electrónico.

La realidad es otra, Zero Trust no es algo que comprás. No es un producto, es una estrategia; una forma de pensar el acceso, la red y la seguridad de un sistema. Una forma bastante más desconfiada, por cierto.

Lo curioso es que la mayoría de las organizaciones ya tienen una buena parte de lo necesario para empezar. No lo llaman Zero Trust, no lo usan de forma coherente con esta arquitectura, pero está ahí: identidades, segmentación básica, logs, controles para los dispositivos, capacidad de cifrado, todos medio dormidos.

Este artículo no es una guía canónica ni un manual de “mejores prácticas”, no hay recetas universales. Es más un resumen de lo que fui aprendiendo viendo implementaciones que funcionaron, y otras que se quedaron por la mitad. Algunas con presupuestos obscenos, algunas con tecnología bien integrada de un solo proveedor, otras hechas con esfuerzo, paciencia y un stack tecnológico diverso. Y si tengo que resumir: el éxito casi nunca estuvo en “comprar la solución correcta”. Lo que funciona es entender tanto la arquitectura como el problema real, aprovechar al máximo la tecnología que se tiene, y recién ahí —cuando hace sentido— salir a comprar algo nuevo.

¿Qué es Zero Trust, sin el marketing?

Zero Trust se resume en tres ideas: nunca confíes por defecto, verificá siempre, y da el mínimo acceso necesario. Suena obvio cuando lo decís así, pero rompe con treinta años de diseño de redes.

El modelo tradicional es el del castillo y el foso. Construís un perímetro fuerte —firewall, VPN, DMZ para exponer servicios— y todo lo que está adentro es territorio confiable. Si pasaste la muralla, sos de los nuestros. Segmentás con VLANs, subredes, algunas ACLs entre zonas, pero la premisa de fondo no cambia: hay un “adentro” y un “afuera”, y el adentro es seguro.

El castillo y el foso

El problema con ese modelo no es que sea malo en sí mismo. Durante años funcionó razonablemente bien. El problema es que asume que existe un perímetro bien definido, que es hermético, y que los de adentro son de confianza. Y las tres cosas dejaron de ser ciertas hace rato. Los ataques modernos generalmente no fuerzan la puerta principal; roban credenciales, explotan una vulnerabilidad en un endpoint remoto, o simplemente esperan a que alguien haga click en el lugar equivocado. Y una vez adentro, con el modelo tradicional pueden moverse lateralmente sin mucha resistencia.

Zero Trust invierte la lógica. No hay “adentro” confiable. Cada acceso se valida: quién es el usuario, desde qué dispositivo se conecta, qué estado de seguridad tiene ese dispositivo, qué recurso está pidiendo, y si realmente necesita acceder a eso. El perímetro ya no es un firewall físico en un rack; es móvil, está en cada endpoint y alrededor de cada recurso.

Esto significa dejar de pensar en la “red interna segura” y empezar a pensar algo como “cada flujo de datos es sospechoso hasta que demuestre lo contrario”. Es incómodo, porque te obliga a desconfiar de cosas que antes dabas por sentadas —y a tener controles para ello—. Pero es necesario, porque en la época del multi-cloud y el trabajo remoto, las amenazas ya no respetan la frontera que dibujaste en el diagrama de red.

Los 5 pilares

Zero Trust no es una tecnología única. Es un modelo de seguridad que se sostiene sobre cinco pilares interdependientes. Cada uno protege un aspecto distinto del flujo de acceso, pero ninguno funciona aislado. La fortaleza está en cómo se integran.

Veamos uno a uno qué protegen, cómo funcionan a grandes rasgos, cómo interactúan con los demás pilares y algunos ejemplos de herramientas que aportan funcionalidades requeridas para cada pilar.

Los 5 pilares

Device Trust (el dispositivo como actor verificable)

Qué protege: Previene que dispositivos comprometidos, desactualizados o no autorizados accedan a recursos corporativos. Un usuario válido en un dispositivo no confiable sigue siendo un riesgo.

Cómo funciona: El dispositivo debe probar su identidad y estado de seguridad antes de permitir cualquier acceso. Esto se logra mediante:

  • Identificación única: Certificados de máquina que funcionan como “credenciales del dispositivo”. No es suficiente saber que “alguien” se conecta; necesitás saber desde qué dispositivo específico.
  • Posture checking (verificación de estado): Antes de autorizar acceso, el sistema valida que el dispositivo cumpla requisitos mínimos: antivirus activo, firewall habilitado, OS parcheado, sin jailbreak/root, disco cifrado, etc. Si algo falla, el acceso se deniega o se restringe.
  • Inventario y registro: Solo dispositivos explícitamente autorizados pueden intentar conectarse. BYOD sin registro no entra.

Integración con otros pilares:

  • Se combina con User Trust para validar no solo “quién eres” sino “desde dónde te conectás”. Credenciales robadas en un dispositivo no corporativo no alcanzan.
  • Alimenta a Application Trust: el gateway puede decidir dar acceso a apps menos críticas desde cualquier dispositivo corporativo o BYOD autorizado, pero restringir apps sensibles solo a dispositivos corporativos con compliance perfecto.
  • Los certificados del dispositivo se usan en Transport Trust para establecer conexiones mTLS (mutual TLS), donde ambos extremos validan identidad.

Qué herramientas lo implementan:

  • MDM/UEM: Intune, Workspace ONE, Jamf, FortiClient EMS
  • Certificados: PKI interna (Windows CA, OpenSSL), servicios cloud (Entra ID Certificate Authority)
  • Posture checking: Agentes de endpoint que reportan estado a un servidor central (Forticlient, WorkspaceONE, etc.)

User Trust (identidad humana verificable)

Qué protege: Previene acceso no autorizado basado en credenciales robadas, compartidas o comprometidas. La autenticación de un solo factor ya no es suficiente.

Cómo funciona: La identidad del usuario debe validarse con múltiples factores y, dependiendo del contexto, con mayor o menor fricción.

  • Multi-factor authentication (MFA): Algo que sabés (password) + algo que tenés (token, app en el móvil) + algo que sos (biometría). El segundo factor hace que robar credenciales no sea suficiente.
  • Autenticación basada en certificados: El usuario tiene un certificado digital personal. En combinación con password o MFA, esto suma otra capa. Además, los certificados pueden tener vigencia corta y renovarse automáticamente, reduciendo ventanas de exposición.
  • Passwordless (FIDO2, WebAuthn, Windows Hello): La evolución lógica de MFA es eliminar la contraseña completamente. Con FIDO2, el usuario autentica con biometría (huella, facial) o PIN local, y el dispositivo firma un challenge criptográfico que valida identidad sin enviar secretos por la red. No hay password que robar, phishear o reutilizar. Es más seguro y más cómodo que MFA tradicional. Windows Hello for Business, passkeys en iOS/Android, y hardware tokens como YubiKey implementan este estándar.
  • Autenticación contextual/adaptativa: No siempre pedís lo mismo. Si el usuario se conecta desde su dispositivo habitual, en horario laboral, desde la oficina, tal vez alcanza con passwordless. Si se conecta desde un país nuevo, a las 3 AM, desde un dispositivo desconocido, exigís passwordless + validación adicional de identidad (push notification con confirmación explícita, pregunta de seguridad).
  • Single Sign-On (SSO): Autenticás una vez (con MFA), y ese token de identidad te da acceso a múltiples aplicaciones sin volver a pedir credenciales. Esto reduce friction sin sacrificar seguridad, siempre que el flujo de autenticación inicial sea robusto.

Integración con otros pilares:

  • Device Trust + User Trust = contexto completo. No solo sabés quién es, sino desde dónde se conecta.
  • Application Trust: Las políticas de acceso pueden ser por usuario Y por grupo. “El equipo de Finanzas puede acceder al ERP, pero solo si están autenticados con MFA y desde dispositivos corporativos.”
  • Transport Trust: El token de identidad (SAML assertion, JWT) se valida en cada solicitud. Si el token expira o se invalida (usuario deshabilitado, cambio de permisos), el acceso se corta.

Qué herramientas lo implementan:

  • Directorios: Active Directory, Entra ID, Okta, Google Workspace, WorkspaceONE.
  • MFA: MFA de Entra ID, Duo, Google Authenticator, FortiToken, WorkspaceONE Verify hardware tokens (YubiKey)
  • SSO/Federation: SAML, OIDC, servicios como Okta, Entra ID, Workspace ONE Access

Transport/Session Trust (comunicación verificada continuamente)

Qué protege: Previene ataques de man-in-the-middle, secuestro de sesión, y movimiento lateral después de una autenticación inicial exitosa.

Cómo funciona: No alcanza con autenticar al principio y confiar en la sesión por horas. El transporte debe estar cifrado y la sesión debe revalidarse constantemente.

  • Cifrado robusto obligatorio (TLS 1.2+): Todo el tráfico entre usuario y aplicación debe ir cifrado. Nada en texto plano, ni siquiera en la red interna. Configurar correctamente cipher suites, deshabilitar versiones viejas de TLS, validar certificados.
  • Mutual TLS (mTLS): No solo el servidor presenta certificado; el cliente también. Esto asegura que ambos extremos de la conexión son quienes dicen ser. Común en arquitecturas de microservicios y comunicación entre sistemas.
  • Tiempos de sesión cortos: Una sesión autenticada no debe durar indefinidamente. Configurar TTL (time to live) razonable: 4-8 horas para usuarios comunes, menos para accesos administrativos. Esto limita la ventana de explotación si alguien roba un token de sesión.
  • Revalidación continua: Durante la sesión, validar periódicamente que el usuario y el dispositivo siguen cumpliendo las políticas. Si el dispositivo deja de cumplir compliance (antivirus se apaga, usuario deshabilitado en AD), la sesión se termina aunque no haya expirado el token.
  • Micro-segmentación: Controlar el tráfico entre recursos internos (east-west traffic), no solo el tráfico de entrada/salida (north-south). Cada VM, contenedor o workload tiene su propio perímetro de red. Las reglas de firewall se aplican por identidad (usuario, grupo AD, workload identity), no solo por IP. Esto previene movimiento lateral: si un atacante compromete un servidor web, no puede hablarle directamente a la base de datos a menos que exista una regla explícita que lo permita. Las políticas “viajan” con la carga de trabajo si se mueve de host o datacenter.

Integración con otros pilares:

  • Device Trust + User Trust: Los certificados de dispositivo y usuario se usan para establecer mTLS. Sin ellos, no hay conexión. En micro-segmentación con identity-based firewalls, estos mismos certificados o el contexto de autenticación permiten que el firewall distribuido sepa “este tráfico viene del usuario X en el grupo Y” y aplique reglas por identidad en lugar de solo por IP de origen/destino.
  • Application Trust: El gateway que publica la aplicación valida el token de sesión en cada request. Si el token es inválido o expiró, rechaza la conexión.
  • Data Trust: El cifrado del transporte protege la data mientras viaja por la red. Incluso si alguien intercepta el tráfico, no puede leerlo.

Qué herramientas lo implementan:

  • Proxies reversos: nginx, HAProxy, Traefik (con configuración TLS/mTLS)
  • Gateways ZTNA: FortiGate ZTNA, Zscaler, Cloudflare Access, Palo Alto Prisma
  • Micro-segmentación: VMware NSX, Cisco ACI, Illumio, Calico (en Kubernetes).
  • Session management: Manejado por IdP (Entra ID, Okta) con políticas de conditional access

Application Trust (acceso granular y principio de mínimo privilegio)

Qué protege: Previene movimiento lateral. Si un atacante compromete una cuenta, no debe poder acceder a todo, solo a lo estrictamente necesario para esa cuenta.

Cómo funciona: Cada aplicación o recurso debe tener políticas de acceso explícitas. No “si estás en la red, podés acceder a todo”, sino “tenés acceso solo a lo que necesitás para tu rol”.

  • Publicación selectiva de aplicaciones: En lugar de dar acceso VPN a toda la red, publicás aplicaciones individualmente. El usuario se conecta a “app.empresa.com”, no a “toda la subred 10.x.x.x”.
  • Políticas de acceso basadas en identidad y contexto: No alcanza con “el usuario X puede acceder”. Es “el usuario X, desde un dispositivo corporativo, con MFA, puede acceder a la app Y entre las 8 AM y 6 PM, desde estas ubicaciones geográficas”.
  • Application-level gateways: Un proxy o gateway delante de cada aplicación valida identidad, device compliance, y permisos antes de dejar pasar tráfico. Si algo falla, el tráfico no llega al backend.

Integración con otros pilares:

  • User Trust + Device Trust: El gateway valida ambos antes de permitir acceso. Usuario válido + dispositivo no corporativo = acceso denegado.
  • Transport Trust: La conexión entre usuario y gateway está cifrada, y el gateway re-valida tokens de sesión constantemente. Gracias a la micro-segmentación, a nivel de red el tránsito también está restringido, si un atacante evade el Gateway igualmente no puede establecer comunicación con un workload no autorizado.
  • Data Trust: Al limitar qué aplicaciones puede usar cada usuario, limitás también qué datos puede tocar. Si no podés acceder al ERP, no podés ver la información financiera que vive ahí.

Qué herramientas lo implementan:

  • ZTNA gateways: FortiGate ZTNA, Zscaler Private Access, Cloudflare Access
  • Proxies reversos: nginx, HAProxy con autenticación integrada
  • Identity-based firewalls: Palo Alto, FortiGate con integración AD, Azure Firewall con user identity, VMware NSX con Identity Firewall.

Data Trust (proteger la información, no solo el perímetro)

Qué protege: El dato en sí, independientemente de dónde esté. No importa si un atacante llega hasta el almacenamiento; si el dato está cifrado y no tiene las claves, no le sirve.

Cómo funciona: La información debe estar protegida en reposo y en tránsito, clasificada según criticidad, y con controles granulares sobre quién puede hacer qué con ella.

  • Cifrado en reposo: Discos cifrados en endpoints (BitLocker, FileVault), storage cifrado en servidores, bases de datos con TDE (Transparent Data Encryption). Si alguien roba un disco físico o hace snapshot de una VM, no puede leer la información.
  • Cifrado en tránsito: Ya cubierto en Transport Trust, pero vale remarcar: el dato nunca viaja en claro.
  • Clasificación de información: No todos los datos son iguales. Públicos, internos, confidenciales, restringidos. Cada nivel tiene controles diferentes. Esto implica proceso (entrenar a usuarios en cómo clasificar) y tecnología (metadatos en archivos, etiquetas en objetos de almacenamiento).
  • Permisos granulares: Principio de mínimo privilegio en file shares, bases de datos, APIs. No “Everyone: Full Control”. Es “el grupo Finanzas tiene read/write en esta carpeta, el resto no la ve”.
  • Data Loss Prevention (DLP): Monitorear y bloquear intentos de exfiltración. Si alguien intenta copiar 10,000 registros de clientes a un USB o subirlos a Dropbox personal, el sistema lo detecta y bloquea.
  • Auditabilidad: Logs de quién accedió a qué, cuándo, desde dónde. Si hay un incidente, poder reconstruir qué pasó.

Integración con otros pilares:

  • Application Trust: Las políticas de acceso limitan qué aplicaciones puede usar cada usuario, lo cual indirectamente limita qué datos puede tocar.
  • User Trust + Device Trust: Solo usuarios autenticados desde dispositivos verificados pueden descifrar información. Las claves de cifrado pueden estar atadas a certificados de usuario/dispositivo.
  • Transport Trust: El cifrado del transporte asegura que la data no se intercepte mientras viaja. El cifrado en reposo asegura que si alguien la roba igual no la puede leer.

Qué herramientas lo implementan:

  • Cifrado de disco: BitLocker, FileVault, LUKS
  • Cifrado de almacenamiento: AWS KMS, Azure Key Vault, soluciones on-prem con encrypted volumes
  • DLP: Microsoft Purview, Symantec DLP, Forcepoint, soluciones open source (MyDLP, OpenDLP)
  • Clasificación: Microsoft Information Protection, Boldon James, etiquetas manuales + proceso
  • Auditoría: SIEM (Splunk, QRadar, Wazuh), logs nativos de sistemas (Windows Event Log, syslog)

Cómo se integran los pilares

En una implementación real de Zero Trust, los pilares no se “ejecutan” uno después del otro como una checklist. Se pisan, se alimentan y se corrigen entre sí. Cada acceso es una decisión basada en el contexto completo.

Pongamos como ejemplo un caso concreto: María entra a erp.empresa.com.

Mismo usuario, contexto confiable

María está en horario laboral, desde su laptop corporativa, en la oficina. El navegador ya tiene una sesión activa.

El sistema evalúa identidad (User Trust) y contexto: usuario conocido, dispositivo habitual, ubicación esperable. No pide MFA adicional. No porque “confíe”, sino porque el riesgo es bajo y el costo de fricción no aporta seguridad real.

El dispositivo presenta su certificado (Device Trust). Es válido, emitido por la CA corporativa, el equipo está parcheado y en compliance. Eso habilita el siguiente paso.

La conexión se establece cifrada, con mTLS (Transport Trust). El gateway y el dispositivo se validan mutuamente. A nivel de red, la micro-segmentación permite ese flujo específico: María → gateway ERP. Nada más.

Con todo ese contexto, el gateway evalúa políticas (Application Trust): María pertenece a Finanzas, está en un contexto permitido, accede solo al ERP. No ve otras aplicaciones internas, aunque estén “en la misma red”.

Dentro del ERP, los permisos son los de su rol (Data Trust). Puede consultar y cargar información, pero no exportar masivamente datos sensibles. Todo queda auditado.

Acceso concedido. Sin fricción innecesaria. Seguridad suficiente para el riesgo real.

Mismo usuario, contexto intermedio

María necesita entrar al ERP desde su casa, fuera de horario, porque le pidieron cerrar algo urgente.

La identidad es válida (User Trust), pero el contexto ya no es el ideal: ubicación distinta, red doméstica, horario atípico. El sistema no bloquea, pero sube el nivel de exigencia. Se pide MFA explícito, aunque normalmente no se lo pediría, y la sesión tiene un TTL más corto.

El dispositivo pasa validación (Device Trust), pero con restricciones. Es su laptop corporativa, está en compliance, tiene certificados válidos, pero el acceso queda marcado como “riesgo medio”. Eso alimenta al resto de las decisiones.

La conexión se establece cifrada con mTLS (Transport Trust), pero la micro-segmentación es más estricta: solo se habilita el flujo exacto hacia el ERP. Nada de servicios auxiliares.

En el gateway, las políticas de acceso (Application Trust) permiten el ERP, pero en modo restringido. María puede consultar información y completar la tarea puntual, pero ciertas acciones quedan bloqueadas: exportaciones masivas, cambios estructurales, accesos administrativos.

Los datos siguen protegidos (Data Trust): cualquier intento de copiar información sensible fuera de los canales permitidos se registra o se bloquea automáticamente. Todo queda auditado, con más detalle que en un acceso normal.

El acceso existe, pero no es igual al acceso ideal. Es suficiente para resolver el problema, sin abrir más superficie de ataque de la necesaria.

Mismo usuario, contexto poco confiable

Ahora cambiemos solo el contexto: María intenta acceder a erp.empresa.com un sábado a la madrugada, desde un país donde nunca estuvo, usando un equipo personal.

La identidad sigue siendo válida (User Trust), pero el contexto no. El sistema exige MFA fuerte, y aun así el dispositivo no pasa validación (Device Trust): no está registrado, no hay certificado de máquina, no hay posture conocido.

El acceso se bloquea antes de que la aplicación siquiera entre en juego. No importa que la contraseña sea correcta. No importa que el usuario sea “de confianza”. El contexto no lo es.

Y aunque alguien lograra pasar esa etapa, la red tampoco ayuda: desde esa ubicación y segmento, el tráfico ni siquiera llega al gateway (Transport Trust).

Resultado: acceso denegado. Sin discusión.

Lo importante no es el flujo, es la decisión

Zero Trust no trata de hacer más pasos, sino de tomar mejores decisiones con el contexto completo:

  • El User Trust dice quién es.
  • El Device Trust dice desde dónde.
  • El Transport Trust asegura que la conversación es legítima y controlada.
  • El Application Trust limita a qué puede acceder.
  • El Data Trust define qué puede hacer con la información.

Cuando todo eso se integra bien, pasan dos cosas interesantes:

  • En contextos sanos, la experiencia es simple.
  • En contextos raros, el sistema restringe y bloquea.

No es magia, ni es automático implementarlo, ni es gratis en complejidad. Pero cuando funciona permite flujos de trabajo con poca fricción y una postura de seguridad elevada.

Las bases: Visibilidad y analítica, Automatización y orquestación, Gobernanza

Los cinco pilares son los componentes visibles de Zero Trust,pero para que funcionen son necesarias tres capacidades transversales. No son pilares en sí mismos, pero son requisitos que permiten que todo lo demás opere.

Visibilidad y analítica: No podés proteger lo que no ves. Zero Trust requiere visibilidad completa del tráfico (quién accede a qué, desde dónde, cuándo), del estado de los dispositivos, de las identidades activas, y de los datos sensibles. Pero visibilidad sin contexto es ruido, se necesita la capacidad de correlacionar eventos: “este usuario se autenticó desde tres países distintos en 10 minutos” no es un dato aislado, es un indicador de compromiso. Herramientas como SIEM (Splunk, Microsoft Sentinel, Wazuh), plataformas XDR (Microsoft Defender XDR, SentinelOne Singularity), o soluciones específicas de cada vendor (Omnissa Intelligence, FortiAnalyzer) consolidan logs y generan alertas accionables.

Automatización y orquestación: Validar manualmente cada acceso, revisar compliance de cada dispositivo, ajustar reglas de firewall cuando cambia un usuario de rol, no son acciones escalables. Zero Trust necesita automatización: provisioning/deprovisioning automático de accesos (identity governance), remediación automática cuando un dispositivo pierde compliance (forzar actualización de antivirus, revocar certificado), respuesta automática a incidentes (aislar dispositivo comprometido, terminar sesiones activas del usuario afectado). SOAR (Security Orchestration, Automation and Response) como Cortex XSOAR, FortiSOAR, o capacidades nativas de plataformas UEM/XDR hacen esto posible. Sin automatización, la sobrecarga operativa impide implementar Zero Trust completo.

Gobernanza: Alguien tiene que decidir quién puede acceder a qué, bajo qué condiciones, y quién es responsable de mantener esas políticas actualizadas. Gobernanza incluye: gestión del ciclo de vida de identidades (onboarding, cambios de rol, offboarding), revisión periódica de accesos (¿este usuario sigue necesitando acceso a este sistema?), políticas documentadas y auditables, y separación de funciones (quien aprueba accesos no es quien los configura técnicamente). Herramientas de Identity Governance and Administration (IGA) como Entra ID Governance u Okta Identity Governance, o procesos bien definidos con workflows en sistemas como ServiceNow o Jira, son parte de esto. Sin gobernanza, Zero Trust se degrada: permisos huérfanos, usuarios con más acceso del necesario, políticas que nadie mantiene.

Conclusión: Zero Trust es arquitectura, no checklist

Zero Trust no es un estado binario que alcanzás y listo. Es un modelo de arquitectura que aplicás gradualmente, priorizando donde más importa. El cambio fundamental no está en poder marcar todos los ítems de una checklist, sino en cómo pensás el diseño de acceso: nunca confiar por defecto, verificar siempre, dar el mínimo privilegio necesario.

Los cinco pilares —Device Trust, User Trust, Transport Trust, Application Trust, Data Trust— funcionan juntos. Ninguno es suficiente en sí mismo. Y sin las bases de visibilidad, automatización y gobernanza, no importa qué herramientas tengas, no vas a poder sostenerlo en el tiempo.

Esto no soluciona todo. Siguen existiendo aplicaciones legacy que no entienden autenticación moderna y para las que debemos ser creativos y aún así no lograremos integrarlas al 100%. También siguen existiendo usuarios que encuentran formas creativas de romper las reglas. Y sigue existiendo el riesgo de que alguien robe credenciales + dispositivo + certificado, aunque sea más difícil. Zero Trust achica la ventana de oportunidad para un atacante, pero no la cierra completamente. Quien te prometa lo contrario te está vendiendo algo imposible.

Por último: si después de leer esto te quedás pensando “ok, entiendo el concepto, pero ¿cómo arranco?”, en la segunda parte de este artículo hablo de la implementación concreta: cómo evaluar tu stack actual, qué podés hacer sin comprar nada, y cuándo sí necesitás presupuesto. Porque entender la arquitectura es el primer paso. El siguiente es empezar a aplicarla.

Referencias