Threat Modeling the Brutalist Way
Jan 2026
Security Brutalism starts from a simple assumption: breaches will happen, so the real question becomes whether you've made intrusion expensive, limited what an attacker can do once inside, and built systems that recover rather than fall apart.
Threat modeling in this approach isn't a framework exercise but disciplined "realism", forcing a security program to look at what actually exists, what can actually be attacked, and what actually fails under pressure so it can survive contact with real adversaries rather than just look good on paper.
That work starts with knowing your assets cold, because you need to know where things live, who can touch them, and what happens if they're lost before you can call any of it security. Real systems, real data, real identities, real dependencies all need names and owners. If you can't say what would cause material damage when stolen, altered, or destroyed, you're performing security theather rather than doing real security.
From there, threat modeling turns into adversarial reasoning about who would realistically target this organization, what they want, and how they'd move through the environment toward something that actually hurts the business. That means tracing how access turns into damage through identity abuse, misconfigurations, trusted connections, third parties, and architectural assumptions nobody questioned, and if the resulting picture doesn't make leadership uncomfortable, it probably isn't close enough to reality.
Mitigation is where this gets mechanical, since every serious attack path needs a real counterforce that blocks it, constrains it, or contains it. Strong identity controls, segmentation that actually isolates, defaults that deny by default, and recovery that holds up under stress all count as counterforce. Noticing an attack helps, but it doesn't protect anything on its own.
Strength here comes from compression rather than accumulation, so a small set of controls you understand deeply will outperform a sprawling stack of tools nobody fully operates. Every control earns its place by how much freedom it takes away from an attacker, and since complexity adds attack surface, keeping things minimal becomes a defensive move in itself.
Testing turns belief into evidence, because brutalist audits try to break systems rather than documents. Controls have to prove themselves against real techniques. Accounts need to actually expire, segmentation needs to actually block traffic, and restores need to actually work when something's on fire, since a control that can't be demonstrated under pressure amounts to decoration.
Resilient systems plan for failure from the start, assuming compromise, outages, mistakes, and misconfiguration will happen, which turns redundancy into a form of survival rather than waste. Independent control layers, immutable recovery paths, and operational fallbacks keep an intrusion from turning into something that ends the business.
Stripped of the theater, threat modeling becomes survivability engineering. It means knowing what's important, mapping how it breaks, and blocking the paths that count, then hardening the smallest set of controls carrying the most defensive weight and testing them until they've earned trust. Building in enough redundancy means failure never has just one outcome.
Security Brutalism isn't elegant or comfortable. It's the discipline of building systems that keep working after the breach has already happened.
A different version of this post was first published on the Security Brutalist Blog.