CRA-stödperiod: femårig miniminivå

EU:s cyberresiliensförordning gör planering av stödperioden till ett produktlanseringsbeslut, inte en eftertanke. En tillverkare måste bestämma hur länge användare kan förvänta sig att sårbarheter hanteras, publicera slutdatumet för stöd vid köp och hålla säkerhetsuppdateringar tillgängliga under den period som krävs. Den här guiden täcker varaktighetsmekaniken: när klockan startar, hur undantaget för kortare förväntad användning fungerar, hur portföljer med flera versioner överlappar och vad uppströmsavtal måste täcka. För leveranskadens, se CRA-säkerhetsuppdateringar; för användarens slutdatum för stödperioden, se redovisning av stödets slut.

Vad CRA kräver för stödperioden

En stödperiod är det fönster under vilket tillverkaren måste hålla produktens sårbarhetshanteringsprocess vid liv. Den omfattar produkten och dess komponenter, startar från utsläppande på EU-marknaden och måste vara tillräckligt lång för att motsvara hur användare rimligen kan förvänta sig att produkten används. Tillverkaren bör sätta den utifrån praktiska bevis: produkttyp, avsett ändamål, jämförbara produkter, relevant unionsrätt som anger livslängd för produkter, tillgänglighet för driftmiljön, stödperioder för centrala tredjepartskomponenter och vägledning från ADCO eller kommissionen. Det praktiska resultatet är enkelt: stödet måste fastställas före lansering och hållas igång under hela det deklarerade stödfönstret.

Skyldigheten har tre delar:

När femårsklockan startar

Stödklockan startar när produkten kommer in på EU-marknaden, inte när slutkunden köper den. I EU:s produkträtt är det första gången produkten görs tillgänglig på unionsmarknaden för distribution eller användning. För stödplanering är datumet för utsläppande på marknaden det datum som räknas.

Klockan startar: datumet då produkten först görs tillgänglig för en distributör, återförsäljare, importör eller användare för distribution eller användning på EU-marknaden.

Klockan startar inte vid: kundens köp, kundens aktivering, leverans av en specifik enhet eller datumet då en kund installerar produkten.

Praktiskt exempel:

1. Januari 2028. Produkt v1.0 släpps ut på EU-marknaden. Den femåriga stödperioden börjar. Tillverkaren är skyldig att leverera säkerhetsuppdateringar till minst januari 2033.
2. Juni 2029. En kund köper v1.0 från en återförsäljare. Kunden har ungefär 3,5 år kvar av stödet, inte fem år från köp.
3. Januari 2033. Stödperioden upphör. Det grundläggande åtagandet för sårbarhetshantering av v1.0 upphör. Ytterligare användaraviseringar eller regulatorisk kontakt beror på fakta.

Bästa praxis: spåra datum för utsläppande på marknaden per produktversion, inte per enskild enhet. En enda placeringspost per SKU är vanligtvis den praktiska bevisbasen för att beräkna slutdatum för stöd.

Undantaget för kortare förväntad användning

Femårsgränsen kan bara kortas när produkten verkligen förväntas användas i mindre än fem år. Undantaget är snävare än det ser ut och kommer från stödperiodsartikeln:

• "Förväntad användningstid" bedöms utifrån rimliga användarförväntningar baserat på produktens natur, hur liknande produkter normalt används och vad tillverkaren kommunicerar.
• Den kortare perioden måste dokumenteras i den tekniska dokumentationen och redovisas för användare vid köp, inklusive minst månad och år för stödets slutdatum.
• En tillverkare kan inte åberopa undantaget efter att en sårbarhet har upptäckts. Bedömningen måste göras före utsläppande på marknaden och registreras i den tekniska filen.
• För de flesta programvaruprodukter, IoT-enheter och uppkopplad hårdvara är fem år det praktiska minimumet. Undantaget gäller produkter med objektivt kort nyttjandetid, till exempel engångs- eller begränsat cyklad hårdvara, inte produkter där tillverkaren bara föredrar en kortare skyldighet.

Stöd för flera versioner

De flesta tillverkare har flera produktversioner på marknaden samtidigt. Hårdvaruprodukter och självständigt underhållna programvaruversioner kan skapa överlappande stödfönster. Programvaruprodukter har också en begränsad endast-senaste-version-väg för senare väsentligt ändrade versioner, men bara om användare av tidigare versioner kan gå över till den senaste versionen kostnadsfritt och utan extra kostnader för hårdvaru- eller programvarumiljön.

Förskjutna stödperioder skapar överlappande skyldigheter:

Från januari 2029 till januari 2033, under fyra år, kan tillverkaren vara skyldig att leverera säkerhetsuppdateringar till alla tre versioner samtidigt, om ingen kvalificerad endast-senaste-version-väg gäller. Varje version har sin egen CVE-exponering, sitt eget beroendeträd och potentiellt sin egen kundbas. Backportering av patchar mellan huvudversioner är tekniskt komplex och dyr.

Strategier för att minska bördan med flera versioner:

