CVSS v4.0 vs v3.1: what actually changed in vulnerability scoring
CVSS v4.0, published by FIRST on 1 November 2023, is the first new major version of the Common Vulnerability Scoring System since v3.1 (June 2019). It keeps the familiar 0-10 severity scale, but it retires the often-misunderstood Scope metric, adds a new Base metric for attack prerequisites, formalises threat and safety context as metrics that do not touch the score, and requires a new labelling scheme so a bare number is never read as more than it is. Neither version has been withdrawn, so vulnerability databases and vendor advisories you read today may still carry either one.
Why FIRST built a new major version instead of patching v3.1
FIRST's own framing for v4.0 is that CVSS "is not just the Base score": the new nomenclature exists to "reinforce the concept" that a single number, calculated from Base metrics alone, was never meant to carry a full risk decision by itself. In practice, the Base score is exactly what most tools, dashboards and compliance checklists display and sort by, which is the behaviour v4.0's structural changes are aimed at correcting rather than merely documenting. The specification also adds explicit, if optional, support for safety impact and OT/ICS-relevant context that v3.1 had no dedicated field for.
What changed in the Base metric group
| CVSS v3.1 | CVSS v4.0 | |
|---|---|---|
| Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI) | Present | Present (User Interaction gains Passive/Active values) |
| Attack Requirements (AT) | Not present | New: captures deployment/execution preconditions outside attacker control |
| Scope (S) | Changed / Unchanged, a single boundary-crossing flag | Retired |
| Impact on the vulnerable component | Confidentiality (C), Integrity (I), Availability (A) | Vulnerable System impact: VC, VI, VA |
| Impact beyond the vulnerable component | Folded into Scope=Changed, same C/I/A scale | Subsequent System impact: SC, SI, SA, scored separately |
Splitting Scope into Vulnerable System and Subsequent System impact is the change most v3.1 scorers will feel first. Under v3.1, a vulnerability that let an attacker pivot into a different security authority was marked only with Scope=Changed, reusing the same Confidentiality/Integrity/Availability scale for both "this component" and "whatever it reaches." v4.0 scores those two surfaces with separate metrics instead of overloading one.
Threat and Supplemental metrics: context that does, and does not, move the score
v3.1's Temporal group (Exploit Code Maturity, Remediation Level, Report Confidence) becomes v4.0's Threat group, narrowed to a single metric, Exploit Maturity (E), with clarified values. v4.0 also adds a wholly new Supplemental Metrics group: Safety (S), Automatable (AU), Provider Urgency (U), Recovery (R), Value Density (V) and Vulnerability Response Effort (RE). FIRST's specification states plainly that Supplemental metrics "do not modify the final score" and exist only to carry extra context, such as whether a vulnerability could affect physical safety, alongside the number rather than folded into it.
The nomenclature: CVSS-B, CVSS-BE, CVSS-BT, CVSS-BTE
v4.0 requires that any published CVSS number be labelled with which metric groups produced it:
| Label | Metric groups included |
|---|---|
| CVSS-B | Base only |
| CVSS-BE | Base + Environmental |
| CVSS-BT | Base + Threat |
| CVSS-BTE | Base + Threat + Environmental |
v3.1 had no equivalent requirement; a "CVSS score" in a v3.1-era advisory could silently be a Base score, an Environmental score, or something a vendor hand-adjusted, with no label distinguishing them. Under v4.0, an unlabelled number is, by the specification's own convention, non-conformant.
How scores are actually calculated now: MacroVectors
The bigger change is under the hood. v3.1 computed the score from a published algebraic formula applied directly to the metric values. v4.0's specification describes a different method: FIRST clustered roughly 15 million possible CVSS-BTE metric combinations into about 270 MacroVectors, equivalence sets that an expert evaluation process judged to be of comparable severity, assigned each MacroVector a score via lookup table, and interpolates the score for an individual vector within its MacroVector using a severity-distance calculation. The practical effect for anyone scoring a vulnerability is the same, a reference calculator does the arithmetic, but the result now comes from expert-ranked equivalence classes rather than a single public formula, so a hand-built v3.1-style calculator cannot simply be extended to v4.0.
What this means for triage
A v4.0 score alone still is not a patch-priority decision, any more than a v3.1 score was. It pairs with the same inputs as before: whether a CVE is in CISA's KEV catalog, its FIRST EPSS probability, and your own asset exposure; see KEV and EPSS: vulnerability prioritisation for OT fleets. Two practical points specific to the version change:
- Check which version an advisory or scanner is using before comparing numbers. A v4.0 CVSS-B score and a v3.1 Base score are not computed the same way and are not guaranteed to land in the same band for the same vulnerability, because the Scope/Vulnerable-Subsequent split alone can move a score.
- Use the nomenclature, not the bare number, in your own advisories and VEX records. Labelling a score CVSS-B versus CVSS-BTE tells a downstream reader, or an automated system matching your advisories against a firmware SBOM, exactly what was and was not accounted for.
SoftWSP scores and triages vulnerabilities found in firmware and OT fleets against current CVSS, KEV and EPSS data, and keeps the record auditable per release: see PSIRT as a service.
This guide is general information, not legal advice.
Frequently asked questions
When was CVSS v4.0 released, and does it replace v3.1?
FIRST published the CVSS v4.0 specification on 1 November 2023 (with clarifying revisions in versions 1.1 and 1.2 through June 2024). It is the successor to CVSS v3.1, which FIRST published in June 2019, but FIRST has not withdrawn v3.1: both remain published specifications, and a given scoring provider or database may still use either, so always check which version a score you are reading was calculated under.
What is the single biggest structural change from v3.1 to v4.0?
The retirement of the v3.1 Scope (S) metric. v3.1 used one Changed/Unchanged flag to signal that a vulnerability's impact crosses a security boundary. v4.0 replaces it with two separate sets of impact metrics: Vulnerable System impact (VC, VI, VA) for the component that contains the flaw, and Subsequent System impact (SC, SI, SA) for everything the exploit can reach beyond it.
What is Attack Requirements (AT), the new Base metric in v4.0?
Attack Requirements captures deployment and execution conditions that have to exist before an attack can succeed, separate from Attack Complexity (which covers attacker effort) and Privileges Required (which covers access level). FIRST's specification gives it two values, None and Present, where Present means the attack depends on conditions outside the attacker's control, such as a specific configuration or a race condition window.
Do CVSS v4.0's Supplemental metrics change the numeric score?
No. FIRST's specification is explicit that the Supplemental Metrics group, Safety (S), Automatable (AU), Provider Urgency (U), Recovery (R), Value Density (V) and Vulnerability Response Effort (RE), adds context for a reader but does not feed into the calculated CVSS score at all. They exist precisely so that score and context are not silently blended together, the way ad hoc CVSS modifications sometimes did under v3.1.
What do CVSS-B, CVSS-BE, CVSS-BT and CVSS-BTE mean?
They are the nomenclature v4.0 requires whenever a numeric CVSS value is shown: CVSS-B is a Base-metrics-only score, CVSS-BE adds Environmental metrics, CVSS-BT adds Threat metrics (exploit maturity), and CVSS-BTE adds both. FIRST introduced this labelling specifically so that a bare number is never mistaken for the full, context-adjusted picture.