Artikel 13(8) i EU:s cyberresilienslag (förordning (EU) 2024/2847) kräver att tillverkare levererar säkerhetsuppdateringar kostnadsfritt och utan onödigt dröjsmål under hela stödperioden. Den här sidan täcker leveransmekaniken för inbyggda, fristående, SaaS- och hybridarkitekturer. För varaktighetsmekaniken, se CRA Stödperiod: Grunderna; för redovisning innan köp, se redovisning av stödperiodens slut.
Sammanfattning
- Säkerhetsuppdateringar är inte funktionsuppdateringar. En ändring som åtgärdar en sårbarhet regleras av Artikel 13(8):s krav på kostnad och kadens; en ändring som tillför ny funktionalitet gör det inte.
- Kostnadsfritt enligt Artikel 13(8). Tillverkare får inte bunta ihop säkerhetskorrigeringar med betalda prenumerationer, premiumtjänster eller uppgraderingar till ny huvudversion.
- Automatiskt där det är möjligt enligt Bilaga I Del II. Led 7 kräver säkra distributionsmekanismer med automatisk leverans där det är tillämpligt; led 8 kräver distribution utan dröjsmål.
- "Utan onödigt dröjsmål" styrs av allvarlighetsgrad. Branschstandard är dagar för aktivt utnyttjade kritiska problem, 30 dagar för hög allvarlighetsgrad, 90 dagar för medel och nästa ordinarie cykel för låg.
- Arkitekturen förändrar leveransmodellen. Inbyggd firmware, fristående programvara, SaaS och hybridprodukter har var sin leveransmekanism som den tekniska filen måste dokumentera.
- Artikel 14-rapportering samverkar med uppdateringscykeln. När en aktivt utnyttjad sårbarhet detekteras löper den 24-timmarslånga tidiga varningen till ENISA parallellt med patchprocessen; uppdateringsmekanismen måste vara kopplad till rapporteringsarbetsflödet.
De fyra ankarpunkterna för CRA:s efterlevnad av säkerhetsuppdateringar: kostnadsregeln, distributionspreferensen, kadensförväntningen och taket för böter.
Att ta betalt för säkerhetsuppdateringar är en av de mest direkta vägarna till ett konstaterande av bristande efterlevnad. Om en korrigering som åtgärdar en sårbarhet bara är tillgänglig för kunder på en betald supportnivå, bakom en premiumprenumeration eller i en uppgradering till ny huvudversion prissatt som en ny release, uppfyller det inte Artikel 13(8). Grundläggande säkerhetspatchar måste vara tillgängliga för samtliga användare av produkten som placerats på marknaden, utan extra kostnad, under hela stödperioden. Funktionsreleaser, professionella tjänster och valfria funktioner kan fortfarande ta betalt. Gränsdragningen är om ändringen åtgärdar en sårbarhet.
Vad som räknas som en säkerhetsuppdatering
Artikel 13(2) i cyberresilienslagen kräver att tillverkare designar och producerar produkter som är "säkra som standard" och som säkerställer "konfidentialitet, integritet och tillgänglighet för data". Artikel 13(8) kräver sedan att sårbarheter som upptäcks efter marknadsplaceringen hanteras under stödperiodens varaktighet.
En säkerhetsuppdatering enligt CRA är en ändring som åtgärdar en sårbarhet, en svaghet i produkten som kan utnyttjas för att kompromissa konfidentialitet, integritet eller tillgänglighet. Skillnaden från en funktionsuppdatering är viktig av två skäl: säkerhetsuppdateringar måste vara kostnadsfria och måste levereras utan onödigt dröjsmål, medan funktionsuppdateringar inte bär någondera skyldigheten.
| Uppdateringstyp | Skyldighet enligt Artikel 13(8) | Får avgift tas ut? |
|---|---|---|
| Patch som åtgärdar ett känt CVE | Ja (säkerhetsuppdatering) | Nej |
| Härdningsändring som minskar attackytan | Ja (säkerhetsuppdatering) | Nej |
| Ny funktion utan säkerhetsrelevans | Nej | Ja |
| Ny huvudversion med nya funktioner | Nej (om den inte innehåller säkerhetskorrigeringar) | Ja |
| Beroenduppdatering för att eliminera en känd sårbarhet | Ja (säkerhetsuppdatering) | Nej |
| Konfigurationsändring för att täppa till en säkerhetslucka | Ja (säkerhetsuppdatering) | Nej |
"Utan onödigt dröjsmål" definieras inte numeriskt i förordningen, men den allmänna förväntningen från marknadskontrollmyndigheter och ENISA:s vägledning stämmer överens med branschpraxis kopplad till allvarlighetsgrad. Diagrammet nedan visar patchfönstret per allvarlighetsnivå, mätt från det ögonblick sårbarheten offentliggörs (T0):
| Allvarlighetsgrad | Branschstandard |
|---|---|
| Kritisk (aktivt utnyttjad) | Dagar, inte veckor |
| Hög (enkelt att utnyttja på distans) | Inom 30 dagar |
| Medel | Inom 90 dagar |
| Låg | Ingår i nästa ordinarie uppdateringscykel |
Det är inte CRA-föreskrivna tidsramar, men de representerar den standard mot vilken "utan onödigt dröjsmål" bedöms i tillsynsärenden.
Hur man levererar CRA-säkerhetsuppdateringar
Automatiska uppdateringar
Där det är tekniskt möjligt och lämpligt föredrar Artikel 13(8) och Bilaga I Del II automatiska säkerhetsuppdateringar. Produkten bör kunna ta emot och tillämpa uppdateringar utan att användaren behöver vidta manuella åtgärder.
Krav för en efterlevnadsenlig automatisk uppdateringsmekanism:
- Säker nedladdningskanal (TLS, signerade paket)
- Integritetskontroll innan installation
- Återställningsmöjlighet om en uppdatering misslyckas
- Lämplig hantering av anslutningsproblem
- Synlighet för användaren om uppdateringsstatus
Användaren måste behålla möjligheten att välja bort automatiska uppdateringar, med en tydlig varning om säkerhetskonsekvenserna av detta. För kritiska säkerhetsuppdateringar kan tillverkaren utforma systemet för att tillämpa uppdateringen utan att kunna skjutas upp. Artikel 13(8) stöder detta när risken motiverar det.
Manuella uppdateringar
Produkter som inte kan ta emot automatiska uppdateringar (luftgapade industriella system, inbyggda enheter utan anslutning, viss medicinsk eller säkerhetskritisk utrustning) kräver en manuell uppdateringsleveransprocess:
- Nedladdningsbara uppdateringspaket med tydlig versionshantering
- Kryptografiska signaturer och publicerade publika nycklar för verifiering
- Installationsdokumentation
- Avisering via alla tillgängliga kanaler (e-post, webbportal, produktgränssnitt, fysisk avisering om nödvändigt)
Inbyggd firmware och SaaS: olika uppdateringsmodeller
Leveransmekanismen för uppdateringar skiljer sig avsevärt beroende på produktarkitektur:
| Produkttyp | Uppdateringsmodell | Viktig CRA-hänsyn |
|---|---|---|
| Inbyggd firmware (IoT, industriell) | Tillverkaren skickar signerad firmware; kunden tillämpar | Måste ha OTA-kapabilitet eller dokumenterad manuell process; långa enhetslivslängder kan driva den förväntade användningstiden nära fem år |
| Fristående programvara (dator, server) | Tillverkaren släpper paket; kunden installerar | Automatisk uppdateringsagent föredras; versionslåsning av företagskunder skapar börda med stöd för flera versioner |
| SaaS / molnbaserad | Tillverkaren kontrollerar miljön; uppdateringar är transparenta för användaren | Klockan startar fortfarande vid marknadsplacering; stödperioden är meningsfull huvudsakligen för lokalt installerade eller hybridkomponenter; API-versionshantering skapar egna stödåtaganden |
| Hybrid (lokal agent + molnbackend) | Agentuppdateringar styrs av tillverkaren; backenduppdateringar är transparenta | Varje komponent har sin egen stödperiodsklocka; agenten är produkten med digitala element och den klockan gäller |
För bredare Bilaga I Del II-sårbarshetshantering utöver uppdateringsleverans (CVD-policy, offentligt offentliggörande, rapportering från tredje part), se guiden för sårbarshetshantering.
Rapporteringsskyldigheter för sårbarheter under och efter stödperioden
Artikel 14 ålägger tillverkare tidsbundna rapporteringsskyldigheter för aktivt utnyttjade sårbarheter och allvarliga incidenter. Dessa skyldigheter gäller under stödperioden.
Den viktigaste samverkan:
| Fas | Rapporteringsskyldighet enligt Artikel 14 |
|---|---|
| Under stödperioden | Artikel 14 gäller fullt ut: 24-timmars tidig varning, 72-timmarsanmälan, slutrapport efter 14 dagar för aktivt utnyttjade sårbarheter; 24h / 72h / 1 månad för allvarliga incidenter. Via ENISA:s enda rapporteringsplattform. |
| Efter stödperiodens slut | Ingen rapporteringsskyldighet enligt Artikel 14 för sårbarheter som upptäcks efter EOL. Om tillverkaren blir medveten om en kritisk, aktivt utnyttjad sårbarhet i en produkt utan stöd som påverkar en stor installerad bas, finns ingen obligatorisk rapportering. Ansvarsfull redovisning och användarinformation rekommenderas starkt av reputationsskäl och för samarbete med marknadskontrollmyndigheter. |
Stödperiodens slutdatum är därmed också horisonten för Artikel 14. När stödperioden löper ut har tillverkaren ingen skyldighet att undersöka, patcha eller rapportera sårbarheter som upptäcks i den produktversionen. Marknadskontrollmyndigheter kan fortfarande utreda enligt Artikel 58 om produkten utgör en betydande cybersäkerhetsrisk, men den löpande skyldigheten för sårbarshetshantering enligt Artikel 13(8) har upphört.
För den fullständiga tidslinjemekaniken i Artikel 14, inklusive vad varje rapport måste innehålla och hur de två rapporteringsströmmarna (aktivt utnyttjade sårbarheter och allvarliga incidenter) skiljer sig åt, se guiden för sårbarshetsrapportering.
Vanliga misstag
Att ignorera transitiva beroenden. De flesta sårbarheter i uppkopplade produkter härstammar från tredjepartsbibliotek och -komponenter, inte från tillverkarens egen kod. Skyldigheten enligt Artikel 13(8) täcker hela produkten, inte bara koden tillverkaren har skrivit. En SBOM är förutsättningen. Se SBOM-klusterguiden för det ramverk för beroendeövervakning som gör transitiv sårbarshetsövervakning operationell.
Att ta betalt för säkerhetsuppdateringar. Att bunta ihop säkerhetskorrigeringar i en betald supportnivå strider mot Artikel 13(8). Grundläggande säkerhetspatchar måste vara gratis.
Vanliga frågor
Måste säkerhetsuppdateringar alltid vara gratis?
Ja. Artikel 13(8) kräver att säkerhetsuppdateringar tillhandahålls kostnadsfritt. En tillverkare kan inte bunta ihop en säkerhetskorrigering i en betald prenumeration, en premium-supportnivå eller en uppgradering till ny huvudversion och göra anspråk på efterlevnad av Artikel 13(8). Funktionsuppdateringar, ny funktionalitet och betalda professionella tjänster är separata och kan debiteras normalt. Skyldigheten är begränsad till uppdateringar som åtgärdar sårbarheter: ändringar som avhjälper en säkerhetssvaghet i produkten som placerats på marknaden.
Hur snabbt måste en tillverkare släppa en säkerhetsuppdatering enligt CRA?
CRA:s Artikel 13(8) kräver säkerhetsuppdateringar "utan onödigt dröjsmål" men definierar inte en numerisk tidsgräns. Marknadskontrollmyndigheter och ENISA:s vägledning stämmer överens med branschpraxis kopplad till allvarlighetsgrad: kritiska aktivt utnyttjade sårbarheter bör patchas inom dagar, hög allvarlighetsgrad inom ungefär 30 dagar, medel inom 90 dagar och låg allvarlighetsgrad bundlas i nästa ordinarie uppdateringscykel. Det är inte CRA-föreskrivna tidsramar men representerar den standard mot vilken "utan onödigt dröjsmål" bedöms vid tillsyn. Tillverkare bör spåra faktisk tid-till-patch per CVE så att avvikelser från denna baslinje är synliga och försvarliga.
Kräver CRA automatiska uppdateringar?
Inte i alla fall. Bilaga I Del II led 7 kräver att tillverkare tillhandahåller säkra distributionsmekanismer med automatisk leverans "där det är tillämpligt". För produkter med tillförlitlig anslutning och inget verksamhetsskäl att skjuta upp, är automatiska uppdateringar det förväntade standardalternativet. För luftgapade industriella system, vissa medicintekniska produkter eller säkerhetskritisk utrustning där automatisk patchinstallation kan störa driften, är en dokumenterad manuell uppdateringsprocess acceptabel. Den tekniska filen i Bilaga VII måste motivera den valda metoden. Användarna måste behålla möjligheten att välja bort automatiska uppdateringar med tydliga varningar om säkerhetskonsekvenserna, utom när risken motiverar en kritisk korrigering som inte kan skjutas upp.
Har en SaaS-produkt en CRA-stödperiod?
Det beror på om SaaS-produkten faller inom CRA:s tillämpningsområde som en produkt med digitala element. Rena SaaS-tjänster som inte levereras med en hårdvarukomponent eller nedladdningsbar programvaruagent är i allmänhet utanför tillämpningsområdet enligt Artikel 2(1). Om en SaaS-produkt inkluderar en lokal agent, en nedladdningsbar klient eller en hårdvarugateway som placeras på EU-marknaden, är den komponenten inom tillämpningsområdet och dess stödperiodsklocka enligt Artikel 13(8) startar vid marknadsplacering. Den molnbaserade backend-tjänsten, när den är under tillverkarens kontroll och kontinuerligt uppdateras, uppfyller vanligtvis skyldigheten att patcha "utan onödigt dröjsmål" genom transparent driftsättning, men tillverkaren måste fortfarande dokumentera stödåtagandet i Bilaga II-informationen för den komponent som är inom tillämpningsområdet.
Vad händer med säkerhetsuppdateringar efter att CRA-stödperioden upphör?
Skyldigheterna enligt Artikel 13(8) upphör med stödperioden. När det redovisade slutdatumet har passerat har tillverkaren ingen CRA-skyldighet att undersöka, patcha eller distribuera säkerhetsuppdateringar för den produktversionen, och rapporteringsskyldigheterna enligt Artikel 14 upphör också eftersom de endast gäller under stödperioden. Marknadskontrollmyndigheter kan fortfarande utreda enligt Artikel 58 om produkten utgör en betydande cybersäkerhetsrisk efter EOL, men den dagliga skyldigheten för sårbarshetshantering har upphört. Tillverkare bör tydligt kommunicera stödet upphör till användarna i förväg; slutdatumsredovisningen i Bilaga II led k är det användarorienterade instrumentet för det. Att fortsätta tillhandahålla goodwill-patchar efter EOL är tillåtet men inte obligatoriskt.