Modul 3 – Kapitel II, del 1 (Art. 6–10): Riskkategorier och väsentliga cybersäkerhetskrav

1. Snabb orientering: Var är vi i förordningen?

I denna modul går vi in i kapitel II (Art. 6–10) i cyberresiliensförordningen – Cyber Resilience Act, förordning (EU) 2024/2847.

Kapitel II handlar om:

• Hur produkter med digitala element riskklassas (Art. 6–7)
• Vilka väsentliga cybersäkerhetskrav som gäller (Art. 8)
• Principerna "secure by design" och "secure by default" (Art. 9–10)
• Kopplingen till tekniska standarder (framför allt via bilagor och harmoniserade standarder enligt EU:s standardiseringssystem)

Syftet är att flytta fokus från brandkårsutryckningar efter incidenter till inbyggd säkerhet under hela produktens livscykel.

> Kom ihåg från modul 2:

> Produkt med digitala element = en produkt som innehåller programvara eller kan kopplas till ett nätverk, och där cybersäkerhet är nödvändig för att uppfylla produktens avsedda funktion.

2. Artikel 6 – Översikt över riskkategorierna

Artikel 6 introducerar att produkter inte behandlas likadant – kraven skruvas upp med ökad risk.

Förenklat kan du tänka dig tre nivåer:

1. Basnivå – alla produkter med digitala element

• Måste uppfylla de väsentliga kraven i Art. 8–10.

1. Kritiska produkter – Klass I (lägre av de kritiska nivåerna)

• Produkter där en incident kan få allvarliga konsekvenser, t.ex. vissa utvecklingsverktyg, identitetshantering, nätverksprodukter.

1. Kritiska produkter – Klass II (högre av de kritiska nivåerna)

• Produkter som är särskilt känsliga eller systembärande, t.ex. vissa industriella styrsystem, avancerad säkerhetsprogramvara, vissa molntjänstrelaterade komponenter.

De exakta kategorierna och exemplen finns i bilagor till förordningen (särskilt bilagan om kritiska produktklasser). EU-kommissionen kan dessutom uppdatera listorna genom delegerade akter, vilket gör att fler produktkategorier kan läggas till över tid.

Varför spelar detta roll?

• Klass I och II innebär strängare bedömning av överensstämmelse (t.ex. större krav på oberoende tredje part, s.k. anmälda organ).
• Men även icke-kritiska produkter måste följa Art. 8–10.

3. Exempel: Riskklassning i praktiken (Art. 6–7)

Föreställ dig tre produkter:

1. Smart högtalare för hemmet

• Kopplad till internet, röststyrning, styrning av lampor.
• Typiskt inte kritisk klass I eller II.
• Men: måste ändå uppfylla alla generella krav i Art. 8–10 (t.ex. säker uppdatering, hantering av sårbarheter).

1. Industriell router för elnätsoperatör

• Används i kritisk infrastruktur.
• Stor påverkan om den komprometteras.
• Hög sannolikhet att denna hamnar i kritisk klass I eller II (beroende på detaljer och bilagans klassning).
• Konsekvens: strängare bedömning av överensstämmelse, mer dokumentation, ofta tredjepartsbedömning.

1. Programvara för identitets- och åtkomsthantering (IAM)

• Styr behörigheter till många system.
• Ofta listad som kritisk i bilagan (klass I eller II beroende på omfattning och användningsområde).

> Poängen: Artiklarna 6–7 handlar inte bara om etiketter, utan om vilken bevisbörda och vilka processer tillverkaren måste följa för att visa att Art. 8–10 uppfylls.

4. Tankeövning: Var skulle du placera produkten?

Fundera kort på följande produkt och skriv (för dig själv) hur du skulle resonera om riskklass:

> Produkt: En uppkopplad medicinsk övervakningsenhet för hemmet som mäter hjärtrytm och skickar data till sjukhuset.

1. Vilka typer av skador kan uppstå vid cybersäkerhetsincident (på individ, system, samhälle)?
2. Är produkten direkt kopplad till kritisk infrastruktur eller vårdinformationssystem?
3. Skulle du intuitivt placera den närmare basnivå eller kritisk klass I/II?

💡 Tips: Tänk i termer av konsekvens + sannolikhet + systemberoende. Hög konsekvens + hög systempåverkan → större sannolikhet att hamna i kritisk klass.

> Du behöver inte landa exakt rätt klass – övningen handlar om att träna risktänkandet som ligger bakom Art. 6–7.

5. Artikel 8 – Väsentliga cybersäkerhetskrav och säkerhetsmål

Artikel 8 är kärnan: den listar väsentliga cybersäkerhetskrav som alla produkter med digitala element måste uppfylla.

Förenklat kan de grupperas i följande säkerhetsmål:

1. Skydd av konfidentialitet, integritet och tillgänglighet (CIA)

• Produkten ska utformas så att data och funktioner är skyddade mot obehörig åtkomst, manipulation och otillgänglighet.

1. Motståndskraft mot attacker

• Produkten ska tåla kända typer av angrepp, inklusive basala attacker som brute force, injektionsattacker, enkel exploatering av kända sårbarheter.

1. Säker hantering av data och kommunikation

• Kryptering där det är lämpligt.
• Skydd av autentiseringsuppgifter (t.ex. lösenord, nycklar) mot exponering.

1. Säker livscykel

• Säker utveckling (inkl. säker kodningspraxis).
• Säkra uppdateringsmekanismer.
• Hantering av sårbarheter under en definierad supportperiod.

