ENISA tar in sina första CNAs: vad det innebär för CRA Artikel 14
ENISA tar in nya europeiska CNA:er som CVE Root. Läs hur det stärker rapporteringskedjan under CRA Artikel 14 och EU:s sårbarhetshantering.
I denna artikel
24-timmarsklockan under CRA Artikel 14 startar i det ögonblick du har rimlig anledning att tro att en sårbarhet aktivt utnyttjas. Den klockan förutsätter en fungerande kedja för sårbarhetsidentifiering. ENISA har nu gjort den kedjan mer direkt.
Den 6 maj 2026 meddelade ENISA att fyra nya organisationer gick med i CVE-programmet som CVE Numbering Authorities (CNA:er) under ENISA Root. Sju befintliga europeiska CNA:er flyttade också från MITRE Root till ENISA Root. För dig som tillverkare och förbereder dig för CRA Artikel 14 är detta den operativa ryggraden som nu börjar fungera på riktigt.
Det här tillkännagivandet är viktigare än det ser ut. Cyberresiliensförordningen (Cyber Resilience Act) existerar inte i ett vakuum. Den fastställer rättsliga skyldigheter, men de skyldigheterna kräver infrastruktur som måste finnas och fungera innan den 11 september 2026. ENISA:s uppbyggnad av sin CVE Root är en del av den infrastrukturen. Och det faktum att det sker nu, med CRA-deadlinen så nära, är både uppmuntrande och en påminnelse om att EU fortfarande monterar ihop maskineriet medan klockan tickar.
Sammanfattning
- ENISA är en CVE Root för europeiska enheter. ENISA fick Root-status i november 2025 och tog in sina första CNA:er i maj 2026.
- 4 nya CNA:er gick med i CVE-programmet under ENISA Root, utbildade och inboardade direkt av ENISA. 7 befintliga europeiska CNA:er överfördes från MITRE Root.
- 90+ europeiska CNA:er har möjlighet att frivilligt gå över till ENISA Root. Europa utgör redan nästan en femtedel av de 510 CNA:erna i 42 länder globalt.
- CRA Artikel 14 kräver att tillverkare rapporterar aktivt utnyttjade sårbarheter inom 24 timmar via ENISA:s gemensamma rapporteringsplattform (SRP), från och med den 11 september 2026.
- CVE-ID:n är det gemensamma identifieringssättet för den rapporten. ENISA som CVE Root innebär att Europa nu tilldelar CVE-ID:n direkt, utan att gå via MITRE.
- AI-acceleration är en uttalad drivkraft. ENISA:s Hans de Vries lyfte fram hur avancerade AI-modeller krymper tiden mellan sårbarhetsfynd och aktivt utnyttjande.
- Cybersäkerhetslagen 2 föreslår ytterligare operativa resurser till ENISA för att möta den ökande volymen.
MSB (Myndigheten för samhällsskydd och beredskap) och NCSC Sverige har per maj 2026 inte publicerat nationell vägledning om CRA. Informationen nedan utgår från förordningstexten och ENISA:s egna meddelanden.
Källa: ENISA:s tillkännagivande, 6 maj 2026.
Varför CVE-ID:n spelar roll för din Artikel 14-rapport
När CRA Artikel 14 kräver att du rapporterar en aktivt utnyttjad sårbarhet, måste rapporten identifiera sårbarheten exakt. CVE-ID:n är den globala standarden för den identifieringen. Det är dem ENISA:s europeiska sårbarhetsdatabas (EUVD) använder. Det är dem ENISA:s gemensamma rapporteringsplattform kommer att kräva.
För att få ett CVE-ID tilldelat krävs en CNA. Om ingen EU-CNA täckte din programvarukategori gick du till MITRE. MITRE är USA-baserat. Samordningen fungerade, men den introducerade fördröjning. Med en 24-timmarsklocka är fördröjning en efterlevnadsrisk.
ENISA som CVE Root förändrar flödet. Europeiska CNA:er samordnar nu CVE-tilldelning direkt med ENISA. För de flesta tillverkare är detta osynligt i vardagen. Du behöver inte vara en CNA. Men säkerhetsforskaren som hittar en bugg i din produkt, eller den CSIRT som hanterar din avslöjandeprocess, arbetar nu under en root-myndighet som är geografiskt anpassad till den myndighet du rapporterar till under Artikel 14.
Det är den infrastruktur ditt 24-timmarsfönster är beroende av.
Rapporteringskedjan under CRA Artikel 14
Artikel 14.1 kräver att tillverkare rapporterar till koordinerande CSIRT och till ENISA samtidigt, via ENISA:s gemensamma rapporteringsplattform. Du lämnar in en gång. Båda tar emot.
Men SRP:n behöver ett CVE-ID för att förankra rapporten. ENISA:s roll som CVE Root innebär att identifieringssteget och rapporteringssteget nu ligger under samma myndighet. Den aktör som namnger sårbarheten är samma aktör du rapporterar till. Det täpper till ett samordningsgap som fanns när de två funktionerna drevs av separata organisationer på olika kontinenter.
ENISA tilldelar nu CVE-ID:n för europeiska enheter och tar emot Artikel 14-rapporter via SRP:n. Den myndighet som namnger sårbarheten är samma myndighet du rapporterar till under CRA.
Se Artikel 14-rapporteringsguiden för den fullständiga 24-timmars-, 72-timmars- och 14-dagarscykeln och vad SRP-inlämningen täcker.
AI-accelerationsproblemet
Hans de Vries, ENISA:s Chief Cybersecurity and Operations Officer, var tydlig om varför detta spelar roll just nu:
I en tid när avancerade AI-modeller accelererar upptäckt och utnyttjande av sårbarheter måste Europas kapacitet för sårbarhetshantering hålla jämna steg och ge pålitligt operativt stöd till det bredare cybersäkerhetssamhället.
AI-verktyg krymper tiden mellan att en bugg hittas och att den utnyttjas. Fönstret mellan "en forskare hittar den" och "din 24-timmars Artikel 14-klocka startar" blir kortare. Två saker följer av det. Först: din interna triageprocess måste matcha en snabbare hotzeitlinje. Sedan: CVE-tilldelningssteget i kedjan behöver samma hastighet. ENISA bygger den kapaciteten nu. Cybersäkerhetslagen 2 föreslår ytterligare operativa resurser till ENISA specifikt för den funktionen.
Vad du inte behöver göra
Du behöver inte bli en CNA. CVE Numbering Authority-status är för organisationer som hittar och publicerar sårbarhetsposter. De flesta tillverkare är inte CNA:er och CRA kräver det inte.
Vad CRA Bilaga I, del II kräver är en policy för koordinerad sårbarhetsavslöjning (CVD). Den policyn beskriver hur din organisation tar emot, hanterar och avslöjar sårbarheter. Inom ramen för den policyn arbetar du med CNA:er eller CSIRT:er som hanterar CVE-tilldelning. ENISA som CVE Root innebär att de samarbetsparterna nu arbetar under en mer direkt EU-myndighetsstruktur.
Granska din CVD-policy mot tre frågor innan den 11 september 2026:
- Namnger den rapporteringsvägen? Policyn måste referera till ENISA SRP som inlämningskanal för Artikel 14-rapporter.
- Specificerar den hur du hanterar inkommande rapporter? När en forskare rapporterar en sårbarhet till dig måste policyn beskriva din svarstid och processen för CVE-begäran.
- Identifierar den din koordinerande CSIRT? Artikel 14.7 kräver att tillverkare utser en koordinerande CSIRT. Den utpekandet hör hemma i policyn.
Se CVD-policymallen för en strukturerad startpunkt.
Vår bedömning
"Förstärk, fragmentera inte" är rätt hållning. Risken med all EU-specifik infrastruktur är fragmentering. En europeisk CVE-silo som avviker från MITRE skulle skada alla, inklusive europeiska tillverkare som arbetar med globala leveranskedjor. Tillkännagivandet är tydligt: ENISA arbetar med CISA och MITRE som en del av ett gemensamt åtagande för det globala programmet.
Det viktigaste budskapet för tillverkare är en fråga om tidsplan. Infrastrukturen monteras ihop samtidigt som du ska efterleva den. SRP:n är inte live ännu. CVE Root har 11 CNA:er under sig av 90+ berättigade. Det här kommer att vara klart till september 2026, men du måste också vara redo, och att bygga din process kring infrastruktur som fortfarande håller på att komma online är svårare än att bygga den på stabil grund.
Vanliga frågor
Förändrar ENISA:s roll som CVE Root mina skyldigheter under Artikel 14?
Nej. Dina skyldigheter under Artikel 14 är oförändrade. Du rapporterar fortfarande aktivt utnyttjade sårbarheter inom 24 timmar via ENISA SRP från och med den 11 september 2026. Det som förändras är infrastrukturen bakom plattformen. ENISA hanterar nu CVE-ID-tilldelning direkt för europeiska enheter, vilket minskar samordningsfördröjningen mellan sårbarhetsidentifiering och rapporteringssteget. Se Artikel 14-rapporteringsguiden för fullständiga skyldighetsbeskrivningar.
Behöver jag bli en CVE Numbering Authority för att efterleva CRA?
Nej. CNA-status är för organisationer som hittar och publicerar sårbarhetsposter. CRA kräver en policy för koordinerad sårbarhetsavslöjning enligt Bilaga I, del II, och Artikel 14-rapportering via ENISA SRP. Det är skilt från CNA-medlemskap. De flesta tillverkare efterlever kraven genom att arbeta med befintliga CNA:er eller CSIRT:er i stället för att själva hålla CNA-status.
När blev ENISA en CVE Root och vad innebär det i praktiken?
ENISA blev CVE Root för europeiska enheter i november 2025. Som Root rekryterar, inboardar, utbildar och hanterar ENISA CNA:er inom sitt ansvarsområde, och bidrar till CVE-ID-tilldelning och postpublicering för europeiska enheter. De första CNA-inboardningarna under ENISA Root tillkännagavs den 6 maj 2026: fyra nya CNA:er och sju som överfördes från MITRE Root. I praktiken innebär det att europeiska CNA:er nu samordnar CVE-tilldelning med ENISA i stället för att gå via den USA-baserade MITRE-organisationen.
Vad är den europeiska sårbarhetsdatabasen och hur kopplar den till ENISA Root?
ENISA driver den europeiska sårbarhetsdatabasen (EUVD), som katalogiserar sårbarheter med CVE-ID:n som gemensam identifierare. Som CVE Root kontrollerar ENISA nu tilldelningen av dessa ID:n för europeiska enheter. Databasen och tilldelningsbehörigheten är samlade under en myndighet. Du kan använda EUVD för att kontrollera om en sårbarhet har registrerats, innan eller efter att du lämnar in en Artikel 14-rapport via SRP:n.
Varför spelar AI-accelerationsargumentet roll för min CRA-förberedelse?
ENISA:s Chief Cybersecurity and Operations Officer lyfte fram att avancerade AI-modeller krymper tiden mellan sårbarhetsfynd och utnyttjande. Ett kortare fönster från fynd till utnyttjande innebär mindre buffert mellan när en forskare hittar en bugg och när din 24-timmars Artikel 14-klocka startar. Din interna triageprocess måste vara byggd för det tempot. Kör en tabletop-övning mot 24-timmarsfönstret innan den 11 september 2026 för att verifiera att din process håller.
Vad är skillnaden mellan MITRE Root och ENISA Root för europeiska CNA:er?
MITRE är den USA-baserade organisation som historiskt fungerade som global CVE-root. Europeiska CNA:er under MITRE Root samordnade CVE-tilldelning via MITRE. Under ENISA Root samordnar dessa CNA:er direkt med ENISA. CVE-ID-formatet och CVE-programmets regler är oförändrade. Skillnaden är root-myndigheten: EU-baserad, EU-mandaterad och integrerad med den ENISA SRP och EUVD som CRA-tillverkare rapporterar genom.
Den här artikeln är enbart för informationsändamål och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, kontakta kvalificerad juridisk rådgivare.
Relaterade artiklar
Gäller CRA för din produkt?
Svara på 6 enkla frågor för att ta reda på om din produkt omfattas av EU:s Cyber Resilience Act. Få ditt resultat på under 2 minuter.
Redo att uppnå CRA-efterlevnad?
Börja hantera dina SBOM:ar och efterlevnadsdokumentation med CRA Evidence.