Supportperiode: hvor længe lover I at rette sårbarheder?

Supportperioden er det tidsrum, hvor I som fabrikant lover at håndtere sårbarheder i et produkt. Efter Cyber Resilience Act skal den være mindst fem år, medmindre produktet forventes brugt kortere, og den skal være længere, hvis det forventes brugt længere. Fem år er altså ikke standardsvaret. I skal fastsætte perioden ud fra kriterierne i forordningens art. 13, stk. 8, og oplyse slutdatoen ved køb. Kravene gælder fra 11. december 2027 for de omfattede produkter. Beslutningen er ledelsens, for den binder udviklingskapacitet i årevis og fastlægger, hvad I lover kunderne.

Hvad forordningen kræver

Kravene er forholdsvis enkle at gengive og sværere at leve op til:

• Længden. Mindst fem år, kortere hvis forventet brugstid er kortere, og længere, hvis produktet forventes brugt længere.
• Fastsættelsen. Fabrikanten bestemmer perioden ud fra kriterierne i art. 13, stk. 8. Læs dem direkte, og skriv jeres begrundelse ned.
• Oplysningen. Slutdatoen, som mindst måned og år, skal oplyses ved køb efter art. 13, stk. 19.
• Versioner. Hver væsentligt ændret version af software skal have en erklæret supportperiode.

Hvad der er omfattet, har sin egen artikel. Artiklen her er en orientering. Konkret tvivl hører til hos en advokat, og Kommissionens vejledning, som meget af det bygger på, er ikke bindende.

Lempelsen for software

Art. 13, stk. 10, giver software en vigtig lempelse. Har ældre versioner en opgradering uden ekstra omkostninger, må I samle rettelserne i den nyeste. Vejledningen beskriver det i eksempel 52.

Det har stor betydning for arkitektur og forretning. Kan kunderne altid komme op på den seneste version uden merudgift, slipper I for at vedligeholde flere rettelsesspor. Kræver en opgradering, at kunden betaler, eller at der skal tilpasses meget hos hver kunde, er lempelsen langt sværere at bruge. Det gør kundetilpasninger i standardproduktet til et CRA-spørgsmål, for hver særlig version øger det, I skal holde rettet.

Hvad perioden binder

Regn det igennem, før tallet skrives på et tilbud. En lang periode lover mere end sikkerhedsrettelser. Den forudsætter, at I har:

• Folk, der kan koden. Kan I stadig rette den gamle del om mange år? Tanken rækker ind i produkter i gammel teknologi.
• Komponenter, der holder. Mister et centralt bibliotek sin egen support, skal I stadig kunne dække jeres løfte. Kommissionens FAQ nævner kontrol af komponentens supportperiode som en del af omhuen.
• Værktøjer, der virker. En rettelse kræver, at I stadig kan bygge den gamle version. Gemte versioner af byggeværktøjer og afhængigheder bliver en del af løftet.
• En måde at levere rettelsen på. Rettelser skal kunne nå kunderne, også dem på ældre versioner.
• Kapacitet. Hver version med aktiv support tager tid fra nyt.

Sådan fastsætter I perioden

1. Find den forventede brugstid. Hvor længe bruger kunderne reelt produktet? Se på jeres egne data: Hvor længe kører installerede versioner, og hvornår skifter kunderne?
2. Læs kriterierne. Gennemgå art. 13, stk. 8, og noter, hvordan de passer på produktet.
3. Se på komponenterne. Hvilke centrale dele har kendte udløbsdatoer?
4. Vælg en versionspolitik. Hvilke versioner støttes, og hvad betyder det for ældre versioner? Er seneste version nok, så lad det stå tydeligt.
5. Skriv begrundelsen ned. Den hører til dokumentationen, så beslutningen kan forklares senere.
6. Lad direktøren godkende. Det er et forretningsløfte.

Gamle versioner og køreplanen

Når en periode er fastsat, bliver den en dato i den tekniske køreplan. Tre datoer hører til hver version: lancering, slut på almindelig udvikling og slut på sikkerhedsrettelser.

Har I kunder på gamle versioner, skal de vide, hvad der sker, og hvornår. Det er sjældent populært, og derfor skal planen ligge fast, længe før datoen. Fremgangsmåden står i udfasning af gamle versioner. Produkter fra før 11. december 2027 rammes først af kravene, hvis de væsentligt ændres fra den dato, se hvornår er en opdatering en væsentlig ændring?.

Salg og aftaler

Slutdatoen skal oplyses ved køb, så salg, tilbud og produktbeskrivelser skal have samme tal. Vi anbefaler, at I:

• Skriver datoen ét sted, som alle henter fra.
• Sammenholder den med løfter om support, der allerede står i kundeaftaler.
• Overvejer, om den skal stå på jeres hjemmeside.
• Lader en advokat læse formuleringerne.

Sælger I til forbrugere eller med fysiske produkter, kan supportperioden også have betydning for ansvaret. Lovforslaget om produktansvar kobler opdateringer til ansvaret, og det er endnu ikke vedtaget.

Tegn på, at I ikke er klar

• Ingen kan sige, hvor mange versioner der er i brug hos kunderne.
• Den gamle version kan ikke bygges længere.
• Salg lover support, som udviklingen ikke kender til.
• Ingen ved, om vigtige komponenter stadig vedligeholdes.

Det skal I lade være med

• At skrive fem år, fordi tallet står i reglerne · perioden skal bygge på den forventede brugstid.
• At love mere, end I kan bygge og rette · perioden binder folk, værktøj og komponenter.
• At lade datoen stå forskellige steder · kunden får et løfte fra den tekst, der står forkert.

Det skal I kræve af den eksterne

• ☐ En begrundet supportperiode pr. produkt.
• ☐ En versionspolitik, som salg kan forstå.
• ☐ En liste over komponenter med kendt udløb.
• ☐ En bekræftelse af, at ældre versioner stadig kan bygges.
• ☐ Datoer i den tekniske køreplan.

Kilder

• Kommissionens vejledning C(2026) 5252: ikke bindende, nr. 125 til 129 med eksempel 52.
• Kommissionens FAQ: afsnit 4.4 om komponenter.
• Forordning (EU) 2024/2847: art. 13, stk. 8, 10 og 19.

Senest gennemgået: november 2026.

Næste skridt

• Sikkerhed i produktet og i udviklingsprocessen
• Cyber Resilience Act: hvad betyder den for jeres produkt?

Læs også: Tredjepartsbiblioteker, SBOM og byggepipeline · Skal produktet skrives om?

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT