EU:s Cyber Resilience Act (Förordning (EU) 2024/2847) kräver att tillverkare hanterar sårbarheter under stödperioden och, när säkerhetsuppdateringar finns tillgängliga, distribuerar dem utan dröjsmål och kostnadsfritt. Den här sidan beskriver hur uppdateringar levereras i inbyggda, fristående, SaaS- och hybridarkitekturer. För stödperiodens längd, se grunderna för stödperioden; för information före köp, se redovisning av stödperiodens slut.
Sammanfattning
- Säkerhetsuppdateringar är inte funktionsuppdateringar. En ändring som åtgärdar en sårbarhet följer skyldigheterna för säkerhetsuppdateringar; en ny funktion gör det inte.
- Säkerhetskorrigeringar ska inte ligga bakom betalnivåer. Tillgängliga säkerhetsuppdateringar bör spridas utan dröjsmål och kostnadsfritt, med rådgivande meddelanden som berättar för användarna vad uppdateringen åtgärdar och vilken åtgärd som krävs, utom när annat avtalats för skräddarsydda produkter för företagsanvändare.
- Automatiskt där det är tillämpligt. Automatiska säkerhetsuppdateringar är standarddesignen där det är rimligt, med säkra distributionsmekanismer och tydliga användarkontroller.
- Patchmål bör följa allvarlighetsgrad. Praktiska mål är dagar för aktivt utnyttjade kritiska sårbarheter, 30 dagar för hög, 90 dagar för medel och nästa ordinarie cykel för låg.
- Arkitekturen styr leveransmodellen. Inbyggd firmware, fristående programvara, SaaS och hybrider har olika mekanismer som den tekniska dokumentationen måste beskriva.
- Rapportering hänger ihop med uppdateringscykeln. När en aktivt utnyttjad sårbarhet upptäcks löper 24-timmarsvarningen till den samordnande CSIRT och ENISA parallellt med patchprocessen; uppdateringsmekanismen måste mata rapporteringsflödet.
De fyra ankarpunkterna för CRA-efterlevnad av säkerhetsuppdateringar: kostnadsregel, distributionspreferens, uppdateringstillgänglighet och sanktionsmodell.
För sanktionsnivåer, se guiden om sanktioner och tillsyn.
Vad som räknas som en säkerhetsuppdatering
Uppdateringsskyldigheten börjar med produktens cybersäkerhetsriskbedömning och de säkerhetsegenskaper som är tillämpliga. Säker standardkonfiguration, konfidentialitet, integritet och tillgänglighet avgör om en ändring är säkerhetsrelevant. Tillverkaren måste därefter hantera sårbarheter effektivt under stödperioden.
En säkerhetsuppdatering är en ändring som åtgärdar en sårbarhet, alltså en svaghet i produkten som kan utnyttjas för att skada konfidentialitet, integritet eller tillgänglighet. Skillnaden mot en funktionsuppdatering är viktig: tillgängliga säkerhetsuppdateringar måste vara kostnadsfria och distribueras utan dröjsmål; funktionsuppdateringar har inte de skyldigheterna.
| Typ av uppdatering | Skyldighet för säkerhetsuppdatering | Kan debiteras? |
|---|---|---|
| Patch för känd CVE | Ja (säkerhetsuppdatering) | Nej |
| Härdning som minskar angreppsytan | Ja (säkerhetsuppdatering) | Nej |
| Ny funktion utan säkerhetsrelevans | Nej | Ja |
| Ny huvudversion med nya funktioner | Nej (om den inte innehåller säkerhetsfixar) | Ja |
| Dependency-uppdatering som tar bort känd sårbarhet | Ja (säkerhetsuppdatering) | Nej |
| Konfigurationsändring som stänger en säkerhetslucka | Ja (säkerhetsuppdatering) | Nej |
Utan dröjsmål definieras inte med ett antal dagar i förordningen. Tillverkaren bör ändå sätta mål per allvarlighetsgrad, så att patchbeslut blir konsekventa, dokumenterade och möjliga att förklara. Diagrammet visar ett praktiskt patchfönster från det att tillverkaren får kännedom om sårbarheten:
| Allvarlighetsgrad | Praktiskt operativt mål |
|---|---|
| Kritisk (aktivt utnyttjad) | Dagar, inte veckor |
| Hög (lätt att utnyttja på distans) | Inom 30 dagar |
| Medel | Inom 90 dagar |
| Låg | I nästa ordinarie cykel |
Detta är inte CRA-föreskrivna tidsfrister. Det är interna mål som hjälper tillverkaren visa att dröjsmål var kontrollerat, riskbaserat och dokumenterat.
Hur man levererar CRA-säkerhetsuppdateringar
Automatiska uppdateringar
Där det är tekniskt möjligt och lämpligt är automatiska säkerhetsuppdateringar den föredragna designen. En förenlig automatisk modell bör aktivera säkerhetsuppdateringar som standard, ge en tydlig möjlighet att välja bort, avisera tillgängliga uppdateringar, tillåta tillfälligt uppskov där det är lämpligt och distribuera uppdateringar säkert.
En välutformad mekanism för automatiska uppdateringar bör ge:
- Säker nedladdningskanal (TLS, signerade paket)
- Integritetskontroll före installation
- Möjlighet till återställning om uppdateringen misslyckas
- Hantering av anslutningsproblem
- Synlig uppdateringsstatus för användaren
Användaren måste kunna välja bort automatiska uppdateringar, med en tydlig varning om säkerhetsföljderna. Vid kritiska uppdateringar bör tillverkaren dokumentera varje designval som inte kan skjutas upp i riskbedömningen och den tekniska dokumentationen.
Manuella uppdateringar
Produkter som inte kan ta emot automatiska uppdateringar kräver en manuell process:
- Nedladdningsbara paket med tydlig versionshantering
- Kryptografiska signaturer och publicerade nycklar för verifiering
- Installationsdokumentation
- Avisering via alla tillgängliga kanaler
Inbyggd firmware och SaaS: olika uppdateringsmodeller
Leveransmekanismen skiljer sig mellan arkitekturer:
| Produkttyp | Uppdateringsmodell | Viktig CRA-fråga |
|---|---|---|
| Inbyggd firmware | Tillverkaren levererar signerad firmware; kunden installerar | OTA eller dokumenterad manuell process behövs; lång livslängd kan kräva stöd längre än fem år |
| Fristående programvara | Tillverkaren publicerar paket; kunden installerar | Automatisk uppdateringsagent föredras; låsta versioner ger stöd för flera versioner |
| SaaS / moln | Tillverkaren kontrollerar miljön; uppdateringar är transparenta | Bekräfta först om tjänsten omfattas som produkt med digitala element eller fjärrdatabehandlingslösning |
| Hybrid | Agentuppdateringar styrs av tillverkaren; backend uppdateras transparent | Varje komponent har egen stödperiod; agenten är produkten med digitala element som styr klockan |
För bredare sårbarhetshantering utöver uppdateringsleverans (CVD-policy, offentlig redovisning, rapportering till tredje part), se guiden om sårbarhetshantering.
Rapporteringsskyldigheter under uppdateringsleverans
CRA-rapportering innehåller tidsbundna krav för aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar produktens säkerhet. Uppdateringsprocessen bör samla de fakta som behövs, eftersom slutrapporten ska innehålla detaljer om säkerhetsuppdateringen eller andra korrigerande åtgärder som gjorts tillgängliga.
Interaktionen är operativ:
| Utlösare | Uppgift i uppdateringsflödet |
|---|---|
| Aktivt utnyttjad sårbarhet | Fånga tidpunkt för kännedom, berörda produkter, utnyttjandefakta, mitigering och uppdateringsdetaljer för 24 timmar, 72 timmar och slutrapport. |
| Allvarlig incident | Fånga påverkan, misstänkt olaglig eller skadlig orsak, första bedömning, mitigering och korrigerande åtgärder för användare. |
| Användaravisering | Förbered tydliga instruktioner om riskminskning och korrigering för berörda användare och vid behov alla användare. |
Behandla inte rapportering som ett separat steg efteråt. Information från support, PSIRT, telemetri, kundtjänst eller deployment måste snabbt nå rapporteringsansvarig när en rapporteringströskel kan vara uppnådd.
För hela tidslinjemekaniken, inklusive vad varje rapport ska innehålla och hur de två rapporteringsströmmarna skiljer sig, se guiden om sårbarhetsrapportering.
Tillgänglighet för säkerhetsuppdateringar efter publicering
Det räcker inte att publicera en patch en gång. Varje säkerhetsuppdatering som görs tillgänglig under stödperioden måste fortsätta vara tillgänglig i minst 10 år efter publicering, eller under resten av stödperioden om den är längre. Det ändrar releasearbetet: gamla paket, rådgivningar, signaturer, hashvärden och installationsinstruktioner behöver långsiktig hosting och versionsspårbarhet.
Användarinformationen måste också ange vilken teknisk säkerhetsstöd tillverkaren erbjuder och slutdatum för stödperioden. Under den perioden kan användare förvänta sig sårbarhetshantering och säkerhetsuppdateringar. För modellen före köp, se redovisning av supportslut.
Vanliga misstag
Att ignorera transitiva beroenden. De flesta sårbarheter i uppkopplade produkter kommer från tredjepartsbibliotek och komponenter. Skyldigheten att hantera sårbarheter täcker hela produkten, inklusive komponenter. En SBOM är förutsättningen. Se SBOM-klusterguiden.
Att ta betalt för säkerhetsuppdateringar. Att lägga säkerhetsfixar i en betald supportnivå krockar med CRA:s grundläggande uppdateringsmodell, om inte undantaget för skräddarsydda företagsprodukter gäller. Grundläggande säkerhetspatchar måste vara kostnadsfria.
Vanliga frågor
Måste säkerhetsuppdateringar alltid vara gratis?
Ja, tillgängliga säkerhetsuppdateringar måste vara kostnadsfria, om inte det smala undantaget för skräddarsydda företagsprodukter gäller. En tillverkare kan inte lägga en sårbarhetsfix i en betald prenumeration, premiumnivå eller betald huvudversionsuppgradering och behandla det som vanlig CRA-efterlevnad. Funktionsuppdateringar, ny funktionalitet och professionella tjänster kan debiteras separat. Gränsen är om ändringen åtgärdar ett identifierat säkerhetsproblem i produkten.
Hur snabbt måste en tillverkare släppa en säkerhetsuppdatering enligt CRA?
CRA anger ingen fast patchfrist. Tillverkare behöver därför dokumenterade mål per allvarlighetsgrad. Kritiska aktivt utnyttjade sårbarheter bör hanteras på dagar, hög allvarlighetsgrad på cirka 30 dagar, medel på cirka 90 dagar och låg i nästa ordinarie cykel, om inte riskbedömningen motiverar något annat. Spåra faktisk tid till patch per sårbarhet så att dröjsmål blir synligt, riskbaserat och förklarligt.
Kräver CRA automatiska uppdateringar?
Inte alltid. Automatiska säkerhetsuppdateringar krävs där de är tillämpliga, och produkten bör också avisera tillgängliga uppdateringar och tillåta tillfälligt uppskov. För konsumentprodukter med tillförlitlig anslutning är det normalt den förväntade utformningen. För isolerade industrisystem, vissa medicintekniska produkter eller säkerhetskritisk utrustning kan en dokumenterad manuell process vara motiverad. Den tekniska dokumentationen bör förklara valet och användarinstruktionerna bör förklara hur automatisk installation stängs av.
Har en SaaS-produkt en CRA-stödperiod?
Det beror på om tjänsten omfattas som produkt med digitala element eller fjärrdatabehandlingslösning. Ren fristående SaaS som inte är kopplad till hårdvara, nedladdningsbar programvara eller tillverkaransvarig fjärrbehandling faller normalt utanför den här uppdateringsmodellen. Om erbjudandet omfattar en lokal agent, nedladdningsbar klient, hårdvarugateway eller omfattad fjärrbehandling, kartlägg stödperiod och uppdateringsmekanism för komponenten. Användarinformationen behöver fortfarande stödtyp och slutdatum.
Vad händer med säkerhetsuppdateringar efter att CRA-stödperioden upphör?
Den vanliga skyldigheten att hantera sårbarheter är knuten till stödperioden, men redan publicerade uppdateringar måste fortsätta vara tillgängliga. Varje säkerhetsuppdatering som gjorts tillgänglig under stödperioden ska finnas kvar i minst 10 år efter publicering eller under resten av stödperioden om den är längre. Tillverkare bör kommunicera stödets slut i förväg och hålla användarinstruktioner tillgängliga under den krävda perioden. Säg inte att rapportering kan ignoreras efter stödperioden utan en juridisk bedömning av det enskilda fallet.