CRA:s stödperiod — bestäm, dokumentera och förvalta den

Cyberresiliensförordningen kräver att tillverkare fastställer en stödperiod för produkter med digitala element. Det är inte ett ”EOL”-fält som fylls i efteråt. Beslutet avgör bland annat hur länge effektiv sårbarhetshantering måste fortsätta, och motiveringen ska ingå i den tekniska dokumentationen.

Som huvudregel är stödperioden minst fem år. Om produkten förväntas användas under mindre än fem år motsvarar stödperioden denna förväntade användningstid.

Kriterier i CRA

Tillverkaren ska särskilt beakta:

rimliga användarförväntningar;
produktens art;
dess avsedda ändamål;
relevant EU-rätt som fastställer produktens livslängd.

CRA tillåter också att följande beaktas:

stödperioder för produkter med liknande funktioner;
tillgången till driftsmiljön;
stödperioder för integrerade tredjepartskomponenter som tillhandahåller grundläggande funktioner;
relevant vägledning från kommissionen och ADCO.

Kriterierna ska tillämpas proportionerligt.

Börja inte med datumet

En svag process börjar med:

”Vi anger fem år eftersom CRA säger det.”

En starkare process börjar med antagandena:

Hur länge kan användarna rimligen förvänta sig att använda produkten?
Hur länge kan grundläggande beroenden stödjas?
Vilken livscykel har hårdvaran eller driftsmiljön?
Används produkten i en industriell eller annan miljö där den praktiska livslängden är längre?
Vilka åtaganden följer av avtal och annan tillämplig rätt?
Kan processen för säkerhetsuppdateringar realistiskt upprätthållas under den valda perioden?

Godkänn slutdatumet först när dessa frågor har beaktats.

Underlag för beslutet

En minimipost kan innehålla:

Fält	Exempel på innehåll
Produkt / version	unik identifiering
Beslutsdatum	när stödperioden godkändes
Slutdatum	åtminstone månad och år
Förväntad användningstid	antagande + källa
Användarförväntningar	avtal, produktdata, marknadsunderlag
Grundläggande beroenden	tredje parters stödperioder
Driftsmiljö	nödvändiga system/plattformar
Rättslig grund/vägledning	källor som användes i beslutet
Godkännare	ansvarig person/roll
Granskningsdatum	när antagandena kontrolleras på nytt

Användarna behöver ett tydligt slutdatum för stödet

Artikel 13 kräver att stödperiodens slutdatum – åtminstone månad och år – anges tydligt och begripligt vid köpet på ett lättillgängligt sätt och, där det är tillämpligt, på produkten, förpackningen eller digitalt.

Detta kopplar ett internt livscykelbeslut till produktkommunikationen. Om datumet skiljer sig mellan den tekniska dokumentationen, prisinformationen, gränssnittet och avtalet uppstår problemet i det vanliga kundarbetet långt före en revision.

Stödperioden är ett verksamhetsåtagande, inte bara ett datum

Under stödperioden måste tillverkaren hantera sårbarheter effektivt enligt CRA-kraven. Dokumentationen för stödperioden bör därför kopplas till:

policyn för samordnad information om sårbarheter;
triage och avhjälpande av sårbarheter;
säkerhetsutgåvor;
tredjepartskomponenter;
användarkommunikation;
bevakning av när stödet upphör.

CRA innehåller också krav på fortsatt tillgänglighet för utfärdade säkerhetsuppdateringar och på att dokumentation bevaras under angivna perioder. Livscykelhantering kan inte reduceras till ett fält i ett CRM-system eller en produktkatalog.

Hur Pulsar kan hantera beslutet

Pulsar kan bevara beslutet, motiveringen, ansvariga personer, åtgärder och underlag och koppla dem till risker och dokumentation. Vid en senare granskning ser teamet vad som har ändrats sedan det förra beslutet utan att behöva återskapa den ursprungliga motiveringen.

Det betyder inte att Pulsar självständigt avgör den rätta stödperioden. Antagandena och godkännandet ligger kvar under tillverkarens ansvar.

Se Pulsar GRC i ett besluts livscykel

Ett stödperiodsbeslut behöver produktens verkliga användning

Anta att företaget säljer en nätverksansluten styrenhet som kunderna normalt installerar i utrustning med lång användningstid. Produktansvarig vill först välja ett slutdatum utifrån ett standardiserat kommersiellt avtal. Innan beslutet fattas behöver teamet kontrollera vad användningssituationen, produktens natur och de tillämpliga CRA-kriterierna faktiskt innebär. Ett datum som passar försäljningsplanen kan vara en otillräcklig grund för produktens stödperiod.

