CVD Portal
← CRA Glossary
Security Standards & Frameworks

Common Vulnerability Scoring System (CVSS)

CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities, producing a numerical score from 0 to 10. Manufacturers use CVSS scores to prioritise remediation and to communicate risk in security advisories required under the CRA.

CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities, producing a numerical score from 0 to 10. Manufacturers use CVSS scores to prioritise remediation and to communicate risk in security advisories required under the CRA.

Security Standards & Frameworks
Free CVD portal →

What Is CVSS?

The Common Vulnerability Scoring System (CVSS) is a vendor-neutral, open standard maintained by the Forum of Incident Response and Security Teams (FIRST). It provides a structured method for assessing the severity of software vulnerabilities on a 0–10 scale: None (0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0). CVSS v3.1 and v4.0 are the current versions in active use. A CVSS score consists of a Base Score (intrinsic characteristics), a Temporal Score (exploit maturity and remediation), and an Environmental Score (deployment context). The Base Score is most widely cited; the Temporal and Environmental scores allow downstream organisations to adjust for their specific circumstances.

CRA reference:Article 13(6)

CVSS Under the CRA

The CRA does not mandate CVSS by name, but Annex I Part II and Article 14 require manufacturers to handle vulnerabilities without undue delay and to prioritise remediation based on risk. CVSS is the universally accepted mechanism for expressing that risk quantitatively. When manufacturers publish security advisories - required when releasing patches - regulators and downstream customers expect CVSS scores to be present. The CSAF standard (ISO/IEC 29147 and OASIS CSAF 2.0), which ENISA recommends for CRA-compliant advisories, includes CVSS as a mandatory field for each vulnerability record. Without CVSS scoring, a manufacturer cannot demonstrate risk-based prioritisation to auditors or market surveillance authorities.

CRA reference:Article 13(6), Article 14, Annex I Part II

How to Score Vulnerabilities Correctly

Accurate CVSS scoring requires understanding the attack vector, complexity, and impact:

  • Attack Vector (AV) - Network, Adjacent, Local, or Physical. A remotely exploitable flaw scores higher.
  • Attack Complexity (AC) - Low or High. Exploits that require no special conditions score higher.
  • Privileges Required (PR) and User Interaction (UI) - unauthenticated, zero-click vulnerabilities score highest.
  • Impact (C/I/A) - Confidentiality, Integrity, Availability impact on the vulnerable system.

Common scoring errors: overestimating Scope (Changed vs. Unchanged), assigning Low AC when special configuration is actually required, and ignoring the Temporal metrics when a public PoC is available.

CRA reference:Article 13(6)

CVSS Pitfalls for Manufacturers

Manufacturers new to CVSS frequently encounter these problems:

  • Scoring from the researcher's PoC rather than the deployed product - the correct base score reflects the worst-case deployed scenario, not a lab environment.
  • Using CVSS 2.0 - CVSS v2 is retired; CVSS v3.1 or v4.0 is required for credible advisories.
  • Publishing only the score without the vector string - regulators and downstream users cannot verify or adjust a bare numeric score.
  • Treating CVSS as a prioritisation absolute - a CVSS 9.8 in a product deployed in an air-gapped factory may be lower operational priority than a CVSS 7.0 in an internet-facing device. Environmental scores address this.

CVD Portal makes Common Vulnerability Scoring System (CVSS) compliance straightforward.

Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Receiving and tracking reports is free for all manufacturers placing products with digital elements on the EU market. Article 14 filing with the SRP-ready package is on Pro.

Start your free portal

Frequently asked

Which version of CVSS should we use - v3.1 or v4.0?+

As of 2025, both CVSS v3.1 and CVSS v4.0 are accepted by FIRST and in active use. CVSS v4.0 introduced significant improvements including finer-grained attack complexity, safety metrics, and OT/ICS considerations. For new advisories, CVSS v4.0 is recommended. Existing advisories scored in v3.1 do not need to be rescored unless republished. Always include the version designation in the vector string (e.g. CVSS:4.0/AV:N/…).

Does a CVSS score determine our CRA notification deadline?+

Indirectly. The CRA's 24-hour ENISA notification requirement (Article 14) is triggered when a vulnerability is 'actively exploited' - not by a CVSS threshold. However, CVSS scores inform internal triage: organisations typically set escalation policies where Critical (9.0+) and High (7.0+) vulnerabilities receive expedited response. Market surveillance authorities will expect to see evidence that severity scoring informed the response timeline.

Can we assign CVSS scores ourselves, or do we need a third party?+

Manufacturers can and should score their own vulnerabilities - waiting for a third party adds unnecessary delay. However, scores should be reviewed by someone with security engineering expertise. FIRST provides detailed scoring guidance and a calculator. For high-profile vulnerabilities, consider having an independent security firm validate the score, as under-scoring critical vulnerabilities creates compliance and reputational risk.

Related terms

Common Vulnerabilities and Exposures (CVE)CVE is a public catalogue of known cybersecurity vulnerabilities, each assigned a unique identifier (e.g. CVE-2024-12345) maintained by MITRE. Under the CRA, manufacturers are expected to track CVEs affecting their products and report actively exploited vulnerabilities to ENISA.Security AdvisoryA security advisory is a public document published by a manufacturer to inform users of a security vulnerability in a product, the severity of the issue, and how to remediate it. Annex I Part II of the CRA requires manufacturers to publish security advisories when releasing vulnerability fixes.Common Security Advisory Framework (CSAF)CSAF is an OASIS open standard for machine-readable security advisory documents, replacing the older CVRF format. ENISA recommends CSAF as the preferred format for security advisories published by manufacturers under the EU Cyber Resilience Act.Vulnerability HandlingVulnerability handling is the complete lifecycle process through which a manufacturer identifies, evaluates, remediates, and discloses security vulnerabilities in its products. Annex I Part II of the CRA makes robust vulnerability handling a mandatory ongoing obligation for all manufacturers of products with digital elements.Actively Exploited VulnerabilityAn actively exploited vulnerability is a security flaw for which evidence exists that threat actors are currently using exploit code in real-world attacks. Under the CRA, manufacturers must notify ENISA within 24 hours of becoming aware that a vulnerability in their product is being actively exploited.Critical VulnerabilityA critical vulnerability is a security flaw assigned a CVSS base score of 9.0 or higher, indicating the highest potential for harm - typically enabling remote code execution or full system compromise without authentication. Critical vulnerabilities require accelerated remediation and immediate advisory publication under CRA-compliant vulnerability handling processes.

CRA articles using this term

Article 13Obligations of ManufacturersArticle 14Active Exploitation and Incident Reporting - 24h, 72h, and 14-Day ObligationsAnnex IEssential Cybersecurity Requirements for Products with Digital Elements

Sector checklists covering Common Vulnerability Scoring System (CVSS)

Industrial Controllers & PLCsIndustrial controllers, PLCs, and SCADA components are classified as Important Class II under Annex III of the CRA, requiring third-party conformity assessment. These products have long operational lifetimes (10–20+ years), network connectivity, and significant safety implications. CRA compliance must be planned well in advance of the September 2026 deadline.IoT Sensors & Connected DevicesIoT sensors - temperature, humidity, pressure, flow, and motion sensors - are the backbone of industrial and building automation. Most fall into the Default CRA class, but their constrained hardware often makes meeting Annex I security requirements challenging. Manufacturers must plan for secure update mechanisms even on resource-constrained devices.

Browse the full CRA Compliance Checklist

See how Common Vulnerability Scoring System (CVSS) fits into your complete CRA compliance programme.

View checklists →