Cyber Resilience Act (CRA): Nye sikkerhetskrav for all programvare i EU/EØS

Cyber Resilience Act (CRA) er EUs nye forordning som innfører obligatoriske cybersikkerhetskrav for alle produkter med digitale elementer som selges i EU/EØS — inkludert programvare og IoT-enheter. Kravene omfatter SBOM, CE-merking og secure by design. Rapporteringsplikt for sårbarheter starter 11. september 2026, og full etterlevelse kreves fra 11. desember 2027.

CRA representerer et paradigmeskifte for programvareindustrien. For første gang blir cybersikkerhet et lovpålagt produktkrav — på linje med fysisk sikkerhet og elektromagnetisk kompatibilitet. For norske programvareutviklere, produsenter og distributører betyr dette nye forpliktelser som krever forberedelse allerede nå.

I denne artikkelen gir vi en komplett oversikt over hva CRA innebærer, hvem som rammes, hvilke krav som stilles, og konkrete tiltak du bør iverksette.

Hva er Cyber Resilience Act?

Cyber Resilience Act (CRA) er en EU-forordning vedtatt i oktober 2024 som stiller horisontale cybersikkerhetskrav til alle produkter med digitale elementer som gjøres tilgjengelig på det indre markedet. Med «produkter med digitale elementer» menes ethvert programvare- eller maskinvareprodukt og tilhørende fjerndatabehandlingsløsninger, inkludert programvarekomponenter som gjøres tilgjengelig separat.

Dette betyr at CRA rammer et enormt spekter — fra IoT-enheter som smarte lyspærer og industrielle sensorer, via operativsystemer og nettlesere, til spesialiserte bedriftsløsninger og skybaserte tjenester med tilhørende klientprogramvare. Forordningen gjelder direkte i hele EU, og vil gjennomføres i norsk rett gjennom EØS-avtalen.

CRA skiller seg fra direktiver som NIS2 ved at den retter seg mot produktene selv, ikke virksomhetene som bruker dem. Målet er å sikre at alle digitale produkter på markedet oppfyller et minimumsnivå av cybersikkerhet gjennom hele livssyklusen.

Bakgrunn: Hvorfor CRA?

De siste årene har cyberangrep rettet mot programvareforsyningskjeder eksplodert i omfang og alvorlighetsgrad. Hendelser som SolarWinds-angrepet i 2020, Log4Shell-sårbarheten i 2021 og MOVEit-angrepet i 2023 viste hvordan en enkelt sårbarhet i en programvarekomponent kan ramme tusenvis av organisasjoner globalt.

EU-kommisjonen identifiserte tre grunnleggende problemer som CRA skal løse:

Lavt cybersikkerhetsnivå i produkter. Mange digitale produkter lanseres med kjente sårbarheter og uten forpliktelse til å levere sikkerhetsoppdateringer. Produsenter har hatt få insentiver til å investere i sikkerhet etter lansering.

Mangel på informasjon for brukere. Forbrukere og virksomheter har hatt liten mulighet til å vurdere cybersikkerheten til produktene de kjøper. Det har ikke eksistert et felles rammeverk for å sammenligne sikkerhetsnivået.

Fragmentert regulering. Ulike sektorer har hatt ulike krav, og mange produktkategorier har manglet cybersikkerhetskrav helt. CRA etablerer et enhetlig, horisontalt rammeverk som dekker alle digitale produkter.

Estimater fra EU-kommisjonen anslår at cyberangrep kostet den globale økonomien over 5,5 billioner euro i 2023. CRA er EUs svar på å bryte den onde sirkelen der usikre produkter slippes på markedet uten konsekvenser for produsenten.

Tidslinje: Viktige datoer

CRA trer i kraft gradvis med tre sentrale milepæler:

• Oktober 2024: CRA vedtas formelt av EU og publiseres i Official Journal
• 11. juni 2026: Regler for samsvarsvurderingsorganer (notified bodies) trer i kraft
• 11. september 2026: Rapporteringsplikt for aktivt utnyttede sårbarheter trer i kraft — produsenter må varsle ENISA/nasjonale myndigheter innen 24 timer
• 11. desember 2027: Full anvendelse — alle krav til produkter med digitale elementer gjelder fullt ut, inkludert CE-merking, SBOM og secure by design
• 2027–2028: Forventet innlemmelse i EØS-avtalen og gjennomføring i norsk rett

For norske virksomheter er det kritisk å merke seg at rapporteringsplikten for sårbarheter starter allerede i september 2026. Selv om full etterlevelse ikke kreves før desember 2027, bør forberedelsene starte umiddelbart.

Hvem rammes av CRA?

CRA pålegger forpliktelser til alle økonomiske aktører i verdikjeden for digitale produkter. Forordningen skiller mellom tre roller med ulike ansvarsområder:

Rolle	Hvem er dette?	Hovedforpliktelser
Produsent (manufacturer)	Den som utvikler eller produserer produktet med digitale elementer, og markedsfører det under eget navn	Gjennomføre risikovurdering, sikre at produktet oppfyller sikkerhetskravene, levere SBOM, utføre samsvarsvurdering, CE-merke produktet, levere sikkerhetsoppdateringer i hele produktets levetid, rapportere aktivt utnyttede sårbarheter innen 24 timer
Importør	Den som bringer et produkt fra en ikke-EU-produsent inn på EU/EØS-markedet	Verifisere at produsenten har gjennomført samsvarsvurdering og CE-merking, sikre at produsentens dokumentasjon er tilgjengelig, ikke bringe produkter på markedet som ikke oppfyller kravene
Distributør	Den som gjør produktet tilgjengelig på markedet uten å endre det	Verifisere CE-merking og samsvarserklæring, sikre at produktet ikke har kjente sårbarheter som ikke er adressert, varsle tilsynsmyndigheter om produkter som ikke oppfyller kravene

Hvem er «produsent» i praksis?

Definisjonen av produsent er bred og fanger opp de fleste norske programvareselskaper. Hvis du utvikler programvare — enten det er en mobilapp, en SaaS-plattform, en desktop-applikasjon eller en firmware-oppdatering — og gjør den tilgjengelig på EU/EØS-markedet (også gratis), er du sannsynligvis en produsent under CRA.

Hva med åpen kildekode?

CRA inneholder et viktig unntak for åpen kildekode-programvare som utvikles og deles uten kommersiell aktivitet. Men vær oppmerksom: hvis du bruker åpen kildekode i et kommersielt produkt, er du som produsent ansvarlig for å sikre at disse komponentene oppfyller CRA-kravene. Og hvis et open source-prosjekt drives av en kommersiell virksomhet — for eksempel med betalt support, hosting eller premium-funksjoner — kan prosjektet selv falle inn under CRA.

CRA introduserer også konseptet «open-source software steward» for organisasjoner som systematisk støtter utviklingen av åpen kildekode beregnet for kommersiell bruk. Disse får lettere forpliktelser, men må likevel ha sikkerhetspolicyer og samarbeide med myndigheter ved sårbarhetsrapportering.

Hva kreves? Sentrale forpliktelser

CRA stiller omfattende krav til produkter med digitale elementer. Her er de viktigste:

Krav	Beskrivelse	Frist
Risikovurdering	Dokumentert cybersikkerhetsrisikovurdering gjennom hele produktets livssyklus	Des. 2027
Secure by design	Produkter skal designes, utvikles og produseres med sikkerhet innebygd fra starten	Des. 2027
Minimering av angrepsflate	Produkter skal leveres med en sikker standardkonfigurasjon og minimal angrepsflate	Des. 2027
Sårbarhetshåndtering	Produsenter må identifisere, dokumentere og utbedre sårbarheter gjennom hele produktets levetid	Des. 2027
Sikkerhetsoppdateringer	Gratis sikkerhetsoppdateringer i minimum 5 år eller produktets forventede levetid	Des. 2027
SBOM	Software Bill of Materials — maskinlesbar oversikt over alle komponenter og avhengigheter	Des. 2027
Samsvarsvurdering	Produsenten må gjennomføre en samsvarsvurdering (egenvurdering eller tredjepartsvurdering)	Des. 2027
CE-merking	Produktet må CE-merkes for å vise samsvar med CRA-kravene	Des. 2027
Teknisk dokumentasjon	Komplett teknisk dokumentasjon som dekker design, utvikling og samsvarsvurdering	Des. 2027
Sårbarhetsrapportering	Aktivt utnyttede sårbarheter må rapporteres til ENISA/nasjonal myndighet innen 24 timer	Sep. 2026

