Modul 4 – Kapitel II, del 2 (Art. 11–15): Tillverkarens skyldigheter och sårbarhetshantering

Översikt: Var är vi i Cyber Resilience Act (CRA)?

I denna modul fördjupar vi oss i Kapitel II, del 2 (artiklarna 11–15) i EU:s Cyber Resilience Act (CRA).

Sedan 2024 har CRA successivt färdigställts på EU-nivå som en förordning (inte ett direktiv). Det betyder att reglerna gäller direkt i alla medlemsstater när de väl trätt i kraft, utan nationell implementering. Flera av detaljerna kring praktiskt genomförande preciseras i kompletterande rättsakter och vägledningar från EU-kommissionen och ENISA.

I tidigare moduler har du lärt dig:

• Modul 2 (Art. 1–5): syfte, tillämpningsområde, definitioner.
• Modul 3 (Art. 6–10): riskkategorier, väsentliga cybersäkerhetskrav, secure by design och secure by default.

Nu fokuserar vi på tillverkarens ansvar under hela livscykeln för en produkt med digitala element (PDE):

• Art. 11–12: Allmänna skyldigheter och riskhantering.
• Art. 13: Teknisk dokumentation och bevis på överensstämmelse.
• Art. 14: Sårbarhetshantering och rapportering (inkl. tidsfrister).
• Art. 15: Livscykelhantering, supportperiod och säkerhetsuppdateringar.

> Lärandefokus: Efter modulen ska du kunna:

> 1. Förklara tillverkarens huvudsakliga skyldigheter enligt art. 11–13.

> 2. Förstå kraven på sårbarhetshantering och rapportering (art. 14), särskilt tidslinjer.

> 3. Beskriva vad som krävs kring säkerhetsuppdateringar under produktens livscykel (art. 15).

> 4. Känna igen vilka interna processer ett företag behöver ha på plats för att klara kraven.

Tidsåtgången är cirka 15 minuter, med korta interaktiva moment längs vägen.

Art. 11 – Tillverkarens allmänna skyldigheter (översikt)

Artikel 11 samlar kärnan i vad en tillverkare måste göra innan en produkt med digitala element släpps på EU-marknaden och under dess användning.

Förenklat kan man se art. 11 som fem huvudblock:

1. Design och utveckling

• Produkten ska uppfylla de väsentliga cybersäkerhetskraven (från art. 8 och bilagor) redan från början.
• Secure by design och secure by default ska vara inbyggt, inte påklistrat i efterhand.

1. Riskbedömning

• Tillverkaren ska genomföra en systematisk riskanalys av:
• kända och rimligen förutsebara hot,
• möjliga angreppsvektorer,
• konsekvenser för konfidentialitet, riktighet, tillgänglighet.
• Riskanalysen ska uppdateras när nya sårbarheter eller användningssätt upptäcks.

1. Teknisk dokumentation

• Allt som behövs för att visa att produkten uppfyller kraven ska dokumenteras (se art. 13 mer i detalj senare).

1. Överensstämmelsebedömning och CE-märkning

• Tillverkaren ansvarar för att rätt bedömningsförfarande används beroende på produktens riskklass.
• När kraven är uppfyllda: EU-försäkran om överensstämmelse och CE-märkning.

1. Övervakning efter utsläppande på marknaden (post-market)

• Tillverkaren måste aktivt övervaka produkten efter lansering:
• samla in information om sårbarheter och incidenter,
• analysera och hantera risker,
• distribuera säkerhetsuppdateringar.

En viktig skillnad mot äldre regelverk är att CRA betonar kontinuerligt ansvar: tillverkarens ansvar slutar inte vid försäljning, utan fortsätter under hela den definierade supportperioden.

Reflektionsövning: Kartlägg tillverkarens ansvar

Föreställ dig att du är cybersäkerhetsansvarig på ett företag som utvecklar en smart hem-hubb (styrning av lampor, dörrlås, sensorer via app).

Fundera kort (skriv gärna ned stödord):

1. Vilka tre konkreta saker måste ni göra innan produkten får säljas i EU för att uppfylla art. 11?
2. Vilka två typer av aktiviteter måste ni fortsätta med efter att produkten släppts på marknaden?

Tips – tänk i kategorierna:

• design/utveckling
• riskbedömning
• dokumentation
• övervakning/sårbarhetshantering

När du är klar, jämför med denna korta checklista:

• Före marknadslansering: genomförd riskanalys, teknisk dokumentation framtagen, överensstämmelsebedömning + CE-märkning.
• Efter lansering: kontinuerlig övervakning av sårbarheter, snabb hantering och distribution av säkerhetsuppdateringar.

Art. 12 – Riskhantering: från teori till process

