Critical Vulnerability

A critical vulnerability is a security flaw with a CVSS base score of 9.0 to 10.0 on the standard 0–10 severity scale. This score reflects the highest potential impact: vulnerabilities in this range typically allow an unauthenticated attacker to remotely execute arbitrary code, gain full administrative control, or cause complete denial of service with no user interaction required. Classic examples include buffer overflow vulnerabilities in network-facing services, authentication bypass flaws in administrative interfaces, and SQL injection vulnerabilities with full database access. Critical vulnerabilities in widely deployed products are priority targets for threat actors and are frequently weaponised within days of public disclosure, making rapid manufacturer response essential.

The CVSS (Common Vulnerability Scoring System) framework, published by FIRST, defines five severity bands: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0). Achieving a Critical base score requires a combination of high impact ratings (confidentiality, integrity, and/or availability) with low attack complexity, no required privileges, and no user interaction — or equivalently, network accessibility combined with high impact and no mitigating factors. CVSS v4.0 introduced additional granularity including threat metrics and supplemental scores, but the base score critical threshold remains at 9.0. Manufacturers should note that a high CVSS base score does not always mean high contextual risk — environmental scoring can adjust the effective severity when compensating controls are in place.

The CRA does not define 'critical' as a specific regulatory category but requires that vulnerabilities be addressed 'without undue delay' — language that industry interprets as requiring the fastest response for the highest-severity issues. For critical vulnerabilities, CRA-compliant manufacturers should:

• Triage within 24–48 hours: Validate the vulnerability, confirm scope, and establish an EPSS-informed exploitation probability assessment.
• Issue interim advisory within 5 days: Even before a patch is available, publish guidance on mitigations and workarounds.
• Target patch release within 30 days: Compress the development and testing cycle, with emergency release approval processes bypassing normal sprint cadences.
• Notify ENISA immediately if actively exploited: If evidence of exploitation exists, the 24-hour notification obligation applies regardless of patch status.

A significant proportion of critical vulnerabilities affecting products originate in third-party dependencies — open source libraries, commercial SDKs, or firmware components. Log4Shell (CVE-2021-44228, CVSS 10.0) is the canonical example: a single critical vulnerability in a widely used logging library that affected thousands of products across hundreds of manufacturers. For manufacturers subject to the CRA, this means maintaining a current SBOM is not optional — it is the prerequisite for rapid identification of affected products when critical upstream vulnerabilities are disclosed. Manufacturers should have a defined process for SBOM-based CVE correlation that can be executed within hours of a critical CVE being published, not days.