Key Points
- Microsoft describes how Azure IaaS security relies on layered defense in depth, guided by the Secure Future Initiative (SFI) principles of secure by design, secure by default, and secure in operation.
- Concrete protections include hardware roots of trust, Trusted Launch for VMs, Azure confidential computing with AMD SEV-SNP and Intel TDX, and default encryption at rest for storage.
- This matters most to cloud architects and IT admins who design or operate Azure infrastructure and want to understand what security controls are built into the platform by default.
What is changing
Microsoft is laying out how Azure IaaS security works as a system rather than a single product. The platform applies defense in depth across hardware, host integrity, virtualized compute isolation, network segmentation, storage encryption, and continuous monitoring. Trusted Launch is enabled by default for newly created Azure Gen2 VMs and scale sets.
Networking defaults block inbound VM traffic unless explicitly allowed. Features like Azure Private Link and private endpoints keep services off the public internet. Azure Firewall provides centralized policy enforcement, and DDoS protection runs automatically at the platform edge.
Why it matters
Cloud architects and security teams building on Azure should know that many protections, like host-level isolation, disk encryption, and Trusted Launch, are on by default and cannot be disabled by tenants. Azure confidential computing extends this with hardware-based memory encryption for sensitive workloads, though this is limited to supported VM sizes and regions.
The practical takeaway is that Azure IaaS has multiple independent security layers in place before you add any of your own. If you rely on these defaults, your attack surface starts smaller. Have you checked which of these defaults are active in your own deployments?