Arielle Waldman , Features Writer , Dark Reading January 23, 2026 7 Min Read Source: Cagkan Sayin via Alamy Stock Photo In response to continued uncertainty around the future of the MITRE-run Common Vulnerabilities and Exposures (CVE) program , a European cybersecurity organization has launched the Global CVE Allocation System (GCVE) for identifying software security vulnerabilities. Experts anticipate significant fragmentation in how organizations track and manage security flaws. The existing CVE program experienced its fair share of ups and downs in 2025. Government funding nearly ceased last April, which would have forced a total shutdown of the program. A last-minute contract extension between the Cybersecurity and Infrastructure Security Agency and MITRE saved the CVE program, but that contract expires this March. With CVE's funding future still murky, various organizations have tried setting up competing models . The European Union's GCVE is a vulnerability identification and numbering system that is "designed to improve flexibility, scalability, and autonomy for participating entities," according to its website. Operated by the Computer Incident Response Center Luxembourg (CIRCL), the initiative has been in the works since last April. The GCVE system fits within the European Union's cybersecurity infrastructure, which includes the European Union Vulnerability Database , based on CIRCL's vulnerability-lookup software. GCVE is designed to remain compatible with the traditional CVE system, with one key difference: It is a decentralized database . Decentralization introduces both benefits and risks to the CVE ecosystem. How Does the GCVE Differ From the CVE? The EU's program includes GCVE Numbering Authorities (GNA) — independent entities that can assign identifiers "at their own pace" without relying on a central authority. The publicly available identifiers help security teams track, share, and fix vulnerabilities. GNAs can define their own internal policies for vulnerability identification, which could make processes more efficient, considering the overwhelming number of reported vulnerabilities. The GCVE program emerged in response to broader concerns about resilience, sustainability, and potential single points of failure in the existing CVE program, explains Haiman Wong, fellow, cybersecurity and emerging threats at R Street Institute. "It was designed to involve multiple governments and stakeholders, provide an open API for integration with existing security tools, and map back to the existing CVE framework rather than replace it outright," she tells Dark Reading. The GCVE could be beneficial for companies if it meaningfully improves continuity and access to vulnerability intelligence, Wong says. Cybersecurity tends to benefit more from harmonized, coordinated sources of truth, so defenders can focus on remediation rather than reconciling inconsistencies across multiple databases, she explains. "Additional cross-validation in vulnerability reporting could, in theory, also provide a sense of resilience and corroboration if a single system falters or loses support, but that value diminishes quickly if multiple CVE initiatives begin to diverge in how vulnerabilities are identified, labeled, or prioritized," Wong says. GCVE may still be in its early stages, but it has the potential to improve the global vulnerability ecosystem, explains vulnerability historian Brian Martin. However, that free data comes at a cost, he warns, as it creates yet another source defenders need to check for vulnerabilities. That can be difficult for some organizations' current workflows, he says, noting that many have their processes designed around a single vulnerability feed and adding another can be problematic. What's the Catch? The MITRE-run CVE database seeks to standardize vulnerability tracking and scoring for organizations, but it also faces backlog, transparency, and relevance issues — especially as organizations struggle to understand which vulnerabilities affect them directly. Unfortunately, it doesn't appear that a new program will alleviate those pressures. The primary risk posed by GCVE is not its mere existence but the potential fragmentation of vulnerability coordination if different CVE initiatives operate as distinct or competing authorities, Wong says. She anticipates that it's unlikely the EU will encounter entirely unique classes of vulnerabilities that could introduce duplicative or inconsistent listings, only adding to the confusion for defenders. Duplicative CVEs could also increase operational burden and undermine confidence in vulnerability data, she adds. "While the EU's impulse to increase resilience is understandable, the ultimate efficacy of GCVE will hinge on whether it lives up to its stated intent — reinforcing global coordination and access — or inadvertently undermines them during its proving phase," Wong says. Confusion for organizations trying to interpret multiple sources of data will only mount if fragmented CVE authorities ascribe different severities, have different views of exploitability, map CVEs differently to software versions, or leverage different syntax and format for describing CVEs, explains Spektion CEO Joe Silva. Then there's the regulatory aspects since it is a EU-based system. "It will likely generate regulatory and other compliance requirements from the EU government and EU based companies to ensure that companies vulnerability management programs are leveraging GCVE data in their programs, which will have further downstream cost impacts," Silva says. There may also be usability issues with the GCVE website, which Martin described as "difficult to navigate and use efficiently." However, GCVE is accessible via an API, which is "something that MITRE/CVE didn't do for most of its tenure," he says. "Fortunately, there is active work on both [the website and API] for now, so we will likely see [usability] improve steadily." 'Fragmentation Unhelpful at Best' Defenders already operate in noisy environments. Fragmentation created by dueling CVE programs, adding to that noise, is a common concern. While CIRCL created the GCVE to be "backward compatible" with the existing CVE ecosystem, there is a worrying omission in its operation, says Stephen Fewer, a senior principal researcher at Rapid7. His main concern, he says, is that new GCVE identifiers unique to the GCVE system will not be made available to the CVE ecosystem. "This fragmentation across two disparate vulnerability ecosystems will lead to potential duplication and confusion amongst shared users," Fewer tells Dark Reading. A lack of centrally enforced policies is his second top-most concern with the emergence of GCVE. CIRCL framed decentralization as the big differentiator between its US counterpart, stating that organizations that allocate new GCVE identifiers do not need to "adhere strictly to centrally enforced policies." The policy directly contrasts with the more rigid, highly process-based CVE ecosystem defined by MITRE, which concerns Fewer. For example, multiple identifiers could be assigned by different organizations to the same vulnerabilities, or a single identifier could be assigned to multiple vulnerabilities. Identifiers not being published in a timely fashion and unresolved disputes between organizations on the validity of vulnerability reports are additional concerns, he adds. While the goal is coordinated vulnerability disclosure, transparency remains an issue. Some companies may be hesitant to disclose vulnerabilities to save face or avoid legal battles. Alternatively, companies may disagree on disclosure timelines, with some claiming early disclosures help the bad guys. Others want to give companies sufficient time to patch. "The existing CVE ecosystem is not perfect, but fragmentation in this space is unhelpful at best," Fewer says. "Entities that want a robust and accurate global vulnerability ecosystem should consider supporting the existing CVE ecosystem's pain points, such as vulnerability enrichment or other operational improvements. In my opinion, that would be of much greater benefit to the entire community." Whether organizations can effectively apply the "go to the source" methodology to vulnerability intelligence is a greater concern than fragmentation, says Martin. Going to the source means defenders have to monitor thousands of sources -- some that require monitoring hourly, daily, or monthly. "The real problem organizations face is that they are still using intelligence from vulnerability disclosure points that are 'opt-in, '" Martin says. Editor's Note: This story has been updated with this statement from CISA on Jan. 28: "Under CISA’s leadership and sponsorship, the CVE Program has continually evolved and modernized to support the global vulnerability ecosystem. The CVE Program first underwent a ’Growth Era,' scaling to 490 CVE Numbering Authorities (CNAs) and publishing an astonishing 48k+ CVE records in 2025. With the release of CISA's strategic focus, the CVE Program embarked on its ‘Quality Era' to cement its role as the cornerstone of global cybersecurity defense under CISA’s leadership. As part of this, CISA, in collaboration with the global cybersecurity community, is committed to enhancing data quality, modernizing infrastructure and services, improving governance processes with more diverse representation, among other lines of effort. CISA continues to collaborate with international governments, including ENISA who is now designated as a Root CVE Numbering Authority (CNA) for EU, to ensure there remains an authoritative source for cybersecurity vulnerabilities." About the Author Arielle Waldman Features Writer, Dark Reading Arielle spent the last decade working as a reporter, transitioning from human interest stories to covering all things cybersecurity related in 2020. Now, as a features writer for Dark Reading, she delves into the security problems enterprises face daily, hopi