CVSS v3.1 vs CVSS v4.0

CVSS v3.1 vs CVSS v4.0: which version to cite and when to combine them

The choice of CVSS version is mainly about what your reports and remediation SLAs must be comparable with. If a penetration test report, a remediation SLA or a trend dashboard already uses v3.1 scores, keep citing v3.1 until those baselines are re-scored, because a v4.0 number next to a v3.1 number invites the wrong conclusion. If you are writing a new policy or commissioning a new test with no legacy baseline, cite v4.0 and state that choice explicitly. During a transition, a policy should name both: say which version drives SLA thresholds, which version appears in the report, and the date from which the switch applies. Ask your test provider which version each finding will carry and whether both scores will be shown.

CVSS v4.0 scores are not a drop-in replacement for v3.1 scores. The v4.0 specification restructures the metric groups: the Temporal group is renamed Threat, and a Supplemental group is added that adds context without changing the score. The nomenclature also changed, so a score can be shown as CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE to make clear which groups it includes. Confirm the exact groups behind any score you receive, because a Base-only v4.0 score and an enriched v3.1 score are not measuring the same thing. Do not mix the two in one trend chart without a separate series for each version and a note on the change.

Before you write the policy, check three things with your provider and your tooling: whether your scanner and ticketing system store the vector string with the version prefix, whether your SLA thresholds were calibrated on v3.1 score bands, and whether a v4.0 rescoring of past findings is needed to keep history meaningful. The FIRST CVSS v4.0 specification is the primary reference for metric definitions. Where a PCI SSC assessment or another regulator requires a traceable severity basis, the report should explain how the rank was derived and any environmental adjustments.

How CVSS v3.1 and v4.0 differ on the factors buyers compare

This table compares CVSS v3.1 and v4.0 on the factors that change how a finding is scored, labeled and reported. Read each row as a question a buyer would ask of a penetration test report or a vulnerability management policy, and check the cells marked for confirmation against the FIRST documents before writing them into a contract or policy.

Factor	CVSS v3.1	CVSS v4.0
Metric groups	Base, Temporal and Environmental groups	Base, Threat, Environmental and Supplemental groups; Threat replaces Temporal
Time-varying metrics	Temporal group covers exploit code maturity, remediation level and report confidence	Threat group covers characteristics that change over time, such as known exploitation; confirm exact metrics in the FIRST specification
Score nomenclature	Scores are reported as a base score with optional temporal and environmental scores	Scores carry a label showing which groups are included: CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE
Supplemental context	No separate group for context that leaves the score unchanged	Supplemental group adds context that does not change the score; confirm which items it lists
Specification history	Predates v4.0; confirm the release history on the FIRST site	First published 1 November 2023; current specification is version 1.2, dated 18 June 2024 (FIRST)
Reporting a score	Report the version prefix and the metric vector used for the base score	Report the nomenclature label and the vector, so readers know whether threat or environmental values were applied
Enrichment a consumer must add	Temporal and environmental values are optional inputs that the reporter must justify	Threat and environmental values are not required but highly recommended; factors such as regulatory requirements or breach losses sit outside CVSS

What changed in CVSS v4.0: the Threat group replaces Temporal

CVSS v4.0 renamed the Temporal metric group to Threat, and the change matters most when you read a score in a report. The Threat group holds characteristics that change over time, such as whether exploit activity is known. The Supplemental group is new in the sense that it adds context, such as safety or automatable details, without changing the numeric score. Base reflects constant characteristics of the flaw, and Environmental reflects your own deployment. When a penetration test report or scanner export shows only a Base score, the reader should assume that no time-dependent or environmental adjustment has been applied, and should ask the tester or vendor which groups were used.

CVSS v4.0 also adds nomenclature to show which groups a reported score includes. CVSS-B means the score uses Base metrics only. CVSS-BT adds Threat metrics, CVSS-BE adds Environmental metrics, and CVSS-BTE includes all three. A bare number with no label is ambiguous, because two teams can quote the same flaw as 9.3 and mean different things. The vulnerability management policy should require the label next to every score, and the penetration test report should state which label applies to each finding so that the remediation owner can trace how the rank was derived.

