CVSS 3.1 accumulated two long-standing complaints. The first was that a base score, taken alone, said almost nothing about risk in a specific environment, yet almost everybody used base scores alone. The second was that the temporal metric group was too coarse to express what defenders actually wanted to know: is this being exploited right now. CVSS 4.0 restructured the standard around both complaints.
For financial services firms the practical question is what changes in remediation prioritisation and in the reports you receive from assessors. This article covers the structural changes, then the part that matters operationally.
Nomenclature comes first
The most useful change is also the simplest. CVSS 4.0 gives explicit names to which metric groups were used:
- CVSS-B — base metrics only
- CVSS-BT — base and threat metrics
- CVSS-BE — base and environmental metrics
- CVSS-BTE — base, threat and environmental metrics
This exists because "the CVSS score is 8.1" was ambiguous and frequently misleading. A CVSS-B of 8.1 is a statement about the vulnerability in the abstract. A CVSS-BTE of 8.1 is a statement about your deployment, with your compensating controls and current exploitation activity accounted for. Reports should state which they are giving you, and the nomenclature makes it impossible to be vague about it.
Scope is gone
The Scope metric in 3.1 was the most frequently misapplied element of the standard. Two competent assessors regularly disagreed on whether a vulnerability changed scope, and the score moved substantially depending on the answer.
4.0 removes it and replaces it with two impact sets. The Vulnerable System metrics (VC, VI, VA) describe impact on the component containing the vulnerability. The Subsequent System metrics (SC, SI, SA) describe impact on other components reached as a consequence. This is more work to assess but far less ambiguous, and it maps naturally onto how a finding is explained to a business audience: what breaks here, and what breaks downstream.
New and revised exploitability metrics
Attack Requirements (AT) is new. It separates conditions outside the attacker's control — a race window, a specific configuration, a particular deployment topology — from Attack Complexity, which in 3.1 conflated the two. A vulnerability that requires winning a race is now distinguishable from one that requires defeating a mitigation.
User Interaction (UI) gains a third value. Instead of none or required, it distinguishes Passive interaction (the victim performs an ordinary action such as viewing a page) from Active interaction (the victim must be induced to perform a specific, unusual action). For phishing-adjacent findings in a payments context this distinction changes prioritisation meaningfully.
Threat replaces temporal
The temporal group in 3.1 had three metrics: Exploit Code Maturity, Remediation Level and Report Confidence. The last two were rarely used and rarely useful. 4.0 keeps only Exploit Maturity (E), with values covering unreported, proof-of-concept and actively attacked.
This is a simplification worth adopting. Exploit Maturity is the metric that should move a finding up or down your remediation queue on a weekly basis, and having it as the single threat dimension makes it operationally tractable: one field to update from threat intelligence, one field that changes the score.
Supplemental metrics
4.0 adds a supplemental group that carries information without affecting the numeric score: Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort and Provider Urgency.
Two of these are directly useful in financial services. Automatable states whether an attacker can reliably automate the full chain from reconnaissance to exploitation — which is exactly the property that separates a vulnerability that produces one incident from one that produces a campaign against every customer account. Value Density distinguishes a vulnerability that yields access to one user's data from one that yields access to a concentrated store. For a payment platform or a custodian, those two fields often carry more prioritisation signal than the score itself.
Scoring behaviour
The scoring function was rebuilt. 4.0 uses a lookup approach based on equivalence classes of metric combinations rather than the arithmetic formula of 3.1, calibrated against expert scoring data. The practical consequences are that the distribution across the severity bands is less clustered than 3.1, and that direct numerical comparison between a 3.1 score and a 4.0 score is not meaningful.
The qualitative bands are unchanged — None, Low, Medium, High, Critical, on the same thresholds — which makes migration less disruptive than it might have been. Do not, however, rescore a historic 3.1 finding set into 4.0 and compare year-on-year. Keep the standard version on the record with each finding and treat the transition as a break in the series.
What to do with it
For a regulated firm, three practical steps follow.
Define your environmental metrics once. Confidentiality, Integrity and Availability Requirements should be set per system class in advance — a custody signing service and a marketing site do not share a CR value — rather than argued per finding. This turns environmental scoring from a debate into a lookup.
Require the vector, not just the number. Any assessment report should publish the full vector string. Without it you cannot check the assessor's environmental assumptions, and you cannot rescore for your own deployment.
Prioritise on CVSS-BTE plus Automatable. Base-only prioritisation systematically over-invests in vulnerabilities that are unreachable in your architecture and under-invests in medium-scored issues that an attacker can automate against your entire customer base. That mis-ordering is the specific problem 4.0 was designed to address, and it only goes away if the additional metric groups are actually used.
