Going deeper: Examining Microsoft Azure “Secure by Default” vs Amazon Web Services “Security-by-Design”

Microsoft’s recent “Secure by Default” initiative – part of its broader Secure Future Initiative (SFI) – has raised questions about whether it is simply catching up to Amazon Web Services (AWS) or marking a distinct strategic shift. AWS has long touted a security-by-design approach, with many default configurations favouring secure baselines. This analysis compares Microsoft’s initiative with AWS’s established practices in key areas (network security, identity and access management, and compliance) and examines expert opinions and Microsoft’s stated motivations.

Motivation and Strategic Shift

Microsoft launched the Secure Future Initiative in late 2023 amid high-profile security incidents (e.g. the Storm-0558 breach) that exposed gaps in its security posture. In response, Microsoft’s leadership pledged to “prioritise security above all else” and to enforce security protections by default across all products. The Secure by Default principle, where security features are enabled out-of-the-box, with no user action and no opt-out – is a core part of this push. This represents a company-wide cultural shift, with Microsoft tying executive compensation and engineering goals to security outcomes.

While Microsoft’s new defaults do align with some practices long used by AWS, the initiative is more than just copycat behaviour. It’s rooted in Microsoft’s effort to regain customer trust and defend against evolving threats. Charlie Bell (Microsoft Security EVP and former AWS executive) emphasised integrating cybersecurity “by design” and “by default” after internal reviews found “avoidable errors” in prior configurations. In short, Microsoft is catching up in certain areas to match AWS’s secure defaults, but it’s also making a strategic pivot to bake security into every facet of its services (something AWS has espoused from the start).

Network Security: Default Isolation vs. Outbound Access

One notable comparison is how each cloud handles network connectivity by default. AWS has historically taken a least-access approach to networking: in a new AWS virtual private cloud (VPC), no internet traffic is allowed unless you explicitly attach an Internet Gateway or NAT gateway and configure routes. By default, an AWS EC2 instance in a private subnet has no outbound internet access – the onus is on the user to enable it if needed. This “secure by design” network isolation limits exposure unless intentionally opened.

Azure, until recently, took the opposite approach for convenience: an Azure virtual machine in a virtual network automatically had outbound internet connectivity by default, even without a public IP or user configuration. While inbound traffic was still restricted by network security groups, the default outbound access meant Azure users didn’t have to configure anything to reach the internet. This difference has often been cited in cloud security discussions – “Azure VMs have internet connectivity by default… (no NAT gateway needed) unlike AWS”. However, Microsoft is now changing this default to enhance security. It announced that as of September 30, 2025, new Azure VMs will no longer have default outbound internet access; administrators will need to configure a NAT gateway, load balancer, or attach a public IP to enable egress. Existing VMs aren’t cut off, but Microsoft is strongly encouraging a transition to explicit outbound methods. In effect, Azure is aligning with AWS’s model of requiring deliberate setup for internet exposure, eliminating the “open by default” outbound path.

Beyond internet access, both providers offer similar network security constructs (virtual networks/VPCs, subnets, security groups, firewalls) with secure defaults. Azure Network Security Groups default to a “deny all inbound, allow outbound” stance, much like AWS Security Groups (which deny all inbound by default, except explicitly allowed). Both clouds provide built-in DDoS protection at the network edge (AWS Shield Standard is automatic; Azure has basic DDoS protection always on) and options for advanced DDoS service tiers.

The key change is Microsoft’s shift to explicit egress configuration, which is clearly a catch-up move to AWS’s long-standing practice. Microsoft itself acknowledges this alignment: “Azure VM networking has differed from AWS... AWS VMs have no internet access by default... This is set to change” with Azure’s new policy.

Identity and Access Management (IAM): Defaults and Best Practices