Produktkategorier og samsvarsvurdering

CRA deler produkter inn i tre kategorier basert på kritikalitet:

• Standard (default): De fleste produkter. Produsenten kan gjennomføre egenvurdering av samsvar (modul A)
• Viktige produkter, klasse I: Identitetshåndtering, nettlesere, passordforvaltere, VPN-er, nettverksadministrasjon, SIEM-systemer med flere. Kan bruke harmoniserte standarder for egenvurdering, ellers kreves tredjepartsvurdering
• Viktige produkter, klasse II: Operativsystemer, hypervisorer, mikrokontrollere, industrielle kontrollsystemer, brannmurer med flere. Krever obligatorisk tredjepartsvurdering
• Kritiske produkter: Smartkort, HSM-er, smartmålere og lignende. Krever europeisk cybersikkerhetssertifisering

SBOM: Software Bill of Materials

En av de mest konkrete og transformative kravene i CRA er påbudet om Software Bill of Materials (SBOM). Men hva er egentlig en SBOM, og hvorfor er den så viktig?

Hva er en SBOM?

En SBOM er en formell, maskinlesbar oversikt over alle programvarekomponenter og avhengigheter som inngår i et produkt. Tenk på det som en ingrediensliste for programvare. Akkurat som en matprodusent må oppgi alle ingredienser på pakningen, må en programvareprodusent under CRA dokumentere alle biblioteker, rammeverk og tredjepartskomponenter som produktet inneholder.

Hvorfor krever CRA en SBOM?

Log4Shell-sårbarheten i desember 2021 illustrerer behovet perfekt. Log4j var en utbredt Java-komponent som var innebygd i tusenvis av produkter. Da den kritiske sårbarheten ble oppdaget, hadde de fleste virksomheter ingen oversikt over hvor Log4j var i bruk. Det tok uker — i noen tilfeller måneder — bare å kartlegge omfanget. Med en SBOM på plass kan du umiddelbart identifisere om en sårbar komponent finnes i dine produkter.

Hva må en SBOM inneholde?

CRA krever at SBOM-en som minimum dekker de øverste avhengighetene i produktet. I praksis bør en robust SBOM inneholde:

• Navn og versjon på alle programvarekomponenter
• Lisensvilkår for hver komponent
• Leverandør eller opphav for komponenten
• Unike identifikatorer (f.eks. CPE eller Package URL)
• Avhengighetstreet som viser relasjoner mellom komponenter

Vanlige formater er CycloneDX og SPDX, begge støttet av bredt verktøy i utviklerøkosystemet.

Hvordan kommer du i gang med SBOM?

For de fleste moderne utviklingsprosjekter kan SBOM-generering automatiseres direkte i CI/CD-pipelinen. Verktøy som Syft, Trivy og CycloneDX CLI kan generere SBOM-er fra eksisterende prosjekter. Det viktigste er å starte tidlig — retroaktiv SBOM-generering for komplekse systemer er vesentlig mer krevende.

Secure by design: Sikkerhet fra første kodelinje

CRA formaliserer prinsippet «secure by design» som et lovkrav. Dette betyr at sikkerhet ikke kan behandles som en ettertanke eller et tillegg — det må være en integrert del av produktutviklingen fra arkitektur til levering.

Hva innebærer secure by design i praksis?

CRA stiller konkrete krav til hvordan produkter skal designes og leveres:

