Cyber Resilience Act: berör det ert företag?

Fick ni ett mejl om CRA? Det är oftast inte er webbplats det handlar om

Om ni har läst en varning eller fått ett mejl om EU:s Cyber Resilience Act (CRA) kan det låta som att varje företag med en webbplats nu måste agera. För de flesta stämmer det inte. För några gör det det, och då är det bra att veta det innan ni skriver ett avtal.

De flesta av våra kunder har en vanlig företagswebbplats, och sådana berörs normalt inte av CRA. Det är först när ni säljer en app, en uppkopplad produkt eller programvara, eller låter bygga ett eget system under ert namn, som lagen kan bli ert ansvar. Det här inlägget reder ut vem lagen gäller och vilka fyra frågor ni bör ställa. Det är inte juridisk rådgivning.

Vad är Cyber Resilience Act, och vad hände den 11 september?

Lagen i en mening: cybersäkerhet i produkter med digitala delar

CRA (förordning (EU) 2024/2847) ställer krav på cybersäkerhet i produkter med digitala delar. Det är hårdvara och programvara som är uppkopplade mot en enhet eller ett nätverk och som tillhandahålls i kommersiell verksamhet på EU-marknaden. Det kan vara en app, en smart enhet eller ett program som kunden installerar, och det spelar ingen roll var tillverkaren sitter. Läs gärna den officiella sammanfattningen från EU-kommissionen.

Två datum: rapportering sedan 11 september 2026, huvudkrav 11 december 2027

Lagen trädde i kraft den 10 december 2024. Rapporteringskraven gäller från 11 september 2026 och huvudkraven från 11 december 2027. Sedan 11 september måste tillverkare rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar säkerheten i produkter med digitala delar. Tidsgränserna enligt kommissionens sida om rapportering är:

• En tidig varning inom 24 timmar efter att tillverkaren fått kännedom.
• En fullständig anmälan inom 72 timmar.
• En slutrapport senast 14 dagar efter att en rättelse finns för en sårbarhet.
• För allvarliga incidenter ska slutrapporten lämnas inom en månad efter 72-timmarsanmälan.

Rapporteringen sker via ENISA:s gemensamma rapporteringsplattform (Single Reporting Platform), och rapporterna går till ENISA och till landets nationella CSIRT. Kravet gäller alla produkter med digitala delar på EU-marknaden, även sådana som lanserades före 11 september 2026. Att produkten är gammal ger alltså inget undantag, vilket bland annat förklaras i den här guiden om artikel 14.

Huvudkraven från 2027 omfattar enligt en sammanfattning från en tredje part bland annat säker utveckling, hantering av sårbarheter, teknisk dokumentation, CE-märkning och en supportperiod som ofta är minst fem år. Programvarulista (SBOM) nämns som ett verktyg i sårbarhetshanteringen. Eftersom det är en sammanfattning bör detaljerna kontrolleras mot förordningstexten.

Kommissionens vägledning från 27 juli 2026

Kommissionen publicerade sin första officiella vägledning den 27 juli 2026 (C(2026) 5252). Den är icke bindande men visar hur myndigheterna förväntas tolka lagen, bland annat när en produkt omfattas, vad som är en väsentlig ändring och hur supportperioder och rapportering ska tillämpas. Enligt en genomgång av vägledningen är den skriven med små företag i åtanke, har 84 sidor och 67 exempel, flödesscheman och användningsfall, och flyttar inga datum.

En enkel tumregel utifrån vägledningen: en ren webbplats hamnar utanför, medan en molnbackend som en produkt är beroende av kan hamna innanför.

Vem lagen gäller och vem den inte gäller

Troligen utanför: vanliga företagswebbplatser och rena webbtjänster

Webbplatser som inte stöder funktionen i en produkt med digitala delar omfattas inte av förordningen. Det framgår av förordningens ingress, som finns återgiven här. En vanlig företagswebbplats som bara presenterar verksamheten är alltså normalt utanför.

Ren SaaS, alltså en tjänst som används i webbläsaren och inte installeras, ligger också normalt utanför. Det ändras i vissa fall, som vi kommer till nedan.

Troligen innanför: appar, uppkopplade produkter och programvara som ni säljer

En nedladdningsbar app eller ett installerat klientprogram är alltid en produkt. Det gäller även en smart enhet eller ett program som ni tillhandahåller kunder i kommersiell verksamhet.

Tillverkare är den som marknadsför produkten under eget namn eller varumärke, även om någon annan har skrivit koden. Den som beställer en app och publicerar den under sitt eget varumärke är alltså tillverkare, och att anlita en leverantör flyttar inte det lagstadgade ansvaret. Det beskrivs bland annat i den här artikeln om specialutvecklad programvara.

Gränsfall: beställda system, öppen källkod och molnbackend

Molnbackend: ren SaaS ändras om molndelen är utvecklad av tillverkaren och produkten inte fungerar utan den, så kallad fjärrbehandling av data. Det gäller till exempel backend till en app. Det förklaras i den här genomgången av vanliga CRA-frågor.

