Vad innebär Cyber Resilience Act för programvara?

Cyber Resilience Act (CRA) är en EU-förordning som ställer cybersäkerhetskrav på alla produkter med digitala element under hela livscykeln, och bevisar kraven genom CE-märkning. Den flyttar ansvaret för säker mjukvara till den som tillverkar och säljer den.

CRA trädde i kraft 10 december 2024. Skyldigheterna fasas in stegvis fram till 11 december 2027, men rapporteringsplikten blir skarp redan 11 september 2026. För er som bygger eller köper programvara är säkerhet inte längre en frivillig kvalitetsfråga. Det är ett lagkrav med CE-märkning, dokumentation och böter knutna till sig.

Varför det spelar roll

I tjugo år har ansvaret för säker mjukvara legat hos den som driver systemet, inte hos den som byggde det. CRA vänder på den ordningen. Den som släpper en produkt på EU-marknaden ska kunna visa tre saker. Produkten är säker i sin standardkonfiguration, den får säkerhetsuppdateringar under en definierad supportperiod, och kända sårbarheter hanteras enligt en fastlagd process.

Det här berör fler än de uppenbara hårdvarutillverkarna. En produkt med digitala element är all mjukvara och hårdvara som kan anslutas till en enhet eller ett nätverk. Ett affärssystem, en mobilapp, en uppkopplad sensor och ett bibliotek som säljs som komponent kan alla omfattas. Skillnaden mot tidigare är att kravet följer produkten ut på marknaden, inte organisationen som råkar driva den.

För svenska verksamheter landar CRA mitt i en redan tät regulatorisk höst. Cybersäkerhetslagen (SFS 2025:1506) trädde i kraft 15 januari 2026 och genomför NIS2 i svensk rätt, med MSB som nationell kontaktpunkt och CSIRT. Den som bygger och driver mjukvara behöver hantera båda. CRA reglerar produkten ni bygger eller köper, Cybersäkerhetslagen reglerar organisationen som driver tjänsten.

Hur det fungerar

CRA bygger på fyra mekanismer som hänger ihop: väsentliga krav, bevis genom överensstämmelse, en rapporteringskedja och en livscykelplikt.

De väsentliga kraven. Annex I beskriver vad en säker produkt är. Den ska levereras utan kända exploaterbara sårbarheter, vara säker i sin standardkonfiguration, skydda data i vila och under överföring, och minimera angreppsytan. Tillverkaren ska också ha en process för att hantera sårbarheter under hela supportperioden.

Bevis genom överensstämmelse. De flesta produkter får tillverkaren bedöma själv genom intern kontroll och sedan CE-märka. Annex III listar viktiga produkter i två klasser. Class II och de kritiska produkterna i Annex IV kräver ett anmält organ som gör en oberoende EU-typkontroll. Genomförandeförordning (EU) 2025/2392, antagen 28 november 2025, definierar exakt vilka kategorier som räknas hit.

Rapporteringskedjan. Det här är delen som blir skarp först. För en aktivt utnyttjad sårbarhet eller en allvarlig incident gäller tre steg:

Steg	Tidsgräns	Innehåll
Tidig varning	inom 24 timmar	första signal om händelsen
Notifiering	inom 72 timmar	mer fullständig beskrivning
Slutrapport	senast 14 dagar	efter att en åtgärd finns tillgänglig

Rapporterna lämnas via CRA Single Reporting Platform (SRP), som ENISA etablerar och driver enligt Artikel 16. Plattformen ska vara operativ senast 11 september 2026, med en testperiod innan.

Livscykelplikten. En SBOM (software bill of materials), en maskinläsbar förteckning över komponenter och beroenden, ska skapas och hållas aktuell. När en sårbarhet upptäcks i ett beroende ska tillverkaren kunna avgöra om den egna produkten påverkas och agera. SBOM:en behöver skapas men inte publiceras.

När det passar

CRA-arbete är rätt att prioritera nu om något av följande stämmer in på er:

• Ni utvecklar eller säljer en produkt som distribueras separat. Det gäller mjukvara, firmware, en app eller en hårdvaruenhet som hamnar hos en kund eller på en publik marknadsplats.
• Ni levererar en komponent eller ett SDK som andra bygger in i sina produkter. Då blir ni en del av kundens överensstämmelsekedja och behöver kunna leverera SBOM och sårbarhetsinformation.
• Ni driver en open source-funktion i kommersiellt sammanhang och kan klassas som steward enligt Artikel 24.
• Ni köper in programvara och vill kunna kräva CE-märkning, SBOM och en supportperiod i upphandlingen. CRA ger inköparen ett konkret språk att ställa krav på.

För den som bygger något som ska säljas eller distribueras är rapporteringsklockan i september 2026 den första hårda deadline att planera mot.

