Is migrating from CVSS v3.1's three metric groups to v4.0's four worth it for your programme?
answer
- three groups became four
- one group never moves the number
- Scope disappeared entirely
- Threat kept only one old metric
- Safety, Automatable, Recovery sit outside the score
basics
~20 sCVSS v4.0 splits scoring into Base, Threat, Environmental and Supplemental groups, drops Scope for explicit subsequent-system impact, and adds non-scoring context such as Safety and Automatable. Migrating pays where those distinctions change decisions, not as a bulk re-score.
solid answer
~50 sCVSS v4.0 has four metric groups instead of three: **Base**, **Threat**, **Environmental** and **Supplemental**. Base gains Attack Requirements and a three-valued User Interaction, and it drops Scope in favour of rating impact twice — on the vulnerable system (`VC/VI/VA`) and on any subsequent system (`SC/SI/SA`). Threat replaces the old Temporal group and keeps only Exploit Maturity; Remediation Level and Report Confidence are gone. Supplemental — Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency — carries context that never changes the number. The migration is worth it where those distinctions actually route work: a device gateway whose failure reaches patients is far better described by `Safety:Present` and an explicit subsequent-system impact than by one number. The costs are real too: raters need retraining, there is no defined conversion between versions, and downstream consumers still expect v3.1 vectors.
go deeper
Know that CVSS has more than one live version, that v3.1 vectors and v4.0 vectors are both in circulation, and that the version prefix at the front of the string tells you which scheme you are reading.
Be able to name v4.0's four metric groups and the headline changes: Scope replaced by vulnerable- and subsequent-system impact, Temporal shrunk into Threat, and a Supplemental group that never affects the number.
Expect to re-score a described flaw under v4.0 and explain what the new metrics reveal that a v3.1 vector hid, particularly for systems where the consequence is physical or the exploit is automatable.
Own the adoption decision itself: which product areas move, what raters need retrained, how you avoid comparing scores across schemes, and why re-scoring a historical backlog is almost never worth the spend.
## What actually changed CVSS v3.1 had three metric groups — Base, Temporal, Environmental. CVSS v4.0 has four: - **Base** — intrinsic, deployment-independent properties, still the only mandatory group. - **Threat** — what is known about exploitation in the wild right now. - **Environmental** — the deployer's adjustment for their own installation, via modified base metrics and security requirements. - **Supplemental** — additional context that is recorded but **never affects the numeric score**. The naming convention follows the groups you actually filled in: `CVSS-B` for base only, `CVSS-BT` with threat, `CVSS-BE` with environmental, `CVSS-BTE` with both. That nomenclature exists to stop people describing a bare base score as "the CVSS score" of a flaw in their estate. ### Base group changes Two additions and one removal matter. **Attack Requirements (`AT`)** splits out of the old Attack Complexity. In v3.1, `AC` carried both "the attacker must defeat an exploit mitigation" and "a particular deployment condition must happen to hold". v4.0 keeps `AC` for the former and gives the latter its own metric with values None and Present. **User Interaction (`UI`)** gains a third value. Instead of None/Required it is None, **Passive** or **Active** — the difference between a victim who merely has to be using the product normally and one who has to be led into a specific unusual action. **Scope is gone.** It was the least reproducibly applied metric in v3.x. In its place, impact is rated twice: `VC`, `VI`, `VA` for the vulnerable system and `SC`, `SI`, `SA` for a subsequent system. The rater now states the crossing directly rather than compressing it into one letter and then re-pointing the impact metrics at a different component. ### Threat group The Temporal group shrank to a single metric, **Exploit Maturity (`E`)**, with values Attacked, Proof-of-Concept, Unreported and Not Defined. Remediation Level and Report Confidence were retired because, in practice, almost nobody maintained them and their multipliers mostly nudged scores downward without changing any decision. ### Supplemental group Six metrics — **Safety**, **Automatable**, **Recovery**, **Value Density**, **Vulnerability Response Effort**, **Provider Urgency** — that a provider may publish and a consumer may act on, with zero effect on the computed number. Safety takes Negligible or Present; Automatable takes No or Yes (can an attacker script reconnaissance through exploitation across many targets?); Recovery takes Automatic, User or Irrecoverable. This group is the clearest signal of what v4.0 is for: it stops trying to squeeze every consideration into one scalar and instead lets the vector carry structured context alongside it. ## Where the migration earns its keep Take a gateway on a hospital's clinical network that relays telemetry from infusion pumps and accepts dose-configuration updates on their behalf. The attacker position is someone with a foothold on that clinical segment; the asset is patient safety, not records. Under v3.1 the rater sets `S:C` because the pumps are governed by a different authority than the gateway, points the impact metrics at the pumps, and emits one number. Everything that made this finding special — that the consequence is physical harm, that restoring a mis-dosed pump is not an automatic rollback, that an attacker could sweep every pump on the segment — is invisible in the output. Under v4.0 the same analysis records impact on the gateway *and* separately on the pumps as the subsequent system, marks `Safety:Present`, sets Recovery to User or Irrecoverable, and states Automatable explicitly. A triage board reading the vector sees the safety consequence without inferring it. That is a real change in how work gets routed, and it is the strongest argument for moving. ## Where it does not Be blunt about the costs, because the interviewer is really asking whether you can resist a standards-chasing project. - **There is no defined conversion between versions.** You cannot mechanically translate a v3.1 vector into a v4.0 one; you re-score, which means re-reading the analysis for every finding you care about. - **Raters need retraining.** `AT` versus `AC` and the three-valued `UI` are new judgment calls, and a half-trained rater produces vectors that are worse than consistent v3.1 ones. - **Consumers still expect v3.1.** Advisories, contracts and internal SLAs that quote v3.1 severity bands do not update because you changed methodology. - **A base score is still a base score.** Four groups do not make the number smarter about your deployment; the Environmental group is what does that, and it required effort in v3.1 too. The defensible position is a scoped migration: adopt v4.0 for **new** ratings in the product areas where subsequent-system impact or safety consequence genuinely drives triage, keep the historical corpus as it is, publish the version prefix everywhere so nobody compares across schemes by accident, and never re-score a backlog just to make the versions match.
- Why would you record Supplemental metrics at all if they never change the score?Because they route work. Safety:Present tells a triage board that the consequence is physical harm; Recovery:Irrecoverable says a rollback will not undo it; Automatable:Yes says one attacker can sweep every instance. None of that belongs in a severity scalar — squeezing it in is what made DREAD-style schemes unreliable — but all of it changes who picks the ticket up and how fast. The Supplemental group is structured context travelling with the vector instead of in a comment field.
- What replaced the Scope metric in CVSS v4.0, and why was it removed?Impact is now rated twice: VC/VI/VA for the vulnerable system and SC/SI/SA for any subsequent system. Scope was removed because it was applied inconsistently — raters read it as blast radius or as severity rather than as a crossing of security authority, and it silently changed which component the impact metrics described. Splitting the impact metrics makes the rater state both sides explicitly, which is far easier to review and to disagree about productively.
- Can you convert your existing v3.1 vectors to v4.0 automatically?No. There is no defined mapping between the versions, and several metrics have no counterpart — Scope has no v4.0 equivalent, Attack Complexity split into two metrics, and User Interaction gained a value. Any conversion would be guessing at judgments the original rater never recorded. If you need v4.0 vectors for old findings you re-score them from the underlying analysis, which is precisely why a bulk migration of a backlog is usually not worth funding.
v4.0 stops forcing every consideration through one scalar: the score carries the measurement, while the Supplemental group is a set of labels on the outside of the box that never change the weight printed on it.
saying these in an interview costs you the question
- Says v4.0 Supplemental metrics change the computed score
- Thinks the Threat group still includes Remediation Level
- Claims Scope survived into v4.0 unchanged
- Assumes v3.1 and v4.0 scores are directly comparable
- Proposes re-scoring the whole backlog to adopt v4.0
- Treats more metric groups as making the score deployment-aware