Cyber Resilience Act · 2026/2027

Gäller cyberresiliensförordningen för min produkt?

Författare: Piotr AdamskiOperativ granskning och säkerhetsgranskning: Brillnet C-Team

Information. Ersätter inte individuell juridisk rådgivning eller bedömning av överensstämmelse.

Kontrollera CRA:s tillämpning och ladda ned din bedömning

CRA-kontroll: en första bedömning av en produkt

Svara på fyra frågor för att få en grund för granskning och en underlagschecklista. Svaren stannar i den här webbläsaren; ladda ned rapporten utan konto.

Detta är en inledande bedömning av tillämpningsområdet, inte juridisk rådgivning eller bekräftelse av överensstämmelse. Produktansvarig måste granska resultatet. Den fastställer inte de särskilda skyldigheterna för förvaltare av programvara med öppen källkod.

Frågornas grund: CRA artiklarna 2 och 3

CRA:s tillämpningsområde avgörs inte enbart av företagets bransch eller etiketter som ”SaaS”, ”IoT” eller ”programvaruleverantör”. Börja med den specifika produkten med digitala element, hur den tillhandahålls på EU-marknaden, organisationens roll och eventuell fjärrbehandling av data som ingår i produktens funktioner.

Resultatet bör vara en dokumenterad bedömning av tillämpningsområdet där grunden för slutsatsen syns, inte ett oförklarat ja eller nej.

Steg 1. Identifiera produkten

Börja med det som användaren faktiskt köper, laddar ned, installerar, integrerar eller tar emot som komponent.

Dokumentera:

  • produktnamn och identifierare;
  • version eller versionsfamilj;
  • avsett ändamål;
  • huvudfunktioner;
  • leveransmodell;
  • varumärket under vilket produkten når marknaden;
  • marknader där den tillhandahålls.

Om teamet inte kan avgränsa produkten kommer resten av bedömningen att bygga på antaganden som är svåra att granska senare.

Steg 2. Kontrollera definitionen av en produkt med digitala element

CRA definierar en produkt med digitala element som en programvaru- eller hårdvaruprodukt och dess lösningar för fjärrbehandling av data. Programvaru- eller hårdvarukomponenter som släpps ut på marknaden separat kan också omfattas av definitionen.

För fjärrtjänster är det funktionella sambandet avgörande. Förordningen beskriver fjärrbehandling av data som behandling på distans där programvaran har utformats och utvecklats av tillverkaren eller under tillverkarens ansvar, och vars avsaknad skulle hindra produkten från att utföra en av sina funktioner.

Därför räcker inte ”den körs i molnet” som test av tillämpningsområdet. Kartlägg först produkten och beroendena.

Steg 3. Fastställ organisationens roll

Den relevanta rollen kan vara:

  • tillverkare;
  • representant;
  • importör;
  • distributör;
  • en annan person som gör en väsentlig ändring och tillhandahåller produkten på marknaden.

Ett viktigt fall är en importör eller distributör som släpper ut en produkt på marknaden under sitt eget namn eller varumärke, eller gör en väsentlig ändring av den. Enligt CRA kan tillverkarens skyldigheter då gälla för denna aktör.

Steg 4. Bortse inte från produkter som redan finns på marknaden

De huvudsakliga CRA-kraven börjar tillämpas den 11 december 2027, men det betyder inte att produkter som redan finns på marknaden kan lämnas utanför dagens rapportering.

Artikel 69(3) anger att rapporteringsskyldigheterna i artikel 14 gäller produkter med digitala element inom förordningens tillämpningsområde även om de släpptes ut på marknaden före den 11 december 2027.

För en befintlig produkt som fortfarande används är arbetsflödet för sårbarhets- och incidentrapportering därför en aktuell verksamhetsfråga.

Steg 5. Kontrollera undantag och sektorsspecifik lagstiftning

Förlita er inte på en kort nätlista över ”branscher undantagna från CRA”. Förordningen har ett eget tillämpningsområde, egna undantag och kopplingar till sektorsspecifik EU-rätt.

En process som går att försvara innebär att:

  1. dokumentera den rättsliga bestämmelse och källa som används för bedömningen;
  2. dokumentera granskningsdatumet;
  3. skilja fakta från antaganden;
  4. markera frågor som kräver kvalificerad juridisk granskning i stället för att omvandla osäkerhet till ett tvärsäkert produktpåstående.

Minsta dokumentation för bedömning av tillämpningsområde

