Home / Knowledge hub / Defence in depth
Knowledge hub
Defence in depth
Assume any one control will fail, and have something else behind it.
What it means
Defence in depth assumes any one control will eventually fail, and arranges for something else to stop the attack anyway. NIST describes it as layering different kinds of protection so that what one misses, another catches.
The word different is doing the work. Not the same control twice. A login, then a permission check on every request. Then a cap on what one account can export. Then a log that would show the export happening.
Why it matters
This is why a strong login does not excuse weak permission checks behind it. Passwords leak, sessions get stolen, staff get phished, and none of that involves a bug in your code. Ask of any design what an attacker gets once they are inside as a real user, because eventually somebody will be.
It is also the argument for the unglamorous work. Layers deep inside an application demo badly and nobody asks about them in a sales call. They are the ones still standing when a password turns up in a breach dump. Test any design by what it costs an attacker who already got past the first thing.
How it shows up
The common mistake is stacking layers of the same kind. Three products watch the perimeter and nothing checks whether a signed-in user may read the record they just requested.
Useful internal layers are dull ones. Put authorisation on every request rather than on every screen. Give service accounts least privilege. Cap bulk reads and exports. Keep secrets out of the code. Log in a way that would reveal quiet abuse, not only a crash.
Questions people ask
Defence in depth, answered
Is defence in depth just an excuse to buy more tools?
It becomes one when every layer sits at the perimeter. Buying a fourth product that inspects inbound traffic adds cost, not depth.
Depth means independent controls at different points, and most of the ones that matter inside an application are code you write rather than something you purchase.
How many layers is enough?
There is no number, and anyone quoting one is selling something. The test is coverage, not count.
Take a realistic path an attacker would walk through your product and ask what stops them at each step. Where the answer is nothing, add one control. Where the answer is three of the same kind, you already overspent.
Is zero trust the same thing?
They overlap. Defence in depth says assume a control will fail. Zero trust says stop granting access because of where a request came from, and verify every time.
In practice zero trust is one way of getting depth, and it is not a product you install.
We are a small team with no security staff. Where do we start?
Start with authorisation on every request, a second factor on staff logins, and logs that record who read what. Those three cover most of what actually goes wrong.
Everything else can wait until those work on every endpoint, including the ones added last month.
Can more layers make things worse?
They can. Complexity has its own failure modes, and a control nobody understands tends to get an exception that quietly disables it.
Prefer a few layers your team can explain and test over many they cannot. A control you cannot verify is a belief, not a defence.
Sources
Where this comes from
Related
Terms that sit next to this one
Least privilege
Giving every person and service the minimum access the job requires.
Zero trust
Assuming the network proves nothing, and checking every request.
Access control
The rules deciding which person can see or do which thing in your app.
Rate limiting
Capping how often something can be attempted, per user or per address.
Logging and monitoring
Recording what happens, and actually watching what gets recorded.
What happens once someone is inside?
We test the layers behind the login: permission checks per request, what one account can export, what a lower role reaches. Each finding arrives with proof. Ask about your application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.