Beställda system: om ni bara använder systemet internt och inte marknadsför något under eget namn är det oklart vem som är tillverkare. En källa menar att det då oftast är leverantören, men frågan är inte slutligt avgjord. Programvara som bara används internt och aldrig tillhandahålls andra räknas inte som utsläppt på marknaden. Källorna är dock oeniga om specialbyggd programvara åt en enda kund, som den här sammanställningen visar. Vi ger därför inget färdigt svar här, och i sådana fall rekommenderar vi en jurist.

Öppen källkod: fri programvara med öppen källkod som tillhandahålls utanför kommersiell verksamhet är undantagen. När sådan kod byggs in i en kommersiell produkt tar produktens tillverkare ansvar för komponenterna, något som Jama Software beskriver. Det är relevant om ni bygger på WordPress-plugin, bibliotek eller ramverk i en produkt som ni säljer.

Fyra frågor att ställa: tillverkare, rapportering, uppdateringar och kod

Vi råder er att ställa frågorna redan i avtalet. Vid specialbyggd programvara för en bestämd företagsanvändare kan parterna nämligen uttryckligen avtala om undantag från två krav: säker standardkonfiguration och kostnadsfria säkerhetsuppdateringar. Det beskriver advokatbyrån Greenberg Traurig, och det är därför avtalet spelar roll. Det här är en praktisk checklista och inte juridisk rådgivning.

Vem är tillverkare, och räcker det att någon annan skrivit koden?

Nej, det räcker inte. Om produkten säljs under ert namn eller varumärke är ni tillverkare, även om en leverantör skrivit varje rad kod. Fråga därför rakt ut: vem är tillverkare enligt lagen, och står det i avtalet?

Vem rapporterar inom 24 timmar?

En första varning ska skickas inom 24 timmar efter att tillverkaren fått kännedom om en utnyttjad sårbarhet. Fråga vem som upptäcker och rapporterar, och vem som har kontakten med myndigheterna. Om svaret är att ingen vet, saknar ni en person som kan agera i tid.

Hur och hur länge uppdateras systemet?

Fråga hur och hur länge säkerhetsuppdateringar levereras, och vem som betalar. Eftersom huvudkraven bland annat rör en supportperiod som ofta är minst fem år bör ni inte nöja er med ett muntligt löfte. Se också till att avtalet inte tyst avtalar bort uppdateringar som ni sedan måste ordna själva.

Vem äger koden?

Det här är vår tydligaste rekommendation: kräv att ni äger er kod, och att ni får den om samarbetet tar slut. Utan koden kan ni varken uppdatera, byta leverantör eller rätta en sårbarhet själva. Fråga också vilka komponenter med öppen källkod som ingår och vem som följer upp dem.

Vanliga misstag och vad som står på spel

Fem misstag vi ser framför oss

Det mesta här följer av källorna ovan, men urvalet är vår egen bedömning.

1. Att tro att företaget är undantaget för att det är litet.
2. Att tro att en leverantör som skrivit koden automatiskt tar hela ansvaret.
3. Att anta att molnet är utanför, när appen inte fungerar utan det.
4. Att glömma att tredjepartskomponenter och plugin ingår i ansvaret.
5. Att missa att reglerna gäller redan sålda produkter, och att sakna en person som kan agera inom 24 timmar.

Böter och myndigheter

Sanktionsavgifterna kan nå 15 miljoner euro eller 2,5 procent av den globala årsomsättningen, det högsta av beloppen. Den nivån gäller brott mot tillverkarens skyldigheter i artikel 13 och 14 samt de grundläggande säkerhetskraven, enligt Finite State. Källorna är dock oeniga om när böterna kan tillämpas: en källa hävdar att artikel 64 om sanktioner bara gäller från 11 december 2027 och att advokatbyråer tolkat det olika. Vi påstår därför inte att böter redan delas ut, och förordningstexten bör kontrolleras.

I Sverige föreslog utredningen SOU 2025:115 att Post- och telestyrelsen (PTS) ska vara marknadskontrollmyndighet. CERT-SE, Sveriges nationella CSIRT, ingår sedan 1 juli 2026 i Nationellt cybersäkerhetscenter (NCSC), enligt en sekundär källa. Kontrollera myndigheternas roller hos regeringen eller PTS innan ni fattar beslut.

Det här tar ni med er

• En vanlig företagswebbplats som bara presenterar verksamheten berörs normalt inte av CRA.
• En app, en uppkopplad produkt eller programvara som ni säljer under ert namn kan göra er till tillverkare.
• Att en leverantör skrivit koden flyttar inte ansvaret.
• Fråga om tillverkare, rapportering inom 24 timmar, uppdateringar och kodägande innan avtalet skrivs.
• Kräv att ni äger er kod, och att ni får den om samarbetet tar slut.
• Vid gränsfall, som beställda system, ska en jurist svara. Det här inlägget är inte juridisk rådgivning.

Osäker på om ni berörs? Fråga oss innan ni skriver avtal

Vi går gärna igenom era frågor och säger hellre nej till säkerhetstjänster ni inte behöver än säljer er något i onödan. För juridiska gränsfall rekommenderar vi en jurist. Hör av er via vår kontaktsida om ni vill ha en second opinion på ett avtal eller ett system.