Fält Vad som ska dokumenteras
Produkt namn, version, identifierare
Organisationens roll tillverkare / importör / distributör / annan
Marknad var produkten tillhandahålls
Digitala funktioner programvara, hårdvara, gränssnitt, komponenter
Fjärrbehandling vad som körs på distans och om det krävs för en produktfunktion
Grund CRA-bestämmelse, kommissionens vägledning, antaganden
Resultat sannolikt inom tillämpningsområdet / sannolikt utanför / kräver fördjupad bedömning
Beslutsansvarig personen som godkänner bedömningen
Granskningsdatum när beslutet ska omprövas

När en ny bedömning behövs

Bedömningen av tillämpningsområdet ska inte bli en bortglömd PDF. Ompröva den när exempelvis:

  • det avsedda ändamålet ändras;
  • en ny fjärrtjänst blir nödvändig för en produktfunktion;
  • produkten ändras väsentligt;
  • distributionsmodellen eller varumärket ändras;
  • organisationen får en annan roll som ekonomisk aktör;
  • ny vägledning från kommissionen eller en myndighet ändrar beslutets grund.

Hur Pulsar gör beslutet spårbart

Pulsar kan bevara bedömningens grund tillsammans med stöddokument och koppla resultatet till risker, åtgärder och underlag. Värdet är förmågan att senare visa vad som bedömdes, vilka källor som användes, vem som godkände resultatet och vilka åtgärder som följde, inte ett oförklarat automatiskt svar.

Pulsar ersätter inte individuell rättslig bedömning.

Se hur en bedömning genomförs i Pulsar GRC

Ett genomarbetat exempel på produktgränsen

Anta att företaget säljer en nätverksansluten mätare och ett tillhörande program. Programmet visar mätvärden lokalt men använder dessutom en backend för en särskild funktion. Beskriv delarna var för sig innan någon fattar beslut. Vilken del får kunden, vilken del drivs av tillverkaren och vilken funktion kräver fjärrbehandlingen? Ange vilka versioner bedömningen gäller. Svaret behöver stöd i produktens funktion och distribution, inte i hur försäljningen kallar paketet.

Gör därefter ett funktionellt borttagningstest som tankeövning eller i en lämplig testmiljö. Vad fungerar när backend inte finns? Dokumentera utfallet utan att likställa testresultatet med ett färdigt juridiskt svar. En rättslig bedömare behöver koppla fakta till CRA:s definitioner och eventuella undantag. Produktteamets uppgift är att ge den bedömaren ett tydligt och korrekt faktaunderlag.

Rollen kan förändras när erbjudandet förändras

Ett företag kan köpa en produkt från en annan tillverkare och senare ändra, integrera eller marknadsföra den under eget namn. Beskriv därför vad företaget faktiskt gör i den aktuella distributionskedjan. Bevara avtal, varumärkesbeskrivning och tekniska ändringar som förklarar rollen. Att samma leverantör fortfarande levererar hårdvaran avgör inte ensamt ansvaret för det färdiga erbjudandet.

När något ändras behöver den tidigare bedömningen omprövas. Exempelvis kan en ny funktion påverka produktgränsen, medan en ändrad affärsmodell kan påverka organisationens roll. Dokumentera både den tekniska förändringen och den juridiska frågan. Markera vad som är bekräftat och vem som fortfarande behöver lämna en bedömning. Ett avtal som fördelar praktiskt arbete ska inte automatiskt tolkas som att rättsliga skyldigheter försvinner.

Separat programvara behöver separat uppmärksamhet

En nedladdningsbar app, ett agentprogram eller en separat distribuerad komponent kan behöva en annan bedömning än den webbtjänst som säljs tillsammans med den. Lista därför erbjudandets delar och vilka som tillhandahålls på marknaden. Undvik en gemensam slutsats för alla delar när distributionssätten skiljer sig. Granskningen kan sedan visa vilka delar som ska hanteras tillsammans och varför.

Ta med avsedd användning, anslutningar och beroenden. Beskriv även om kunden installerar programmet själv eller får det genom en annan produkt. Dessa fakta hjälper bedömaren att förstå situationen. En produktförteckning med bara namn och pris räcker sällan. För varje post behöver någon kunna visa den version och den dokumentation som faktiskt användes i bedömningen.

Undantag ska styrkas, inte bara markeras

När teamet bedömer att ett undantag eller annan sektorsreglering är relevant ska beslutet ange källan och skälet. Förklara vilken produkt och vilka förutsättningar bedömningen omfattar. Ett fält med ”ej tillämpligt” är svårt att försvara senare om underlaget saknas. Om frågan är osäker ska den lämnas öppen för kvalificerad granskning i stället för att fyllas med en bekväm slutsats.

Samma försiktighet gäller programvara som beskrivs som öppen källkod. Licens, utvecklingsmodell, kommersiell verksamhet och organisationens roll behöver kontrolleras i de aktuella reglerna och den officiella vägledningen. En etikett i projektets README avgör inte ensam utfallet. Teamet bör inte använda den som en generell befrielse från att bedöma sina egna produkter eller ansvar.