• Sikker standardkonfigurasjon: Produkter skal leveres med sikre standardinnstillinger. Brukeren skal ikke måtte aktivere sikkerhet — den skal være på som standard
• Minimering av angrepsflate: Unødvendige porter, tjenester og grensesnitt skal være deaktivert som standard
• Forsvarlig autentisering: Standardpassord og forutsigbare legitimasjonsdata er ikke tillatt. Unike, sterke initiell-legitimasjonsdata kreves
• Kryptografisk beskyttelse: Data i transit og data i hvile skal beskyttes med oppdaterte kryptografiske mekanismer
• Integritetsbeskyttelse: Mekanismer for å sikre at produktets programvare og konfigurasjonsdata ikke er uautorisert endret
• Tilgjengelighetsbeskyttelse: Produkter skal være motstandsdyktige mot tjenestenektangrep og overdreven ressursbruk

For utviklingsteam betyr dette at sikkerhetsgjennomganger, trusselmodellering og sikker koding må bli en naturlig del av utviklingsprosessen — ikke noe som gjøres i etterkant av en penetrasjonstest.

CE-merking av programvare

For første gang i historien vil programvare trenge CE-merking for cybersikkerhet. CE-merket — som de fleste kjenner fra fysiske produkter som elektronikk og leker — vil nå også signalisere at et digitalt produkt oppfyller EUs cybersikkerhetskrav.

Hva betyr CE-merking for programvare?

CE-merking under CRA innebærer at produsenten erklærer at produktet oppfyller de grunnleggende cybersikkerhetskravene i forordningen. For å kunne CE-merke produktet må produsenten:

1. Gjennomføre en dokumentert risikovurdering
2. Sikre at produktet oppfyller alle relevante sikkerhetskrav
3. Utarbeide teknisk dokumentasjon
4. Gjennomføre samsvarsvurdering (egenvurdering eller tredjepartsvurdering, avhengig av produktkategori)
5. Utstede en EU-samsvarserklæring
6. Påføre CE-merket på produktet eller dets dokumentasjon

For programvare som ikke har fysisk emballasje, kan CE-merket vises i produktets digitale dokumentasjon, brukergrensesnitt eller nedlastingsside.

Konsekvenser for markedsadgang

Etter 11. desember 2027 vil produkter med digitale elementer uten CE-merking ikke kunne selges lovlig på EU/EØS-markedet. Dette betyr at CRA-compliance ikke er valgfritt — det er en forutsetning for markedsadgang.

Sanksjoner og bøter

CRA innfører et betydelig sanksjonsregime som gir tilsynsmyndighetene sterke verktøy for å håndheve kravene:

Bruddtype	Maksimal bot	Alternativ beregning
Brudd på grunnleggende sikkerhetskrav og sårbarhetshåndtering	15 millioner EUR	2,5 % av global omsetning (det høyeste beløpet gjelder)
Brudd på øvrige forpliktelser	10 millioner EUR	2 % av global omsetning (det høyeste beløpet gjelder)
Feilinformasjon til tilsynsmyndigheter	5 millioner EUR	1 % av global omsetning (det høyeste beløpet gjelder)

I tillegg til bøter kan tilsynsmyndighetene:

• Pålegge tilbaketrekking av produkter fra markedet
• Kreve korrigerende tiltak med bindende frister
• Forby eller begrense tilgjengeliggjøring av produkter
• Ilegge tvangsmulkt ved manglende etterlevelse

I Norge vil Nasjonal kommunikasjonsmyndighet (Nkom) ha tilsynsansvar for CRA. Nkom har allerede erfaring med markedstilsyn for elektroniske produkter og vil utvide dette til å dekke cybersikkerhetskravene i CRA.

For SMB-er gjelder proporsjonalt lavere bøter, men de er fortsatt betydelige nok til å true virksomhetens eksistens. Det er viktig å merke seg at bøter kan ilegges ikke bare for usikre produkter, men også for manglende dokumentasjon, manglende sårbarhetsrapportering eller utilstrekkelig samsvarsvurdering.

