Azure Defense in Depth: Build Security Layers That Still Work When One Fails

An Azure architecture is not defense in depth merely because its diagram contains many security products. Two firewalls that depend on the same administrator, the same route, and the same unmonitored exception can fail as one control. A storage account can be encrypted and still disclose every document to an identity with excessive permission. Logs can be collected and still provide no protection if nobody owns the alert or has authority to contain the incident.

The useful question is therefore not, “How many controls did we deploy?” It is:

If one control fails, which independent layer prevents the attacker from completing the next step, which signal reveals the attempt, who contains it, and how do we recover safely?

This is the first detailed note in a 12-topic Module 1 study plan for Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course. The Module 1 review remains the map of DDoS protection, firewalls, just-in-time access, and encryption. This article goes one level deeper: it turns the idea of layered security into a repeatable architecture and evidence method.

These are independent study notes, not a transcript, assessment answer, or claim of completed Azure deployment. Course concepts are separated from Microsoft documentation and from the design reasoning developed here. Product and framework terminology was reviewed against Microsoft Learn on August 10, 2026.

1. The question this article answers

How do we design overlapping Azure security layers so that they reduce different failure modes instead of creating the appearance of protection?

By the end, you should be able to:

• explain defense in depth without listing products;
• distinguish it from Zero Trust, shared responsibility, and a landing zone;
• map a realistic attack path across identity, edge, network, compute, application, and data boundaries;
• attach prevention, detection, containment, recovery, evidence, and ownership to every important step;
• identify controls that appear separate but share one hidden failure point; and
• run an architecture tabletop before spending money on Azure resources.

You need only basic familiarity with subscriptions, virtual networks, identities, applications, and data stores. This article intentionally avoids portal steps, CLI commands, and Terraform because the deliverable is a threat-informed design, not an unverified deployment recipe.

2. A practical definition of defense in depth

Microsoft’s introductory Azure model describes seven layers: physical security, identity and access, perimeter, network, compute, application, and data. The model is valuable as a checklist, but the number seven is not a purchasing list and it is not a guarantee that every workload needs seven separate Azure products.

A more operational definition is:

Defense in depth
= controls that reduce different attack or failure conditions
+ signals that show whether each control worked or was bypassed
+ containment and recovery when prevention fails
+ an owner who can act within an agreed time

The layers should create repeated decisions for an attacker. Passing the public application edge should not automatically grant access to the application tier. Running code in the application tier should not automatically grant broad data access. Obtaining a data credential should not automatically allow deletion of the recovery copy. Acquiring one administrative role should not automatically permit changing controls, suppressing logs, and destroying backups.

This framing produces four useful tests.

1. Different failure: Does the next control address a failure that the previous control does not?
2. Real enforcement: Must the attack actually pass through the control, or can it use another endpoint, route, identity, or protocol?
3. Observable result: Can we distinguish allowed use, a blocked attempt, a bypass, and a disabled control?
4. Recoverable state: If the attacker succeeds or the control blocks legitimate work, can we return to a trusted state?

A control that fails all four tests may still add cost and a diagram icon, but it is not a dependable layer.

3. Start with responsibility, not with an Azure service

Defense in depth begins with knowing who owns each part of the stack. In the cloud shared responsibility model, Microsoft protects the underlying cloud infrastructure, while customer responsibilities change with the service model.

Boundary	IaaS example	PaaS example	Responsibility that remains with the customer
Physical facility, host, hypervisor	Operated by Microsoft	Operated by Microsoft	Understand provider scope and design workload resilience
Guest OS and runtime	Customer operates the VM OS and runtime	More of the stack is operated by Microsoft	Configure the service securely and understand what the platform does not manage
Application	Customer deploys and operates the code and configuration	Shared: Microsoft operates the platform and runtime; the customer owns deployed code and configuration	Secure design, dependencies, authentication, authorization, and input handling
Identity and access	Customer-managed roles and access paths	Customer-managed roles and access paths	Accounts, MFA, Conditional Access, RBAC, privileged access, and reviews
Data	Customer data in the workload	Customer data in the managed service	Classification, authorization, retention, encryption choices, backup, and legal obligations

