Threat vs Vulnerability vs Risk

What Is the Difference Between a Threat, a Vulnerability and a Risk?

The three words describe different parts of one problem, and each answers its own question. A threat answers “who or what could hurt us?” A vulnerability answers “where are we weak?” Risk answers “how likely is the harm, and how bad would it be?”

Every risk is a risk to something, so a fourth word sits under all three: the asset. That can be a server, a customer database or the gateway your staff use to work from home. The table uses one such gateway as the running example on this page.

A short way to remember it: the threat is the who, the vulnerability is the where, and the risk is the how likely and how bad. Take one away and the risk falls away with it. A weakness no threat can reach, a threat with no way in, or an attack on something with no value adds little or no risk.

What Do the Terms Look Like Outside a CVE?

A vulnerability is not always a software bug. NIST’s definition also covers weaknesses in “system security procedures, internal controls, or implementation”. Common kinds are unpatched software, a misconfigured service, weak or reused passwords, missing training or a weak procedure, and a gap in backup or failover. The same three-part split works for each one.

These are plain examples, not data. NIST names a power failure and human error among its threat sources, and gives weaknesses in backup and failover mechanisms as an example of a vulnerability.

How Does NIST Define Threat, Vulnerability and Risk?

NIST Special Publication 800-30 Rev. 1, the US government’s Guide for Conducting Risk Assessments, gives definitions you can quote in a policy or a report. NIST’s online glossary carries close variants of the same wording from other NIST documents, such as FIPS 200 and SP 800-53 Rev. 5.

• Threat: “any circumstance or event with the potential to adversely impact” an organization’s operations, assets or people through an information system. The harm comes through unauthorized access, destruction, disclosure or modification of information, or denial of service.
• Vulnerability: “a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source.”
• Risk: “a measure of the extent to which an entity is threatened by a potential circumstance or event.” NIST adds that risk is typically a function of two things: the adverse impact if the event happens, and the likelihood that it happens.

Two more NIST terms make the model easier to use. A threat source is what starts the harm, and a threat event is what happens. NIST lists four kinds of threat source: hostile cyber or physical attacks, human errors, structural failures of hardware, software or environmental controls, and natural or man-made disasters.

The guide gives its own example. One provisioning server can go offline through a denial-of-service attack, a malicious administrator, an administrative error, a hardware fault or a power failure. That is one threat event with five different threat sources. So a threat is not always an attacker, and a threat actor is only the human kind of threat source.

How Do Threat, Vulnerability and Risk Fit Together?

NIST’s risk model reads like a chain, and each step needs the one before it:

1. A threat source with some intent and capability starts a threat event.
2. The threat event exploits one or more vulnerabilities.
3. Predisposing conditions make success more or less likely. NIST’s example is a stand-alone system with no outside network connection, which is less exposed to a network attack.
4. Success causes an adverse impact on an asset, the organization or people.
5. Risk combines how likely that chain is to happen with how bad the impact would be.

For adversarial threats, NIST bases likelihood on three things: the adversary’s intent, capability and targeting. This is where threat intelligence feeds a risk assessment. News that a ransomware crew is exploiting a flaw right now raises likelihood, even if nothing changed in your own network.

Many articles turn this into a formula: Risk = Threat × Vulnerability × Impact. It is a useful memory aid, but it is not arithmetic, since you cannot multiply a ransomware crew by an unpatched appliance. NIST’s guide allows quantitative, qualitative or semi-quantitative assessment; its own tables use qualitative and semi-quantitative scales instead. It also warns that pairing threats and vulnerabilities one to one can be a problem, because there are so many of both.

NIST prefers threat scenarios: a series of threat events, each using one or more vulnerabilities, that ends in harm. In its words, “a threat scenario tells a story.” The next section tells one.

What Do the Three Terms Look Like on One Real Vulnerability?

Take one internet-facing NetScaler Gateway that staff use for remote access. In October 2023 a flaw in this product showed all three terms at once. Our vulnerability library covers it as Citrix Bleed (CVE-2023-4966).

The vulnerability: CVE-2023-4966 lets an outsider with no login send a crafted request that makes the appliance return part of its memory. That memory holds a valid session cookie. Citrix published its bulletin on 10 October 2023, with fixed builds such as 14.1-8.50 and 13.1-49.15. The flaw applies only when the appliance is set up as a Gateway or an AAA virtual server.

The threat: Citrix said exploits on unmitigated appliances had been observed. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on 18 October 2023 and marks it as known to be used in ransomware campaigns. A joint advisory of 21 November 2023 (AA23-325A) dates exploitation activity to as early as August 2023. It names LockBit 3.0 ransomware affiliates among the threat actors using it.

The risk: With a stolen cookie, the attacker opens a session as a real user. CISA says this bypasses passwords and multifactor authentication, and lets the actor harvest credentials, move laterally and reach data. For an organization with an exposed, unpatched gateway in late 2023, both likelihood and impact were high. For one running the same product without a Gateway or AAA setup, the threat was the same, but this flaw did not apply.

The scores describe the same flaw from different angles. Citrix rated it 9.4 (critical) in CVSS 3.1, while NIST’s National Vulnerability Database rated it 7.5 (high), because the two judged the integrity and availability impact differently. Its EPSS probability on 10 November 2026 was 0.99999, in the 99.997th percentile of scored CVEs. None of these numbers is your risk, as the next section shows.

The useful part is what each response changed. Patching alone was not enough, and the reason is the gap between a vulnerability and a risk.

Two lessons carry over to any vulnerability. A fix can remove the weakness and still leave risk behind, because the threat may already have used it. And a control that does not touch the actual attack path, like MFA here, can leave the risk where it was.

Is CVSS a Measure of Risk?

