Trusted Launch as Default : Azure sécurise tes VMs Gen2

Une VM Azure Gen2 que tu déploies aujourd’hui via Terraform, sans rien préciser dans ton securityProfile, n’a plus le même comportement qu’il y a six mois. Secure Boot et vTPM s’activent tout seuls. Pas de case à cocher, pas de paramètre à ajouter — juste un changement silencieux de comportement par défaut qui peut surprendre si tu génères des images personnalisées ou si tu exploites une VM en hibernation.

Trusted Launch as Default, disponible en production

Trusted Launch as Default (TLaD) est passé en disponibilité générale cet été. Le principe : toute nouvelle VM ou tout nouveau scale set Gen2 que tu crées — que ce soit via le portail Azure, PowerShell, l’Azure CLI, un template ARM, Bicep ou Terraform — bascule automatiquement en Trusted Launch avec Secure Boot et vTPM activés, sans que tu aies à ajouter le moindre bloc securityProfile à ton code de déploiement.

Concrètement, ça combine trois briques : Secure Boot, qui n’autorise que des systèmes d’exploitation et des pilotes signés à démarrer ; un vTPM conforme à la spec 2.0, qui sert de coffre-fort dédié pour tes clés et mesures d’intégrité ; et la surveillance d’intégrité du démarrage via Microsoft Defender for Cloud, qui déclenche une alerte si la chaîne de boot a été altérée. Rien de nouveau en soi — Trusted Launch existe depuis plusieurs années — mais jusqu’ici, il fallait le demander explicitement. Ce n’est plus le cas.

Ce qui change vraiment côté déploiement

Avant TLaD, l’absence de bloc securityProfile dans ton template créait une VM Gen2 « standard », sans Secure Boot ni vTPM. Depuis la bascule, avec une API en version 2025-11-01 ou supérieure, l’absence de ce même bloc produit désormais une VM Trusted Launch. Ton code ne change pas — c’est l’interprétation par défaut de son absence qui s’inverse. Si tu passais explicitement securityType: "Standard", rien ne bouge : ton intention reste respectée.

La bascule automatique ne s’applique que si quatre conditions sont réunies : l’image source du Marketplace supporte Trusted Launch, une image issue d’une Azure Compute Gallery est elle aussi validée pour Trusted Launch, le disque source le supporte, et la taille de VM choisie fait partie des familles compatibles. Si une seule de ces conditions manque, le déploiement continue normalement — tu obtiens une VM Gen2 sans Trusted Launch, pas une erreur.

Zéro surcoût, mais une vraie limite à connaître

Premier point rassurant : Trusted Launch ne coûte rien de plus. C’est une couche de sécurité fondamentale incluse dans le prix de la VM, ce qui rend la question « faut-il le désactiver pour économiser » sans objet. Microsoft déconseille d’ailleurs explicitement de le désactiver sur de nouveaux déploiements, sauf cas précis.

La vraie limite technique concerne le redimensionnement. Une fois une VM créée en Trusted Launch, tu ne peux plus la redimensionner vers une famille de taille qui ne le supporte pas — les séries M, notamment. Si ton scénario impose de basculer un jour vers une taille incompatible, la seule voie de sortie documentée consiste à désallouer la ressource, puis repasser explicitement securityType à Standard via l’API 2025-11-01 ou une version ultérieure, avec un outil client autre que le portail — cette opération n’est pas disponible dans l’interface graphique Azure.

Trois cas où il faut désactiver la bascule explicitement

Microsoft documente précisément les scénarios où contourner TLaD n’est pas optionnel :

• tu utilises une VM Gen2 pour générer des images de type TrustedLaunchSupported, TrustedLaunchAndConfidentialVMSupported ou ConfidentialVMSupported dans une Azure Compute Gallery, via Azure Image Builder ou Packer ;
• tu captures une image managée classique (managed image) à partir d’une VM Gen2 — cette fonctionnalité n’est tout simplement pas compatible avec Trusted Launch, Microsoft recommandant de migrer vers Azure Compute Gallery ;
• tu exploites l’hibernation sur une VM Linux Gen2 — Trusted Launch et hibernation Linux restent mutuellement exclusifs à ce jour.

Dans ces trois cas, le contournement passe par l’enregistrement de la fonctionnalité preview TrustedLaunchByDefaultPreview sous l’espace de noms Microsoft.Compute, désactivée pour ta souscription, ou par un securityType: "Standard" explicite VM par VM.

Et les VM existantes ?

Aucun changement. TLaD ne touche que les nouvelles créations — une VM ou un scale set déjà en production garde exactement le comportement pour lequel il a été déployé, TLaD ou pas. Si tu veux faire monter en sécurité un parc existant, la bascule reste manuelle : désallouer la VM, passer le type de sécurité à Trusted Launch, cocher Secure Boot et vTPM, puis redémarrer. Une VM Gen1 doit d’abord être mise à niveau vers Gen2, ce qui implique de valider au préalable le volume système invité — cette étape ne peut pas être ignorée, même en ligne de commande.

FAQ

TLaD s’applique-t-il à mes VM Gen1 ?

Non, uniquement aux VM et scale sets Generation 2. Une VM Gen1 doit d’abord être migrée vers Gen2 — avec validation du volume système invité — avant de pouvoir bénéficier de Trusted Launch, par défaut ou manuellement.

Est-ce que ça change mes scripts d’automatisation existants ?

Si tes templates ARM ou modules Terraform utilisaient déjà l’API 2021-11-01 ou une version plus récente sans bloc securityProfile explicite, le comportement change sans que tu aies à toucher au code — c’est justement le point. Si tu veux garder le comportement pré-TLaD, ajoute securityType: "Standard" explicitement.

Faut-il l’activer manuellement sur ma souscription ?

Non. Le portail Azure, PowerShell et l’Azure CLI appliquent Trusted Launch par défaut sur les VM Gen2, indépendamment de tout enregistrement de fonctionnalité. L’enregistrement de TrustedLaunchByDefaultPreview ne concerne que les déploiements via SDK, Terraform ou d’autres outils tiers.

Ce qu’il faut retenir

Pour l’écrasante majorité des déploiements de VM Windows ou Linux standards, TLaD est une bonne nouvelle qui ne demande aucune action : la sécurité de base progresse sans effort de ta part, sans facture supplémentaire. La vigilance à avoir concerne surtout les pipelines de fabrication d’images (Packer, Azure Image Builder) et les environnements qui dépendent encore de managed images classiques plutôt que d’Azure Compute Gallery — ce sont eux qui ont le plus de chances de voir un déploiement automatisé changer de comportement sans prévenir. Si la résilience de tes VM Azure t’intéresse au-delà du boot sécurisé, notre article sur la GA de l’Ephemeral OS Disk avec Full Caching et celui sur le passage aux Azure Verified Modules complètent bien ce sujet.