Varför obegränsade revideringar?

För att ett bra resultat inte alltid uppstår första gången, och det vet vi om. Vi är noggranna med vilka vi jobbar med. Inte för att vara svåra, utan för att det är enda sättet att ge varje kund den tid och det engagemang de förtjänar. När vi väl tar på oss ett projekt så är vi där, helt och fullt. Obegränsade revideringar finns inte för att vi räknar med att misslyckas. Det finns för att vi bryr oss tillräckligt för att alltid ta oss dit vi behöver komma, tillsammans med dig.

Vad kan jag skicka till er?

Allt. Landningssidor, sektioner, applikationer, animationer, buggar, arbetsflöden, marknadsföring, SEO, kampanjer etc. Är det online så kan vi fixa eller bygga det.

Kan jag pausa eller avbryta?

Ja. Why not? Pausa tills nästa månad. Du betalar aldrig för tid du inte använder.

Om jag inte är nöjd?

Vi kör på tills du är det. Inga extra kostnader, ingen attityd.

12 augusti 20266 min läsning

CyberResilienceAct:rapporteringskravenbörjargälladen11september2026

NIS2 handlar om organisationer och hur de sköter sin säkerhet. Cyber Resilience Act, CRA, handlar om produkter. Den som utvecklar och säljer mjukvara, appar, plugins, firmware eller uppkopplade prylar i EU kommer att behöva förhålla sig till den, och det första datumet ligger bara några veckor bort.

Från och med den 11 september 2026 gäller rapporteringsskyldigheten i artikel 14: aktivt utnyttjade sårbarheter och allvarliga säkerhetsincidenter i era produkter ska rapporteras till myndigheterna inom 24 timmar. Resten av förordningen, med krav på säker utveckling, dokumentation och CE-märkning, gäller fullt ut från den 11 december 2027.

Vad CRA är

CRA är förordning (EU) 2024/2847. Den trädde i kraft i december 2024 och är en produktsäkerhetslag i samma familj som reglerna för leksaker, maskiner och elektronik. Skillnaden är att den gäller "produkter med digitala element": hårdvara och mjukvara som direkt eller indirekt kan kopplas upp mot ett nätverk eller en annan enhet.

Det är en bred definition. Den täcker operativsystem, webbläsare, lösenordshanterare, VPN-klienter, routrar, smarta lampor, mobilappar, desktopprogram och bibliotek som säljs eller på annat sätt tillhandahålls kommersiellt.

Kärnan i CRA är tre skyldigheter för tillverkaren:

Säkerhet från början. Produkten ska levereras utan kända utnyttjbara sårbarheter, med säker standardkonfiguration, och tillverkaren ska ha gjort en riskbedömning.
Sårbarhetshantering under supporttiden. Minst fem år, eller produktens förväntade livslängd om den är kortare. Det inkluderar en process för att ta emot rapporter, säkerhetsuppdateringar utan dröjsmål och en SBOM, en förteckning över vilka komponenter produkten innehåller.
Rapportering. Aktivt utnyttjade sårbarheter och allvarliga incidenter ska anmälas via ENISA:s gemensamma rapporteringsplattform, med tidig varning inom 24 timmar, en fylligare anmälan inom 72 timmar och en slutrapport senare.

Det är det tredje kravet som blir skarpt i september. Det går alltså inte att vänta till 2027 med att ha en process för det.

Vilka som omfattas

Det är här de flesta frågor hamnar, och gränsen är inte alltid tydlig.

Omfattas: Den som tillverkar en produkt med digitala element och tillhandahåller den på EU-marknaden inom ramen för kommersiell verksamhet. Det gäller oavsett om ni tar betalt direkt, säljer via en marknadsplats eller ger bort produkten som del av något annat ni tjänar pengar på. Det gäller också importörer och distributörer, med lättare krav.

Omfattas inte: Rena tjänster. Ett SaaS där kunden aldrig får ner någon mjukvara omfattas som utgångspunkt inte av CRA utan hamnar under NIS2 om det är tillräckligt stort. Undantaget är "fjärrdatabehandling" som är nödvändig för att en produkt ska fungera, till exempel molntjänsten bakom en uppkopplad prisdisplay. Då är den delen av produkten.