The model is not a fifty-fifty division. A real solution can combine virtual machines, managed databases, SaaS administration, and third-party services, so the boundary must be evaluated component by component.

Two errors follow from skipping this step:

• “It runs in Azure, so Microsoft secures the workload.” Microsoft secures the provider layer, but it does not choose the customer’s RBAC assignment, patch a customer-managed guest OS, validate application input, or approve data retention.
• “I configured it, so I own the whole failure.” The customer should not invent controls for the physical host or hypervisor. The design should use provider commitments, service health information, availability features, and a recovery strategy at that boundary.

Write the owner beside every layer. If the owner is “Azure,” name the service commitment or provider capability that the design relies on. If the owner is the customer, name the accountable team, the configuration source, the signal, and the response action.

4. Defense in Depth, Zero Trust, and landing zones are different tools

These concepts reinforce one another, but they answer different questions.

Concept	Question it answers	Dangerous shortcut
Defense in Depth	If one control fails, what independently prevents, detects, contains, or helps recover from the next attack step?	“Deploy more security products.”
Zero Trust	What evidence allows this identity, device, workload, or flow to perform this action now, with what minimum privilege?	“Put everything behind Conditional Access and call it complete.”
Shared responsibility	Which security task belongs to Microsoft, the customer, or both for this component and service model?	“Azure owns cloud security.”
Azure landing zone	Which organization-wide platform boundaries, policies, connectivity, logging, and delegated responsibilities should every workload inherit?	“Deploy the accelerator and every workload is secure.”
Well-Architected Security	How should this workload protect confidentiality, integrity, and availability while balancing reliability, cost, performance, and operations?	“Pass a checklist once.”

Microsoft’s Zero Trust guidance centers on three principles: verify explicitly, use least privilege, and assume breach. Defense in depth supplies places to apply those decisions. “Assume breach” is the direct connection: a primary control can fail, so another control must limit the blast radius and provide a new decision or signal.

Zero Trust does not remove network controls. It removes implicit trust based only on network location. An administrator on a private network still needs a verified identity, an appropriate device and session context, time-bound privilege, an approved path, and audited activity. Segmentation remains useful because an authenticated identity or workload can be compromised.

An Azure landing zone can establish organization-level guardrails such as management-group structure, policy inheritance, central identity, connectivity, security monitoring, and delegated subscription ownership. It does not secure application code, select data permissions, or operate incident recovery for every workload. The platform team builds safe roads and guardrails; the workload team still designs, drives, observes, and recovers the vehicle.

5. Read the seven layers as security questions

The classic layers become more useful when each is phrased as a question and paired with evidence.

Layer	Design question	Customer decisions or dependencies	Representative evidence
Physical/provider	Who protects facilities, hardware, the physical network, and the virtualization layer?	Service model, region and zone choices, provider commitments, recovery assumptions	Service documentation, architecture decision, resilience test
Identity and access	Who or what can change Azure resources and reach workload functions?	Microsoft Entra controls, RBAC, PIM, managed identity, emergency access	Sign-in record, role assignment, activation record, Activity Log
Perimeter/edge	How does untrusted traffic reach a public endpoint, and how is availability protected?	Public exposure, DDoS design, HTTP edge, origin restrictions	Endpoint inventory, WAF/DDoS metric, origin access test
Network	Where may traffic move after it enters or after a workload is compromised?	Segmentation, NSG, route, firewall, private connectivity, egress policy	Effective route and rule, flow or firewall log, deny test
Compute	How is execution on a VM, container, or host hardened and observed?	Patch, baseline, endpoint protection, image provenance, administrative path	Vulnerability state, process alert, configuration record, rebuild test
Application	How does the application reject abuse carried inside an allowed protocol?	Authentication, authorization, validation, dependency and secret handling, secure delivery	Test result, application event, WAF correlation, release evidence
Data	Who may read, change, export, delete, or recover the final asset?	Data-plane permission, encryption and key choice, retention, soft delete, backup	Access log, key event, delete protection, restore result