The specification says Threat and Environmental values are not required but are highly recommended for more meaningful results. It also states that factors such as regulatory requirements or breach losses are outside the scope of CVSS. Your policy should therefore assign those factors separately, through a documented decision such as a remediation deadline for in-scope regulated systems. Confirm with your tester whether they populated Threat and Environmental values from evidence you can review, and ask who supplied the environmental inputs, because those values depend on your asset context rather than on the tester's view of the flaw.

What each version finds, misses and needs from the reader

CVSS v3.1 and v4.0 both produce a severity number, but each layer of that number answers a different question. The cards below walk through the layers in order, from the constant Base score to the supplemental context that informs triage without changing the number.

Base-only score

A Base score describes the constant characteristics of a flaw, such as attack vector, complexity and the impact on confidentiality, integrity and availability. It is the number most scanners and penetration test reports show first, so it is the number most often copied into a remediation SLA. It says nothing about whether the flaw is being exploited, whether it is reachable in your environment, or what a regulator expects. Check which version the report uses before comparing two scores, because v3.1 and v4.0 Base values are not interchangeable.

Base score enriched with Threat

In v4.0, the Threat group replaces the Temporal group from v3.1 and holds characteristics that change over time, such as whether exploit code is available. The CVSS v4.0 specification recommends adding Threat values to Base metrics, although the step is optional. A Threat-enriched score still does not confirm active exploitation in your estate, so the report should say which source supplied the Threat values. Ask whether the scanner or testing team refreshes these values after the initial assessment.

Environmental values for the asset

Environmental values let the reader adjust a score for the asset: how important the system is, and whether compensating controls such as network segmentation limit impact. This is where a scanner's generic result becomes a result for your specific host or application. The adjustment is only as good as the asset inventory and business impact ratings behind it, so the report should show the reasoning for each change. Environmental scoring is not a regulatory classification, and it does not replace the legal duties that apply to the data.

Supplemental context for triage

The Supplemental group, which exists in v4.0 and has no v3.1 equivalent, adds context such as safety, automatable behavior or recovery characteristics. It informs triage and prioritization without changing the Base, Threat or Environmental numbers. Teams should record these values in the finding so the reader can see why two identical scores were handled differently. Confirm with the testing provider whether the report fields follow the v4.0 Supplemental definitions or a local convention.

What the score omits

No CVSS layer states whether exploitation is happening, whether a patch exists, or what a regulator or contract requires. The CVSS v4.0 specification places factors such as regulatory requirements and breach losses outside its scope. A reader who needs those answers should pair the score with exploitation data and a documented policy. Confirm which catalogs and internal rules your vulnerability management policy uses alongside CVSS.

What a penetration test report and a vulnerability management policy should each say

A penetration test report is the record a reader will check when a finding is disputed, retested or cited in an audit. PCI SSC's Penetration Testing Guidance expects the report to explain how severity or risk rankings were derived, typically from an industry score such as CVSS, and to show traceable reasoning wherever a score was adjusted for the environment. For CVSS v3.1 and CVSS v4.0, that means the report should not just print a number. It should state which version produced it and which metric groups the number includes, so a reader can tell a Base-only score from a score that also reflects threat or environmental context.

Version on every finding: Name the CVSS version for each finding, not once in the front matter, so a finding copied into a ticket keeps its scoring basis.
Metric groups stated: For v4.0, identify whether the score is Base only (CVSS-B) or includes Threat and Environmental values (for example, CVSS-BTE). Record the same distinction for v3.1 using its Base and Temporal values.
Derivation shown: Give the vector string and the metric values that produced the score, so the severity can be recomputed independently.
Environmental adjustments justified: Where a tester lowers or raises severity for the client's compensating controls or asset criticality, record the adjustment, the evidence behind it and the reasoning in the finding.
Scope of the score stated: Note that CVSS does not cover regulatory or business impact, so any ranking that considers those factors should be labeled as a separate judgment.

Check that each finding's vector string can be recomputed with the named version's calculator, and that every environmental adjustment points to evidence a client can review.

What you receive from each side of the scoring decision

This table sets the deliverables from an external penetration test against those from an internal vulnerability management policy, both of which must state which CVSS version they use. Read each row as a question to put to your provider or to check in your own policy draft, since the score derivation itself should be verified against the FIRST specification.