1. Dokumentation och transparens

• Användare ska få tillräcklig information om cybersäkerhetsfunktioner, begränsningar och hur de använder produkten säkert.

Detaljkraven utvecklas i bilagor till CRA och konkretiseras via harmoniserade standarder (t.ex. EN/ISO/IEC-standarder). Uppfyller du relevanta harmoniserade standarder anses du normalt uppfylla motsvarande krav i Art. 8 (s.k. presumption of conformity).

6. Artikel 9 – "Secure by design" i praktiken

Secure by design i CRA betyder att säkerhet ska vara inbyggd från början, inte påklistrad i slutet.

Centrala principer i Art. 9:

1. Säkerhet integrerad i hela utvecklingsprocessen

• Kravanalys: cybersäkerhetsrisker identifieras tidigt.
• Design: arkitekturen ska stödja separering av komponenter, minimering av attackytor, principen om minsta privilegium.
• Implementation: säker kodning, kodgranskning, statisk/dynamisk analys.
• Test: penetrationstester, fuzzing där relevant, regressionsprovning av säkerhetsfixar.

1. Livscykelperspektiv

• Tillverkaren ska planera för uppdateringar och sårbarhetshantering under produktens förväntade livslängd.

1. Dokumenterad riskanalys

• Det ska finnas teknisk dokumentation som visar hur säkerhetskraven har beaktats.

> Nyckelidé: Secure by design i CRA är nära kopplat till etablerade ramverk som t.ex. "security by design"-principerna i ISO/IEC 27034 och utvecklingspraxis i DevSecOps.

7. Artikel 10 – "Secure by default" med konkreta exempel

Secure by default betyder att produkten är säkert konfigurerad från start, utan att användaren behöver vara expert.

Typiska krav och exempel:

1. Inga osäkra standardlösenord

• Otillåtet: Alla enheter levereras med användarnamn `admin` / lösenord `admin`.
• Enligt CRA: Enheten kräver att användaren sätter ett unikt starkt lösenord vid första uppstart, eller använder säkra, unika fabrikshemligheter.

1. Minimerade behörigheter som standard

• Otillåtet: Alla användare har admin-rättigheter efter installation.
• Enligt CRA: Standardkontot har begränsade rättigheter, admin-funktioner kräver aktiv uppgradering och stark autentisering.

1. Säker kommunikation aktiverad som standard

• Otillåtet: Oskyddad HTTP som standard, användaren måste själv slå på HTTPS.
• Enligt CRA: Produkten använder TLS eller likvärdig kryptering som standard.

1. Endast nödvändiga tjänster aktiva

• Otillåtet: Flera oanvända debug-portar och tjänster öppna.
• Enligt CRA: Endast funktioner som behövs för den avsedda användningen är aktiverade.

> Sammanfattning: Secure by default handlar om att minimera risk utan extra klick, även för icke-experter.

8. Snabbkontroll: Secure by design vs. secure by default

Testa om du kan skilja på begreppen.

9. Koppling till tekniska standarder och harmoniserade normer

Cyberresiliensförordningen anger vad som ska uppnås (säkerhetsmål) – inte alltid exakt hur. Det hur:et fylls i stor utsträckning av harmoniserade standarder.

Nyckelpoänger:

• Harmoniserade standarder antas på EU-nivå (CEN/CENELEC/ETSI) efter begäran från kommissionen.
• Om en tillverkare följer relevanta harmoniserade standarder får den presumtion om överensstämmelse med motsvarande krav i Art. 8–10.
• Exempel på standarder som ofta är relevanta (exakta hänvisningar kan uppdateras över tid):
• EN ISO/IEC 27001 (informationssäkerhet – ledningssystem)
• EN ISO/IEC 27002 (kontroller och god praxis)
• EN ISO/IEC 62443 (industriella styrsystem, OT-säkerhet)
• EN IEC 62443-4-1/4-2 (säker utveckling och tekniska krav för komponenter)
• Standarder för säker programvaruutveckling, kryptografi, sårbarhetshantering m.m.

> I praktiken: Tillverkare kommer ofta att kombinera CRA-krav + harmoniserade standarder + interna policies för att bygga ett sammanhängande cybersäkerhetsramverk.

> Viktigt per mars 2026: Flera detaljerade harmoniserade standarder specifikt kopplade till CRA är under framtagande/uppdatering. När de publiceras i EU:s officiella tidning blir de centrala referenser för överensstämmelse.

10. Mini-workshop: Översätt krav till utvecklingsaktiviteter

Välj en enkel produkt i din vardag, t.ex. en uppkopplad skrivare eller en smart glödlampa.

Skriv (för dig själv) tre korta punkter:

1. Secure by design – Vad skulle du kräva av utvecklingsteamet?

• Exempel: hotmodellering, säkra uppdateringsmekanismer, segmenterad firmware-arkitektur.

1. Secure by default – Vilka inställningar ska vara säkra direkt ur kartongen?

• Exempel: krypterad kommunikation, inga öppna telnet-portar, krav på lösenordsbyte.

1. Standarder – Vilken typ av standarder tror du är relevanta?

• Exempel: generell informationssäkerhetsstandard (typ ISO 27001), produkt-/domänspecifika standarder.

> Målet är inte att ha ett perfekt svar, utan att träna på att översätta abstrakta krav (Art. 8–10) till konkreta aktiviteter.

11. Repetitionskort: Nyckelbegrepp från Art. 6–10

Använd korten för att repetera de centrala begreppen innan du går vidare till nästa modul.