Artikel 12 konkretiserar hur tillverkaren ska arbeta med risker.

Nyckelidé: riskhantering är en återkommande process, inte en engångsövning inför lansering.

Centrala krav i art. 12

1. Systematisk riskhanteringsprocess

Tillverkaren ska ha en process som minst omfattar:

• Identifiering av tillgångar (data, funktioner, gränssnitt) och hot.
• Bedömning av sannolikhet och konsekvens (risknivå).
• Riskbehandling (t.ex. ändra design, lägga till skydd, begränsa funktioner).
• Verifiering av att åtgärderna fungerar (tester, penetrationstester, kodgranskning).

1. Koppling till väsentliga krav

• Riskhanteringen ska säkerställa att de väsentliga kraven (t.ex. åtkomstkontroll, loggning, uppdateringsmekanismer) verkligen är uppfyllda i praktiken.

1. Livscykelperspektiv

• Processen ska täcka:
• utveckling,
• produktion,
• distribution,
• drift och underhåll,
• avveckling.

1. Hantering av nya sårbarheter

• När nya sårbarheter upptäcks (egna tester, bug bounty, CERT-varningar etc.) ska de:
• snabbt bedömas (är detta exploaterbart? vilken påverkan?),
• vid behov leda till uppdateringar av både produkt och riskanalys.

> Koppling till verkligheten (2026): Många företag använder idag etablerade ramverk som ISO/IEC 27001, ISO/IEC 62443 (industri) eller NIST Cybersecurity Framework som grund. CRA kräver inte ett visst ramverk, men i praktiken blir dessa ofta ryggraden i att visa att man har en strukturerad riskhanteringsprocess.

Exempel: Riskhantering för en uppkopplad medicinsk sensor

Vi tar ett förenklat exempel på hur art. 12 kan se ut i praktiken.

Produkt: Bärbar medicinsk sensor som mäter hjärtfrekvens och skickar data via mobilapp till sjukhuset.

Steg 1 – Identifiera tillgångar och hot

• Tillgångar: patientdata, kommunikationskanal, autentiseringsmekanismer, molnserver.
• Hot:
• Avlyssning av data i transit.
• Obehörig åtkomst till molnkontot.
• Manipulation av mätvärden.

Steg 2 – Bedöma risker

• Avlyssning av data: medel sannolikhet, hög konsekvens (integritetsrisk) → hög risk.
• Obehörig åtkomst till molnkontot: låg sannolikhet (med bra lösenord), mycket hög konsekvens → hög risk.

Steg 3 – Riskbehandling

• Kryptering av all kommunikation (TLS).
• Starkt autentiseringssystem (t.ex. tvåfaktorsautentisering för vårdpersonal).
• Loggning och övervakning av inloggningar.

Steg 4 – Verifiering

• Genomföra penetrationstest av appen och molnplattformen.
• Testa att loggar verkligen fångar misstänkta inloggningsförsök.

Steg 5 – Kontinuerlig uppdatering

• När en ny sårbarhet i den använda krypteringsbiblioteket rapporteras av en extern forskare:
• analysera påverkan på produkten,
• ta fram patch,
• distribuera uppdatering,
• uppdatera riskanalysen och tekniska dokumentationen.

Detta illustrerar hur art. 12 inte bara är "pappersarbete" utan kräver en levande process i organisationen.

Art. 13 – Teknisk dokumentation och bevis på överensstämmelse

Artikel 13 beskriver vad teknisk dokumentation ska innehålla och hur den kopplas till överensstämmelse med CRA.

Vad är teknisk dokumentation?

En samlad dokumentation som gör det möjligt för myndigheter och bedömningsorgan att kontrollera att produkten uppfyller CRA. Den ska finnas innan produkten släpps på marknaden och hållas uppdaterad.

Typiska delar i dokumentationen

(Detaljer kan variera beroende på produkt och senare genomförandeakter, men i praktiken förväntas minst):

1. Produktbeskrivning

• funktioner, arkitektur, komponenter (inkl. tredjepartsbibliotek och open source),
• avsedd användning och rimligen förutsebar felanvändning.

1. Riskanalys och riskhanteringsresultat

• identifierade risker,
• valda skyddsåtgärder,
• kvarvarande risker.

1. Tekniska lösningar för cybersäkerhet

• autentisering, auktorisation, loggning,
• kryptering, nyckelhantering,
• uppdateringsmekanism (hur patchar distribueras säkert).

1. Tester och verifiering

• testplaner och testresultat (inkl. säkerhetstester),
• ev. resultat från tredjepartsgranskning.

1. Överensstämmelsebedömning

• vilket förfarande som använts (t.ex. intern kontroll, anmält organ för högriskprodukter),
• EU-försäkran om överensstämmelse.