No. FIRST, which maintains the Common Vulnerability Scoring System (CVSS), says so in its CVSS v3.1 user guide. CVSS “is designed to measure the severity of a vulnerability and should not be used alone to assess risk.” The base score covers only the flaw itself and stays the same in every environment. It knows nothing about who is exploiting the flaw or what your copy of the product protects.

Each common score or list describes one part of the picture. Put them side by side and the gap to risk becomes clear:

For scale, the KEV catalog version of 9 November 2026 lists 1,773 vulnerabilities, and 361 of them are marked as known to be used in ransomware campaigns.

Only the last two rows of the table are yours, and they turn a score into a risk. That is the idea behind what vulnerability prioritization means in practice: rank by severity, threat evidence and your own exposure together. CVSS v4.0 adds Threat and Environmental metrics for the same reason, so a team can adjust the base score with exploitation data and its own controls.

How Do You Rate and Record a Risk?

Start with one sentence that names every part. A simple pattern is: [threat source] could [threat event] by exploiting [vulnerability] in [asset], causing [impact]. For the gateway it reads: “Ransomware affiliates could hijack a staff session by exploiting CVE-2023-4966 in our NetScaler Gateway, leading to ransomware on the internal network.”

Then rate likelihood and impact on a shared scale. NIST SP 800-30 uses five levels, from Very Low to Very High, and combines them in the matrix below, its Table I-2. Read across from the likelihood row to the impact column.

Notice the shape. A very likely event with a very low impact is still a very low risk. A very low likelihood keeps even a very high impact at low. Teams can tailor the scale, but the matrix keeps likelihood and impact in view instead of hiding them in one number.

A risk register entry then keeps each part in its own field, so you can see which one a fix changes. Here is an example entry, as a team might have written it after the November 2023 advisory:

risk: Session hijack on the remote access gateway
asset: NetScaler Gateway (internet-facing, staff VPN)
threat_source: threat actors incl. LockBit 3.0 affiliates (CISA AA23-325A)
threat_event: steal a session cookie and log in as a real user
vulnerability: CVE-2023-4966, build older than 13.1-49.15
threat_evidence: CISA KEV since 2023-10-18, known ransomware use
likelihood: Very High
impact: Very High
risk_level: Very High   # NIST SP 800-30 Table I-2
treatment:
  - upgrade to 13.1-49.15 or later
  - kill all active and persistent sessions
  - hunt for users on two or more public IP addresses
residual_risk: re-rate after the session hunt
owner: remote access team

When the upgrade is done, only the vulnerability line changes. The threat lines stay true, which is why the residual risk needs its own check.

Which Mistakes Mix Up the Three Terms?

• Calling a CVE a threat. “The Citrix threat” is really a vulnerability. The threat is whoever exploits it, and knowing who that is tells you how fast to move.
• Reading a CVSS score as a risk level. A 9.4 on a product you do not run, or on a setup the flaw does not affect, is not a risk to you. A 7.5 on your only remote access gateway can be a serious one.
• Writing “ransomware” in the risk register. Ransomware is a threat. The risk is the specific harm through a specific weakness, such as encrypted servers that stop orders for days.
• Calling a zero-day a threat. A zero-day vulnerability is a vulnerability with no fix yet. It becomes urgent when a threat has an exploit for it.
• Treating a risk rating as permanent. NIST notes that the validity of any risk assessment “is bounded in time.” A new KEV entry or exploitation report can raise likelihood overnight while your network stays the same.
• Pairing threats and vulnerabilities one to one. NIST warns that this pairing struggles with the sheer number of threats and vulnerabilities. A few threat scenarios built around your important assets can say more.

What Does Criminal Market Data Show About Threats and Vulnerabilities?

Threat information often arrives as a criminal advert, not as a CVE. Our Cybercrime Report 2026, built on Brandefense Blackhole data from 1 January to 27 October 2026, shows both sides of that gap.

In the Initial Access Offers chapter, 48 of 106 corporate network access offers name an edge device or remote-access service, counting one repeated firewall family once. The doors named include firewalls and other network devices, RDP, VPN, RDWeb and Citrix. These are seller claims, not proven break-ins, but they show which kind of entry point an initial access broker advertises.

The Exploit Trade chapter shows the opposite problem. Of 93 sampled exploit seller posts that use the word 0-day, none names a CVE, and across 221 offers and requests only 2 name one. A forum claim is threat information, but you cannot find and patch it as a vulnerability until it is tied to a product, a version or an advisory.

The counts are posts collected by Blackhole, mostly from Telegram, not sales, sellers or confirmed breaches. For a defender the use is practical. Check the doors sellers name against your own edge devices, and check any exploit claim against a vendor advisory or the KEV catalog first.

What Should a Security Team Do Next?

1. List the assets that matter. Start with what faces the internet, because that is where the gateway example began. Our attack surface entry explains what to count.
2. Match vulnerabilities to those assets, setup included. CVE-2023-4966 affected only Gateway and AAA setups, so the version number alone did not settle it.
3. Add threat evidence. Check KEV, EPSS and vendor notes on exploitation, and follow the threat actors targeting your sector.
4. Rate likelihood and impact on one shared scale. Write the risk sentence and record each part separately, as in the register entry above.
5. Pick the fix by the factor it changes. Remove the weakness, cut exposure or limit impact. Then check for leftovers such as live sessions or stolen passwords.
6. Re-rate on a schedule and after any change. Review each rating at a set interval, and again when a new KEV entry or advisory arrives.

For the full process on the vulnerability side, read the Vulnerability Management 101 guide. For mapping attackers to your systems before an incident, see threat modeling. The Brandefense vulnerability intelligence platform tracks NVD, vendor advisories and the CISA KEV catalog, watches underground exploit talk and matches each CVE to the technology you declare.