CRA får sin instruktionsmanual: Vad kommissionens vägledning innebär för dig

Cyberresilienslagen har haft sin text sedan slutet av 2024. Vad den saknade var en instruktionsmanual. Den 3 mars 2026 publicerade EU-kommissionen exakt det: utkast till kommuniké Ares(2026)2319816 – ungefär 70 sidor med praktisk vägledning om hur förordningen ska tolkas.

Detta är artikel 26-vägledningen som branschen har väntat på. Här är vad den säger och vad det innebär för dig.

Sammanfattning

• SaaS-/molnprodukter ingår i tillämpningsområdet bara om de uppfyller ett strängt tredelstest för "fjärrdatabehandling" (RDPS). De flesta tredjepartssaas faller utanför produktgränsen men måste behandlas som en komponent.
• Äldre produkter som placerats på marknaden före december 2027 behöver inte omdesignas, men tillverkare måste genomföra en aktuell cybersäkerhetsriskbedömning och utfärda en försäkran om överensstämmelse.
• Programvaruuppdateringar utgör i allmänhet inte "väsentliga ändringar" om de inte introducerar nya hotvektorer eller ändrar produktens avsedda syfte.
• Öppen källkod-bidragsgivare utan kontroll över releaser, färdplan eller styrning är explicit inte ansvariga – även om de har commit-åtkomst.
• Supportperioder måste återspegla förväntad produktlivstid. Fem år är ett golv, inte ett standardvärde.
• Sårbarhetrapportering (september 2026): 24-timmarsklockan startar vid medvetenhet, inte vid bekräftelse.

Viktigt: Denna vägledning är ett UTKAST. Återkopplingsperioden är öppen via portalen för bättre lagstiftning. Den kommer att slutföras när alla EU-språkversioner är tillgängliga.

Introduktion

Utkasten till kommuniké Ares(2026)2319816, daterad den 3 mars 2026, är EU-kommissionens första heltäckande vägledningsdokument om cyberresilienslagen. På ungefär 70 sidor täcker den de frågor som har hållit efterlevnadsteam vakna på natten: Vad räknas som "fjärrdatabehandling"? Behöver äldre produkter omdesignas helt? När blir en programvaruuppdatering en ny produkt?

Den här artikeln destillerar de nio mest konsekventa avgörandena till praktisk vägledning för tillverkare, importörer och distributörer av produkter med digitala element.

1. SaaS och moln: RDPS-testet

Kommissionen introducerar ett strängt trefrågestest för att avgöra om en moln- eller SaaS-komponent kvalificerar som "lösningar för fjärrdatabehandling" (RDPS) och därmed ingår i produktens konformitetsomfång.

flowchart TD
    A["Behandlar lösningen data
'på distans'?"] -->|Nej| B["Inte RDPS"]
    A -->|Ja| C["Skulle produkten förlora en kärnfunktion
utan denna lösning?"]
    C -->|Nej| D["Inte RDPS
(behandla som komponent,
gör due diligence enligt Art 13(5))"]
    C -->|Ja| E["Designad av eller under
tillverkarens ansvar?"]
    E -->|Nej| F["Inte RDPS
(tredjepartssaas = komponent,
gör due diligence enligt Art 13(5))"]
    E -->|Ja| G["RDPS: inom produktens
konformitetsbedömningsomfång"]

Viktigt: Även när en molntjänst inte kvalificerar som RDPS, måste tillverkaren ändå behandla den som en komponent och utföra due diligence i leverantörskedjan enligt artikel 13(5).

2. Äldre produkter

Produkter som redan finns på EU-marknaden före december 2027 behöver inte redesignas från grunden. Men de är inte heller undantagna.

Kommissionen förtydligar tre saker:

Ingen historisk rekonstruktion krävs. Du behöver inte återskapa utvecklingsdokumentation från år tillbaka. Det som är viktigt är en aktuell cybersäkerhetsriskbedömning som visar att produkten uppfyller väsentliga krav baserat på dess avsedda syfte.

Produktfamiljer kan grupperas. Om flera äldre produkter delar samma arkitektur och riskprofil kan du göra en enda riskbedömning som täcker familjen.

Full konformitet gäller fortfarande. Äldre produkter behöver fortfarande CE-märkning, en försäkran om överensstämmelse och aktiv sårbarhethantering framöver.

3. Programvara och "oändliga kopior"

När anses programvara "placerad på marknaden"? Kommissionen bekräftar: en gång. Den inledande digitala distributionen utgör placering. Efterföljande mindre uppdateringar återställer inte den regulatoriska klockan.

4. När uppdateringar blir "väsentliga ändringar"

Kommissionen föreslår fyra frågor som varje tillverkare bör ställa innan en uppdatering släpps:

1. Introducerar uppdateringen nya hotvektorer?
2. Möjliggör den nya attackscenarier?
3. Ändrar den sannolikheten för befintliga attackscenarier?
4. Ändrar den konsekvenserna av befintliga attackscenarier?

5. Regler för öppen källkod

Vägledningen ger flera viktiga klargöranden om hur CRA gäller för programvara med öppen källkod:

• Att publicera källkod i offentliga arkiv utgör inte "placering på marknaden."
• Community-edition kontra betald edition = olika produkter.
• Donationer ensamma gör inte FOSS kommersiell – om inte åtkomst till programvaran är villkorad av att donera.
• Ideella organisationer vars överskott helt går till icke-vinstdrivande syften är undantagna.
• Bidragsgivare utan kontroll över releaser, färdplan eller styrning betraktas INTE som tillverkare.

6. Supportperiod: Fem år är ett golv

Kommissionen gör det klart att den femåriga standardsupportperioden är ett minimum, inte ett mål. Produkter som förväntas användas längre än fem år måste ha proportionellt längre supportperioder.

7. Riskbedömning: Intern risktolerans är irrelevant

Kommissionen är otvetydig: riskbedömningar enligt CRA måste baseras på objektiva cybersäkerhetskriterier, inte på tillverkarens interna risktolerans.

• Kommersiell strategi och kostnadshänsyn påverkar inte cybersäkerhetsriskbedömningen.
• Du kan inte överföra cybersäkerhetsrisk till användare genom dokumentation, ansvarsfriskrivningar eller användarvillkor.

8. Kända exploaterbara sårbarheter

Vägledningen förtydligar vad "känd" innebär i samband med CRA:s krav på att leverera produkter utan kända exploaterbara sårbarheter:

• Listade i offentliga databaser: EU:s sårbarhetsdatabas, CVE/MITRE, NVD.
• Avslöjad via icke-offentliga kanaler: koordinerade program för sårbarhetavslöjande.
• Prominently rapporterade i tillförlitliga medier: en stor sårbarhet som täcks av mainstream-cybersäkerhetspublikationer.

9. Rapporteringsskyldigheter (september 2026)

• 24 timmar: Tidig varning till ENISA efter att ha blivit medveten om aktiv exploatering
• 72 timmar: Detaljerad notifiering med tekniska indikatorer
• 14 dagar: Slutrapport för sårbarheter / 30 dagar för incidenter

"Medveten" innebär rimlig säkerhet efter en inledande bedömning – inte fullständig rättsmedicinskbekräftelse.

Vad detta innebär för dig

Denna vägledning ändrar inte vad CRA kräver. Men den ändrar hur mycket gissningsarbete som är inblandat. Tillverkare har nu konkreta tester (RDPS), konkreta exempel (väsentliga ändringar) och konkreta tidslinjer (rapportering) att arbeta med.

Tre omedelbara åtgärder:

1. Kör RDPS-testet på varje molntjänst din produkt är beroende av.
2. Granska din uppdateringsprocess mot de fyra frågorna om väsentliga ändringar.
3. Förbered för rapportering i september 2026. Interna triageprocesser, eskaleringsväggar och rapportmallar måste vara på plats före deadline.

Den här artikeln baseras på utkastet till kommuniké Ares(2026)2319816, daterad den 3 mars 2026. Denna vägledning har ännu inte formellt antagits av EU-kommissionen och kommer att slutföras när alla EU-språkversioner är tillgängliga.