Monitoring and recovery cut across all seven layers. A SIEM is not an eighth wall that automatically repairs weak controls. It is part of the observation and response plane. Likewise, backup is not only a data-layer checkbox; its identity, network path, key dependency, immutability, and restore authority need their own layered design.

One service can contribute to more than one layer. Key Vault can support application secret handling and data-key governance. Azure Firewall can be involved at an edge or an internal network boundary. Microsoft Defender for Cloud can provide posture and workload-protection signals across several resource types. The model organizes security questions; it does not force a one-product-to-one-layer mapping.

6. Design from an attack path

Before choosing a control, write the following worksheet.

Asset:
Business impact if disclosed, changed, or unavailable:
Threat actor and objective:
Entry point:
Trust boundaries crossed:
Attack steps:
Preventive control at each step:
Observable signal:
Containment owner and target time:
Recovery path and proof:
Residual risk and approver:

The worksheet forces the architecture to connect business impact, technical flow, operations, and evidence. A generic statement such as “protect the data with Azure security services” cannot survive it. Which data? From whom? Through which identity or endpoint? What does “protect” mean: confidentiality, integrity, availability, or all three? What happens when prevention misses the attack?

Use at least three attack paths for an important workload:

1. an external actor abusing a public application path;
2. a compromised identity or administrator changing the control plane; and
3. a compromised workload moving internally or abusing its own data permission.

Those paths exercise different layers and reveal common dependencies that a perimeter-only threat model misses.

7. Scenario: a partner document-upload service

Consider a service that receives sensitive documents from business partners. The public edge accepts HTTPS uploads. A private processing workload extracts approved fields and writes the result to a private data service. The processor uses a managed identity. Administrators use a governed private management path. Security and activity logs go to a separately governed monitoring scope. Recovery copies have deletion protection and a tested restore process.

External partner
    │ authenticated HTTPS upload
    ▼
Public application edge
    │ allowed application flow
    ▼
Private document processor ── managed identity ──► Data service
    │                                                │
    └──────── workload and security signals ─────────┤
                                                     ▼
Control plane: Microsoft Entra ID + RBAC + Policy + Activity Log
Observation: workload logs + security alerts + incident workflow
Recovery: trusted source + protected backup + redeployment procedure

This diagram is intentionally product-light. Front Door, Application Gateway, Web Application Firewall, Azure Firewall, Private Link, virtual machines, containers, or managed application services might implement parts of the design, but the right combination depends on protocol, scale, threat, latency, cost, and operating capability. Adding every service would not make the design automatically safer.

Now follow one plausible attack sequence.

1. The attacker takes over a partner account.
2. The attacker sends a malicious document through valid HTTPS.
3. A parser vulnerability permits code execution in the processing workload.
4. The compromised processor probes internal endpoints.
5. It attempts to use the processor’s managed identity to read more documents than required.
6. It tries to change a network rule or suppress a log path.
7. It attempts to destroy data and recovery copies before extortion or exfiltration.

No single firewall can answer this sequence. The traffic is initially authenticated and uses an allowed protocol. The next defense must come from application validation and isolation, workload hardening, identity scope, network segmentation, control-plane authorization, independent logging, and protected recovery.

8. Convert every attack step into an operating contract

