Introduction: Risk Based Vulnerability Management Under the Cyber Resilience Act
Modern teams already know that fixing every vulnerability is impossible. What really matters is fixing the right ones. That is why risk based vulnerability management has become the preferred approach for DevSecOps teams. However, in the European Union, this is no longer just a best practice. The Cyber Resilience Act introduces concrete legal obligations, especially when software includes issues listed in the CISA Known Exploited Vulnerabilities Catalog.
In this new context, vulnerability prioritization moves from a security choice to a compliance requirement. Teams must prove they understand which vulnerabilities are actively exploited and how they decide what to fix first.
Risk Based Vulnerability Management and Known Exploited Vulnerabilities
Risk based vulnerability management focuses on real exposure instead of raw severity. Rather than treating all CVEs equally, teams prioritize based on exploitation, reachability, and impact.
This is where known exploited vulnerabilities play a central role. When a CVE appears in the CISA Known Exploited Vulnerabilities Catalog, it confirms that attackers already use it in real environments. That signal carries much more weight than a theoretical score.
If you want a deeper explanation of what KEVs are and how to identify them, you can read our earlier post Known Exploited Vulnerabilities: What to Fix First. In this article, we focus on how KEVs fit into compliance and prioritization models under the Cyber Resilience Act.
What the Cyber Resilience Act Really Requires
The Cyber Resilience Act sets mandatory cybersecurity obligations for products with digital elements sold in the EU. According to the official EU documentation:
- https://www.european-cyber-resilience-act.com/
- https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Manufacturers must:
- Identify and handle vulnerabilities throughout the product lifecycle
- Prevent shipping software with known exploited vulnerabilities
- Apply timely remediation once exploitation is known
- Maintain evidence of vulnerability handling decisions
In other words, once a vulnerability appears in the CISA Known Exploited Vulnerabilities Catalog, ignoring it creates both security and regulatory risk.
What Is the Cyber Resilience Act (CRA)
The Cyber Resilience Act is an EU regulation that defines mandatory cybersecurity requirements for software and digital products sold in Europe. It requires vendors to manage vulnerabilities throughout the product lifecycle and to avoid releasing software with known exploited vulnerabilities.
CRA Ready Vulnerability Prioritization Checklist
| Requirement | What CRA Expects | Best Practice for Teams |
|---|---|---|
| Exploit awareness | Prevent shipping software with known exploited vulnerabilities | Automatically match findings against the CISA Known Exploited Vulnerabilities Catalog |
| Risk based prioritization | Focus on vulnerabilities that create real security risk | Combine KEVs, EPSS, reachability, and asset exposure |
| Timely remediation | Apply fixes without unreasonable delay once exploitation is known | Define fix now SLAs for reachable KEVs and enforce them in CI/CD |
| Continuous monitoring | Handle vulnerabilities throughout the product lifecycle | Run continuous scans on code, dependencies, and pipelines |
| Release controls | Avoid releasing products with active exploited flaws | Block merges or deployments when KEVs affect reachable code |
| Decision traceability | Prove how vulnerability decisions were made | Keep audit logs for detection, prioritization, and remediation actions |
| Developer integration | Security measures must not break development workflows | Surface prioritization directly in pull requests and CI pipelines |
| Lifecycle responsibility | Maintain security after release | Track KEVs and EPSS changes for shipped versions |
Why KEVs Are Central to CRA Compliance
The CISA Known Exploited Vulnerabilities Catalog lists CVEs that attackers already exploit in the wild. In other words, it removes ambiguity from prioritization.
Instead of asking “Could this be exploited?”, teams must now ask a much more direct question:
“Is this already being exploited, and are we shipping it anyway?”
Under the Cyber Resilience Act, that distinction matters legally. As a result, KEVs become the strongest trigger for remediation SLAs and release blocking. In this context, risk based vulnerability management aligns naturally with regulatory expectations.
CVSS, EPSS, and KEVs Serve Different Purposes
To prioritize correctly, teams must first understand what each signal actually represents.
- CVSS shows potential impact
- EPSS estimates likelihood of exploitation
- CISA Known Exploited Vulnerabilities Catalog confirms exploitation already happens
Taken alone, each metric can mislead. However, when teams use them together, they gain much clearer context. For this reason, combining these signals forms the foundation of effective risk based vulnerability management.
Risk Based Vulnerability Management in Practice
In practice, a risk driven prioritization model follows a clear and repeatable flow.
- Detect vulnerabilities across code and dependencies
- Check matches against the CISA Known Exploited Vulnerabilities Catalog
- Evaluate exploit likelihood using EPSS
- Verify reachability in your application or pipeline
- Apply remediation rules based on exposure and product role
As a result, teams stop treating vulnerability lists as static backlogs and start treating them as concrete security decisions.
Different Prioritization Models Teams Use Today
Not all teams prioritize risk in the same way. In general, we see three common models in real environments.
1. Severity First Model
Teams fix issues based only on CVSS.
This model is easy to adopt. However, it creates noise and does not meet Cyber Resilience Act expectations.
2. Likelihood Driven Model
Teams rely on EPSS to predict what attackers might exploit next.
This approach improves focus. Even so, it still misses vulnerabilities that attackers already exploit.
3. Exploitation Aware Model
Teams combine EPSS with the CISA Known Exploited Vulnerabilities Catalog and technical context.
In contrast, this model best supports risk based vulnerability management and maps directly to CRA obligations.
How Xygeni Operationalizes CRA Ready Prioritization
Xygeni helps teams turn regulation into daily workflow.
Rather than relying only on dashboards, Xygeni enforces decisions exactly where code changes happen. As a result, prioritization becomes automatic and consistent.
Key capabilities include:
- Automatic correlation with the CISA Known Exploited Vulnerabilities Catalog
- EPSS based exploit likelihood scoring
- Reachability analysis to confirm real exposure
- Guardrails that block merges or releases when KEVs affect reachable code
- Automated remediation through secure pull requests
- Full audit logs to demonstrate Cyber Resilience Act compliance
In short, teams do not just see risk. They act on it in a repeatable and auditable way.
Dev to Dev Example: KEV Blocking a Release
Imagine a dependency update introduces a CVE.
- The vulnerability appears in the CISA Known Exploited Vulnerabilities Catalog
- Xygeni detects it during the pull request
- Reachability analysis confirms the code path executes
- Guardrails block the merge automatically
- The bot proposes a safe upgrade and runs tests
The developer resolves the issue in the same workflow. The release stays compliant. No meetings are needed.
In other words, this is risk based vulnerability management applied exactly where developers already work.
Why This Matters Beyond Compliance
Although the Cyber Resilience Act triggered this shift, the benefits go further.
Teams that prioritize using KEVs, EPSS, and context:
- Reduce alert fatigue
- Shorten remediation time
- Avoid emergency patches
- Ship safer software with confidence
On the whole, compliance becomes a natural outcome of doing security the right way.
Final Thoughts: CRA Makes Risk Based Management Mandatory
The Cyber Resilience Act formalizes what security teams already learned the hard way. Not all vulnerabilities matter equally.
The CISA Known Exploited Vulnerabilities Catalog defines what attackers use today. EPSS predicts what they will use next. Context shows whether it affects you.
Together, they form modern risk based vulnerability management.
Xygeni helps teams apply this model continuously, automatically, and in a way developers actually accept.
About the Author
Written by Fátima Said, Content Marketing Manager specialized in Application Security at Xygeni Security.
Fátima creates developer-friendly, research-based content on AppSec, ASPM, and DevSecOps. She translates complex technical concepts into clear, actionable insights that connect cybersecurity innovation with business impact.
