Organizations rarely lose data because a single wall was breached. It usually happens differently: defense at one line held, but the next line simply wasn't there — and the attack passed straight through, via an email that mail filtering missed, or via an administrator account nobody was watching. Each individual product covers its own part of the perimeter, but a gap remains between products, and that gap is exactly where an attacker goes.
Defense in depth is a way of thinking that replaces the question "which single product will protect us" with the question "how many independent lines must an attacker cross to reach the target." This article is a cornerstone piece in the Expertise track: it doesn't cover any single product in depth, but shows how products fit into the overall picture — and which article to start with for each layer.
It's useful for a security architect building a defense strategy from scratch or auditing an existing one, and for a security or L&D leader deciding which skills the team is missing so the layers actually work rather than just show up on a purchase order.
What Defense in Depth Is and Where the Idea Comes From
Defense in depth is a principle under which infrastructure is protected by several independent lines at once, rather than a single universal barrier. If an attacker gets past one line, the next one — built on a different principle — is waiting. Crossing every line in sequence is far harder than bypassing any one of them.
The idea comes from military engineering: a fortress with a single wall falls once that wall is breached, while a fortress with multiple lines of defense forces the attacker to restart the assault each time, buying the defender time to react. The same logic applies in cybersecurity: the time an attacker spends on the second and third line is time you gain to detect the intrusion and stop it before it causes damage.
This differs from simply "buying more products": defense in depth is about the independence of lines, not their number. Two antivirus tools on one endpoint aren't two layers — they're one layer with a duplicate mechanism inside it. A real layer covers a different entry point or a different stage of the attack: email is the entry point, the endpoint is what happens after an attachment is opened, privileged access is what an attacker tries to obtain once already established on the network. Each layer is designed for the situation where the previous one failed.
What Layers Make Up Defense in Depth
The seven layers below aren't an abstract model — they directly reflect the areas already covered by products and training on the platform. Each layer addresses its own class of attacks and its own point in the chain where an attacker can be spotted or blocked.
Perimeter and Network
The network layer meets traffic before it reaches the user or server: it connects distributed infrastructure securely and prevents connections to known-malicious addresses.
The SD-WAN class handles the first task — software-defined wide area networks that manage traffic between offices and clouds independently of the physical communication channels; see "What Is SD-WAN". Secure DNS handles the second: it blocks a request to a malicious domain before the connection is even made — nearly every network interaction starts with a DNS query, which makes this one of the earliest and cheapest lines of defense; see "What Is Secure DNS".
Email as the Main Entry Point
Email remains the primary channel through which an attacker first enters the internal network: a message reaches an employee directly, bypassing perimeter defenses, and a single click on an attachment is enough to start the attack chain.
Mail Security filters inbound and outbound email: it screens out phishing, malicious attachments and links, spam, and BEC attacks (business email compromise carried out without an attachment, through sender spoofing). See "What Is Mail Security". Even an excellent filter lets some messages through, so this layer isn't designed for 100% filtering — it's designed to sharply cut the volume the next layer has to handle.
Endpoints
If a message gets past the filter and the attachment is opened, the next line of defense is what happens on the workstation or server. EDR (Endpoint Detection and Response) continuously collects telemetry from endpoints, recognizes suspicious behavior from a chain of actions rather than just a known file signature, and provides tools for investigation.
The difference from antivirus is fundamental: antivirus checks a file against a list of known threats, while EDR records and correlates actions — which process launched what, what it accessed — and can catch an attack that no signature would identify. Read more in "What Is EDR".
Privileged Access
Once an attacker has established a foothold on an endpoint, the next goal is to escalate privileges and gain access to accounts with elevated rights — these accounts lead to critical systems, which makes this one of the most underrated layers in practice.
PAM (Privileged Access Management) stores privileged account secrets in a protected vault instead of scripts and spreadsheets, grants access by rules and for a limited time, records sessions, and automatically rotates passwords — on a schedule or after every connection. Start with "What Is PAM"; for session control, see "Monitoring and Recording Privileged Sessions".
Application Access and the Zero Trust Model
The privileged access layer controls administrator accounts, but regular users shouldn't be trusted just because they're connected to the network either — that's the core idea of Zero Trust Network Access. ZTNA verifies every application request individually: who is making it, from which device, to which resource, and under what conditions.
The model replaces the principle of "connect and see a lot" with "get access only to a specific application, and only if the policy conditions are met" — this limits an attacker's lateral movement even if a node is already compromised. See "What Is ZTNA".
Processes and Compliance
The technical layers above answer the question "what will stop a specific attack." This one answers a different question: "can you prove requirements are being met, and is the risk visible in full?" Without it, an organization can buy all six technical layers and still fail an audit.
GRC (Governance, Risk and Compliance) brings governance, risk assessment, and compliance control together into a single model, where the same risk is tied to a policy, a control, and a requirement, instead of sitting in a separate spreadsheet owned by a separate department. Start with "What Is GRC"; for risk assessment, see "Risk Management in GRC".
People
The last layer isn't sold as a product, which is exactly why it's most often underrated: every technical line passes through a person who configures a policy, responds to an alert, or decides whether to open an attachment. A trained analyst notices what a correlation rule would miss, while an untrained one can wipe out the value of the most expensive product with a single action.
This layer is covered by hands-on product training on lab environments — the courses are covered below — and by systematic development of the people who work with alerts day after day. On the economics of training, see "Staff Training: The Economics"; on growing a SOC analyst within your team, see "How to Grow a SOC Analyst".
Where to Start If You Have No Layers Yet
If an organization has none of the seven layers, or only one or two, the order matters — not every line pays back its implementation cost equally fast, and not every one is equally critical for a typical attack profile.
A practical priority order:
- Email. The first entry point for most human-involved attacks — the fastest layer to implement and the one with the most visible effect.
- Endpoints. The difference between "we noticed the attack within an hour" and "we found out from a partner a month later": the only layer that sees what already happened inside a node.
- Privileged access. Once you have visibility on endpoints, the next step is to stop the attacker from escalating privileges and reaching critical systems.
- Application access (Zero Trust). Limits lateral movement after a compromise has already happened — a logical step after gaining control over accounts.
- Perimeter and network. Secure DNS deploys quickly and with almost no user pushback; SD-WAN is a longer project.
- Processes and compliance (GRC). Formalizing risk pays off once the technical layers have already produced data on real risks, not just hypotheses.
- People — not last, but alongside every step. The team goes through training before a product goes into production, not after the first missed incident.
This order isn't dogma: if your company has already had an incident through a privileged account, it makes sense to move PAM higher in the queue. Your own risk profile sets the priorities, not an abstract model.
Common Mistakes in Defense in Depth
Duplicate Tools in One Layer While a Neighboring Layer Has a Gap
A common picture: two competing filters sit in the email layer, while endpoints are only partially covered by EDR because "installing an agent on servers feels risky." Two tools in one layer don't create a second line — they create redundancy where there was no breach to begin with, and leave a hole where there's no layer at all. Before reinforcing a layer that already works, make sure every remaining layer has at least one line of defense.
The Tool Exists, But There's No Process Around It
A product that's deployed but not built into the team's daily work creates the appearance of a layer, not an actual layer. A typical example: EDR generates alerts, but no one is assigned to triage them. For an attacker, there's almost no difference between "no EDR" and "EDR exists, but nobody looks at the alerts": detection happened, but the response didn't.
Settings Aren't Reviewed After Deployment
A product left in its baseline configuration, never revisited since deployment, stops matching infrastructure that has since changed: new network segments and employees with different access rights appear, while the policies stay the same. Reviewing settings isn't a one-time action at rollout — it's a process that needs to be as formalized as patch management or password rotation.
Betting on Technology Without Trained People
The most expensive mistake is buying a product for every layer and deciding the job is done. A product provides capabilities, not results: the result appears when a person knows how to review a PAM session, tell an EDR false positive apart from a real attack, and configure a ZTNA policy for a specific application. Without that skill, a set of seven layers works like a fortress with no garrison.
How to Check Yourself: A Layer-by-Layer Checklist
Go through the table and honestly mark the state of each layer — not "is the product purchased," but "does the line actually work in practice."
| Layer | What to check |
|---|---|
| Perimeter and network | DNS requests to malicious domains are blocked, channels between sites are protected |
| Phishing, malicious attachments, and BEC attacks are filtered out before the mailbox | |
| Endpoints | Telemetry covers all workstations and servers, including "inconvenient" nodes |
| Privileged access | Account secrets sit in a protected vault, sessions are recorded |
| Application access | Every application request is checked individually, not trust in the whole network |
| Processes and compliance | Every risk is tied to a specific policy and regulatory requirement |
| People | The team knows how to work with the deployed product, not just install it |
If even one row gets the answer "never checked," that's your current gap — the one an attacker will walk through, even if the product for that layer has formally already been purchased.
Where to Practice Hands-On: Platform Courses
Understanding the model doesn't replace hands-on practice with a specific product: the difference between "I read about PAM" and "I configured a session control policy myself" is the difference between theory and readiness for a real incident. The platform provides isolated lab environments for each layer, not just lecture notes.
It makes sense to start with the layer that's thinnest in your organization today. The "Deploying and Administering BI.ZONE EDR" course covers the endpoint layer — from agent configuration to investigating an attack chain on a real lab environment, no simulators. For privileged access, there's the "Installing and Administering BI.ZONE PAM" course: configuration, session control policies, integration with a user directory. For application access, there's the "Deploying and Administering BI.ZONE ZTNA" course, where Zero Trust becomes a working configuration rather than a model on a slide.
Putting defense in depth together on paper is the first step. The second one — without which the first doesn't work — is training your team to cover each layer hands-on, with a real product.