Attack step	Prevent or reduce	Detect	Contain and recover	Evidence to retain	Residual risk
Partner account takeover	Strong authentication, risk-aware access, least privilege, short sessions	Risky sign-in, unusual device or session, upload anomaly	Revoke session, restrict account, preserve request context	Sign-in and application correlation ID, response timeline	A valid session can still be abused before detection
Malicious upload	Authentication, file type and size policy, content validation, isolated processing	WAF and application event, parser error, sandbox signal	Quarantine object, stop processing, block repeated source behavior	Sanitized request metadata, file hash, detection result	A novel payload can bypass known checks
Processor compromise	Hardened image, patching, minimal runtime, endpoint protection, restricted execution	Process or behavior alert, integrity change, abnormal outbound connection	Isolate workload, revoke its identity, rebuild from trusted source	Alert timeline, image version, changed-resource inventory	A zero-day can execute before detection
Internal movement	Explicit routes, subnet boundaries, private endpoints, narrow east-west and egress rules	Denied flow, firewall event, unexpected DNS or destination	Quarantine source segment or workload, block destination path	Effective routes and rules, positive and negative flow tests	Allowed business traffic can be abused
Data access through workload identity	Resource-specific identity and minimum data-plane role, separation of read/write/delete	Data access and key-operation anomaly	Revoke assignment or identity, rotate dependent material, scope investigation	Role assignment, access record, before/after permission	Authorized operations can look legitimate
Control-plane change	PIM, approval, conditional access, Policy guardrails, separation of duties	Activity Log, policy drift, role change alert	Disable session, revert known-good configuration, invoke emergency process	Activation record, change diff, rollback result	A privileged insider can use an approved path
Data or backup destruction	Separate recovery authority, soft delete, immutability where supported, protected key and backup scope	Delete, retention, backup, and key alert	Freeze destructive access, restore to isolated scope, validate integrity	Restore test, recovery point, recovery time, approval record	Recovery might exceed business tolerance

The table is an operating contract, not a product checklist. Each row can be assigned to a team and tested. If a row has prevention but no signal, the organization cannot know that the control was bypassed. If it has a signal but no owner or containment authority, detection becomes a notification service. If it has backup but no restore proof, recovery is an assumption.

9. Five tests for a real layer

9.1 Independence

Ask whether two controls share an identity, configuration source, path, region, key, or administrator. An NSG and a central firewall may filter at different points, but they are not operationally independent if one overprivileged automation identity can disable both and erase their logs.

Independence does not require a different vendor for every control. It requires understanding correlated failure. Separate roles, protected log destinations, policy enforcement, change approval, and recovery ownership can create meaningful independence within one cloud platform.

9.2 Enforcement

A policy diagram is not a packet path. Confirm that intended traffic must cross the enforcement point.

• Can the origin be reached directly, bypassing the application edge?
• Does a route actually send egress or east-west traffic through the intended firewall?
• Does a private endpoint coexist with an unnecessary public endpoint?
• Can a workload use a different identity, credential, or data API?
• Does an emergency path bypass every normal approval without compensating monitoring?

Test an allowed flow and a nearby denied flow. A successful request proves only availability. The negative test is what exposes broad rules, bypass paths, and shadowed controls.

9.3 Observability

For every control, define four observable states:

1. normal allowed activity;
2. activity blocked by the control;
3. activity that bypassed or evaded the control; and
4. the control being disabled, degraded, or misconfigured.

The third state is often hardest because a bypass might not produce a log at the expected enforcement point. Correlate identity, control-plane, network, workload, application, and data events. Preserve timestamps and identifiers that let an investigation connect them without recording unnecessary sensitive content.

9.4 Ownership

An alert owner must possess the authority and context to act. A central security team might detect an application anomaly but need the workload team to safely stop processing. A platform team might own a firewall but not know whether a destination is business-critical. Define the decision path before the incident.

Record:

• who acknowledges the alert;
• who can isolate identity, network, workload, and data access;
• the target time for each decision;
• who approves a risky exception;
• how business owners are informed; and
• who declares the recovered state trustworthy.

9.5 Recoverability

Recovery is a security layer only when the organization can prove that the recovered state is trusted. Restoring a compromised image, an overprivileged role assignment, or an attacker-controlled secret recreates the incident.

A recovery test should verify:

• the recovery copy is available and protected from the compromised authority;
• required keys and identities remain usable through the recovery process;
• infrastructure and application artifacts come from trusted sources;
• restored data passes integrity and access checks;
• networking and monitoring are active before service reopening; and
• recovery time and data loss remain inside the approved business tolerance.

10. Common-mode failures defeat multiple layers at once

The most dangerous architecture weakness is often not a missing product. It is one dependency shared by supposedly independent layers.

