Cyber Resilience

Supportperioden: begrundelsen i den tekniske dokumentation

Supportperioden: begrundelsen i den tekniske dokumentation

Supportperioden for et softwareprodukt skal efter Cyber Resilience Act afspejle det tidsrum, produktet forventes at være i brug, og den er som udgangspunkt mindst fem år. Den tekniske dokumentation skal indeholde de oplysninger, I lagde vægt på, da I fastsatte den.

Reglerne findes i artikel 13, stk. 8, og bilag VII, nr. 4, med virkning fra 11. december 2027. Supportperioden styrer, hvor længe I skal håndtere sårbarheder, så begrundelsen er et af de dokumenter, en gennemgang læser grundigst.

Kriterierne i artikel 13, stk. 8

Artikel 13, stk. 8, andet afsnit, siger, at fabrikanten fastsætter supportperioden, så den afspejler det tidsrum, produktet forventes at være i brug. Stykket nævner kriterier, som Kommissionens FAQ (punkt 4.5.1) deler i to grupper.

Det, der skal tages hensyn til:

  • rimelige brugerforventninger
  • produktets art, herunder det tilsigtede formål
  • relevant EU-ret, der fastsætter produkters levetid

Det, der kan tages hensyn til:

  • supportperioder for lignende produkter fra andre fabrikanter
  • om driftsmiljøet fortsat er tilgængeligt
  • supportperioder for integrerede tredjepartskomponenter, der leverer centrale funktioner
  • vejledning fra den administrative samarbejdsgruppe (ADCO) og Kommissionen

Forholdene overvejes forholdsmæssigt. Vi har ikke set vejledning fra ADCO om supportperioder (november 2026), så det sidste kriterium har endnu intet indhold at støtte sig til.

Fem år er en bundgrænse

Artikel 13, stk. 8, tredje afsnit, siger, at supportperioden er mindst fem år. Forventes produktet brugt i kortere tid, svarer supportperioden til den forventede anvendelsestid.

Kommissionens vejledning (punkt 126) kalder de fem år et sikkerhedsnet. Tallet er tænkt som en nedre grænse og er ingen standard for alle produkter. Forventes produktet brugt længere, skal supportperioden være længere. Betragtning 60, som FAQ’en (punkt 4.5.2) citerer, nævner styresystemer og videoredigeringsværktøjer som eksempler på software, der ofte bruges i mere end fem år.

Det afgørende er den forventede brugstid. Den kan føre til en periode på mere end fem år, og kun i særlige tilfælde til en kortere.

Kommissionen kan efter fjerde afsnit fastsætte minimumsperioder for bestemte produktkategorier ved en delegeret retsakt, hvis data fra markedsovervågningen viser, at supportperioderne er for korte. Vi har ikke set en sådan retsakt (november 2026).

Supportperioden binder andre pligter

Tallet styrer mere end dokumentationen. Kravene i bilag I, del II, om sårbarhedshåndtering skal efter Kommissionens FAQ (punkt 4.1.3) opfyldes i hele perioden. Slutdatoen skal efter artikel 13, stk. 19, oplyses til kunderne ved købet, og perioden indgår i reglen i stk. 9 om, hvor længe sikkerhedsopdateringer skal kunne hentes. En lang periode binder altså sårbarhedsarbejdet i mange år, og en kort periode skal kunne forsvares. Begrundelsen er stedet, hvor den afvejning bliver synlig.

Det, dokumentationen skal indeholde

Artikel 13, stk. 8, femte afsnit, og bilag VII, nr. 4, kræver, at den tekniske dokumentation indeholder de oplysninger, der blev taget i betragtning ved fastlæggelsen af supportperioden. Dokumentationen skal altså vise vejen til tallet.

En begrundelse, der kan efterprøves, kunne have disse felter. Felterne og eksemplerne er tænkte:

  • Produkt og version · (lagerstyringssystem, version 8)
  • Tilsigtet formål · (styring af varelager i mellemstore virksomheder)
  • Forventet brugstid og grundlag · (kunder bruger typisk en hovedversion i syv til ni år, efter salgsdata for de seneste versioner)
  • Brugerforventninger · (branchen køber systemet som en langvarig investering)
  • Driftsmiljø · (understøttede databaser og styresystemer, og hvor længe de forventes at findes)
  • Centrale tredjepartskomponenter · (rammeværk og database med kendte supportperioder)
  • Lignende produkter · (oplysninger om andre fabrikanters supportperioder, hvis de er brugt)
  • Fastsat supportperiode · (ti år fra omsætningen af versionen)

Det centrale felt er grundlaget for den forventede brugstid. Uden det er resten af begrundelsen svær at efterprøve.

Typiske svagheder i en begrundelse

De følgende svagheder er tænkte, men de viser, hvad en gennemgang leder efter.

En begrundelse, der kun siger “fem år, som forordningen kræver”, tager ikke stilling til den forventede brugstid. En begrundelse, der henviser til tredjepartskomponenternes supportperioder, men ikke forklarer, hvad der sker, når en komponent udløber før produktet, efterlader et hul. Og en begrundelse, der er skrevet efter, at tallet var valgt af salgsafdelingen, kan være svær at forsvare, hvis grundlaget ikke passer.

Sådan efterprøver gennemgangen tallet

Gennemgangen læser begrundelsen og holder den op mod det, der ellers kan vides om produktet. Metoden er praksis. Svarer den forventede brugstid til det, kunderne faktisk gør? Er de kriterier, stk. 8 kræver, behandlet? Passer supportperioderne for de centrale komponenter til produktets? Og er det samme tal oplyst til kunderne som slutdato ved købet?

Vil I have begrundelsen læst af en uvildig part, før den bliver en del af dokumentationen, kan Nielco IT gennemgå den mod kriterierne i stk. 8.

Hvad det kræver, og hvad det koster at lade være

Det kræver data om, hvor længe kunderne bruger produktet, og en skriftlig begrundelse, der knytter data til tallet. Det kræver også, at produkt, salg og udvikling er enige om tallet, fordi det binder sårbarhedshåndteringen i hele perioden.

En supportperiode uden begrundelse er svær at forsvare over for myndigheden. Er den for kort i forhold til den forventede brugstid, står I med et produkt, der ikke opfylder artikel 13, stk. 8.

Det skal I lade være med

  • At vælge fem år, fordi det er minimum · Kommissionen kalder det et sikkerhedsnet.
  • At skrive begrundelsen efter, at tallet er valgt · grundlaget skal bære tallet.
  • At glemme komponenter, der udløber før produktet · det er et af kriterierne.

Det skal auditten kunne vise

  • ☐ En begrundelse efter bilag VII, nr. 4, med stillingtagen til kriterierne i stk. 8.
  • ☐ Grundlaget for den forventede brugstid.
  • ☐ Sammenhæng mellem komponenternes og produktets supportperioder.
  • ☐ Samme slutdato i dokumentationen og i oplysningerne til kunderne.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Find ud af, hvor længe jeres kunder i gennemsnit bruger en hovedversion, og skriv grundlaget ned ved siden af den supportperiode, I har i tankerne.

Læs også: Komponentens support slutter · Slutdatoen ved købet og beskeden i programmet

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.