CVSS 4.0 vs CVSS 3.1: What Actually Changed for Triage

CVSS v4.0 replaces the version most triage playbooks were built around, and the change is not cosmetic. FIRST published the new standard in November 2023, and by 2026 most scanner vendors ship v4.0 vectors alongside v3.1 ones in the same finding. If your severity thresholds, SLA clocks, or auto-assignment rules still reference the old metric names, some of that logic silently breaks the moment a scanner starts returning a CVSS 4.0 vector string it does not recognize. This is a working guide to what changed, where scores actually move, and what to touch in your triage rules before the two scoring systems collide in your backlog.

The structural shift: four groups instead of three

CVSS v3.1 organized metrics into Base, Temporal, and Environmental groups, with Temporal treated as an optional refinement that few teams scored consistently. CVSS v4.0 drops that structure for four groups: Base, Threat, Environmental, and Supplemental. The naming is not just relabeling.

• Base still captures the exploitability and impact of the vulnerability itself, independent of any deployed mitigation or exploit activity.
• Threat replaces Temporal and keeps only Exploit Maturity (E). Remediation Level and Report Confidence are gone; FIRST concluded both were rarely populated with real data and added noise rather than signal.
• Environmental still lets you override Base values and set Confidentiality, Integrity, and Availability Requirements for your own environment, but it now applies across the split impact metrics described below.
• Supplemental is new and, critically, does not change the numeric score at all. It carries Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, and Provider Urgency as metadata you can factor into prioritization logic outside the CVSS math itself.

CVSS v4.0 also introduces explicit nomenclature for which groups were scored: CVSS-B for Base only, CVSS-BT for Base plus Threat, CVSS-BE for Base plus Environmental, and CVSS-BTE when all three scoring groups are present. A vector labeled CVSS-B is not comparable to one labeled CVSS-BTE, and a dashboard that shows one blended number without that suffix is hiding which inputs actually went into it.

Metric by metric: Attack Requirements, User Interaction, and the end of Scope

Three changes at the Base metric level account for most of the scoring drift you will see.

Attack Requirements (AT) is new. CVSS v3.1 folded “does the attacker need a specific pre-existing condition” into Attack Complexity (AC), which conflated two different questions: how hard is the exploitation technique, and does it depend on a state the attacker does not control. CVSS v4.0 splits these. AC now measures only technique difficulty, and AT captures whether the attack needs a non-default configuration, a race condition window, or another external condition. A vulnerability that is trivial to exploit once a rare precondition is met used to get folded into AC:H under 3.1; it can now score AC:L with AT:P, which is a more honest description and often moves the number in either direction.

User Interaction (UI) is no longer binary. CVSS 3.1 had UI:None or UI:Required, with no distinction between a user clicking a link they were tricked into and a user performing an action they had no reason to suspect. CVSS 4.0 adds UI:Passive, where the user does something ordinary such as opening a file that happens to trigger the exploit, and UI:Active, where the user has to take a specific, unusual step the attacker engineered. This split matters for phishing-chained vulnerabilities that previously all scored the same regardless of how much social engineering they actually required.

Scope is retired. Scope, Unchanged or Changed, was the single most inconsistently applied metric in CVSS 3.1: analysts routinely disagreed on whether a given vulnerability caused an impact beyond the vulnerable component. CVSS v4.0 removes it entirely and replaces it with two full sets of impact metrics, described next.

Subsequent System impact: VC/VI/VA vs SC/SI/SA

This is the change with the most practical effect on chained-impact scoring. CVSS 3.1 had one Confidentiality, Integrity, Availability triad, and Scope:Changed was the only way to signal that impact spread past the component that was actually vulnerable. CVSS v4.0 replaces that single triad with two explicit ones.

The practical benefit is that a container escape, a server-side request forgery that reaches internal metadata endpoints, or a deserialization bug that pivots into a different service no longer depends on one reviewer’s judgment call about whether scope changed. You score VC/VI/VA for the vulnerable component and SC/SI/SA for whatever it reaches, and the two triads combine mathematically instead of through a boolean flag. Findings that involve lateral movement or a privilege boundary crossing tend to score higher under v4.0 for this reason, because Subsequent System impact is now additive rather than gated behind a single yes or no switch that many analysts under-applied to avoid disputes.

Score drift in practice

There is no fixed conversion formula between CVSS 3.1 and CVSS 4.0 scores, and treating one as a linear transform of the other will misclassify real findings. The direction of drift follows from the metric changes above, so the practical move is to re-vector representative findings rather than guess at an offset.

