A severity score is useful only when it reflects the actual CRA-covered product. The same underlying weakness can create different consequences depending on whether the vulnerable function is remotely exposed, requires authentication, affects a privileged component, exists only in an optional configuration or is already being exploited.
The CRA Does Not Mandate One Universal Severity Model
The Cyber Resilience Act does not prescribe CVSS or another single universal vulnerability severity scoring system for manufacturer vulnerability handling. Annex I Part II point 2 instead requires manufacturers to address and remediate vulnerabilities in relation to the risks posed to products with digital elements and without delay. A manufacturer can use CVSS or another structured method as an input, but the final assessment should reflect the actual product context and risk.
- Use a repeatable severity method.
- Do not treat one external score as the complete product assessment.
- Document product-specific factors.
- Record the rationale for the rating.
Start With Security Impact
Severity assessment should identify what an attacker could achieve if the vulnerability were successfully exploited. Relevant impact can include loss of confidentiality, unauthorised modification, loss of availability, authentication bypass, privilege escalation, compromise of update integrity or control of security-sensitive functions. The assessment should describe actual product consequences rather than relying only on a generic vulnerability category.
- Confidentiality impact.
- Integrity impact.
- Availability impact.
- Privilege impact.
- Security-control bypass.
Assess Exploitability Separately
A severe technical consequence does not automatically mean exploitation is easy. Exploitability analysis should consider whether an attacker needs network access, local access, valid credentials, physical possession, user interaction or a specific configuration. The CRA separately defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions. Recording exploitability separately prevents severity discussions from hiding important attack prerequisites.
- Remote or local access.
- Authentication requirements.
- Required privileges.
- User interaction.
- Configuration prerequisites.
Consider Product Exposure
Exposure describes whether the vulnerable function is realistically reachable in the product's normal or foreseeable deployment. An internet-facing management interface can create a different risk from the same vulnerable code compiled into a disabled maintenance feature. Teams should consider enabled services, network location, default configuration, deployment patterns and whether the affected function is normally accessible to untrusted actors.
- Default exposure.
- Internet or network reachability.
- Enabled services.
- Deployment environment.
- Trust-boundary location.
Identify Every Affected Version
Severity should be tied to affected versions rather than treated as one timeless label for the product family. A vulnerability may be remotely exploitable in one branch, locally reachable in another and absent from a third. Version-specific analysis also determines which supported releases need remediation and which users need security advisories. The case record should therefore identify affected versions and any meaningful differences in exposure or impact.
- Identify affected releases.
- Identify supported branches.
- Record version-specific differences.
- Identify confirmed unaffected versions where useful.
Account for Compensating Controls
Existing product controls can reduce practical risk without eliminating the underlying vulnerability. Network restrictions, sandboxing, privilege separation, authentication requirements or disabled-by-default functionality can change exploitability or impact. Compensating controls should be verified rather than assumed. They can inform severity and remediation priority, but they should not be used to claim that a confirmed vulnerability no longer exists when the vulnerable condition remains present.
- Identify existing controls.
- Verify that the controls actually apply.
- Assess possible bypasses.
- Document residual risk.
CVSS Can Be an Input Without Becoming the Legal Test
CVSS can provide a useful common vocabulary for technical vulnerability characteristics, especially when manufacturers exchange information with suppliers or security researchers. The CRA does not make a specific CVSS score the legal test for whether a vulnerability must be remediated. Product teams should therefore avoid rules such as treating every score below one threshold as automatically safe to defer. Product exposure, affected functions, exploitability and support obligations can change the actual risk.
- Use CVSS consistently if adopted.
- Preserve the vector or rationale.
- Add product-specific context.
- Do not use the score as the only remediation decision.
Active Exploitation Is a Separate and Important Fact
Active exploitation should not be hidden inside an ordinary severity score. The CRA defines an actively exploited vulnerability separately and Article 14 creates specific reporting obligations when the manufacturer becomes aware of one. Reliable evidence that a malicious actor has exploited the vulnerability can change both regulatory obligations and operational priority even if the original severity assessment was lower.
- Track evidence of exploitation separately.
- Preserve awareness timing.
- Reassess operational priority.
- Trigger Article 14 assessment.
Article 14 Final Reporting Requires Severity and Impact
For an actively exploited vulnerability reported under Article 14, the final report must include a description of the vulnerability including its severity and impact. ENISA's current CRA SRP glossary asks manufacturers to provide the assessed severity rating or classification, the rationale for that assessment and other relevant supporting factors or criteria. That makes a documented severity methodology particularly useful even though the CRA does not mandate one universal scoring framework.
- Record the severity rating or classification.
- Record impact.
- Record the assessment rationale.
- Preserve supporting factors.
Severity Can Change as Investigation Develops
The first severity estimate may be based on incomplete information. A proof of concept can show that exploitation is easier than expected, affected-version analysis can expand the scope or a compensating control can reduce practical exposure. The vulnerability case should support reassessment as new evidence arrives. Significant changes should be recorded with the reason so later remediation and disclosure decisions remain understandable.
- Allow provisional ratings.
- Reassess after technical validation.
- Reassess when exploitation evidence changes.
- Record significant rating changes.
Keep Severity Separate From Remediation Priority
Severity is one input to remediation priority, not always the complete decision. A high-severity vulnerability in an unreachable optional component can compete with a lower-scored vulnerability that is remotely exposed and actively exploited. Manufacturers should therefore retain both the severity assessment and the remediation-priority decision. The next step is to combine severity with exploitability, exposure, active exploitation, support status and the availability of mitigations or fixes.
- Record severity.
- Record remediation priority separately.
- Explain material differences.
- Update priority when new evidence appears.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.