Kommissionens CRA-vägledning: utkastet från mars 2026

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

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

Introduktion

Utkastet till kommuniké Ares(2026)2319816, daterat den 3 mars 2026, är EU-kommissionens första vägledningsdokument om cyberresilienslagen. På ungefär 70 sidor besvarar den frågorna tillverkare har haft utan svar: Vad räknas som "fjärrdatabehandling"? Behöver äldre produkter omdesignas helt? När blir en programvaruuppdatering en ny produkt?

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). Säkerhetsskyldigheten försvinner inte, den flyttar från bedömning av överensstämmelse till komponenthantering.

2. Äldre produkter

Enskilda enheter som släppts på EU-marknaden före den 11 december 2027 omfattas inte av de nya kraven, om de inte ändras väsentligt från det datumet. Rapporteringsskyldigheterna är undantaget: de har gällt för de enheterna sedan september 2026.

Vägledningen hjälper mest för äldre modeller som du fortsätter sälja. Enheter av en befintlig modell som du först släpper på marknaden från och med den 11 december 2027 måste uppfylla kraven fullt ut, och kommissionen förtydligar tre saker om hur du kommer dit:

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 i stället för att bedöma varje artikelnummer för sig.

Full överensstämmelse gäller enheter du fortsätter att släppa. Enheter av en äldre modell som du först släpper på EU-marknaden från och med den 11 december 2027 behöver CE-märkning, en EU-försäkran om överensstämmelse och aktiv sårbarhetshantering. Enheter som redan släppts före det datumet omfattas inte av de kraven om de inte ändras väsentligt därefter, men rapporteringsplikten gäller dem sedan september 2026. Lättnaden gäller dokumentationshistoriken, inte skyldigheterna vid fortsatt utsläppande på marknaden.

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 (till exempel v1.0.0 till v1.0.1) återställer inte den regulatoriska klockan.

Det gäller specifikt fristående programvara som distribueras digitalt. Hårdvaruprodukter med inbyggd programvara följer de vanliga reglerna för att släppa fysiska varor på marknaden.

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

Kommissionen fastställer fyra frågor som varje tillverkare måste besvara 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?

Om svaret på någon av frågorna är ja är uppdateringen sannolikt en väsentlig ändring som kräver en ny bedömning av överensstämmelse.

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, även om de har commit-åtkomst. Ansvaret ligger hos den som styr releaseprocessen.
• Skyldigheter för stewards av öppen källkod växer med graden av stöd. Icke-teknisk stewardship ger lättare skyldigheter än fullt kommersiellt stöd.

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.

Vägledningen förtydligar också vägen enligt artikel 13(10): tillverkare får sluta korrigera äldre versioner om användarna kostnadsfritt kan uppgradera till en version som stöds. "Ytterligare kostnader" betyder här obligatoriska hårdvaruinköp. Rutinmässig testning, omkonfigurering eller driftsättning hos användaren räknas inte.

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.
• Om identifierade risker inte kan hanteras med tekniska eller organisatoriska åtgärder kan produkten behöva konstrueras om innan den får släppas på marknaden.

En tillverkare kan alltså inte medvetet leverera en produkt med ohanterade cybersäkerhetsrisker bara för att verksamheten har "accepterat" risken.

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årbarhetsavslöjande, intern säkerhetstestning, penetrationstester från tredje part.
• Rapporterade i tillförlitliga medier: en stor sårbarhet som täcks av etablerade cybersäkerhetspublikationer räknas som "känd".

Tillverkare får ett begränsat utredningsfönster för att bekräfta om en rapporterad sårbarhet faktiskt gäller deras produkt. Men "utredning" är inget kryphål. Klockan går från medvetenhet, och förseningar kommer att granskas.

9. Rapporteringsskyldigheter (september 2026)

Rapporteringsskyldigheterna från september 2026 är den första CRA-fristen med verklig sanktionskraft. Vägledningen bekräftar tidsstrukturen:

• 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 / en månad för incidenter

"Medveten" innebär rimlig säkerhet efter en inledande bedömning. Fullständig rättsmedicinsk bekräftelse krävs inte. Har du trovärdiga belägg för aktiv exploatering tickar klockan.

När det gäller underrättelse till användare bekräftar kommissionen att den ska vara riskbaserad och proportionerlig. Det finns inget obligatoriskt krav på offentligt avslöjande om avslöjandet skulle öka säkerhetsrisken.

För svenska tillverkare är Nationellt cybersäkerhetscenter (NCSC) vid FRA, där CERT-SE ingår, den relevanta myndigheten för rapporteringen. NCSC har en översiktssida om cyberresiliensförordningen, men vi har per den 17 oktober 2026 inte hittat någon CRA-vägledning för tillverkare från NCSC eller från Myndigheten för civilt försvar (MCF, tidigare MSB). Kontakta myndigheterna direkt för att förstå deras process.

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. Var redo att rapportera. Interna triageprocesser, eskaleringsvägar och rapportmallar måste finnas på plats nu. Uppdatering, 17 oktober 2026: rapporteringen har gällt sedan den 11 september 2026.

Den här artikeln dokumenterar utkastet till kommuniké Ares(2026)2319816 av den 3 mars 2026. Samrådet stängde den 13 april 2026. Se vägledningen från juli 2026 för den aktuella utkastpositionen.