Kort svar.
Cyber Resilience Act är EU-förordningen om cybersäkerhet för produkter med digitala element som omfattas. Tillverkare ansvarar för säkerheten genom utveckling, tillhandahållande och support. Tillverkarnas rapporteringsskyldigheter gäller sedan den 11 september 2026 och de allmänna produktskyldigheterna från den 11 december 2027. Grunden är förordning (EU) 2024/2847.
Cyber Resilience Act och CRA-tidsfrister.
Cyber Resilience Act, CRA eller cyberresiliensförordningen, reglerar produkters cybersäkerhet. Förordning (EU) 2024/2847 förenar konstruktionskrav med skyldigheter under produktens livscykel. Bedömningsobjektet är den konkreta produkten, inklusive relevanta komponenter och tillhörande fjärrdatabehandling. Ett säkerhetsprogram för hela företaget kan stödja arbetet men besvarar inte ensamt de produktspecifika frågorna.
CRA:s tidsfrister gäller stegvis. Enligt art. 71 Abs. 2 CRA börjar de allmänna kraven gälla den 11 december 2027. Tillverkarnas rapportering enligt art. 14 gäller redan sedan den 11 september 2026. Kapitel IV om anmälan av organ för bedömning av överensstämmelse gäller sedan den 11 juni 2026. Detta institutionella datum är ingen tidigarelagd allmän CE-tidsfrist för alla programvaruprodukter.
Äldre produkter är inte generellt undantagna från tillverkarnas rapportering. Art. 69 Abs. 2 och 3 CRA skiljer mellan övergångsregler för produktöverensstämmelse och rapportering. Kommissionens riktlinjer C(2026) 5252, avsnitt 9.1, förklarar skillnaden även för produkter som släppts ut på marknaden före december 2027. Riktlinjerna är en icke rättsligt bindande tolkningshjälp. Förordningen förblir avgörande.
Vilka produkter och företag CRA berör.
CRA gäller hårdvaru- och programvaruprodukter som omfattas, tillhandahålls på EU-marknaden och avser direkt eller indirekt dataanslutning till en enhet eller ett nätverk. Art. 2 och 3 CRA fastställer tillämpningsområde och definitioner. Även separat tillhandahållna komponenter kan ingå. Pröva den faktiska funktionen och lagstadgade undantag innan hela portföljen klassificeras likadant.
Företagets roll avgör dess skyldigheter. Tillverkare, importörer och distributörer har olika uppgifter. Tillverkarrollen kan även bli relevant vid marknadsföring under eget varumärke. För programvara med öppen källkod ska kommersiellt tillhandahållande, enskilda personers bidrag och den särskilda rollen som förvaltare av öppen källkod skiljas åt. En fri licens befriar inte generellt tillverkaren av en kommersiell produkt från ansvar.
En SaaS-tjänst omfattas eller undantas inte från CRA enbart genom sin försäljningsbeteckning. Avgörande är produktgränsen och tillhörande fjärrdatabehandling. Kommissionens riktlinjer, avsnitt 2 och 8, skiljer mellan programvaruprodukter och tjänster som tillhandahålls på distans. Dokumentera motiveringen för den konkreta arkitekturen. Ett allmänt påstående om alla molnerbjudanden vore för långtgående.
CRA-kravens huvudområden.
CRA-kraven förenar riskbaserad produktsäkerhet med fortlöpande ansvar. Art. 13 och bilaga I CRA utgör grunden för produktskyldigheterna. Art. 14 reglerar tillverkarnas rapportering som gäller tidigare. Följande områden ger orientering utan att ersätta lagens detaljkrav.
Förstå produkten och riskerna.
En cybersäkerhetsriskbedömning bär upp säkerhetsbesluten under hela livscykeln. Tillverkare beaktar avsedd och rimligen förutsebar användning. Beskriv praktiskt produktens funktioner, gränssnitt och beroenden och vilka konsekvenser ett säkerhetsproblem kan få för användarna.
Bygg in säkerhet i produkten.
Säker konstruktion och säkra standardinställningar hör ihop. Bilaga I CRA omfattar produktegenskaper såsom åtkomstskydd, dataskydd och begränsade angreppsytor. En efterhandskriven riktlinje kan inte ersätta tekniska egenskaper. Utvecklingsbeslut och deras verifiering måste motsvara riskbedömningen.
Integrera komponenter med tydligt ansvar.
Integrerade komponenter ingår fortsatt i produktbedömningen. Tillverkare behöver spårbar information om vad de levererar och hur sårbarheter i beroenden påverkar produkten. Kommissionen beskriver uttryckligen tillbörlig aktsamhet gentemot tredjepartskomponenter. Att enbart vidarebefordra leverantörsuppgifter besvarar inte varje produktfråga.
Hantera sårbarheter och uppdateringar.
Sårbarhetshantering är en löpande uppgift under den relevanta supportperioden. Den omfattar tillgängliga rapporteringsvägar, bedömning, avhjälpande och säker distribution av säkerhetsuppdateringar. Skilj den tekniska hanteringen av ett fynd från den rättsliga bedömningen av om en aktivt utnyttjad sårbarhet eller en allvarlig incident är rapporteringspliktig.
Fastställ support och användarinformation.
Supportperioden styrs av kriterierna i art. 13 Abs. 8 CRA och förväntad användning. I princip gäller minst fem år. Vid kortare förväntad användning gäller dess längd och vid längre förväntad användning kan en längre period krävas. Kommissionens riktlinjer, avsnitt 5, förklarar uttryckligen att fem år inte är någon allmän maxgräns.
Möjliggör tillverkarnas rapportering.
Art. 14 CRA skiljer mellan aktivt utnyttjade sårbarheter och allvarliga säkerhetsincidenter. För tillverkare gäller stegvis rapportering: utan dröjsmål, senast inom 24 timmar en tidig varning och inom 72 timmar ytterligare uppgifter efter kännedom. Slutfristerna skiljer sig beroende på utlösande händelse. Ett skannerfynd är därför varken automatiskt en obligatorisk rapport eller tillräcklig grund för att avsluta händelsen.
Förbered överensstämmelse och dokumentation.
Teknisk dokumentation och bedömning av överensstämmelse måste förklara den erbjudna produkten. Art. 32 CRA och produktkategorin avgör tillåtet förfarande. Dokumentera vald bedömningsgrund tillsammans med produktversionen. En allmän dokumentsamling utan spårbar koppling till den granskade utförandevarianten räcker inte som praktisk strategi för att styrka överensstämmelse.
Genomför CRA som en produktprocess.
Avgränsa portfölj och roller.
Börja praktiskt med att kartlägga erbjudna produkter, deras relevanta funktioner, ansvarig juridisk person och rollen i respektive försäljningskanal.
Håll isär tillämpningsfaserna.
Skilj den redan gällande beredskapen för tillverkarrapportering från förberedelserna för allmän produktöverensstämmelse och pröva övergångar för befintliga produkter.
Omsätt risker i produktbeslut.
Koppla riskbedömningen till konstruktion, komponentval och verifierbara säkerhetskriterier för utveckling och godkännande.
Öva rapporteringsvägarna.
Utse ansvariga och ersättare och öva bedömning, eskalering och överföring med ofullständig information inom tillämpliga tidsfrister.
Fastställ support och hur överensstämmelse ska styrkas.
Planera underhållet av produktversioner som stöds och klargör utifrån kategorin vilken bedömning av överensstämmelse och teknisk dokumentation som kommer att krävas.
CE-märkning av programvara och produktunderlag.
CRA-underlaget utgörs av en produktrelaterad bedömning av överensstämmelse. Kommissionen förklarar om art. 32 CRA att intern bedömning är möjlig för standardkategorin. För vissa viktiga eller kritiska produkter gäller strängare förfaranden med ett anmält organ eller andra tillåtna vägar för att styrka överensstämmelse. Produktens faktiska funktion avgör kategorin. Ett marknadsföringsnamn räcker inte.
EU-försäkran om överensstämmelse och CE-märkningen följer det tillämpliga förfarandet. De är inget allmänt certifikat för hela företaget och inget löfte om att en produkt aldrig kommer att ha en sårbarhet. En enhetlig certifikatstid passar därför inte som beskrivning av CRA. Dokumentation, sårbarhetshantering och respektive gällande skyldigheter måste bedömas under den relevanta livscykeln.
Andra ramverk och självständiga skyldigheter.
ISO 27001 organiserar ett ledningssystem för informationssäkerhet. Ett sådant certifikat bekräftar inte ensamt en produkts CRA-överensstämmelse. NIS2 gäller berörda verksamhetsutövare och deras säkerhetsorganisation. GDPR skyddar personuppgifter, varför en produkthändelse kan väcka ytterligare dataskyddsfrågor. Närliggande arbetsflöden kan samordnas, men deras rättsliga utlösande faktorer och underlag ska prövas separat.
I Secani.
Secani innehåller en redaktionell arbetskatalog för CRA med källor, granskningsfrågor och exempel på underlag. Företagsprofilen dokumenterar bland annat roller och bedömningsdatum. Oklara förutsättningar förblir synliga som granskningsbehov. Hjälpmedlet stöder organiseringen av prövningen men bekräftar varken rättslig klassificering eller produktöverensstämmelse.
Börja med en avgränsad produkt.
Välj en konkret produkt och klargör först dess gräns, ansvarig juridisk person och ansvariga för säkerhetsrapportering. Pröva sedan vilka nuvarande och kommande skyldigheter som berör produkten. Denna start gör förberedelserna hanterbara och förhindrar att ett allmänt efterlevnadsprojekt skymmer den rapporteringsberedskap som redan krävs.
Källor.
- Förordning (EU) 2024/2847 – Cyber Resilience Act
- Europeiska kommissionen: Cyber Resilience Act och tillämpningsdatum
- Europeiska kommissionen: sammanfattning av rättsakten
- Europeiska kommissionen: tillverkarnas skyldigheter
- Europeiska kommissionen: bedömning av överensstämmelse
- Europeiska kommissionen: CRA och öppen källkod
- Europeiska kommissionen: riktlinjer C(2026) 5252 med bilaga
Vanliga frågor.
Ja, för tillverkare som omfattas gäller rapporteringen enligt art. 14 CRA sedan den 11 september 2026. De allmänna produktskyldigheterna börjar gälla den 11 december 2027. Särskilda roller och övergångar ska prövas separat.
Nej, beteckningen SaaS avgör inte tillämpningsområdet. Pröva programvaruprodukten, dess funktioner och tillhörande fjärrdatabehandling utifrån den konkreta arkitekturen.
Nej, den särskilda behandlingen av tidigare bidrag till öppen källkod befriar inte generellt den kommersiella produkttillverkaren från skyldigheterna. Tillverkarrollen och en eventuell förvaltarroll måste hållas isär.
Nej, ett ISO 27001-certifikat gäller ett avgränsat ledningssystem. CRA kräver en separat bedömning av produkten och de underlag för överensstämmelse som gäller i det enskilda fallet.
Organisera produktsäkerheten på ett spårbart sätt.
Arbeta strukturerat med CRA-krav och deras prövning i Secani.
Denna sida förklarar Cyber Resilience Act övergripande och ersätter inte en rättslig prövning av den enskilda produkten. Gällande rättsakter är avgörande.