Microsoft ha llevado a disponibilidad general Trusted Launch as Default para la creación de nuevas máquinas virtuales Gen2 y Virtual Machine Scale Sets compatibles. El cambio parece pequeño en el portal, pero tiene una consecuencia importante: la configuración segura deja de depender de que alguien recuerde activarla en cada despliegue.
Trusted Launch combina Secure Boot y un vTPM para reforzar la cadena de arranque. El objetivo es reducir la exposición frente a bootkits, rootkits y otro malware capaz de ejecutarse antes o durante la carga del sistema operativo. No sustituye al hardening, al parcheado ni a Defender, pero mejora la base sobre la que se construye la VM.
Qué cambia realmente
En los nuevos despliegues compatibles, Azure aplica Trusted Launch de forma predeterminada. Esto afecta a VM Gen2 y a scale sets cuando la imagen, el tamaño y el método de creación admiten esta modalidad. Microsoft indica que la experiencia ya está disponible con carácter general en Azure Portal, PowerShell y Azure CLI; algunas rutas de despliegue mediante otros clientes o API pueden seguir sujetas a condiciones específicas, por lo que conviene comprobar la documentación del método utilizado.
Lo importante es lo que no cambia: las VM y scale sets que ya están funcionando no se convierten automáticamente. Tampoco se ignoran las decisiones explícitas incluidas en una plantilla. Si un despliegue necesita el tipo de seguridad estándar por una incompatibilidad concreta, debe declararse y justificarse de forma consciente.
Por qué importa a un equipo de plataforma
Este cambio reduce el riesgo de crear infraestructura nueva con una protección de arranque inferior por simple omisión. A la vez, puede descubrir dependencias que hasta ahora permanecían ocultas: imágenes antiguas, familias de tamaños no compatibles, procesos de generación de imágenes o automatizaciones que asumían que una VM Gen2 equivalía siempre a una configuración estándar.
También cambia el enfoque de gobierno. En lugar de preguntar por qué una carga activa Trusted Launch, la excepción pasa a ser la VM que no lo utiliza. Esa inversión es positiva, pero necesita trazabilidad: cualquier exclusión debería quedar documentada, tener propietario y revisarse cuando cambie la imagen o el tamaño.
Qué revisaría ahora
- Plantillas ARM, Bicep y Terraform: comprobar las versiones de API y si
securityProfilese declara de forma explícita. - Catálogo de imágenes: validar compatibilidad con Secure Boot, vTPM y las familias de VM empleadas.
- Pipelines: ejecutar un despliegue de prueba y confirmar el tipo de seguridad resultante; no basta con que la creación termine correctamente.
- Excepciones: localizar configuraciones con
securityType: Standardy verificar que siguen teniendo una razón técnica vigente. - Máquinas existentes: tratarlas como una línea de trabajo separada, porque este anuncio no las migra por sí solo.
Mi lectura es clara: es una mejora de seguridad útil precisamente porque convierte una buena práctica en el camino normal. El trabajo para IT no está en pulsar una casilla, sino en verificar que las automatizaciones producen el resultado esperado y que las excepciones no se convierten en deuda permanente.
Más detalles en el anuncio oficial de Azure. Para revisar compatibilidad, comportamiento y excepciones, Microsoft mantiene también las preguntas frecuentes de Trusted Launch.