FIRST published CVSS version 4.0 on November 1, 2023. The main changes are new names for each type of score (CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE), a new Attack Requirements metric, User Interaction split into Passive and Active, Scope replaced by separate impacts on the vulnerable and subsequent systems, a Threat metric group in place of Temporal, and a set of Supplemental metrics that don't change the score. Should you switch? Not overnight. Make your process version-aware now, adopt v4.0 scores as your sources start publishing them, and never mix v3.1 and v4.0 numbers in the same comparison.
What is CVSS 4.0?
The Common Vulnerability Scoring System is FIRST's open standard for rating the severity of software vulnerabilities. Version 4.0 replaces version 3.1, which had been in use since 2019.
The new version went through a public preview at the FIRST Conference in June 2023, followed by a public comment period and revisions, before the official release on November 1. FIRST's stated goals include finer granularity in the base metrics, less ambiguity in scoring, simpler threat metrics and better coverage of operational technology, industrial control and IoT environments.
Some things stay the same. Scores still run from 0 to 10, and the qualitative bands are unchanged: Low is 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9 and Critical 9.0–10.0. Vector strings now begin with CVSS:4.0/.
What's new in CVSS 4.0?
New nomenclature: CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE
Version 4.0 names each score after the metric groups used to produce it:
| Label | Metric groups used |
|---|---|
| CVSS-B | Base only |
| CVSS-BT | Base and Threat |
| CVSS-BE | Base and Environmental |
| CVSS-BTE | Base, Threat and Environmental |
The specification says this nomenclature "should be used wherever a numerical CVSS value is displayed or communicated."
This small change fixes a long-standing problem. Under v3.1, a bare "9.8" rarely said whether anyone had considered exploit activity or the deployment environment. Most published scores are base-only, and labeling them CVSS-B makes that obvious.
Attack Requirements, and a narrower Attack Complexity
Attack Requirements (AT) is a new base metric with two values, None and Present. It captures conditions in the vulnerable system's deployment or execution that must exist for the attack to work, such as winning a race condition or being in a position to inject into a network path.
Attack Complexity (AC) still exists but is now narrower. It covers actions the attacker must take to evade or get around built-in security measures, such as exploit mitigations, or the need to obtain target-specific secrets. In v3.1, both ideas were squeezed into a single "High" complexity value.
User Interaction: None, Passive and Active
User Interaction used to be a yes-or-no question. Version 4.0 has three values:
- None: no user involvement is needed.
- Passive: the targeted user has limited, involuntary interaction with the vulnerable system, such as viewing a crafted page or running a program the attacker has planted.
- Active: the user must take specific, conscious actions, such as importing a file or dismissing a security warning.
All else being equal, the more deliberate the action required, the lower the score. This lets scorers separate vulnerabilities triggered by ordinary use from those that need a user to go out of their way.
Vulnerable system and subsequent system impacts replace Scope
Scope was one of the most debated parts of v3.x, and scorers applied it inconsistently. Version 4.0 removes it.
In its place, each vulnerability now has two sets of impact metrics:
- Vulnerable system confidentiality, integrity and availability (VC, VI, VA): the impact on the system that contains the flaw.
- Subsequent system confidentiality, integrity and availability (SC, SI, SA): the impact on other systems affected downstream.
That's more precise. A flaw in a hypervisor or a shared library can now show a modest impact on the component itself and a high impact on everything that depends on it, without an on-off Scope switch.
The Threat metric group replaces Temporal
The Temporal group has been renamed Threat and slimmed down. Remediation Level and Report Confidence are retired. What remains is Exploit Maturity (renamed from Exploit Code Maturity), with four values:
| Value | Meaning |
|---|---|
| Attacked (A) | Attacks have been reported, or tools that simplify exploitation are available |
| POC (P) | Proof-of-concept code is public, but no attacks are reported |
| Unreported (U) | Neither of the above is known |
| Not Defined (X) | No reliable threat intelligence; scored as Attacked |
The default matters. Because Not Defined is scored as the worst case, a CVSS-B score assumes exploitation. Adding threat intelligence can only hold the score steady or lower it. That makes the Threat group a practical place to feed in sources such as CISA's Known Exploited Vulnerabilities catalog.
Environmental metrics, with a safety option
The Environmental group works much as before. You can set confidentiality, integrity and availability requirements for the affected asset, and override any base metric to reflect your own deployment, such as a service that isn't reachable from the internet.
One addition stands out. The modified subsequent system integrity and availability metrics accept a Safety value, for cases where exploitation could cause physical harm to people.
New Supplemental metrics
Version 4.0 adds six optional Supplemental metrics. The specification is explicit that none of them change the score. They add context for your own decision-making.
| Metric | Values | What it tells you |
|---|---|---|
| Safety (S) | Negligible, Present | Whether exploitation could affect human safety |
| Automatable (AU) | No, Yes | Whether an attacker could automate exploitation across many targets |
| Recovery (R) | Automatic, User, Irrecoverable | How the system recovers after an attack |
| Value Density (V) | Diffuse, Concentrated | Whether one successful attack yields a lot of resources or a little |
| Vulnerability Response Effort (RE) | Low, Moderate, High | How hard it is to respond to the vulnerability |
| Provider Urgency (U) | Clear, Green, Amber, Red | The supplier's own assessment of urgency |
Each also has a Not Defined option. Automatable is likely to be the most useful for smaller teams, since a vulnerability that can be exploited at scale against internet-facing systems deserves faster attention.
A different scoring method
Version 3.1 used a published formula. Version 4.0 instead groups possible vectors into equivalence sets, ranks them using expert comparisons, and interpolates scores within each set. The practical upshot is that you shouldn't try to rebuild the calculation in a spreadsheet. Use FIRST's calculator or a maintained implementation.
How do CVSS 3.1 and CVSS 4.0 compare?
| Area | CVSS v3.1 | CVSS v4.0 |
|---|---|---|
| Score labels | One "CVSS score" | CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE |
| Scope | Changed or Unchanged | Removed |
| Impact metrics | One set of C, I, A | Vulnerable and subsequent system sets |
| User Interaction | None or Required | None, Passive or Active |
| Attack conditions | Attack Complexity only | Attack Complexity plus Attack Requirements |
| Exploit-related group | Temporal (three metrics) | Threat (Exploit Maturity only) |
| Extra context | None | Six Supplemental metrics, no score effect |
| Severity bands | Low, Medium, High, Critical | Unchanged |
Should you switch to CVSS 4.0?
For most organizations, switching isn't a single decision you control. The majority of the scores you use come from software vendors, CVE Numbering Authorities, the National Vulnerability Database and your scanning tools. Each will adopt v4.0 on its own timeline.
At the time of writing, v4.0 is only weeks old. Expect most of the scores you encounter in advisories, databases and scan results to remain v3.x for a while, and check each source's plans rather than assuming support is there.
A sensible plan in the meantime:
- Record the version with every score. Store the full vector string, not just the number, so you always know which standard produced it.
- Don't mix versions in comparisons. A v4.0 score and a v3.1 score for the same vulnerability can differ. Averaging or ranking across versions produces nonsense.
- Key remediation timelines to severity bands and exploitation evidence, not exact numbers. The bands are unchanged, so policies written that way will survive the transition better than ones with hard numeric cutoffs.
- Pilot v4.0 on your own findings. Take a sample of penetration test or internal findings and score them under both versions. You'll learn how the new metrics behave before external scores start arriving.
- Check your tools. Ask whether your scanner, ticketing system and reporting can store and display v4.0 vectors, and when they plan to.
Some organizations have good reason to move sooner. Software vendors that publish advisories can start offering v4.0 alongside v3.1. Teams running operational technology may find the Safety values valuable right away. And any team that already uses environmental scoring will benefit from the clearer Threat and Environmental groups.
If you only consume scanner output, it's reasonable to wait until your main data sources publish v4.0 consistently.
Frequently asked questions
Can we convert CVSS 3.1 vectors to 4.0 automatically?
Not reliably. Version 4.0 asks questions that a v3.1 vector doesn't answer, such as whether user interaction is passive or active and how subsequent systems are affected. A proper v4.0 score needs someone who understands the vulnerability.
Will CVSS 4.0 scores be higher or lower than 3.1 scores?
It varies by vulnerability. Base scores may move in either direction, and Threat metrics can lower a score when there's no sign of exploitation. Don't assume a fixed relationship.
Does CVSS 4.0 measure risk?
No. A base score still describes the intrinsic characteristics of a vulnerability. The specification encourages consumers to add Threat and Environmental metrics for a better input to risk assessment, but asset value, exposure and business context remain your job.
Is CVSS 3.1 now obsolete?
Not in practice. Existing scores remain valid for the version they were produced under, and v3.1 will stay in widespread use during the transition. Just keep track of which version each score comes from.
Key takeaways
- CVSS 4.0 was published on November 1, 2023, with the same 0–10 scale and severity bands.
- Label scores clearly: most published scores are CVSS-B, which assumes the worst case on exploitation.
- The biggest changes are Attack Requirements, Passive and Active User Interaction, the removal of Scope and the new Threat group.
- Supplemental metrics such as Automatable add useful context without changing the score.
- Make your records version-aware now, and adopt v4.0 as your data sources support it rather than forcing it everywhere at once.