In the realm of identity and access management, AWS and Azure have taken somewhat different approaches, each with its own advantages. AWS’s IAM is very granular and flexible – users or roles are created with zero permissions by default and administrators attach JSON policies to grant least-privilege access. This flexibility is powerful but can be complex, and misconfiguration (like an overly broad "*" permission stanza in a policy) can inadvertently over-provision access. Azure, on the other hand, uses a Role-Based Access Control (RBAC) model tied to Microsoft Entra ID (formerly known as Azure AD). Identities (users, service principals) are granted roles which are defined by a set of permissions, and then scope is specified at assignment (subscription, resource group, or resource level). By decoupling permissions from scope, Azure makes it harder to unintentionally grant rights over all resources – an admin must explicitly choose the scope when assigning a role, which adds a safety check.

Microsoft’s Secure by Default initiative pushes identity security even further. Microsoft is now enabling multi-factor authentication (MFA) by default for Entra ID tenants to counter credential attacks. New Azure AD/Entra tenants since 2019 have had Security Defaults turned on (enforcing MFA for admins, blocking legacy auth, etc.), but now even existing tenants are being moved to stronger authentication requirements. Charlie Bell highlighted automatic MFA by default as a recent step embracing the Secure by Default ethos.

By contrast, AWS does not automatically enforce MFA on new accounts or IAM users – it’s encouraged but left optional. AWS does mandate MFA for certain sensitive operations (like deleting root access keys) and provides tools like AWS MFA and AWS SSO (IAM Identity Centre), but it hasn’t made MFA a default requirement across the board. In this aspect, Microsoft’s initiative is a distinct shift, taking a more opinionated stance on identity security than AWS does out-of-the-box.

Another difference is in default credential management for programmatic access. AWS historically issues long-lived Access Keys for IAM users to use in the CLI or API calls. These static keys do not expire and rely on the user to rotate or revoke them, which has led to many incidents of leaked AWS credentials due to poor handling. AWS now recommends avoiding long-term access keys in favour of its IAM Identity Centre (providing temporary credentials for CLI via an SSO approach), but many still use keys because it’s the traditional method and initially easier.

In Azure, the approach has been more “secure by default” for user access: Azure does not use long-lived user keys for CLI logins. Instead, users authenticate with their Entra ID credentials via an interactive device login, obtaining short-lived OAuth tokens (with refresh tokens that expire in 90 days). There is no concept of a user-level access key in Azure – this reduces the chance of credentials being left in config files or code repositories. For non-interactive access, Azure uses service principals with secret or certificate credentials (which are analogous to AWS access keys for service accounts), but these are explicitly created for app scenarios. In short, Azure’s default CLI authentication is ephemeral and tied to user identity, whereas AWS’s default (until recently) was a static key – a design gap that Microsoft had arguably addressed earlier than AWS. This is one case where Microsoft wasn’t catching up to AWS, but rather AWS has been adjusting its best practices to catch up with a more secure pattern.

Finally, each provider offers robust identity features such as single sign-on, integration with external IdPs, and privileged identity management. Azure’s long history with Active Directory gives it a seamless hybrid story (integrating on-premises AD with Entra ID). AWS, while originally account-centric, now also offers organisations and SSO to link with corporate directories. Both support the principle of least privilege – but Microsoft’s Secure by Default push is making least privilege and strong auth the default stance (e.g. “ensure 100% of users are protected with phishing-resistant MFA” is an SFI goal), whereas AWS historically leaves such measures to customer implementation.

Compliance and Secure Configuration Frameworks

Both AWS and Azure understand that enterprise customers care about compliance frameworks (such as ISO 27001, PCI-DSS, FedRAMP, etc.) and have built extensive compliance programs. AWS had a head start here: it presently supports 143 security standards and compliance certifications globally, offering compliance attestations through its Artifact service and maintaining dedicated government cloud regions (e.g. AWS GovCloud) for regulated workloads. Microsoft Azure is not far behind – it has over 100 compliance certifications, including 50+ region- or country-specific ones, and similarly provides Azure Government regions and the Microsoft Trust Centre for compliance information. In terms of coverage of regulatory requirements, both cloud providers are comparably strong, regularly updating their certifications to address new regulations.

