CAF and WAF: Designing Secure Azure Foundations
Learn how the Cloud Adoption Framework and Well-Architected Framework give cybersecurity architects a structured approach to security strategy, Azure Landing Zones, and design trade-offs.
Why frameworks matter to architects
Imagine building a house without building codes.
You could wire the electricity however you wanted, skip the fire exits, and put the plumbing wherever it fits. It might work — until something goes wrong.
Building codes exist because smart people already figured out what fails and how to prevent it. They don’t tell you what colour to paint the walls — they tell you where the load-bearing walls must go.
CAF and WAF are the building codes for Azure security. They don’t replace your creativity as an architect — they give you guardrails so you don’t have to rediscover every failure mode yourself. The SC-100 exam expects you to know these frameworks and design within them.
Cloud Adoption Framework — security methodology
The CAF security methodology defines how security integrates into every phase of cloud adoption:
| CAF Phase | Security Role | Architect’s Contribution |
|---|---|---|
| Strategy | Define security strategy aligned with business outcomes | Identify crown jewels, risk appetite, regulatory requirements |
| Plan | Integrate security into the cloud adoption plan | Assess current security posture, define target state, identify skill gaps |
| Ready | Implement security in the Azure Landing Zone | Design identity, networking, and governance guardrails |
| Secure | Establish security baselines and implement security controls | Define security posture, threat model, security operations strategy |
| Adopt (Migrate) | Secure workloads during migration | Assess workload security posture, design secure migration paths |
| Adopt (Innovate) | Build security into new development | DevSecOps integration, secure-by-default architecture patterns |
| Govern | Establish ongoing security governance | Azure Policy, compliance monitoring, cost governance with security budget |
| Manage | Operate security continuously | SecOps, monitoring, incident response, patching |
🌐 Scenario: Elena's cloud transformation
Meridian Global Industries is migrating 200 workloads from on-premises data centres to Azure over 18 months. Dr. Elena Vasquez uses CAF to ensure security is embedded from day one:
- Strategy: Elena identifies customer payment data and manufacturing IP as crown jewels. The board — led by Marcus Chen — accepts moderate risk for general workloads but zero tolerance for payment systems.
- Plan: Li Wei, IT Ops director, assesses the current security posture. They discover 40% of workloads use legacy authentication. Elena adds “eliminate legacy auth” to the adoption plan.
- Ready: She works with the platform team to deploy Azure Landing Zones with mandatory policies — all resources must be in approved regions, all storage encrypted, all public endpoints blocked by default.
- Govern: Azure Policy enforces guardrails automatically. Workload teams cannot deploy resources that violate security baselines.
Without CAF, security would be bolted on after migration — finding problems only when auditors come knocking.
CAF security design principles
The CAF security methodology centres on these principles that shape architect decisions:
- Security is a team sport — Security teams advise, but workload teams own their security posture
- Align security to business priorities — Not every asset gets the same protection level
- Assume compromise and verify explicitly — Direct alignment with Zero Trust
- Build security into the adoption lifecycle — Not as an afterthought
- Use native security capabilities first — Azure-native controls before third-party tools
Well-Architected Framework — Security pillar
While CAF covers the journey, WAF covers the destination. The Security pillar defines five design principles for secure workloads:
| WAF Security Principle | What It Means | Example |
|---|---|---|
| Plan your security readiness | Establish security requirements before design | Define data classification, compliance needs, and threat model before choosing services |
| Design to protect confidentiality | Apply defence in depth to data, access, and communication | Encrypt data at rest and in transit, use private endpoints, apply sensitivity labels |
| Design to protect integrity | Prevent corruption of design, implementation, operations, and data | Immutable infrastructure, code signing, tamper-evident logging |
| Design to protect availability | Ensure the system meets availability targets despite security incidents | Redundant security controls, DDoS protection, backup and recovery design |
| Sustain and evolve your security posture | Continuously improve through monitoring, testing, and automation | Regular security assessments, automated compliance checks, threat modelling updates |
| Aspect | Cloud Adoption Framework (CAF) | Well-Architected Framework (WAF) |
|---|---|---|
| Scope | Organisation-wide cloud journey | Individual workload design |
| When to use | Planning cloud adoption, building platform | Designing or reviewing a specific workload |
| Security focus | Strategy, governance, landing zones, operating model | Architecture patterns, design principles, trade-offs |
| Key output | Landing Zone with policy guardrails | Secure workload architecture with design decisions documented |
| Who drives it | Cloud platform team + CISO office | Workload architect + security team |
| Exam relevance | Questions about security strategy, governance, landing zones | Questions about workload-level design decisions and trade-offs |
Azure Landing Zones — security by design
An Azure Landing Zone is the target Azure environment architecture that implements CAF security principles through automation. It’s the platform foundation that every workload lands on.
Security components of a Landing Zone
| Component | What It Provides | Why It Matters |
|---|---|---|
| Identity baseline | Centralised Entra ID tenant, Conditional Access policies, PIM | All workloads inherit identity controls |
| Management groups | Hierarchical organisation with inherited policies | Policy governance at scale |
| Azure Policy | Automated compliance enforcement | Prevents insecure configurations before deployment |
| Network topology | Hub-spoke or Virtual WAN with centralised security | Consistent network security, centralised inspection |
| Logging | Centralised Log Analytics workspace, Defender for Cloud | Unified visibility across all workloads |
| Security baselines | MCSB-aligned default configurations | New resources start secure by default |
Exam tip: Landing Zones vs custom builds
The exam often presents scenarios where an architect must choose between deploying Azure Landing Zones (with Microsoft’s reference architecture) or building custom infrastructure. The correct answer almost always favours Landing Zones because:
- They encode security best practices automatically
- They scale across multiple workloads
- They align with CAF — which the exam explicitly tests
- Custom builds require justification for every deviation
The exception: when the organisation has unique regulatory or sovereignty requirements that Landing Zones don’t support out of the box. Even then, the architect customises a Landing Zone — not abandons the concept.
☁️ Scenario: Rajan's client architecture review
Rajan Krishnamurthy from Skyline Security Consulting is reviewing a client’s Azure deployment. The client has 15 subscriptions, no management groups, and each team deploys their own networking. Security policies are applied manually per subscription.
Rajan’s recommendation: implement Azure Landing Zones with:
- Management group hierarchy (Platform → Landing Zones → Sandbox)
- Centralised hub-spoke networking with Azure Firewall
- Azure Policy for MCSB compliance at the management group level
- Centralised logging to a shared Log Analytics workspace
Priya Anand, his junior architect, suggests configuring security per subscription instead of using management groups. Rajan explains: “That’s how this client ended up with 15 islands. Management groups enforce consistency — you set the policy once and every subscription inherits it.”
This transforms the client from “15 independent islands” to “one governed platform” — exactly the architect thinking SC-100 tests.
How CAF, WAF, and Zero Trust connect
These aren’t competing frameworks. They work at different levels:
| Layer | Framework | Question It Answers |
|---|---|---|
| Principles | Zero Trust | ”What should we never assume?” |
| Journey | CAF | ”How do we adopt cloud securely?” |
| Platform | CAF Landing Zones | ”What guardrails does every workload inherit?” |
| Workload | WAF | ”Is this specific architecture secure?” |
| Controls | MCSB (next module) | “What specific controls should we implement?” |
The SC-100 exam tests your ability to navigate all these layers. A question might describe a business scenario and ask you to identify which framework guides the decision — or which design principle justifies a particular architectural choice.
💰 Scenario: Ingrid bridges the framework gap
Ingrid Svensson at Nordic Capital Partners encounters a common problem: the platform team used CAF to deploy Landing Zones, but individual workload teams are designing applications without consulting WAF.
Result? The platform is secure (thanks to CAF), but individual applications have unencrypted databases, missing private endpoints, and over-privileged service accounts.
Ingrid’s fix: mandate a WAF Security pillar review for every workload before production deployment. She creates a checklist aligned to the five WAF security principles and makes it part of the change approval process. Harald Eriksen, the compliance officer, embeds the checklist into the audit cycle.
The takeaway: CAF without WAF gives you a secure platform with insecure workloads. WAF without CAF gives you well-designed workloads on an ungoverned platform. You need both.
🎬 Video coming soon
Key takeaways
Knowledge check
Meridian Global is migrating 200 workloads to Azure. Dr. Elena Vasquez wants security embedded from the start. Which approach best aligns with Microsoft's recommended frameworks?
A workload architect is designing a new application on Azure and wants to ensure it meets security best practices. Which framework should guide their workload-level security design decisions?
Ingrid discovers that Nordic Capital Partners' platform team deployed Azure Landing Zones with strong governance, but workload teams are deploying applications with unencrypted databases and over-privileged service accounts. What is the root cause?
Next up: MCRA and Cloud Security Benchmark — the reference architecture and controls that map Zero Trust principles to specific Microsoft security capabilities.