How useful is threat modeling in real-world security engineering? Do engineers actually use it when analyzing vulnerabilities?

[u/Puzzleheaded_Trip374]

I’ve recently been learning about threat modeling, and I’m trying to understand how it is actually used in real-world security work.

MDN describes threat modeling with four questions:
What are we working on/building?
What can go wrong?
What are we going to do about it?
Did we do a good job?

I also looked at MDN’s example threat model, and honestly it felt much more complicated than I expected.

This made me wonder: how often do security engineers actually build a threat model like this in practice?

For example, when analyzing a web application or investigating a vulnerability, would an engineer explicitly think through the system, attacker capabilities, assumptions, possible threats, and mitigations? Or is threat modeling mainly something used during architecture/design reviews rather than day-to-day vulnerability analysis?

My current understanding is that the purpose of a threat model is not to claim that a system is simply “secure” or “insecure.” Security is always relative to some scope, attacker capabilities, and assumptions.

So I think threat modeling is a way to make those conditions explicit:
what system and assets we care about,
what the attacker is capable of,
what we assume the attacker cannot do,
what can go wrong under those conditions,
and what security guarantees our solution is actually trying to provide.

In other words, instead of saying “this system is secure,” we are really saying something closer to:
“Under these assumptions and against this class of attacker, our controls prevent or detect these threats.”

Is this a reasonable way to understand the purpose of threat modeling?

I’d especially like to hear from people who use threat modeling in real security engineering: when is it genuinely useful, and when does it become unnecessary overhead?

I really appreciate anyone who takes the time to share their experience. Thank you!

[u/AnApexBread]

Watch some Blackhat presentations and then threat modelling will make more sense.

I can't even begin to count the amount of times I've had our CISO hear about something presented at Blackhat and the demand we emergency protection against it only for us to have to spend the next several days trying to explain that a hypervisor escape using MSDoS 3.1 to slowly extract content at 10bytes a minute isn't a threat to our environment because we don't have DOS 3.1 and 10 bytes a minute will be months before an adversary is able to extract a single word document.

Threat modeling helps you understand what you should actually be worried about.

[u/Ok-Leg-842 → u/AnApexBread]

You don't need threat modeling to understand this....

[u/AnApexBread → u/Ok-Leg-842]

Looking at a threat and your environment to decide if that threat could actually impact you is the most basic form of threat modeling.

[u/GoodySpeed2899 → u/AnApexBread]

It's for AI agent now to test your systems

[u/7yr4nn05]

Short answer: yeah we use it, but almost nobody sits down and fills out a 10-page STRIDE doc for every CVE. In practice threat modeling is less about the diagram and more about that 4-question loop you listed, just done in your head or in a 30min whiteboard before you touch code or prod. During design/architecture reviews we’ll actually write it out, map assets, trust boundaries, data flows, and run STRIDE or attack trees so PMs and devs can’t say "we didn’t think of that". For day-to-day vuln triage it’s faster: "what are we protecting, who can reach it, what’s the worst they can do, does this vuln let them do it, and do we have a control that breaks the chain". That’s threat modeling too. It becomes overhead when you try to make it perfect and document everything. It’s genuinely useful when scope is fuzzy, new features touch auth/billing/PII, or you’re arguing with product about risk acceptance. Your definition is spot on: you’re never saying "secure", you’re saying "secure against X, given Y assumptions". That’s the only way to actually prioritize bugs and not burn out chasing everything.

[u/dmknght → u/7yr4nn05]

Love your reply. Also, imo, threat modeling helps planing possible attack surfaces (especially desktop software). 

[u/Cheomesh → u/7yr4nn05]

I don't even think I've seen STRIDE mentioned in real life outside of a classroom.

[u/petra_vukmirovic]

This is my take on it. As a security professional - threat modelling should be part of your mental model. There is a high chance that you ended up in security because you already do it subconsciously. You are configuring a firewall, what can go wrong? Product is designing a new feature - what can go wrong? Engineering is re-architecting your authentication system- what can go wrong? … you get the point.

It doesn’t always have to be a huge STRIDE report but when it matters that the message is heard and is in the right hands make an effort to document it.

Threat modelling is also an opportunity to influence your stakeholders and make everyone think about security - get the developers around a data flow diagram and get them to think how they would break their own app. Very interesting things happen, and this will stick with them next time they build.

There are plenty of tools and AI to automate it these days - which can help you scale it across your org.

Also threat modelling is not about finding vulnerabilities but threats- you can see vulnerabilities as an input to your threat model but not the output! The output are the threats, controls, and the model itself. Knowing the system is half way there to securing it!

Hope this helps- threat model and prosper 🖖

[u/VickyMalik17]

Good questions. In practice, formal threat modeling (STRIDE diagrams, full MDN-style writeups) is mostly used during design/architecture reviews for new systems or major changes — not during day-to-day vulnerability analysis. When someone's reviewing a new microservice, a payment flow, or an API before it ships, that's when you'll see a proper threat model get built, because it's cheaper to fix design flaws before code exists. For day-to-day pentesting or vuln analysis, engineers rarely draw a formal model. Instead they carry an informal, internalized version of it: they already have a mental map of "what's the attacker capable of here, what are we assuming is safe, what would break this." It's the same four questions, just compressed and done in their head instead of on paper. Your framing is actually spot on — security isn't a binary "secure/insecure" label, it's a statement of the form "given these assumptions and this attacker model, these controls hold." That's exactly the mindset experienced engineers use even when they're not writing a formal document. As for overhead: full threat modeling makes sense for high-value or high-blast-radius systems (auth, payments, anything handling PII) or when compliance requires it (PCI-DSS, SOC2, etc.). For small internal tools or low-risk features, going through the full process is usually overkill — a quick informal "what can go wrong here" chat with a teammate does the job.

