CRA supportperiodplanering: 5 år av säkerhetsuppdateringar (och vad det verkligen innebär)

Fem år. Det är minimum du måste tillhandahålla säkerhetsuppdateringar för dina produkter under CRA. För många tillverkare innebär detta en grundläggande förändring av hur de tänker kring produktlivscykel och supportkostnader.

Den här guiden täcker vad supportperiodkravet faktiskt innebär, hur man planerar för det och hur man hanterar den oundvikliga slut-på-support-övergången.

Sammanfattning

• CRA kräver säkerhetsuppdateringar i minst 5 år (eller förväntad produktlivstid, vilket som är kortast)
• Uppdateringar måste åtgärda sårbarheter "utan dröjsmål" och vara kostnadsfria
• Du behöver: mekanism för uppdateringsleverans, kundnotifieringsprocess, slut-på-support-plan
• Supportperioden börjar när produkten placeras på marknaden, inte när kunden köper den
• Planera din kostnadsmodell kring 5-årsåtagande för support innan prissättning

Vad CRA faktiskt kräver

Artikel 13 och Bilaga I fastställer supportperiodsskyldigheter:

Minimiperiod

5 år från när produkten placeras på EU-marknaden, ELLER den förväntade produktlivstiden, beroende på vilket som är kortast.

"Förväntad produktlivstid" bestäms av:

• Rimliga kundförväntningar baserade på produktens natur
• Hur liknande produkter vanligtvis används
• Vad du kommunicerar om produkten

För de flesta programvaru- och IoT-produkter är 5 år det praktiska minimumet.

Vad du måste tillhandahålla

Under supportperioden måste du:

1. Åtgärda sårbarheter utan dröjsmål

   • Tillhandahåll säkerhetspatcher för kända sårbarheter
   • Prioritera baserat på allvarlighetsgrad
   • Vänta inte till "nästa stora release"

2. Leverera uppdateringar säkert

   • Automatiska uppdateringar där tekniskt möjligt
   • Säker distribution (signerad, verifierad)
   • Återkallningsförmåga om uppdateringar misslyckas

3. Notifiera kunder

   • Informera om tillgängliga säkerhetsuppdateringar
   • Ge tydliga installationsinstruktioner
   • Kommunicera säkerhetsrelevant information

4. Tillhandahåll uppdateringar kostnadsfritt

   • Inga avgifter för säkerhetsuppdateringar
   • Funktionsuppdateringar kan debiteras separat

När börjar klockan gå?

Supportperioden börjar när produkten "placeras på marknaden", det vill säga när du gör den tillgänglig för första gången i EU.

Inte när:

• Kunden köper den
• Kunden aktiverar den
• En specifik enhet skickas

Detta skapar lagerrisk: Om din produkt ligger i distribution i 18 månader innan försäljning slutar supporten fortfarande 5 år från initial marknadsplacering.

Exempeltidslinje

Jan 2028: Produkt v1.0 placeras på EU-marknaden
          → Supportperiod börjar
          → Måste tillhandahålla uppdateringar till jan 2033

Jun 2029: Kund köper v1.0 från distributör
          → Kunden har 3,5 år av support kvar

Jan 2033: Supportperiod slutar
          → Ingen ytterligare skyldighet att patcha v1.0
          → Kunden har 18 månader av ostödd produkt

Bästa praxis: Spåra marknadsplaceringsdatum per produktversion, inte per enhet.

Krav på uppdateringsleverans

Automatiska uppdateringar (Föredraget)

Där tekniskt genomförbart och lämpligt förväntar sig CRA automatiska säkerhetsuppdateringar:

KRAV PÅ AUTOMATISKA UPPDATERINGAR:

Tekniska:
- Säker nedladdningskanal (TLS, signerade paket)
- Integritetsverifiering före installation
- Återkallningsförmåga om uppdatering misslyckas
- Elegant hantering av anslutningsproblem

Användarkontroll:
- Användaren måste kunna välja bort (med tydlig varning)
- Användaren måste kunna skjuta upp (med rimliga begränsningar)
- Kritiska uppdateringar kan åsidosätta uppskjutning för säkerhet
- Uppdateringsstatus måste vara synlig för användaren

Notifiering:
- Informera användaren när uppdateringar finns
- Förklara vad uppdateringen åtgärdar
- Ge installationsinstruktioner om manuell

Manuella uppdateringar (När automatisk inte är möjlig)

