CVSS 3.1 vs 4.0 for findings: what changed and when to use each

CVSS 4.0 has been out since late 2023, and most reports still quote CVSS 3.1. That is not inertia so much as a real tension: 4.0 is the better model, and 3.1 is the version your client’s compliance framework, scanner, and vulnerability management tool were all built around. This is a practical read on what actually changed between the two, and how to decide which one (or both) belongs on a finding.

The short version: CVSS is a way to turn a set of facts about a vulnerability into a number between 0.0 and 10.0, using a published formula so that two people scoring the same bug land in the same place. 4.0 keeps that goal and fixes several things 3.1 got wrong. But scoring a finding is only half the job. The other half is that whoever reads the report can recompute your score and agree with it, and that half is decided by which version your reader expects.

What actually changed in 4.0

Four changes matter most in day-to-day finding work.

Scope is gone, replaced by explicit downstream metrics. The single most argued-about part of 3.1 was Scope (S), the flag for “did the impact cross a security boundary.” It was powerful and it was ambiguous, and two careful testers routinely disagreed on it. 4.0 removes it and instead splits impact into the vulnerable system (Confidentiality, Integrity, Availability as VC/VI/VA) and any subsequent systems (SC/SI/SA). You now state the downstream impact directly rather than encoding it in one overloaded flag.

Attack Requirements (AT) is new. 3.1 had Attack Complexity doing two jobs at once. 4.0 separates the effort an attacker spends (Attack Complexity) from preconditions outside the attacker’s control, such as a race window or a specific configuration (Attack Requirements). This makes conditional bugs score more honestly instead of being forced into a single “high complexity” bucket.

User Interaction is now graded. 3.1 offered None or Required. 4.0 grades it as None, Passive, or Active, which distinguishes “the victim just has to load a page” from “the victim has to complete a specific multi-step action.” For client-side findings this is a meaningful difference that 3.1 flattened.

The naming acknowledges reality: CVSS-B, BT, BE, BTE. 4.0 makes it explicit that a base score alone (CVSS-B) is not the whole picture, and names the score once you add Threat (T) and Environmental (E) metrics. In practice most reports still quote the base score, but the naming nudges toward the environmental context that a base score deliberately ignores.

A worked contrast

Take a stored XSS in an admin panel that fires when another admin views a record. Under 3.1 you reach for Scope Changed to express that the script runs in a different security context, and the score swings on a metric people argue about. Under 4.0 you say it plainly: the vulnerable system takes a low integrity hit, the subsequent system (the admin’s session) takes the real impact, and User Interaction is Passive because the admin only had to view the record. The 4.0 vector encodes the same reality with far less room to disagree.

The scores from 3.1 and 4.0 are not directly comparable, and you should never present them as if they are. They are two different formulas. A 7.5 in one is not “the same finding as” a 7.5 in the other. If you quote both, quote them as two separate scores, each with its own vector.

So which do you use?

Decide by who reads the score, not by which model is newer.

Use 3.1 when the report has to line up with someone else’s system. If the client’s vulnerability management platform, their scanner output, or their compliance framework (many still reference 3.1 explicitly) is going to sit next to your findings, scoring in 3.1 keeps everything comparable. A finding that scores 8.1 in your report and imports as a different number into their tracker creates an argument you do not want to have.

Use 4.0 when the score has to be defensible on its own terms. For findings where the 3.1 model genuinely misrepresents the risk (downstream impact, conditional exploitation, graded user interaction), 4.0 lets you state the case more precisely, and the vector is easier to defend in a review because there is less ambiguity to argue about.

When in doubt, carry both. Scoring a finding in 3.1 and 4.0 costs a few minutes and removes the “why this version” question entirely. The reader who lives in 3.1 gets a number they can reconcile; the reader who wants the sharper model gets that too. This is why our free CVSS calculator computes both from the base metrics and hands back report-ready severity text, and why Cairn’s Report module carries 3.1 and 4.0 (base, temporal, and environmental) on every finding rather than making you choose one at the top of the report.

Whichever you pick, show the vector

The version debate distracts from the thing that actually earns trust: publishing the vector string. A severity label is an assertion. A vector is an argument a reader can check and, if they disagree, argue with on your terms. A report that shows CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N next to a score is telling the reader exactly how it got there. That transparency matters more than which of the two versions produced it.