EU-förordning 2024/2847
Cyber Resilience Act trädde i kraft december 2024. Sårbarhetsrapportering till ENISA är obligatorisk från september 2026. Full efterlevnad krävs från december 2027. Säljer ni hårdvara eller mjukvara i EU måste ni vara klara innan dess.
Den här sidan är en konkret checklista, inte en juridisk översikt. Stora drag och tekniska åtgärder vi har sett fungera. För juridisk bedömning, prata med jurist.
Berör det er
Två förordningar, två scope. CRA är "product safety": ni säljer en produkt. NIS2 är "essential service": ni driftar en kritisk tjänst. Många bolag berörs av båda, ofta utan att vara medvetna om det.
IoT-tillverkare, embedded-mjukvara, downloadable software, smart-home, OT, industri-firmware, on-prem-appliances, mobil-appar, browser-extensions, SaaS som integreras i en produkt. Ren molntjänst (utan installation) är undantagen art. 2(5).
Energi, vård, transport, vatten, digital infrastruktur (datacenter, CDN, cloud), public administration, post, kemi, livsmedel, tillverkning. Mellanstora och stora bolag i sektorerna omfattas automatiskt.
Vanligast: IoT-bolag som även har egen molnplattform, säkerhetsleverantörer med både SaaS och on-prem-appliance, e-handelsplattformar som distribuerar plugins. Två separata compliance-spår — försök inte slå ihop dem.
Konsultbyråer, advokatbyråer, mindre webbyråer som bygger åt kund (kunden är CRA-tillverkare). Ni har inga CRA-skyldigheter direkt, men ert ansvar kan komma via kundens leverantörsled (Art. 14(2) supplier-disclosure).
Checklista
CycloneDX eller SPDX-format, genererad i CI vid varje release. Inkluderar transitiva beroenden, licens och version. Hålls tillgänglig för marknadstillsyn — behöver INTE publiceras publikt (CRA art. 13).
Publicerad process för hur ni tar emot, triagerar och åtgärdar sårbarhetsrapporter. RFC 9116 security.txt och Coordinated Vulnerability Disclosure-policy. Bilaga I del 2 i CRA kräver detta.
Aktivt utnyttjade sårbarheter och allvarliga incidenter rapporteras till ENISA single-reporting-platform inom 24 timmar (art. 14). En e-postadress + en runbook räcker initialt.
Definierad och kommunicerad support-period (förväntad livslängd för produkten). Säkerhetspatchar skickas gratis under hela support-perioden. Slutdatum publicerat tydligt.
Inga default-lösenord. MFA-stöd inbyggt. Krypterad kommunikation som default. Minsta privilegium. Dokumentera vilka säkerhetsegenskaper produkten har och varför.
Cybersäkerhets-riskbedömning per produkt (vilka hot, vilka mitigeringar). Teknisk dokumentation som visar att produkten uppfyller bilaga I-krav. Sparas i 10 år efter sista enheten släppts på marknaden.
Produkter får inte säljas i EU utan CE-märke. Standardprodukter använder intern egendeklaration. "Important" och "critical" PDE kräver tredjepartsbedömning (notified body). Anmäld instans måste vara plats minst 6 mån innan.
Era leverantörer (open source, kommersiella komponenter) måste rapportera sårbarheter till er inom skälig tid (art. 14(2)). Ni måste i sin tur välja komponenter som "kontinuerligt underhålls". Open source-stiftelser har lättare regelverk.
Vad vi gör för er
Vi tar inte CE-märkningen åt er och vi skriver inte er juridiska riskbedömning. Det är hörnstenar som måste sitta hos er egen organisation. Däremot bygger vi den tekniska bevisföringen som CRA kräver att ni kan visa upp.
Vidare läsning: vår genomgång av CRA 2027, API-säkerhetsanalys, strategisk säkerhetsanalys.
FAQ
Nej. CRA art. 13 kräver att SBOM ska vara "tillgänglig för marknadstillsyn" (ENISA, nationella myndigheter), inte publicerad. Många bolag (inklusive oss) håller den privat eftersom en publik SBOM ger angripare en exakt karta över beroenden. Kunder som behöver den för due diligence får den under NDA.
En sårbarhet i er produkt där ni har bekräftade tecken på faktisk exploit i naturen (incident hos kund, IOC i logs, leakad exploit-kod publicerad). Att en CVE har en POC räcker inte. Tröskeln är högre än NIS2-incidentrapportering.
Beror på. Ren molntjänst utan installerad komponent hos kund är undantagen art. 2(5) — den hör hemma under NIS2 istället. Om ni har en CLI, browser-extension, mobil-app, plugin eller on-prem-appliance så är DEN delen CRA-scope. Många bolag har båda spåren.
Ni är CRA-tillverkare för slutprodukten oavsett om beroendena är OSS eller kommersiella. Open source-projekt har lättare regelverk (om de drivs av en stiftelse), men er produkt med samma OSS i sig omfattas fullt ut. Krav: välj komponenter som "kontinuerligt underhålls", spåra dem i SBOM, övervaka för CVE.
Ja, om ni säljer produkten i EU. CRA har inga storleksundantag (till skillnad från NIS2 som börjar vid 50 anställda). En enmans-konsult som säljer en IoT-prylkomponent måste uppfylla samma tekniska krav som en stor tillverkare. Vissa förenklade procedurer finns för "microenterprise" men inte undantag.
Upp till 15 miljoner euro eller 2,5% av global omsättning (det högsta), per art. 64. För mindre överträdelser (felaktig dokumentation) 5 miljoner euro eller 1% av omsättningen. Marknadstillsyn kan också beordra återkallande av produkt från EU-marknaden.
Ni får en uppriktig bedömning av vad som krävs och vad som kan vänta. Inget säljsnack. Om ni inte behöver oss säger vi det.