Vissa produkter kan inte uppdateras automatiskt: air-gapped-system, industriell utrustning, inbyggda enheter utan anslutning.

För dessa:

• Tillhandahåll nedladdningsbara uppdateringspaket
• Tydlig versionering och ändringslogg
• Installationsdokumentation
• Verifieringsmetod (checksummor, signaturer)
• Notifiering via tillgängliga kanaler (e-post, webbportal, fysisk avisering)

Uppdateringssignering

Alla säkerhetsuppdateringar bör kryptografiskt signeras:

KRAV PÅ UPPDATERINGSSIGNERING:

Kodsignering:
- Signera alla uppdateringspaket
- Använd dedikerad signeringsnyckel (HSM-skyddad)
- Inkludera signaturverifiering i uppdateringsprocess
- Publicera publik nyckel för verifiering

Metadata:
- Versionsnummer
- Releasedatum
- Ändringslogg/rådgivningsreferens
- Minsta kompatibel basversion
- Signaturtidsstämpel

Sårbarhetrespons under supportperioden

Supportperioden handlar inte bara om att ha uppdateringar tillgängliga. Det handlar om att svara på sårbarheter när de upptäcks.

Responsförväntningar

Dessa är inte CRA-föreskrivna tidslinjer, men de återspeglar branschförväntningar och vad tillsynsmyndigheter kommer att betrakta som "utan dröjsmål."

Spåra sårbarheter

Du behöver en process för:

1. Intagspunkt

   • CVD-policy och kontaktpunkt
   • Internt upptäckningspipeline
   • Beroendeövervakning

2. Bedömning

   • Påverkar sårbarheten vår produkt?
   • Vilka versioner är drabbade?
   • Vad är allvarlighetsgraden i vårt sammanhang?

3. Åtgärd

   • Utveckla patch
   • Testa patch
   • Distribuera patch

4. Kommunikation

   • Notifiera kunder
   • Publicera rådgivning (om lämpligt)
   • Rapportera till ENISA (om aktivt exploaterad)

Beroende-sårbarheter

Din produkt inkluderar tredjepartskomponenter. När de har sårbarheter:

• Direkta beroenden: Du måste bedöma påverkan och uppdatera om drabbad
• Transitiva beroenden: Samma skyldighet, svårare att spåra
• OS/plattform-sårbarheter: Kan kräva att du uppdaterar eller kommunicerar begränsning

SBOM är väsentligt: Du kan inte spåra vad du inte vet om.

Kostnadsmodellering för supportperiod

Många tillverkare underskattar supportkostnader. Här är ett ramverk:

Fasta kostnader (Per produktlinje)

Rörliga kostnader (Per stödår)

Exempelkostnadsmodell

KOSTNADSMODELL FÖR SUPPORTPERIOD

Produkt: Smart Home Hub v2.0
Supportperiod: 5 år (jan 2028 - jan 2033)
Uppskattade enheter: 50 000

FASTA KOSTNADER (engångs):
- Uppdateringspipeline-inställning:  15 000 kr
- Signeringsinfrastruktur:            5 000 kr
- Notifieringssystem:                10 000 kr
- Dokumentationsmallar:               5 000 kr
DELSUMMA:                            35 000 kr

ÅRSKOSTNADER:
- Säkerhetsingenjör (0,2 FTE):      30 000 kr/år
- Beroendeövervakning:               2 000 kr/år
- Testinfrastruktur:                 5 000 kr/år
- Kundsupport delta:                 3 000 kr/år
DELSUMMA:                      40 000 kr/år × 5 = 200 000 kr

INCIDENTRESERV (5 år):
- Kritiska sårbarheter (uppsk. 2):  20 000 kr
- Reguljära patcher (uppsk. 15):    30 000 kr
DELSUMMA:                           50 000 kr

TOTAL 5-ÅRIG SUPPORTKOSTNAD:       285 000 kr
SUPPORTKOSTNAD PER ENHET:            5,70 kr

Om man säljer för 990 kr/enhet:
Support = 0,6% av intäkter

Nyckelinsikt: Supportkostnad per enhet minskar med volym. Lågvolymprodukter har proportionellt högre supportbörda.

Slut-på-support-planering

Supportperioden tar slut. Vad händer sedan?

Innan slut-på-support

12 månader före:

• Annonsera slut-på-support-datum
• Kommunicera till alla registrerade användare
• Publicera på produktsidor och dokumentation
• Erbjud uppgraderings-/ersättningsvägar

6 månader före:

• Påminnelsekommunikation
• Sista funktionsuppdateringar (om några)
• Dokumentationsstopp (dokumentera nuläget)
• Förbered sista säkerhetsuppdatering

Vid slut-på-support:

• Ge ut slutlig säkerhetsuppdatering med alla kända åtgärder
• Publicera slut-på-support-avisering
• Uppdatera produktdokumentation för att återspegla status
• Omdirigera supportkanaler till alternativ

Mall för kundkommunikation

SLUT-PÅ-SUPPORT-AVISERING

Produkt: [Produktnamn v1.0]
Datum för slut-på-support: [Datum]

Vad detta innebär:
- Säkerhetsuppdateringar tillhandahålls inte längre efter [Datum]
- Teknisk support för den här versionen slutar
- Produkten fortsätter fungera men kan bli sårbar

Vad du bör göra:
- Alternativ 1: Uppgradera till [Produktnamn v2.0] - [länk]
- Alternativ 2: Byt till [Alternativ produkt] - [länk]
- Alternativ 3: Fortsätt använda på egen risk (rekommenderas inte)

Tidslinje:
- [Datum - 6 månader]: Slutlig funktionsuppdatering
- [Datum - 1 månad]: Slutlig säkerhetsuppdatering
- [Datum]: Slut-på-support

Frågor? Kontakta [supportkanal]

Efter slut-på-support

Dina skyldigheter efter supportperiod:

• Behåll teknisk fil i 10 år totalt (från sista enheten på marknaden)
• Svara på begäranden från marknadsövervakningsmyndigheter
• Ingen skyldighet att patcha nya sårbarheter

Bästa praxis (frivilliga):

• Upprätthåll säkerhetskontakt för ansvarsfullt avslöjande
• Överväg att publicera kända-men-oåtgärdade sårbarheter
• Behåll uppdateringsinfrastruktur tillgänglig för kritiska nödsituationer

Stöd av flera versioner

De flesta tillverkare har flera produktversioner på marknaden simultant.

Utspridda supportperioder

VERSIONS SUPPORTTIDSLINJE

v1.0: Jan 2028 ─────────────────────────── Jan 2033
v1.1:      Jul 2028 ─────────────────────────── Jul 2033
v2.0:           Jan 2029 ─────────────────────────── Jan 2034

Överlappande support: Jan 2029 - Jan 2033 = 4 år av dubbelt stöd

Exempel på supportmatris

PRODUKTSUPPORTMATRIS (per jan 2030)

Version   Releasad    Support slutar  Status
────────────────────────────────────────────
v1.0      Jan 2028    Jan 2033        Underhåll
v1.1      Jul 2028    Jul 2033        Underhåll
v2.0      Jan 2029    Jan 2034        Aktuell
v2.1      Jan 2030    Jan 2035        Aktuell

Underhåll = Säkerhetsuppdateringar enbart
Aktuell = Säkerhets- + funktionsuppdateringar

Minska bördan av multi-versionsstöd

Strategier för att minimera överlappande support:

1. Enhetlig kodbas: Dela kod mellan versioner där möjligt
2. Bakåtporteringsprocess: Automatiserade eller semi-automatiserade säkerhets-backportar
3. Kortare releasecykler: Mer frekventa releaser = mer förutsägbara supportfönster
4. Aggressiv avveckling: Uppmuntra kunder att uppgradera

Branschspecifika hänsyn

IoT-enheter

• Många har 7-10 år förväntad livstid
• Uppdateringsmekanismer kan vara begränsade
• Kundnåbarhet är utmanande
• Överväg: fjärruppdateringsförmåga, heartbeat-övervakning

B2B-programvara

• Företagskunder förväntar längre support
• Supportkontrakt kan redan överstiga 5 år
• Integrationskomplexitet påverkar uppdateringsdriftsättning
• Överväg: förlängda supportnivåer, professionella tjänster

Konsumentelektronik

• Återförsäljarkanal komplicerar kundkommunikation
• Slutanvändare kanske inte registrerar produkter
• Konkurrerar med planerad obsolescenskultur
• Överväg: produktinterna uppdateringsnotifieringar, appbaserade uppdateringar

Industriell utrustning

• 15-20 år förväntad livstid är vanligt
• Driftstopp för uppdateringar är kostsamt
• Air-gapped-installationer
• Överväg: stegvisa utrullningar, kompatibilitetstestning, professionella driftsättningstjänster

Vanliga misstag

