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. And the clock is no longer abstract: CRA reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026, with the full set of main obligations following in December 2027. Whatever prioritization model an organization is running today needs to be defensible under that reporting requirement in a matter of weeks, not quarters.
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 is an EU regulation that sets mandatory cybersecurity obligations for products with digital elements sold in the EU. It requires vendors to manage vulnerabilities throughout the product lifecycle and to avoid releasing software with known exploited vulnerabilities. According to the official EU documentation, manufacturers must:
- Identify and handle vulnerabilities throughout the product lifecycle
- Prevent shipping software with known exploited vulnerabilities
- Report actively exploited vulnerabilities and severe incidents within 24 hours of awareness, a reporting obligation that becomes enforceable on September 11, 2026
- 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, and starting September 2026, that risk comes with a reporting clock attached.
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 Risk Based Vulnerability Management Checklist
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.
We covered the incident-reporting side of this in more depth in a joint session with Nariman Aga-Tagiyev, Cybersecurity Architect at SecureHabits.nl: 24 Hours to Report: Surviving the CRA’s Notification Clock. It walks through the three-stage incident lifecycle CRA expects organizations to track, from a reported concern, to an investigation, to a confirmed incident that starts the 24-hour reporting window.
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, and starting September 11, 2026, it stops being optional. Teams that can already answer “is this exploited, and are we shipping it anyway?” will meet the CRA’s reporting clock without scrambling. Teams that can’t are finding out how short 24 hours actually is.
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.