Praktiske tiltak: Slik forbereder din bedrift seg

Uansett om du utvikler programvare, importerer digitale produkter eller distribuerer teknologiløsninger, bør du starte forberedelsene nå. Her er en faseinndelt tilnærming:

Fase 1: Kartlegging og analyse (nå – september 2026)

• Kartlegg alle produkter med digitale elementer du produserer, importerer eller distribuerer
• Klassifiser hvert produkt etter CRA-kategorien (standard, viktig klasse I/II, kritisk)
• Identifiser din rolle i verdikjeden for hvert produkt (produsent, importør, distributør)
• Gjennomfør en GAP-analyse mot CRA-kravene for hvert produkt
• Kartlegg alle tredjepartskomponenter og avhengigheter i produktene dine
• Vurder om open source-komponenter du bruker kan medføre CRA-forpliktelser
• Etabler prosedyrer for sårbarhetsrapportering (påkrevd fra september 2026)

Fase 2: Implementering (september 2026 – desember 2027)

• Implementer SBOM-generering i CI/CD-pipelinen for alle produkter
• Integrer automatisert sårbarhetsskanning i utviklingsløpet
• Etabler prosesser for secure by design — trusselmodellering, sikker koding, sikkerhetsgjennomgang
• Utarbeid teknisk dokumentasjon som oppfyller CRA-kravene
• Gjennomfør risikovurdering for hvert produkt
• Etabler rutiner for levering av sikkerhetsoppdateringer gjennom produktets levetid
• Forbered samsvarsvurdering (egenvurdering eller planlegg tredjepartsvurdering)
• Oppdater kontrakter med leverandører for å sikre CRA-samsvar i hele verdikjeden

Fase 3: Samsvar og vedlikehold (desember 2027 og løpende)

• Gjennomfør samsvarsvurdering og CE-merk alle produkter
• Utstede EU-samsvarserklæring for hvert produkt
• Etabler kontinuerlig sårbarhetshåndtering og oppdateringsprogram
• Gjennomfør regelmessige revisjoner av SBOM og avhengigheter
• Hold teknisk dokumentasjon oppdatert ved alle produktendringer
• Overvåk regulatoriske oppdateringer og harmoniserte standarder
• Gjennomfør periodiske sikkerhetsrevisjoner og penetrasjonstester

Hvordan henger CRA sammen med NIS2 og KI-loven?

CRA er del av en større regulatorisk bølge fra EU. Sammen med NIS2-direktivet og KI-loven (EU AI Act) danner CRA et helhetlig rammeverk for digital sikkerhet og tillit:

• CRA regulerer produktene — sikrer at digitale produkter er sikre fra design til livsslutt
• NIS2 regulerer virksomhetene — sikrer at kritiske virksomheter har tilstrekkelig cybersikkerhet
• KI-loven regulerer KI-systemene — sikrer at kunstig intelligens brukes trygt og ansvarlig

For IT-leverandører i finanssektoren bør du også sette deg inn i DORA, som stiller egne krav til digital motstandskraft. Og med EU Data Act kommer det i tillegg nye regler for datadeling og skyportabilitet.

For virksomheter som rammes av flere av disse regelverkene, er det klokt å ta en helhetlig tilnærming til compliance. Mange av tiltakene — som risikovurdering, dokumentasjon, hendelseshåndtering og forsyningskjedesikkerhet — overlapper.

Slik kan vi hjelpe

I UNOS SOFTWARE AS bygger vi programvare med sikkerhet som en kjerneverdi, og vi hjelper norske bedrifter med å navigere det stadig mer komplekse regulatoriske landskapet. Sammen med vår samarbeidspartner Unos IT AS tilbyr vi et komplett tjenestetilbud som dekker alt fra utvikling til drift. Vi tilbyr:

• Sikker programvareutvikling med CRA-compliance innebygd — gjennom vår programvareutviklingstjeneste bygger vi løsninger med secure by design-prinsipper, automatisert SBOM-generering og sårbarhetshåndtering integrert i utviklingsløpet
• Teknisk rådgivning om CRA-forberedelser — vår rådgivningstjeneste hjelper deg med GAP-analyser, produktklassifisering, SBOM-strategi og forberedelse til samsvarsvurdering
• Systemintegrasjon og modernisering — gjennom vår integrasjonstjeneste hjelper vi deg med å integrere sikkerhetsverktøy, automatisere SBOM-generering og bygge robuste CI/CD-pipelines som støtter CRA-compliance
• Sikker skyinfrastruktur — vår sky- og infrastrukturtjeneste sikrer at infrastrukturen din er bygd for å levere sikkerhetsoppdateringer effektivt og oppfylle CRA-kravene til kontinuerlig sårbarhetshåndtering

CRA er ikke bare et regulatorisk krav — det er en mulighet til å heve kvaliteten på programvaren din, redusere sikkerhetsrisikoen og bygge varig tillit hos kundene dine.

Er du usikker på hvordan CRA påvirker dine produkter? Ta kontakt for en uforpliktende samtale om dine CRA-forberedelser og compliance-behov.

Vanlige spørsmål om Cyber Resilience Act

Gjelder CRA for SaaS-programvare?

Ja, i de fleste tilfeller. Programvare som gjøres tilgjengelig på EU/EØS-markedet — inkludert SaaS-løsninger med tilhørende klientprogramvare — omfattes av CRA. Rene skybaserte tjenester uten lokal programvarekomponent kan falle utenfor, men grensene er fortsatt under avklaring.

Når starter rapporteringsplikten for sårbarheter?

Rapporteringsplikt for aktivt utnyttede sårbarheter starter 11. september 2026. Produsenter må varsle ENISA og nasjonale myndigheter innen 24 timer etter at de blir kjent med at en sårbarhet utnyttes aktivt.

Hva er forskjellen mellom CRA og NIS2?

CRA regulerer produktene — den stiller sikkerhetskrav til digitale produkter som selges på markedet. NIS2 regulerer virksomhetene — den stiller sikkerhetskrav til virksomheter i kritiske sektorer. En virksomhet kan være underlagt begge regelverk.

Må jeg ha SBOM for eksisterende produkter?

Ja, fra 11. desember 2027 må alle produkter med digitale elementer som er på markedet ha en oppdatert SBOM. Retroaktiv SBOM-generering kan være krevende for eldre systemer, så det er viktig å starte tidlig.

Hva skjer om jeg ikke overholder CRA innen fristen?

Bøter kan bli opptil 15 millioner euro eller 2,5 prosent av global omsetning. I tillegg kan tilsynsmyndighetene kreve tilbaketrekking av produkter fra markedet eller forby salg inntil kravene er oppfylt.

---

Kilder og videre lesning

• Europaparlamentet (2024). «Regulation (EU) 2024/2847 — Cyber Resilience Act.» eur-lex.europa.eu
• EU-kommisjonen (2025). «Cyber Resilience Act — Factsheet and Implementation Guidance.» digital-strategy.ec.europa.eu
• Nasjonal kommunikasjonsmyndighet (2025). «CRA og tilsyn med cybersikkerhet i digitale produkter.» nkom.no
• ENISA (2025). «Cyber Resilience Act — Guidelines for Manufacturers.» enisa.europa.eu
• Regjeringen (2025). «EØS-gjennomføring av Cyber Resilience Act.» regjeringen.no
• NSM (2025). «Sikkerhet i programvareforsyningskjeden — anbefalinger for norske virksomheter.» nsm.no
• NTIA (2025). «Software Bill of Materials — Minimum Elements and Guidance.» ntia.gov

---

Ta kontakt med oss

Trenger du hjelp med CRA-forberedelser, SBOM-strategi eller sikker programvareutvikling? UNOS SOFTWARE AS — i samarbeid med Unos IT AS — hjelper norske bedrifter med å navigere de nye kravene. Send oss en henvendelse gjennom kontaktskjemaet — vi tar en uforpliktende samtale om hvordan vi kan hjelpe din virksomhet med CRA-compliance.