Samla källor som beskriver avsedd användning och förväntad livslängd. Bevara produktinformation, relevanta kundbehov, tekniska förutsättningar och bedömningen av grundläggande komponenter. Ange vilka antaganden som är säkra och vilka som behöver verifieras. Ett intervall i ett internt underlag kan vara rimligt under analysen, men det slutliga användarbudskapet behöver följa de krav som faktiskt gäller.

Skilj olika datum innan något publiceras

Försäljningsstopp, avtalsslut, garanti, kommersiell support och säkerhetsstöd kan ha olika betydelser. Definiera dem uttryckligen i produktens interna dokumentation. Om samma ord används för flera av dessa händelser kan kunden dra en slutsats som tillverkaren inte avsåg. Det kan även göra den interna planeringen svårare eftersom ingen vet vilken funktion som måste finnas kvar efter ett visst datum.

Kontrollera även vad som gäller för olika utgåvor och produkter i samma familj. Ett nytt versionsnummer behöver inte innebära att ett gammalt åtagande försvinner. Beskriv relationen mellan produkt, utgåva och den period som bedömningen avser. Den rättsliga tolkningen behöver ansvarig granskning. Den tekniska och kommersiella dokumentationen ska sedan återge samma beslut så att teamen arbetar utifrån en gemensam grund.

Komponenternas stöd är en planeringsfråga

En viktig tredjepartskomponent kan få kortare stöd än produktens planerade period. Lista komponenter som påverkar grundläggande funktioner och dokumentera deras kända förvaltning. Bedöm möjliga alternativ innan ett löfte om produktens period publiceras. Ett leverantörsdatum är ett underlag för tillverkarens beslut, inte en automatisk regel som ensamt avgör den egna produktens skyldigheter.

Alternativen kan omfatta byte av komponent, annan förvaltning eller en teknisk ändring av produkten. Bedöm arbetsinsats, verifiering och konsekvenser för stödda utgåvor. Om inget alternativ är bekräftat ska den osäkerheten framgå i planeringen. En lång period på produktsidan skapar inte kapacitet att genomföra nödvändiga uppdateringar. Ledningen behöver se och besluta om den faktiska resursfrågan.

Gör åtagandet genomförbart

Dokumentera vem som följer sårbarhetsinformation, vem som analyserar fynd och vilka personer som kan göra en rättelse. Bevara tillgång till nödvändiga verktyg, byggmaterial och relevant testmiljö enligt organisationens regler. Teamet behöver kunna leverera och verifiera ändringar även när de ursprungliga utvecklarna inte längre arbetar med produkten. Den förmågan bör prövas innan den behöver användas under tidspress.

Planera även användarkommunikation och distributionssätt. Det behöver finnas ett begripligt sätt att identifiera berörd version och informera om en uppdatering. Om kundregister är ofullständiga ska organisationen bedöma hur informationen kan nå användarna och vilka begränsningar som finns. Artikeln ger inte en universell metod; produktens faktiska distributionsmodell styr vilka kontroller som är relevanta.

Ett verifierat exempel på underhållsförmåga

Välj en stödd äldre utgåva i en lämplig testmiljö. Genomför en ofarlig ändring och kontrollera att teamet kan bygga, testa, leverera och dokumentera den genom ordinarie procedur. Använd inte produktionskunder som test utan ett godkänt upplägg. Mät var processen stannar: saknade källor, utgångna verktyg, otydliga behörigheter eller en testmiljö som bara fungerar för den senaste versionen.

Mottagningstestet ska visa att resultatet hör till rätt utgåva och att en granskare kan förstå vad som verifierades. Att en fil kan byggas innebär inte att produkten beter sig korrekt. Bevara därför relevanta funktionstester och eventuella begränsningar. Om en äldre variant inte kan kontrolleras behöver det bli en öppen åtgärd med ansvarig, inte en tyst avvikelse i det publicerade åtagandet.

Produktbudskapet ska stämma i alla kanaler

Kontrollera produktblad, digitalt gränssnitt, orderinformation och den tekniska dokumentationen mot samma godkända källa. Skriv slutdatumets avsedda betydelse så att en användare kan skilja det från andra avtalsdatum. Om olika regioner eller distributionsvarianter kräver olika information ska det framgå. En översättning ska återge beslutet korrekt, inte hitta på ett mer attraktivt löfte för en viss marknad.