• A vulnerability that needed a non-default configuration to exploit typically moves down under v4.0, because AT:P separates that condition out instead of inflating Attack Complexity to High.
• A vulnerability requiring heavy social engineering to trigger typically moves down relative to a one-click phishing case, because UI:Active versus UI:Passive is now distinguished where 3.1 scored both simply as UI:Required.
• A vulnerability that pivots into another system, service, or tenant typically moves up under v4.0, because Subsequent System impact is scored explicitly instead of relying on an under-applied Scope:Changed flag.
• A straightforward, unauthenticated, network-exploitable bug with no chained impact tends to land close to its 3.1 score, since Attack Vector, Privileges Required, and the core impact metrics did not change in kind.

Run your organization’s ten or twenty highest-volume finding types through the official FIRST CVSS v4.0 calculator with both vectors side by side. That exercise, done once against your own finding population, tells you more about where your thresholds will move than any general rule can.

Migration reality: dual-scored inventories and NVD coverage gaps

NVD began publishing CVSS v4.0 base scores for newly assigned CVEs starting in 2024, but it has not systematically backfilled v4.0 scores across the historical CVE catalog, and vendor advisories are inconsistent about which version they lead with. The practical result is a mixed inventory: recent CVEs may carry both a v3.1 and a v4.0 vector, older CVEs frequently carry v3.1 or even v2 only, and some scanner plugins compute their own v4.0 score locally when NVD has not published one, which will not always agree with a score another tool derives from the same CVE.

Do not try to normalize this by rescoring the entire backlog on day one. Instead:

1. Store both vector strings on a finding whenever a source provides them, rather than overwriting one with the other.
2. Tag each finding with which CVSS version drove its current triage disposition, so a later audit can tell whether a decision predates the migration.
3. Set a rule that new findings ingested after your cutover date are triaged on v4.0 when available, falling back to v3.1 only when no v4.0 vector exists yet.
4. Leave already-closed or already-accepted-risk findings on their original score. Rescoring a backlog wholesale because the standard changed, rather than because new information about the vulnerability arrived, burns analyst time without changing remediation priority for most findings.

Platforms that ingest scanner output across both score versions, such as SITEY, keep the raw CVSS-B and CVSS-BTE vector strings attached to each finding as part of its vulnerability lifecycle record, instead of collapsing them into a single blended number. That is what makes the first rule above practical rather than aspirational: without the raw vector retained, you cannot later explain why a finding’s severity moved when the scoring version changed under it.

What to change in your triage rules the day you adopt v4

A handful of concrete changes cover most of the operational risk of the transition.

• Update string matching, not just thresholds. If any automation parses the vector string directly, a regex written against CVSS:3.1/AV:N/AC:L/… will not match a CVSS:4.0/AV:N/AC:L/AT:N/… string. Update the parser to handle both prefixes and the new metric set, including AT and the VC/VI/VA and SC/SI/SA splits, before you enable v4.0 ingestion, or findings will fail silently instead of erroring loudly.
• Re-anchor severity bands to CVSS-BTE, not CVSS-B, wherever threat and environmental data exist. A Base-only score with no Threat or Environmental context is the least informed number the new standard can produce, and treating it as final removes the exact context v4.0 was built to add.
• Recheck any SLA tied to a numeric cutoff. A policy rule tied to a fixed threshold, the kind of rule that compliance mapping against frameworks like PCI DSS or ISO 27001 usually encodes as a remediation deadline, needs an explicit decision about which CVSS version’s number it means, because a finding can cross that line under one version and not the other.
• Keep Supplemental metrics out of the score itself. If a risk engine adds its own weighting for exploitability in the wild or asset criticality, make sure it is not double counting against Supplemental fields such as Automatable or Provider Urgency, which FIRST deliberately kept out of the numeric score for exactly this reason.
• Version-tag every automated decision. An assignment rule, an SLA clock, or a suppression that fired based on CVSS should record which CVSS version it evaluated, so a later dispute over why a finding was or was not escalated has a clear answer.

Systems that keep the scoring step separate from assignment and remediation, rather than baking one hardcoded CVSS threshold into ingestion, absorb a standards change like this with a rule update instead of a data migration. That separation is also what the triage stage in a pipeline like SITEY’s relies on: it lets a re-test after patching compare against the same vector version the original finding was scored under, instead of comparing numbers computed from two different metric definitions.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.