ENISA Onboards Its First CNAs: What It Means for CRA Article 14

The 24-hour clock under CRA Article 14 starts the moment you have reasonable belief of active exploitation. That clock presupposes a working vulnerability identification chain. ENISA just made that chain more direct.

On 6 May 2026, ENISA announced that four new organisations joined the CVE Programme as CVE Numbering Authorities (CNAs) under ENISA Root. Seven existing European CNAs also moved from MITRE Root to ENISA Root. For any manufacturer preparing for CRA Article 14 compliance, this is the operational backbone becoming operational.

This announcement matters more than it looks. The CRA does not exist in a vacuum. It defines legal obligations, but those obligations depend on infrastructure that has to exist and function before 11 September 2026. ENISA building out its CVE Root is part of that infrastructure, and the fact that it is happening now, with the CRA deadline this close, is both reassuring and a reminder that the EU is still assembling the machinery while the clock runs.

Why CVE IDs Matter to Your Article 14 Report

When CRA Article 14 requires you to report an actively exploited vulnerability, the report needs to identify the vulnerability precisely. CVE IDs are the global standard for that identification. They are what ENISA's European Vulnerability Database (EUVD) uses. They are what the ENISA Single Reporting Platform will expect.

Getting a CVE ID assigned requires a CNA. If no EU CNA covered your software category, you went to MITRE. MITRE is US-based. The coordination worked, but it added latency. Under a 24-hour clock, latency is a compliance risk.

ENISA as CVE Root changes the routing. European CNAs now coordinate CVE assignment directly with ENISA. For most manufacturers, this is invisible day-to-day. You don't need to be a CNA. But the security researcher who finds a bug in your product, or the CSIRT that handles your disclosure, now operates under a root authority that is geographically aligned with the agency you report to under Article 14.

That is the infrastructure your 24-hour window depends on.

The Reporting Chain Under CRA Article 14

CRA Article 14(1) requires manufacturers to report to the coordinator CSIRT and to ENISA simultaneously, via the ENISA Single Reporting Platform. You file once. Both receive it.

But the SRP needs a CVE ID to anchor the report. ENISA's role as CVE Root means the identification step and the reporting step now sit under the same agency. The body that names the vulnerability is the same body you report to. That closes a coordination gap that existed when the two functions ran through separate organisations on different continents.

See the Article 14 reporting guide for the full 24h, 72h, and 14-day cadence and what the SRP submission covers.

The AI Acceleration Problem

Hans de Vries, ENISA's Chief Cybersecurity and Operations Officer, was direct about why this matters now:

AI tools compress the time between a bug being found and a bug being exploited. The window between "a researcher discovers it" and "your 24-hour Article 14 clock starts" is getting shorter. Two things follow. First, your internal triage process needs to match a faster threat timeline. Second, the CVE assignment step in the chain needs the same speed. ENISA is building that capacity now, and Cybersecurity Act 2 proposes additional ENISA operational resources specifically for this function.

What You Don't Need to Do

You don't need to become a CNA. CVE Numbering Authority status is for organisations that discover and publish vulnerability records. Most manufacturers are not CNAs and the CRA does not require it.

What CRA Annex I, Part II does require is a coordinated vulnerability disclosure (CVD) policy. That policy describes how your organisation receives, handles, and discloses vulnerabilities. Under that policy, you work with CNAs or CSIRTs who handle CVE assignment. ENISA as CVE Root means those partners now operate under a more direct EU authority structure.

Review your CVD policy against three questions before 11 September 2026:

1. Does it name the reporting path? The policy must reference the ENISA SRP as the submission channel for Article 14 reports.
2. Does it specify how you handle inbound reports? When a researcher reports a vulnerability to you, the policy must describe your response timeline and the CVE request process.
3. Does it identify your coordinator CSIRT? Article 14(7) requires manufacturers to designate a coordinator CSIRT. That designation belongs in the policy.

See the CVD policy template for a structured starting point.

Our Take

The "reinforce, not fragment" framing is the right position. The risk with any EU-specific infrastructure is fragmentation. A European CVE silo that diverges from MITRE would hurt everyone, including European manufacturers working with global supply chains. The announcement is explicit that ENISA is working with CISA and MITRE under a shared commitment to the global programme.

The bigger message for manufacturers is timing. The infrastructure is being assembled at the same time you are supposed to comply with it. The SRP is not yet live. The CVE Root has 11 CNAs out of 90+ eligible. These will be ready by September 2026, but you need to be ready too, and building your process around infrastructure that is still coming online is harder than building it on stable ground.