Threat Modeling as a Design Practice

Apr 11, 2025

Threat modeling isn’t a security checklist. It’s a design activity. It’s the deliberate act of thinking about what might go wrong in a system before it's built, or while it’s still possible to do something about it.

Despite being around for years, threat modeling has recently gained renewed attention, including a mention in the latest ThoughtWorks Technology Radar. The reason? Teams are starting to treat it less as a specialized security task and more as a regular design habit. And that’s a welcome shift.

What Threat Modeling Actually Is

The premise of threat modeling is simple: every system has assets worth protecting, and every system makes assumptions about what can and cannot happen. Threat modeling is about identifying both, and then challenging those assumptions.

It often revolves around four recurring questions:

What are we building?
What could go wrong?
What are we going to do about it?
Did we do a good enough job?

It’s not a formal method or a framework. It’s a structured conversation, usually centered around architecture diagrams, that helps a team uncover risks and make design choices with intent, not just hope.

Why It Matters in Architecture

Security flaws aren’t always the result of coding mistakes. They’re often a symptom of misplaced trust, implicit assumptions, or blind spots in the architecture itself.

If a service assumes the caller is authenticated because it's “internal,” or if a frontend trusts data returned from an API without verifying it, those are architectural issues. They aren’t going to be caught by linters or firewalls.

Threat modeling shifts the conversation left, before production, before implementation, and puts it in the hands of those making design decisions. It allows teams to reduce the attack surface and build in defense where it’s most effective: at the edges of architectural trust boundaries.

Making It a Habit, Not an Event

One of the most effective things teams can do is lower the barrier to threat modeling. If it becomes a heavyweight activity with forms, templates, and formal reviews, it’ll get deferred until “later.” In most cases, later never comes.

Teams that do this well treat it as a recurring, informal discussion, often baked into sprint planning, story refinement, or design reviews. It doesn’t need to be exhaustive every time. A 30-minute conversation with a whiteboard sketch can go a long way, especially when focused on a single new feature or integration point.

The key is frequency, not completeness. Risks evolve as the system evolves. A “threat model” isn’t a static artifact, it’s a lens to regularly re-examine your system’s weak spots.

How to Run an Effective Threat Modeling Session

Here’s what works in practice, no buzzwords, no silver bullets:

1. Start with a Diagram

Draw how the system works, even if it’s rough. Show components, users, data flows, and especially trust boundaries (e.g., between the browser and backend, between services, between your system and third parties). If you can’t draw it, you probably don’t understand it.

2. Ask “What Could Go Wrong?”

This is the heart of it. Walk through each part of the system and ask:

What if this component is compromised?
What happens if this data is tampered with?
What assumptions are we making about the network, the identity provider, the user?

3. Use Threat Categories If Needed

Many teams use the STRIDE model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) as a checklist. It helps, but don’t follow it blindly. Think of it as training wheels — a way to spark questions, not to gatekeep answers.

4. Prioritize, Don’t Panic

Not every risk needs a mitigation. Some just need documentation. Some are so unlikely they’re not worth addressing now. But some will point to weak spots in the design that should be fixed early. The point is to surface them, discuss them, and make decisions deliberately.

5. Document the Assumptions

Even if you don’t write down a full report, log your assumptions. For example:

“We assume service X cannot be accessed from the public internet.”
“We trust the identity provider’s tokens are valid and time-bound.”
“This system doesn't store PII, so data exposure is low-impact.”

These assumptions are often what come back to bite you six months later, especially during incident response.

Common Pitfalls to Avoid

Even with good intentions, threat modeling efforts can go off track. Here are the traps to watch for:

Trying to cover everything at once – It’s better to model one feature well than the whole system badly. Keep it scoped and focused.
Over-formalizing the process – Threat modeling isn’t compliance. It’s about clarity and critical thinking, not checkboxes.
Doing it once, then forgetting about it – Systems change. So do risks. If you don’t revisit your assumptions, they’ll silently rot.
Relying only on security experts – Engineers, architects, product owners — all of them see different angles. Don’t gatekeep the process.

Threat Modeling in Agile Teams

Traditional security reviews often happened late, if they happened at all. That doesn’t work in iterative environments. Teams need lightweight, repeatable practices that match the pace of delivery.

Some useful strategies:

Incorporate threat modeling in backlog grooming for features that affect trust boundaries or data flow.
Add “evil user stories” (e.g., “As an attacker, I want to bypass rate limits to scrape data”) to uncover threats from an adversary's point of view.
Treat architectural spikes as opportunities to explore security implications, not just technical feasibility.

The point is not to slow down agility, it’s to build security thinking into the process without friction.

Good architecture isn’t just about performance, scalability, or modularity. It’s about trust, knowing where your system is vulnerable and putting the right controls in place.

Threat modeling gives teams the space to challenge their assumptions and clarify their thinking. It’s not just a security technique; it’s a design discipline. And like all good design habits, its power comes from repetition, not complexity.

You don’t need a dedicated security team to start. You just need to care enough to ask, “What could go wrong?” and take the time to answer it while it still matters.

If you like my content enough to pay me a coffee…

Articles I enjoyed this week

Thanks for reading IT Untold! If you like this article please share it with your friends and colleagues

IT Untold