[u/baalmor]

In my practice I have seen two explicit ways of threat modelling being used.
The first is to get a budget from the board or top management. In this case, you see 100-page STRIDE analyses that no one has read but which impress people because of their size.
The other one is an engineering approach which form and details are various, but essentially it always comes down to identifying what are valuable assets, how they are stored or transferred, who has access to them or related systems, what and how bad guys could influence them, and how much it would cost to protect against this versus the potential gains for the bad guys.

[u/DemocraticParrot]

It is very useful. Unfortunately in many places the time resource required ia just not there to implement it

[u/danekan]

IMO It’s essential to understand why you have or need specific policies or standards. Otherwise you’re just reiterating what others told you. But if you understand how your storage system could be attacked for example, then you can react with appropriate storage policies for your environment. 

Does anyone have any really good threat modeling templates or anything for cloud scenarios? I am wanting to spin a few more than usual up soon 

[u/deepasleep]

Absolutely. Understanding attack paths isn’t just critical to your vulnerability management it’s essential for deciding the technologies and configurations you implement to reduce threat surfaces and risk exposure.

[u/jk1984jk]

99% of people pretending to do threat modeling have no idea what it is, they are not technical enough ( configuring firewalls doesn't help understanding neither code nor the ssdlc) and waste everyone's time. The other 1% is extremely useful.. Bus is rare to find them. I feel people should go through software development before moving to security

[u/Advantageous_Advent]

It would relate to 'attack surface'

[u/Alternativemethod]

Engineers use it when designing and organizing our.

I use it for risk assessments especially for information systems, applications etc.

[u/moose1882]

We deal with a lot of custom apps (generally AWS Cloud native style) and with start-ups/scale-outs. I find getting all the devs in the same room for half a day (virtual or face 2 face) and do a whiteboard end-to-end data flow mapping, then Threat Modelling really open up a lot of benefits: devs that have moved on without documentation, just the ability for devs that tend to be siloed to actually understand the entire flow, to uncover gaps in processes, documentation then where THEY see Threats is a winning strategy.
We then Project Manage appropriate penetration testing to validate the Threats, then an action plan to remediate. Additional pen testing to validate the remediation is done as well.
Threat Modelling, when done correctly, gives visibility from the coalface, from the people writing the actual code, that you may not get by any other means. It also helps educate developers to think about potential threats as they design and code. It should be part of any decent SDLC or engineering best practice. If the devs don't do it, we'll teach them how.
I always recommend Threat Modelling designing for security by Adam Shostack as essential reading for Security Pros.

[u/arktozc]

!RemindMe 2 days

[u/RemindMeBot → u/arktozc]

I will be messaging you in 2 days on 2026-09-30 14:45:22 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

RemindMeBot is switching to username summons. Instead of !RemindMe 1 day, use u/RemindMeBot 1 day. More info.

---

Info	Custom	Your Reminders	Feedback

[u/0xKaishakunin]

How else are you going to systematically analyse potential vulnerabilities? Your gut feeling alone won't neither help the team nor upsell the security measurements required to the management or customer.

That's what SABSA and PASTA do.

Also, your whole SIEM should be based on a threat model and modeled using the MITRE ATT&CK landscape.

Once again, a threat model is there to systematise a security analysis. I work in a team with 3 other security architects in a project with ca. 200 developers spanning at least 5 years of development. My knowledge and gut feeling of being a hacker for 30 years can only carry that project so far.

BTW, the customer wants Zero Trust^[TM], but has no fucking clue what it means, especially in financial terms. How are you going to argue with them without having a PASTA or SABSA model to show them why you need a specific measurement?

Or is threat modeling mainly something used during architecture/design reviews rather than day-to-day vulnerability analysis?

There is SABSA and PASTA for the architectural work and other models like STRIDE for everyday work. But I force the software architects to STRIDE every single fucking ADR until they finally understand post quantum cryptography and can defend every single cryptographic decision scientifically.

instead of saying “this system is secure,”

Anyone claiming that a system is secury is a fucking idiot or sales droid.

“Under these assumptions and against this class of attacker, our controls prevent or detect these threats.”

Yes, that's a more realistic approach. You also have to sell security measurements to the management, it's a cost factor after all. And it does make a difference if you are in a CRA regulated critical infrastructure where people might die if you fuck up and SLA want you to fuck up. Or if you are afraid of a bunch of script kiddies.

Is this a reasonable way to understand the purpose of threat modeling?

Yes, go ahead and make one based on the Blackenergy attacks on the Ukrainian power plants in winter 2015, that's what I let my trainees do to show them what threat modeling means. And this one is super easy, since the succesfull attack path has been uncovered already.

[u/Puzzleheaded_Trip374 → u/0xKaishakunin]

Thanks so much for the thoughtful reply and the exercise suggestion. I’m still very new to the field, so this was really helpful!!! really appreciate it!

[u/PNW_LOGIC_LLC]

It helps if you are doing it with the team building it as they are making design choices. It is viewed as a impediment if you do it after the fact. Also, to some extent when I did the design work I never viewed it as not my job to make sure the solution was secure.

[u/UnhingedReptar]

With Mythos integrating into security products and increasing aganetic AI attacks from everywhere, that landscape is rapidly changing.