El camino hacia una arquitectura Zero Trust real

Zero Trust es uno de esos términos que han sufrido el desgaste de la sobreexposición. Aparece en presentaciones comerciales, en pliegos públicos y en titulares de prensa, pero cuando se baja al terreno la pregunta sigue siendo la misma: ¿por dónde empiezo? La entrada de NIS2 ha acelerado las decisiones, y muchas organizaciones se enfrentan ahora a la necesidad de demostrar que su modelo de seguridad va más allá del perímetro tradicional. El problema es que Zero Trust no se compra ni se instala: se diseña, se recorre y se mide.

Qué es y qué no es Zero Trust

Zero Trust no es un producto ni una arquitectura única. Es un modelo basado en tres principios definidos por NIST en su SP 800-207: verificar explícitamente cada acceso considerando identidad, dispositivo, ubicación y riesgo; conceder el mínimo privilegio necesario y solo durante el tiempo imprescindible; y asumir que la brecha ya ha ocurrido, diseñando los controles para limitar el impacto cuando suceda. Lo importante no son los principios en sí, que son fáciles de enunciar, sino entender que aplicarlos exige tocar identidad, endpoints, red, datos, aplicaciones y gobierno de forma coordinada. No hay un interruptor mágico.

Diseñar el camino, no solo el destino

Aquí es donde la mayoría de los proyectos fallan. Se aborda Zero Trust como una lista de tecnologías a desplegar y no como una estrategia evolutiva. El modelo de madurez de Zero Trust de CISA, que es hoy en día una de las referencias más útiles, plantea cuatro fases, tradicional, inicial, avanzada y óptima, a través de cinco pilares: identidad, dispositivos, redes, aplicaciones y datos, sostenidos por capacidades transversales de visibilidad, automatización y gobierno. Este enfoque permite hacer algo que los checklists no permiten: situar honestamente a la organización en el mapa de Zero Trust, priorizar los siguientes pasos en función del riesgo real y demostrar progreso medible ante dirección, auditores y el regulador.

El camino típico no es lineal ni igual para todos. Una organización con los sistemas clásicos ya consolidados suele tener avanzada la capa de identidad y atrasada la de datos. Una industrial con OT tiene el problema inverso. Por eso el primer entregable de cualquier iniciativa Zero Trust seria no debería ser una arquitectura objetivo, sino una evaluación de madurez por pilar y un roadmap de 12 a 24 meses con hitos verificables.

Errores frecuentes

El más extendido es confundir Zero Trust con desplegar MFA y dar por hecho el resto. MFA es condición necesaria, no suficiente. El segundo es comprar herramientas antes de definir políticas: cualquier plataforma, por buena que sea, amplifica el desorden si no hay un modelo de identidades, dispositivos y datos detrás. Y el tercero, quizá el más caro, es tratarlo como un proyecto de seguridad en lugar de como una transformación que afecta a operaciones, soporte y experiencia de usuario. Sin esa conversación, el rechazo interno acaba frenando incluso los despliegues técnicamente bien ejecutados.

Más allá del cumplimiento

NIS2, ENS o ISO 27001 son hoy el detonante de muchas conversaciones sobre Zero Trust, pero quedarse ahí es desaprovechar la inversión. Una arquitectura Zero Trust bien gobernada reduce la superficie de ataque, acorta los tiempos de respuesta ante incidentes, simplifica el acceso remoto y permite adoptar nuevas tecnologías, entre ellas la la IA generativa, con un marco de control coherente. El cumplimiento se obtiene como consecuencia de hacer las cosas bien, no como objetivo.

La pregunta para cualquier organización que esté empezando no es qué herramienta de Zero Trust elijo, sino en qué punto del modelo de madurez estoy y cuál es el siguiente paso que más reduce mi riesgo. Esa es la conversación que merece la pena tener.