Common dependency	Why several layers can fail together	Better design question
One permanently privileged administrator	Can change identity, network, logging, key, and recovery settings	Which destructive actions require time-bound privilege, approval, or separate authority?
One broad managed identity	A processor compromise becomes broad data and control access	Can read, write, delete, and management permissions be separated and resource-scoped?
A direct public origin	Bypasses DDoS/WAF edge policy and its telemetry	Can origin access be restricted to the intended service path?
Logs in the same authority boundary	An attacker can change the workload and erase its evidence	Is important telemetry retained in a separately governed destination?
Deletable backup and keys	Destructive access removes both production and recovery	Are recovery authority, retention, and required keys protected independently?
Permanent exceptions	Temporary bypass becomes the real production policy	Does every exception have a reason, owner, scope, expiry, and review signal?
One region, DNS path, certificate, or firewall	A security dependency becomes an availability dependency	What is the safe degraded mode and tested recovery path?
Alert owner without response rights	Detection occurs but containment waits	Do the on-call role and runbook grant bounded emergency action?

This is also why “more controls” can reduce reliability. Additional inspection, identity, certificate, route, and policy dependencies introduce latency, cost, failure states, and operational work. The Azure Well-Architected Security principles should be balanced with reliability, cost optimization, operational excellence, and performance efficiency. A right-sized, tested control is stronger than an advanced feature that nobody can operate safely.

11. A zero-cost architecture tabletop

You can test the reasoning before creating Azure resources.

1. Draw the actual or proposed data flow, including the control plane, administrator path, telemetry, and recovery path.
2. Mark three important assets and describe the confidentiality, integrity, and availability impact for each.
3. Mark every external and internal trust boundary.
4. Draw at least three attack paths: public application abuse, privileged identity compromise, and compromised-workload movement.
5. For every step, write prevention, signal, containment owner, recovery action, and residual risk.
6. Remove one control at a time. Ask whether the remaining design still limits damage and reveals the attempt.
7. Identify shared identities, routes, keys, regions, logging destinations, and administrators.
8. Define one positive and one negative validation for each enforcement point.
9. Define the evidence artifact and remove sensitive or identifying data before retention or publication.
10. Record unresolved risk, the approving owner, and a review date.

The expected result is not a diagram full of Azure icons. It is a matrix in which every important attack step has an independent decision, an observable signal, an authorized owner, a recovery path, and an explicitly accepted residual risk.

12. Evidence: what each artifact proves and does not prove

Artifact	It can support this claim	It does not prove this by itself
Architecture and data-flow diagram	Scope, components, trust boundaries, intended paths	That production traffic follows the path
Effective route and rule export	Current configuration at an enforcement point	Continuous operation or absence of another path
Positive and negative flow test	One intended flow was allowed and one unintended flow was denied	That every attack is blocked
Sign-in, activity, security, or application event	The event reached an observable system	That a person investigated or contained it
Incident timeline	Detection and response sequence for the exercise	That recurrence has been prevented
Restore test	A selected recovery point could be restored under test conditions	That every backup is current, complete, and trusted
Owner and review date	Accountability and intended maintenance	Technical effectiveness of the control

Good evidence ties a claim to a repeatable observation. Ten screenshots with no expected result are weaker than one test record that says what was attempted, where it was enforced, what signal should appear, what actually appeared, and which limitation remains.

For a public learning note, sanitize tenant names, subscription identifiers, resource identifiers, addresses, account details, and security-sensitive topology. Evidence should demonstrate the method without publishing an attack map of a real environment.

13. Six common objections

“Isn’t one central firewall enough?”

No. A firewall can enforce selected network flows, but it does not validate every application request, govern Azure control-plane privilege, constrain every data permission, patch a workload, or prove recovery. It is one enforcement point in a larger attack path.

“Doesn’t Azure already secure all of this?”

Azure protects the provider infrastructure and supplies security capabilities. The customer still decides exposure, identity, roles, configuration, application behavior, data policy, monitoring ownership, and recovery within the customer responsibility boundary.

“Does Zero Trust make layered security obsolete?”

