CRA-checklista för konstruktionsteam: från omfattning till arkiv

Del av vår guide till cyberresiliensförordningen. Granskad 17 oktober 2026.

Så använder ni checklistan

Checklistan gör om EU:s cyberresiliensförordning (CRA), förordning (EU) 2024/2847, till arbetsuppgifter för ett konstruktionsteam, uppdelade på åtta områden: tillämpningsområde, säker konstruktion, programvaruförteckning (SBOM), sårbarhetshantering, teknisk dokumentation, bedömning av överensstämmelse, stödperiod och arkivering. Varje punkt anger relevant artikel eller bilaga. Vad förordningen är, vilka den omfattar och hela tidslinjen finns i guiden till cyberresiliensförordningen.

Vill ni ha ett eget exemplar kan ni skriva ut sidan eller spara den som PDF från webbläsarens utskriftsdialog; menyer och länkar på webbplatsen kommer inte med på utskriften.

Använd listan som arbetsstöd. Den är inte juridisk rådgivning; stäm av klassificering och förfarande mot den officiella texten.

Det som redan gäller. Sedan den 11 september 2026 måste tillverkare rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter enligt artikel 14, även för produkter som redan finns på marknaden (artikel 69.3). Har ni inte satt upp rapporteringen i avsnitt 4 ännu, börja där. Allt annat gäller från den 11 december 2027.

1. Tillämpningsområde och klassificering

1. Bekräfta att produkten omfattas. CRA gäller produkter med digitala element vars avsedda eller rimligen förutsebara användning innefattar en direkt eller indirekt logisk eller fysisk dataanslutning till en enhet eller ett nätverk (artikel 2.1).
2. Kontrollera undantagen. CRA undantar produkter som omfattas av MDR (EU) 2017/745, IVDR (EU) 2017/746 eller typgodkännandeförordningen för fordon (EU) 2019/2144, liksom vissa luftfarts- och marinprodukter (artikel 2.2 till 2.4). En bärbar produkt för hälsoövervakning som inte omfattas av MDR eller IVDR räknas däremot som en viktig produkt (bilaga III, klass I, punkt 19).
3. Bekräfta er roll. Ni är tillverkare om ni saluför produkten under ert namn eller varumärke (artikel 3.13).
4. Gå igenom bilaga III och bilaga IV. Produkter vars kärnfunktion motsvarar en kategori i bilaga III är viktiga produkter (klass I eller II); bilaga IV listar kritiska produkter. Klassen styr vilket förfarande ni ska använda (artiklarna 7, 8 och 32). Att bygga in en komponent med en funktion från bilaga III gör inte i sig er produkt till en viktig produkt (artikel 7.1).
5. Sortera befintliga produkter. Produkter som släppts ut på marknaden före den 11 december 2027 omfattas bara om de genomgår en väsentlig ändring från det datumet (artikel 69.2); rapporteringen i artikel 14 gäller ändå (artikel 69.3).
6. Dokumentera beslutet som ett godkänt och versionshanterat dokument.

2. Krav på säker konstruktion

1. Gör en cybersäkerhetsriskbedömning som täcker avsett ändamål, förutsebar användning, driftmiljö, tillgångar och förväntad användningstid (artikel 13.2 och 13.3).
2. Gå igenom bilaga I, del I, punkt 2. Ange för varje krav om det är tillämpligt, hur ni uppfyller det och varför det inte gäller när så är fallet (artikel 13.3 och 13.4).
3. Arbeta igenom konstruktionskraven (bilaga I, del I, punkt 2):
   • inga kända utnyttjbara sårbarheter vid utsläppandet (a)
   • säker standardkonfiguration, med möjlighet att återställa till ursprungsläget (b)
   • säkerhetsuppdateringar, automatiska som standard där det är tillämpligt, med möjlighet att välja bort (c)
   • åtkomstkontroll, konfidentialitet och integritet (d, e, f)
   • dataminimering (g)
   • tillgänglighet, inklusive motståndskraft mot överbelastningsattacker, och begränsad påverkan på andra nätverk (h, i)
   • begränsad attackyta och skydd mot utnyttjande (j, k)
   • säkerhetsloggning med möjlighet att välja bort (l)
   • säker radering av användardata och inställningar (m)
