Vägledning från Europeiska kommissionen om CRA

01Vad detta är

Art. 26 kräver att kommissionen publicerar vägledning för att hjälpa ekonomiska aktörer att tillämpa CRA, med särskilt fokus på att göra efterlevnaden enklare för små och medelstora företag. Den 27 July 2026 godkände kommissionen innehållet i den vägledningen (dokumentreferens C(2026) 5252). Den omfattar omkring 80 sidor och går igenom de frågor som tillverkare oftast ställer.

Vägledningen är inte bindande och ändrar inte lagen: en auktoritativ tolkning av CRA kan endast komma från EU-domstolen. Men marknadskontrollmyndigheter och anmälda organ ser till den för en enhetlig, harmoniserad tolkning, vilket gör den till det naturliga komplementet till förordningen.

02Vad som räknas som en produkt

Den största delen av vägledningen handlar om tillämpningsområde, det område som det ställs flest frågor om. En produkt med digitala element är en mjukvaru- eller hårdvaruprodukt (och dess fjärrdatabehandling) vars användning omfattar en direkt eller indirekt dataanslutning. Art. 3(1)

• Var programvaran körs avgör det; programvara som körs på användarens enhet (en nedladdad app, ett webbläsartillägg, en lokalt installerad klient) är en produkt med digitala element. Programvara som enbart nås på distans via en webbläsare är det inte, enbart på den grunden.
• Webbappar och webbplatser; en webbapplikation som endast används via en webbläsare, och en webbplats som enbart presenterar information, är i allmänhet inte produkter med digitala element. De omfattas endast där de utgör fjärrdatabehandling som stöder en produkts funktion.
• Källkod; CRA:s definition av programvara omfattar både maskinkod och källkod, men att enbart dela öppen källkod i ett offentligt kodförråd räknas i allmänhet inte som att "tillhandahålla på marknaden". Art. 3(4)

Om du är osäker på var din produkt hör hemma, Fast Check och den förklaring i klarspråk går igenom tillämpningsområdet i praktiken.

03Programvara med öppen källkod

Vägledningen beskriver i detalj den skräddarsydda, lättare ordningen för öppen källkod. Icke-kommersiell programvara med öppen källkod som utvecklas utanför en kommersiell verksamhet faller till stor del utanför tillämpningsområdet; utlösande faktorn är kommersiell verksamhet och om programvaran tillhandahålls på marknaden.

• När FOSS "tillhandahålls på marknaden"; vägledningen går igenom att ta betalt, monetarisera relaterade tjänster eller kräva personuppgifter, betald support, donationer, finansieringsupplägg och icke-vinstdrivande strukturer, samt andra tillverkares integrering av FOSS.
• Förvaltare av programvara med öppen källkod; en definierad, proportionerlig uppsättning skyldigheter inriktade på att stödja programvarans säkerhet och fortsatta livskraft.
• Viktig FOSS; viktiga produkter (klass I eller II) som tillhandahålls på marknaden som fri programvara med öppen källkod får följa de lättare förfarandena för överensstämmelse i standardkategorin. Art. 32(5)

04Väsentliga ändringar

Om en ändring är en substantial modification avgör om en ny bedömning av överensstämmelse krävs. Skäl 39 ramar in det: en produkt är väsentligt ändrad när en ändring påverkar dess nivå av cybersäkerhetsrisk på ett sätt som tillverkaren inte redan hade beaktat i sin riskbedömning. Art. 3(30)

• Säkerhetsuppdateringar är i allmänhet inte väsentliga ändringar; deras syfte är att minska risken, så en säkerhetsfix som inte ändrar produktens avsedda ändamål eller introducerar nya risker räknas inte i sig som en sådan.
• Det handlar om risk, inte storlek; testet är förändringens påverkan på cybersäkerhetsriskprofilen (nya hotvektorer, nya attackscenarier eller en förändrad sannolikhet eller påverkan), inte ändringens omfattning.
• Konsekvensen; en väsentligt ändrad produkt behandlas som ett nytt tillhandahållande på marknaden. Om någon annan än den ursprungliga tillverkaren gör ändringen övertar denne tillverkarens skyldigheter för den ändrade delen. Art. 21 · 22