Befintliga produkter behöver en karta över versioner

Välj en produkt som redan finns hos kunder och lista aktuella utgåvor. Ange när de tillhandahölls, vilka som fortfarande används och vad som skiljer deras funktioner. Dokumentera källan för dessa uppgifter. Om organisationen saknar en säker bild av installerade versioner ska det framgå. Säljhistorik kan hjälpa, men den visar inte alltid vilken version kunden använder i dag.

Rapporteringsarbetet behöver kunna identifiera de utgåvor som en händelse kan påverka. Ett generellt produktbeslut hjälper inte om teamet sedan inte kan skilja en äldre funktion från den senaste. Koppla därför omfattningsbedömningen till utgåve- och sårbarhetsprocessen. Bevara osäkerheter och planera hur de ska minskas. Det gör nästa tekniska bedömning snabbare utan att skapa en ogrundad juridisk säkerhet.

Underlagets kvalitet avgör om beslutet kan återanvändas

En arkitekturskiss behöver visa relevant funktion och ansvar, inte bara en tekniskt tilltalande bild. Ange vad symbolerna betyder, vilka delar som ägs av organisationen och vilka som drivs av tredje part. Produktbeskrivningen bör stämma med den faktiska användarinformationen. Om dokumenten motsäger varandra behöver den skillnaden utredas innan granskaren använder dem som beslutsgrund.

Koppla beslutet till en låst eller tydligt identifierad dokumentversion. En länk till ”senaste arkitektur” kan senare visa något annat än det som bedömdes. Bevara originalets datum och versionsuppgift. Om materialet uppdateras ska teamet veta om det bara förtydligar samma fakta eller ändrar en förutsättning för den juridiska bedömningen. Det är skillnaden mellan att underhålla en akt och att tyst skriva om dess grund.

Ett mottagningstest för omfattningsbeslutet

Be en kollega att besvara tre konkreta frågor från paketet: vilken produktversion gäller beslutet, vilken distributionsmodell bedömdes och vilken fjärrfunktion ingår? Personen ska hitta dokumenterade svar utan att först ringa utvecklingsledaren. Kontrollera också att beslutets godkännare och öppna frågor framgår. Testet visar begriplighet och spårbarhet, inte att rättslig slutsats är korrekt.

Använd sedan en testkopia med en ändrad förutsättning, exempelvis en ny mobilapp eller en backend som blivit nödvändig. Granskaren ska kunna identifiera behovet av ombedömning. Om samma slutsats återanvänds trots förändringen behöver granskningsregeln förtydligas. Dokumentera vad som utlöser ny bedömning och vem som ansvarar för att produktändringar når den juridiska funktionen.

Avgränsa frågor som ligger i andra regelverk

Ett beslut om CRA:s tillämpningsområde avslutar inte organisationens övriga skyldigheter. Dataskydd, avtal, sektorsregler och nationella NIS2-bestämmelser kan behöva egna bedömningar. Ange därför vilken fråga dokumentet besvarar och vilka andra frågor som hanteras separat. Detta hindrar ett avgränsat produktbeslut från att felaktigt användas som ett allmänt efterlevnadsbesked.

Skriv även geografisk omfattning. Den svenska språkversionen beskriver EU-förordningen men bedömer inte automatiskt varje nationell skyldighet för företaget. När roller eller etablering skiljer sig mellan länder behöver ansvariga kontrollera vilka myndigheter och processer som berörs. Pulsar kan koppla besluten till samma produkt och bevara källorna; sakkunniga personer behöver fortfarande bedöma frågorna och godkänna utfallet.

Kontrollera beslutet mot produktens kundbeskrivning

Jämför produktakten med det erbjudande kunden faktiskt får. Om försäljningstexten beskriver en funktion som saknas i den tekniska omfattningen behöver skillnaden utredas. Samma sak gäller en komponent som levereras genom en partner men inte finns i företagets interna produktlista. En granskad omfattning ska bygga på verklig distribution och funktion, inte bara på projektets interna namn.

Bevara vilken kundbeskrivning som användes och dess datum. När nästa paketering eller distribution ändras ska produktansvarig kunna se om samma beslut fortfarande gäller. Om fakta är motsägande bör bedömningen ange en öppen fråga och en mottagare som kan lösa den. Det är bättre än att välja den beskrivning som ger det enklaste juridiska svaret.

Relaterad vägledning

Källor

Källor kontrollerade: 2 oktober 2026. De praktiska testerna och exemplen ovan är redaktionella förslag, inte nya rättsliga krav.