Threat modeling has a reputation problem: STRIDE diagrams, three-day workshops, a deliverable that nobody reads. Most teams don't need any of that. They need a small amount of disciplined skepticism, applied early.
Three questions that do most of the work
What can go wrong? Walk through the flow and list the ways it could fail, be misused, or be bent by someone acting in bad faith. Include mundane failures (a timeout, a typo) alongside adversarial ones.
Who benefits from it going wrong? This is the part non-security teams skip, and it's the most productive question. A system that nobody gains from exploiting is different from one where gaining is easy and worthwhile.
How would we notice? If the answer is “we wouldn't,” that's your first finding. Detection is usually cheaper than prevention and always cheaper than discovering a problem months late.
Document by changing behavior, not by writing documents
A threat-modeling session that ends with a document nobody opens again is theater. A session that ends with a changed log, a new alert, a shorter session timeout, or a removed feature is real work.
The goal is enough rigor to make the next decision better, and no more.