Koppla säkerhet till funktionsuppdateringar

Problem: Säkerhetspatchar finns bara i stora releaser.

Varför det är fel: Kunder ska inte behöva acceptera nya funktioner (och potentiella nya buggar) för att få säkerhetsfix.

Lösning: Underhåll säkerhets-enbart uppdateringsspår för stödda versioner.

Ignorera beroendeuppdateringar

Problem: Produktkod underhålls men beroenden föråldras.

Varför det är fel: De flesta sårbarheter kommer från beroenden.

Lösning: Inkludera beroendeuppdateringar i ditt säkerhetsunderhållsomfång.

Ingen uppdateringsverifiering

Problem: Uppdateringar är tillgängliga men kunder kan inte verifiera äkthet.

Varför det är fel: Angripare kan distribuera falska "uppdateringar."

Lösning: Signera alla uppdateringar, publicera verifieringsprocedurer.

Oklart slut-på-support

Problem: Support bara... slutar. Ingen kommunikation.

Varför det är fel: Kunder lämnas med sårbara produkter de inte vet är ostödda.

Lösning: Proaktiv, dokumenterad slut-på-support-process.

Supportperiod inte inkluderad i prissättning

Problem: Produkt prissatt utan hänsyn till 5-årig supportkostnad.

Varför det är fel: Support blir ett kostnadscenter som äter in i marginaler.

Lösning: Modellera supportkostnader före prissättning. Betrakta support som kostnad för sålda varor.

Checklista för supportperiodplanering

CHECKLISTA FÖR SUPPORTPERIODPLANERING

INNAN MARKNADSPLACERING:

Infrastruktur:
[ ] Uppdateringsbyggpipeline etablerad
[ ] Säker uppdateringsleveransmekanism
[ ] Kodsigneringsinfrastruktur
[ ] Kundnotifieringssystem

Planering:
[ ] Supportperiod fastställd (min 5 år)
[ ] Slut-på-support-datum beräknat
[ ] Kostnadsmodell genomförd
[ ] Supportbemanning planerad
[ ] Beroendespårning etablerad

Dokumentation:
[ ] Supportperiod angiven i produktinfo
[ ] Uppdateringsprocess dokumenterad
[ ] Mallar för kundnotifiering redo

UNDER SUPPORTPERIODEN:

Övervakning:
[ ] Sårbarhetövervakning aktiv
[ ] Beroendeuppdateringar spårade
[ ] Kundfeedbackkanaler övervakade

Respons:
[ ] Sårbarhetstriage-process
[ ] Patchutvecklingsarbetsflöde
[ ] Test- och releaseprocess
[ ] Kundnotifieringsprocess

Rapportering:
[ ] ENISA-rapporteringsintegration (om exploatering)
[ ] Rådgivningspubliceringsprocess
[ ] Supportmetrikspårning

SLUT-PÅ-SUPPORT:

Kommunikation:
[ ] 12-månaders förhandsavisering skickad
[ ] 6-månaders påminnelse skickad
[ ] Slutlig avisering vid slut-på-support
[ ] Dokumentation uppdaterad

Övergång:
[ ] Uppgraderingsväg dokumenterad
[ ] Slutlig säkerhetsuppdatering distribuerad
[ ] Supportkanaler omdirigerade
[ ] Teknisk fil arkiverad (10-årsbevarande)

Viktigt: CRA kräver en minimumsupportperiod på 5 år för säkerhetsuppdateringar. En kortare period kräver dokumenterad motivering baserad på produktens förväntade livstid.

Tips: Räkna in löpande sårbarhetövervakning och patchleveranskostnader i din produktprissättning från dag ett.

Relaterade guider

• CRA End-of-Life-planering: Ansvarsfull produktövergång
• CRA-efterlevnadskostnad
• CRA-teknisk fil (Bilaga VII)-guide

Hur CRA Evidence hjälper

CRA Evidence tillhandahåller supportperiodhantering:

• Versions­livscykelspårning: Marknadsplaceringsdatum, slut-på-support-datum
• Beroendeövervakning: SBOM-baserade sårbarhetvarningar
• Kundnotifiering: Mallar och distributionstspårning
• Dokumentation: Slut-på-support-register för teknisk fil
• Efterlevnadspanel: Supportperiodstatus över produkter

Planera dina supportperioder på app.craevidence.com.

Den här artikeln är endast avsedd för informationsändamål och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, konsultera kvalificerade juridiska rådgivare.