No. Zero Trust rejects implicit trust and guides access decisions. Defense in depth ensures that a mistaken or compromised decision does not become unrestricted progress. Identity is a primary perimeter, but a compromised identity is exactly why network, workload, application, data, detection, and recovery layers still matter.

“If data is encrypted, isn’t the data layer complete?”

No. Encryption can protect confidentiality under defined key and access conditions. It does not stop an authorized identity from reading data, prevent an application from exposing plaintext, establish retention, prove integrity, or guarantee that keys and backups survive a destructive incident.

“If every log goes to a SIEM, is detection solved?”

No. Logs need correct sources, usable fields, time correlation, retention, detections, tuning, ownership, authority to respond, and tested playbooks. A centralized log collection with no response contract is storage, not defense.

“Does a higher posture score prove the workload is secure?”

No. Posture findings help prioritize configuration work. They do not replace threat modeling, path validation, application testing, negative security tests, incident exercises, or restore evidence. A score is an input to risk management, not a certificate of safety.

14. Architecture review checklist

Scope and design

• Important assets and business impact are written down.
• Control-plane and data-plane actions are separated.
• External and internal trust boundaries are visible.
• At least three realistic attack paths are modeled.
• Microsoft and customer responsibilities are explicit for every component.
• Each control reduces a different failure condition or has a documented reason for overlap.

Enforcement and observation

• The actual enforcement point and traffic or identity path are verified.
• No unintended public endpoint, route, credential, or emergency path bypasses the control.
• Both an allowed test and a nearby denied test are defined.
• Every important attack step produces a searchable signal.
• Control disablement and policy drift are observable.
• Important logs are protected from the authority that can compromise the workload.

Operations and recovery

• Alert owners have the context and bounded authority to contain the incident.
• Exceptions have a reason, scope, owner, expiry, and review signal.
• Identity, key, route, region, log, and backup common-mode failures are reviewed.
• Isolation, rollback, rebuild, and restore procedures have expected results.
• Recovery returns identity, network, monitoring, and data to a trusted state.
• Residual risk and its approving owner are recorded.

15. Self-review questions

1. What separates defense in depth from deploying three security products?
2. If an administrator identity is compromised, which actions can network controls limit, and which can they not limit?
3. If a web application firewall misses an allowed HTTPS payload, how do the application and data layers limit the outcome?
4. How can segmentation fail even when both NSGs and a central firewall exist?
5. Why can detection fail even when every log is in one workspace?
6. Why does encryption not stop data exfiltration by an authorized identity?
7. Which identity, route, key, region, or administrator is the largest common failure point in the current design?
8. What residual risk appears if one selected control is removed?
9. Which three artifacts provide the strongest evidence that the architecture behaves as intended?
10. If prevention fails, who owns containment and who declares the recovered state trustworthy?

If an answer names only an Azure product, ask again: which attack step, enforcement point, signal, owner, recovery action, and residual risk does that product address?

16. One-page memory card

Asset
→ Business impact
→ Trust boundary
→ Attack path
→ Independent control
→ Observable signal
→ Containment owner
→ Recovery evidence
→ Residual risk

The memory line is:

Defense in depth does not promise one perfect stop. It requires a separate trust decision, control, and piece of evidence each time an attacker tries to advance.

The next Module 1 notes will apply this method to topics including DDoS protection scope, DDoS IP Protection versus Network Protection, private VM design, VNet and NSG fundamentals, Azure Firewall design and validation, JIT access, Key Vault key lifecycle, and managed-disk encryption. They remain planned until each article is complete; no empty route is created for them.

References

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Describe defense in depth
• Microsoft Learn: Shared responsibility in the cloud
• Microsoft Learn: Zero Trust overview
• Microsoft Learn: Azure Well-Architected Security design principles
• Microsoft Learn: Azure Well-Architected Security checklist
• Microsoft Learn: Azure landing zones
• Microsoft Learn: Azure landing zone security design area
• Microsoft Learn: Security architecture design
• Microsoft Learn: Network security and connectivity strategies
• Microsoft Learn: Microsoft cloud security benchmark