4. Granska komponenter från tredje part och öppen källkod med tillbörlig aktsamhet (artikel 13.5).
5. Håll riskbedömningen aktuell under stödperioden (artikel 13.3).

3. Programvaruförteckning och komponentspårning

1. Upprätta en programvaruförteckning (SBOM) i ett allmänt använt och maskinläsbart format som åtminstone täcker de översta beroendena (bilaga I, del II, punkt 1).
2. Ta fram en SBOM per släppt programvaru- eller firmwareversion, och koppla den till den hårdvarurevision den levereras på.
3. Lägg SBOM:en i den tekniska dokumentationen (bilaga VII, punkt 2 b), och var beredd att lämna den till en marknadskontrollmyndighet efter en motiverad begäran (bilaga VII, punkt 8).
4. Bestäm om ni ska dela den med användarna. Ni är inte skyldiga att offentliggöra SBOM:en (skäl 77). Om ni delar den ska användarinformationen ange var den finns (bilaga II, punkt 9).
5. Bevaka genomförandeakter om SBOM:ens format och innehåll (artikel 13.24).

SBOM och produktdata går igenom format, minimielement och revisionsstyrning.

4. Sårbarhetshantering och rapportering

Process (bilaga I, del II, om inget annat anges):

1. Utse en enda kontaktpunkt för sårbarhetsrapporter; användarna ska kunna välja kommunikationssätt, inte bara automatiserade verktyg (artikel 13.17). Publicera en kontaktadress för rapportering (punkt 6).
2. Inför och tillämpa en policy för samordnad delgivning av information om sårbarheter (punkt 5).
3. Genomför effektiva och regelbundna säkerhetstester och granskningar (punkt 3).
4. Åtgärda sårbarheter utan dröjsmål; leverera säkerhetsuppdateringar separat från funktionsuppdateringar där det är tekniskt möjligt (punkt 2).
5. Distribuera uppdateringar säkert (punkt 7), utan dröjsmål och kostnadsfritt, med meddelanden som förklarar vad användaren behöver göra (punkt 8).
6. När en rättelse finns, publicera information om den åtgärdade sårbarheten (punkt 4).
7. Rapportera sårbarheter ni hittar i inbyggda komponenter till den som underhåller dem (artikel 13.6).

Obligatorisk rapportering (artikel 14). Anmäl samtidigt till den CSIRT-enhet som utsetts till samordnare och till ENISA, via den gemensamma rapporteringsplattformen (artiklarna 14.1 och 16):

Händelse	Tidig varning	Anmälan	Slutrapport
Aktivt utnyttjad sårbarhet	Inom 24 timmar från att ni fått kännedom	Inom 72 timmar	Senast 14 dagar efter att en korrigerande eller begränsande åtgärd finns
Allvarlig incident som påverkar produktens säkerhet	Inom 24 timmar från att ni fått kännedom	Inom 72 timmar	Inom en månad efter incidentanmälan

8. Informera berörda användare, och vid behov alla användare, om sårbarheten eller incidenten och om åtgärder de själva kan vidta (artikel 14.8).
9. Bestäm i förväg vem som gör triage, vem som avgör att något ska rapporteras och vem som skickar in det. Klockan börjar gå när ni får kännedom.

5. Teknisk dokumentation

Ta fram den innan produkten släpps ut på marknaden och uppdatera den åtminstone under stödperioden (artikel 31.2). Bilaga VII anger minsta innehåll:

