Organisations should prioritise CVSS v4.0 for newly published vulnerabilities while continuing to rely on CVSS v3.1 for older CVEs that are not being re-scored. The article makes clear that historical databases are not expected to be retroactively updated, so most mature programs will need both versions side by side during the transition. That supports consistent triage without rewriting prior decisions.
Why CVSS v4.0 becomes the default for new findings
CVSS v4.0 is the newer scoring model, so it should be the reference point for freshly disclosed issues where you want the most current severity expression and the most complete view of the vulnerability. For a vulnerability management program, that usually means new CVEs, new disclosures, and new triage queues should be scored and compared using v4.0 first, while older records remain on their original basis unless they are explicitly re-scored.
That matters because a score is not just a label, it drives prioritisation, SLA handling, and escalation. If you mix old and new issues without a clear version rule, the queue becomes inconsistent: two vulnerabilities can look comparable while actually being scored with different assumptions and different weighting models.
When the question is operational, the practical test is whether the item is newly published or already embedded in an existing backlog. New publications belong on the newer scale; legacy records belong on the scale they were originally assessed against unless there is a deliberate remediation of the score itself.
Why mature programs keep CVSS v3.1 in parallel
Most organisations cannot simply flip a switch and abandon CVSS v3.1 because older CVEs, historical dashboards, exception registers, and audit records were built around it. If those records are not re-scored, the older baseline remains the only stable way to preserve continuity in trending, prioritisation history, and evidence of prior decisions.
That dual-track approach avoids a common failure mode: forcing retroactive conversion of every old finding can create artificial churn and break comparisons with previous reporting cycles. In practice, the transition period is less about choosing a winner and more about maintaining a coherent scoring policy for two populations of vulnerabilities, old and new.
The useful distinction is governance, not preference. CVSS v4.0 should improve how you score what is emerging now, while CVSS v3.1 preserves the integrity of what has already been recorded and acted on.
How to decide which version to use in triage workflows
The most reliable rule is to anchor the scoring version to the vulnerability record, not to the reporting dashboard. If the issue is newly disclosed and there is an available v4.0 score, use it for current prioritisation. If the issue predates the transition or no re-score exists, keep the v3.1 value as the operational reference.
This is especially important when teams compare scanner output, threat intel updates, and remediation queues. A single program may need to display both versions side by side so analysts can see the old score for continuity and the new score for current treatment without collapsing them into one misleading number. That approach also makes exception handling easier, because the team can explain why an older record was not re-evaluated while still using the latest method for new findings.
For reference material, the underlying scoring specification is maintained by FIRST CVSS, and vulnerability records are commonly published through the NIST National Vulnerability Database, which is useful when you need to confirm whether a CVE has a current score and which version is being used.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | CVSS version changes affect vulnerability reporting and tracking consistency. |
| Recommendation — Keep vulnerability records and scoring changes auditable across toolchains. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The question is about how to prioritise vulnerability scoring in ongoing triage. |
| Recommendation — Use a defined scoring policy to prioritise new findings consistently. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | CVSS is used to document and prioritise identified vulnerabilities. |
| Recommendation — Document vulnerabilities with a version-aware scoring process. | ||
Practitioner Guidance
What to prioritise: Define a clear policy that new disclosures are scored with CVSS v4.0, while legacy records keep v3.1 unless you intentionally re-score them. That avoids ad hoc analyst judgment and prevents version drift inside the same workflow.
What to verify: Check whether your scanners, ticketing system, and risk reports can display both versions without overwriting historical values. If they cannot, you will lose comparability and create avoidable disagreement over whether a vulnerability’s priority has changed or only its scoring method has.
Practitioner takeaway: Treat CVSS versioning as a recordkeeping and triage consistency problem, not a search for a single universal score. The right answer is usually version-aware coexistence, not forced conversion.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- When should organisations prioritise app risk scoring over device-only monitoring?
- Why should organisations prioritise exploited vulnerabilities over higher-scoring but unexploited ones?
- When should organisations prioritise reachability over raw vulnerability counts?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