När det inte passar

CRA gäller inte allt, och att försöka CE-märka det som ligger utanför scope är bortkastat arbete.

• Ren tjänsteleverans. En SaaS-tjänst eller ett system ni driver åt en kund utan att leverera en distribuerbar produkt faller i regel utanför CRA och hanteras i stället av NIS2 och Cybersäkerhetslagen. Gränsdragningen kan vara hårfin och bör verifieras per fall.
• Produkter som redan täcks av sektorslagstiftning. Medicintekniska produkter, fordon och viss luftfartsutrustning regleras av egna ramverk och undantas helt eller delvis.
• Icke-kommersiell öppen källkod. Programvara som utvecklas och tillhandahålls utanför kommersiell verksamhet omfattas inte av tillverkarskyldigheterna.
• Produkter som redan finns på marknaden och inte ändras väsentligt. De omfattas fullt ut först vid en väsentlig modifiering, vilket ger en mjukare övergång för befintlig portfölj.

Den vanligaste feldispositionen är att lägga CRA-resurser på tjänster som egentligen är ett NIS2-ärende. Att först klassa varje produkt och tjänst sparar arbete senare.

Konkret exempel

Tänk er en svensk leverantör som säljer en uppkopplad mätenhet med tillhörande molnapp till kommuner. Hårdvaran med inbyggd firmware är en produkt med digitala element och omfattas av CRA. Den ska CE-märkas, levereras säker i sin standardkonfiguration och ha en deklarerad supportperiod. Molnappen som distribueras till slutanvändarna omfattas också. Driften av kommunens egna system, däremot, faller under Cybersäkerhetslagen eftersom kommunen är operatör av en samhällsviktig tjänst.

För att klara rapporteringskedjan behöver leverantören kunna gå från upptäckt av en aktivt utnyttjad sårbarhet till en tidig varning inom 24 timmar. Det förutsätter en SBOM som säger vilka beroenden som faktiskt finns i den levererade firmwaren, ett sätt att matcha nya sårbarheter mot den listan, och en etablerad kanal in i ENISA:s rapporteringsplattform.

På Digitalist arbetar vi med SBOM som en del av hur vi bygger och förvaltar system, så att en leverans går att spåra ner till sina beroenden. I de verksamhetskritiska system vi förvaltar möts ofta produktkrav och organisationskrav i samma leverans, vilket gör gränsdragningen mellan CRA och Cybersäkerhetslagen till en konkret fråga snarare än en teoretisk. Vår ISO 27001-certifiering innebär att en process för sårbarhetshantering redan finns på plats, inte efterhandskonstruerad när första rapporten ska skickas.

Vanliga missförstånd

“CRA gäller först 2027, vi har gott om tid.” De fulla produktkraven gäller från 11 december 2027, men rapporteringsplikten för aktivt utnyttjade sårbarheter och allvarliga incidenter blir skarp redan 11 september 2026. Den som väntar på 2027 har missat den första hårda deadline med över ett år.

“SBOM är ett dokument vi tar fram vid behov.” En SBOM som skrivs i efterhand, genom att skanna en färdig binär, missar ofta djupa transitiva beroenden. CRA förutsätter en levande förteckning som hålls aktuell under hela supportperioden och som går att matcha mot nya sårbarheter samma dag de blir kända.

“CRA och NIS2 är samma sak.” De överlappar i ämne men reglerar olika saker. CRA är en förordning om produkten, bevisad med CE-märkning. NIS2 är ett direktiv om organisationen, i Sverige genomfört som Cybersäkerhetslagen. Att ha NIS2-arbetet på plats betyder inte att produktkraven i CRA är uppfyllda.

CRA gör det som goda utvecklingsteam redan vet till ett krav med datum, dokumentation och CE-märke. Den som börjar med att klassa sina produkter och sätta upp SBOM och rapporteringskanal nu möter september 2026 förberedd i stället för överraskad.

Källor

• Cyber Resilience Act, Europeiska kommissionen, Shaping Europe’s digital future, 2026: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CRA Summary of the legislative text (infasningsdatum), Europeiska kommissionen, 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• CRA Reporting obligations (Artikel 14 och 16, ENISA SRP), Europeiska kommissionen, 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• CRA Conformity assessment (produktklasser och CE-märkning), Europeiska kommissionen, 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-conformity-assessment
• Genomförandeförordning (EU) 2025/2392, antagen 28 november 2025, EUR-Lex: https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj/eng
• NIS2 Sweden / Cybersäkerhetslagen SFS 2025:1506 / MSB, Resiliently, 2026: https://resiliently.ai/blog/posts/nis2-sweden-msb-compliance-guide-2026