1. Allmän beskrivning: avsett ändamål, programvaruversioner som påverkar överensstämmelsen, bilder av hårdvaran och användarinformation (punkt 1).
2. Information om konstruktion och utveckling, inklusive ritningar, scheman och systemarkitektur (punkt 2 a).
3. Sårbarhetshantering: SBOM, policy för samordnad delgivning, belägg för en kontaktadress och lösningen för säker distribution av uppdateringar (punkt 2 b).
4. Processer för tillverkning och övervakning och valideringen av dem (punkt 2 c).
5. Cybersäkerhetsriskbedömningen (punkt 3).
6. Underlaget för att bestämma stödperioden (punkt 4).
7. Tillämpade harmoniserade standarder, gemensamma specifikationer eller certifieringsordningar, eller de lösningar som valts i stället (punkt 5).
8. Testrapporter (punkt 6).
9. En kopia av EU-försäkran om överensstämmelse (punkt 7).

Mikroföretag och små företag får använda ett förenklat dokumentationsformulär som kommissionen fastställer (artikel 33.5).

6. Bedömning av överensstämmelse och CE-märkning

1. Välj förfarande (artikel 32):
   • produkter som inte finns i bilaga III eller IV: modul A (intern kontroll), modul B och C, modul H eller en certifieringsordning där sådan finns (artikel 32.1)
   • viktiga produkter, klass I: modul A bara om harmoniserade standarder, gemensamma specifikationer eller certifieringsordningar tillämpas fullt ut; annars B och C, eller H (artikel 32.2)
   • viktiga produkter, klass II: B och C, H, eller en certifieringsordning på minst assuransnivån "betydande" (artikel 32.3)
   • kritiska produkter: en europeisk cybersäkerhetscertifieringsordning enligt artikel 8.1, eller ett förfarande för klass II (artikel 32.4)
2. Upprätta EU-försäkran om överensstämmelse enligt mallen i bilaga V (artikel 28); en gemensam försäkran när flera unionsrättsakter gäller (artikel 28.3).
3. Anbringa CE-märkningen innan produkten släpps ut på marknaden (artikel 30.3), följd av det anmälda organets nummer när modul H används (artikel 30.4).
4. Identifiera produkten med typ-, parti- eller serienummer (artikel 13.15), och ange tillverkarens kontaktuppgifter (artikel 13.16).
5. Leverera användarinformationen enligt bilaga II (artikel 13.18).
6. Se till att serietillverkningen fortsätter att uppfylla kraven när konstruktion och tillverkning ändras (artikel 13.14).

7. Stödperiod och uppdateringar

1. Bestäm stödperioden utifrån förväntad användningstid: minst fem år, eller den förväntade användningstiden om den är kortare (artikel 13.8).
2. Dokumentera underlaget i den tekniska dokumentationen (artikel 13.8; bilaga VII, punkt 4).
3. Ange slutdatumet, minst månad och år, vid köptillfället (artikel 13.19).
4. Håll varje säkerhetsuppdatering tillgänglig i minst 10 år efter att den getts ut, eller resten av stödperioden om den är längre (artikel 13.9).
5. Bedöm varje ändring mot definitionen av väsentlig ändring (artikel 3.30), och uppdatera riskbedömningen och den tekniska dokumentationen.
6. Agera vid bristande överensstämmelse med korrigerande åtgärder, tillbakadragande eller återkallelse (artikel 13.21).

8. Arkivering av dokumentation

1. Spara den tekniska dokumentationen och EU-försäkran om överensstämmelse i minst 10 år efter utsläppandet på marknaden, eller under stödperioden om den är längre (artikel 13.13).
2. Håll användarinformation och instruktioner tillgängliga under samma tid (artikel 13.18).
3. Kunna lämna allt som visar överensstämmelse till en myndighet efter en motiverad begäran (artikel 13.22).
4. Ordna underlaget per produktrevision, så att ni kan ta fram det för varje levererad revision flera år senare.

Där produktdata och dokumentstyrning kommer in

De flesta punkterna på listan ger ett dokument som ni ska godkänna, versionshantera, koppla till en produktrevision och spara i ett decennium, och det är dokumentstyrningens uppgift. Under CRA-efterlevnad med neo ser ni hur neo hanterar dokumenten och vad som lämnas åt andra verktyg, eller prata med oss om er produktlinje.