The Azure Well-Architected Framework Security Pillar: A Practical Walkthrough for Platform Engineers

A Microsoft Azure Well-Architected Framework security pillar assessment surfaces the same findings in almost every environment: PIM not activated for privileged roles, MFA gaps hidden in Conditional Access exclusions, broad inbound NSG rules on sensitive ports, storage accounts not requiring secure transfer, and Log Analytics retention too short for DORA or NIS2. None are exotic. They are hardening steps deferred under delivery pressure.

You’ve been told to run a WAF security pillar assessment. Or you’re considering running one and trying to figure out what you’re walking into. Either way, the Microsoft documentation does not help you here. It’s comprehensive, abstract, and tells you nothing about whether your specific environment would pass or fail.

That’s the actual problem. Not the framework itself — the framework is sound. But reading the WAF security pillar docs is like reading a building code. You come away understanding the principles fine. You have no idea if your building passes inspection.

So here’s the specific version. The findings that appear in nearly every Azure environment that hasn’t been through a structured WAF security pillar assessment. Not similar findings — the same ones, named identically, with the same root causes. If you run this assessment on your tenant, this is a reasonable preview of what it surfaces. Use it to prepare.

Key takeaways

• The five WAF security design principles map to concrete, repeatable findings. Most environments run Azure Policy in Audit rather than Deny, and most have monitoring tools deployed without a governance loop.
• Identity findings appear in every assessed environment: PIM not activated, MFA gaps in Conditional Access exclusions, over-permissioned guest accounts, and service principals using multi-year client secrets.
• Network and data defaults are permissive: broad inbound NSG rules on ports 22/3389/1433/5432, no centralised egress inspection, storage without secure-transfer enforcement, and Key Vaults reachable from any network.
• These are deferred hardening steps, not exotic misconfigurations. The reliability pillar carries its own parallel set — see the Well-Architected reliability pillar walkthrough — and running the security assessment before an audit means remediating on your schedule, not under pressure.

What the five design principles actually translate to in practice

The WAF security pillar organises around five design principles. Here’s what each one finds in real environments, rather than what the documentation says it covers.

Plan your security readiness sounds like governance maturity. In practice, it surfaces whether a security baseline has been defined at the landing zone level — and more specifically, whether Azure Policy assignments enforcing that baseline have enforcement mode set to Deny or just Audit. Audit means the policy reports violations. Deny means it prevents them. Most environments are set to Audit. The assessment finds it every time.

Design to protect confidentiality covers encryption and access controls on data stores. This is where storage account configuration, Key Vault access models, and database encryption settings get evaluated. It maps directly to GDPR Article 32, ISO27001 Annex A.10, and DORA Article 9. The specific findings are almost always the same two or three things — which I’ll name below.

Design to protect integrity is about configuration management and change control. For most mid-market Azure teams, this surfaces findings around pipeline security: service principals with excessive permissions, IaC pipelines that don’t enforce resource tagging or configuration standards, and the absence of Azure Policy enforcement on resource creation outside the pipeline.

Design to protect availability looks at DDoS protection and backup configuration. Specifically: whether Azure DDoS Protection Standard is enabled on virtual networks hosting public-facing resources, and whether recovery objectives are documented and tested. The DDoS finding shows up constantly — because DDoS Protection Standard costs money and the basic tier is free, so most teams defer it.

Sustain and evolve your security posture is the principle assessed as inadequate most often. Not because teams haven’t deployed monitoring tools — they usually have Defender for Cloud enabled in some form. It’s that the tools are deployed without a supporting process. Alerts fire and nobody reviews them. Log Analytics workspaces collect data at retention periods too short to satisfy DORA or NIS2. The tooling is there. The governance loop isn’t.

Identity and access: where the most damaging findings live

Every assessed environment has identity findings. Without exception. These are the most common and the most directly tied to regulatory control failures.

PIM not activated for privileged roles. This is the finding that appears first and gets the most pushback. Privileged Identity Management provides just-in-time activation for Entra ID roles and Azure RBAC assignments — so accounts hold elevated access only when they actually need it, not continuously. When PIM isn’t enabled, an account with Global Administrator or Subscription Owner has that access all the time. This directly violates the principle of least privilege as required under ISO27001 Annex A.9.2.3 and DORA’s ICT risk management requirements.

The reason it’s deferred is practical: PIM requires Entra ID P2 licensing and an initial migration effort. Both are real costs. But the finding is consistently one of the highest-severity items in any WAF security assessment, and it’s the one regulators focus on first.

MFA gaps in Conditional Access. A Conditional Access policy enforcing MFA exists. It also excludes a service account group that includes accounts used by humans. Or it doesn’t cover legacy authentication pathways. Or break-glass accounts are fully exempted with no compensating control. Microsoft’s own data attributes over 99% of compromised account takeovers to accounts without MFA. The finding is almost never “no MFA policy exists.” It’s “the MFA policy has exclusions that create an effective gap.”

Guest accounts with excessive permissions. External collaborators, partners, contractors onboarded through B2B — these accounts accumulate and are rarely reviewed. An assessment enumerates all guest principals with Azure RBAC assignments and surfaces those with Contributor or higher access on production subscriptions. The finding isn’t that guest accounts exist. It’s that there’s no access review process.

Service principals using client secrets with multi-year expiry. Azure Managed Identity eliminates the need for stored credentials for workloads running inside Azure. When service principals use client secrets instead — especially with two- or three-year expiry windows — you have credentials sitting in pipelines and key stores that haven’t been rotated and may not be monitored. This is both technically avoidable and extremely common.

