CVSS 4.0 vs CVSS 3.1: Differences, Migration, Audit Impact
FIRST released CVSS 4.0 in November 2023 as the first major revision to the Common Vulnerability Scoring System since CVSS 3.0 in 2015. Three years on, most enterprise vulnerability management, AppSec, and GRC programmes still anchor to CVSS 3.1 because of compatibility with three years of historical scoring, scanner output, vendor advisories, and audit framework references; CVSS 4.0 is gaining ground in NVD enrichment and in newer CNA publications. This guide walks through what actually changed between 3.1 and 4.0, why each change exists, how the new score is computed, what the named CVSS-B / CVSS-BT / CVSS-BE / CVSS-BTE combinations mean, where CVSS 4.0 has and has not been adopted, and a defensible migration plan for an enterprise programme that needs to keep its evidence trail intact.
A Short History: Why CVSS 4.0 Exists
CVSS 3.0 (2015) restructured the 2.0 metric set around explicit Exploitability and Impact subscores and introduced the Scope concept to model vulnerabilities that affect components beyond their immediate container. CVSS 3.1 (2019) was a clarification release: the same metrics, the same math, refined wording and worked examples to reduce inter-rater variance. Most enterprise programmes have been running 3.1 for seven years.
CVSS 4.0 was developed by the FIRST Special Interest Group across roughly four years of public review and published in November 2023. The headline goals: produce more granular Base scores by separating the attacker-controlled difficulty of an exploit from environmental conditions outside the attacker control, replace the single Scope flag with an explicit Vulnerable System and Subsequent System impact pair to remove the ambiguity that made S:C reasoning hard to score consistently, retire the Temporal group in favour of a leaner Threat group, and add a Supplemental metrics group for advisory signals (safety, automatable, recovery) that programmes wanted but the closed-form scoring formula could not absorb without distorting the underlying severity. The result is a richer vector that is harder to misuse but requires more discipline to score and more lookup-table machinery to compute. For the underlying CVSS mechanics that 4.0 builds on, see the CVSS 3.1 vector strings, base score, and severity rating scale guide; this page focuses on what changed.
The Four Metric Groups in CVSS 4.0
CVSS 3.1 had three metric groups: Base, Temporal, and Environmental. CVSS 4.0 has four: Base, Threat, Environmental, and Supplemental. The names matter because CVSS 4.0 also introduces an explicit nomenclature for which combination of groups a given score includes.
| Group | CVSS 3.1 | CVSS 4.0 | Affects numeric score |
|---|---|---|---|
| Base | AV, AC, PR, UI, S, C, I, A (eight metrics, single Scope flag) | AV, AC, AT, PR, UI, VC, VI, VA, SC, SI, SA (eleven metrics, explicit Subsequent System) | Yes |
| Threat (was Temporal) | E (Exploit Code Maturity), RL (Remediation Level), RC (Report Confidence) | E (Exploit Maturity) only; RL and RC removed | Yes |
| Environmental | CR, IR, AR plus modified Base metrics (eight) | CR, IR, AR plus modified Base metrics (eleven) | Yes |
| Supplemental (new) | Did not exist | S, AU, R, V, RE, U (Safety, Automatable, Recovery, Value Density, Response Effort, Provider Urgency) | No (advisory only) |
The CVSS 4.0 Naming: B, BT, BE, BTE
CVSS 4.0 formalises four named score combinations. The names are not cosmetic; they encode which metric groups the score includes, which is the single most commonly miscommunicated property of a CVSS score in practice.
CVSS-B: Base Only
The Base group score with no Threat and no Environmental data layered on. This is what a CNA, vendor, or independent researcher publishes alongside a vulnerability advisory. It is the publishable score because it is reproducible from the vector alone with no environmental assumptions.
CVSS-BT: Base plus Threat
The Base group plus the Threat group (Exploit Maturity). This is the appropriate score for a published advisory that reflects what is currently known about exploitation in the wild. CVSS-BT is used when the issuing party wants to communicate the at-the-time threat picture without making environmental assumptions about the consumer side.
CVSS-BE: Base plus Environmental
The Base group plus the Environmental group, which lets a consuming organisation re-weight the score for the asset-specific Confidentiality, Integrity, and Availability requirements (CR, IR, AR) and modify the Base metrics for environmental conditions. CVSS-BE is the right score for an asset owner producing a per-asset severity for SLA purposes when threat intelligence is not the dominant factor.
CVSS-BTE: Base, Threat, and Environmental
The full score with all three score-influencing groups included. CVSS-BTE is the most informed score a programme can produce for a specific finding on a specific asset under a specific threat picture. It is also the least transferable: the Threat and Environmental inputs depend on the consuming organisation, so CVSS-BTE is not a publishable score but an internal one.
Why this matters: CVSS 3.1 conflated all four under a single CVSS Base / Temporal / Environmental phrase. Consumers who read a vendor advisory routinely treated the published Base as a CVSS-BE or CVSS-BTE because the language did not distinguish them. CVSS 4.0 makes the distinction explicit so the published advisory, the threat-aware advisory, and the asset-specific severity can be different scores with different names on the same finding.
Base Group: What Changed Metric by Metric
Eight of the eleven CVSS 4.0 Base metrics retained their CVSS 3.1 names (AV, AC, PR, UI, plus the four impact metrics now split across two systems). Three are new or restructured.
Attack Complexity (AC) and Attack Requirements (AT): the split
CVSS 3.1 had a single AC metric that mixed two ideas: how hard the exploit is for the attacker, and what conditions in the target environment have to hold. CVSS 4.0 splits these. AC now models only the attacker-controlled difficulty (specialised techniques, evasion of defences, the need for attacker preparation). AT is a new metric capturing target-side conditions outside attacker control: a race condition that needs a timing window the attacker does not control, a TLS downgrade that needs a specific network position, an exploit that succeeds only when a non-default configuration is in place. AT:None means the exploit succeeds whenever the attacker can launch it; AT:Present means there is a target-side gate that may or may not be present at exploitation time.
Privileges Required (PR) and User Interaction (UI): refined
PR retained its three values (None, Low, High) and the same broad meaning. UI was restructured. CVSS 3.1 had two values (None, Required). CVSS 4.0 has three: None, Passive, and Active. UI:Passive describes interactions a user routinely performs without security awareness (visiting a page, opening an email). UI:Active describes interactions that require security-relevant intent (running an installer, accepting a warning dialog). The split lets the score distinguish drive-by exploits from social-engineering-required exploits more honestly.
Vulnerable System Impact (VC, VI, VA) and Subsequent System Impact (SC, SI, SA): replacing Scope
CVSS 3.1 used a single Scope flag (S:U or S:C) plus C, I, A impact metrics that applied either to the vulnerable component or to the impacted component depending on Scope. CVSS 4.0 abandons the flag and requires the scorer to fill out two impact triplets. VC, VI, VA describe the impact on the Vulnerable System (the component containing the vulnerability). SC, SI, SA describe the impact on Subsequent Systems (anything beyond the vulnerable component). A sandbox escape becomes legible in the score because high SC, SI, SA explicitly describe damage outside the sandbox; a sandbox-internal data leak shows high VC and SC:None. The split is the most consequential change in 4.0 because it drives the most score-band shifts on real vulnerabilities.
Threat Group: Why It Replaced Temporal
CVSS 3.1 Temporal had three metrics: Exploit Code Maturity (E), Remediation Level (RL), and Report Confidence (RC). The intent was to let the score reflect what was currently known about exploitation, remediation availability, and disclosure confidence. In practice, RL and RC were rarely used and rarely updated; programmes that ran scoring at scale ignored them, and the closed-form formula gave both metrics small enough weights that the operating impact was negligible. CVSS 4.0 retired RL and RC entirely and kept Exploit Maturity, renamed the group from Temporal to Threat, and gave E a more meaningful weight in the macrovector lookup.
Exploit Maturity (E) values in CVSS 4.0: Attacked (A), Proof-of-Concept (P), Unreported (U), and Not Defined (X). The renaming from Functional / High / Proof-of-Concept / Unproven aligns with the way EPSS and CISA KEV describe exploitation evidence, which makes the Threat metric easier to populate from existing telemetry. Programmes that ingest EPSS and KEV alongside CVSS can map: a KEV-listed CVE is CVSS-E:A; a CVE with public PoC and no observed exploitation is CVSS-E:P; a CVE with no public exploit evidence is CVSS-E:U.
For the surrounding likelihood layer that the Threat group sits next to, see the EPSS score explained guide and the CISA KEV catalog guide. CVSS 4.0 Exploit Maturity is the in-vector mirror of the same evidence those external feeds publish.
Environmental Group: Same Idea, More Inputs
The Environmental group works the same way it did in CVSS 3.1: the consuming organisation re-weights the score for asset-specific Confidentiality, Integrity, and Availability requirements (CR, IR, AR) and can modify the Base metrics for environmental conditions. The difference in 4.0 is the input set. CVSS 3.1 allowed modified versions of eight Base metrics; CVSS 4.0 allows modified versions of all eleven Base metrics, including the new Subsequent System impact triplet (MSC, MSI, MSA) and the new Attack Requirements (MAT). A programme operating under CVSS 4.0 can therefore re-weight Subsequent System damage for assets where containment is or is not effective, which was not expressible in 3.1.
The CR, IR, AR mechanic is unchanged: each asks whether the asset has Low, Medium, High, or Not Defined requirements for the corresponding impact dimension, and the modified score amplifies or dampens the Base impact accordingly. Most programmes that already use CR/IR/AR in 3.1 can copy the asset-tier mapping straight into 4.0.
Supplemental Group: Advisory Metrics That Do Not Affect the Score
The Supplemental group is the most distinctive new feature in CVSS 4.0. Six metrics travel with the vector but do not affect the numeric score. They exist because programmes wanted to capture risk-relevant attributes the closed-form formula could not absorb without distorting the technical severity.
| Metric | Values | What it captures |
|---|---|---|
| Safety (S) | Negligible, Present, Not Defined | Whether exploitation can cause physical harm in safety-critical or industrial environments. Used heavily in IEC 62443 and ICS contexts. |
| Automatable (AU) | No, Yes, Not Defined | Whether the exploit can be automated end-to-end (reconnaissance, weaponisation, delivery, exploitation). Wormable vulnerabilities are AU:Yes. |
| Recovery (R) | Automatic, User, Irrecoverable, Not Defined | Whether the affected system recovers automatically, requires user intervention, or cannot recover from exploitation. |
| Value Density (V) | Diffuse, Concentrated, Not Defined | Whether exploitation yields a single asset (Diffuse) or a concentrated population (Concentrated). A worm targeting domain controllers is Concentrated. |
| Vulnerability Response Effort (RE) | Low, Moderate, High, Not Defined | How hard remediation is for the consuming organisation. A patch with a quiet rollout is Low; a fix that requires an architectural change is High. |
| Provider Urgency (U) | Clear, Green, Amber, Red, Not Defined | The issuing CNA or vendor view of the urgency band, intended to align with TLP-style colour codes. |
Programmes use Supplemental metrics to flag wormable findings (AU:Yes), safety-critical findings (S:Present), or hard-to-fix findings (RE:High) for elevated SLA without distorting the technical severity. The metrics do not influence CVSS-B, CVSS-BT, CVSS-BE, or CVSS-BTE; they are recorded alongside as advisory data.
The Math: From Closed Form to Macrovector Lookup
CVSS 3.1 computes the Base score with a closed-form formula. The Exploitability subscore is a function of AV, AC, PR, UI; the Impact subscore is a function of C, I, A and Scope; the Base score is a roundup of their combination. Anyone implementing a calculator can copy the equations from the spec.
CVSS 4.0 abandons the closed-form formula. The vector is reduced to a six-dimensional macrovector through a published mapping (effectively a categorical hash of the eleven Base metrics into a tractable space), and the macrovector resolves to a base score through a lookup table the FIRST SIG published as part of the spec. Threat and Environmental scores follow the same macrovector mechanism with adjusted inputs. The change is invisible to scoring users (calculators run the lookup automatically) but matters for anyone implementing scoring: there is no closed-form CVSS 4.0 base score equation. The reference implementation lives in the official FIRST CVSS 4.0 calculator and a small number of open-source ports.
Why the change: the closed-form formula had structural irregularities at metric boundaries (small changes in input could produce disproportionate score shifts) that the SIG considered impossible to tune without breaking other parts of the score. A lookup table lets the SIG calibrate any specific metric combination directly. The trade-off is that the math is harder to inspect, harder to argue with, and harder to reproduce from the spec without the lookup table at hand.
Severity Rating Bands: Same Numbers, Different Population
CVSS 4.0 kept the CVSS 3.1 severity rating bands identical: None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9), Critical (9.0 to 10.0). What changes is the population that lands in each band because the metric definitions and the scoring math are different.
| Severity | CVSS Score | Common SLA mapping |
|---|---|---|
| Critical | 9.0 to 10.0 | Immediate or 7-day remediation, executive notification, KEV-tier handling. |
| High | 7.0 to 8.9 | 14-30 day remediation; common compliance threshold for elevated tracking. |
| Medium | 4.0 to 6.9 | 60-90 day remediation; standard programme cadence. |
| Low | 0.1 to 3.9 | Next release cycle; track and batch. |
| None | 0.0 | Informational; no remediation SLA. |
The operationally relevant point: a vulnerability that scored 7.5 (High) in 3.1 may score 6.8 (Medium) or 8.1 (High) in 4.0 because the new metrics influence the lookup. Historical comparability across the two versions is therefore not direct, which is why programmes that record both vectors during a transition track them as parallel evidence rather than substituting one for the other.
Worked Example: SQL Injection on an Internet-Facing API
Consider an authenticated SQL injection on a public-internet API endpoint that, when exploited, lets the attacker read and modify the underlying database for the API service but does not give shell access on the host. The exploit is a single HTTP request once the attacker has any authenticated session.
CVSS 3.1 vector and score
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Network attack vector, low complexity, low privileges, no user interaction, scope unchanged (S:U because the API process and the database client are the same security authority in 3.1 reasoning), high confidentiality and integrity impact, no availability impact. The 3.1 base score lands at 8.1 (High). The Scope:U decision is contestable (the database is arguably a second security authority), which is the source of the inter-rater variance the 4.0 changes target.
CVSS 4.0 vector and score
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:L/SI:L/SA:N
The same network, low complexity, low privilege picture; AT:None because the exploit succeeds whenever the attacker authenticates; UI:None because no user interaction is required. Vulnerable System impact is high for confidentiality and integrity (the API can read and modify its database). Subsequent System impact is low for confidentiality and integrity because the attacker can pivot from the API data to other parts of the estate that consume the same data, but not directly to additional systems. The 4.0 lookup produces a CVSS-B score in the high band; programmes that layer Threat (E:P if a public PoC exists, E:A if KEV-listed) and Environmental (CR/IR/AR by the API criticality) move the CVSS-BTE score accordingly.
What changed between the two scores
The biggest difference is the explicit Subsequent System impact. In 3.1 the scorer had to choose Scope:U or Scope:C and the C, I, A impact metrics applied to whichever side Scope selected. In 4.0 both impact triplets are filled, so the score reads precisely: high VC and VI on the API itself, low SC and SI on systems beyond. The CVSS 3.1 8.1 and the CVSS 4.0 score are not the same number, but they describe the same vulnerability with more disambiguation in the 4.0 vector. For a programme running both, recording both vectors together preserves the reasoning trail without requiring a version choice.
Adoption Status as of 2026
Three years after release, CVSS 4.0 is alongside CVSS 3.1 in most ecosystems but has not displaced it. The pragmatic posture for most enterprise programmes is dual-tracking, with CVSS 3.1 as the operating anchor and CVSS 4.0 recorded when the source publishes one.
| Source | CVSS 3.1 | CVSS 4.0 |
|---|---|---|
| NVD CVE enrichment | Primary baseline; populated for almost all CVE records | Added where the source CNA publishes one; growing share of new records |
| CISA ADP advisories | Standard alongside 4.0 | Increasingly published alongside 3.1 in newer advisories |
| Microsoft MSRC | Published per advisory | Mixed; gradually adding 4.0 vectors |
| Oracle Critical Patch Updates | Primary score | Limited 4.0 adoption |
| RedHat advisories | Per advisory | Trending toward dual publication |
| Network and web scanners (Nessus, Burp Suite, Qualys, Rapid7) | Default vector form in output | Optional or roadmap; not yet default |
| PCI DSS, ISO 27001, SOC 2, NIST 800-53 | Implicitly assumed when CVSS is referenced | No version requirement; either is acceptable |
Migrating an Enterprise Programme: A Defensible Plan
A programme operating under CVSS 3.1 today can move to dual-tracking, then incrementally toward CVSS 4.0 primary, without breaking the audit trail. The discipline is to treat the migration as a recordkeeping change, not a scoring re-run.
- Phase 1, dual-track ingest. Add CVSS 4.0 vector storage to the finding record alongside CVSS 3.1. When a CNA, NVD, or scanner emits both, store both. When a source emits only one, store what is available. Do not back-score historical findings; the cost of re-scoring the historical record exceeds the operational value.
- Phase 2, audit-evidence parity. Update the audit-evidence pack to record CVSS-B (Base) as the published score from each source, plus CVSS-BE for asset-specific re-weighting where the programme already runs CR/IR/AR. Most programmes that record CR/IR/AR in 3.1 can copy the asset-tier mapping into 4.0 without change.
- Phase 3, SLA mapping continuity. Keep the SLA bands tied to severity labels (Critical, High, Medium, Low) rather than to a specific CVSS version. Because the band boundaries are identical between 3.1 and 4.0, the SLA policy does not need to change. The programme continues to run a Critical SLA on score 9.0 or above regardless of which version produced the score.
- Phase 4, exception and disposition discipline. When a finding has both a 3.1 score and a 4.0 score, record both on the disposition. If the band differs between the versions, the exception register notes which version drives the SLA decision and why. Most programmes run a higher-band-wins rule as the safe default; some programmes anchor to the version the source publishes.
- Phase 5, supplemental metric capture. Once dual-tracking is stable, add CVSS 4.0 Supplemental metric capture for findings where Safety, Automatable, or Response Effort meaningfully changes the response. Wormable findings (AU:Yes) and safety-relevant findings (S:Present) are the highest-value Supplemental signals; the others can wait until the operational picture demands them.
CVSS 4.0 in the Wider Prioritisation Stack
CVSS 4.0 is one signal among several in a modern vulnerability prioritisation framework. EPSS speaks to likelihood, KEV speaks to observed exploitation, CWE speaks to weakness class, and reachability analysis speaks to whether the affected code path is actually exercised. CVSS 4.0 changes none of those layers; it only refines the technical severity layer they sit alongside.
For the multi-signal prioritisation framework that combines CVSS, EPSS, KEV, and asset context, see the vulnerability prioritisation framework guide. For the action-call layer that sits above the score (Track, Track-star, Attend, Act), see the SSVC stakeholder-specific vulnerability categorization guide. For the noise-reduction layer that runs before any prioritisation function consumes inputs, see the reachability analysis guide. CVSS 4.0 is the technical-severity refinement; the other layers continue to do the same work they did under 3.1.
Audit-Evidence and Compliance Implications
Audit frameworks do not specify a CVSS version. ISO 27001 Annex A 8.8 (technical vulnerability management), SOC 2 Trust Services Criteria CC7.1 (system monitoring), PCI DSS Requirement 6.3 (vulnerability identification and ranking), NIST 800-53 RA-5 (vulnerability monitoring) and SI-2 (flaw remediation) all require a defensible technical-severity score with a documented SLA mapping; they do not say which version that score must use. Auditors read the consistency of the programme rather than the version.
The defensible audit-evidence posture during the dual-tracking transition has three components. First, document which version is the programme primary score and why (most programmes anchor to 3.1 in 2026 because of historical comparability). Second, record both scores on findings where both are available, so the audit trail shows the version reasoning rather than implying a silent swap. Third, keep the SLA mapping tied to the severity label rather than the version, so the policy continues to mean what it says when the primary version eventually changes.
For the audit-evidence cadence and durability discipline this sits inside, see the audit evidence half-life research and the audit evidence retention workflow. Both treat the score itself as a small part of the evidence record; the durability, the timestamped-state-change trail, and the framework mapping carry most of the audit weight.
How SecPortal Records CVSS 3.1 and CVSS 4.0
SecPortal exposes a standalone CVSS calculator that supports both CVSS 3.1 and CVSS 4.0 Base score calculation. The calculator runs the full CVSS 4.0 macrovector lookup over the eleven Base metrics (AV, AC, AT, PR, UI, VC, VI, VA, SC, SI, SA), produces the CVSS-B score and severity label, generates the 4.0 vector string, and supports a shareable URL for handing the score off to a remediation owner. The 3.1 calculator on the same page produces the equivalent for the 3.1 metric set.
Inside the engagement record, the findings management workflow stores the CVSS vector and base score on each finding for downstream reporting and audit-evidence purposes. The in-product finding-side calculator and the 300+ finding template library currently default to CVSS 3.1 vectors; CVSS 3.0 and 3.1 vector strings are parsed on import (so scanner output and vendor advisories using either form are accepted without conversion). For programmes dual-tracking during the CVSS 4.0 transition, the operating pattern is to compute the CVSS 4.0 Base score on the standalone calculator, copy the resulting 4.0 vector and score into the finding evidence section as supplementary data, and continue to record the CVSS 3.1 vector as the calculator-backed primary score on the finding for SLA continuity.
Scanner imports preserve the original CVSS vector emitted by the source tool. When scanners that emit CVSS 4.0 vectors land in the import surface, the imported vector text is preserved on the finding record alongside the 3.1 vector when both are available. The activity log captures CVSS-related state changes (vector edits, severity recalibration, evidence updates) with timestamps and the acting user, which is the audit-evidence trail an external auditor reads when reconciling the SLA decision against the recorded score. The compliance tracking surface maps findings to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST framework references with CSV export for evidence packs.
What the platform does not do: SecPortal does not autoconvert between 3.1 and 4.0 vectors (no defensible mapping exists that would let a 3.1 vector mechanically produce a 4.0 score because the metric definitions differ), does not subscribe to CVSS-version-specific feeds, and does not replace the policy-side decision about which version is the programme primary score. Those decisions remain with the security organisation; the platform records the version reasoning and the resulting SLA decision in the finding lifecycle.
Where the Programme Sits in the Wider Security Org
CVSS scoring is one input into a wider internal security organisation. The version decision sits next to the daily operational discipline of the vulnerability management team, the engineering-side AppSec function, the GRC owner cadence, and the leadership reporting cadence the CISO produces.
For the find-track-fix-verify operator function, see SecPortal for vulnerability management teams. For the AppSec function that triages scanner output for engineering ownership, SecPortal for AppSec teams covers the upstream. For the CISO sponsoring the programme, the SecPortal for CISOs page covers how scoring decisions roll up into leadership reporting. For the GRC owner translating scoring discipline into evidence, SecPortal for GRC and compliance teams covers the audit-side discipline. For the per-finding triage operator running the queue every shift, SecPortal for SOC analysts covers the scoring calibration practice at finding granularity.
Buyers comparing dedicated risk-based vulnerability management platforms (which build proprietary exploit-likelihood scoring on top of CVSS, EPSS, and KEV signals) to a single workspace that records CVSS 3.1, CVSS 4.0, EPSS, KEV, and engagement context together can read the SecPortal vs Kenna Security comparison for the side-by-side, and the risk-based vulnerability management buyer guide for the broader category framing.
Record CVSS 3.1 and CVSS 4.0 on a Single Engagement Record
The CVSS 4.0 transition is mostly a recordkeeping problem in disguise. Both vector forms are public, both map to the same severity bands, and both feed the same SLA policy if the policy is anchored to the severity label. What stops most programmes from getting clean dual-track evidence is that the per-finding CVSS vectors, the lifecycle audit trail, the exception register, the framework mapping, and the leadership read all sit on different records, so producing the evidence pack means reconciling four or five sources at audit time. SecPortal is built around a single engagement record: findings management with the in-product CVSS 3.1 calculator plus the standalone CVSS 3.1 and 4.0 calculator at /tools/cvss-calculator for ad-hoc dual-track scoring, the activity log for the timestamped chain of state changes, compliance tracking with framework mapping and CSV export, and AI-powered report generation when leadership wants the executive summary. None of these features pull CVSS 4.0 automatically; the version choice is yours. What the platform does is keep the score, the lifecycle, the evidence, and the framework mapping on the same record so the audit conversation collapses into a query rather than a multi-team scramble.
Run dual-track CVSS scoring on SecPortal
Stand up the engagement record in under two minutes. Free plan available, no credit card required.
Frequently Asked Questions
What is the difference between CVSS 4.0 and CVSS 3.1?
CVSS 4.0 restructures the standard into four metric groups (Base, Threat, Environmental, Supplemental) where CVSS 3.1 had three (Base, Temporal, Environmental). The Base group adds Attack Requirements (AT), splits Privileges Required from User Interaction more cleanly, and replaces the single Scope flag with a Vulnerable System (VC, VI, VA) plus Subsequent System (SC, SI, SA) impact pair. The Temporal group is renamed to Threat and is reduced to a single metric (Exploit Maturity, E). A new Supplemental group introduces Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, and Provider Urgency as advisory metrics that do not affect the numeric score. The CVSS 4.0 nomenclature also formalises four named score combinations: CVSS-B (Base only), CVSS-BT (Base plus Threat), CVSS-BE (Base plus Environmental), and CVSS-BTE (full).
What is Attack Requirements (AT) in CVSS 4.0?
Attack Requirements (AT) is a new Base metric in CVSS 4.0 that captures conditions in the target environment that must be present beyond the attacker control before exploitation succeeds. It complements Attack Complexity (AC), which retained its name from 3.1 but now models only the attacker-controlled difficulty of the exploit (techniques, evasion, special access). Practical examples: a race condition that depends on a specific timing window outside the attacker control is AT:Present; a deserialisation bug that succeeds whenever input crosses the parser is AT:None; a TLS downgrade that requires a network position the attacker does not always have is AT:Present. Splitting AT from AC produces a more honest picture of exploitability for vulnerabilities that are easy in principle but operationally constrained.
What replaces Scope (S) in CVSS 4.0?
CVSS 3.1 collapsed the impact picture into a single Scope flag (S:U or S:C) plus Confidentiality, Integrity, and Availability impact metrics that applied either to the vulnerable component or to the impacted component depending on the Scope value. CVSS 4.0 replaces this with two explicit impact triplets: Vulnerable System Confidentiality, Integrity, and Availability (VC, VI, VA) describes the impact on the component containing the vulnerability, and Subsequent System Confidentiality, Integrity, and Availability (SC, SI, SA) describes the impact on systems beyond the vulnerable component. The split removes the ambiguity that made S:C reasoning hard to score consistently in 3.1 and produces a Base score that distinguishes a sandbox escape (high SC, SI, SA) from a sandbox-internal data leak (high VC only).
What is the CVSS 4.0 supplemental metrics group?
The Supplemental group is six advisory metrics that travel with the vector but do not affect the numeric score. Safety (S) flags vulnerabilities where exploitation can cause physical harm in industrial control or safety-critical environments. Automatable (AU) flags vulnerabilities that lend themselves to wormable exploitation. Recovery (R) describes whether the affected system recovers automatically, with user intervention, or not at all. Value Density (V) flags whether exploitation yields a single asset or a concentrated population. Vulnerability Response Effort (RE) flags how easy or hard remediation is. Provider Urgency (U) lets the issuing CNA or vendor mark the advisory urgency band. Programmes use these to flag wormable (AU:Yes) or safety-relevant (S:Present) findings for elevated SLA without distorting the underlying technical severity.
How is CVSS 4.0 severity calculated differently from CVSS 3.1?
CVSS 3.1 computes the Base score from a closed-form mathematical formula combining Exploitability and Impact subscores. CVSS 4.0 abandons the closed-form formula in favour of a lookup table approach (the MacroVector method): the metric vector is reduced to a five or six dimensional macrovector, and the macrovector resolves to a base score through a published lookup. The Threat and Environmental scores are computed from the same macrovector mechanism with adjusted inputs. The change is operationally invisible (calculators run the lookup) but matters for anyone implementing a calculator: there is no closed-form CVSS 4.0 base score equation to copy from the spec. The severity rating bands stayed identical (None 0.0, Low 0.1-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0).
Should we migrate to CVSS 4.0?
Most enterprise programmes in 2026 are running both. CVSS 3.1 remains the dominant vector form in the NVD historical record, in scanner output (Nessus, Burp Suite, Qualys, Rapid7), in vendor advisories (Microsoft MSRC, Oracle CPU, Cisco PSIRT), and in audit framework references (PCI DSS, ISO 27001, NIST 800-53). CVSS 4.0 is being added alongside 3.1 in NVD and CISA NVD enrichment for new CVEs. The pragmatic position: keep CVSS 3.1 as the operating anchor through 2026, ingest the 4.0 vector as a secondary record where the source publishes one, and revisit migration once NVD coverage and scanner output reach majority adoption. A premature cutover breaks the comparability with three years of 3.1 evidence on existing findings without producing a downstream operational gain.
Does CVSS 4.0 change the severity rating scale?
No. The severity rating bands are identical between CVSS 3.1 and CVSS 4.0: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0). What changes is which findings land in which band because the scoring math and metric definitions are different. A vulnerability that scored 7.5 (High) in 3.1 may score differently in 4.0 because Subsequent System impact and Attack Requirements influence the new score. That is the most-cited operational implication of migration: the SLA bands stay the same on paper, but the population that lands in each band shifts, so historical comparability across the two versions is not direct.
What is the CVSS 4.0 nomenclature (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE)?
CVSS 4.0 introduced explicit naming for the four meaningful score combinations. CVSS-B is the Base score alone (vendor-publishable, no environment, no threat intelligence). CVSS-BT is Base plus Threat (Exploit Maturity included). CVSS-BE is Base plus Environmental (asset-specific re-weighting). CVSS-BTE is the full score with all groups included. The naming matters because CVSS 3.1 conflated all four under a single CVSS Base / Temporal / Environmental phrase that buyers, scanners, and audit reviewers misread interchangeably. CVSS 4.0 vendor advisories typically publish CVSS-B; an enterprise programme should record CVSS-B from the source and produce CVSS-BE for its own consumption when environment-specific re-weighting matters for the SLA decision.
How does NVD handle CVSS 4.0 vs 3.1?
NVD continues to enrich CVE records with CVSS 3.1 vectors as the primary baseline because of the historical record, and it adds CVSS 4.0 vectors where the source CNA publishes them. The NVD JSON schema supports both vectors on the same record, and the API returns both when present. CISA-issued advisories under the ADP (Authorised Data Publisher) programme increasingly include 4.0. Vendor advisories from large issuers (Microsoft, Oracle, Cisco, RedHat, Adobe) are mixed and trending toward 4.0 alongside 3.1 rather than 4.0 alone. The defensible operating posture is to ingest both vectors when present and prefer 3.1 as the legacy comparability anchor through the 2026 reporting cycle.
Does SecPortal support CVSS 4.0?
SecPortal includes a standalone CVSS calculator at /tools/cvss-calculator that supports both CVSS 3.1 and CVSS 4.0 Base score calculation, runs the official CVSS 4.0 macrovector lookup over the eleven Base metrics, generates the 4.0 vector string, and supports a shareable URL for the result. Inside the engagement record, the findings management workflow stores CVSS vectors on each finding and parses CVSS 3.0 and 3.1 vector strings on import (so scanner output using either form is accepted without conversion). The in-product finding-side calculator and the 300+ finding template library currently default to 3.1 vectors. For programmes dual-tracking during the CVSS 4.0 transition, the operating pattern is to compute the 4.0 Base score on the standalone calculator, copy the resulting vector into the finding evidence section as supplementary data, and continue to record the 3.1 vector as the calculator-backed primary score on the finding for SLA continuity.
How does CVSS 4.0 interact with EPSS, KEV, and SSVC?
EPSS, the CISA KEV catalog, and SSVC are independent of the CVSS version and travel with the CVE rather than the score. EPSS produces a probability of exploitation in the next thirty days from CVE-level features and operates the same way against 3.1 and 4.0 records. KEV records observed exploitation against the CVE and is unchanged by the scoring version. SSVC consumes CVSS-class severity (any version) plus EPSS and exploitation evidence to emit an action call (Track, Track-star, Attend, Act). Migrating to CVSS 4.0 does not require migrating any of those layers. The prioritisation framework that combines CVSS, EPSS, KEV, and asset context continues to work; only the CVSS portion changes.
What audit-evidence implications does CVSS 4.0 migration have?
Audit frameworks (ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS 6.3, NIST 800-53 RA-5/SI-2) require a defensible technical-severity score with a documented SLA mapping. They do not specify a CVSS version. Auditors read the consistency: scores are produced by a documented method, the method matches the policy, and the SLA decision can be reconstructed from the recorded evidence. A programme that records CVSS 3.1 across the historical record and adds CVSS 4.0 alongside it satisfies both consistency and forward-compatibility. A programme that switches to CVSS 4.0 mid-cycle without recording the transition produces an audit trail that cannot be reconciled across versions, which is the failure mode worth avoiding.
Sources and Further Reading
- FIRST, CVSS v4.0 Specification Document, November 2023. first.org/cvss/v4-0/specification-document
- FIRST, CVSS v4.0 User Guide. first.org/cvss/v4-0/user-guide
- FIRST, CVSS v4.0 Examples. first.org/cvss/v4-0/examples
- FIRST, CVSS v3.1 Specification Document. first.org/cvss/v3-1/specification-document
- NIST National Vulnerability Database, CVSS scoring policy. nvd.nist.gov/vuln-metrics/cvss
- CISA, Authorised Data Publisher (ADP) programme. cisa.gov/cve-program
- FIRST, EPSS model and data feed. first.org/epss
- CISA, Known Exploited Vulnerabilities Catalog. cisa.gov/known-exploited-vulnerabilities-catalog
- CMU SEI, Stakeholder-Specific Vulnerability Categorization (SSVC). cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
- ISO/IEC 27001 Annex A 8.8, Management of technical vulnerabilities.
- PCI DSS v4.0 Requirement 6.3, Identify security vulnerabilities. pcisecuritystandards.org
- NIST SP 800-53 Rev 5 RA-5 Vulnerability Monitoring and Scanning, SI-2 Flaw Remediation.
- SOC 2 Trust Services Criteria CC7.1.
- SecPortal CVSS calculator. /tools/cvss-calculator
- SecPortal CVSS 3.1 vector string fields explainer. /blog/cvss-scoring-explained
- SecPortal vulnerability prioritisation framework. /blog/vulnerability-prioritisation-framework