DREAD is a risk-scoring model Microsoft introduced alongside STRIDE in the early 2000s: once STRIDE has told you what kind of threat you're looking at, DREAD gives you a number for how bad it is. Rate five factors — Damage, Reproducibility, Exploitability, Affected Users, Discoverability — from 1 to 10, average them, and you get a single risk score you can use to sort a backlog of threats. It was one of the first attempts to make threat prioritization systematic instead of gut-feel, and for a while it was the default pairing with STRIDE in Microsoft's own SDL guidance.
Quick definition: DREAD is a five-factor threat-scoring model — Damage, Reproducibility, Exploitability, Affected Users, Discoverability — each rated 1–10 and averaged into a single risk score. Microsoft deprecated it internally in the mid-2000s in favor of a simpler High/Medium/Low bug bar, and most teams today reach for CVSS instead.
The five factors
| Factor | Question it answers | High score (10) looks like |
|---|---|---|
| Damage | How bad is the impact if this is exploited? | Full system compromise, mass data loss, total service outage |
| Reproducibility | How reliably can the attack be repeated? | Works every time, no special conditions or timing required |
| Exploitability | How much skill or tooling does the attack need? | A beginner with a browser and no special tools can do it |
| Affected Users | What proportion of users or systems are exposed? | All users, or the entire installed base |
| Discoverability | How easily would an attacker find this? | Obvious from public documentation, error messages, or a quick scan |
Score each factor from 1 to 10, average the five numbers, and you get a DREAD score out of 10. Run the same exercise across every threat STRIDE surfaced, and you have a ranked list — which is exactly what most teams need after a threat modeling session: not just "here are twelve things that could go wrong," but "here are the three to fix this sprint."
Why most teams moved on
DREAD's core problem is that "1 to 10" invites false precision. Two reviewers scoring the same threat routinely land three or four points apart on Exploitability or Discoverability, because those factors are judgment calls dressed up as numbers — there's no rubric defining what separates a 6 from a 7. Average five subjective 1-10 guesses together and the result looks rigorous — a score like "7.2" — while actually encoding whoever happened to be in the room that day. Microsoft's own SDL team ran into this in practice and quietly moved to a simpler High/Medium/Low bug bar in the mid-2000s, because a coarser scale was more consistent across reviewers than a false-precision numeric one.
The other issue is overlap. Reproducibility and Exploitability frequently move together — an attack that's easy to exploit is usually easy to reproduce — so DREAD's average can quietly double-count the same underlying property under two different labels, inflating scores for threats that aren't actually more severe than a threat that scores lower on one axis but not the other.
DREAD vs. CVSS
CVSS solved the consistency problem DREAD ran into, which is why it's now the industry default for scoring vulnerabilities. CVSS still scores multiple factors — attack vector, complexity, privileges required, user interaction, and impact to confidentiality, integrity, and availability — but each factor has a small, defined set of discrete values (e.g., Attack Vector is Network, Adjacent, Local, or Physical — not "pick a number 1 to 10"), which makes two analysts far more likely to land on the same score for the same vulnerability. CVSS also publishes a standard formula for combining those factors, rather than a plain average, and is versioned and maintained by FIRST as a formal open standard — DREAD was never formalized past Microsoft's original internal guidance.
The practical distinction: CVSS scores a known vulnerability in a generic, product-agnostic way — it's what you see attached to a CVE. DREAD (and its intent, if not its exact mechanics) was for scoring threats surfaced during modeling, before any specific vulnerability exists, in the context of your specific system. That's a gap CVSS doesn't really fill — see why CVSS scores break down as a threat-model risk measure for more on that distinction.
What most teams use instead, today
If you're threat modeling now, the practical options are: a simple qualitative High/Medium/Low bar per threat (fast, low false-precision, what Microsoft itself landed on); CVSS where a threat maps cleanly to a known vulnerability class; or a lightweight custom rubric — likelihood × impact on a small discrete scale, each level tied to a one-sentence definition so scoring stays consistent across reviewers and over time. The common thread across all three is a small number of clearly-defined buckets instead of a wide numeric range that invites false precision. Whatever scale you pick, the output should feed the same place DREAD scores were meant to: a prioritized risk register, so nothing found in a threat model just sits in a doc no one revisits.
DREAD is worth knowing because you'll still see it referenced in older SDL documentation and training material, and the underlying five factors are still a reasonable checklist for what "severity" should account for — even if averaging them into one number isn't the move anymore.