Article 28 defines the European Union Agency for Cybersecurity's (ENISA) operational roles under the CRA. Central to these is the establishment and operation of the European Vulnerability Database (EVDB), which serves as the EU's authoritative registry of vulnerabilities in CRA-regulated products. Article 28 also establishes ENISA's coordination functions in vulnerability disclosure, its advisory role to manufacturers and member states, and its responsibility for maintaining the infrastructure through which Article 14 notifications are processed.
The European Vulnerability Database
Article 28 tasks ENISA with establishing and maintaining the European Vulnerability Database (EVDB). The EVDB serves as the EU-level registry for vulnerabilities affecting CRA-regulated products, complementing the global CVE programme coordinated by MITRE/NVD.
The EVDB allows manufacturers to register vulnerabilities in their products with standardised identifiers (European Vulnerability Identifiers or EVIs), enabling structured tracking and reporting of vulnerability lifecycles. For manufacturers subject to Article 14 reporting obligations, the EVDB is the downstream repository where their notifications ultimately contribute to an EU-wide vulnerability intelligence picture.
The EVDB is also intended to serve as a resource for market surveillance authorities, security researchers, and downstream users who need to assess their exposure to known vulnerabilities. By centralising vulnerability information, the EVDB aims to improve the EU's collective ability to monitor the security state of digital products and respond to emerging threats.
ENISA's Coordination Function in Vulnerability Disclosure
Article 28 gives ENISA a coordination role in the EU's vulnerability disclosure ecosystem. Where a vulnerability in a CRA-regulated product affects multiple manufacturers, multiple product categories, or has systemic implications for critical infrastructure, ENISA may coordinate the disclosure process to ensure:
- All affected manufacturers are notified simultaneously
- Disclosure timelines are coordinated to avoid one manufacturer's advisory revealing the vulnerability before others are ready
- National CSIRTs in affected member states receive timely and accurate information
- The EVDB entry for the vulnerability is comprehensive and accurate
This coordination role is particularly important for vulnerabilities affecting widely-deployed standards, protocols, or common components — situations where a single CVE may affect hundreds of manufacturers and millions of products simultaneously.
Interface Between the EVDB and Global Vulnerability Databases
Article 28 recognises that the EVDB does not operate in isolation — it must interface with the global vulnerability management ecosystem, including the MITRE CVE programme, the NVD, and national vulnerability databases maintained by CERT organisations in member states.
ENISA is responsible for establishing data exchange arrangements with these international databases to avoid duplication and to ensure that vulnerability information registered in the EVDB is synchronised with global CVE records. For manufacturers, this means that vulnerabilities disclosed through the CRA Article 14 process will contribute to both EU-specific and global vulnerability intelligence.
Manufacturers should familiarise themselves with both the EVDB and the global CVE programme. The processes for registering CVEs (through CNA — CVE Numbering Authorities) are established, and ENISA is expected to become a CNA covering EU-specific vulnerabilities.
ENISA's Advisory and Guidance Functions
Beyond database operations, Article 28 establishes ENISA as a source of guidance and advice for manufacturers, national authorities, and other stakeholders on CRA implementation. ENISA's advisory functions include:
- Publishing implementation guidance on CRA obligations for manufacturers across different product categories
- Developing technical guidelines on CVD policy best practices, SBOM formats, and CSAF advisory standards
- Providing guidance to national CSIRTs on handling Article 14 notifications
- Advising the Commission on the development of implementing acts and common specifications
- Publishing annual reports on the state of CRA implementation and the vulnerability landscape for digital products
Manufacturers should actively monitor ENISA's publications as the CRA's application date approaches, as guidance documents will clarify many practical compliance questions that the regulation itself leaves open.
ENISA's Role in Article 14 Notification Processing
Article 28 connects with Article 14 to establish ENISA's central role in processing vulnerability and incident notifications from manufacturers. Under Article 14, manufacturers report severe vulnerabilities to their national CSIRT, which forwards notifications to ENISA. ENISA aggregates these notifications, maintains statistics, identifies trends, and coordinates cross-border responses.
The practical infrastructure for this — the single reporting platform referenced in Article 29 — is designed and operated under ENISA's coordination. Manufacturers who submit Article 14 notifications to their national CSIRT are indirectly contributing to the EU-wide vulnerability intelligence that ENISA maintains.
ENISA also plays a role in the early warning process: where a notification indicates a vulnerability that may affect critical infrastructure or a large number of users, ENISA can escalate the alert to national cybersecurity authorities across the EU.
CVD Portal helps you comply with Article 28 automatically.
Public submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever.
Start your free portalFrequently asked
Do manufacturers need to register vulnerabilities directly with ENISA?+
Under the Article 14 process, manufacturers report to their national CSIRT, which forwards to ENISA. Direct registration with ENISA is not the standard pathway. However, ENISA may establish self-service mechanisms for manufacturers to submit information directly to the EVDB — particularly for open-source components or cross-border situations where the national CSIRT routing is unclear. Watch for ENISA guidance on submission procedures.
Is the European Vulnerability Database publicly accessible?+
ENISA intends the EVDB to be publicly accessible for vulnerability information, similar to the NVD. Public access to vulnerability information enables users, researchers, and downstream manufacturers to assess their exposure. However, some sensitive information — such as unpatched vulnerabilities reported under Article 14 before a fix is available — may be restricted or time-delayed to avoid facilitating exploitation.
Will the EVDB replace CVE identifiers with European identifiers?+
The EVDB is designed to complement rather than replace the global CVE system. ENISA is expected to participate in the CVE programme as a CNA, enabling it to assign CVE identifiers for EU-origin vulnerability disclosures. European vulnerabilities will typically have both a CVE identifier and an EVDB reference. Manufacturers should register vulnerabilities in a way that produces CVE identifiers recognisable in global tooling.
How does ENISA's coordination role differ from a national CSIRT's role?+
National CSIRTs handle day-to-day vulnerability coordination within their national jurisdiction and serve as the first point of contact for Article 14 notifications from manufacturers in their country. ENISA operates at the EU level — coordinating across all national CSIRTs, maintaining EU-wide databases, and handling cross-border vulnerability scenarios. A national CSIRT escalates to ENISA when a vulnerability has EU-wide implications.
Related CRA Articles
Need a CVD policy that satisfies Article 28?
Download a free CRA-compliant template and deploy it in minutes.