A lot of enterprise security teams treat Azure security as "AWS security with different service names," and that assumption causes real gaps. The underlying principles overlap least privilege, encryption, monitoring, all still matter but Azure's actual control surfaces, default behaviors, and common misconfiguration patterns are genuinely different in specifics, and teams that port over AWS-flavored assumptions wholesale tend to miss exactly the places Azure diverges.
My honest take, from working across both platforms: Azure's identity model, built around Entra ID (formerly Azure AD) as the connective tissue across essentially everything, is both its biggest security strength and its most common source of enterprise misconfiguration. Get that layer right and a lot of the rest follows naturally. Get it wrong and no amount of resource-level hardening fully compensates.
*Entra ID Is the Actual Perimeter Treat It That Way *
For most enterprise Azure environments, Entra ID identity is functionally the real security boundary, more than network configuration is. Conditional Access policies, which govern who can access what, from where, under what device and risk conditions, are the primary control surface that actually matters day to day arguably more than network security groups, because so much of enterprise Azure usage flows through identity-based access to services rather than traditional network-perimeter access patterns.
Conditional Access should be configured to require MFA universally, restrict access based on genuine device compliance status, and apply meaningfully different risk-based conditions for privileged accounts specifically compared to standard user accounts. Enterprises that configure this thoroughly at the identity layer get a security posture that AWS's more network-centric default model doesn't provide out of the box in quite the same way this is a genuine area where Azure's architecture, done correctly, holds an advantage.
*Privileged Identity Management: Use It, Don't Just License It *
Privileged Identity Management (PIM) enables just-in-time privileged access administrators request elevated permissions for a defined, limited time window rather than holding standing administrative privileges continuously, indefinitely, whether they're actively using them or not. This is a genuinely powerful control that dramatically reduces the attack surface presented by privileged accounts specifically, since a compromised credential that doesn't currently hold elevated privileges is far less immediately dangerous than one that does.
The gap we see constantly: organizations license PIM as part of a broader Entra ID licensing tier and never actually configure or enforce it operationally. Standing administrative access remains the norm in practice even though the tooling to eliminate it is already paid for and sitting unused. If your organization has PIM available and isn't actively using it for genuinely privileged roles, that's a real, immediately actionable gap worth closing before pursuing anything more advanced.
Network Security Groups and Azure Firewall: Layered, Not Redundant
Azure's network security model offers multiple layers Network Security Groups at the subnet and NIC level, Azure Firewall for centralized, more sophisticated traffic filtering. A common mistake is treating these as redundant and relying heavily on just one, when they're actually meant to work together as complementary layers, each catching different classes of misconfiguration or threat.
NSGs should enforce least-privilege network access at the resource level specifically, while Azure Firewall provides centralized policy enforcement and genuine visibility across the broader network different vantage points, both genuinely necessary rather than either one substituting fully for the other. Relying on NSGs alone misses centralized visibility and consistent policy enforcement across environments; relying on Azure Firewall alone without properly configured NSGs leaves resource-level gaps that centralized filtering isn't positioned to catch on its own.
Azure Security Center / Microsoft Defender for Cloud: Actually Act on Recommendations
Microsoft Defender for Cloud provides genuinely useful continuous security posture assessment and specific, actionable recommendations across an Azure environment. The tooling itself is mature and does real work identifying gaps. The gap, consistently, is organizational: recommendations get generated and then sit unaddressed, because nobody's specifically assigned to review and act on them on any defined cadence.
Assigning genuine ownership for reviewing and actually acting on Defender for Cloud recommendations not just having the tool generate them into a dashboard nobody checks turns a genuinely capable monitoring tool into an actual security improvement, rather than a compliance artifact that exists mainly to demonstrate the organization owns monitoring tooling, which is a very different thing from actually using it.
Storage Account Security Requires Explicit, Deliberate Configuration
Azure Storage accounts, similar to S3 buckets on AWS, can be configured with public access, and misconfigured storage accounts are a common source of accidental exposure on Azure specifically, for largely the same underlying reasons this happens on any cloud platform permissions widened during troubleshooting, never fully locked back down once the immediate need passed.
Storage account access should default to private, with public access enabled only for genuinely specific, deliberate use cases and reviewed regularly rather than left permissive by default or by accident. Azure Storage firewall rules, restricting access to specific, known network ranges rather than allowing broad access, add a meaningful additional layer beyond identity-based access controls alone.
*Azure Policy: Enforce Standards Instead of Just Documenting Them *
Azure Policy allows organizations to define and automatically enforce configuration standards across resources genuinely preventing non-compliant resources from being created, rather than just detecting non-compliance after the fact once something's already been deployed and is potentially already exposed. This is a meaningfully stronger control than after-the-fact detection, because it stops the misconfiguration from ever existing in production rather than catching it once it's already live and potentially already exploited.
Organizations that rely purely on documented standards a policy document describing how resources should be configured, without actual automated enforcement backing it up consistently see more configuration drift over time than organizations using Azure Policy to genuinely enforce those standards automatically at the platform level, where compliance isn't optional or dependent on any individual remembering the documented standard correctly.
Key Vault: Centralize Secrets, and Actually Restrict Access to the Vault Itself
Azure Key Vault provides genuinely solid secrets management capability API keys, certificates, connection strings, all centralized rather than scattered across configuration files and source code where they're far more exposed. The tooling itself isn't usually the gap here.
The gap is frequently access control on the vault itself Key Vault access policies that are broader than they should be, effectively undermining the centralization benefit, since centralizing secrets into a vault that's itself too broadly accessible doesn't actually reduce risk nearly as much as it appears to on paper. Access to Key Vault should follow the same least-privilege principles applied everywhere else, reviewed with the same rigor, not treated as inherently secure just because it's a purpose-built secrets management service rather than a plain configuration file.
Azure AD Application Registrations: An Underappreciated Attack Surface
Application registrations in Entra ID, used for service-to-service authentication and third-party integrations, represent a genuinely underappreciated attack surface in a lot of enterprise Azure environments. Overly broad API permissions granted to an application registration, or registrations that are no longer actually in active use but never got cleaned up once whatever created them wrapped up, both represent real, often-overlooked risk sitting quietly in an environment that doesn't get the same routine review that user accounts typically receive.
Regular review of application registrations, their actual granted permissions against genuine current need, and removal of anything no longer legitimately in use closes a gap that's frequently missed specifically because it doesn't look like a traditional "user account" security review and so doesn't naturally get folded into the processes built for that more familiar category.
*Resource Locks and Azure Blueprints for Consistent Governance *
For enterprises managing genuinely complex, multi-subscription Azure environments, Resource Locks prevent accidental or unauthorized deletion or modification of critical resources, while Azure Blueprints enable consistent, repeatable deployment of properly configured, compliant environments across a subscription structure. Both are underused specifically in larger organizations, where sprawl across many subscriptions and resource groups makes manual, case-by-case consistency genuinely difficult to maintain without this kind of platform-level governance tooling doing real work.
*Building This Into an Actual Enterprise Control Framework *
Pulled together, a genuinely mature Azure security posture requires:
Conditional Access configured thoroughly, treating identity as the primary security perimeter it functionally is
PIM actually enforced for privileged roles, not just licensed and left unconfigured
NSGs and Azure Firewall working as complementary, layered controls, not one substituting for the other
Defender for Cloud recommendations actively owned and acted upon, not generated into a dashboard nobody reviews
Storage accounts defaulting to private, with any public access deliberate and regularly reviewed
Azure Policy enforcing standards automatically, not just documenting them for reference
Key Vault access genuinely restricted, not assumed secure purely because it's a purpose-built secrets service
Application registrations audited regularly, closing a gap that doesn't fit neatly into traditional user-account review processes
Resource Locks and Blueprints for consistent governance at real multi-subscription enterprise scale
*The Actual Point
*
Azure's security model isn't weaker than AWS's, and it isn't stronger either it's differently shaped, built around identity as the organizing principle in a way that rewards teams who genuinely understand and configure Entra ID and Conditional Access thoroughly, and quietly punishes teams who port over network-centric assumptions from a different platform without adapting them to how Azure actually works underneath.
The enterprises with genuinely strong Azure security posture aren't the ones with more security budget than everyone else. They're the ones who understood that Azure's identity layer deserved the same depth of attention traditional network security got on other platforms and actually gave it that attention, consistently, rather than treating identity configuration as a one-time setup step during initial tenant provisioning.
Top comments (0)