Threat Model

Anyone who wants to protect something must first know what it needs protecting from. A threat model answers precisely this question in an organized way. You write down what is worth protecting, who might attack it, and what means that attacker realistically has. From this follows which protective measures make sense and which would be a waste. A 15-euro bike lock is sensible against an opportunistic thief and useless against a professional with a battery-powered angle grinder. Both statements are true – they simply refer to different threat models.

Why security is meaningless without an attacker assumption

Sentences like “the system is secure” are meaningless without a threat model. Secure against whom? Against a curious classmate or against a state intelligence agency with a multimillion-dollar budget? Only the attacker assumption makes a security claim verifiable. That’s why every serious security analysis begins with this step.

A threat model also prevents two typical misinvestments. The first: building elaborate defenses against exotic attacks while overlooking the obvious ones. Many data leaks arise not from broken encryption but from weak passwords or a misconfigured database. The second misinvestment is the opposite: underestimating the attacker and protecting too little.

It’s also important what a threat model explicitly excludes. These excluded cases are called non-goals. A messenger app can guarantee that no one can read messages in transit. It offers no protection against someone holding your unlocked phone in their hand. That is not a failure, but a disclosed limitation.

From valuable asset to countermeasure

In practice, one works through four steps. First: What is worth protecting? This could be customer data, money, a service’s availability, or a company’s reputation. Second: Where are the transition points at which data enters or leaves the system? These transition points are called attack surfaces, because that’s where someone can gain a foothold.

Third, one collects possible attacks. There are checklists for this, such as STRIDE, an acronym from English for six types of attack: spoofing as someone else, tampering with data, repudiating actions, information disclosure, denial of service, and elevation of privilege. Such lists ensure that you don’t only think of the attacks that are already on your mind. Fourth, each case is assessed by damage and probability, and a decision is made: defend against it, mitigate it, insure against it, or knowingly accept it.

A threat model is not a document you write once and file away. If the system changes, the threats change. Anyone who opens a new interface for partner companies has created a new attack surface. Good teams revise their model with every major change.

Threat models in AI systems and everyday life

Threat models are currently a particularly hot topic for AI products. Language models – programs like ChatGPT that generate text – have their own vulnerabilities. Prompt injection is a well-known example: an attacker hides instructions in a webpage or email that the model later reads and follows. If the model has access to a mailbox or calendar at that point, real damage can result. A threat model determines which such cases the product is supposed to catch.

In company announcements and security reports, the term usually appears as a justification. A provider might write that a reported attack lies “outside our threat model.” That can be legitimate if the assumption was publicly documented beforehand. But it can also be an excuse if the model was tailored after the fact to fit.

The concept is worth applying privately, too. Before worrying about encryption methods, consider who realistically wants your data. For most people, that means fraudsters with stolen password lists, not intelligence agencies. Very concrete priorities follow from this: different passwords for different accounts, a password manager, and two-factor login, where a second proof is required in addition to the password. That’s a threat model in miniature.