Varför är detta viktigt i praktiken?

• Vid tillsyn (t.ex. av en marknadskontrollmyndighet) måste tillverkaren snabbt kunna visa hur kraven uppfylls.
• Vid en allvarlig incident kan bristfällig dokumentation göra det svårt att visa att man agerat ansvarsfullt.
• Dokumentationen är också grunden för att effektivt kunna uppdatera produkten när nya sårbarheter upptäcks.

Snabbtest: Vad ingår i teknisk dokumentation?

Välj det alternativ som bäst motsvarar vad teknisk dokumentation enligt art. 13 typiskt ska innehålla.

Art. 14 – Sårbarhetshantering och rapportering (inkl. tidsfrister)

Artikel 14 är en av de mest praktiskt krävande delarna för tillverkare. Den rör organiserad sårbarhetshantering och rapportering av allvarliga incidenter och sårbarheter.

1. Sårbarhetshanteringsprocess

Tillverkaren ska ha en formell process som minst omfattar:

• mottagning av sårbarhetsrapporter (t.ex. via en vulnerability disclosure policy på webben),
• triagering (bedömning av allvarlighetsgrad och påverkan),
• åtgärdsplanering (patch, workaround, konfigurationsändring etc.),
• testning av åtgärder,
• distribution av uppdateringar till användare,
• kommunikation till användare om risker och åtgärder.

Detta ligger i linje med moderna principer för coordinated vulnerability disclosure (CVD), som både ENISA och många branschaktörer rekommenderar.

2. Rapporteringsskyldigheter och tidsfrister

CRA kopplas till EU:s bredare incidentrapporteringsregimer (bl.a. NIS2). Detaljerade tekniska genomföranderegler har preciserats efter 2024, men kärnprinciperna är:

• Vem rapporterar?
• Tillverkaren av produkten med digitala element.

• Vad ska rapporteras?
• Allvarliga incidenter kopplade till cybersäkerheten i produkten, t.ex.:
• incidenter som leder till betydande störningar i viktiga tjänster,
• incidenter som ger stor påverkan på konfidentialitet, riktighet eller tillgänglighet för data,
• incidenter som kan ha gränsöverskridande effekter.
• Allvarliga sårbarheter som upptäcks i produkten, särskilt om de redan utnyttjas aktivt eller lätt kan utnyttjas.

• Till vem?
• Rapporter går i första hand till relevanta nationella behöriga myndigheter eller CSIRTs (Computer Security Incident Response Teams) som utsetts enligt NIS2 och kompletterande regler.
• I vissa fall kan även ENISA involveras som samordnande EU-organ.

• När? (tidsfrister)
• För allvarliga incidenter följer CRA i stort sett de korta tidsfrister som etablerats i NIS2-regleringen (tim- till dygnsnivå). I praktiken innebär det att tillverkaren typiskt måste:
• lämna en tidig varning inom ungefär 24 timmar från att ha fått kännedom om en allvarlig incident,
• lämna en mer detaljerad incidentrapport inom några dagar (t.ex. 72 timmar),
• lämna en slutrapport när incidenten är hanterad.

> Viktigt 2026: Exakta tidsangivelser och format för rapporter specificeras i kompletterande rättsakter och nationella föreskrifter. Men som tillverkare måste man redan nu planera för mycket snabba rapporteringskedjor (timmar, inte veckor).

3. Samspel med användare och andra aktörer

• Tillverkaren ska informera användare om:
• kända sårbarheter som påverkar dem,
• tillgängliga uppdateringar och hur de installeras,
• tillfälliga åtgärder (workarounds) om patch inte omedelbart är möjlig.
• Tillverkaren ska också kunna samarbeta med:
• andra aktörer i leveranskedjan (importörer, distributörer),
• andra tillverkare vars produkter påverkas av samma sårbarhet (t.ex. gemensamma bibliotek).

Scenariobaserad övning: Incidentrapportering enligt art. 14

Scenario: Ditt företag tillverkar routrar för småföretag. En säkerhetsforskare kontaktar er och visar på en sårbarhet som gör det möjligt att ta full kontroll över routern på distans utan lösenord. Ni bekräftar snabbt att sårbarheten är verklig och lätt exploaterbar.

Reflektera kort över följande (skriv gärna ned punktvis):

1. Vilka tre första steg bör ni ta internt de första 24 timmarna?
2. Vilka externa parter behöver informeras, och ungefär hur snabbt?
3. Vad behöver ni kommunicera till kunderna?

Jämför sedan med denna möjliga åtgärdslista:

• Första 24 timmarna:
• aktivera incidenthanteringsgruppen,
• bekräfta tekniska detaljer och påverkan,
• göra en preliminär riskbedömning (påverkan, spridning, pågående utnyttjande?).
• Externt (inom ca 24–72 timmar för allvarliga incidenter):
• lämna en första incidentrapport till behörig myndighet/CSIRT enligt de tidsfrister som gäller nationellt,
• vid behov samverka med andra drabbade aktörer (t.ex. ISP:er).
• Mot kunder:
• informera om sårbarheten,
• ge tydliga instruktioner om tillfälliga skyddsåtgärder (t.ex. stänga fjärradministration),
• förbereda och distribuera patch så snart det är säkert möjligt.

Art. 15 – Livscykelhantering, supportperiod och säkerhetsuppdateringar

Artikel 15 fokuserar på hur länge och på vilket sätt tillverkaren måste ge säkerhetsstöd till produkten.

1. Definiera supportperiod

• Tillverkaren måste ange en supportperiod under vilken:
• produkten får säkerhetsuppdateringar,
• sårbarheter hanteras aktivt.
• Denna period ska vara rimlig i förhållande till produktens förväntade livslängd och riskprofil.
• Exempel: En uppkopplad leksak kan ha kortare supportperiod än en router som används i kritisk infrastruktur.

2. Krav på säkerhetsuppdateringar

Under supportperioden ska tillverkaren:

• tillhandahålla uppdateringar som åtgärdar kända sårbarheter,
• se till att uppdateringar kan:
• installeras på ett säkert sätt (integritets- och autenticitetsskydd),
• inte orimligt försämra produktens funktion eller användbarhet,
• vid behov kunna installeras automatiskt eller med tydliga instruktioner.

3. Information till användare

• Användare ska få klar information om:
• hur länge produkten får säkerhetsuppdateringar (supportperioden),
• hur uppdateringar levereras och installeras,
• vilka risker som uppstår efter att supportperioden löpt ut.

4. När supportperioden tar slut

• När supportperioden är över har tillverkaren normalt inte längre skyldighet att tillhandahålla nya säkerhetsuppdateringar.
• Men: om produkten fortfarande används i stor skala i känsliga miljöer kan det i praktiken uppstå reputations- och avtalsrisker om man slutar uppdatera helt.

> I praktiken (2026): Stora tillverkare börjar nu allt oftare ange tydliga "säkerhetsstöd till och med"-datum på sina produkter, liknande hur mobilplattformar kommunicerar versionsstöd. Detta blir en viktig del av kundernas beslutsunderlag.

Kunskapscheck: Supportperiod och uppdateringar

Testa din förståelse av art. 15.

Vilka interna processer behövs för att uppfylla art. 11–15?

För att ett företag i praktiken ska klara kraven i art. 11–15 krävs inte bara teknik, utan väl etablerade interna processer.

Här är en översikt över typiska processer som behöver finnas eller förstärkas:

1. Produktutvecklingsprocess med inbyggd säkerhet

• Secure development lifecycle (SDL/S-SDLC):
• säkerhetskrav i kravspecifikationen,
• kodgranskning med fokus på säkerhet,
• säkerhetstester före release.

1. Formell riskhanteringsprocess (art. 12)

• metodik för riskanalys (t.ex. enligt ISO/IEC 27005),
• regelbundna uppdateringar vid förändringar i produkt eller hotlandskap,
• dokumentationsrutiner kopplade till art. 13.

1. Sårbarhetshantering och CVD (art. 14)

• publicerad vulnerability disclosure policy på webben,
• definierade kontaktvägar (t.ex. security@företag.se),
• triageringsprocess (prioritering av inkommande rapporter),
• samarbetsrutiner med forskare och CERT/CSIRT.

1. Incidenthantering och rapportering (art. 14)

• incidentresponsplan med roller, ansvar och beslutsvägar,
• förberedda mallar för rapportering till myndigheter (för att klara snäva tidsfrister),
• övningar (t.ex. tabletop) för att testa processen.

1. Livscykel- och uppdateringshantering (art. 15)

• releaseprocess för patchar (test, godkännande, distribution),
• tydlig dokumentation av supportperiod per produkt,
• kommunikationsplan för att informera användare om uppdateringar och end-of-support.

1. Styrning och ansvar

• utpekad produktägare eller säkerhetsansvarig per produktlinje,
• ledningssystem för informationssäkerhet (t.ex. ISO/IEC 27001) som ger struktur och uppföljning,
• utbildning av utvecklare, produktägare och supportpersonal i CRA-kraven.

> Nyckelinsikt: CRA handlar lika mycket om organisation och process som om teknik. Företag som redan arbetar metodiskt med informationssäkerhet har ett försprång, men behöver ändå justera sina processer för att matcha de specifika kraven i art. 11–15.

Repetition av nyckelbegrepp

Använd korten för att repetera centrala begrepp från artiklarna 11–15.