Network and data protection: what Azure’s defaults miss

Azure’s default network configuration is a permissive starting point. The WAF assessment surfaces the distance between what Azure gives you out of the box and what a secure baseline actually requires.

NSG rules allowing broad inbound access on sensitive ports. Inbound rules permitting traffic from Any source, or from /8 or /16 CIDR ranges, on ports 22, 3389, 1433, or 5432. These rules are created operationally — someone is troubleshooting something and needs access — and not removed. The WAF finding maps this to NIS2 Article 21 and CIS Azure Benchmark control 6.1. It appears in nearly every environment assessed.

Here’s a concrete example of how this happens: a platform engineer at a Belgian logistics firm received a support escalation from a developer who couldn’t connect to a test VM. She opened RDP from Any to unblock him, planning to tighten it after the call. The ticket got resolved, the call ended, and the NSG rule was still open six months later when the firm ran its first structured security assessment. The developer had moved to a different team. Nobody remembered the rule existed.

No centralised egress inspection. Environments without Azure Firewall or an equivalent NVA on egress paths have no mechanism to detect command-and-control traffic, data exfiltration, or connections to known malicious infrastructure. Azure Firewall Premium’s IDPS signatures and TLS inspection capabilities address this. Their absence is a finding under DORA’s network traffic monitoring requirements. And it’s a finding that’s hard to argue your way out of in a regulatory audit.

Storage accounts not requiring secure transfer. One toggle. supportsHttpsTrafficOnly set to false. It’s not the default on every storage account created through the portal in older tenant configurations, and accounts created outside IaC pipelines frequently miss it. The assessment produces a list of storage accounts with the setting disabled, mapped to ISO27001 Annex A.10.1.

Storage accounts with public blob access enabled. Even if no containers are currently configured as public, the property being enabled at the account level is a misconfiguration that could lead to accidental data exposure. Microsoft disabled this by default for accounts created after November 2023. Older accounts in your tenant are likely still enabled.

Key Vaults accessible from all networks. Key Vault instances without network restrictions — no private endpoint, no virtual network service endpoint, accessible from the public internet — represent unnecessary exposure of secrets and cryptographic material. The finding isn’t about exposed secrets. It’s about the attack surface being wider than the workload requires.

The full list of what a structured assessment typically surfaces

Run a WAF security pillar assessment against Azure Resource Graph — actual resource configuration, not self-reported answers to a questionnaire — and these are the findings that come back:

PIM not activated for privileged roles. MFA not enforced for all Entra ID users (gap usually in exclusions, not in policy existence). NSG rules allowing broad inbound access on sensitive ports. Storage accounts not requiring secure transfer. Log Analytics workspace retention below 90 days — the pragmatic minimum for DORA and NIS2; 180 days is more defensible. Defender for Cloud plans disabled on one or more resource categories. Diagnostic settings not configured on critical resources — Key Vault, Azure Firewall, Application Gateway, Entra ID audit logs not streaming to a Log Analytics workspace. No resource locks on production resource groups. Subscription-level activity logs not retained beyond the 90-day default. Azure DDoS Protection Standard not enabled on public-facing virtual networks.

The pattern is consistent across environments. These are not exotic misconfigurations requiring deep expertise to create. They’re defaults that weren’t hardened, settings that weren’t enforced, and controls that got deferred because the delivery priority didn’t require them at the time.

That last part is important. None of this reflects badly on the teams who built these environments. It reflects the gap between how Azure environments are built under delivery pressure — iteratively, with availability as the primary mandate — and what the WAF security pillar formally requires. The framework is essentially asking: did you go back and harden everything that shipped fast? The answer is almost always no.

Running the assessment before a regulatory audit or a security incident is the difference between remediating on your schedule and remediating under pressure, with an auditor or an incident response team watching.

FAQ

What is the most common Well-Architected Framework security finding? PIM not activated for privileged roles. Privileged Identity Management gives just-in-time activation for Entra ID and Azure RBAC roles; without it, Global Administrator and Subscription Owner accounts hold elevated access continuously. It violates least privilege under ISO27001 Annex A.9.2.3 and is the finding regulators focus on first.

Does a Conditional Access MFA policy mean MFA is covered? Rarely fully. The finding is almost never “no MFA policy exists” — it is exclusions that create an effective gap: a service-account group containing human accounts, uncovered legacy authentication, or break-glass accounts exempted with no compensating control. See Conditional Access and PIM for compliance for how the exclusions get audited.

What does the WAF security pillar check that Microsoft’s docs don’t tell you? The docs describe principles abstractly; the assessment evaluates actual resource configuration via Azure Resource Graph. It names whether Azure Policy enforcement is set to Deny or Audit, whether storage accounts require secure transfer, and whether Log Analytics retention meets the 90-to-180-day minimum DORA and NIS2 expect.

Can I prepare for the assessment before running it? Yes. Check the recurring items directly: PIM activation, MFA exclusions, broad inbound NSG rules on ports 22/3389/1433/5432, secure-transfer enforcement on storage, Key Vault network restrictions, and diagnostic settings on Key Vault, Azure Firewall, and Entra ID audit logs. Most teams cannot confirm these without looking — which is the point.

Here is the more useful question, though. Of the findings above, how many could you confirm or rule out in your own tenant right now — without going to check first? For most teams the honest answer is “not many,” and that gap is the whole point: the configuration is knowable, it just has not been looked at all at once.

The checklist that produces these findings is open and free to run against your own environment — link in the comments. If it surfaces something you did not expect, I would genuinely like to hear which one.