CVSS 4.0 Release Date, Changes, and Adoption Status

The CVSS 4.0 release date was November 1, 2023, when FIRST (the Forum of Incident Response and Security Teams) published the standard as generally available after a public preview that began in June 2023. It was the first major revision of the Common Vulnerability Scoring System since v3.0 in June 2015 (v3.1, released in 2019, was a clarification pass rather than a redesign). More than a year and a half on, v4.0 is officially supported by the CVE Program and the National Vulnerability Database, but the bulk of scores you encounter day to day are still v3.1 — which makes understanding how the two coexist a practical necessity, not trivia.

The timeline, briefly

• 2005–2007: CVSS v1 and v2 establish the idea of a common 0–10 severity scale.
• June 2015: CVSS v3.0 introduces the Scope metric and the severity bands (None/Low/Medium/High/Critical) most teams still use.
• June 2019: v3.1 clarifies definitions and formulas without changing the metric set.
• June 2023: FIRST previews CVSS v4.0 at its annual conference and opens a public comment period.
• November 1, 2023: CVSS v4.0 is published as generally available.
• 2024: The CVE Program's record format and the NVD add official CVSS v4.0 support, letting CNAs publish v4 scores alongside or instead of v3.1.

So if you see "CVSS:4.0/AV:N/AC:L/AT:N/..." vector strings in an advisory, that is post-November-2023 scoring; anything you carried over from before is v3.1 or older.

What actually changed in CVSS 4.0

New nomenclature: CVSS-B, BT, BE, BTE

FIRST's biggest philosophical point in v4.0 is that a Base score alone was never meant to be a risk score. The new nomenclature makes explicit what you are looking at:

• CVSS-B — Base metrics only (intrinsic severity of the flaw)
• CVSS-BT — Base plus Threat (is it actually being exploited?)
• CVSS-BE — Base plus Environmental (what does it mean in your deployment?)
• CVSS-BTE — all three, the closest thing to a defensible prioritization input

If your ticketing rules still say "CVSS above 7 = fix in 7 days" against raw Base scores, v4.0 is politely telling you that was always the wrong usage.

Base metric changes

• Attack Requirements (AT) is a new base metric capturing preconditions in the target's configuration (for example, a race condition that only triggers under specific settings) — distinct from Attack Complexity, which now focuses on measures the attacker must defeat.
• User Interaction is more granular: None, Passive, or Active, replacing the old binary None/Required.
• Scope is gone. The v3 Scope metric was the most inconsistently applied concept in the standard. v4.0 replaces it with two explicit impact sets: Confidentiality/Integrity/Availability for the Vulnerable System (VC/VI/VA) and for Subsequent Systems (SC/SI/SA). A container escape, for instance, now expresses "low impact on the vulnerable container, high impact on the host" directly.

Threat replaces Temporal

The old Temporal group (Exploit Code Maturity, Remediation Level, Report Confidence) collapses into a single Threat metric: Exploit Maturity. Fold in threat intelligence — is exploitation Attempted, is a PoC public, or is it Unreported — and the effective score adjusts. In practice this is where CVSS v4 meets feeds like CISA KEV and EPSS in a prioritization pipeline.

Supplemental metrics

A new, non-scoring Supplemental group conveys context: Safety (can it hurt humans — relevant for OT/ICS), Automatable, Recovery, Value Density, Vulnerability Response Effort, and Provider Urgency. They never change the number; they exist so downstream consumers can build smarter triage on top.

A different scoring engine

v3.x computed scores from formulas with tuned coefficients. v4.0 instead ranks millions of possible metric combinations into equivalence classes ("MacroVectors") ordered by expert comparison, and derives the 0–10 score from that ordering. The output range and severity bands look familiar, but identical-looking vulnerabilities can land on somewhat different numbers than they did under v3.1. Do not expect a stable mapping from a v3.1 score to a v4.0 score.

Where adoption stands

Adoption has been steady but unhurried, which is normal for scoring standards — v3 took years to displace v2 as well. As of this writing:

• The NVD and CVE Program support v4.0 records, and a growing set of CNAs publish v4 vectors for new CVEs.
• Most of the installed base is still v3.1. The historical corpus of hundreds of thousands of CVEs was scored under v3.x (or v2), and re-scoring old entries at scale is not happening. Any tooling you run will be consuming mixed v3.1/v4.0 data for years.
• Scanner and platform support is now table stakes. Modern vulnerability and SCA platforms ingest both vector formats; the differentiator is whether they use the Threat and Environmental dimensions rather than sorting everything by Base score. A platform like Safeguard, for example, layers exploit-maturity and reachability signals on top of the base vector precisely because CVSS-B alone over-prioritizes unexploited criticals.
• Policy frameworks lag. Plenty of compliance regimes and customer security questionnaires still say "CVSS v3.1" verbatim. Expect to report both for a while.

What you should do about it

1. Accept dual-format reality. Store the vector string, not just the number, and record which version produced it. A "7.5" means different things under v3.1 and v4.0.
2. Stop treating Base as risk. Use CVSS-BT at minimum: a Critical with no known exploitation and an internal-only footprint is routinely less urgent than a High that is in CISA KEV. This is also the spirit of the standard now, not just practitioner folklore.
3. Fill in Environmental metrics where it pays. You will not hand-score everything, but for your crown-jewel systems, CVSS-BE/BTE turns a generic advisory into a deployment-specific decision. Automate what you can from asset metadata.
4. Watch for version mismatches in SLAs. If your vulnerability SLA thresholds were calibrated against v3.1 distributions, validate them against v4.0-scored findings before enforcement — the equivalence-class engine shifts some populations between severity bands.
5. Train the team on the new vectors. The AT metric and the VC/VI/VA vs SC/SI/SA split are the two things reviewers most often misread. A short internal workshop (or a structured training path) covers it in an afternoon.

The honest assessment

CVSS 4.0 is a genuinely better standard: the Scope removal alone eliminates the single largest source of scoring disputes, and the B/BT/BE/BTE framing forces the "severity is not risk" conversation that practitioners have been having informally for a decade. Its limitation is unchanged: CVSS describes a vulnerability, not your exposure to it. Pair it with exploitation data and asset context, and it earns its place in the pipeline. Use it as a lone sorting key, and v4.0 will disappoint you exactly the way v3.1 did.

FAQ

What is the exact CVSS 4.0 release date?

November 1, 2023. FIRST published CVSS v4.0 as generally available on that date, following a public preview and comment period that started in June 2023.

What replaced the Scope metric in CVSS 4.0?

Two explicit impact metric sets: Confidentiality, Integrity, and Availability for the Vulnerable System (VC/VI/VA) and for Subsequent Systems (SC/SI/SA). This expresses cross-system impact directly instead of through the ambiguous Scope flag.

Does the NVD use CVSS 4.0?

Yes — the NVD and the CVE Program added official CVSS v4.0 support in 2024, and CNAs can publish v4.0 vectors. However, the large majority of historical CVEs remain scored under v3.x, so consumers must handle both formats.

Can I convert a CVSS v3.1 score to v4.0?

Not reliably. v4.0 uses a different metric set and a different scoring methodology (equivalence classes rather than v3's formulas), so the same vulnerability must be re-scored against the v4.0 vector, not mathematically converted.