Omfattas inte: Icke-kommersiell open source. Ett bibliotek som utvecklas och publiceras utan att någon tjänar pengar på det är undantaget. Stiftelser och andra som håller i öppen kod utan vinstsyfte får en lättare roll som "open source steward" med skyldighet att ha en säkerhetspolicy och samarbeta vid sårbarheter, men utan CE-märkning.

Gråzon: Beställningsutveckling. En webbapp som byggs specifikt åt en kund och aldrig säljs vidare ser för de flesta ut som en tjänst, inte en produkt. Men om samma kod paketeras och säljs till nästa kund, eller om ett plugin man byggt åt en kund läggs ut på en marknadsplats, har man plötsligt en produkt. Här är det klokt att följa hur kommissionens vägledning utvecklas och inte utgå från att man är utanför bara för att man kallar sig byrå.

Några vanliga fall:

Ett WordPress-plugin eller Shopify-tema som säljs: produkt, omfattas.
En Next.js-sajt som driftas åt en kund: tjänst, omfattas inte av CRA.
En mobilapp som kunden publicerar under sitt eget namn: kunden är tillverkare, ni är underleverantör, men avtalet bör säga vem som sköter sårbarhetshanteringen.
Ett npm-paket ni släppt gratis på fritiden: undantaget.
Samma npm-paket med betald pro-version: produkt.

Vad rapporteringskravet innebär i praktiken

Artikel 14 kräver att ni upptäcker, bedömer och anmäler inom snäva tider. Det förutsätter tre saker som många små tillverkare inte har idag:

En kanal in. Ett publikt sätt att rapportera sårbarheter, typiskt en security.txt och en adress som någon läser. Om ingen kan nå er vet ni inte att ni blivit utnyttjade.
Någon som bedömer. En person eller roll som inom timmar kan avgöra om en rapport gäller en sårbarhet som utnyttjas aktivt. Det behöver inte vara en säkerhetsavdelning, men det måste vara bestämt vem.
En rutin för att anmäla. Vem skickar, vad ska stå i, var finns kontouppgifterna till rapporteringsplattformen. Skrivet på ett ställe så att det går att göra klockan tre på natten.

Sanktionsavgifterna för brott mot de centrala kraven kan gå upp till 15 miljoner euro eller 2,5 procent av global omsättning. För små företag är den mer sannolika konsekvensen att en större kund begär dokumentation på efterlevnad och att man inte har någon att visa.

Vad ett litet team bör göra nu

För den som har en produkt som ligger i närheten av definitionen är det här en rimlig lista för hösten:

Avgör vad som är produkt. Gå igenom det ni säljer eller distribuerar och märk upp: produkt, tjänst, gratis open source. Skriv ner motiveringen.
Sätt upp mottagningen. security.txt på domänen, en dedikerad e-postadress, ett svar inom några dagar. Detta är billigt och bör finnas oavsett CRA.
Bestäm rollerna. Vem bedömer, vem anmäler, vem pratar med kunder. Ett dokument på en sida räcker.
Börja med SBOM. Verktyg som npm sbom, Syft eller CycloneDX-plugins genererar en komponentlista på minuter. Kravet på SBOM gäller först 2027, men den hjälper er redan nu att veta vad ni behöver patcha när nästa supply chain-incident kommer.
Se över supportlöftet. Om ni säljer ett plugin och slutar underhålla det efter ett år är det inte längre förenligt med CRA. Antingen underhåller ni eller så tar ni ner det.
Prata med kunderna. Om ni bygger åt andra som blir tillverkare, reglera i avtalet vem som gör vad. Det är enklare nu än efter första incidenten.

Hur det hänger ihop med NIS2

Många företag omfattas av båda. NIS2 ställer krav på hur organisationen sköter sin säkerhet, inklusive leverantörskedjan. CRA ställer krav på produkterna som organisationen köper. En NIS2-verksamhet kommer därför att börja fråga sina leverantörer om CRA-efterlevnad för att kunna visa att den själv köper säkra produkter. Även den som har en liten produkt och låg egen risk kan alltså få frågan från kundens jurister.

CRA har fått mindre uppmärksamhet än NIS2 och GDPR, delvis för att de fulla kraven ligger 2027. Rapporteringskravet gäller dock från den 11 september i år, och det förutsätter processer som tar tid att sätta upp. För de flesta som bygger webb åt kunder handlar det om att veta var gränsen går och att skriva in det i avtalen. För den som säljer mjukvara som produkt är det dags att bestämma vem som svarar på security-adressen och vad den personen gör när det ringer.