I december 2027 träder EU:s Cyber Resilience Act i full kraft. För första gången sätter EU lagstadgade cybersäkerhetskrav på produkter med digitala element, inte på organisationer som bearbetar data eller driver kritisk infrastruktur, utan på själva mjukvaran och hårdvaran som placeras på den europeiska marknaden. Redan i september 2026 träder de första rapporteringsskyldigheterna i kraft. Det innebär att fönstret för förberedelser är öppet nu, och att de flesta bolag som säljer en uppkopplad produkt, en SaaS-tjänst eller ens en mobilapp inom EU behöver fatta beslut under det närmaste året som kommer att forma deras produktutveckling i många år framåt.
Den här texten är skriven för en ledningsgrupp eller styrelse som behöver förstå vad förordningen kräver, vilka beslut som faktiskt landar på ledningsnivå och vad konsekvenserna blir av att skjuta upp arbetet. Den tekniska implementeringen kommer att utföras av era ingenjörer, säkerhetsteam och produktägare. Men sekvenseringen, prioriteringen och resurssättningen är ledningens ansvar, och det är dessa beslut som avgör om er organisation kommer att stå redo i tid.
En ny typ av reglering
Innan CRA reglerade EU hur organisationer hanterar data och risk, det är vad GDPR, NIS2 och DORA gör. Men det fanns ingen reglering av hur säkra produkterna själva behövde vara. En tillverkare kunde släppa en uppkopplad enhet på EU-marknaden med minimala säkerhetskontroller, utan en process för sårbarhetshantering och utan skyldighet att leverera säkerhetsuppdateringar. När produkten väl var såld flyttades ansvaret till användarorganisationen, som sedan förväntades hantera risken under sina egna NIS2- eller GDPR-skyldigheter.
CRA stänger den asymmetrin. Förordningen tvingar tillbaka ansvaret till källan, det vill säga till tillverkaren av produkten. Det är ett perspektivskifte värt att stanna upp inför: ett bolag som tidigare har varit kund till osäkra produkter kommer nu också att möta krav från sina egna kunder att kunna bevisa att de egna produkterna är säkra. Den kommersiella pressen kommer alltså inte bara uppifrån från regulatorn, utan också från B2B-kundernas inköpsavdelningar.
Tillämpningsområdet är brett. En produkt med digitala element är, i grova drag, alla typer av hårdvara eller mjukvara som kan kopplas direkt eller indirekt till en enhet eller ett nätverk. Det fångar in alltifrån konsumentprodukter inom Internet of Things till företagsprogramvara, från mikrokontroller till operativsystem, från mobilappar till SaaS-plattformar med betydande databearbetning på distans. För de flesta bolag som säljer något digitalt till EU-marknaden är frågan inte om de träffas, utan hur de träffas och i vilken klassificering deras produkter hamnar.
Vem som bär ansvaret
CRA lägger skyldigheter på tre aktörer i värdekedjan: tillverkare, importörer och distributörer. Den tyngsta bördan ligger hos tillverkaren, definierad som den juridiska enhet som placerar produkten på marknaden under sitt eget varumärke. Det är värt att notera att även om produktion, utveckling, hosting eller sårbarhetsrespons är outsourcad till tredje part, så är det fortfarande tillverkaren som bär det juridiska ansvaret. Statutära skyldigheter kan inte kontraktuellt skickas vidare till en underleverantör. Indemnifieringsklausuler kan vara kommersiellt nyttiga men de skyddar inte mot regulatorisk åtgärd.
Detta är en punkt som ledningar ofta missuppfattar. Det är vanligt att tänka att eftersom utvecklingen sker hos en extern partner är ansvaret också externt. Så är det inte. Om ert varumärke står på produkten är ni tillverkaren i CRA:s mening, och regulator kommer att vända sig till er.
Produktklassificering: varför detta avgör allt annat
Innan vi går in på de materiella kraven är det värt att förstå att CRA delar in produkter i kategorier som avgör hur compliance ska bevisas. Klassificeringen bestämmer om ni får göra en självbedömning eller om ett anmält organ måste blandas in, och det i sin tur påverkar både tidsplan och kostnad väsentligt.
Huvudkategorin är default-produkter. Hit hör majoriteten av konsument- och företagsprogramvara samt allmän hårdvara som inte utför säkerhetskritiska funktioner. För dessa kan tillverkaren göra en självbedömning, upprätta teknisk dokumentation och utfärda en EU-försäkran om överensstämmelse på egen hand. Inget externt organ behöver involveras.
Sedan finns important products enligt Annex III, indelade i klass I och klass II. Hit hör produkter med förhöjd cybersäkerhetsrisk, exempelvis identitetshanteringssystem, lösenordshanterare, nätverksutrustning, brandväggar, mikrokontrollers, smarta hem-hubbar och liknande. Klass I kan i de flesta fall fortfarande hanteras via självbedömning under förutsättning att en harmoniserad standard tillämpas. Klass II kräver däremot ett anmält organ, en tredje part som granskar tillverkarens dokumentation och processer innan CE-märkning får ske.
Slutligen finns critical products enligt Annex IV, en mycket smal kategori där kommissionen kan kräva certifiering under ett europeiskt cybersäkerhetscertifieringsschema. Listan är idag begränsad men förväntas växa via delegerade akter.
För ledningen är detta inte en akademisk distinktion. En klassificering i klass II eller högre innebär en tredjepartsbedömning, vilket både tar tid och kostar pengar. Marknaden för anmälda organ är dessutom under uppbyggnad och kapaciteten antas bli ansträngd 2027. För bolag med produkter som potentiellt hamnar i klass II är det därför rimligt att initiera kontakt med möjliga anmälda organ redan under 2026.
Vad förordningen kräver: produktens egenskaper
CRA:s materiella krav ligger samlade i ett bilageavsnitt som är uppdelat i två funktionellt olika delar. Den första delen handlar om vilka egenskaper produkten själv måste ha, den andra om vilka processer tillverkaren måste driva runt produkten. En produkt kan inte vara compliant genom att enbart möta en av delarna.
Genomgående är kraven riskbaserade. CRA föreskriver inte fixerade tekniska lösningar utan ställer principkrav som ska uppfyllas i förhållande till produktens specifika riskprofil. Det innebär att riskbedömningen, som måste dokumenteras och löpande uppdateras, blir det centrala dokument som binder samman de abstrakta kraven med er specifika produkt.
Produktegenskapskraven kan grupperas i några praktiska teman.
En lämplig nivå av cybersäkerhet baserad på risk. Säkerhetsnivån är inte absolut utan proportionell mot de risker produkten utgör. En uppkopplad leksak och ett industriellt styrsystem möter olika riskprofiler och därför olika krav.
Leverans utan kända exploaterbara sårbarheter. Vid det ögonblick produkten placeras på marknaden får den inte innehålla kända, exploaterbara sårbarheter. Det är inte en garanti mot okända sårbarheter, men det förutsätter att tillverkaren faktiskt vet vad som finns i produkten och har en process för att skanna mot kända sårbarhetsdatabaser innan release.
Säker standardkonfiguration. Produkten ska levereras med säker konfiguration som utgångspunkt, så att slutkunden inte ska behöva utföra ytterligare härdning för att nå en rimlig säkerhetsbaslinje. Där användare kan återställa till fabriksinställningar ska även dessa standardvärden vara säkra.
Skydd mot obehörig åtkomst. Autentisering, identitets- och åtkomsthantering måste finnas där produktens riskprofil kräver det, inklusive motståndskraft mot brute-force-attacker och säker hantering av inloggningsuppgifter.
Konfidentialitet och integritet för data. Lagrad och överförd data ska skyddas, typiskt genom kryptering enligt state-of-the-art. Integritetsskydd ska hindra obehörig modifiering av kod, konfiguration och data på själva enheten.
Dataminimering. Produkten får endast bearbeta data som är adekvat, relevant och begränsad till vad som är nödvändigt för det avsedda syftet, oavsett om datan är personuppgifter eller inte.
Tillgänglighet och motståndskraft. Produkten ska fortsätta fungera under attack i den utsträckning som är rimligt för dess syfte, och får inte i normal drift eller under attack dra med sig omkringliggande infrastruktur.
Begränsad attackyta. Produkten ska bara exponera de gränssnitt som är nödvändiga för dess avsedda syfte. Oanvända portar, tjänster och API:er ska vara avstängda eller helt borttagna.
För många bolag innebär dessa krav inte en revolution utan en formalisering. Mycket av detta är god säkerhetspraxis som de bättre engineering-organisationerna redan följer. Skillnaden är att det nu måste dokumenteras och bevisas för en regulator eller ett anmält organ.
Vad förordningen kräver: tillverkarens processer
Den andra delen av kraven är ofta den som överrumplar mjukvarubolag med mogen utvecklingsverksamhet. Deras produkter klarar redan en stor del av produktkraven, men de saknar typiskt det formaliserade processramverk som CRA kräver.
Tillverkaren ska identifiera och dokumentera sårbarheter i produkten löpande. När sårbarheter upptäcks ska de åtgärdas utan dröjsmål och säkerhetsuppdateringarna ska distribueras kostnadsfritt. CRA föreskriver effektiva och regelbundna tester och granskningar av produktens säkerhet, vilket i praktiken brukar omsättas i sårbarhetsskanning, penetrationstester och kodgranskning, även om förordningen inte föreskriver exakta metoder. Information om åtgärdade sårbarheter ska delas, vilket i praktiken oftast sker genom CVE-poster och säkerhetsrådgivningar. Tillverkaren ska ha en policy för koordinerad sårbarhetsavslöjande som ger externa säkerhetsforskare en formell väg att rapportera fynd, och ska underlätta informationsutbyte med relevanta säkerhetsaktörer.
Värt att notera är att flera av dessa krav är öppet formulerade. CRA säger att tester ska ske, inte exakt hur ofta eller med vilka metoder. Det innebär att den faktiska tolkningen kommer att formas av harmoniserade standarder, sektorpraxis och, så småningom, regulatorisk vägledning. För många bolag kommer marknadsförväntningarna från större kunder i praktiken att driva fram en högre ambitionsnivå än vad lagtexten i sig kräver.
Två krav förtjänar särskild uppmärksamhet från ledningens sida eftersom de driver de mest kostsamma operativa programmen: SBOM-kravet och supportperioden.
SBOM: den tunga operativa lyftet
Software Bill of Materials, eller SBOM, är ett strukturerat dokument som listar de komponenter som ingår i produkten. CRA kräver att tillverkare identifierar och dokumenterar dessa komponenter, åtminstone på toppnivå, det vill säga de direkta beroendena. Många tillverkare väljer att gå djupare för produkter i högre klassificering.
CRA kräver inte generellt att SBOM:er publiceras publikt. De ska däremot hållas tillgängliga för relevanta myndigheter och kan i praktiken behöva delas med kunder eller regulatoriska motparter, särskilt i sektorer där kunderna själva har NIS2- eller DORA-skyldigheter. SBOM:en är primärt en intern compliance-tillgång som stöder sårbarhetshantering.
I praktiken är detta för de flesta bolag den enskilt största operativa insatsen som krävs av CRA. Det är inte ett tekniskt problem i den meningen att verktyg saknas, Syft, Trivy, Dependency-Track och kommersiella SCA-verktyg är väl etablerade. Utmaningen är att integrera SBOM-generering i ingenjörskulturen så att det blir en rutinmässig output från CI/CD-pipelinen snarare än en exceptionell aktivitet inför varje release. En manuell SBOM är inaktuell inom dagar och därför oanvändbar för löpande sårbarhetsövervakning.
För ledningar finns några konkreta beslutspunkter att fatta. Vilken granularitet ska SBOM:erna ha, bara toppnivå eller även transitiva beroenden? Vilken täckning ska de ha, bara applikationskoden eller även firmware, embedded operativsystem och container images? Hur ska SBOM-data hanteras från leverantörer, något som måste byggas in i upphandlings- och leverantörsavtal? Var ska SBOM:erna lagras, och hur länge? CRA kräver att teknisk dokumentation bevaras i minst tio år.
Hur lång tid SBOM-arbetet faktiskt tar varierar kraftigt beroende på portföljens storlek, befintlig teknisk skuld och hur långt utvecklingsorganisationen redan kommit med dependency tracking. Ett spann på sex till tolv månader är en rimlig planeringsgrund för bolag med någorlunda modern utvecklingsmiljö, men längre tidsåtgång är vanlig vid legacy-tunga portföljer. Sen start är den vanligaste schemamässiga felräkningen i hela CRA-implementeringen.
Supportperioden: ett strategiskt kommersiellt beslut
CRA kräver att tillverkaren bestämmer och offentliggör en supportperiod under vilken säkerhetsuppdateringar och sårbarhetshantering tillhandahålls. Perioden ska vara lämplig för produkten med hänsyn till dess förväntade användning och rimliga kundförväntningar, men minst fem år, om inte den förväntade användningstiden är kortare. Supportperioden ska deklareras till kunden vid försäljningstillfället.
Detta är ett beslut som tenderar att hamna i ingenjörsorganisationen som default, och det är ett misstag. Supportperioden är inte primärt ett tekniskt åtagande utan ett strategiskt kommersiellt beslut med långa konsekvenser. En produkt med fem års supportperiod som släpps i slutet av 2027 binder tillverkaren till sårbarhetshantering och uppdateringskapacitet ända in i 2032. För produkter med längre faktisk användningstid kan supportperioden behöva förlängas, vilket innebär att äldre versioner måste underhållas parallellt med utveckling av nya.
Det kan vara en legitim affärsstrategi att förkorta eller medvetet förnya produktlinjer för att linjera supportperioderna med engineering-kapaciteten, men det måste i så fall kommuniceras transparent. När supportperioden tar slut ska tillverkaren informera användare och, där det är relevant, marknadsövervakningsmyndigheter. En substantiell modifiering av en produkt efter att den ursprungliga supportperioden börjat löpa kan dessutom starta om hela tillverkaransvaret för den modifierade versionen.
Beslutet om supportperiod bör därför fattas av produktledningen och säkerhetsfunktionen tillsammans, medvetet och dokumenterat, inte landa som en bieffekt av en teknisk standardinställning.
Säker leverans av uppdateringar
Sårbarhetshanteringen är värdelös om uppdateringskanalen själv är osäker. CRA kräver inte bara att uppdateringar tillhandahålls utan också att de levereras säkert. I praktiken innebär det en autentiserad uppdateringskanal (typiskt kodsignering), integritetsskydd mot modifiering under överföring, skydd mot rollback-attacker där en angripare tvingar fram installation av en äldre sårbar version, samt atomicitet så att en uppdatering antingen genomförs fullt ut eller rullas tillbaka rent.
Det här blir ett område med betydande legacy-skuld för många bolag. Produkter som designats utan en uppdateringskanal står inför ett substantiellt omkonstruktionsarbete. Kompromettering av en uppdateringskanal kan vara katastrofalt, vilket SolarWinds-incidenten visade, och CRA ställer därför särskilt strikta krav på just denna komponent.
Den tekniska dokumentationen
För varje produkt ska tillverkaren upprätta och underhålla en teknisk dokumentationsfil som visar hur produkten möter de väsentliga kraven. Filen innehåller bland annat en allmän beskrivning av produkten, riskbedömningen, beskrivningar av design-, utvecklings- och sårbarhetshanteringsprocesserna, en bedömning av hur produkten möter varje tillämpligt krav, testrapporter, referenser till tillämpade standarder och EU-försäkran om överensstämmelse. Den ska bevaras i minst tio år efter att produkten placerats på marknaden.
För ledningen är detta inte bara ett administrativt åtagande utan en konkret leverabel som regulatorer, anmälda organ och i ökande utsträckning B2B-kunder kommer att efterfråga. En välordnad teknisk dokumentationsfil blir snabbt en kommersiell tillgång i upphandlingar mot motparter som själva är NIS2- eller DORA-reglerade.
Var ert befintliga säkerhetsarbete passar in
En fråga som dyker upp i nästan varje uppdrag är om befintligt säkerhetsarbete, ISO 27001, NIST SP 800-53, SOC 2, IEC 62443, OWASP ASVS, kan återanvändas för CRA-compliance. Det ärliga svaret är att det hjälper men inte ersätter.
ISO 27001 är ett informationssäkerhetsledningssystem fokuserat på organisatoriska processer. Det överlappar med kraven på sårbarhetshanteringsprocesser men adresserar inte produktens egna säkerhetsegenskaper. IEC 62443 är industristandarden som mappar väl mot CRA för industriprodukter och blir för många industribolag den naturliga startpunkten. OWASP ASVS mappar mot delar av produktkraven för mjukvaruprodukter, särskilt kring autentisering, sessionshantering och dataskydd.
Den praktiska rekommendationen är att mappa befintligt arbete mot CRA:s krav, identifiera luckor och adressera dessa snarare än att börja från noll. Harmoniserade standarder är under utveckling och förväntas successivt publiceras under 2026, vilket sannolikt kommer att minska gapet mellan befintliga ramverk och CRA-kraven. Erfarenhet från andra EU-standardiseringsprocesser talar dock för att tidsplanen kan glida.
En realistisk tidslinje för 2026 och 2027
Under första kvartalet 2026 bör scope-analys, aktörsklassificering, produktklassificering och en första gap-analys mot kraven vara på plats, liksom en utsedd exekutiv sponsor och en etablerad programstruktur.
Under andra kvartalet 2026 påbörjas engineering-arbetet på produktkraven. SBOM-programmet byggs ut, leverantörsavtalen börjar granskas, och för produkter i högre klassificering tas kontakt med möjliga anmälda organ. Kapaciteten för incidentrespons byggs ut inför rapporteringsskyldigheterna.
Under tredje kvartalet 2026 sker en operativ beredskapsgranskning inför att rapporteringsskyldigheterna börjar gälla 11 september 2026. Incident-runbooks ska vara färdiga och rapporteringskapaciteten live.
Under fjärde kvartalet 2026 stabiliseras rapporteringsdriften samtidigt som engineering- och processarbetet fortsätter. Eventuellt publicerade harmoniserade standarder bedöms och integreras.
Under första och andra kvartalet 2027 närmar sig conformity assessment-beredskapen. Den tekniska dokumentationen utarbetas, och för produkter som kräver ett anmält organ påbörjas den formella bedömningen. Tredje kvartalet 2027 är slutförberedelser inför full tillämpning i december.
De vanligaste felmodena
Det finns några återkommande misstag som bolag gör i CRA-implementeringen, och som ledningen kan motverka genom att vara medveten om dem från början.
Att behandla CRA som ett juridiskt projekt. En respons som består av att uppdatera policyer och kontrakt utan underliggande förändring i engineering och process är otillräcklig.
Att underskatta SBOM-arbetet. Som beskrivits ovan är detta det enskilt vanligaste schemamissförståndet.
Att vänta med anmälda organ. Bolag med produkter i klass II eller högre som väntar till 2027 riskerar att möta kapacitetsproblem.
Att glömma legacy-portföljen. Rapporteringsskyldigheterna från september 2026 gäller även befintliga produkter på marknaden.
Att hantera CRA isolerat. Bolag som är både CRA-tillverkare och NIS2-reglerade entiteter bör bygga integrerade compliance-program. Sårbarhetshantering, incident-runbooks och leverantörsuppföljning kan i hög grad samutnyttjas.
Att betrakta arbetet som ett engångsprojekt. CRA är en livscykelreglering, och compliance som inte etablerar en löpande operativ kapacitet kommer att fallera under år två eller tre när supportskyldigheterna börjar bita.
Vad ledningen behöver besluta, och när
Det är inte ledningens roll att skriva den tekniska dokumentationen eller bygga SBOM-pipelinen. Men ett antal beslut kan bara fattas av ledningen, och de avgör om resten av programmet kommer att kunna genomföras.
Vem är exekutiv sponsor? CRA-program utan en tydlig sponsor i ledningen tenderar att förlora prioritet mot kommersiella projekt.
Vilka produkter omfattas, och vilka behöver omklassificeras eller fasas ut? Detta är ett kommersiellt beslut lika mycket som ett tekniskt, vissa äldre produkter kan vara billigare att avveckla än att modernisera.
Vilken supportperiod ska kommuniceras till kunden? Detta beslut formar er engineering-belastning i fem år framåt och bör inte fattas tekniskt.
Hur stor budget ska programmet ha, och över hur lång tid? Realistiska program löper över 18–24 månader med tyngdpunkten under 2026.
Hur ska arbetet integreras med andra regulatoriska program? Om er organisation är NIS2-reglerad, GDPR-exponerad eller DORA-träffad är ett integrerat angreppssätt billigare och mer försvarbart än parallella spår.
CRA innebär en strukturell förändring av hur ansvar för produktcybersäkerhet allokeras på EU-marknaden. För ledningen är frågan inte om bolaget kommer att möta dessa krav, utan om man gör det med kontroll över sekvensen eller pressad av deadlines man satt sig själv på.