Be en person som inte deltagit i beslutet läsa kundinformationen och beskriva vad den innebär. Om svaret skiljer sig från tillverkarens avsikt behöver texten förtydligas. Kontrollera också att tidigare publicerade budskap går att spåra. När information rättas bör organisationen veta vilken version som var tillgänglig vid ett visst köp och om någon vidare kommunikation behövs.

Ändringar kräver en bedömning av befintliga åtaganden

Ett nytt kommersiellt upplägg eller en leverantörsändring kan påverka den interna planen. Gör en dokumenterad bedömning innan publicerad stödperiod ändras. Kontrollera relevanta rättsliga krav, avtal och användarinformation. Att en produkt slutar säljas betyder inte i sig att arbete för befintliga produkter kan avslutas. Bevara vilka grupper av produkter och utgåvor varje beslut gäller.

Ange varför beslutet ändrades och vilken grund som användes. Om det tidigare underlaget inte längre gäller ska teamet förstå vilken förutsättning som fallit bort. En ny rad i en produktkatalog ger inte samma spårbarhet som ett granskat beslutsärende. Detta blir särskilt viktigt när olika funktioner ska hantera kundfrågor, teknisk planering och dokumentationskrav långt efter den ursprungliga lanseringen.

Planera slutet av perioden utan att börja med radering

När slutdatumet närmar sig behöver organisationen bedöma kvarstående uppgifter om uppdateringars tillgänglighet, dokumentation och kommunikation utifrån CRA och andra tillämpliga regler. Gör den bedömningen separat från ett beslut att avveckla en intern miljö. Material som behövs för tidigare produktbeslut kan fortfarande behöva bevaras. Skriv vem som fattar respektive beslut och vilka källor som styr det.

Kontrollera användarens väg till redan tillgängliga säkerhetsuppdateringar och relevant information. En länk som försvinner när ett gammalt projektnamn tas bort kan göra materialet oanvändbart. Testa hur en användare med den äldre produkten hittar den information som fortfarande ska finnas. Resultatet behöver dokumenteras med omfattning och eventuella luckor. Ett internt arkiv är inte alltid samma sak som fungerande extern tillgänglighet.

Följ ansvar och kapacitet över tid

Gå regelbundet igenom produkter som fortfarande har åtaganden men få aktiva utvecklare. Lista ärenden som saknar ägare, komponenter som behöver ny bedömning och verifiering som inte kan genomföras med nuvarande miljö. Ange vilka frågor ledningen måste avgöra. En plan som upptäcker kapacitetsbristen tidigt ger fler val än en plan som väntar tills nästa kritiska sårbarhet kommer.

Pulsar kan bevara motivering, ansvar, risker, uppgifter och underlag för periodens beslut. Det ersätter inte tillverkarens tekniska underhåll eller rättsliga bedömning. Den användbara frågan är om organisationen kan visa både varför perioden valdes och hur den kan fullföljas för de produkter den omfattar. Ett väl dokumenterat datum utan denna förmåga lämnar den viktigaste operativa frågan obesvarad.

Skilj produktfamilj från det beslut som kunden ser

En produktfamilj kan innehålla modeller med olika tekniska beroenden och användningsförutsättningar. Om en gemensam stödperiod används ska teamet kunna förklara varför samma grund gäller. Om perioderna skiljer sig ska informationen identifiera rätt produkt och variant. Kontrollera hur detta framgår i orderflöde, produktblad och relevant digital information. Ett gemensamt familjenamn får inte göra att kunden läser datumet för en annan modell.

Prova en konkret kundfråga: vilken period gäller den produkt och version som köptes vid ett visst tillfälle? Underlaget ska ge ett begripligt svar med hänvisning till det beslut och budskap som gällde. Om teamet bara hittar den senast uppdaterade webbsidan behöver historiken förbättras. Detta är ett internt användbarhetstest som hjälper organisationen att följa sina beslut, inte ett nytt lagstadgat krav på en särskild databasteknik.

När flera modeller förvaltas av samma personer kan kapacitetsplanen behöva behandla dem tillsammans. Behåll ändå de individuella besluten och deras begränsningar. Det gör det möjligt att prioritera underhåll utan att sammanblanda olika användares åtaganden.

Relaterad vägledning

Källor

Källor kontrollerade: 2 oktober 2026. De praktiska testerna och exemplen ovan är redaktionella förslag, inte nya rättsliga krav.

Pulsar GRC — åtkomst, dataisolering och export (polska)