Deliverable	Provider penetration test report	Internal vulnerability management policy
CVSS version statement	States whether findings use CVSS v3.1 or v4.0, and the version named on each finding	Names the version the organization scores with, and what happens to findings scored under the other version
Metric group label	Shows which groups a score includes, such as Base only or a Base with Threat and Environmental combination, using the v4.0 nomenclature where v4.0 is used	Requires every score recorded in the register to carry its metric group label so scores from different tests stay comparable
Base scores	One Base score per finding with the vector string, so a reader can recompute it	Defines who may assign Base scores and whether testers' scores are accepted or re-scored internally
Threat and Environmental adjustments	Explains any adjustment made for exploit maturity or the client's environment, with the reasoning written out	Sets which Threat and Environmental values are required, who supplies them, and how often they are reviewed
Supplemental context	Notes any supplemental information that adds context without changing the score, such as safety or automatable impact	Decides whether supplemental context is recorded and how it is used in prioritization without altering the score
Derivation notes	Explains how severity or risk ranking was derived, per PCI SSC guidance, so the reader can trace the reasoning	Requires traceable derivation for any score that departs from the vendor or tester value
Remediation SLA mapping	Gives remediation context per finding but does not set the client's deadlines	Maps severity bands to remediation timelines that the organization sets and enforces
Review cadence	Usually a point-in-time deliverable tied to one engagement	States how often scoring rules, enrichment sources and SLA mappings are reviewed when the specification or threat picture changes

What drives the cost and effort of moving to CVSS v4.0

Moving from CVSS v3.1 to CVSS v4.0 is mostly a rescoring, tooling and process project rather than a single software purchase. The cards below separate one-time work from recurring work, and each one names the factor that makes it larger or smaller in your environment.

Re-scoring the existing findings

Someone has to decide whether open findings are re-scored under v4.0, or whether v3.1 scores stay in place until each item is retired. The one-time effort scales with the number of open findings and the number of reports that quote a score. Ask the vendor or service provider whether re-scoring is in the written scope, and whether historical reports will be left unchanged.

Scanner and ticketing tool support

Each tool that stores, displays or filters scores must handle v4.0 vectors, and some may only store a base number. Check whether your scanner, penetration test platform and ticketing system read the v4.0 vector string, keep v3.1 and v4.0 scores apart, and expose the Threat and Supplemental fields for filtering. Upgrades and custom fields are often one-time work, while license tiers and connector maintenance recur.

Analyst training on Threat and Environmental inputs

The Threat group replaces Temporal, and analysts must learn when exploit maturity should change a score and when an environmental value should be applied. This is mostly one-time training, but it recurs as new analysts join and as scoring guidance changes. The effort grows with the amount of asset context your team already holds, such as asset criticality and exposure data. Ask for a written method that shows which inputs are required and which are optional.

Policy and SLA rework

A vulnerability management policy that names CVSS v3.1 thresholds, or remediation deadlines tied to score bands, must be reviewed for v4.0 scores. Legal, risk and audit stakeholders may need to approve the change, and penetration test report templates need a stated version. Policy review is one-time, but the SLA reporting and exception handling it creates recur every reporting cycle. Ask for the review and approval steps to be listed as deliverables.

Traceability for adjusted scores

PCI SSC's Penetration Testing Guidance expects a report to explain how severity was derived, with traceable reasoning when a score is adjusted for the environment. Recording each Threat and Environmental input, and who set it, adds recurring effort on every finding. The workload is smaller when the team already records evidence for each finding and larger when adjustments are made by hand in spreadsheets. Ask how the adjusted score and its justification will be stored with each finding.

Questions buyers ask about CVSS v3.1 and v4.0 before hiring help

Do we have to switch from CVSS v3.1 to v4.0 now?

No single rule forces the switch from the specification alone, so the answer depends on what your reports, tools and customers expect. CVSS v4.0 was first published by FIRST on 1 November 2023, and the current specification document is version 1.2, dated 18 June 2024. Check what your scanners, ticketing system and client contracts record, and what your compliance program asks for. Many teams run both versions for a period, which means they need a clear rule for which score drives remediation deadlines. Confirm that rule in writing before you change any reporting template.

Can our own team re-score findings in v4.0 without outside help?