Den Guide till CE-märkning omfattar den bedömning av överensstämmelse som ett nytt tillhandahållande på marknaden utlöser.

05Stödperiod

Stödperioden är den tid under vilken sårbarheter måste hanteras. Den bör återspegla hur länge produkten rimligen förväntas vara i bruk. Art. 13(8)

• Fem år är ett golv, inte en standard; perioden måste vara minst fem år, om inte produkten förväntas användas kortare tid. Produkter som rimligen förväntas vara i bruk längre bör ha längre stödperioder.
• Informera användarna; ange slutdatumet (minst månad och år) vid köptillfället, och meddela användarna när det löper ut där det är tekniskt möjligt. Art. 13(19)
• Flexibilitet för programvara; tillverkare får, under vissa förutsättningar, åtgärda sårbarheter endast i den senaste versionen, förutsatt att användarna kan uppgradera kostnadsfritt och utan extra kostnad. Art. 13(10)
• Efter en väsentlig ändring; bedöm perioden på nytt utifrån samma kriterier; den återställs eller förlängs inte automatiskt.

Planera din med planerare för stödperiod och slutdatum.

06Viktiga och kritiska produkter

Klassificeringen avgör vägen för bedömning av överensstämmelse. En produkt är viktig if its kärnfunktionalitet matchar en Annex III-kategori (klass I eller II), och kritisk om den matchar Annex IV; allt annat är en standardprodukt som kan självbedömas. Art. 7 · 8 · 32

• Kärnfunktionalitet är testet; produktens huvudfunktioner, utan vilka den inte skulle uppfylla sitt avsedda ändamål. Kompletterande funktioner ändrar inte klassen, och att enbart integrera en viktig eller kritisk komponent gör inte hela produkten viktig eller kritisk: en smartphone som innehåller ett operativsystem är inte i sig ett "operativsystem".
• En kärnfunktionalitet; vid val av väg för bedömning av överensstämmelse anses en produkt ha en enda kärnfunktionalitet, identifierad i dess tekniska dokumentation.
• Kategoridefinitionerna; de tekniska beskrivningarna av kategorierna viktig och kritisk anges i Commission Implementing Regulation (EU) 2025/2392.

Matcha din produkt mot kategorierna med produktklassfinare.

07Fjärrdatabehandling

Fjärrdatabehandlingslösningar ingår i en produkt med digitala element endast där de är nödvändig för att produkten ska kunna utföra sina funktioner. Art. 3(2) Vägledningen erbjuder ett praktiskt test: sker behandlingen "på distans"; skulle dess frånvaro hindra produkten från att utföra en av sina funktioner; och utformades och utvecklades programvaran av, eller under ansvar av, tillverkaren.

Den illustrerar testet med praktiska användningsfall (en mobilbanksapplikation, en smart termostat, en e-läsare, en industrirobot och ett mobilnät) som visar var gränsen går mellan en produkt och en ren tjänst.

08Rapportering och sårbarheter

Vägledningen förtydligar också de löpande skyldigheterna: Article 14 reporting av aktivt utnyttjade sårbarheter och allvarliga incidenter, samt Annex I vulnerability-handling krav: rapportering uppströms och delning av säkerhetsfixar, hantering av kända utnyttjbara sårbarheter, samt genomförande av effektiva, regelbundna säkerhetstester och granskningar. Art. 14 · Annex I

09Andra officiella källor

Vägledningen kompletterar två andra officiella referenspunkter som är värda att läsa tillsammans.

Harmoniserade standarder. De väsentliga kraven i Bilaga I är skrivna i resultattermer; när en relevant harmoniserad standard väl har publicerats i Europeiska unionens officiella tidning ger efterlevnad av den en presumtion om överensstämmelse. Kommissionens standardiseringsbegäran M/606 accepterades av CEN, CENELEC och ETSI 2025 och omfattar omkring 41 standarder. De två centrala horisontella standarderna (säker utveckling och sårbarhetshantering) förväntas till 30 August 2026, de vertikala produktstandarderna till 30 October 2026, och de återstående horisontella standarderna till 30 October 2027, ungefär ett år före full tillämpning.