Where Microsoft’s Secure by Default strategy may differ is in how default settings align to compliance best practices. A secure-by-default approach means new resources should be configured in ways that inherently meet common security controls (or at least make it easy to meet them). For example, encryption of data at rest is now enabled by default on both AWS and Azure storage services (AWS S3 defaulted to encryption by default starting 2023, and Azure Storage has encrypted all data at rest by default for years). Public access to storage is another example: historically, an AWS S3 bucket was open to the internet by default unless you locked it down, which led to many data leak incidents over the years. AWS ultimately changed this behaviour in 2023, so new S3 buckets block public access by default. Azure Blob storage, by contrast, never allowed anonymous access without explicit configuration – even if you set a blob container to “public,” the platform required authentication unless you deliberately enabled anonymous access. This prevented many accidental exposures; one security researcher noted “we have rarely encountered issues with exposed Azure Storage Accounts” thanks to Azure’s secure-by-default design here. In this case, Microsoft was ahead of AWS in default security, and AWS had to catch up after a decade of breaches.

Both AWS and Azure provide governance tools to help customers adhere to frameworks. AWS Config and AWS Security Hub can audit configurations against standards like CIS benchmarks or NIST, and AWS Control Tower can enforce baseline guardrails. Azure offers Azure Policy and the Defender for Cloud compliance dashboard to similarly assess and enforce resource configurations. In fact, both clouds have built-in policy packs for common frameworks (for example, Azure Policy initiatives and AWS Config rulesets to check compliance with PCI, ISO 27001, etc.).

It's important to note that neither cloud will make you automatically compliant – customers still must configure settings appropriately – but the default postures are increasingly aligned with best practices. Microsoft’s “secure by default” ethos explicitly aims for “ground-up compliance,” meaning the default settings should map to regulatory requirements and reduce the work needed to meet standards. This indicates a strategic emphasis on compliance in the design phase. AWS has similarly championed the notion of building with security and compliance in mind (their well-architected framework and shared responsibility model stress this), but AWS tends to provide the tools and leave the defaults more flexible. Microsoft’s initiative tilts more toward enforcing a baseline (for instance, deprecating insecure legacy protocols and requiring modern auth, as well as the networking changes discussed).

Conclusion

It’s worth noting that AWS’s philosophy has always been to give customers freedom (with strong tools to secure through defense in depth) – which can sometimes mean fewer enforced defaults. As one Sumo Logic analysis put it, “AWS had the first mover advantage, [and] Azure was quick to catch up. With every new update, they keep up with each other, and there’s little that separates these two…” in core security capabilities. In many respects, both providers now offer similar security features (identity management, encryption, monitoring, etc.), but how they implement defaults differs.

Microsoft’s “Secure by Default” initiative is both a catch-up measure in specific areas and a broader strategic shift. In network security, Microsoft is undeniably catching up to AWS’s long-standing practice of explicit outbound access configuration, closing a gap that made Azure more open by default. In identity management, Microsoft’s enforcement of MFA by default and its emphasis on short-lived credentials go beyond what AWS currently mandates, reflecting a proactive stance born from hard lessons in recent cyberattacks. The initiative signals a company-wide commitment (backed by leadership and cultural change) to make secure configurations the norm rather than the exception. This top-down mandate is a distinct shift in strategy, likely influenced by Microsoft’s unique challenges (e.g. securing a vast legacy ecosystem and responding to government scrutiny).

At the same time, AWS’s security-by-design approach has set a high bar that Microsoft clearly acknowledges. Both cloud giants now espouse similar core principles – “secure by design, secure by default, continuous monitoring” – and continue to learn from each other. For customers and industry watchers, the key takeaway is that default cloud security postures are strengthening. Microsoft’s initiative should result in fewer “foot-gun” misconfigurations for Azure users, much as AWS’s built-in guardrails have evolved over the years. In the words of one industry analysis, AWS and Azure security now have “little that separates” them in capabilities, but the philosophy of enforcement vs. flexibility distinguishes Microsoft’s new approach. “Secure by Default” is Microsoft putting a firm stake in the ground that convenience will not trump security – a shift in mindset that goes beyond imitation and towards leadership in cloud security best practice.