Yes, a capable internal team can re-score findings, provided it reads the specification and applies the metric definitions consistently. The work is mostly judgment about attack requirements, user interaction and impact on each system, so the main risk is inconsistency between analysts rather than missing skills. Write down how each metric is set for your environment and have a second reviewer check a sample. Outside help usually adds value in calibrating that method, reviewing a difficult batch, or documenting the reasoning for an assessor. DeployOpen plans and implements this kind of work on written scope, so ask for the deliverables in writing.

How much effort does re-scoring open findings take, and what drives it?

Effort is driven by the number of open findings, how many distinct vulnerabilities they cover, and how much of your environment context has to be documented first. Findings that share a root cause can often be scored once and reused, while findings tied to internet-facing systems or sensitive data need more careful review. Your asset inventory determines how quickly an analyst can answer environmental questions. Ask any provider for a written breakdown: what is counted per finding, what is reviewed by a second person, what is delivered as a register, and whether ongoing re-scoring is included or billed separately. No duration is set here because it depends on your scope.

Does a penetration test report have to name the CVSS version it uses?

Your report should state the version, because a score without a version is hard to reproduce or compare. PCI SSC's Penetration Testing Guidance expects the report to explain how severity or risk rankings were derived, typically from industry scores such as CVSS, with traceable reasoning when a score is adjusted for the environment. Ask the tester to name the version, list which metric groups were included, and show any environmental adjustments. Confirm your own contractual or regulatory requirements, because the guidance describes expectations rather than a single mandated format.

How do we compare v3.1 and v4.0 trends in our vulnerability metrics?

Do not plot v3.1 and v4.0 scores on one line without adjustment, because the two versions use different metric definitions and the scores are not interchangeable. Keep a separate series for each version and mark the date you changed. Where you need continuity, re-score a sample of historical findings in v4.0 and compare the two sets, then report that overlap as a method, not as a proven trend. Ask your reporting team to label every chart with its version. The specification is the reference for how the groups and nomenclature fit together.

What does the work need from our asset inventory and tool owners?

The work needs an accurate asset list, an owner for each system, and a clear view of what each system is exposed to and what data it holds. CVSS v4.0 asks for environmental and threat context, and the specification notes that Threat and Environmental values are not required but are highly recommended. Tool owners must confirm how their scanners export severity, which version they use, and whether they can store both scores. Plan for a named contact who can answer questions about each asset, and agree how changes to asset data are recorded.

Does CVSS alone satisfy a compliance requirement?

No. CVSS measures technical severity, and the specification states that factors such as regulatory requirements or breach losses are outside its scope. A score can feed a remediation policy, but it does not prove that a control operates, that a deadline was met, or that a regulator is satisfied. Map your use of CVSS to the specific requirement in your framework, document the process and evidence, and confirm with your assessor which artifacts they expect. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.

How DeployOpen scopes, delivers and supports security testing

DeployOpen plans, implements and documents security testing inside your own infrastructure, so scoring decisions are made against your systems and evidence. We help teams decide which CVSS version their reports and policy should name, then build the controls and records that show how scores were applied.

How we scope

Engagements are fixed-scope, with the scoring version, deliverables and timelines agreed in writing before work starts.
The written scope names which CVSS version your penetration test reports and vulnerability management policy will use.
We confirm which Base, Threat, Environmental and Supplemental values your team will record, and who approves changes to them.

How we build

We set up scoring fields and report templates so each finding shows its CVSS version and the metric groups included.
Environmental and Threat inputs are documented with the source of each value, so adjusted scores can be traced by an auditor.
Where your scanners or ticketing tools store CVSS values, we check how each tool handles the v3.1 and v4.0 vectors.

How we hand over

You receive a written scoring method that explains how each severity was derived, with examples drawn from your own findings.
Policy wording covers which CVSS version applies, when re-scoring happens, and who owns the Threat and Environmental inputs.
Handover includes a short record of open questions for your security lead, such as tool support gaps, to resolve before the next cycle.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so scoring practice can be reviewed as the specification changes.
We can review future test reports against the documented method to confirm that scores and nomenclature stay consistent.
Support scope and frequency are set in a written agreement, and a quote follows from that scope rather than a fixed price list.

CVSS v3.1 vs CVSS v4.0