1. Gemensam kodbas. Upprätthåll om möjligt en enda säkerhetspatchad kärna som alla versioner bygger på. Säkerhetsfixar som tillämpas en gång sprids till alla versioner.
2. Starka migrationsincitament. Kortare glapp mellan kunder på gamla versioner minskar den aktiva stödmatrisen. Uppgraderingspriser, gratis migreringsverktyg och stödkrediter påskyndar versionskonsolidering.
3. Tydlig EOL-plan per version. Publicera stödets slutdatum för varje version vid utsläppande på marknaden. Kunder som vet att v1.0 upphör i januari 2033 har tid att planera migrering utan akut press.
4. Senaste-version-väg för kvalificerad programvara. Om du använder senaste-version-vägen, dokumentera hur användare av tidigare versioner får den senaste versionen kostnadsfritt och utan kostnader för miljöjustering.

Leverantörs- och uppströmsavtal

Tillverkaren äger stödperiodsskyldigheten även när en sårbarhet kommer från en uppströmskomponent. Om produkten inte kan patchas därför att en komponentleverantör har avslutat stöd, behöver tillverkaren ändå en åtgärdsväg. Luckan i uppströmsavtalet är inget försvar enligt stödperiodsregeln.

Vad detta betyder i praktiken:

• Om en produkt innehåller ett operativsystem, middleware eller chipset-firmware från tredje part måste tillverkaren säkra ett leveransavtal som täcker hela stödperioden. En uppströmsleverantör som tillhandahåller säkerhetspatchar i tre år tvingar tillverkaren att antingen underhålla patcharna själv efter år tre eller sluta släppa ut produkten på EU-marknaden efter uppströms EOL.
• SBOM-baserad beroendespårning (se SBOM-klusterguiden) är den operativa mekanismen: tillverkaren kan inte övervaka uppströmssårbarheter utan att veta vad produkten innehåller.
• Leveransavtal bör ange: uppströms patchåtagandets varaktighet, anmälningsskyldigheter för nyupptäckta sårbarheter, tillgång till källkod eller patchverktyg om uppströmsleverantören avvecklar komponenten och ersättningsvillkor för sårbarheter som härrör från uppströmskomponenter.

Importörer och distributörer som släpper ut en produkt på marknaden under eget namn eller varumärke, eller väsentligt ändrar en produkt som redan släppts ut på marknaden, behandlas som tillverkare och ärver tillverkarens skyldigheter, inklusive uppströmsavtalsrisk. Se guiden om importörens skyldigheter för rolleskaleringsflödet.

Planering för livscykelns slut och ansvarsfulla produktövergångar

När stödperioden upphör avslutas det grundläggande åtagandet för sårbarhetshantering för den produktversionen, men vissa ansvar finns kvar.

Det som finns kvar vid stödets slut:

• Slutdatumet för stödperioden som redovisats vid köp står kvar som användarlöftet.
• Den tekniska dokumentationen och EU-försäkran om överensstämmelse måste bevaras i minst 10 år från utsläppande på marknaden eller under stödperioden, beroende på vilket som är längst.
• Information och instruktioner till användare måste fortsätta vara tillgängliga för användare och marknadskontrollmyndigheter på samma grund, 10 år eller stödperioden, oavsett distributionskanal; om de tillhandahålls online måste de även förbli tillgängliga online under den perioden.
• Där det är tekniskt möjligt bör tillverkaren visa användarna ett meddelande om att produkten har nått slutet av sin supportperiod.
• Sårbarheter i produkter utan stöd kräver fortfarande omsorgsfull hantering. CRA ger ingen generell safe harbour-mening för varje incidentrapporteringsfråga vid EOL, och marknadskontrollmyndigheter kan fortfarande agera när en produkt innebär betydande cybersäkerhetsrisk. Sanktionsrisken behandlas i guiden om sanktioner och tillsyn.

Kommunikationsskyldigheter vid stödets slut:

CRA anger ingen lagstadgad varseltid för stödets slut. Redovisningen av stödperiodens slutdatum vid köp innebär att användare som köpte produkten efter att redovisningen fanns på plats redan hade fått besked. För produkter där den ursprungliga redovisningen saknades eller var oklar är förhandsbesked en operativ riskkontroll, inte en numrerad CRA-frist.

Efter EOL: tillverkaren bör behålla en säkerhetskontakt för ansvarsfull sårbarhetsrapportering, hålla produktdokumentation tillgänglig och samarbeta med varje marknadskontrollutredning.

Vanliga misstag

• Att inte spåra datum för utsläppande på marknaden. Utan en post per version kan tillverkaren inte beräkna när stödskyldigheter börjar eller slutar, inte ta fram det användarorienterade slutdatumet för stöd och inte visa efterlevnad för marknadskontrollmyndigheter.

• Att inte planera för uppströms EOL. Om en chipset-, OS- eller middleware-leverantör avslutar stöd innan tillverkarens stödperiod löper ut måste tillverkaren ha en plan. Reaktiv upptäckt av uppströms EOL utan leveransavtal på plats är ett vanligt och dyrt fel.

• Att koppla säkerhetspatchar till funktionsversioner. Att paketera säkerhetsfixar med större versionsuppgraderingar tvingar kunder att acceptera nya funktioner och ny riskyta för att få en säkerhetsfix. Säkerhetsfixar bör levereras som säkerhetsfixar, utan att tvinga fram betalnivåer eller stora funktionsuppgraderingar.