For software, der er bragt i omsætning før 11. december 2027, gælder indberetningspligten i artikel 14 alligevel. Fabrikanten skal melde en aktivt udnyttet sårbarhed og underrette brugerne, men forordningen kræver ikke, at den retter sårbarheden.
Det lyder som en lille pligt. For et produkt, som ingen i huset længere kan bygge, kan det alligevel være svært at svare på det mest basale: hvilke versioner er berørt, og hvem bruger dem?
Hvad forordningen siger om ældre produkter
Artikel 69, stk. 3, gør artikel 14 gældende for alle produkter med digitale elementer, der er bragt i omsætning før 11. december 2027. Pligten har været i kraft fra 11. september 2026.
Kommissionens FAQ (punkt 5.3) og vejledningen (punkt 210) forklarer konsekvensen. For de ældre produkter skal fabrikanten indberette, men forordningen kræver ikke, at den opfylder de øvrige pligter, fx sårbarhedshåndtering. Kommissionen nævner selv grundene: værktøjer kan mangle, byggemiljøer kan være umulige at genskabe, afhængigheder kan være forsvundet, og medarbejdere med kendskab til koden kan være gået.
Pligten til at underrette brugerne efter artikel 14, stk. 8, gælder også for de ældre produkter, bekræfter FAQ’en.
ENISA’s FAQ om indberetningsplatformen, opdateret 15. oktober 2026, siger det samme om de ældre produkter og tilføjer en grænse bagud. Kendte fabrikanten allerede til den aktive udnyttelse før 11. september 2026, skal den ikke indberettes bagud. Får fabrikanten først kendskab til udnyttelsen efter den dato, gælder pligten. Datoen for kendskabet bør derfor stå i sagen, også for et gammelt produkt.
Efter supportperioden
Vejledningen (punkt 210) siger desuden, at indberetningspligten fortsætter, efter at supportperioden er udløbet. Sårbarhedshåndteringen gør ikke. Et produkt, hvis support sluttede for år tilbage, kan altså stadig udløse en indberetning, hvis nogen udnytter en sårbarhed i det.
For mange softwarehuse er det de ældste installationer hos de mest konservative kunder, der er sværest at få overblik over.
Fire spørgsmål, der skal kunne besvares
For at kunne udfylde en tidlig varsling og en meddelelse efter 72 timer skal I kunne svare på fire spørgsmål om det ældre produkt. De er ikke opstillet i forordningen, men de følger af, hvad indberetningen og underretningen beder om.
- Hvilke versioner findes hos kunderne? Uden et versionsregister kan I ikke sige, om sårbarheden findes i den version, en bestemt kunde kører.
- Hvilke lande er produktet solgt i? Varslingen skal i givet fald nævne medlemsstaterne.
- Hvem er brugerne? Underretningen efter stk. 8 kræver, at I kan nå dem.
- Hvad kan brugerne selv gøre? Meddelelsen efter 72 timer skal nævne de foranstaltninger, brugerne kan træffe. For et produkt uden rettelse kan det være at slå en funktion fra, lukke en port eller tage systemet ud af drift.
Det fjerde spørgsmål er ofte det sværeste uden et byggemiljø. Til det rækker en forståelse af produktet. Den viden kan findes i gammel dokumentation, i supportsager eller hos tidligere medarbejdere.
Hvad der kan være tilbage
En gennemgang af et ældre produkt handler om at kortlægge det, der er tilbage af viden. Det er praksis. Typiske kilder:
- releasenoter og gamle installationsvejledninger
- supportsystemets historik med versioner pr. kunde
- licensregistre og fakturaer, der viser, hvem der har købt hvad
- kildekode i et arkiv, også selv om den ikke kan bygges
- gamle komponentlister eller byggefiler, der viser, hvilke biblioteker der indgik
Kildekode, der ikke kan bygges, kan stadig læses. Den kan vise, om en bestemt komponent eller funktion findes i produktet, og dermed om en offentligt kendt sårbarhed er relevant.
Når produktet ikke kan rettes
For de ældre produkter kræver forordningen ingen rettelse. Brugerne skal stadig have besked. Den endelige rapport for en sårbarhed er knyttet til, at en korrigerende eller afbødende foranstaltning er tilgængelig. For et produkt, hvor ingen rettelse kommer, kan afbødningen være en vejledning til brugerne. Hvordan den slags afbødning håndteres for nyere produkter, står i sårbarheden kan ikke rettes.
Hvordan reglerne anvendes i en konkret sag, hvor intet kan rettes, er ikke afklaret i dansk praksis. Der er endnu ingen tilsynspraksis i november 2026.
Hvem der ejer de gamle produkter
I mange softwarehuse har de ældre produkter ingen fast ejer. Udviklerne arbejder på det nye, supporten svarer på det, kunderne spørger om, og ingen har ansvaret for at holde viden om det gamle samlet. Når en aktivt udnyttet sårbarhed dukker op i et af dem, bruges de første timer på at finde ud af, hvem der skal tage sagen.
En simpel løsning er at give hvert ældre produkt en navngiven ejer, som ved, hvor kildekode, releasenoter og kundelister ligger, og som kan svare på de fire spørgsmål ovenfor. Ejeren behøver ikke kunne bygge produktet. Det er praksis. Til gengæld er det den hurtigste vej til en varsling inden for 24 timer.
Hvad det kræver, og hvad det koster at lade være
Det kræver en liste over de ældre produkter, der stadig er i brug, med versioner, lande og kunder, og en person, der ved, hvor den gamle viden ligger. Det kræver også en skabelon til en brugerbesked, der kan sendes uden en rettelse.
Uden kortlægningen kan en aktivt udnyttet sårbarhed i et glemt produkt efterlade jer uden svar på, hvem der er berørt. Fristen er den samme som for jeres nyeste produkt.
Det skal I lade være med
- At gå ud fra, at gamle produkter er uden for CRA · indberetningen gælder dem.
- At kassere kildekode og releasenoter, fordi produktet ikke kan bygges · de er grundlaget for at vurdere en sårbarhed.
- At stoppe kundelisten, når supporten slutter · underretningen gælder stadig.
Det skal auditten kunne vise
- ☐ En liste over ældre produkter i brug med versioner, lande og kunder.
- ☐ Arkiveret kildekode, releasenoter og komponentoplysninger for hvert produkt.
- ☐ En skabelon til brugerbesked med afbødende tiltag uden rettelse.
- ☐ En navngiven ansvarlig for hvert ældre produkt.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 14, artikel 69, stk. 3, og artikel 71, læst 13. november 2026.
- Europa-Kommissionen, vejledning C(2026) 5252, punkt 210, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 5.3, læst 13. november 2026.
- ENISA, SRP Frequently Asked Questions, spørgsmål 12 og 13, opdateret 15. oktober 2026, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv jeres ældste produkt i brug op og find ud af, om I kan nævne versionerne hos de tre største kunder.
Læs også: Udfasning før 2027 · Versioner fra før 11. december 2027
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
